Multi-core ECU Design using AUTOSAR

BY DEEPENDRA MAGARDE

DEEPENDRA MAGARDE

AUTOSAR layer is divided into three levels

DEEPENDRA MAGARDE

AUTOSAR Basic Software Layers

The Application layer is on the top of this architecture. Software Components, which provide the specific functions like controlling actors or monitoring sensors, take place in this Application layer AUTOSAR Software Components (SWC) are also called atomic Software Component, because they cannot distributed over several ECUs The Basic Software layer (BSW) is located directly on the ECU. It contains all ECU specific components and provides services to software on higher levels example the operating system, network management or memory management. Complex Device Driver works directly on the ECUs Hardware and communicates only to the Runtime Environment and not to other components on the BSW. Hardware, which is not supported by AUTOSAR, can be integrated by an implementation of a Complex Device Driver. By using the Complex Device Driver it is possible to migrate already existing non-AUTOSAR specified applications.
DEEPENDRA MAGARDE

AUTOSAR Basic Software Layers

The Runtime Environment (RTE) is a concretion of the Virtual Function Bus (VFB). The VFB is a middleware concept to abstract the communication relations between the several components. The virtual connections between the components are mapped by the RTE on system resources or on network mechanisms. All software components communicate only over the RTE.

DEEPENDRA MAGARDE

Architecture Introduction to Basic Software Modules

Driver contains the functionality to control and access an internal or an external device. internal driver and is located in the Microcontroller Abstraction Layer. external driver and is located in the ECU Abstraction Layer. Interface contains the functionality to abstract from modules which are architecturally placed below them. interfaces are located in the ECU Abstraction Layer. Handler is a specific interface which controls the concurrent, multiple and asynchronous access of one or multiple clients to one or more drivers Manager offers specific services for multiple clients. It is needed in all cases where pure handler functionality is not enough to abstract from multiple clients managers are located in the Services Layer

DEEPENDRA MAGARDE

RUNNABLE ENTITY
Runnable Entity (RE) is defined as an executable code sequence.
All Runable Entities can be executed by the RTE directly. Only in some special cases of optimization the Runnable Entity is started by another software component directly. Any atomic Software Component is buildup of one or several Runnable Entities. The AUTOSAR specification divides Runnable Entities in three categories . Runnables, which have only implicit data access and cannot block data access. Runnables, which have additionally explicit rights to read and write data directly, but cannot block this access. Runnables, which have implicit and explicit data access and can block additional data access The RTE maps the Runnable Entities to TASKs. This mapping has to be described in the ECU Configuration Description and is a part of the input of the RTE Generator.

DEEPENDRA MAGARDE

Communication among Runnable Entities

Runnable Entities have to share data among each other AUTOSAR provides four different possibilities

o Semaphores The operating system provides mutual exclusion by semaphores to

protect the access to shared resources.

o Interrupt Disabling While using single core systems interrupt disabling can prevent
simultaneously access to shared memory

o Priority Ceiling Protocol Runnable Entity has a static priority. This priority defines
the importance of the Runnable Entity for the whole system. Runnable Entity also has a dynamic priority. The dynamic priority is definedby the maximum of the own static priority and the priorities of all blocked runnable entities. Resource has a static ceiling value. This value is defined by the maximum priority of all Runnable Entities which use this resource. A Runnable Entity can only lock a resource if its dynamic priority is higher than the ceiling value of each currently locked resource.
DEEPENDRA MAGARDE

DEEPENDRA MAGARDE

DEEPENDRA MAGARDE

DEEPENDRA MAGARDE

DEEPENDRA MAGARDE

DEEPENDRA MAGARDE

DEEPENDRA MAGARDE

DEEPENDRA MAGARDE

DEEPENDRA MAGARDE

DEEPENDRA MAGARDE

DEEPENDRA MAGARDE

DEEPENDRA MAGARDE

DEEPENDRA MAGARDE

DEEPENDRA MAGARDE

DEEPENDRA MAGARDE

DEEPENDRA MAGARDE

DEEPENDRA MAGARDE

DEEPENDRA MAGARDE

DEEPENDRA MAGARDE

DEEPENDRA MAGARDE

AUTOSAR Ports
Port belongs to exactly one AUTOSAR Software Component and represents a point of interaction of that component. Interface that is encapsulated by a port is provided by a module of the AUTOSAR Service layer, it has to be a Standardized AUTOSAR Interface AUTOSAR Interfaces as well as an Standardized AUTOSAR Interfaces can be one of three kinds. Client-Server interface: Blocking and Non Blocking , the client awaits a response from the server. Sender-Receiver interface: All calls are non-blocking calls and the client will never get a response. Configuration interface: Interface enables a AUTOSAR Software Component to receive values for configuration parameters.

DEEPENDRA MAGARDE

DEEPENDRA MAGARDE

DEEPENDRA MAGARDE

Intra- and Inter-ECU communication

DEEPENDRA MAGARDE

AUTOSAR WORKFLOW

DEEPENDRA MAGARDE

DEEPENDRA MAGARDE

DEEPENDRA MAGARDE

