RTS Meeting 8th July 2009 Introduction Middleware AUTOSAR Conclusion

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]

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]

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

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

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

AUTOSAR AUTOSAR: AUTomotive Open System Architecture [2] [3] Formed as a partnership (10 core partners) in 2003 The first phase: 2003-2006 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: www.autosar.org. June 2009.

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

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

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

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

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

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

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)

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

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

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

AUTOSAR: Methodology Figure 7 – AUTOSAR methodology [2]

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

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

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

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

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

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)

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

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

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

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

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: www.realtimeatwork.com.