RTS Meeting 8 th July 2009 Introduction Middleware AUTOSAR Conclusion.
-
Upload
rudolf-parker -
Category
Documents
-
view
214 -
download
1
Transcript of RTS Meeting 8 th July 2009 Introduction Middleware AUTOSAR Conclusion.
![Page 1: RTS Meeting 8 th July 2009 Introduction Middleware AUTOSAR Conclusion.](https://reader036.fdocuments.in/reader036/viewer/2022062516/56649e6c5503460f94b6b32b/html5/thumbnails/1.jpg)
RTS Meeting8th July 2009
• Introduction
• Middleware
• AUTOSAR
• Conclusion
![Page 2: RTS Meeting 8 th July 2009 Introduction Middleware AUTOSAR Conclusion.](https://reader036.fdocuments.in/reader036/viewer/2022062516/56649e6c5503460f94b6b32b/html5/thumbnails/2.jpg)
Introduction
gateway node
Figure 1 – Distributed real-time bus network architecture and node hardware structure [1]
![Page 3: RTS Meeting 8 th July 2009 Introduction Middleware AUTOSAR Conclusion.](https://reader036.fdocuments.in/reader036/viewer/2022062516/56649e6c5503460f94b6b32b/html5/thumbnails/3.jpg)
Introduction
Figure 2 – An example of automotive real-time bus network [2]
![Page 4: RTS Meeting 8 th July 2009 Introduction Middleware AUTOSAR Conclusion.](https://reader036.fdocuments.in/reader036/viewer/2022062516/56649e6c5503460f94b6b32b/html5/thumbnails/4.jpg)
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
![Page 5: RTS Meeting 8 th July 2009 Introduction Middleware AUTOSAR Conclusion.](https://reader036.fdocuments.in/reader036/viewer/2022062516/56649e6c5503460f94b6b32b/html5/thumbnails/5.jpg)
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
![Page 6: RTS Meeting 8 th July 2009 Introduction Middleware AUTOSAR Conclusion.](https://reader036.fdocuments.in/reader036/viewer/2022062516/56649e6c5503460f94b6b32b/html5/thumbnails/6.jpg)
Middleware
• Middleware examples:– TITUS/DBKOM– OSEK/VDX– Volcano– OSEK/VDX FTCom– AUTOSAR
![Page 7: RTS Meeting 8 th July 2009 Introduction Middleware AUTOSAR Conclusion.](https://reader036.fdocuments.in/reader036/viewer/2022062516/56649e6c5503460f94b6b32b/html5/thumbnails/7.jpg)
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.)
![Page 8: RTS Meeting 8 th July 2009 Introduction Middleware AUTOSAR Conclusion.](https://reader036.fdocuments.in/reader036/viewer/2022062516/56649e6c5503460f94b6b32b/html5/thumbnails/8.jpg)
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
![Page 9: RTS Meeting 8 th July 2009 Introduction Middleware AUTOSAR Conclusion.](https://reader036.fdocuments.in/reader036/viewer/2022062516/56649e6c5503460f94b6b32b/html5/thumbnails/9.jpg)
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
![Page 10: RTS Meeting 8 th July 2009 Introduction Middleware AUTOSAR Conclusion.](https://reader036.fdocuments.in/reader036/viewer/2022062516/56649e6c5503460f94b6b32b/html5/thumbnails/10.jpg)
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
![Page 11: RTS Meeting 8 th July 2009 Introduction Middleware AUTOSAR Conclusion.](https://reader036.fdocuments.in/reader036/viewer/2022062516/56649e6c5503460f94b6b32b/html5/thumbnails/11.jpg)
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
![Page 12: RTS Meeting 8 th July 2009 Introduction Middleware AUTOSAR Conclusion.](https://reader036.fdocuments.in/reader036/viewer/2022062516/56649e6c5503460f94b6b32b/html5/thumbnails/12.jpg)
AUTOSAR: Software Architecture
Figure 4 – ECU layered software architecture defined by AUTOSAR [2, 3]
![Page 13: RTS Meeting 8 th July 2009 Introduction Middleware AUTOSAR Conclusion.](https://reader036.fdocuments.in/reader036/viewer/2022062516/56649e6c5503460f94b6b32b/html5/thumbnails/13.jpg)
AUTOSAR: Software Architecture
Figure 5 – Detailed ECU layered software architecture [2, 3]
![Page 14: RTS Meeting 8 th July 2009 Introduction Middleware AUTOSAR Conclusion.](https://reader036.fdocuments.in/reader036/viewer/2022062516/56649e6c5503460f94b6b32b/html5/thumbnails/14.jpg)
• 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)
![Page 15: RTS Meeting 8 th July 2009 Introduction Middleware AUTOSAR Conclusion.](https://reader036.fdocuments.in/reader036/viewer/2022062516/56649e6c5503460f94b6b32b/html5/thumbnails/15.jpg)
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
![Page 16: RTS Meeting 8 th July 2009 Introduction Middleware AUTOSAR Conclusion.](https://reader036.fdocuments.in/reader036/viewer/2022062516/56649e6c5503460f94b6b32b/html5/thumbnails/16.jpg)
AUTOSAR: BSW & RTE
Figure 6 –The features of the RTE [2]
![Page 17: RTS Meeting 8 th July 2009 Introduction Middleware AUTOSAR Conclusion.](https://reader036.fdocuments.in/reader036/viewer/2022062516/56649e6c5503460f94b6b32b/html5/thumbnails/17.jpg)
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
![Page 18: RTS Meeting 8 th July 2009 Introduction Middleware AUTOSAR Conclusion.](https://reader036.fdocuments.in/reader036/viewer/2022062516/56649e6c5503460f94b6b32b/html5/thumbnails/18.jpg)
AUTOSAR: Methodology
Figure 7 – AUTOSAR methodology [2]
![Page 19: RTS Meeting 8 th July 2009 Introduction Middleware AUTOSAR Conclusion.](https://reader036.fdocuments.in/reader036/viewer/2022062516/56649e6c5503460f94b6b32b/html5/thumbnails/19.jpg)
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
![Page 20: RTS Meeting 8 th July 2009 Introduction Middleware AUTOSAR Conclusion.](https://reader036.fdocuments.in/reader036/viewer/2022062516/56649e6c5503460f94b6b32b/html5/thumbnails/20.jpg)
AUTOSAR: Methodology
Figure 8 – Input information and .XML file generation [2]
![Page 21: RTS Meeting 8 th July 2009 Introduction Middleware AUTOSAR Conclusion.](https://reader036.fdocuments.in/reader036/viewer/2022062516/56649e6c5503460f94b6b32b/html5/thumbnails/21.jpg)
AUTOSAR: Methodology
Figure 9 – System configuration overview [2]
![Page 22: RTS Meeting 8 th July 2009 Introduction Middleware AUTOSAR Conclusion.](https://reader036.fdocuments.in/reader036/viewer/2022062516/56649e6c5503460f94b6b32b/html5/thumbnails/22.jpg)
AUTOSAR as Middleware
• Reference Model– Application layer– BSW (Middleware software components)– RTE
• Two communication models– Sender/receiver
• Explicit mode• Implicit mode
– Client/server
![Page 23: RTS Meeting 8 th July 2009 Introduction Middleware AUTOSAR Conclusion.](https://reader036.fdocuments.in/reader036/viewer/2022062516/56649e6c5503460f94b6b32b/html5/thumbnails/23.jpg)
AUTOSAR as Middleware
Figure 10 – Communication software architecture [2]
![Page 24: RTS Meeting 8 th July 2009 Introduction Middleware AUTOSAR Conclusion.](https://reader036.fdocuments.in/reader036/viewer/2022062516/56649e6c5503460f94b6b32b/html5/thumbnails/24.jpg)
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)
![Page 25: RTS Meeting 8 th July 2009 Introduction Middleware AUTOSAR Conclusion.](https://reader036.fdocuments.in/reader036/viewer/2022062516/56649e6c5503460f94b6b32b/html5/thumbnails/25.jpg)
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
![Page 26: RTS Meeting 8 th July 2009 Introduction Middleware AUTOSAR Conclusion.](https://reader036.fdocuments.in/reader036/viewer/2022062516/56649e6c5503460f94b6b32b/html5/thumbnails/26.jpg)
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
![Page 27: RTS Meeting 8 th July 2009 Introduction Middleware AUTOSAR Conclusion.](https://reader036.fdocuments.in/reader036/viewer/2022062516/56649e6c5503460f94b6b32b/html5/thumbnails/27.jpg)
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
![Page 28: RTS Meeting 8 th July 2009 Introduction Middleware AUTOSAR Conclusion.](https://reader036.fdocuments.in/reader036/viewer/2022062516/56649e6c5503460f94b6b32b/html5/thumbnails/28.jpg)
AUTOSAR as Middleware
Figure 11 – Transmission of an I-PDU consisting of two signals S1 (triggered) and S2 (pending) during mixed transmission mode [2]
![Page 29: RTS Meeting 8 th July 2009 Introduction Middleware AUTOSAR Conclusion.](https://reader036.fdocuments.in/reader036/viewer/2022062516/56649e6c5503460f94b6b32b/html5/thumbnails/29.jpg)
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)