310 likes | 474 Views
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]. Application layer
E N D
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]
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 Communication Layer MAC and DLL Introduction 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)