Safe, Reliable, Available, High‒Integrity, and Fault Tolerant Embedded Software Systems

+
Safe, Reliable, Available,
High‒Integrity, and
Fault Tolerant
Embedded Software
Systems
An overview of developing embedded software systems used for safety
critical applications in a variety of domains ‒ from autos, to process control,
to flight systems, to medical devices, fire, safety, and security systems.
Advanced Embedded Systems Development, ECEN 5013
University of Colorado, Boulder
Performance–Based Project Management®, Copyright © Glen B. Alleman, 2002 - 2018
1

Performance–Based Project Management®, Copyright © Glen B. Alleman, 2002 - 2018 2
Glen B. Alleman, MSSM
Embedded Real‒Time systems
for
Flight Avionics
Radar Systems
Process Control Systems
Manufacturing and Shop Floor Systems
Conventional and Nuclear Power

+ Terminal Learning Objectives
(TLO) for Today
n TLO #1 ‒ understand the structures and processes needed to
development reliable, available, safe, and fault tolerant embedded
systems
n TLO # 2 ‒ understand a spectrum of embedded and their fault
management strategies
n Error Reporting
n Fault Detection
n Fault Tolerance
n Fail Safe
n TLO # 3 ‒ using the car example, categorize the embedded systems
using the taxonomy of TLO # 2
3

An embedded system is a controller programmed and controlled by a real-time
operating system (RTOS) with a dedicated function within a larger mechanical or
electrical system, often with real‒time computing constraints.
It is embedded as part of a complete device often including hardware and
mechanical parts.
Embedded Computer
Software
Hardware
Output
Variables
Input
Variables
Link to Other Systems
Software Intensive System of Systems
Interfaces to
Humans or Machine

+ A Starting Point for Reliability, Availability,
and Safety of Embedded Systems
n “It is not feasible to assess the number or kinds of software errors, if
any, that may remain after the completion of system design,
development, and test”
n “Since dependability cannot be guaranteed from an assessment of
the software product, it is necessary to have assurance on its
development process”
n “You can’t deliver clean water in a dirty pipe”
n “Because we cannot demonstrate how well we’ve done, we’ll have to
show how hard we’ve tried”
5

+ Considerations for Embedded
Systems (1)†
n Reliability ‒ the system does what it is supposed to do
n Each requirement can be traced to its implementing code and
verification that code can be traced to requirements
n Why is this code here?
n Where in the code are the requirements implemented?
n Bi‒Directional trace ensures coverage of requirements in the code and
coverage of the code in the Requirements
n No missing functionality
n Safety ‒ the system does not do what it is not supposed to do
n The system creates no hazards
n Each piece of code can be traced back to a requirement
n Each requirement can be traced to pieces of code
n No additional functionality is present in the code base ‒ no dead code
n This requires strict configuration management and quality assurance
6
† Sommerville, Software Engineering, 10 ed., Chapter 11

+ Considerations for Embedded
Systems (2)†
n Availability ‒ at a point in time, system will be operational and
deliver requested service
n Expressed as a percentage of the time the system is available
n Does not consider
n Number of user impacted
n Length of the outage
n Fault Tolerance ‒ the system can continue in an operational state in
the presence of a software fault
n Even if the system has been proved to conform to its specification, it must
tolerate faults ‒ internal and external ‒ to remain safe and operational in
some form
7

+
n Limit visibility of information
n Only allow access to data needed
for implementation
n Accidental corruption of parts of
the software is impossible
n Check all inputs for validity
n Always check inputs before
processing against assumptions
made about the inputs
n Provide handlers for all
exceptions
n Use control constructs to detect
exception means additional code
n This may introduce other errors
Programming for Reliability
Considerations for Embedded
Systems (3)†
8
n Minimize use of error‒prone
constructs
n Program faults usually the
consequence of human error
n Avoid or minimize use of error‒prone
constructs
n Provide restart capabilities
n Restart after failure without user
having to redo anything
n Check array bounds
n Avoid bounded buffer vulnerability
n Include timeouts
n Include timeouts on all calls to
external components

+ Connecting all the Parts Produces
a Trusted system
9

