Higher Level Protocols - CAN System Engineering - page 201

buffer or other) is part of the ECU configuration and will be defined by an integration
expert who is integrating basic software with the application software.

4.2.3.2 Communication Path Through the Basic Software

AUTOSAR defines several modules which are taking part to send or receive a sig-
nal. On a first view, the modularity is complex and oversized. The advantages of the
clear separation of functionality seem to be bought very costly—if at each module
border, e.g. a buffer is needed to store the data temporarily. If each module is devel-
oped to be 100 % exchangeable the buffers may be needed, and if the modules are
bundled it is possible to apply optimizations across the borders with the result that
resources are not wasted. This can be done also if the configuration tooling has a
clear view to the overall configuration, knowing all the facts and hence be able to
provide an optimized configuration.
The following example shows how a signal will run through the AUTOSAR-
layered architecture from a sender to a receiver application software component.
The example refers to the CAN stack.

4.2.3.3 AUTOSAR Application

Within the application, information will be represented as a signal. For example, the
actual vehicle speed could be an 8-bit value from 0 to 255, representing the speed
in km/h. The port of the application, through which the signal is sent, is defined by
an interface containing an 8-bit data element. The interface and the data type are de-
fined within the software component description (XML). The generation of the RTE
will also generate a component header (C-code) where these data types are defined.
The RTE has two modes for the generation: In the contract phase, all c-headers with
all data definitions are generated which are needed by the application software com-
ponents (data types, constants, interface structures, function prototypes of the RTE
API, etc.). In the second phase, the RTE generation phase, also the implementation
of the functions will be generated. This is only possible if the complete path of the
signal is known, i.e. the receiver and the medium for transport are defined (another
software component on the same ECU, an output port of the microcontroller or
something on another ECU).
If the interface and data types are defined in the software configuration descrip-
tion, the port can be configured. The name of the port is later a part of the RTE-send-
API within the application software component. A runnable entity with the name
MyRunnable can call the send function of the port pPortname with the value Value
and data element Speed like shown in the following code-fragment: