MISRA C++:2008 &Safely Embedded Software
(SES)
Jürgen MottokRegensburg University of Applied SciencesFakultät Elektro- und Informationstechnik
Frank SchillerTechnical University Munich
Institute of Information Technology in Mechanical Engineering
19th November 2008
An accident trajectory passing through corresponding holes in the layers of defense
The holes can be created (at run time) by active or latent failures.
NormalFunction
modified from J.Reason, Managing the Risk of Organisation Accidents
Fail Safeor Fault Tolerance
Safety Executive Multiple independend
layers of defense(Fault detection, Error reaction, …)
CatastrophicSystem Event
SubsystemFailure
Reason’s ‘swiss cheese’ model
Der Begriff Sicherheit
Sicherheit ein Innovationsfaktor für Automotive IT-SystemeStimmt, aber der Begriff Sicherheit ist in der Informatik vielschichtig.
1. Funktionale Sicherheit (Safety)Übereinstimmung zwischen Ist-Funktionalität der Komponenten mit der spezifizierten Soll-Funktionalität
keine funktional unzulässigen Zustände
Beherrschung systematischer und zufälliger Fehler
2. Informationssicherheit (Security)Annahme von Systemzuständen, die zu keinem unautorisiertenInformationsveränderung oder -gewinnung führen
3. Datensicherheit (Protection)Annahme von Systemzuständen, die zu keinem unautorisierten Zugriff auf Systemresourcen und insbesondere auf Daten führen.
Datensicherung (engl. Backup), Schutz vor Datenverlusten
4. Datenschutz (Privacy)Bundesdatenschutzgesetz (BDSG): Die Fähigkeit einer Person, die Weitergabe von Informationen, die sie persönlich betreffen, zu kontrollieren.
informationelle Selbstbestimmungsrecht
ForschungsprojektFHprofUnd2006 FKZ1752X07
Thema: Dynamische SW-Architekturen in Steuergeräten inFahrzeugsystemen unter Berücksichtigung von Anforderungen zur Funktionalen Sicherheit
Projektleiter: Hochschule Regensburg, Fakultät EI, Prof. Dr. Jürgen Mottok
Industrie Partner: Continental Automotive AG, GmbH
Universität: TU München, Prof Dr. Frank Schiller
Projektträger: Arbeitsgemeinschaft industrieller Forschungsvereinigungen"Otto von Guericke" e.V. (AiF) im Auftrag des BMBF
Zeitraum: 2006 bis November 2010
Volumen: 260 T€Mitarbeiter: 2 MA an der Hochschule Regensburg
mit kooperativer Promotion
Das Konzept „Safely Embedded Software“- wurde zur Konferenz SAFECOMP 2007 bereits vorgestellt:
Jürgen Mottok, Frank Schiller, Thomas Zeitler, Thomas Völkl,A Concept for a Safe Realization of a State Machine in Embedded Automotive Applications,SAFECOMP 2007
ForschungsprojektFHprofUnd2006 FKZ1752X07
Incident Primary Cause by Phase
Defect Density
KSLOC: Kilo-SLOC (Thousand Source/Software Lines of Code)Source: S. Montgomery, The Role of MISRA C in Developing Automotive Software, Ricardo UK
Coding StandardNormative Regulation of IEC 61508
Technique/Measure Ref SIL1 SIL2 SIL3 SIL4
1 Use of coding standard C.2.6.2 HR HR HR HR
2 No dynamic objects C.2.6.3 R HR HR HR
3a No dynamic variables C.2.6.3 --- R HR HR
3b Online checking of the installation of dynamic variables
C.2.6.4 --- R HR HR
4 Limited use of interrupts C.2.6.5 R R HR HR
5 Limited use of pointers C.2.6.6 --- R HR HR
6 Limited use of recursion C.2.6.7 --- R HR HR
7 No unconditional jumps in programs in higher level languages
C.2.6.2 R HR HR HR
a) Measures 2 and 3a do not need to be applied if a compiler is used (1) which ensures that sufficient memory for all dynamic variables and objects will be allocated before runtime, or (2) which inserts runtime checks for the correct online allocation of memory.b) Appropriate techniques/measures shall be selected according to the safety integrity level.
Table B.1 — Design and coding standards (referenced by table A.4) from IEC 61508-3
ISO/IEC 9899:1999: Programming Languages - C.International Organization for Standardization, 1999. with definitive list of C language insecurities.
Motor Industry Software Reliability Association:
A collaboration between vehicle manufacturers, component suppliers and engineering consultancies of Great Britain
MISRA-C: 1998[1]: first published April 1998, NuneatonMISRA-C: 2004[2]: published October 2004, Nuneaton
MISRA, Development Guidelines for Vehicle Based Software [6], November 1994, Nuneaton
…See also: http://www.misra.org.uk/
Historyof MISRA C: Safer C
Software lifecycle, How to achieve a certain MISRA (S)IL?
MISRA, Development Guidelines for Vehicle Based Software [6]
MISRA-C
Software lifecycle, How to achieve a certain MISRA (S)IL?
MISRA, Development Guidelines for Vehicle Based Software [6]
• 198 insecurities of C++ collected in:Hill, M.B., Whiting, E.V.: An Investigation of the Unpredictable Features of the C++ Language. QINETIQ/KI/TIM/TR043014, QinetiQ, May 2004.
• Common programming errors associated with C++ collected in:• Meyers, S.: Effective C++• Meyers, S.: More Eective C++• Dewhurst, S.C.: C++ Gotchas
• Industrial practice in:• Programming Research Limited: High Integrity C++ Coding
Standard Manual, Version 2.2, 2004• Lockheed Martin Corporation: Joint Strike Fighter Air Vehicle C++.
Coding Standard, 2RDU00001 Rev C, 2005• LDRA: LDRA Programming Standard. 2005
Historyof MISRA C++
Milestones
• 2005: C++ Workgroup was established
• 2007: Summer/Review of MISRA C++
• 2008: MISRA C++ was published on 5 June 2008and launched at the Safety-Critical Systems Club Tools Event in London
Historyof MISRA C++
1. Unspecified Behavior (31 occurences)The criteria Order of Evaluation is an example.
2. Undefined Behavior (81 occurences)Examples are invalid escape sequences or attemting to modify a string literal.
3. Implementation-Defined Behavior (62 occurences)An example is the behavior of the integer division and remainderoperators / and % when applied to one positive and one negative number.
4. Indeterminate Behavior (5 occurences)This is similar to Undefined Behavior, but there the C++ Standard omitsan explicit definition of behavior.
5. Behavior That Requires No Diagnostics (19 occurences)These are issues that may be detected by a compiler, but it is explicitly stated there is norequirement to generate a diagnostic message for them.
Insecurities of the C++ programming language
MISRA C++Compliance Matrix
In order to ensure that all the rules have been covered a compliance matrix
Should be produced.
MISRA
Rule No.
Compiler 1 Compiler 2 Checking Tool 1 Checking Tool 2 Manual Review
0-1-1 Warning 347
0-1-2 Error 25
0-1-3 Message 28
0-1-4 Warning 97
0-1-5 Proc x, y
MISRA C++Compliance Matrix
Example compliance matrix with mapping of
company C++ coding guidelines and MISRA rules
company
C++ coding
guidelines
MISRA
Rule No.
Compiler 1 Compiler 2 Checking Tool 1
Checking Tool 2
Manual Review
A1 0-1-1 Warning 347
A2 0-1-2 Error 25
B1 0-1-3 Message 28
B2 0-1-4 Warning 97
C1 0-1-5 Proc x, y
MISRA C++Deviation procedure
The use of a deviation must be justified on the basis of both necessity and safety.
The deviation procedure should be part of a formal quality management.
Two categories of deviations:
• Project deviation:
• a permitted relaxation of rule requirements to be applied in specific circumstances
• should be reviewed as part of formal deviation process
• Specific deviation
• A specific instance of a rule violation in a single file
• Will be reviewed in the development process
• Deviation procedure should not be used to undermine the MISRA-C++ intention!
MISRA C++Deviation procedure
Elements Project
Deviation
Request
Specific
Deviation
Request
Details of the deviation, i.e. the rule that is beeing violated.
X X
Circumstances in which the need
for the deviation arises.
X
Potential consequences which may result from the deviations.
X X
Justification for the deviations. X X
A demonstration of how safety is
assured.
X X
Rule pattern used for MISRA C++rule description
Item Meaning
Rule Number Unique Identier
Rule Category Required, a rule that requires a formal deviation if it is not followedAdvisory, a rule for which a deviation is optional if it is not followedDocument, a rule that requires supporting documentationto be produced and that may not be derived
Headline Text The actual rule
Issue reference An optional list of references to the C++ standard
Rationale A justication of the rule
Exception An optional entry that lists any permitted exceptions to the rule
Example A code fragment showing non-compliant code and,if appropriate, an example of how the same eectcan be achieved in a compliant manner.
See Also An optional entry containing cross-referencesto other (related) rules or documents
MISRA C++Coding standard philosophy
Preferences for C++ Idioms
Constants instead of MACROs
Inline Functions instead of Function MACROs
C++ Casts instead of C style Casts
C++ Containers instead of C style arrays
…
MISRA C++Macros
MISRA C++Exception Handling
MISRA C++Exception Handling
MISRA C++Exception Handling
MISRA C++Template Constructor
MISRA C++Use of goto’s (forward jumps)
Programming Language Driven Architecture Driven
Avoidance of• unspecified behavior• undefined behavior• implementation-defined behavior
Common Programming Errors
Non-functional requirementse.g. Safety, …
Diversity Implementation rules
C++ Safety Coding Guideline
MISRA 2008 C++as a restricted C++ subset
Safely Embedded Software (SES) approach for C++
⇒ Control of Systematic Faults
Factors for deriving aC++ Safety Coding Guideline
⇒ Control of Random Faults
The origins and goals of Safely Embedded Software
Idee einer HW-Lösung: Matra Transport, Frankreich Veröffentlichung über Software Vital Coded Processor
Entworfen für Pariser U-Bahn (Metro A line)
Benutzt noch zusätzlich Hardware-Redundanz
Codierung und Decodierung in Hardware
Ziel: Safely Embedded Software
Codierte Verarbeitung in der Hochsprache C
Verwenden von Standard-Komponenten
k(l)eine Hardware-Redundanz
Absichern von Zustandsautomaten mit den Zielen:
Erkennen von permanenten Fehlern (Fehler ALU)
Erkennen von temporären Fehlern (Bitkipper)
Umsetzung in Applikations-Layer (unabhängige Zertifizierung!)
Anwendung auf SIL-3 Automotive Funktionen
MotivationSafely Embedded Software
Sensoren
Aktuatoren
Daten-kommunikation
Daten-kommunikation
Daten-speicherung
Daten-verarbeitung
Programmierung reaktiver Systeme und Fehlererkennung
1. Fehlererkennung
2. Fehlererauswertungmit Wissensbasis
3. Fehlerreaktion
FMEAFTA
Systemwissen aus der Designzeit!zufällige oder systematische Fehler
Fehlerdiskussion am Modellder Befehlsebene
Ein-Fehler-Kriterium: Versagen einer einzigen Einrichtung darf nicht zumTod von Menschen führen.
Erfüllung z.B. durch Verwendung mehrerer diversitärer Hardware- und/oder Software-Kanäle
Diversitäre Programme
1. Funktionale Diversität2. Diversitäts der Beschreibungssprachen3. Entwurfs-Diversität
4. Diversitäre Datenstrukturen5. Algorithmische Diversität
6. Diversität der Programmiersprachen
7. Produktionsdiversität8. Diversität der Personen9. Kommunikationsdiversität10. Diversität der Ausbildung
Diversität in der Spezifikations-und Entwicklungsphase
„Zoo“ der Diversitätsarten (1/2)
11. Datendiversität12. Zeitdiversität
13. Wirkungsdiversität
14. Richtungsdiversität15. Voterdiversität
16. Compilerdiversität17. Betriebssystemdiversität18. Hardwarediversität19. Werkzeugdiversität20. Bibliotheksdiversität
Diversität in den Eingaben
Diversität in den Auswirkungen
Diversität in der Entwicklungs-und Betriebsumgebung
Diversität in der Auswahl
• N-Version Programming nutzt verschiedene Diversitätsarten.• Vermeidung von Common Cause Failures (Ausfälle gemeinsamer Ursachen
in verschiedenen zueinander redundanden „Kanälen“).
„Zoo“ der Diversitätsarten (2/2)
Basic-Software
COM-IF
S-IF
COM-IF
S-IF
Standardisierte Middleware
Applikations-Modul
(SK-F, SR-F)
COM-IF
Applikations-ModulN-SR
Safety SupervisorKoordinierungsebene
Hardware
App
likat
ions
-Ebe
neU
nter
lage
rte
Ebe
nen
Architektur mit Sicherheitskritischer/-relevanter Applikationssoftware und Safety Supervisor
Quelle: Blum, Duckstein, Hummel, Mattes, Mottok, Schiller, Forschungsprojekt mobilSoft, TP4 Safety, 2006
Safely Embedded Software (SES)Safety Code Weaving
OP1 OP2 OPn
codedOP1
codedOP2
codedOPn
OP1, 2, .., n
coded
OP1, 2, .., n
Control flow
Mixture strategies:
Transformation und Operatoren
Transformation einer Variablen
xc := xf * A + Bx + D
Daten: bisher Datentypen integer, bool
Codierte Operatoren (Bibliothek erstellt)
Addition +, Subtraktion -, Multiplikation *, Division /,
größer oder gleich Null >=0, größer Null >0,
gleich Null ==0,
logisches NOT !, logisches UND &&, usw.
Kontrollstrukturen
Analyse von Transformationsfaktoren
Codierte Addition +
u(a) / a umod b /größer gleich null Operator
unsigned-Funktion: a -> 2er Kompl. -> a1a2…an -> Binärcode -> u(a)
unsigned-modulo-Funktion:
a umod b := u(a) mod b
größer gleich null Operator:
Absichern einer if-Anweisung
tmpf = ( xf >= 0);
if ( xf >= 0 )if ( tmpf )
{
xf = 5; xc = 5*A + Bx + D;
tmpc = geqz_c( xc );
if ( cf != 152 ) { ERROR }
cf = 152; /* check flag */
cf = 153; /* check flag */
if ( tmpc – TRUE_C ) { ERROR }
af = 4; ac = 4*A + Ba + D;if ( cf != 153 ) { ERROR }
}else
{cf = 154; /* check flag */
if ( tmpc – FALSE_C ) { ERROR }af = 10; ac = 10*A + Ba + D;if ( cf != 154 ) { ERROR }
}
4. Schritt: Globales PFM
1. Schritt: Prüfung vorziehen (Übersicht)
3. Schritt: Lokales PFM
2. Schritt: Operationen für Bildraum
Safe Integer Datatype Template Class
template <class DataType>class SafeIntDataType{private:
DataType origValue;int32_t codedValue;const int32_t A;int32_t B, D;
public:SafeIntDataType(const DataType & A);SafeIntDataType(const DataType & A, const DataType & i);
SafeIntDataType<DataType> & operator=(const DataType & i);
void UpdateWithDynamicSignature(const DataType & D);
SafeIntDataType<DataType> & operator+=(const SafeIntDataType<DataType> & i);
friend SafeIntDataType<DataType> operator+(const SafeIntDataType<DataType> & i1,
const SafeIntDataType<DataType> & i2);bool Check();...
};
Safe Integer Datatype Template Class
template <class DataType>SafeIntDataType<DataType>::SafeIntDataType
(const DataType & A, const DataType & i):A(A){
D=1;origValue=i;B= (int32_t) &origValue;codedValue=A*i+B+D;return *this;
}
template <class DataType>SafeIntDataType<DataType> & SafeIntDataType<DataType>::operator+=
(const SafeIntDataType<DataType> & i){
origValue+=i.origValue;codedValue+=i.codedValue-i.B-D;return *this;
};
Safe Pointer Template Class
template <class DataType>class SafePointer{private:
DataType * pDataType;int32_t CodedPointerAdress;int32_t B, D;int32_t A;
public:SafePointer ();SafePointer (const int32_t & A);SafePointer (const int32_t & A, DataType * object);SafePointer & operator=(DataType * object);DataType * operator->() const;void SetDynamicSignature(const int32_t & D);void SetA(const int32_t A);bool Check() const;...
};
Safe PointerTemplate Class
template <class DataType>SafePointer<DataType>::SafePointer(const int32_t & A, DataType * object):A(A){
pDataType=object;B=(int32_t)&pDataType;CodedPointerAdress=A * (int32_t)pDataType+B+D;
}template <class DataType>DataType * SafePointer<DataType>::operator->()const{
try { if (!Check()) throw SafeException();}catch(...) { // ...
throw SafeException();}
return pDataType;}template <class DataType>SafePointer<DataType> & SafePointer<DataType>::operator=(DataType * object){
pDataType=object;B=(int32_t) &CodedPointerAdress;CodedPointerAdress=A * (int32_t) pDataType + B + D;return *this;
}
SafeAggregation
class Aggretand;...class Aggregat{private:
SafePointer<Aggretand> mySafePointer;public:
Aggregat(Aggretand * object){mySafePointer=object; //overloaded operator=() is used!};
...}
AggregatAggretand * pAggretand
Aggretant
1. Diverse Data2. Diverse Operation (Library for arithmetic, logical and boolean operators)
3. Update of the dynamic Signature
4. Local (logical) program flow monitoring(Safeguarding and Coding of C control structures)
5. Global (logical) program flow monitoring(General PFM-Coding, e.g. function calls)
6. Temporal program flow monitoring (Deadline Monitoring, Predictive Scheduling)
7. Comparator function8. Safety protocol (& Safety Interface)
9. Safe communication with a Safety Supervisor
The Nine Design Rules of SES
Transformation of a single software channnel to a coded dualsoftware channel could be performed by a future Safety Compiler.
Simplified Sensor Actuator State Machine
Architektur
Blackboard
Initialisierungsfunktion
Zyklische Funktion
Lokale Variablen
Input Management
Zustandsautomat
nested switch oder
tabellengesteuert
Output Management
(Testumgebung)
St = StateEv = EventAc = Action application statefault storage and timestamp
Blackboard (Managed global variables)
State Machine
implemented withnested switch or table driven
s1
s2
a1
a2
a3
a4
Sensors Actuators
cycle
INPUT
MANAGEMENT
OUTPUT
MANAGEMENT
Safety Supervisor
Vergleich nested switch/table driven (VC++)
0%
200%
400%
600%
800%
1000%
1200%
1400%
1600%
1800%ELOC(init)
ELOC(cycle)
SUM(ELOC)FILESIZE(binary)
RUNTIME
VC++, nested switch VC++, table driven
Generic SES-based Safety Architecture
Channel 1: Function
Channel 2: Transformed Function
Comparator
Reduced Processor Monitoring (e.g. Clock Watchdog)
Processing Unit (µC)
Function Monitoring with SES• reduction of fail safe techniques in Basic-Software
(remaining e.g. clock watchdog)• reduction of monitoring unit
(e.g. remainingclock watchdog, comparator)• comparison of both calculation channels
Reduced Monitoring Unit (MC)
Comparator
Reduced Processor Monitoring (e.g. Clock Watchdog)
Control flow
Safety Code Weaving
BasicSoftware
BasicSoftware
Programming Language Driven Architecture Driven
Avoidance of• unspecified behavior• undefined behavior• implementation-defined behavior
Common Programming Errors
Non-functional requirementse.g. Safety, …
Diversity Implementation rules
C++ Safety Coding Guideline
MISRA 2008 C++as a restricted C++ subset
Safely Embedded Software (SES) approach for C++
⇒ Control of Systematic Faults
Factors for deriving aC++ Safety Coding Guideline
⇒ Control of Random Faults
Herzlichen Dank für Ihre Aufmerksamkeit!
Fail-safe architectureE-Gas concept
SW Module
SW Module
SW Module
Function
Inve
r t
Inve
r t
Compare
Flag Flag Flag FlagProgram flow check
Function MonitoringSW
Module (copy)
SW Module (copy)
SW Module (copy)
Layer 1
Layer 2
Combine
OutputSignal
Validity
Cyclic ROM checkCyclic RAM check
Flag Flag
Monitoring Unit
Layer 3
Inhibit
FunctionController
(Host µC)
Monitoring Controller
(MC)
µC Check
Challenge ResponseALU check
InputSensorSignal
Output AktuatorSignal orCommunication Bus
Fail Safe
Fail passive(Fail silent) orFail active
Wirkungsdiversität:
Mehrere unabhängigeFehlerreaktionspfade(Abschaltpfade)