+
n Fault Avoidance
n Development techniques used to minimize possibility of mistakes or trap
those mistakes before they introduce system faults.
n Fault Detection and Removal
n Verification and validation to increase the probability of detecting and
correcting errors before the system goes into service are used.
n Fault Tolerance
n Runtime techniques to ensure system faults do not result in system errors
and/or system errors do not lead to system failures.
Fault Management strategies for Embedded Systems
Considerations for Embedded
Systems
10

+
Levels of Safety Criticality
11
Level Anomalous Behavior
A Catastrophic failure condition
B Hazardous or severe‒major failure condition
C Major failure condition
D Minor failure condition
E
No effect on operational capability of the system or
operator workload

+
The Big Picture Terminology
n Human Error or mistake ‒ human behavior that results in introduction of
faults into the system
n System fault ‒ a characteristic of a software system that can lead to a
system error
n System error ‒ an erroneous system state that leads to unexpected
system behavior
n System failure ‒ an event that occurs when the system does not deliver
the expected service
n Fault management ‒ strategies to achieve reliability
n Avoidance – minimize or trap mistakes before they introduce faults
n Detection and removal ‒ increase probability of detecting and corrected
errors
n Tolerance ‒ run‒time techniques to ensure system faults do not result in
errors and lead to system failure
12

+
Reliability Requirements
n Functional reliability defines the system and software functions
needed to avoid, detect, or tolerate faults in the software the ensure
faults don’t lead to failure
n Measurable system attribute so non‒functional reliability
requirements can be specified quantitatively
n The number of failures that can be accepted during normal use
n Reliability Metrics
n Probability of Failure on Demand ‒ probability the system will fail when
called upon to provide a service.
n Useful when service requests are infrequent
n Rate of Occurrence of Failures ‒ the inverse of MTTF.
n Useful when large number of service request required in short period
of time
n Availability ‒ the fraction of time the system is available for use
13

+
Elements of Fault Tolerance
n Masking ‒ Dynamic correction of generated errors.
n Detection ‒ Detection of an error - a symptom of a fault.
n Containment ‒ Prevention of error propagation across defined
boundaries.
n Diagnosis ‒ Identification of the faulty module responsible for a
detected error.
n Repair and Reconfiguration ‒ Elimination or replacement of a
faulty component, or a mechanism for bypassing it.
n Recovery ‒ Correction of the system to a state acceptable for
continued operation.
14

Whatever can go wrong will go wrong at the worst
possible time and in the worst possible way.
– Murphy
System Type Unavailability in Minutes/Year Availability Class
Unmanaged 52560 90% 1
Managed 5256 99% 2
Well‒Managed 526 99.9% 3
Fault‒Tolerant 53 99.99% 4
High‒Availability 5 99.999% 5
Very‒High‒Availability 0.5 99.9999% 6
Ultra‒Availability 0.05 99.99999% 7

+ Overview of Fault‒Tolerant
Multi‒Processor Architecture
16
Two processors ‒ Master and Checker
execute the same code synchronized
Master has access to memory and drives
outputs
Checker executes instructions fetched
by Master.
Outputs of Checker feed compare logic
for consistency of data, address and
control lines
Any disagreements reveal presence of a
fault
Lock‒Step Dual Processor Loosely‒Synchronized Dual
Processor
Tasks executed by both processors.
Both processors responsible for
check their own consistency.
A mismatch indicates a fault and
prevents outputs from being
committed.
When mismatch appears, a
predefined sanity‒check or other
self‒testing used on both
processors to identify faulty
component
Triple Modular Redundancy
Three identical processors execute the
same code in lock-step and a majority
vote of outputs masks a single processor
failure.
Inputs and Outputs are voted as well.

Embedded Systems are Everywhere

The Modern Vehicle: A System of
Systems

+
Automotive Systems ‒ ISO 26262
n The generic functional safety
standard for electrical and
electronic (E/E) systems.
n Specifies a functional safety
life‒cycle for automotive
products.
n Provides automotive specific
risk‒based approach for
determining risk classes (ASIL)
n Applies to all activities during the
safety lifecycle of safety related
systems comprised of electrical,
electronic, and software
components
19
ISO
26262
ADAS
Electronic
Stability
Control
Active
Systems
By‒Wire
Systems
Passive
Systems

