Software Architecture & AUTOSAR for Automotive Embedded system

AUTOSAR (Automotive Open System Architecture) is a worldwide development partnership of automotive interested parties founded way back in 2003. Autosar provides a standardized open software architecture for automotive ECUs. AUTOSAR is a consortium of automotive giants such as Toyota, BMW, VW, Ford, Daimler, GM, Bosch, and PSA., which aims to standardize software architecture for the automotive industry.

In the absence of a common standard, like Autosar by OEMs, ECU software development was on different platforms. There was different software architecture that was used by tier 1 suppliers and their vendors to design the ECU software for OEMs. With this approach, whenever any OEM wishes to switch to a new tier 1 supplier or vice-versa, the transition was very difficult. The new supplier used to face enormous challenges in understanding the existing software architecture, hardware platforms, and standards used in ECU software development. The new supplier faces extreme difficulty to drive an on-going project from the midst of its production life cycle.

Some of the listed goals, principal challenges, and the solutions suggested by AUTOSAR together with the benefits achieved by these solutions. are as follows.

• Handling fast-growing Electrical/Electronic complexity associated with the system
• Implementation flexibility for product modification, upgrade and update
• Improve scalability of software solutions and cross-compatibility
• Improve software quality and reliability of the system
• Enable error detection at early development phases.

AUTOSAR Architecture

AUTOSAR is an open software architecture standardized by the automotive industry. Autosar architecture specifies a standard interface between application software and basic vehicle functions. AUTOSAR is intended to provide inherent benefits to the members to manage increasingly complex E/E in-vehicle environments

Autosar architecture is described by Layered Software Architecture. Layered architecture describes a top-down approach to the hierarchical structure of AUTOSAR software and maps the Basic Software Modules to software layers and shows their relationship.

Significance of Autosar Architecture

The number of electronic/ electric systems and the complexity of these systems are increasing in modern vehicles. The increasing complexity of the vehicle network is the motivation behind the development of AUTOSAR.

Modern vehicles have more than a hundred ECUs each. Every one of them has thousands of functions. Without following the standard, software development is most likely to be rewritten when the ECU hardware design is changed.

Autosar facilitates software development independent of hardware, with the standard software is more transferable. This means software can be easily shared between different vehicle systems largely independent of the system’s underlying hardware, which AUTOSAR improved by standardizing component interaction. In the past, and still today, most component software is developed according to the hardware it will be programmed on. AUTOSAR reduces this constraint by implementing a standardized interface between application software and its hardware to allow for hardware-independent component software. The standardized interface allows application software to communicate by utilizing a Virtual Function Bus (VFB).

Figure1.0- VFB communication with application software

Figure 1.1 shows a very generic view of the AUTOSAR approach. It gives a top view of AUSTOSAR is able to create auto-generating software platforms used to connect components. For example, the platforms used for AUTOSAR development are DaVinci Developer and DaVinci Configurator.

The application scope of AUTOSAR is dedicated to Automotive ECUs. Such ECUs have the following properties:

• strong interaction with hardware (sensors and actuators),
• connection to vehicle networks like CAN, LIN, FlexRay or Ethernet,
• microcontrollers with limited resources of computing power and memory.
• Time-critical System and real-time program execution from internal memory.

NOTE: As per AUTOSAR an ECU consists of one microcontroller plus peripherals and accordingly done software/configuration. AUTOSAR does not cover the mechanical design in the scope.

Overview of Layered Autosar Architecture

The AUTOSAR Architecture distinguishes on the topmost abstraction level between three software layers:

1. Application Layer,
2. Runtime Environment and
3. Basic Software (which run on a Microcontroller)

Figure1.1

1. Application Layer

The application layer is the topmost layer of the AUTOSAR software architecture and supports custom functionalities implementation. This layer consists of the specific software components and many applications, which are a group of interconnected AUTOSAR Software Components and perform specific tasks as per instructions.

Each AUTOSAR Software Component encapsulates part of the functionality of the complete application software. AUTOSAR does not prescribe how large the AUTOSAR Software Components are. Depending on the requirements of the application an AUTOSAR Software Component might be a small, reusable piece of functionality such as lane-keeping assistance, Wiper control, Automatic door unlock, etc.

The communication between software components is enabled via specific ports using a virtual Function Bus. These ports also facilitate communication between software components and AUTOSAR Basic Software (BSW).

Figure1.2

• Client-Server Communication: The above semantics of a client/server communication is that a client may initiate the execution of an operation by a server that supports the operation. The server executes the operation and immediately provides the client with the result (synchronous operation call) or else the client checks for the completion of the operation by itself (asynchronous operation call).
• Sender-Receiver Communication: Sender Receiver Interfaces allow for the specification of the typically asynchronous communication pattern where a sender provides data that is required by one or more receivers. Sender Receiver Interface formally describing what kind of information is sent and received.

2. Runtime Environment (RTE)

