Download slides

RTS Meeting
8th 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
–
Communication
Layer
MAC and DLL
Figure 3 – Layered architecture of a node
•
Middleware
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 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 SoftwareBSW)
• 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)