rts meeting 8 th july 2009 introduction middleware autosar conclusion
TRANSCRIPT
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)