The RTE layer provides communication services to the application software for example AUTOSAR Software Components and/or AUTOSAR Sensor/Actuator components.

RTE Layer provides ECU independent interfaces to the application software components. The application layer consists of many SWC which does not follow layered architecture style but component style. The Software Components communicate with other components (inter and/or intra ECU) via the RTE.

SWC Interface is completely independent of ECU. It makes AUTOSAR Software Components independent from the mapping to a specific ECU. Communication between SWCs takes place mainly over two kinds of ports.

• Client/ Server ports where the server is a provider of a service and the client is a user of a service.
• Sender/ Receiver ports where a sender sends information to one or several receivers.

During system development, the SWCs can be integrated with their environment (e.g. hardware, driver, OS, etc)

3. The AUTOSAR Basic Software (BSW) is further divided into three layers:

• Services Layer,
• ECU Abstraction Layer,
• Microcontroller Abstraction and Complex Device Drivers (CDD).

Figure1.3

Each of the three layers consists of different functional groups. Each of these functions may have different modules. To establish a channelized software control, flow- each functional group communicates with a specified software module present in a consecutive layer.

Figure1.4

• Microcontroller Abstraction Layer (MCAL)

The Microcontroller Abstraction Layer is the lowest layer of the Basic Software, this means that MCAL modules can directly access the HW resources. MCAL contains internal drivers which are software modules that are direct access to the µC and internal peripherals.

As the name resembles, the MCAL layer makes the upper layers independent of HW (MCU).

• ECU Abstraction Layer

The ECU Abstraction Layer interfaces the drivers of the Microcontroller Abstraction Layer (MCAL). It also contains drivers for external devices within the ECU and provides an abstraction for various peripheral hardware.

It provides interfaces to access all features of an ECU like communication, memory, or I/O, no matter if these features are part of the microcontroller or served by peripheral components.

• Complex Device Drivers Layer

The Complex Device Drivers (CDD) Layer spans from the hardware layer to the RTE. CDD fulfills special functions and timing requirements needed to operate complex sensors and actuators.

Provide the possibility to integrate special-purpose functionality. This layer consists of drivers for devices that are not specified within AUTOSAR, with very high timing constrains.

• Services Layer

The Services Layer is the topmost layer of the Basic Software (BSW) which also applies its relevance for the application software. It provides an independent Interface of a microcontroller (MCU) and ECU hardware to application software.

The Services Layer offers:

• Operating system functionality
• Vehicle network communication and management services
• Memory services (NVRAM management)
• Diagnostic Services (UDS, Error handling, Memory)
• ECU state management, mode management
• Logical and temporal program flow monitoring (Wdg manager) Task Provide basic services for applications, RTE, and basic software modules.

All the Autosar layers are a group of identified software modules. Each module handles interfaces between adjacent modules.

Detail Description of AUTOSAR COM module

This chapter lists all the features from other modules that are used by the AUTOSAR COM module and functionalities that are provided by the AUTOSAR COM module to other modules. Refer the diagram below for the placement of the AUTOSAR COM module in the communication stack

Figure1.5 View of components

Figure1.6 Sub modules of Autosar COM

Figure1.7 File structure of Autosar COM

The AUTOSAR COM module uses the union of both sets of PDU Router’s upper layer module APIs i.e the APIs for upper layer modules that use TP and the APIs for upper layer modules that do not use TP. This is necessary since the AUTOSAR COM module transports I-PDUs either unfragmented via simple L-PDUs or fragmented via TP.

The following summarizes the functionality of the AUTOSAR COM module needs from the underlying layer PDU Router.

• Indication of incoming I-PDUs
• Sending interface for outgoing I-PDUs including the confirmation if an I-PDU has been sent by the communication controller
• Trigger interface to enable the PDU router to start transmission from the AUTOSAR COM module.
• Buffer handling for TP communication

Layered Software Architecture for Multi-Core Microcontroller

As the demand for computing power consumption is growing higher in the automotive domain, OEMs and Tier-one suppliers are gradually adapting the usage of multicore ECUs in their electronic architectures. Additionally, these multicore ECUs offer new features such as higher levels of parallelism that improve safety requirements implementation such as the functional safety standard ISO26262 and the implementation of other more complex automotive applications. Main use cases for multicore ECUs can be.

1. Decreasing complexity of architecture
2. Dealing with resource-demanding applications
3. Improving safety
4. Dedicated use of cores

AUTOSAR version 4.0 has introduced support for multi-core embedded RTOS. New concepts such as locatable entities (LEs), multi-core start-up/shutdown, Inter-OS-Application Communicator (IOC), introduced in the AUTOSAR 4.0 specification to extend the single-core OS specifications. The Inter-OS-Application Communicator (IOC) which is part of AUTOSAR OS, provides communication services that can be accessed by clients who need to communicate across OS-Application boundaries on the same ECU. Every Core runs an ECU state management and each core also has a 'Core Test' module running in basic software.