+
Key Components of ISO 26262
n Provides an automotive safety lifecycle (management, development,
production, operation, service, decommissioning) and supports
tailoring the necessary activities during these lifecycle phases.
n Provides an automotive specific risk-based approach for
determining risk classes (Automotive Safety Integrity Levels, ASILs).
n Uses ASILs for specifying the item's necessary safety requirements
for achieving an acceptable residual risk.
n Provides requirements for validation and confirmation measures to
ensure a sufficient and acceptable level of safety being achieved.
20

+
ISO 26262 Terms
21
Safety
Absence of
unreasonable risk
Unreasonable Risk
Risk judged to be unacceptable in a certain
context according to valid societal moral concepts
Risk
Combination of the probability
of occurrence of harm and
severity of that Harm
Severity
Estimate of the extent of harm
to one or more individual that
can occur in a potentially
hazardous situation
Exposure
State of being in an operational
situation that can be hazardous in
coincident with the failure mode under
analysis
Harm
Physical injury or damage to
the health of persons
Controllability
Ability to avoid a specified harm or
damage through the timely reactions
of the persons involved, possibly with
support from external measures

+ ISO 26262
Automotive Safety Integrity Level
22
Exposure
Control
Ability
Severity ASIL+ + =

+ ISO 26262 Qualification of
Hardware Components
n Show how the hardware fits into the overall system.
n Assess failure modes.
n Basic hardware components can be qualified with standard
qualification, but more complex parts require evaluation through
ASIL decomposition and testing.
n Hardware components are typically qualified by testing the part in a
variety of environmental and operational conditions.
n Test results are analyzed with numerical methods and presented in
a qualification report along with the testing procedure, assumptions,
and input criteria.
23

+ ISO 26262 Quantification of
Software Components
n Define functional requirements.
n Resource usage.
n Predicting software behavior in failure and overload situations.
n To qualify a software component, a testing standard is used to test
under normal operating conditions along with inserted faults to
determine system reaction to abnormal inputs.
n Software errors like runtime and data errors are analyzed and
addressed throughout the design process.
24

+
ISO 26262 Test Qualification
n Safety-critical systems must react properly to test scenarios and stay
within specified safety limits when exposed to human and
environmental inputs.
n ISO 26262 recognizes using widely accepted software tools
simplifies or automates activities and tasks required for the
development of electrical, electronic, and software elements that
provide safety-related functions.
n The Tool Confidence Level and ACIL determine the level of
qualification required for the software tool
25
Analyze Risk
Early
Establish
Safety
Requirements
Fulfill
Requirements
Through Test

+ ISO 26262 Requirements at
Software Level
n Software safety requirements are derived from the technical safety
concept and the system architectural design specification (inherit
the ASIL)
n Software architectural design suitable to satisfy the software safety
requirements with their respective ASILs
n Software architectural design supports the implementation and
verification of the software being developed.
n Software unit design
n Implementation and verification
n Software integration and verification
n Testing of the resulting embedded software.
26

+ ISO 26262 Integration,Testing, and
Validation
n Validation of safety goals applied to the item integrated at the
vehicle level.
n Validation plan includes test procedures for each safety goal with
pass / fail criteria.
27
Item Integration and
Testing
Vehicle Integration
and Testing
System Integration and
Testing
Hardware‒Software
Integration and Testing

Automobiles requires fuel to run, making that fuel
requires electric power.
Electric power requires control systems

Tricon Safety Instrumented System (SIL3)†
A triple modular redundant programmable controller for
process control and emergency shutdown.
† I was Director Software
Development at Triconex
during the Startup period,
where we invented a real‒time
operating system, the
diagnostics to assure proper
functioning of all hardware and
software.
The Tricon is a
high‒availability,
high‒integrity
systems used in
safety critical
environments
certified to TÜV
Rhineland Safety
Integrity Level 3
§ Turbo Machinery
§ Exothermic
reactors
§ Off shore platforms
§ Nuclear power
feedwater and
safety applications