DEEPENDRA MAGARDE

DEEPENDRA MAGARDE

DEEPENDRA MAGARDE

DEEPENDRA MAGARDE

DEEPENDRA MAGARDE

DEEPENDRA MAGARDE

Multi-Core-ECUs in AUTOSAR 4.0

Hardware requirements AUTOSAR supports only symmetric multi core processors. Each core has to have the same instruction set and the same representation of data. The Hardware has to provide a function to identify each core by the software. Hardware-implemented test-and set-function has to be provided. The atomic test-and-set-function is necessary to guarantee a proper working spinlock mechanism. To realize the test-and-set-function the processor needs a Dual-Port-RAM. There has to be shared RAM implemented on the hardware accessible from each core. If no shared RAM is implemented, each core has to share a part of the private memory. It is not possible to start cores after the operating system has started. The tasks have to be scheduling static to a core. So it has to be done at compile-time. Dynamic inter-core scheduling is not supported

DEEPENDRA MAGARDE

Multi-Core-ECUs in AUTOSAR 4.0

Operating System The Multi-Core OS in AUTOSAR is not a virtual ECU concept, instead it shall be understood as an OS that shares the same configuration and most of the code, but operates on different data structures for each core The AUTOSAR-Operating System based on the OSEK/VDX6 operating system One main core will be defined. The whole relevant basis software is running on this main core. An operating system entity and Complex Device Drivers are running on every single core. To support the inter-core communication the operating system implements an Inter-OS-Application Communicator(IOC). The IOC provides buffered and unbuffered sender-receiver-communication by using shared memory. No inter-core scheduling tasks with high priorities and tasks with low priorities can be executed at the same time on different cores.

DEEPENDRA MAGARDE

Multi-Core-ECUs in AUTOSAR 4.0

Locatable entities A Locatable entity integrate software components, which have to be executed on the same core. Mutual exclusion AUTOSAR 4.0 operating system specification knows the concept of spinlocks Thread or a Task asks for a Boolean lock, to enter a critical section. Is the lock held by another Task, so the Boolean variable is set to true. The asking Task has to wait. At the same time the thread asks continuously for the lock (polling) and keeps active. This mechanism is called busy waiting. Deadlocks Spinlocks are not deadlock-free by itself. AUTOSAR 4.0 specification prohibits nested spinlocks. If nested spinlocks are needed, a unique order has to be defined in the configuration description.
DEEPENDRA MAGARDE

Three use cases for multi-core ECUs in the automotive sector

Multi core ECUs have good conditions of comporting high performance functions of running safety New high performance safety or comfort features need to be implemented on multi core systems Many safety critical functions have to be calculated redundant on multiple processors All processors perform exactly the same instructions The name of this kind of system operation is lock step mode

DEEPENDRA MAGARDE

Simple multi-core system

The simplest embedded microprocessor has a CPU, RAM, flash and peripherals all connected via a single bus The basic idea behind multi-core is that the CPU is replicated. At its simplest this implies that the RAM, flash, peripherals and bus are not replicated and that the extra CPUs connect to the same bus Replicating the CPU implies that they all have the same instruction set. This is very important because it means that the CPUs can share code and data and, therefore, better optimize memory consumption.

DEEPENDRA MAGARDE

Network of SWCs mapped to dual-core system

Key to exploiting multi-core is the decomposition of the application tasks and interrupt handlers into smaller components that communicate with each other These components are then distributed onto the available computing resources AUTOSAR approaches to automotive ECU software development are based upon the idea of static (i.e. compile-time) configuration. Changing the configuration of the system whilst it is running is too complex and expensive. So the distribution of workload to cores is static and this implies that the communications matrix between the cores is also static.
DEEPENDRA MAGARDE

Multi-core inter-task communication

Sending a message between tasks on different cores might therefore entail: 1. Sender task updates application shared data 2. Sender task activates receiver task on other core a. Enter the OS b. Lock data structures shared with other core c. Activate task d. Unlock data structures e. Initiate interrupt on other code to force scheduling point 3. Receiver task reads application shared data

DEEPENDRA MAGARDE

Multi-core AUTOSAR architecture

All the BSW modules run on one core only. The main exception to this is the OS that must support, for example, cross-core task activations. All cores can see the same RAM, flash and peripherals via a single uniform address space. There will be a single instance of the RTE and OS. Each is effectively shared between all of the cores. A new module, called the IOC, is used to communicate between the parts of the RTE on each core

DEEPENDRA MAGARDE

Data flow in multi-core AUTOSAR tools

RTE The C code generated by the RTE generator uses the IOC and cross-core tasks activation and event setting. Also, the XML required to configure the IOC is generated. OS The AUTOSAR OS product has been adapted to support the complete SC1 multi-core API. Also, an IOC generator has been added that supports the same modes as the RTE

DEEPENDRA MAGARDE

Reference
www.autosar.org www.etas.com www.ieeexplore.org www.mentor.com www.dspace.com www.electrobit.com

DEEPENDRA MAGARDE

THANKS FOR YOUR PATIENCE

DEEPENDRA MAGARDE