RTS Meeting 8 th July 2009 Introduction Middleware

RTS Meeting 8 th July 2009 • • Introduction Middleware AUTOSAR Conclusion

Introduction gateway node Figure 1 – Distributed real-time bus network architecture and node hardware structure [1]

Introduction Figure 2 – An example of automotive real-time bus network [2]

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

Middleware • Hiding the distribution – Same services, interfaces for intra-ECU, inter-ECU and interdomain • 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 Qo. S – 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, Flex. Ray, MOST etc. )

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. 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 (ICC 1, ICC 2, ICC 3) 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 – 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, Flex. Ray, 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 S 1 (triggered) and S 2 (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)