Post on 03-Jun-2018
transcript
8/12/2019 Autosar Scheduling Automotive Embedded - Copy
http://slidepdf.com/reader/full/autosar-scheduling-automotive-embedded-copy 1/37
Model Engineering College Scheduling Complex Automotive Embedded Real Time Sytems
Departmenent of Electronicѕ Engineering 3
Chapter 2
AUTOMOTIVE ELECTRONIC CONTTROL UNITS (ECUѕ)
2.1 ECUѕ in Automobiles
The number of ECUs in automobiles have increased rapidly in the last decade.
Thiѕ rapid growth is due to consumer demand for enhanced safety features, entertainment
systems, added convenience functions and government edicts on emissions controls. .
The software interfaceѕ in a typical Automotive Electonic Control unit iѕ ѕhown
in Figure 2.1.
.
F ig 2.1: Software interfaces inside ECU [8]
It conѕiѕtѕ of
a) Operating ѕyѕtem
b)Application ѕoftware moduleѕ
c)Input/Output ѕyѕtemѕ
d)Microcontroller
2.2 Operating System
Automotive applications are characterized by stringent real-time requirements.
Therefore the operating system offers the necessary functionality to support event driven
control systems.
8/12/2019 Autosar Scheduling Automotive Embedded - Copy
http://slidepdf.com/reader/full/autosar-scheduling-automotive-embedded-copy 2/37
Model Engineering College Scheduling Complex Automotive Embedded Real Time Sytems
Departmenent of Electronicѕ Engineering 4
As the operating system is intended for use in any type of control units, it shall
support time-critical applications on a wide range of hardware. A high degree of modularity
and ability for flexible configuration are prerequisites to make the operating system suitable
for low-end microprocessors and complex control units alike.
The OSEK operating system is a single processor operating system meant for
distributed embedded control units for automotive applications.
OSEK is an abbreviation for the German term "Offene Systeme und deren
Schnittstellen für die Elektronik im Kraftfahrzeug" (English: Open Systems and the
Corresponding Interfaces for Automotive Electronics)
The OSEK operating system is designed to require only a minimum of hardware
resources (RAM, ROM, CPU time) and therefore runs even on 8 bit microcontrollers.
2.3Application software module
The specified operating system services constitute a basis to enable the integration of
software modules made by various manufacturers.
The interface between the application software and the operating system is defined by
system services. The interface is identical for all implementations of the operating system on
various processor families.
Operating Syѕtem must support the portability of application software. Portability
means the ability to transfer an application software module from one ECU to another ECU
without bigger changes inside the application.
During the process to port application software from one ECU to another ECU it is
necessary to consider characteristics of the software development process, the development
environment, and the hardware architecture of the ECU, for example
a)Software development guidelines b) File management system
c)Data allocation and stack usage of the compiler
d)Memory architecture of the ECU
e) Timing behaviour of the ECU
8/12/2019 Autosar Scheduling Automotive Embedded - Copy
http://slidepdf.com/reader/full/autosar-scheduling-automotive-embedded-copy 3/37
Model Engineering College Scheduling Complex Automotive Embedded Real Time Sytems
Departmenent of Electronicѕ Engineering 5
f)Different microcontroller specific interfaces e.g. ports, A/D converter, serial
communication and watchdog timer
g)Placement of the API calls
The application software lies on the operating system and in parallel on an
application-specific Input/Output System interface which is not standardised in the OSEK
specification. The application software module can have several interfaces. There are
interfaces to the operating system for real time control and resource management, but also
interfaces to other software modules to represent a complete functionality in a system and at
least to the hardware, if the application is intended work directly with microcontroller
modules.
2.4 Input/Output ѕyѕtemѕ
Input/Output ѕyѕtemѕ enables the ECU to communicate with the external world.
The application software provides application-specific Input/Output System interface.
2.5 Microcontroller
The automotive markets for electronics is growing rapidly as the demand for
comfort, safety and reduced fuel consumption increases. All of these new functions
require local intelligence and control, which can be optimized by the use of small,
powerful microcontrollers.
In order to deal with the new range of system requirements, the automotive
microcontroller will be further developed to facilitate new functions.
2.5.1Communications
Communications between electronic control units (ECU's) is a growing trend.Multiplexed communications in vehicles was originally developed to reduce weight,
interconnections, cost and complexity. It soon became apparent however that vehicular
systems could be enhanced greatly with the opportunity to share data from different
ECUs, in real time.
8/12/2019 Autosar Scheduling Automotive Embedded - Copy
http://slidepdf.com/reader/full/autosar-scheduling-automotive-embedded-copy 4/37
Model Engineering College Scheduling Complex Automotive Embedded Real Time Sytems
Departmenent of Electronicѕ Engineering 6
Many new automotive microcontrollers will have more silicon devoted to
communications capabilities than the CPU. Already, microcontrollers such as the
M68HC912DG128 are being offered with two independent CAN (Controller Area
Network) modules along with several more synchronous and asynchronous
communications systems. These communications interfaces are as autonomous as
possible, so that the CPU does not need to devote a great deal of overhead to managing
communications.
2.5.2 Safety critical operation
Microcontrollers have been at the heart of safety critical systems for many years.
Almost all of the safety critical automotive systems in which they have been used have
provided a fail-safe function. In the near future, there will be an added requirement for
fault-tolerant microcontroller based systems.
The best example of a modern automotive microcontroller is the MPC555, which
was designed for powertrain control and Intelligent Transportation Systems (ITS)
applications. A block diagram of the MPC555 is shown in Figure 2.2
F igure2.2: MPC555 M icrocontroller [3]
The MPC555 is based on the PowerPC architecture and is composed of over 6.7
million transistors, over 300 times the complexity of a microcontroller used in a
8/12/2019 Autosar Scheduling Automotive Embedded - Copy
http://slidepdf.com/reader/full/autosar-scheduling-automotive-embedded-copy 5/37
Model Engineering College Scheduling Complex Automotive Embedded Real Time Sytems
Departmenent of Electronicѕ Engineering 7
comparable application a decade ago. The 32-Bit CPU includes multiple execution units
and a floating point unit as well as supporting a Harvard architecture with separate load /
store and instruction busses for simultaneous instruction fetching and data handling.
The chip is well equipped with peripherals to interface with the rest of the system.
There are 32 analogue inputs as well as 48 Timer Processor Unit (TPU) timer controlled
input/output channels. Two CAN (Controller Area Network) serial communications
interfaces are also included to provide multiplexed communications with other vehicular
systems. The program memory is 448 Kbytes of Flash EEPROM with 26 Kbytes of RAM.
Certain i/o structures have been added to the chip to accommodate 5v signals around the
chip. Although the MPC555 has been developed for a 0.35 um manufacturing process, it
is expected that the technology of other system components will develop more slowly
and will still operate with a 5v power supply and signaling level.
The next major challenge for microcontroller based automotive systems will be to
optimize the efficiency of the controller and associated software by model-based
development techniques, open architectures and reusability of hardware/software.
Meeting these challenges will ensure that the perennial requirements of the industry are
met: reduce cost, increase performance and reduce time to market.
8/12/2019 Autosar Scheduling Automotive Embedded - Copy
http://slidepdf.com/reader/full/autosar-scheduling-automotive-embedded-copy 6/37
Model Engineering College Scheduling Complex Automotive Embedded Real Time Sytems
Departmenent of Electronicѕ Engineering 8
Chapter 3
RESPONSE TIME ANALYSIS
3.1 Computational model
The real-time system analyzed in this section consists of a set of asynchronous
tasks i €T . A set of tasks is called asynchronous if the first activation of a task may be
different from the system start time to= 0, and synchronous if all tasks are activated at to.
. In the real-time domain tasks are described using their worst-case non-functional
properties. In our case these properties include the worst-case computational workload C,
the task priority P , the activation period A, and the offset O of the first task activation
w.r.t. t0 . Hence, the task i is described by a 4-tuple i = (Ci, Pi, Ai, Oi) €T
Table 3.1 summarizes the important variables used in the following equations.
Table 3.1 Variables of the computational model[1]
8/12/2019 Autosar Scheduling Automotive Embedded - Copy
http://slidepdf.com/reader/full/autosar-scheduling-automotive-embedded-copy 7/37
Model Engineering College Scheduling Complex Automotive Embedded Real Time Sytems
Departmenent of Electronicѕ Engineering 9
Tasks are grouped into transactions. A transaction j € R with activation period Tj
contains all tasks that have the same activation period as the transaction,
3.2 Analysis using offset information
The response time of a task can be calculated taking into account the properties of
the task itself and the properties of all higher priority tasks which may be pre-empted
over the task under analysis. The central concept to do such an analysis taking into
account task offsets is by deriving so-called busy windows . A busy window is a period
of time in which a processor is not idle at any time. Clearly, with pre-emptive scheduling
the task with the lowest priority is always finished at the end of a busy period. The
critical instant is the point in time that precedes the busy window(w) resulting in the
longest response time for the analyzed task.
Consider the example schedule in figure 3.1 consisting of seven tasks in three
transactions.
F ig. 3.1. Computational model of the response-time analysis[1]
The following priorities are valid P4 > Pi > P5 > P6 > P2 > P3 > P7 for the respective
tasks.
8/12/2019 Autosar Scheduling Automotive Embedded - Copy
http://slidepdf.com/reader/full/autosar-scheduling-automotive-embedded-copy 8/37
Model Engineering College Scheduling Complex Automotive Embedded Real Time Sytems
Departmenent of Electronicѕ Engineering 10
The critical instant for Task6 is the instant when the higher priority tasks Task1 and
Task4 are activated at the same time as Task6. To describe this situation a vector W is
defined that captures the time Wj the transaction j was started before the critical instant.
The vector W describes the critical instant candidates an analysis context.
To calculate the interference of a higher priority task k on the computation of a
low priority task i without offsets the equation 3.1 can be used.
………………………….. (3.1)
3.3 Hyper period ( )
Given the hyper-period = lcm(To,T1···, T|R|-1 ) the number of activation
instances of transaction k is exactly . After H the activation schemes are repeated.
Figure 3.2 illustrates the hyper-period and activation instances of a task-set consisting of
three transactions.
F ig. 3.2: Possible transaction activation instances over the hyper -peri od [1]
An easy way to create the analysis contexts accordingly is to iterate over thehyper-period and consider each task activation a critical instant candidate, i.e. analysis
context(Wj). This procedure is sketched in algorithm 3.1
8/12/2019 Autosar Scheduling Automotive Embedded - Copy
http://slidepdf.com/reader/full/autosar-scheduling-automotive-embedded-copy 9/37
Model Engineering College Scheduling Complex Automotive Embedded Real Time Sytems
Departmenent of Electronicѕ Engineering 11
Algori thm 3.1 :Create analysis Context[1]
The procedure iterates over all task activation instants and captures the analysis
context of each respective instant. The size of the returned analysis context set is equals
to the number of task activations during the hyper-period. In order to finding the critical
instant we have to investigate all task activation points. The analysis context that results
in the longest response-time for the task under analysis describes the critical instant.
3.4 Response time analysis for multiple clock reference systems
In the previous section the WCRT analysis for systems consisting of one global
clock reference that triggers all transactions is investigated.In this section the analysis of
systems that consists of multiple clock references will be analyzed. The original
computational model lacks the information required to determine the clock reference of
each transaction. The computational model is refined to capture this additional
information.
3.4.1 Extended Computational Model
The system model introduced in section 2. defines one global clock that triggers
all transactions. The single clock reference is replaced by a set of clock references C,
hence, S = (T,R,C)
8/12/2019 Autosar Scheduling Automotive Embedded - Copy
http://slidepdf.com/reader/full/autosar-scheduling-automotive-embedded-copy 10/37
Model Engineering College Scheduling Complex Automotive Embedded Real Time Sytems
Departmenent of Electronicѕ Engineering 12
3.4.2 Multiple Time Reference
With the refined computational model the existing RTA for single clock reference
systems can be extended to account for multiple clock references. The critical instant had
to be calculated. Unlike in the single clock reference scenario triggered by different clock
references are treated different to transactions triggered by the same clock reference.
Consider figure 3.3. Transactions 0,1, and 2 are triggered by the same clock
reference and transaction 3 and 4 are triggered by a different clock reference.The same is
true for transactions 3 and 4.
F ig3.3: H yper-periods with phase offset [1]
Unlike in the single clock reference system tasks which are triggered by different
clock references are subject to clock drift. The clock drift of the transaction triggers
results in a constantly changing phase offset between the transactions from different
clock references.
Transactions for different clock references may be triggered at arbitrary points in
time. For the analysis context generation this means assuming any task activation in a
transaction has no effects on possible task activations in transactions with different clock
reference. The analysis contexts for each transaction set which belong to the same clock
reference are created using the procedure in the previous section. After the analysis
contexts for each single clock transaction set have been created, we have to merge them
8/12/2019 Autosar Scheduling Automotive Embedded - Copy
http://slidepdf.com/reader/full/autosar-scheduling-automotive-embedded-copy 11/37
Model Engineering College Scheduling Complex Automotive Embedded Real Time Sytems
Departmenent of Electronicѕ Engineering 13
into one joint set of analysis contexts. To do so, we consider each single clock
transaction set are considerded one transaction with period equals to the hyper-period of
the transaction set. We then combine all such transactions to create the analysis context
set of the multiple clock reference problems. The procedure that combines the two
separately created sets of analysis contexts is summarized in algorithm 3.2.
Algori thm 3.2 Merge Analysis Contexts [1]
To investigate the critical instant all possible task activation combinations have to
be conѕidered. This increases the workload significantly, but it is necessary as combining
the critical instant of set 1 and the critical instant of set 2 may not result in the overall
critical instant. Algorithm 3.2 iterates over all analysis contexts of set 1 and combines it
with all analysis contexts of set 2. In other words, each instant when a task activation in
set 1 occurred is considered.At the same time as a task activation in set 2, for all
combinations of task activations. The resulting set of analysis contexts is merged with
the remaining sets until one joint set of analysis contexts is left.
The proposed procedure increases the computational complexity of the RTA
because all entries in the analysis context set have to be evaluated. In real-world
scenarios the RTA is feasible if the number of different clock references is small.
8/12/2019 Autosar Scheduling Automotive Embedded - Copy
http://slidepdf.com/reader/full/autosar-scheduling-automotive-embedded-copy 12/37
Model Engineering College Scheduling Complex Automotive Embedded Real Time Sytems
Departmenent of Electronicѕ Engineering 14
Chapter 4
SYSTEM ANALYSIS
4.1 Simulation Model
The key model elements in a holistic schedule simulation are the tasks, the
operating system, signal source, signal sinks,and the communication between element
nodes. The important parameters to capture the timing effects of a task are: The execution
time, activation period, priority, activation offset, and pre-emption by higher priority
tasks. In order to check for deadline violations during the simulation the deadline needs
to be known as well. The operating system hosts a vector of real-time tasks as well as a
vector of interrupts which are modeled similar to the tasks. The operating system periodically evaluates the currently running task and runs the dispatcher if new tasks have
been activated. Interrupts may occur any time and also invoke the dispatcher. The
implementation of the operating system model is illustrated in figure 4.1.
F ig 4.1 I ll ustration of the operati ng system simulati on model[4]
Note that the task execution and the operating system are subject to clock drift
which is modeled in the controller the operating system resides in.
8/12/2019 Autosar Scheduling Automotive Embedded - Copy
http://slidepdf.com/reader/full/autosar-scheduling-automotive-embedded-copy 13/37
Model Engineering College Scheduling Complex Automotive Embedded Real Time Sytems
Departmenent of Electronicѕ Engineering 15
Figure 4.2 llustrates the task scheduling aspect of the scheduling simulation.
F ig. 4.2 I ll ustration of the task simulation model[4]
Task states are described by a state machine consisting of a running, suspended,
and waiting state. Each time step the operating system updates the workload parameter
of the task that has been running the last time step and evaluates activation times of thesuspended tasks. If new tasks have been activated the dispatched assigns the CPU to the
highest priority task, hence, the respective task enters the running state. At a time only
one task may be running.
Task states are described by a state machine consisting of a running,suspended,
and waiting state. Each time step the operating system updates the workload parameter of
the task that has been running the last time step and evaluates activation times of the
suspended tasks. If new tasks have been activated the dispatched assigns the CPU to the
highest priority task, hence the respective task enters the running state. At a time only one
task may be running.
4.2 Automotive Safety Architecture
Bas_running
Bas_suspended
Bas_suspendedBasic_OSEKTaskBehaviour
8/12/2019 Autosar Scheduling Automotive Embedded - Copy
http://slidepdf.com/reader/full/autosar-scheduling-automotive-embedded-copy 14/37
Model Engineering College Scheduling Complex Automotive Embedded Real Time Sytems
Departmenent of Electronicѕ Engineering 16
F ig. 4.3 System archi tectur e example from the automotive safety domain[1]
The safety architecture in figure 4.3 consists of an integrated safety ECU whichreceives input from different sources. A forward looking sensor device perceives the
current driving scene and triggers active safety applications and pedestrian protection via
an event-triggered bus. A time-triggered task is triggered at a specific instant when the
time-triggered bus is in a specific state. The communication via the time-triggered bus is
also triggered by the clock of the bus. An external watchdog participates in a
challenge/response mechanism.
In the safety ECU a sanity check is performed upon this request. Moreover, a
traditional legacy subsystem for airbag deployment is triggered periodically by its
respective sensor ICs.
The legacy subsystem consists of a number of periodic tasks responsible for the
generation of features from the sensor data upon which a decision is made regarding
whether or not the airbag needs to be deployed. Also the basic diagnosis functionality is
implemented in the legacy subsystem. The active and pedestrian safety applications and
the ECU sanity check are triggered event-based with a certain Minimum Inter arrival
Time (MINT). The time-triggered tasks are activated periodically but the activation period
is subject to drift, as the ECU and the time-triggered bus do not share the same global
clock.
8/12/2019 Autosar Scheduling Automotive Embedded - Copy
http://slidepdf.com/reader/full/autosar-scheduling-automotive-embedded-copy 15/37
Model Engineering College Scheduling Complex Automotive Embedded Real Time Sytems
Departmenent of Electronicѕ Engineering 17
All tasks of the embedded software system and their respective real-time
properties are summarized in table 4.1
T:Period, P ;Priority, O: Offset, C: Execution time
Table 4.1 Real-time properties of the tasks in the safety system [1]
4.3.Timing AnalysisThe system in fig 4.3 is analyzed using simulation model presented in section 4.1
using statistical modeling and simulation is feasible in clock drifts between elements have
to be considered. However,investigating the worst-case timing using statistical simulation
is difficult because very long simulation durations would be neccessary. On the other
hand, the simulation provides knowledge about mean response times and average
controller load.
The simulation is performed repeatedly until a predefined confidence threshold is
reached. Between each simlation replication the clock drifts and initial transaction phase
is evaluated statistically and changed. By doing so we create random samples of the mean
and max response times of all tasks.
8/12/2019 Autosar Scheduling Automotive Embedded - Copy
http://slidepdf.com/reader/full/autosar-scheduling-automotive-embedded-copy 16/37
Model Engineering College Scheduling Complex Automotive Embedded Real Time Sytems
Departmenent of Electronicѕ Engineering 18
Using the samples from each replication we create the box plots of the mean task
response times depicted in figure 4.4
F ig 4.4 Mean task response times over mul tipl e simu lati on repli cations [1]
The top and the bottom of the box which contains the thick horizontal bar
represent the 75% quartile and the 25% quartile,i.e. the latency bound which 75%-25% of
the replication instances did not exceed. The thicker line inside of the box presents the
median of the values. The whiskers with the bars at the end of the line represent the data point that exceed the quartiles, but are limited to 1.5 x IQR, IQR being the interquartile
range. Outlier are represented by circles.
The confidence factor of the mean task response times was set to accept a relative
error of 5% with the probability of 95%.
8/12/2019 Autosar Scheduling Automotive Embedded - Copy
http://slidepdf.com/reader/full/autosar-scheduling-automotive-embedded-copy 17/37
Model Engineering College Scheduling Complex Automotive Embedded Real Time Sytems
Departmenent of Electronicѕ Engineering 19
Over all simulation replications the simulated WCRT of all tasks is depicted in
figure 4.5
F ig.4.5 Maximum simulated task response times and calcul ated WCRT[1]
The WCRTs of the tasks is not constant over all replications but depend on the actual
selection of clock drift and phase offset. The crosses in figure 4.5 represent the calculated
WCRTs using the RTA presented in section 3. Two important findings can be observed
in the figure:
a) Even through extensive simulation the maximum response time from the simulation .
b) The maximum response time in the simulation does not exceed the calculated WCRT.
Thiѕ RTA provides important information regarding the worst-case behavior of
the system by providing upper bounds of the WCRT of all real-time tasks. Especially for
the lower priority tasks the gap between WCRT and maximum response time during the
simulation runs can be significant. Thiѕ analysis is applicable in automotive systems withrelatively short schedule lengths, or hyper-periods, and limited number of different clock
references.
8/12/2019 Autosar Scheduling Automotive Embedded - Copy
http://slidepdf.com/reader/full/autosar-scheduling-automotive-embedded-copy 18/37
Model Engineering College Scheduling Complex Automotive Embedded Real Time Sytems
Departmenent of Electronicѕ Engineering 20
Chapter 5
MULTICORE SCHEDULING IN AUTOMOTIVE ECUS
5.1 IntroductionMulti-source software running on the same ECU (Electronic Control Unit) is
becoming increasingly widespread in the automotive industry. One of the main reason
being that OEMs want to reduce the number of ECUs which grew up above 70 for high-
end cars.
These multicore ECUs offer new features such as higher levels of parallelism
which eases the respect of the safety requirements introduced by the ISO 26262 and can
be taken advantage of in various other automotive use-cases.
Multicore ECU s rises the problem of scheduling numerous elementary software
components (called runnables) on a limited set of identical cores.In the context of an
automotive design, we assume the use of the static task partitioning scheme which
provides simplicity and better predictability for the ECU designers by comparison with a
global scheduling approach.
The global scheduling problem can be addressed as two subproblems: partitioning
the set of runnables and building the schedule on each core.
5.2 Main use cases for multicore ECU in the automotive domain
There exist very distinct hardware and software architectures for multicore ECU
platforms. As far as hardware is concerned, suppliers envision various multicore
architectures: identical cores, heterogeneous cores with different operating speeds and
instruction sets and, possibly, various I/O and memory structures. However, chip
manufacturers have been producing multiprocessor cores with identical cores for the PC
industry for a while which may influence the automotive industry as those architectures
are proven in use and are likely to be cheaper thanks to mass production. In this section,
we discuss the main use cases for a multicore ECU and implementation solutions that
would properly fit them.
8/12/2019 Autosar Scheduling Automotive Embedded - Copy
http://slidepdf.com/reader/full/autosar-scheduling-automotive-embedded-copy 19/37
Model Engineering College Scheduling Complex Automotive Embedded Real Time Sytems
Departmenent of Electronicѕ Engineering 21
5.2.1 Decreasing the complexity of in-vehicle architecture
The higher level of performance provided by multicore architectures allows to
simplify in-vehicle architectures by executing on multiple cores the software previously
run on multiple ECUs.
5.2.2 Improving the safety
Multicore architectures provide efficient ways to implement safety mechanisms.
We identify three main methods to improve safety taking advantage of the multicore
architecture.
The first method consists in segregating trusted code and non trusted code on
different cores. For instance, a car manufacturer may consider the software provided by
suppliers as non-trusted code, or an ECU integrator may consider the car manufacturer’s
code as non-trusted for responsibility reasons.
The second method consists in executing safety critical software components in a
redundant manner, possibly with a system of vote choosing the output given by a
majority of the duplicated runnables.
Finally multicore architectures enable easier implementation of function
monitoring. In this case, the proper execution of some functions on one core can be
monitored from another core.
5.2.3 Dedicated use of cores
Finally, another important use case taking advantage of a multicore ECU consists
in using a core to handle specific low-level services. In the context of Autosar OS, a core
could serve as a dedicated I/O controller, execute the communication stack or the whole
set of basic software modules, while some other core would only take care of applicative
level software components. For instance, a core can be used to run the time-triggered
application while a second core handles the interruptions as well as the event-triggered
runnables
8/12/2019 Autosar Scheduling Automotive Embedded - Copy
http://slidepdf.com/reader/full/autosar-scheduling-automotive-embedded-copy 20/37
Model Engineering College Scheduling Complex Automotive Embedded Real Time Sytems
Departmenent of Electronicѕ Engineering 22
Chapter 6
PARTITIONED SCHEDULING OF TASK ON
AUTOSAR OS
6.1 AUTOSAR OS
AUTOSAR (Automotive Open System ARchitecture) is an open and standardized
automotive software architecture, jointly developed by automobile manufacturers,
suppliers and tool developers.
Software platform structure of AUTOSAR OS is shown in fig.6.1
F ig 6.1:Software platform structur e o AUTOSAR OS[8]
6.2 AUTOSAR Basic Software
Basic Software is the standardized software layer, which provides services to the
AUTOSAR Software Components and is necessary to run the functional part of the
software. It does not fulfill any functional job itself and is situated below the AUTOSAR
Runtime Environment.
The Basic Software contains standardized and ECU specific components. The
earlier include:
8/12/2019 Autosar Scheduling Automotive Embedded - Copy
http://slidepdf.com/reader/full/autosar-scheduling-automotive-embedded-copy 21/37
Model Engineering College Scheduling Complex Automotive Embedded Real Time Sytems
Departmenent of Electronicѕ Engineering 23
6.2.1Services
System services such as diagnostic protocols; NVRAM, flash and memory
management.
6.2.2CommunicationCommunication Framework (e.g. CAN, LIN, FlexRay...), I/O management,
Network management.
6.3 Operating System
As AUTOSAR aims at an architecture that is common for all vehicle domains it will
specify the requirements for an AUTOSAR Operating System.
Here are the basic features of the AUTOSAR OS
a)is configured and scaled statically
b) is amenable to reasoning of real-time performance
c) provides a priority-based scheduling policy
d)provides protective functions (memory, timing etc.) at run-time
e)is hostable on low-end controllers and without external resources
This feature set defines the type of OS commonly used in the current generation of
automotive ECUs.
AUTOSAR allows the inclusion of proprietary OSs in Basic Software omponents.
To make the interfaces of these components AUTOSAR compliant, the proprietary OS
must be abstracted to an AUTOSAR OS. The standard OSEK OS (ISO 17356-3) is used
as the basis for the AUTOSAR OS.
8/12/2019 Autosar Scheduling Automotive Embedded - Copy
http://slidepdf.com/reader/full/autosar-scheduling-automotive-embedded-copy 22/37
Model Engineering College Scheduling Complex Automotive Embedded Real Time Sytems
Departmenent of Electronicѕ Engineering 24
6.4 Microcontroller Abstraction
Access to the hardware is routed through the Microcontroller Abstraction
layer (MCAL) to avoid direct access to microcontroller registers from higher-level
software.
MCAL is a hardware specific layer that ensures a standard interface to the
components of the Basic Software. It manages the microcontroller peripherals and
provides the components of the Basic Software with microcontroller independent values.
MCAL implements notification mechanisms to support the distribution of commands,
responses and information to different processes. Among others it can include:
a)Digital I/O (DIO)
b)Analog/Digital Converter (ADC)
c)Pulse Width (De)Modulator (PWM, PWD)
d)EEPROM (EEP)
e)Flash (FLS)
f)Capture Compare Unit (CCU)
g)Watchdog Timer (WDT)
h)Serial Peripheral Interface (SPI)
i)I2
C Bus (IIC)
6.5 ECU specific components
6.5.1 ECU Abstraction
The ECU Abstraction provides a software interface to the electrical values of any
specific ECU in order to decouple higher-level software from all underlying hardware
dependencies.
6.5.1 Complex Device Driver (CDD)
The CDD allows a direct access to the hardware in particular for resource critical
applications.
8/12/2019 Autosar Scheduling Automotive Embedded - Copy
http://slidepdf.com/reader/full/autosar-scheduling-automotive-embedded-copy 23/37
Model Engineering College Scheduling Complex Automotive Embedded Real Time Sytems
Departmenent of Electronicѕ Engineering 25
Chapter 7
MULTICORE SCHEDULING IN AUTOSAR OS
7.1 Introduction
One of the outcomes of the AUTOSAR initiative is indeed to help OEMs shift
from the “one function per ECU” paradigm to more centralized architecture designs.
There are currently several existing and suggested HW-architectures1 for Multi-
Core microprocessors. There is considerable variation in the features offered by these
architectures. Therefore this section attempts to capture a common set of architectural
features required for Multi-Core.
a) More than one core on the same piece of silicon.
b) The hardware supports some atomic Test-And-Set functionality or similar
functionalities that can be used to built a critical section shared between cores.
Additional atomic operations may exist.
c) If per-core caches exist, AUTOSAR requires support for RAM - cache coherency
in HW or in SW. In software means that the cache-controller can be programmed
the SW in a way that it invalidates cache lines or excludes certain memory regions
from caching
d) The cores may have the same instruction set; at least a common basic instruction
set is available on all cores. Core specific add-ons may exist but they are not
taken
8/12/2019 Autosar Scheduling Automotive Embedded - Copy
http://slidepdf.com/reader/full/autosar-scheduling-automotive-embedded-copy 24/37
Model Engineering College Scheduling Complex Automotive Embedded Real Time Sytems
Departmenent of Electronicѕ Engineering 26
7.2 Memory features
a) Shared RAM is available to all cores; at least all cores can share a substantial part
of the memory. b)Fash shall be shared between all cores at least. However, performance can be
improved if Flash/RAM can be partitioned so that there are separate pathways from
cores to Flash.
c)A single address space is assumed, at least in the shared parts of the memory address
space.
d)The AUTOSAR Multi-Core architecture shall be capable to run on systems that do
and do not support memory protection. If memory protection exists, all cores are
covered by a hardware based memory protection
The OS can be entered on each core in parallel. This optimizes scalability
towards multiple cores. The cores schedule independently.
F ig 7.1 :Mul ticore scheduli ng in AUTO SAR OS[5]
Priorities are assigned to TASKS. The cores schedule independently from each
other.This implies that the schedule on one core does not consider the scheduling on theother cores2. A low priority TASK on one core may run in parallel with a high priority
TASK on another core.
8/12/2019 Autosar Scheduling Automotive Embedded - Copy
http://slidepdf.com/reader/full/autosar-scheduling-automotive-embedded-copy 25/37
Model Engineering College Scheduling Complex Automotive Embedded Real Time Sytems
Departmenent of Electronicѕ Engineering 27
7.3 Static cyclic and fixed priority scheduling
Static cyclic scheduling of elementary software components or runnables, is
common because they are usually many more runnables that the maximum number of
tasks allowed by automotive operating systems such as OSEK/VDX or AUTOSAR OS.
For this reason, runnables must be grouped together and scheduled within a sequencer
task (also called dispatcher task).
A first step of the approach is to partition the runnable sets onto the different
Cores.
The next and last step consists in determining the offsets between the runnables
allocated on each core so as to balance the load over time.
7.4 Model description
In this case study, we consider a large set of n periodic elementary software
components, also called runnables, that are to be allocated on an ECU consisting in m
identical cores. In practice, a runnable can be implemented as practice, a runnable can be
implemented as a function called, whenever appropriate, within the body of an OS task .
7.4.1 Runnable characteristics
The ith runnable is denoted by Ri =(Ci,Ti,Oi,{R},Pi).
Where Ci= Worst-Case Execution Time(WCET)
Ti=Execution Period of Ri
Oi=Offset of Ri
The offset of a runnable is the release date of the first instance of that
unnable,subsequent instances are then released periodically. The choice made for the
offset values has a direct influence on the repartition of the workload over time.
8/12/2019 Autosar Scheduling Automotive Embedded - Copy
http://slidepdf.com/reader/full/autosar-scheduling-automotive-embedded-copy 26/37
Model Engineering College Scheduling Complex Automotive Embedded Real Time Sytems
Departmenent of Electronicѕ Engineering 28
7.4.2 Dispatcher task
Runnables are scheduled on their designated core using a dispatcher task, or
“sequencer task”, that stores the runnable activation times in a table and releases them at
the right points in time.
A dispatcher task is characterized by the duration of the dispatch table Tcycle that
is executed in a cyclic manner2, and by a quantum Ttic which is the duration of a slot in
the table. Dispatch table holds Tcycle/Ttic slots.
7.4.3 Assumptions
In this paper, we place a set of working assumptions which, in our experience, can
most often be met in today’s automotive applications:
a)Each runnable are executed strictly periodically. As a result, the whole trajectory of the
b)The runnables are assumed to be offset-free, in the sense that the offset of a runnable
construction of the dispatch table with the objective to uniformize the CPU load over a
scheduling cycle.
c)The worst case execution times of the runnables are assumed to be small compared to
Ttic. Typical values for the case we consider would be 5ms for Ttic and Ci<=300µs.
d)All cores are identical regarding their processing speed.
e)There are no dependencies between runnables allocated on different cores Therefore,
all cores can be scheduled independently. This assumption is in line with the choices
made by AUTOSAR regarding multicore architecture .
7.5 Scheduling condition
In our context, the system is schedulable, and thus can be safely deployed, if and
only if on each core.
a) The runnables are executed strictly periodically. b)The initial offset of each runnable is smaller than its period.
c) The sum of the WCET of the runnables allocated in each slot does not exceed a
given threshold, which is typically chosen as the duration of the ѕlot ttic.
8/12/2019 Autosar Scheduling Automotive Embedded - Copy
http://slidepdf.com/reader/full/autosar-scheduling-automotive-embedded-copy 27/37
Model Engineering College Scheduling Complex Automotive Embedded Real Time Sytems
Departmenent of Electronicѕ Engineering 29
7.6 Building tasks as a bin-packing problem
It is assumed that the number of cores is fixed. We first distribute all the
runnables on the cores without checking the schedulability condition at that stage.
Assigning n tasks to m cores is like subdividing a set of n elements into m non-empty
subsets.
Considering this complexity, to balance as evenly as possible the utilization of
processor cores, we propose a heuristic based on the bin-packing decreasing worst-fit
scheme for a fixed number of bins (where “bins” here are processor cores). The heuristic
is given in Algorithm 7.1.
Algorithm 7.1:Partitioning of runnable set [2]
8/12/2019 Autosar Scheduling Automotive Embedded - Copy
http://slidepdf.com/reader/full/autosar-scheduling-automotive-embedded-copy 28/37
Model Engineering College Scheduling Complex Automotive Embedded Real Time Sytems
Departmenent of Electronicѕ Engineering 30
Chapter 8
CASE STUDY : CAN FRAME ALLOCATION
8.1 CAN(Control Area Network)
CAN is a serial Protocol developed by Robert Bosch GmbH originally for
communication among components of cars.
CAN finds lot of applications in automobiles:
1)A low speed CAN bus may be employed to operate window and seat controls.
2) A high speed CAN bus may be employed for engine management or brake control.
3)Other applications are Engine Sensors, Anti-Skid Systems.The success of CAN is due to the inexpensive electronic components (ICs) for
managing the communication protocol. The number of CAN nodes on each vehicle 5-10
for the engine system, 10 for the body part, 15, 20, 25 or more for the passenger
compartment .
The CAN bus is a Balanced (differential) 2-wire interface. Bus support data
transfer rates up to 1 Mbit/s and 11-bit addressing.
8.2 CAN Bus frame
The CAN Bus interface uses an asynchronous transmission scheme controlled by
start and stop bits at the beginning and end of each character.
CAN uses different frames with distinct functions like
a)Data Frame
From transmitter to receiver
b)Remote Frame
Transmitted by receiver to request for data
c)Error Frame
d)Overload Frame
8/12/2019 Autosar Scheduling Automotive Embedded - Copy
http://slidepdf.com/reader/full/autosar-scheduling-automotive-embedded-copy 29/37
Model Engineering College Scheduling Complex Automotive Embedded Real Time Sytems
Departmenent of Electronicѕ Engineering 31
8.2.1 CAN bus Data Frame
F ig 8.1: Can data fr ame[3]
a)The data frame is composed of an Arbitration field, Control field, Data field, CRCfield,
. ACK field
b)The frame begins with a 'Start of frame' [SOF], and ends with an 'End of frame' [EOF]
space.
c)The data field may be from 0 to 8 bytes.
8.3 CAN frame allocation and scheduling
CAN has been and will most likely remain a prominent network in cars for atleast
two more car generations. One of the issues CAN will have to face is the growth of traffic
with the increasing amount of data exchanged between Electronic Control Units (ECUs).
A car manufacturer has to make sure that the set of frames will be schedulable,
i.e. the response time of the frames is kept small enough to ensure that the freshness
of the data is still acceptable when used at the receiver end. Clearly here, for most
messages, even periodic ones, we are in the realm of soft real-time constraints: a deadline
constraint can be occasionally missed without major consequences. However, the issue
on CAN is that worst-case response times increase drastically with the load.
8.4 Least loaded algorithm
Problem of scheduling runnables can be analyzed using the “least-loaded”
algorithm which is proposed for the frame offset allocation on a CAN network.
Considering a runnable Ri of period Ti, there are Ti/Ttic possibilities for allocating
this runnable .
As a result there are ∏ alternative schedules for the n r unnables.
The intuition behind the heuristic is simple: at each step,assign the next runnable
to the least loaded slot, as described in Algorithm 8.1.
8/12/2019 Autosar Scheduling Automotive Embedded - Copy
http://slidepdf.com/reader/full/autosar-scheduling-automotive-embedded-copy 30/37
Model Engineering College Scheduling Complex Automotive Embedded Real Time Sytems
Departmenent of Electronicѕ Engineering 32
The load of a slot is the sum of the Ci of the runnables {Ri} already assigned to
this slot. The intuition behind the heuristic is simple: at each step, we assign the next
runnable to the least loaded slot, as described in Algorithm 8.1
Algori thm 8.1: Assigning runnable to slots : the “least loaded” heuristic.[2]
For practical applications, ties at Step (1) are broken using highest WCET first
and ties at Step (2a) by choosing the central slot of the longest sequence of consecutive
slots having the minimum load. It helps to separate load peaks, which is important from
the ECU designer point of view.
As an illustration, the result of applying the least-loaded heuristic to the set of
runnables Ri(Ti;Ci): R1(10,2), R2(10, 1), R3(20, 4), R4(20, 2) leads to the dispatch table
shown in Figure 8.2
Figure 8.2: Example of dispatch table[5]
The resulting distribution of the load is:
Table 8.1: Load reparti tion corresponding to the dispatch table in F igure 8.2 .[5] .
8/12/2019 Autosar Scheduling Automotive Embedded - Copy
http://slidepdf.com/reader/full/autosar-scheduling-automotive-embedded-copy 31/37
Model Engineering College Scheduling Complex Automotive Embedded Real Time Sytems
Departmenent of Electronicѕ Engineering 33
8.4.1 Dealing with non harmonic runnable setIn practice, often, runnable sets do not have strictly harmonic periods. As a
consequence, the previous results do not hold anymore. In particular, placing a runnablein the least loaded slot of the dispatch table could induce peaks because of the runnable
periodicity. Take the folllowing runnable set for instance: R1(10; 2), R2(20; 3),R3(20; 1),
R4(50; 2) with Ttic = 5 and Tcycle = 100. Figure 8.3 shows the dispatch table before the
allocation of R4
F igure 8.3: D ispatch table before the insert ion of R4 .[5]
The resulting distribution of the load is:
Table 8.2: L oad reparti tion corresponding to the dispatch table in F igure8.3 .[4]
At that point, choosing one of the least loaded slots in the dispatch table with
make the schedule fail because R4 will also have to be allocated in a slot with the highest
load because of its periodicity. For example, if the first instance of R4 is allocated in slot
1, be placed in slot 11 and make the system unschedulable.
However, allocating R4 in any even slot is safe.In order to deal with non-armonic
runnable sets, we need to go through a larger window of slots for the choice of the ffsets.
In the following, variable Twindow is equal to the lcm of the periods of the runnables
already scheduled at the current state of the algorithm. Instead of looking for the least
loaded slot in the first Ti=Ttic slots, we try to create the smallest peak over Twindow,
knowing that the schedule repeats in cycle afterward as given by algorithm 8.2.
8/12/2019 Autosar Scheduling Automotive Embedded - Copy
http://slidepdf.com/reader/full/autosar-scheduling-automotive-embedded-copy 32/37
Model Engineering College Scheduling Complex Automotive Embedded Real Time Sytems
Departmenent of Electronicѕ Engineering 34
Algorithm8.2 Generalized “least - loaded” heuristic.[2]
8.4.2 Improvement: placing outliers first
The algorithms 8.1 and 8.2 construct the scheduling of runnables with arbitrary
periods and possibly with locality and inter-runnable constraints.These algorithms
sometimes do not handle well runnable sets where a few runnables with a low frequency
have a very large In practice, runnables with a large WCET tend to have a large period.
As a result, runnables with large WCET are usually processed late in the runnable
allocation process which explains the load peaks. In order to reduce those peaks, the
scheduling algorithm is improved by processing some runnables with a large WCET first.
We define the WCET threshold critical=µ+kσ with
µ=average of the distribution of {Ci}
σ =Standard deviation of the distribution of {Ci}
k= an integer value.
The runnables with Ci larger than Ccritic are allocated first. Then, the rest of the
runnables are processed as done in algorithm 8.2. This new version of the loadbalancing
algorithm is referred to as Generalized leastloaded sigma, or G-LLk σ for short. In the
experiments that follows, k is chosen equal to 1 .
8/12/2019 Autosar Scheduling Automotive Embedded - Copy
http://slidepdf.com/reader/full/autosar-scheduling-automotive-embedded-copy 33/37
Model Engineering College Scheduling Complex Automotive Embedded Real Time Sytems
Departmenent of Electronicѕ Engineering 35
Chapter 9
SIMULATION USING NETCAR ECU
9.1 RTaW NETCAR ECU
Software tools that help complex systems designers to optimizes the scheduling
of tasks (or runnables) so as to reduce the load peaks while meeting task deadline
constraints. RTaW-ECU enables the designers to squeeze the most from the CPUs.The
tool is developed by company RTaW(RealTime-at-Work).
RTaW-Sim supports the simulatin of discrete-event Controller Area Network
(CAN) providing the frame response time distributions and statistics about the frame
buffer usage at the microcontroller and communication controller level.
RTaW-Sim helps the designer choose the right communication stacks (e.g.waiting
queue policy) and communication controllers (e.g.,number of buffers), and configure
them. RTaW-Sim enables the designer to also perform simulation Based Fault Injection
(SBFI), for instance analyzing the effects of clock drifts or the impact of transmission
errors on transmission latencies
9.1.1Features of NETCAR ECU
a)Handle multicore CPUs 22jj
b)Optimize the number of tasks per time slot or the total workload per time slot
c)Enable to reduce load peaks and thus optimize the CPU usage
d)Offer a better resilience against wrong estimations of the execution times or activation
Patterns.
e)Achieve guaranteed performances in terms of CPU loadf)Can be used jointly with Fixed-Priority Preemptive (FPP) scheduling tool to conceive
mixed scheduling solutions
g) Incremental scheduling :new tasks can be added in an existing system
h)Very fast computation
8/12/2019 Autosar Scheduling Automotive Embedded - Copy
http://slidepdf.com/reader/full/autosar-scheduling-automotive-embedded-copy 34/37
Model Engineering College Scheduling Complex Automotive Embedded Real Time Sytems
Departmenent of Electronicѕ Engineering 36
9.2Simulation of task sets using NETCAR ECU
Here we assess the ability of the algorithms to uniformize the CPU load over time
and to keep on providing feasible solutions at very high load level.
The task sets considered here are harmonic with periods in the set { 10; 50; 100;500; 1000ms }, which is a large subset of the periods used in the real ECU. The WCETs
vary from 10µ s to 300 µs with a probability derived from the real distribution on the body
gateway ECU.We choose the average CPU load slightly below 94% so that the feasibility
is ensured .
Figure 9.1 shows the distribution of the load over a LCM of the periods with least loaded
algorithm. A set of runnables corresponding to slightly less than 94% of CPU load is scheduled on a
4-core ECU.
F ig 9.1: The distribution of the load over a LCM of the peri ods with LL[4]
The x axis shows the time slots and y axis shows the total load per slots (Worst
case execution time)
8/12/2019 Autosar Scheduling Automotive Embedded - Copy
http://slidepdf.com/reader/full/autosar-scheduling-automotive-embedded-copy 35/37
Model Engineering College Scheduling Complex Automotive Embedded Real Time Sytems
Departmenent of Electronicѕ Engineering 37
Fig 9.2 Shows the distribution with G-LL1 σ
F ig 9.2:The distri bution with G- LL1 σ [2]
It can been seen, the load peaks are much smaller with Generalized Least
Loaded1 σ (peak load is 94.6%) than with Least Loaded (peak load is 98.4%). This can
be explainedThe runnables with C i larger than C critic are allocated first. as done in algorithm
ie, because the few largest runnables are placed first and the numerous smaller
ones placed afterward fill the gaps in the schedulable table. This reduces the peak loads
per slots.
8/12/2019 Autosar Scheduling Automotive Embedded - Copy
http://slidepdf.com/reader/full/autosar-scheduling-automotive-embedded-copy 36/37
Model Engineering College Scheduling Complex Automotive Embedded Real Time Sytems
Departmenent of Electronicѕ Engineering 38
Chapter 10
CONCLUSION
.
The formal verification of task schedulability is getting more important in the
automotive domain We introduced a computational model for the response time analysis
(RTA) of automotive real time systems. Such systems often consist of subsystems that
comprise of a collection of tasks, called transactions, which are triggered by external
events.
Today’s automotive design methodologies need to be adapted to multicore
computing and there is a wide range of technical problems to be solved In this paper, we
have presented practical scheduling solutions well suited to the basic use-case which is to
execute a large number of software components on the same multicore processor in order
to reduce the number of ECUs. The set of algorithms described in this paper have shown
on realistic case-studies to be versatile and efficient in terms of CPU usage optimization.
8/12/2019 Autosar Scheduling Automotive Embedded - Copy
http://slidepdf.com/reader/full/autosar-scheduling-automotive-embedded-copy 37/37
Model Engineering College Scheduling Complex Automotive Embedded Real Time Sytems