RTS Meeting8th 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– ASCs, functions and tasks

• Communication layer– Middleware

• MAC and DLL– Physical and data link layer– MAC and arbitration mechanisms– Communication controllers

Application layer

CommunicationLayer

MAC and DLL

Figure 3 – Layered architecture of a node

Middleware

• Hiding the distribution– 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.)

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 (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– 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)