1. RTS Meeting 8th July 2009
Introduction
Middleware
AUTOSAR
Conclusion

2. Introduction
gateway node
[1] P. Pop, P. Eles, and Z. Peng. Analysis and optimization of heterogeneous real-time embedded systems. IEE Proc. -Comput. Digit. Tech., Vol. 152, No. 2, March 2005.
Figure 1 – Distributed real-time bus network architecture and node hardware structure [1]

3. Introduction
[2] N. Navet (editor) and F. Simonot-Lion (editor). Automotive embedded systems handbook. Industrial Information Technology Series. CRC Press, 2009.
Figure 2 – An example of automotive real-time bus network [2]

4. Introduction Application layer ASCs, functions and tasks
Communication layer
Middleware
MAC and DLL
Physical and data link layer
MAC and arbitration mechanisms
Communication controllers
Application layer
Communication
Layer
MAC and DLL
Figure 3 – Layered architecture of a node

5. Middleware Hiding the distribution Hiding the heterogeneity
Same services, interfaces for intra-ECU, inter-ECU and inter-domain
Hiding the heterogeneity
Encapsulate OS services, provide API for them, common services to access I/O devices
Providing high-level services
membership services, redundancy management, remote procedure call (RPC) and working mode management and frame packing
Ensuring QoS
additional mechanisms and services such as additional CRC, reliable acknowledgement service, frame packing and filtering mechanisms

6. Middleware Middleware examples: TITUS/DBKOM OSEK/VDX Volcano
OSEK/VDX FTCom
AUTOSAR

7. AUTOSAR AUTOSAR: AUTomotive Open System Architecture [2] [3]
Formed as a partnership (10 core partners) in 2003
The first phase: with first AUTOSAR products
Main idea: Controlling the complexity together with an increase in quality and profitability.
The future of automotive engineering is in modular and scalable sw architectures.
Motivation
Demands for safety, comfort, services, economy …
Increasing complexity
More diversity of ECU hardware and networks (CAN, LIN, FlexRay, MOST etc.)
[3] AUTOSAR GbR. Main requirements, V3.1. Available: June 2009.

8. AUTOSAR Shortcomings before AUTOSAR
Non-standardization for networks and development processes
Lack of appropriate level of abstraction in sw architecture modeling and integration
The architectures did not meet quality requirements

9. AUTOSAR
Objectives
Main principle: cooperate on standards, compete on implementation
Availability and safety
Scalability and integration
Maintainability
Increased use of COTS hw
Transferability of functions

10. AUTOSAR XML class model, specified in UML 2.0, is used for modeling
Separation of “application” development from the lower levels integration (Basic Software-BSW)
The separator: Runtime environment (RTE) – RTE uses Virtual Functional Bus (VFB) as abstracting communication principle
No need to know what is going on lower levels
Easier application development

11. AUTOSAR Concept: Development methodology: model-driven
s/w architecture, ECU hardware and n/w topology are modeled in a formal way defined in a metamodel
Support the development from architecture to integration

12. AUTOSAR: Software Architecture
Figure 4 – ECU layered software architecture defined by AUTOSAR [2, 3]

13. AUTOSAR: Software Architecture
Figure 5 – Detailed ECU layered software architecture [2, 3]

14. Service layer includes AUTOSAR OS (needs to access to hardware; i. e
Service layer includes AUTOSAR OS (needs to access to hardware; i.e. timer)
Separation of BSW and ASW by RTE
RTE allows ASW to access BSW services in a “clearly defined way” (API)
RTE provides communication services (VFB)

15. AUTOSAR: BSW & RTE BSW: Drivers, services and AUTOSAR OS
AUTOSAR defines 63 BSW modules
BSW modules have interfaces
Implementation conformance classes (ICC1, ICC2, ICC3) for the BSW

16. AUTOSAR: BSW & RTE
Figure 6 –The features of the RTE [2]

17. AUTOSAR: BSW & RTE
RTE
Performs as a “glue” between two parts (BSW and ASW)
Employs BSW to implement ASW behavior (port and runnable entities)
Communication (send/receive or client/server)
Activation of runnable entities
Generation of RTE
Contract phase
ECU independent
Input: description of an ASW component (ports and runnable entities)
API functions used by ASW components (i.e. send)
Output: ASW component-specific header file
Generation phase
Concrete code generation
Input: ECU configuration description (mapping of runnable entities to OS tasks and communication matrix) and ASW header file
Output: generated code can be compiled to executable file for that ECU

18. AUTOSAR: Methodology
Figure 7 – AUTOSAR methodology [2]

19. AUTOSAR: Methodology
Configure System: maps ASW components to ECUs (considering resource and timing requirements)
Outputs:
System configuration description (mapping, topology, etc.)
System communication matrix (features of networks/media used)
Configure ECU: uses info for implementation such as tasks, scheduling, main BSW modules list, mapping runnables to tasks and configuration of BSW modules
Output:
ECU configuration description with fixing all configuration parameters

20. AUTOSAR: Methodology
Figure 8 – Input information and .XML file generation [2]

21. AUTOSAR: Methodology
Figure 9 – System configuration overview [2]

22. AUTOSAR as Middleware Reference Model Two communication models
Application layer
BSW (Middleware software components)
RTE
Two communication models
Sender/receiver
Explicit mode
Implicit mode
Client/server

23. AUTOSAR as Middleware
Figure 10 – Communication software architecture [2]

24. AUTOSAR as Middleware Communication Elements Signal
specified with length and type (data or event)
Exchanged between software components at the application level
Transfer property parameter
Triggered
Pending
Signal types
Data: Not queued on the receiver side (overwrite on the previous data value)
Event: queued (handling of queues and buffers is done by RTE)

25. AUTOSAR as Middleware Communication Elements I-PDU
Formed by AUTOSAR COM service component
Consists of one or more signals
Maximum length of I-PDU depends on max. length of N-PDU (DLL PDU)
Behavioral parameter
Direct
Periodic
Mixed
None

26. AUTOSAR as Middleware Communication Elements N-PDU
Formed by Transport Protocol (TP) of related communication network (CAN, FlexRay, LIN etc.)
TP not mandatory but if it is used,
Splitting the I-PDU to obtain several N-PDUs
Assembling several I-PDUs into one N-PDU
The length of payload is decided underlying protocol

27. AUTOSAR as Middleware AUTOSAR COM Component
Not fully independent from underlying network
Considering the length of the payload
Determine the points at which I-PDUs will be sent depending on
Transmission mode (direct, periodic, mixed)
Transfer property of signals (triggered, pending and mixed)
Ensure the transmission/reception and informs the sender/receiver
Filtering mechanism for signals
Packing/unpacking of signals into/from I-PDUs

28. AUTOSAR as Middleware
Figure 11 – Transmission of an I-PDU consisting of two signals
S1 (triggered) and S2 (pending) during mixed transmission mode [2]

29. Conclusion Future Directions:
Cross-domain communication (function, location and network) by gateways  improvement needed for interoperability between applications.
Optimization of networking architectures (s/w tools, i.e. NETCAR-Analyzer [4])
Facilitation of the use of s/w along development cycle (ASAM FIBEX standard)
[4] Available: