Multi-core Ecu Designing Using Autosar by Deependra Magarde

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 � 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 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 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

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

Intra- and Inter-ECU communication

DEEPENDRA MAGARDE

AUTOSAR WORKFLOW

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.• 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

� 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.


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

� 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


• 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.

o 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 modekind 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 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 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.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.comwww.mentor.com

www.dspace.com

www.electrobit.com

DEEPENDRA MAGARDE

THANKS FOR YOUR PATIENCETHANKS FOR YOUR PATIENCE

DEEPENDRA MAGARDE

Multi-core Ecu Designing Using Autosar by Deependra Magarde

Documents

Transcript of Multi-core Ecu Designing Using Autosar by Deependra Magarde