See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/307572558
Efficient application of multi-core processors as substitute of the E-Gas (Etc)
monitoring concept
Conference Paper · July 2016
DOI: 10.1109/SAI.2016.7556089
CITATIONS
READS
3
12,767
3 authors, including:
Mario Hirz
Jürgen Fabian
Graz University of Technology
Graz University of Technology
241 PUBLICATIONS 1,067 CITATIONS
29 PUBLICATIONS 149 CITATIONS
SEE PROFILE
All content following this page was uploaded by Mario Hirz on 17 August 2017.
The user has requested enhancement of the downloaded file.
SEE PROFILE
SAI Computing Conference 2016
July 13-15, 2016 | London, UK
Efficient Application of Multi-Core Processors as
Substitute of the E-Gas (Etc) Monitoring Concept
Manfred Großmann, Mario Hirz, Jürgen Fabian
Institute of Automotive Engineering
Graz University of Technology
Graz, Austria
Abstract—Complexity and electrification of automobiles
increases steadily, which involves an enhancement of safetyrequirements of applied E/E-components, controllers and their
connection and interaction in between. As a fundamental safetyrelevant standard, the E-Gas monitoring concept has been
introduced in the ‘90s. Recently, a new version of this E-Gas
monitoring concept has been published, which includes the
application of multi-core processors. In this context, the paper
contains an analysis and evaluation of modern multi-core
architectures in automotive applications and discusses
requirements, benefits and potentials for integrated safety
mechanisms. In addition it is discussed, if modern safety-certified
automotive micro-controller are able to replace the wellestablished 3-level monitoring concept.
Keywords—multi-core microcontroller; functional safety; EGas; monitoring-concept; ISO 26262
I.
INTRODUCTION
Any modern vehicle is a highly complex mechatronic
system, which is built up on a network of different subsystems
with steadily increasing functions and complexity. Besides
continual improvements and changes of powertrain systems,
there are more and more other electronic functionalities, like
driver-assistance systems as well as comfort-related functions
and applications, which directly or indirectly influence the
vehicle characteristics. With increasing complexity, the aspects
of safety gains importance.
Already in the ‘90s, the standardized E-Gas (electronic
throttle control) monitoring concept for gasoline and diesel
engine control units has been published. Recently (in autumn
2015), a new version 6.0 of this standard has been released [1],
which includes a guideline for development of future engine
control systems. The well-established 3-level monitoring
concept is commonly requested and used for several other
applications. This paper includes an analysis and evaluation of
this safety-concept and its requirements with focus on the
changes between the previous and current version.
Since November 2011, the ISO 26262 represents the
current state of the art functional safety standard for road
vehicles with a weight of less than 3.500kg [2]. Amongst
others, it considers the safety-related lifecycle from item
definition to production and operation. For the present work,
the ISO 26262 guidelines are compared against the safetyrequirements of the E-Gas concept.
Automotive chip manufacturers provide modern safetycertified multi-core microcontrollers, which are already
developed according to the ISO 26262. These architectures
also provide integrated safety-functions to reduce
development- and implementation effort. Based on an example,
this paper analyzes the hardware-related safety-mechanisms
introduced in the new release version 6.0 of the E-Gas concept,
and compare them with characteristics of the previous versions.
As a result, the significance and purpose of the 3-level
monitoring concept is proven and a safety-concept for
common-purpose applications (besides electronic throttle
control) is derived. Finally, the possibilities of multi-core
architectures are explored and a new concept for potential
applications is introduced.
The following chapter discusses the E-Gas monitoring
concept and its safety-requirements. This is followed by a
chapter describing integrated safety-features of a current
automotive microcontroller. In the final chapter, the concepts
are merged and conclusions are drawn.
II.
E-GAS MONITORING CONCEPT
The standardized E-Gas monitoring concept for gasoline
and diesel engines [1] is a supplier-independent documentation
to address the high conditions on state of the art Drive-by-Wire
systems.
Drive-by-Wire systems replaced the former mechanical
accelerator cable by pedal-position sensors connected to an
electronic control unit (ECU), which drives the mixture
preparation system. Exemplary, the throttle valve position is
controlled by the ECU, which receives a feedback signal from
a throttle-valve position sensor.
Since version 5.5 released in 2013 [3], the E-Gas concept is
in compliance with the ISO 26262, which requires a hazard
analysis and risk assessment during the concept-phase.
Four hazards were identified, where a malfunctioning
behavior of the E-Gas can lead to harmful situations:
 Unintended acceleration
 Absence of acceleration
 Unintended deceleration
 Absence of deceleration
