Basics of advanced software systemsLecture 1 – introduction to the design of critical
systems
Nicolas Navet – [email protected] 24 Feb 2012
Module overview
o Lecturer: Nicolas Navet, [email protected]
o Lectures: Wed. 9h45-12h30 from week 8 to week 21 except
week 14 (on 06/04/2012)
o Grade: Weighted average of examination and practical works (2
TPs)
o Materials: (will be) available on internal moodle and is available
from http://www.loria.fr/~nnavetfrom http://www.loria.fr/~nnavet
o Objective: “introduction to dependability, formal methods, real-
time computing, Model Driven Development” to provide
1. Basics of the design of critical systems
2. Prepare corresponding Master courses
24/02/2012N. Navet - Basics of Advanced Software Systems - Université du Luxembourg - 2
Module structure and objectives
Principles of formal methods (21UE)
o Understand when formal
methods are appropriate and what
to expect from them
o Provide first practical experience
MDE withexecutable UML (3UE)
Real-time Computing (15UE)
o Understand network
and processor scheduling
issues
o Get to know RT
o Introduction to MDE:
PIM, PSM, etc
o What is xUMLwrt UML?
xUML vs fUML
3
o Provide first practical experience
in formal verification: modeling,
specification of properties,
verification and result analysis
o Give an insight (limited) into the
theory underlying formal methods
o Get to know industrial
applications of formal methods
and existing tools
o Get to know RT
software & hardware
technologies
o Design methods of
large and complex critical
embedded systems
o Illustration on
Automotive Embedded
Systems
xUML vs fUML
o Domain modeling and
action language
o UML modeling tools
capabilities wrt xUML
N. Navet - Basics of Advanced Software systems - Université du Luxembourg
Real-time computing
1. Overview of real-time operating systems : benefits,
features, standards, hypervisors
2. Task scheduling : static cyclic vs dynamic scheduling
(EDF/FPP), multiprocessor: global vs partitioned
3. Lab. work : Configuring a multi-core automotive ECU -
partitioned / FPP & static-cyclic scheduling
4. Basics of real-time distributed systems : priority
buses, switched Ethernet networks, time-triggered
architecture
24/02/2012N. Navet - Basics of Advanced Software systems - Université du Luxembourg - 4
Formal methods
1. Introduction: motivations, from semi-formal to formal
methods, current use in industry
2. Developing models : automaton, specification of
correctness properties
3. Verification Techniques : simulation, model checking,
schedulability analysis, theorem proving, etc
4. Focus : Promela Spin for the verification of concurrent
processes
5. Lab work: modeling & verification of an electronic purse
24/02/2012N. Navet - Basics of Advanced Software systems - Université du Luxembourg - 5
Introduction to the design of critical Introduction to the design of critical
systems
N. Navet - Basics of Advanced Software systems - Université du Luxembourg 24/02/2012 - 6
Outline for today
1. Critical systems, dependability vs security
2. Validation & verification and their means
3. Automotive Embedded Systems and threats to their
dependabilitydependability
4. Focus on timing constraints
5. Trends in the development of safety critical systems:
safety standards, technologies and MDD
24/02/2012N. Navet - Basics of Advanced Software systems - Université du Luxembourg - 7
Embedded systems in our day-to-day life : some of them are critical in the
sense they are subject to dependability constraints
8
Dependability vs Security [from Laprie et al, 3]
SecurityDependability
“ability to deliver
a service that
can justifiably be
trusted ”
“absence of unauthorized access to, or
handling of, system state”
“unauthorized”
system alteration
Availability Reliability Safety Confidentiality Integrity Maintenability
Readiness for
usage
Continuity of
service
Absence of
catastrophic
consequences
Absence of
unauthorized
disclosure of
information
Absence of
improper
system
alterations
Ability to
undergo repairs
and evolutions
Types of critical systems
1. Safety-critical : failure may endanger human life, ex:
automotive, aerospace, railway signalling
2. Security-critical : failure means non-authorized
access to sensitive information, ex: medical records,
electronic transactions, security databases
3. Business-critical (quality critical): cost of failure is 3. Business-critical (quality critical): cost of failure is
very high, ex: semiconductor, financial applications,
telecommunication
24/02/2012N. Navet - Basics of Advanced Software systems - Université du Luxembourg - 10
Some famous failures: bug in floating-point division hardware of the Intel’s Pentium
(1994), Ariane 5 self-destruction (1996 – number conversion problem), loss of Nasa’s
Mars Climate Orbiter (1999 – mixture of pounds and kilograms), see
http://www5.in.tum.de/~huckle/bugse.html for more
Validation, Verification & Certification
• Validation: “system/component satisfies specified
requirements”
• Verification: “products of a given development
phase satisfy conditions imposed at the start” (code
correct wrt specification – does not mean spec. is
correct)correct)
• Certification is “a written guarantee that a system or
component complies with its specified requirements
and is acceptable for operational use” → certification
processes and authorities are specific to a domain,
e.g. aviation, nuclear power-plants, railway, etc
24/02/2012N. Navet - Basics of Advanced Software systems - Université du Luxembourg - 11
(Some) means of verification and
validation
• Simulation : execute and monitor a model of the
system
• Formal methods : formal modeling + formal verification → proof of properties of the specification
and possibly proofs of correctness of implementation
• Risk analysis : identify hazards and their causes,
quantify probability of occurring, counter-measures, quantify probability of occurring, counter-measures,
etc
• Testing : execution of a number of test cases on a
prototype
• Static analysis of the code
• Fault-injection in hardware and software
24/02/2012N. Navet - Basics of Advanced Software systems - Université du Luxembourg - 12
Testing, static analysis and fault-injection cannot take place early in the design cycle
Methods complement each other – none alone is sufficient
Defects should be detected as early
as possible
• Cost of change (time + money) is much higher in the
late phases of the development cycle
Costs
of
change
Re
qu
irem
en
ts
De
sign
De
velo
pm
en
t
Testin
g
De
plo
ym
en
t
From Boehm
24/02/2012N. Navet - Basics of Advanced Software systems - Université du Luxembourg - 13
• Formal methods allow to reduce defects introduced
in the early phases and reduce testing efforts
afterwards
Time
change
Re
qu
irem
en
ts
De
sign
De
velo
pm
en
t
Testin
g
De
plo
ym
en
t
2
N. Navet - Basics of Advanced Software systems - Université du Luxembourg 24/02/2012 - 14
Automotive Embedded SystemsThreats to their dependability
2
Electronics is the driving force of innovation
in automotive
– 90% of new functions use software
– Electronics: 40% of total costs
Many new functions are safety critical:
brake assist, cruise control, lane keeping,
dynamic lights, etc
Picture from [10]
Strong costs and time-to-market constraints !
– Electronics: 40% of total costs
– Huge complexity: 70 ECUs, 2500 signals,
>6 comm. protocols, multi-layered run-time
environment (AUTOSAR), multi-source
software, multi-core CPUs, number of
variants, etc
BMW 7 Series networking architecture [11]
� ZGW = central
gateway
� 4 CAN buses
� 1 FlexRay Bus
� 1 MOST bus� 1 MOST bus
� Several LIN Buses
(not shown here)
� 1 Ethernet bus
� Wireless
Optimizing the use of resources is an
industrial requirement
Why ? • Complexity of the architectures
• Hardware costs / weight, space, consumption, etc
• Need for incremental design
• Industrial risk and time to master new technologies
• Performances (sometimes):
ex1: one 60% loaded CAN network may be more efficient ex1: one 60% loaded CAN network may be more efficient
that two 40% networks interconnected by a gateway
ex2: cost of communication in distributed functions
• Limits of current technologies (CPU frequency w/o fan)
Needed : configuration and verification algorithms
with performance guarantees
Main impediments to safety : complexity!
Technologies: numerous, complex and not
explicit. conceived for critical systems
– e.g.: more than 150 specification documents
(textual) for Autosar, no two implementations
can behave identically!
Size of the system!
– Number of functional domains, buses, gateways,
ECUs, size of code, tasks, wiring, number of
variants, etcAutosar Basic Software
variants, etc
Design process
– Most developments are not done in-house :
less control on externalized developments
– Carry-over / Vehicle Family Management : need to
share/re-use architecture and sub-systems between
several brands/models with different requirements [2]
– Optimized solutions for each component / function
does not lead to a global optimal [2]Wiring harness
Picture from [11]
3
N. Navet - Basics of Advanced Software systems - Université du Luxembourg 24/02/2012 - 19
Focus on the timing constraints
3
Several hundreds of timing constraints –
example of an end-to –end constraints
Constraint :
brake light on < 50ms
Stimulus Response
Figure from [12]
Verification of the timing constraintsPersonal view / experiences
« Worst-case » deterministic analysis
system level
« correctness by construct »
and optimal synthesis
Probabilistic performance & safety
assessment - system level
bursts of errors
Single transmission errors
Interarrival times
Mostly
ahead
of us!
Simulation tools (SBFI)
200919971995
« Smart » monitoring tools
« Worst-case » deterministic analysis (sub-system)
Probabilistic analysis (sub-system)
system level
COTS tools
Why timing constraints may not be
respected occasionally?
Lack of precise specification : hard to identify
the right timing requirements for each function
Lack of traceability : from the architects to the suppliers
Flaws in the verification:
– Knowledge of the system and its environment is incomplete:
• What is done by the suppliers?
• Implementation choices really matter and standards do
not say everything
MiddlewareComm.
task5ms
2
Waiting queue:
- FIFO
- Highest Priority not say everything
• Environmental issues: EMI, α-particles, heat, etc
• Traffic is not always well characterized and/or well modeled
e.g. aperiodic traffic ?! see [5]
– Testing /simulation alone is not enough
– Analysis is not enough too:
• Analytic models, especially complex ones, can be wrong
(remember “ CAN analysis refuted, revisited, etc” [6] ?!)
• They are often much simplified abstraction of reality
and might become optimistic: neglect FIFOs, hardware limitations
1
2 - Highest Priority
First
- OEM specific
CAN Controller
buffer Tx
CAN Bus
9 6 8
Illustration: Worst-Case Response Times on a CAN
bus - Frame waiting queues are HPF, except ECU1 where queue is
FIFO, the OEM does not know or verification software cannot
handle it
Analysis Setup:
- Typical body network with 15 ECUs
generated by NETCARbench
- WCRT computed with NETCAR-Analyzer
Many high-priority frames are delayed here because
a single ECU (out of 15) has a FIFO queue …
Evolution in the development of 4
N. Navet - Basics of Advanced Software systems - Université du Luxembourg 24/02/2012 - 24
Evolution in the development of
safety critical software - Safety standards
- Design process
- Technologies, computing platforms
4
Safety standards and certification processes
cannot be ignored
IEC61226
IEC60880
…
ISO 26262DO 178 / DO 254
EN 50126/28/29
Airbus: 1/3 of the design costs of an airplane due to certification !
ISO 26262DO 178 / DO 254
IEC 61508
ECSS / CNES
Model Based Design for dependable system development
no more hand-coded programs ?! Requirements
Design Verification
code generation
Scade
Simulation
Verification
DesignVerifyer State machine to C
certified transformation tool
C to binary
Compiler
Certification
Kit
End-to-end design flows with proven outcomes at each step
MBD: domain-specific models and tools
must be dealt with
requirements
sysML?
Some open issues: semantic interoperability,
pivotal language? local versus global verification
Technology : from domain specific to cross-
industry solutionsToday :
- Avionics: IEEE1553, AFDX, TTP, ARINC 653, ..
- Automotive: CAN, FlexRay, Autosar, Lin, ..
- Power plants: Alstom Alspa, Siemens Teleperm, ..
Tomorrow :
- Convergence of safety standards
[Thomesse05]
- Computing platforms: cross-industry solutionS with profile per
application domain and scalable dependability : e.g., switched
Ethernet, virtualization, etc
- Architecture patterns with specific dependability capabilities
Calcu lateur
N °1
Sw itch
Sw itch
Sw itch
Sw itch
Sw itch
Sw itch
Sw itch
Sw itch
Calcu lateur
N °i
What is needed now: achieving affordable
dependability
1. A large body of standards, development processes,
tools, and know-how is available for the design of
critical systems
2. Formal methods are now sufficiently mature to handle
industrial problems – needed: reduce the costs by industrial problems – needed: reduce the costs by
automatization & integration within standard
development environments
3. Simpler systems are more amenable to verification!
24/02/2012N. Navet - Basics of Advanced Software systems - Université du Luxembourg - 29
5
N. Navet - Basics of Advanced Software systems - Université du Luxembourg 24/02/2012 - 30
References
5
References [1] N. Navet, F. Simonot-Lion, editors, The Automotive Embedded Systems Handbook, Industrial Information Technology series, CRC Press / Taylor and Francis, ISBN 978-0849380266, December 2008.
[2] P. Wallin, Axelsson, A Case Study of Issues Related to Automotive E/E System Architecture Development, IEEE International Conference and Workshop on the Engineering of Computer Based Systems, 2008.
[3] A. Avizienis, J.C. Laprie, B. Randell, “Dependability and its threat: a taxonomy", IFIP Congress Topical Sessions 2004.
[4] A. Ireland, slides of the course “Distributed Systems Programming - formal Methods for Distributed Systems”, 2011. Available on the web
[5] D. Khan, N. Navet, B. Bavoux, J. Migge, “Aperiodic Traffic in Response Time Analyses with Adjustable Safety Level“, IEEE ETFA2009, Mallorca, Spain, September 22-26, 2009.
[6] R. Davis, A. Burn, R. Bril, and J. Lukkien, “Controller Area Network (CAN) schedulability analysis: Refuted, revisited and revised”, Real-Time Systems,
24/02/2012N. Navet - Basics of Advanced Software systems - Université du Luxembourg - 31
schedulability analysis: Refuted, revisited and revised”, Real-Time Systems, vol. 35, pp. 239–272, 2007.
[7] M. D. Natale, “Evaluating message transmission times in Controller Area Networks without buffer preemption”, in 8th Brazilian Workshop on Real-Time Systems, 2006.
[8] C. Braun, L. Havet, N. Navet, "NETCARBENCH: a benchmark for techniques and tools used in the design of automotive communication systems", Proc IFAC FeT 2007, Toulouse, France, November 7-9, 2007.
[10] P. Leteinturier, “Next Generation Powertrain Microcontrollers”, International Automotive Electronics Congress, November 2007.
[11] H. Kellerman, G. Nemeth, J. Kostelezky, K. Barbehön, F. El-Dwaik, L. Hochmuth, “BMW 7 Series architecture”, ATZextra, November 2008.
[12] AUTOSAR, “Specification of Timing Extensions”, Release 4.0 Rev 2, 2010.