+ Safety Critical Programmable
Control
n Mean Time Between Failure of up to 100 years.
n 99.999% availability performance as designed.
n 12 microprocessors (main CPU), three primary communications paths,
and intelligent I/O with onboard diagnostics and triple redundant
voting logic for digital and analog IN’s and OUT’s.
n Patented bus synchronization ensures main processors function always
in sync.
n Fault detection, correction, and recovery integrated into every element
of the architecture.
n The controller eliminates hard and soft errors.
n Three independent outputs voted so only the same fault occurring on
two pathways at the same time can cause an error.
30
The Probability of this occurring is essentially NIL

+
Simplified Tricon Architecture
31
TMR employs three isolated, parallel control systems and extensive diagnostics
integrated into one system.
The Tricon system uses two out‒of‒three voting to provide high‒integrity, error‒free,
uninterrupted process operation with no single point of failure.

+
Main Processor(s) Architecture
32

+
TMR Input Module
33

+
TMR Output Module
34

+ Appling Embedded Safety Systems to Feed
Water Control of Nuclear Power Station
35

+
Hands On Example
Using the embedded systems for the BMW, let’s identify the
different approaches to building embedded software systems

For each embedded system, identify the fault handling class
§ Error Reporting
§ Fault Detection
§ Fault Tolerance
§ Fail Safe

Embedded Systems in a Typical Modern Automobile
Transmission
Control Unit
Engine Control
Unit
OBD-II
CAN/FlexRay Buses
In-Vehicle Infotainment Unit
Audio System
Navigation System
Telematics Control Unit
Cellular Modem
Main BoardInfotainment System
Traffic Info
Microphone,
Speakers, Mute
Specialized Inputs from
Airbag Status, Ignition
Status, etc.
GPS
Satellite Radio
Satellite
Driver’s Phone
Bluetooth
Cellular Antenna
GPS Antenna
USB Drive
Gateway
Alarm ControlBody Control Units Door Control
Adv. Driver
Assistance Sys
TSP
TSP
MOST Bus
LIN Buses
Tire Pressure
Monitoring System
Common Automotive Busses:
§ CAN - Control Area Network
§ LIN - Local Interconnect Network
§ MOST- Media Oriented System Transport
§ FlexRay - Fault-tolerant, deterministic bus
§ Ethernet
MOST Bus
Antilock
Brake System

Integrated Safety and Security Engineering for Mission Critical Systems
https://resources.sei.cmu.edu/asset_files/Poster/2018_020_001_528963.pdf

+
Exercise 1
n Classify each
system/component
according to
n Error Reporting
n Fault Detection
n Fault Tolerant
n Fail-Safe
n Brief explanation
why
40
Transmission
Control Unit
Engine
Control Unit
OBD-II
CAN/FlexRay Buses
In-Vehicle Infotainment Unit
Audio System
Navigation
System
Telematics Control Unit
Cellular Modem
Main Board
Infotainment
System
Traffic Info
Microphone,
Speakers, Mute
Specialized Inputs
from Airbag Status,
Ignition Status, etc.
GPS
Satellite Radio
Satellite
Driver’s Phone
Bluetooth
Cellular Antenna
GPS Antenna
USB Drive
Gatewa
y
Alarm
Control
Body Control
Units
Door Control
Adv. Driver
Assistance Sys
TSP
TSP
MOST Bus
LIN Buses
Tire Pressure
Monitoring
System
Common Automotive Busses:
§ CAN - Control Area Network
§ LIN - Local Interconnect Network
§ MOST- Media Oriented System
Transport
§ FlexRay - Fault-tolerant,
deterministic bus
§ Ethernet
MOST Bus
Antilock
Brake System
n What fault tolerant processor architecture, if any, would you use for
A) Gateway
B) Telematics Control Main Board
C) Engine Control
C) Interior Lighting Control

+
Exercise 2
n Given a new regulatory mandate that “collisions” must be report via
telematics to PSAP – Public Safety Answering Point (911)
n Classify each system/component according to:
n Error Reporting
n Fault Detection
n Fault Tolerant
n Fail-Safe
n Brief explanation why
41