The improved Autosar architecture would look like:

Figure1.8 Autosar Multi-Core Architecture

At each stage of software development compliance to AUTOSAR various tools are involved to make sure the interface is generated inline to standard. A brief Autosar development flow is represented with the below flow diagram. Even though this diagram does not cover development flow applicable for all software modules.

Functional Safety:

Safety of a system that depends on the expected operation of specific functions. Functional safety standard ISO26262 is derived from IEC-61508 guide us to have an automotive-specific risk-based approach for the development of Electrical and Electronic (E/E) systems. The goal of functional safety is to perform the intended operation correctly or the system will fail and move to a predictable safe state. Software is one of the parameters that can affect complexity on the system level. The new techniques and concepts for software development can be used in order to minimize complexity and therefore can help to achieve functional safety. AUTOSAR R4.0 considers aspects of functional safety important for Morden automotive software development.

There are many development methods being followed under Autosar to detect and report the functional error at each stage of software development. Even though functional safety is applicable and followed at each stage of whole product development until it comes to the user.

Here is a list of typical sources of interferences, causing errors detected by E2E protection:

SW-related sources:

HW-related sources:

An example of a practical approach followed while developing SWC’s interfaces is providing End-to-End protection to data correctness.

For each RTE Write or Read function that transmits safety-related data (like Rte_Write_<p>_<o>()), there is the corresponding E2E protection wrapper function.

1. The wrapper function invokes AUTOSAR E2E Library.
2. The wrapper function is a part of Software Component and is preferably generated.
3. The wrapper function has the same signature as the corresponding RTE function, just instead of Rte_ there is E2EPW_.
4. The E2EPW_ function is called by Application logic of SW-Cs, and the wrapper does the protection/checks and calls internally the RTE function.
5. For inter-ECU communication, the data elements sent through E2E Protection wrapper are by byte arrays. The byte arrays are copied to COM I-PDUs without any alterations.

Figure1.9 E2E protection for safety compliance

ECU Design and Configuration Methodology

AUTOSAR provides a common technical approach for steps of system development. The figure shows an overview of the design steps to build an ECU with AUTOSAR technology.  That means these steps have to be performed for each ECU in the system.

Figure1.10 Autosar Configuration/Generation Workflow

To be noted AUTOSAR does not prescribe a precise order in which development activities should be carried out. Autosar neither tells about the process nor a business model and “roles” and “responsibilities.

The below diagram is an example of a usually followed workflow. Figure 1.10 and figure 1.11 describe development flow for BSW and Application software respectively.

Figure 1.10.1 Autosar Configuration/Generation Workflow

Figure 1.10.2 Autosar Configuration/Generation Workflow

The major activities in this phase are the extraction of ECU-specific information from the System Configuration Description, the configuration of the ECU, and the generation of the executable ECU software.  The following sections will describe these activities in more detail.

Extract ECU-Specific Information

The tool AUTOSAR ECU Configuration Extractor (ex. System desk, Da-Vinci) extracts the information from the System Configuration Description needed for a specific ECU.  This is a one to one copy of all elements of the System Configuration Description that are mapped to this specific ECU.  The output is the ECU Extract of System Configuration. The network database (ex CAN.dbc) file is the input to produce ECU extract ( .arxml ).

Configure (BSW) ECU

The ECU configuration mainly deals with the configuration of the RTE and the Basic Software modules. The configuration is based on the parameters that are available in the ECU Extract of System Configuration. Collection of Available SWC Implementations, and BSW Module Description. BSW also contains the Vendor-Specific ECU Configuration. This is necessary because the output ECU Configuration Description has a flexible structure that does not define a fixed number of configuration parameters while ECU extract.

The communication module, MCAL, the operating system, or AUTOSAR services have to be defined during BSW configuration.

Generate Executable

After the ECU configuration is done, a software source for several modules of the ECU can be generated.  This refers to the Basic Software (e.g. communication module, operating system, etc.), and the RTE.

The configuration, source code generation and generate executable ECU code resemble today's development practice. This is mainly a linking of all components.  There are additional steps involved.  E.g. information from the ECU Configuration Description might be used to generate specially configured executable software.

SW-Component Implementation

The initial work of SWC starts with providing the necessary parts of the software component description [SWCTempl].  That is Component Internal Behaviour Description as part of the software component related templates.  The internal behaviour describes the scheduling relevant aspects of a component, i.e. the runnable entities and the events they respond to.  Furthermore, the behaviour specifies how a component (or more precisely which runnable) responds to events like received data elements.  However, it does not describe the detailed functional behaviour of the component

Further reading

• Enabling SAE L3-L5 Autonomy with Sensor Fusion: Approaches and Challenges
• Safety Concept for Automated Driving
• Guide to Porting Real-time Traffic Sign Recognition Algorithm on Texas Instruments TDA2x SoC