1|P age
978-1-4673-8460-5/16/$31.00 ©2016 IEEE
SAI Computing Conference 2016
July 13-15, 2016 | London, UK
Only unintended acceleration and the corresponding safetygoal to prevent this malfunction has been rated ASIL B. The
others are considered as controllable and rated at the level
Quality Management (QM). ASIL (Automotive Safety
Integrity Level) is one of four levels defined in the ISO 26262
[2], which are used to classify hazardous events and all derived
safety-goals. The classification considers severity of harm,
probability of exposure, and controllability of the situation. The
sum of those three ratings defines the necessary ASIL from A
(lowest) to D (highest). In turn, the ASIL defines necessary
requirements, safety measures and mechanisms. Further
information and documentation about usage and development
according to ISO 26262 can be exemplary found in [4], [5],
[6], [7].
A. Safety-requirements of the E-Gas concept (extract)
Derived requirements summed up in a compact view are:

Plausibility checks for sensor- and actuator-signals

Detection of sensor- and actuator-faults by the ECU

Detection of undesired states or unintended
acceleration. In case of a fault, the ECU switches to a
safe state.

Monitoring of the function controller
The first two requirements are achieved by application of
redundant sensors. The latter two require a safety-concept,
which is called 3-level monitoring concept. It was introduced
by Robert Bosch GmbH and adapted by the EGAS Workgroup
[8]. By safe state usually a switched-off system is meant but
the type of safe state depends on the specific system and
application. A safe state can also be operating correctly or
explicitly indicating an internal error.
B. 3-level monitoring concept
The monitoring concept consists of 3 levels (see Fig. 1.).
The first level is called function level, which contains the
control functions. In case of an electronic throttle control, the
main function is to translate the current accelerator-pedal
position to a referring throttle-valve position (as a very
simplified explanation). Level 1 also includes component
monitoring and input-/output-variable diagnostics. In case of
detected faults, the system has to react accordingly (e.g.
limitation of fuel injection) and those fault-reactions need to be
monitored, too.
The second level monitors the function level, e.g. by
diverse calculation or estimation of the output-values and
applying range checks to level 1 values. In case of detected
faults, level 2 is either able to apply referring reactions by itself
or it initiates a reaction carried out by level 1.
The third level monitors the controller for integrity.
Therefore, an independent monitoring-module, e.g. an
application-specific integrated circuit (ASIC), a watchdog, or
another controller are frequently requesting specific answers to
questions, which guarantee a proper functioning of the
controller. These tests include program-flow checks,
instruction-set tests of the Central Processing Unit (CPU), and
memory tests.
Function Controller (MCU)
Inputs
L1: Function
Outputs
L2: Function Monitoring
L3: Controller Monitoring
Integrated safety mechanisms
L3: Controller Monitoring
System level safety mechanisms
Monitoring Module (e.g. SBC, ASIC)
Fig. 1. 3-level monitoring concept
As shown in Fig. 1., the controller monitoring is divided
partly on the function controller and partly on the independent
monitoring controller. The question and answercommunication has to be in time. For verification, also wrong
answers are transmitted to test proper reaction of the
monitoring module. In case either that the monitoring-module
detects a fault of the function-controller, or vice versa, the
system needs to switch to a safe state (e.g. injection cut off).
C. Additional features of version 6.0 (compared against
version 5.5)
Previous versions were relying on simple microcontroller
architectures [3]. They consisted of a single-core CPU with
some memory and I/O ports. All necessary safety-mechanisms
had to be implemented in software. The new release now
mentions microcontrollers, which include hardware-integrated
safety-mechanisms. Thus, the level 3 controller monitoring
chapter has been adapted and extended in the guideline [1].
The new version includes the possibility, that necessary checks
can be performed by software, error-detection hardware, or by
a combination of both. As restriction to hardware-tests, the
integrated safety-mechanisms have to be tested for
functionality (e.g. by fault-injection or Built-In Self Tests BIST), and the configurations of those safety-mechanisms need
to be protected and checked during runtime.
As an alternative to the function-specific instruction-set
test, the usage of a lockstep-comparator has been added as
verification of proper functionality of the main processor core.
A checker-core is fed with the same inputs as the main core to
verify the integrity of the master-core’s calculations. This
provides a significant improvement, as the duplication of
level 2 codes is eliminated. In former versions, it was necessary
to perform instruction-set tests without disturbing level 2
processes.
The 2015 version 6.0 of the E-Gas concept includes multicore processor architectures, too. In this way, all safetyrelevant data-transmission and each used core need to be
protected by monitoring mechanisms according to their safetyrelevant monitoring functions. The goal is to provide freedom
2|P age
978-1-4673-8460-5/16/$31.00 ©2016 IEEE
SAI Computing Conference 2016
July 13-15, 2016 | London, UK
from interference [2] to avoid that lower ASIL-classified
functions disturb higher classified ones.
In the next chapter, integrated safety-mechanisms are
explored in detail based upon an example [9] and mapped to
safety-requirements of the E-Gas concept.
III.
INTEGRATED SAFETY MECHANISMS OF MODERN
MULTI-CORE MICROCONTROLLERS
There are modern automotive microcontrollers on the
market, which are already developed according to ISO 26262
and safety-certified to fulfil up to ASIL D requirements.
However, as those microcontrollers can be used in different
systems, the requirements and necessary safety-mechanisms
are application dependent. The microcontrollers itself are
considered and developed as Safety Element out of Context
(SEooC) [2]. The integrated safety-concept is relying on
assumptions and recommendations, which are made to fit
possible application-scenarios.
A. Dual-Core Lockstep
The used microcontroller for present investigations [9]
includes a dual-core processer in delayed lockstep-mode. From
application point of view, it behaves just like a single-core
controller, without real multi-core capabilities. The checker
core receives the same inputs with a delay of two clock-cycles
to avoid common cause failures (CCF), evoked by power- and
clock-disturbances. All outputs of the checker-core are
compared against delayed outputs of the master-core. Errors
are forwarded to the central Fault Collection and Control Unit
(FCCU).
Lockstep mode ensures proper calculations of the processor
core, and therefore, an instruction-set test becomes obsolete.
B. Fault Collection and Control Unit (FCCU)
All integrated hardware checks and safety modules transmit
detected errors and test-results to the FCCU, which is
configurable to react to given failure indicators and to bring the
device to a safe state. The FCCU is an autonomous module that
contains a Finite State Machine (FSM), which is able to run
without CPU-intervention. An internal watchdog, the FCCU
Output Supervision Unit (FOSU), monitors the FCCU for
proper error-reaction within a predefined interval. In case of a
timeout, the FOSU assumes that the FCCU has failed, and
resets the microcontroller. The FOSU cannot be configured in
any way. The FCCU has two external signals to communicate
its state and critical failures to other (supervising) devices.
C. Error Correcting Codes (ECC)
ECC-protection is used to ensure data-integrity for
transmissions between the cores and the system memory and
some peripherals. Therefore, the data and addressing
information are encoded using ECC when stored and decoded
at reading. Single-bit errors are automatically corrected,
double-bit errors are detected. Both, correctable and
uncorrectable failures are signaled to the Memory Error
Management Unit (MEMU), which forwards the errorinformation to the FCCU, if configured.
ECC replace former memory tests and integrity-checks
applied in software, e.g. storage of bit-complement or usage of
Cyclic Redundancy Check (CRC) for integrated memory.
D. Cyclic Redundancy Checker Unit (CRC)
The CRC-unit is used for CRC checksum calculations to
offload the CPU. CRC enable a detection of erroneous
corruption of data during transmission or storage.
It is applied to check the integrity of safety-relevant
registers during operation and safety-relevant program-code
initialization. Furthermore, CRC checks are used together with
sequencing, sender identification, and an acknowledgement
protocol for data-transmission over common bus-systems (e.g.
FlexRay or CAN). This complies with requirements from the
E-Gas concept.
E. Built-In Self Test (BIST)
A set of integrated test-mechanisms is used to avoid
accumulation of latent faults. Device BIST is automatically
performed at boot time by testing digital logic and memory.
Further BISTs check integrity of flash memory and test Analog
to Digital Converter (ADC) against latent failures.
In version 6.0, those built-in tests replace former common
tests, which were implemented and executed in software.
F. Memory Protection Unit (MPU)
The core and system MPUs are safety mechanisms to
provide freedom from interference by restricting access to
memory-regions.
This is necessary to enable an integration of multiple
applications or programs with different ASIL classification.
G. Common Cause Failure (CCF) measures
CCFs are dependent failures, in which two or more
component faults exist at the same time, caused by the same
source (e.g. external clock or power supply).
There are several Clock Monitor Units (CMU) to supervise
the frequency of clocks used within the microcontroller. They
are driven by an internal oscillator to be independent from the
monitored clocks.
The Power Management Controller (PMC) contains low
and high voltage detection monitors, with the possibility to
directly reset the microcontroller in case of a detected error. All
I/O peripherals have at least two instances, which are
connected to different bridges. This allows redundant usage of
I/O while limiting possible causes of CFFs.
Further measures against CFFs include physical separation
of components on the die, routing restrictions, or supervision of
temperature, test- and debug signals. Undetectable Common
Mode Failures (CMF) need to be addressed by external
measures on system level. There might be errors, which may
not be detected by the microcontroller itself. Thus, some
separate device is needed to monitor the controller. This
hardware-requirement on system level matches level 3 of the
E-Gas concept.
3|P age
978-1-4673-8460-5/16/$31.00 ©2016 IEEE
SAI Computing Conference 2016
July 13-15, 2016 | London, UK
IV.
RESULTS
Function Controller (MCU)
Other works related to electronic throttle control include
dependability-issues using fault-trees [10], or modeling of
diagnostic system to enable real-time health-monitoring [11].
Concerning usage of multi-core controllers in automotive
applications, several papers are discussing benefits and
challenges regarding hardware and software, e.g. [12], [13],
[14]. Other publications compare the efficiency, related to
power consumption and processing times, between common
single-core and multi-core architectures [15], [16]. Functional
safety critical factors concerning Electro-Mechanical Brake
Systems from microcontroller point-of-view are investigated in
[17].
Analyzing the E-Gas concept provides an overview of
hierarchical monitoring of functions and other monitors. In
three different levels, firstly inputs and outputs, secondly the
function, and thirdly the controller are monitored. By using at
least two independent devices (function-controller and
monitoring device), it is possible to keep the monitoring-device
under surveillance, too. This 3-level monitoring concept stays
valid, also for modern multi-core microcontrollers with
integrated safety-mechanisms and peripherals. It is necessary
to achieve high diagnostic coverage over all components of the
system, starting from sensors, through controller, to actuators.
The integrated safety-mechanisms replace tests and checks,
former implemented in software. This reduces the effort of
implementation and development, depending on the application
and applied peripherals.
Only one external watchdog has to be serviced by the
function-controller to signal its correct behavior. Furthermore,
the error-outputs of the FCCU need to be monitored. In case of
timeout or signaled error-state, the monitoring device has to be
able to reset the function-controller and it has to able to bring
the system to a safe state (e.g. by switching off the driver
output stage).
To achieve necessary independence for the functioncontroller and its monitoring device, separate power-supplies
and clocking have to be installed. As overvoltage might
damage or destroy the microcontroller permanently, its powersupply needs to be regulated and monitored by an external
device. This enables a complete shutdown of the power supply
to the microcontroller to bring the system to a safe state. Chipmanufacturers usually provide an own System Basis Chip
(SBC), which includes above-mentioned safety-functionalities
[9].
V.
OUTLOOKS
The investigated exemplary microcontroller uses a dualcore lockstep CPU. As already mentioned, this behaves from
application point of view just like a common single-core
microcontroller, which means that all programs and application
are carried out by this one core. Looking at multi-core
microcontrollers with two or more individual CPU-cores (with
or without lockstep functionality as a safety-mechanism), the
possibilities of their usage increase [12], [14].
Inputs
Core 1:
L1: Function
Outputs
Core 2:
L2: Function Monitoring
L3: Controller Monitoring
Integrated safety mechanisms
L3: Controller Monitoring
System level safety mechanisms
Monitoring Module (e.g. SBC, ASIC)
Fig. 2. Separation of level 2 function monitoring
In general, multi-core CPUs allow distribution of tasks or
applications onto different cores. This can increase overall
performance, as well as energy- and area-efficiency compared
to single-core CPUs using the same die-space [15], [16].
Another advantage includes a possible reduction of physical
units, as more or different applications and functions might be
executed on the same microcontroller. Considering safetyrelevant aspects, multiple cores increase complexity and there
is a lacking of temporal determinism. Freedom from
interference has to be ensured, e.g. if multiple cores are
running different tasks with different ASIL rating, using the
same integrated peripheral, like ADC. Thus, a concentration of
multiple, different applications might increase development
and integration effort. Therefore, safety relevant aspects have
to be considered as early as possible during concept
development.
Considering the 3-level monitoring concept as a basis, there
are two possible new applications of multi-core
microcontrollers:
1) Separation of level 2 function monitoring:
Level 1 functions run on one generic core (without lockstep
mode). Level 2 functions run on a safety-core (using lockstep
mode). This can be viewed as ASIL decomposition [2]. This is
enabled by splitting a higher rated function into two
independent functions with (possible) lower ASIL rating, e.g.
ASIL D = ASIL D(D) + QM(D). To reach this exemplary
target, the controller-function in level 1 is implemented in QM
and the necessary safety- and monitoring-functions in level 2 is
implemented according to its ASIL.
Fig. 2. exemplary shows how the level 1 function is
executed on core 1, whereas its level 2 function monitoring is
accomplished by the second core. Level 3 safety mechanisms
are divided by integrated safety mechanisms and external
system level safety mechanisms.
4|P age
978-1-4673-8460-5/16/$31.00 ©2016 IEEE
SAI Computing Conference 2016
July 13-15, 2016 | London, UK
Function Controller (MCU 1)
Inputs
Outputs
L1: Function
L2: Function Monitoring
L3: Controller Monitoring
Integrated safety mechanisms
System level safety mechanisms
mechanisms programmed in software, become now available
for other applications. Partitioning of level 1 functions and
level 2 monitoring allows efficient usage of multi-core
processors. For safety-critical applications it is necessary to
provide monitoring of the microcontroller itself, to cope with
common cause and systematic failures. This surveillance of a
microcontroller can be achieved by another microcontroller,
which allows potentially more options to react or control
situations, when failures are detected.
ACKNOWLEDGMENT
The authors would like to thank Mr. Adam Schnellbach
from MAGNA Powertrain in Lannach for his valuable support.
L3: Controller Monitoring
Integrated safety mechanisms
System level safety mechanisms
L2: Function Monitoring
L1: Function
Function Controller (MCU 2)
Fig. 3. Redundant or fail-operational usage of microcontrollers
2) Redundant or fail-operational usage of cores:
All functions and applications are executed on both cores
using different peripherals until an error occurs. Depending on
the error, the system switches to the remaining working core
(or peripherals). Another solution includes one core running
and executing tasks, while the other core stays idle until an
error occurs and the tasks are shifted to the (new) working
core.
A possible third application provides redundant or failoperational usage of multiple microcontrollers (see Fig. 3.).
This is also investigated and proposed by other publications in
a similar way [18]. As shown, external level 3 system level
safety mechanisms are integrated into the microcontrollers,
monitoring each other. This arrangement allows a failoperational execution of level 1 functions. In case of a detected
failure, the second microcontroller unit (MCU) is able to fully
continue operation, while trying to reset the faulty one. It is
also imaginable, that both MCUs are running different
applications and only in case of a failure, the second one takes
over limited functionalities of the faulty one.
Above mentioned, possible applications of multi-core
microcontrollers are newly introduced concepts for E-Gas and
similar applications. In future work, the proposed concepts are
going to be evaluated for realization within test-environment.
VI.
CONCLUSION
This research focuses on safety concepts for electronic
throttle control, because it is commonly also used in other
applications. It was discussed, if modern safety-certified
automotive micro-controller are able to replace the wellestablished 3-level monitoring concept. As a result it can be
stated, that they provide integrated safety-features, which allow
easier integration. Resources former used by safety-
REFERENCES
EGAS Workgroup, „Standardized E-Gas Monitoring Concept for
Gasoline and Diesel Engine Control Units,“ Version 6.0,
https://www.iav.com/publikationen/technische-veroeffentlichungen/egas-monitoring-concepts, 2015.
[2] ISO/TC 22/SC 32, ISO 26262:2011 Road vehicles -- Functional safety -Part 1 to 10, 2011.
[3] EGAS Workgroup, „Standardized E-Gas Monitoring Concept for
Gasoline and Diesel Engine Control Units,“ Version 5.5, 2013.
[4] S. Herrmann, SAFETY Essentials: ISO 26262 auf einen Blick, KUGLER
MAAG, 2014.
[5] V. Gebhardt, Funktionale Sicherheit nach ISO 26262, dpunkt.verlag,
2013.
[6] P. Löw, Funktionale Sicherheit in der Praxis, dpunkt Verlag, 2010.
[7] H.-L. Ross, Funktionale Sicherheit im Automobil: ISO 26262, Carl
Hanser Verlag GmbH & Co. KG, 2014.
[8] K. Reif, „2.1.2.8 E-Gas-Überwachungskonzept,“ in Handbuch
Kraftfahrzeug-elektronik, Wiesbaden, Friedr. Vieweg & Sohn Verlag,
2006, pp. 26-27.
[9] freescale,
„Safety
Manual
for
MPC5744P,“
Rev
3,
http://www.freescale.com/products/power-architectureprocessors/mpc5xxx-5xxx-32-bit-mcus/mpc57xx-mcus/ultra-reliablempc574xp-mcu-for-automotive-industrial-safetyapplications:MPC574xP, 2014.
[10] M. Hans, „Electronic Throttle Control – A Dependability Case Study,“
Journal of Universal Computer Science, pp. 730-741, 28 10 1999.
[11] R. Conatser, „Diagnosis of automotive electronic throttle control
systems,“ in Control Engineering Practice, 12 Hrsg., Elsevier Ltd, 2004,
pp. 23-30.
[12] C. El Salloum, „The ACROSS MPSoC - A New Generation of MultiCore Processors Designed for Safety-Critical Embedded Systems,“ in
Microprocessors and Microsystems, 37 Hrsg., Bd. 8, Elsevier, 2013, pp.
1020-1032.
[13] G. Macher, „Automotive Embedded Software: Migration Challenges to
Multi-Core Computing Platforms,“ IEEE, 13th International Conference
on Industrial Informatics (INDIN), 2015.
[14] P. Leteinturier, „MultiCore Benefits & Challenges for Automotive
Applications,“ in SAE-SP (Special Publications), Bd. 2159, SAE, 2008,
pp. 103-113.
[15] S. K. Jena, „On The Suitability of Multi-Core Processing for Embedded,“
in 2012 International Conference on Cyber-Enabled Distributed
Computing and Knowledge Discovery, 2012.
[16] S. Abinesh, „Analysis of Multi-Core Architecture for Automotive
Applications,“ in 2014 International Conference on Embedded Systems
(ICES), 2014.
[17] G. Hwang, „Microcontroller Approach to Functional Safety Critical
Factors in Electro-Mechanical Brake (EMB) System,“ in SAE Technical
Paper 2014-01-2527, SAE, 2014.
[18] A. Kohn, „Fail-operational in safety-related automotive multi-core
systems,“ in 10th IEEE International Symposium on Industrial Embedded
Systems (SIES), 2015.
[1]
5|P age
978-1-4673-8460-5/16/$31.00 ©2016 IEEE
View publication stats