+
n Engineering a SaferWorld, Nancy G. Leveson,The MIT Press, 2011.
n Embedded Systems Architecture, Daniele Lacamera, Packt Publishing, 2018.
n Making Embedded Systems, Elecia White, O’Reilly, 2011.
n Safeware: System Safety and Computers: Guide to Preventing Accidents and Losses
Caused by Technology, Nancy G. Leveson, Addison‒Wesley Professional, 1995.
n “A Classification System for Industrial Control Systems with Safety Functions and Its
Consequential Requirements,” K. Meffet, IFAC Industrial Process Control.
n “Certification of Safety‒Critical Software Under DO‒178C and DO‒278A,” Stephen A.
Jacklin, NASA Ames Research Center, American Institute of Aeronautics and Astronautics,
June 19, 2012.
n “Fault‒Tolerant Platforms for Automotive Safety‒Critical Applications,” M. Baleani, A.
Ferrari, L. Mangeruce, A. Sangiovanni‒Vincentelli, Maurizo Peri, and Saverio Pezzini,
CASE ’03.
Knowledge is of two kinds. We know a subject ourselves, or we know where we can find information upon it.
When we enquire into any subject, the first thing we have to do is to know what books have treated of it.
This leads us to look at catalogues, and at the backs of books in libraries.” — Samuel Johnson
Bibliography
42

+
Bibliography
n “A Model‒Based Agile Process for DO‒178C Certification,” David J. Coe and
Jeffery H. Kulick, 2013.
n “Advanced Research Integrated Avionic (ARIA) Systems for Fault‒Tolerant
Flight Research,” Jason Gross, Brad Seanor, Srikanth, Marcello R. Naplitano, AIAA
Guidance,Navigation,and Control Conference, 10‒13 August 2009.
n “Introduction to Fault‒Tolerant Systems,” Kjetil Nǿrvåg, Norwegian University of
Science and Technology, July 2000.
n An Introduction to Functional Safety and IEC 61508:Application Note, AN9025‒3,
March 2002.
n “Architectural Principles of Safety‒Critical Real‒Time Systems,” Jaynarayan H.
Lala and Richard E. Harper, Proceedings of the IEEE,Vol. 82, No. 1, January 1994.
n “Overview of the 2nd Edition of ISO 26262: Functional Safety‒Road Vehicles,”
Rami Debouk, GM Research and Development, August 16th, 2018.
43

+
Bibliography
n “Fault‒Tolerant Computing: Fundamental Concepts,”V. P. Nelson,
IEEE Computer, July 1990, pp. 19‒25.
n “Instrumentation and Controls in Nuclear Power Plants: An
Emerging Technologies Update,” Kofi Korsah, David Holcomb, Andy
Loebi, and Miljko Bobrek, NUREG/CR‒6992.
n “5 Essential techniques for Building Fault‒Tolerant Systems,” Diego
Berruete, Engineering Principle, Atlassian,
https://www.atlassian.com/atlascamp/2017/archives/best-
practices/5-essential-techniques-for-building-fault-tolerant-systems
n “Taxonomy of Safety‒Related Requirements,” Donald Firesmith,
Software Engineering Institute, 2004 and other papers at …
https://resources.sei.cmu.edu/library/results.cfm#stq=safety%20re
lated%20systems&stp=1
44

+
Bibliography
n “Integrated Safety and Security Engineering for Mission Critical
Systems,” Peter H. Feiler and Samuel Procter, Research Review,
Software Engineering Institute, October 2018
n “Bibliographical review on reconfigurable fault-tolerant control
systems,”Youmin Zhang and Jin Jiang, Annual Reviews in Control, 32,
pp. 229‒252, 2008.
n “SMOF - A Safety MOnitoring Framework for Autonomous Systems,”
Mathilde Machin, Jeremie Guiochet, Helene Waeselynck, Jean-Paul
Blanquart, Matthieu Roy, and Lola Masson, IEEE Transactions on
System, Man, and Cybernetics Systems, 48, 2018.
n “Application‒Level Fault Tolerance in Real‒Time Embedded
Systems,” Francisco Afonso, Carlos
45

Safe, Reliable, Available, High‒Integrity, and Fault Tolerant Embedded Software Systems

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Safe, Reliable, Available, High‒Integrity, and Fault Tolerant Embedded Software Systems

Similaire à Safe, Reliable, Available, High‒Integrity, and Fault Tolerant Embedded Software Systems (20)

Plus de Glen Alleman

Plus de Glen Alleman (20)

Dernier

Dernier (20)

Safe, Reliable, Available, High‒Integrity, and Fault Tolerant Embedded Software Systems