AUTOSAR VFB & RTEIntroduction • In order to achieve a high degree of transparency against the underlying hardware infrastructure, the AUTOSAR standard introduces two architectural concepts that facilitate infrastructure independent software development: – The Virtual Function Bus (VFB) – The Runtime Infrastructure (RTE) • The AUTOSAR software architecture follows several abstraction principles for obtaining flexibility against the underlying infrastructure. • Any piece of software within an AUTOSAR infrastructure can be seen as an independent component while each AUTOSAR application is a set of interconnected AUTOSAR components • The different layers of abstraction allow the application designer to disregard several aspects of the physical system on which the application will later be deployed on, like: – Type of microcontroller – Type of ECU hardware – Physical location of interconnected components – Networking technology / buses – Instantiation of components / Number of instances Virtual Function Bus (VFB) • The virtual function bus can be described as a system modeling and communication concept • Logical entity that facilitates the concept of relocatability within the AUTOSAR software architecture • Provides a virtual infrastructure that is independent from any actual underlying infrastructure • Provides all services required for a virtual interaction between AUTOSAR components • Separates the domain of application development and modeling from the infrastructure Runtime Environment (RTE) • The runtime environment provides an actual representation of the virtual concepts of the VFB for one specific ECU • Each ECU has its own customized RTE implementation which is generated during the ECU Configuration process of the AUTOSAR methodology • The ECU mapping, i.e. the information about which component will be deployed on which ECU, is part of the input of this configuration process g. e.RTE • Depending on the location of each component. the formerly virtual interaction can then be mapped to real interaction implementation • Components that are mapped onto one ECU will communicate through Intra ECU-Mechanisms. like function calls while Inter-ECU communication will be realized using. a communication bus infrastructure • Since the RTE source code is usually generated. it can be tailored by the generator to implement exactly the communication paths required by its connected AUTOSAR components • RTE can be seen as a static implementation of specialized communication topologies VFB to RTE Mapping where the Virtual Communication Topology is mapped to Three Different ECUs . Comparison of VFB and RTE with Focus on Selected Common Concepts Generation of RTE Generation of RTE . • This means that an RTE implementation always provides only the functionality that is needed for a given configuration. It provides the contract between a given ASW component and the RTE. the contract phase will generate the API function Rte_Send_p_d.• The RTE is generated in order to ensure that it fits a given ECU and system configuration. Generation phase: • In this phase the concrete code generation for a given ECU is performed. which includes especially the mapping of runnable entities to OS tasks or the communication matrix. and nothing more. the API that the ASW component can be coded against. • The result is an ASW component-specific header file that can be included by the corresponding source code file. • Input for this phase is the ECU configuration description. • The generation process is divided into two phases . For example.Contract phase . • The set of allowed API functions depends on the ports of the given ASW component. if an ASW component has a send-port p with a data element d. . • The input for this phase is the description of an ASW component with all its ports and runnable entities. that is.Generation phase Contract phase: • This phase is ECU-independent. a mapping between operating system tasks and existing runnables is created that is later used by the RTE to define and perform scheduling and execution of the runnables according to their specification Categories of Runnables • Type 1 Runnables . the generated code can then be compiled to an executable file for the given ECU. each piece of functionality that has to be executed during runtime of the software component is wrapped into a so-called Runnable • The VFB-Specification defines a runnable as a Sequence of instructions that can be started by the Run-Time Environment • Each runnable that a component provides can be invoked by the RTE and is executed within the context of the underlying operating system • An atomic software component can consist of an arbitrary number of runnables of which each might have its own execution semantics • During the process of ECU configuration.• Together with the ASW component header files created during the contract phase and all necessary BSWcode. Runnables • Since AUTOSAR software components have no direct access to the underlying hardware or the operating system. the implementation of the atomic software components cannot reflect artifacts like Threads or Processes • Instead. } Integration..Relationship between OS.g...). the receive of a data value) – Such runnables are mapped by the RTE to extended operating system tasks that support the state Waiting Pseudo-code Implementation of a Runnable Body void SeatHeating_Runnable_run1 () { . // do something RTE_Write_OutPort_Value (. RTE_Read_InPort_Value (..RTE and VFB . ...)...– Consists of a set of instructions that can be determined to terminate within a finite time – Blocking RTE calls that contain WaitPoints cannot be contained in a type 1 runnable – Runnables that fulfil these constraints are usually mapped to basic operating system tasks • Type 2 Runnables – Contains at least one wait point that causes the runnable to terminate only upon the appearance of an external event (e. like the operating system.g. OSEK OS) does not know about the concepts of runnables at all • Instead. depending on their view on the overall system OS View • An AUTOSAR-Compliant Operating System (e.• The concept of runnables affects several aspects of AUTOSAR. they will be executed anytime the corresponding OS task is scheduled . the operating system usually maintains a list of schedulable entities that are under management of a scheduling algorithm • Since runnable entities will be integrated by the RTE into operating system tasks. the runtime environment as well as the virtual function bus • Each of them deals with runnables differently. RTE View • The runtime environment maps runnables that can be executed together into one OS task • This task is then structured and controlled using RTE glue code that will control the correct execution of the runnables within the OS task • The boxes colored in red denote single runnables • The corresponding control flow that triggers the execution of such a runnable as well as the glue code (yellow box) is under control of the RTE VFB View • On the level time of the runnable as executed are of the virtual function bus (i. during design application).e. the integration context of the well as the environment in which it will be not of concern • Instead. anything except the sequence of single instructions within the function body and the constraints on invocation for the runnable are disregarded . MCAL. Partial Networking and J1939 Overview Introduction to MCAL . responses and information to different processes Input required for implementation of MCAL .Lowest software layer of AUTOSAR Basic Software Contains internal drivers Accesses internal peripherals of microcontroller directly Accesses memory mapped external devices Make higher software layers independent of microcontroller Manages the microcontroller peripherals and provides the upper layer with microcontroller Implements notification mechanisms to support independent values the distribution of commands. AUTOSAR Software Specification (SWS) Datasheet of Microcontroller (User Manual) Module Groups In MCAL The μC Abstraction Layer consists of the following module groups: Communication Drivers . g. General Purpose Timer) Functions with direct μC access (e. Watchdog.g. DIO Ports and DIO Channel Groups The PWM driver module provides functions for initialization and control of the microcontroller internal PWM unit The ICU Driver controls the input capture unit of the microcontroller Port Driver initializes the whole port structure of the microcontroller Communication Drivers . CAN) (e. ADC.g. external Flash) Microcontroller Drivers Drivers for internal peripherals (e.g. SPI) and vehicle I/O Drivers Drivers for analog and digital I/O (e.g. DIO) Memory Drivers Drivers for on-chip memory devices (e.g. Drivers for ECU onboard communication (e. PWM. internal Flash. Core test) I/O Drivers The ADC driver module initializes and controls the internal Analog to Digital Converter unit of the microcontroller The Digital Input and Output driver module provides services for reading from and writing to the DIO Channels.g. internal EEPROM) and memory mapped external memory devices (e. The Communication drivers performs the hardware access and offers a hardware independent API to the upper layer Memory Drivers Memory driver module provides the interface for erasing. – The order to be followed is as follows: – MCU Initialization – WDG Initialization – PORT Initialization – Individual module initialization (ADC. writing and reading the memory Microcontroller Drivers The GPT driver allows generating continuous timer notifications one-shot or The Watchdog driver module provides services for initialization. GPT…) . power down functionality. reset and microcontroller specific functions required from other Low Level Driver modules Initialization Order – The sequence in which the MCAL modules initialization and APIs to be invoked are very important for the proper operation of individual modules. PWM. changing the operation mode and triggering the watchdog The MCU driver module provides services for basic microcontroller initialization. g. • AUTOSAR R3. especially while bus communication is active (e.3 support only Partial Networking. usually – MCAL modules will have standard defined functionality by AUTOSAR Energy Management Introduction • The goal of efficient energy management in AUTOSAR is to provide mechanisms for power saving.2 and R4.0. charging or clamp 15 active). .– How is MCAL different from Complex Drivers? – Complex Drivers are Application customer specific requirements specific. Energy Management – Partial Networking Example scenario of a partial network going to sleep 1 ECU A 1 ECU B 2 ECU C 2 ECU D 2 Physical CAN Bus Partial Network Cluster 1 Partial Network Cluster 2 . Uses NM messages to communicate the request/release information of a partial network cluster between the participating ECUs Partial Network Cluster (PNC) • PNC is a group of system signals necessary to support one or more vehicle functions that are distributed across multiple ECUs in the vehicle network. Other ECUs can continue to communicate on the same bus channel.Partial Networking Allows for turning off network communication across multiple ECUs in case their provided functions are not required under certain conditions. This represents the system view of mapping a group of buses to one or more VFCs. “C” and “D” are members of PNC 2. therefore ECU “C” can release PNC 2.Initial situation: ECUs “A” and “B” are members of Partial Network Cluster (PNC) 1. ECU “A” is not affected at all. That means it remains awake and continues to transmit and receive all signals associated with PNC 1. PNC 2 is only requested by ECU “C”. The function requiring PNC 2 on ECU “C” is terminated. ECU “B” ceases transmission and reception of all signals associated with PNC 2. Both PNCs are active. This is what happens: ECU “C” stops requesting PNC 2 to be active. ECU “B” still participates in PNC 1. CAN buses without network management) can be activated* using PN but no wake-up or communication of PN information are supported on those buses . ECUs “C” and “D” are no longer participating in any PNC and can be shutdown. All functions of the ECUs are organized either in PNC 1 or PNC 2. ECUs “B”.e. Partial Networking Restrictions Partial Networking (PN) is currently supported on CAN and FlexRay buses. LIN and CAN slave buses (i. To wake-up a PN ECU. Characteristics of J1939 • Higher-layer protocol based on Controller Area Network (CAN) . a special transceiver HW is required as specified in ISO 11898-5. A J1939 bus not using address claiming can however be activated using PN as a CAN slave bus as described above Restrictions on FlexRay FlexRay is only supported for requesting and releasing PNCs. A VFC can be mapped to any number of PNCs (including zero) The concept of PN considers a VFC with only ECUinternal communication by mapping it to the internal channel type in ComM as there is no bus communication and no physical PNC Restrictions for CAN J1939 and PN exclude each other. FlexRay nodes cannot be shut down since there is no HW available which supports PN. The standard wake-up without special transceiver HW known from previous AUTOSAR releases is still supported. due to address claiming and J1939 start-up behavior J1939 need to register first their address in the network before they are allowed to start communication after a wake-up. • Marine Stern Drive and Inboard Spark-Ignition Engine OnBoard Diagnostics • Off-Board Diagnostic Connector • Industrial Generator Sets • Truck and Bus Applications SAE J1939 . • Extended CAN identifier (29 bit) • Bit rate 250 kbit/s • Peer-to-peer and broadcast communication • Transport protocols for up to 1785 data bytes • Network management • Definition of parameter groups for commercial vehicles and others • Manufacturer specific parameter groups are supported • Diagnostics features • Maximum 30 nodes (ECUs) in a network J1939 Applications as J1939 Protocol is used in many applications.• Provides serial data communication between Electronic Control Units (ECUs) in any kind of heavy duty vehicle. few of them are follows: • Agricultural and Forestry Off-Road Machinery Control and Communication Network .Message Format . the Reserved bit (always 0). .the data page bit (currently only 0.the PDU (Protocol Data Unit) Format (PF). PDU Specific will be a Destination Address • PDU Format => 0xF0 identifies message as broadcast. . 1 is reserved for future use).PDU Specific (PS).SAE J1939 . • The PGN is a combination of . PDU Specific will be a Group Extension Example J1939 PGN J1939 Wheel Speed Information • PGN: 65215(0xFEBF) • Priority: 6 (default) • Length: 8 . • PDU Format < 0xF0 defines Peer-to-Peer message.Message Format • A Parameter Group Number (PGN) is a part of the 29-bit identifier sent with every message. . right 906 . left • Byte 6: 908 Relative. front axle #1. rear axle #2. right • Byte 7: 909 Relative. rear axle #1. right • Benefits of Autosar: SPN 904 Relative. left Relative. rear axle #2.• TX Rate: 100 ms • Bytes 1-2: Front axle speed • Byte 3: 905 • Byte 4: • Byte 5: 907 Relative. left • Byte 8: 910 Relative. front axle #1. rear axle #1. The final part of the implementation of the prototype meta model in an existing meta model is more of a demonstration piece.• Drawbacks of AUTOSAR: The methodology used for mapping AUTOSAR concepts on existing has serious drawbacks. there is a risk of inconsistency. they can be parts of inheritance structures violating AUTOSAR. In practise the problems cannot be resolved. the implementation is what usually is called “ugly hack” In order to implement a fully working AUTOSAR meta model the usual . •If both the existing concept and the newly introduced AUTOSAR concept carry the same information. On behalf of multiplied information and the risk of inconsistency the problem can theoretically be resolved with multiple inheritances. SystemWeaver does not support multiple inheritances. but this is easily resolved by making the old concept abstract thereby forcing the use of the new concept • Conflicting inheritance. There is also a risk of confusion over which concepts to use. Even if individual concepts map perfectly on each other. customisation of the SystemWeaver is necessary. . not only with respect of the customers needs but also with respect to AUTOSAR´s requirements.