STPASwiss
AComprehensiveSafetyEngineeringApproachforSoftwareIntensiveSystemsbasedonSTPA
AsimAbdulkhaleq
Stockholm, 17th March2016
4thScandinavianConferenceonSystem&SoftwareSafety
Motivation: Software of Today’s Complex Systemsu Today’s safetycritical systemsareincreasingly reliantonsoftware.
Ø Softwareisthemostcomplexpartofmodernsafetycriticalembedded systems.
Ø E.g.Amoderncarhassomething close100million lines ofsoftwarecode init,runningon70to100microprocessors.
Anti-LockBrakingSystems(ABS)
ElectronicStabilityControl
AdaptiveCruiseControl (ACC)
Stop&GoAdaptiveCruiseControl
TractionControlBackCamera
TirePressureMonitoring
ReverseBackupSensors
AutomaticBrakingSystems
ElectronicBrakeforce DistributionSystems
AutomaticBrakingSystems
2/26
Howtorecognizethesoftwarerisksinmodernsystemsandreducethemtoalowlevel?
Vehicle
Agenda
v Motivation
v ProblemStatement&ResearchObjectives
v Background
- SafetyAnalysisTechniques
- STAMPandSTPAApproach
v STPASwissApproach
v XSTAMPP:ToolsupportforSTPASwissApproach
v IllustrativeExample:AdaptiveCruiseControlSystem
v Conclusion&FutureWork
3/26
u Safetyisasystempropertyandneedstobeanalysed inasystemcontext.
Ø Therefore,softwaresafetymustbeconsidered inthecontextofthesystemleveltoensurethewholesystem’ssafety.
Software Safety Challenges
System
SoftwareInputDevices
OutputDevices
MonitoredVariables
InputDataItems
Output DataItems
ControlledVariables
SoftwareCriticalVariables
4/26
Verifythesoftwareagainst itssafetyrequirements
Identifyappropriatesoftwaresafetyrequirements
Ø SafetyAnalysisTechniques:• FTA,FMEA,STPA
Ø SoftwareVerificationapproaches:• Modelchecking(SMV,SPIN,.etc.)• Testingapproaches
Functionalcorrectnessofsoftware,however,evenperfectlycorrectsoftwarecancontributeinanaccident.NotdirectlyconcernsafetyTestallsoftwarebehavioursisimpossible
FTAandFMEAhavelimitationstocopewithcomplexsystems.STPAisdevelopedtocopewithcomplexsystems,butitssubjectissystemnotsoftware.
Research Objectives & Contributionu ResearchObjectives
Ø IntegrateSTPAsafetyactivities inasoftwareengineering processtoallowsafetyandsoftwareengineers aseamless safetyanalysisandverification.
Ø Thiswillhelpthemtoderivesoftwaresafetyrequirements, verifythem,generatesafety-basedtestcaseandexecute themtorecognizetheassociated softwarerisks.
5/26
u Contribution
• We contribute a safety engineering approach to
Ø derive software safety requirements at the system level
Ø transform them safety into formal specification in LTL/CTL
Ø verify them at the design and implementation levels and
Ø generate test cases from the information derived during STPA safety analysis.
• We develop a tool support called XSTAMPP to automate the proposedapproach.
6/26
Background: Safety Analysis Techniquesu Thereareover100different safetyanalysistechniques.
u Therearesome limitationswithtraditional safetyanalysis techniques:
q They assume that accidents are caused by component failures.
q They are not adequate to address new accidents caused by componentinteractions, human errors, management and organizational errors and softwareerrors [Leveson 2011].
7/26
Systems Approach to Safety Engineering(STAMP)STAMP (Systems-Theoretic Accident Model and Processes)is an accident causality model based on systems theory and systemsthinking
u Accidentsaremorethanachainofevents,theyinvolvecomplexdynamic processes.
u Treataccidentsasacontrolproblem, notafailureproblem.
u Preventaccidentsbyenforcingconstraints oncomponentbehaviour andinteractions.
u Capturesmorecausesofaccidents:
― Componentfailureaccidents
― Unsafeinteractionsamongcomponents
― Complexhuman,softwarebehaviour
― Designerrors
― Flawedrequirements
esp.software-relatedaccidents.
STAMPModel
Leveson (2003);Leveson (2011)
STPA Safety Analysis Techniqueu STPA(System-Theoretic ProcessAnalysis)
q Developed byProf.Leveson atMIT,USA,2004
q BuiltonSTAMPmodel basedonsystemandcontroltheoryratherthanreliability.
q Treatssafetyasdynamiccontrolproblemratherthanfailureproblem
Human/AutomatedController
Actuators Sensors
Controlled Process
ControlledVariables
MeasuredVariables
Process OutputsProcess Inputs
Disturbances
FeedbackVariables
ControlledVariables
Agenericcontrolloopofsystem8/26
MonitoredVariables
ProcessesModel
ControllerControl
Algorithm
FeedbackVariablesStarting
Point
STPA Approach Process
9/26
Start
DefineAnalysisScope
DevelopHierarchical
ControlStructure
HierarchicalControlStructure
STPAStep1:IdentifyUnsafeControlActions
STPAStep2:IdentifyHoweachunsafe
ControlActioncouldoccur HierarchicalControlStructure
withprocessmodel
System-LevelAccidents,relatedhazards,designand
safetyrequirements
UnsafeControlActions
CorrespondingSafetyRequirements
UnsafeScenarios
SafetyAnalysisReport
Fundamentals
SystemSpecificationanddesignmodels
RefinedSafetyRequirements
Input Results
STPA Swiss: A Software Safety Engineering Approach
10/26
u Major issues of using STPA in software development process:u STPA is performed separately and has not been yet placed in software engineering process.
u The STPA-generated software safety requirements are written in natural language, which wecan not directly use them in the verification and testing activities.
u Identify the unsafe scenarios of complex software based on the combinations of process modelvariable values manually is time and effort consuming.
u STPA does not provide any kind of model to visualize the relationship between the criticalprocess variables of controller which have an affect of the safety of control actions.
STPASwissSafetyEngineeringProcess
build
Detailed View of the STPA Swiss Approach
11/26
u Theproposedapproachcanbeappliedduringdeveloping anewsafesoftwareoronexistingsoftwareofsafety-critical system
Apply to software at the system level
Safety Control Structure Diagram
STPA Safety Analysis
Unsafe Software Scenarios
Software Safety Requirements
System Requirement Specifications
System Design Models
Software Implementation (code)
Build Safe Software Behavioural Model
Formal Verification (model checker)
Testing approach
State flow model (Simulink)
Safety-based Test Case Generation
Generate and Execute Test-scripts
generate
generate test suites
Formalize
generate
Traceability Execute
*Extract the verification model directly from the
software code
STPA results
Software Safety Verification
1
23
4
5
Safety Verification Report
Formal Specifications
Automated STPA Swiss Approach: XSTAMP Platform
12/26
u Wedeveloped anextensible platformtoolsupport forSTAMPsafetyengineeringcalledXSTAMPP asopensourceplatform.
www.XSTAMPP.deThe XSTAMPP main window
Example: Applying STPA to ACC Simulator
13/26
HowtoderivethesafetyrequirementsofACCsoftwarecontrolleratthesystemlevelandgeneratethesafety-basedtestcases?
u Fundamentals of Analysis
u System-Level Accidents:
Ø ACC-1 : ACC vehicle crashes with a vehicle in front.
u System-Level Hazards
Ø H-1: ACC software controller does not maintain safe distance from front vehicle.
Ø H-2: The ACC software does not stop the vehicle when the front vehicle is fully stopped
u Adaptive Cruise Control System: is a well-known automotive system which hasstrong safety requirements. ACC adapts the vehicle’s speed to traffic environment basedon a long range forward-radar sensor which is attached to the front of vehicle.
http://www.iste.uni-stuttgart.de/en/se/forschung/werkzeuge/acc-simulator.html
Step1.a : Construct The Control Structure Diagram
14/26
ACC
Design andSafetyRequirementsofSystem
SSR0.1 TheACCsimulatorshouldkeepasafedistance between thevehicle andavehicleahead
SSR0.2 TheACCsimulatorshouldstopthevehiclewhenthere isastoppedvehicle inthefront.
u ControlStructure diagramshowsthemaininterconnectingcomponentsoftheACCsystematahighlevel.
Step1.b : Identify Unsafe Control Actions
15/26
ACC
u UnsafeControlActions
Each unsafecontrolaction isthen translated intoasystem-level safetyconstraint
Example: ThecorrespondingsafetyconstraintofUCA1.1is
SR1.1TheACCsoftwareshould bringtherobottofullystopatstandstillwhentherobotvehicleaheadisfullystopped.
Step 1.b: Understand how each UCA could occur
16/26
u Processmodelshowsthecriticalvariableswhichhaveaneffect onsafetyofthecontrolactions. ACC
Four types of process modelvariables:(1) Internal states variables(2) Internal variables(3) Interaction variables(4) Environmental variables
u Basedontheconceptofcontexttablesofeachsafety-critical actions(JohnThomas2013),wegenerate thecombinationsetsbetween processmodelvalues
Step1 : Automatically Generating Context Tables
17/26
u Apply the combinatorial testing algorithm to reduce the number ofcombination between the process model variables (Cooperation with Rick Kuhn,National Institute of Standards and Technology, Computer Security Division, US).
ACC
q Bycombinatorial testingalgorithm: q Wecanautomatically generatethecontexttable.
q Wecanachievedifferentcombinationcoverages(e.g.pairwisecoverage,combinationsandt-waycoverage)
q Wecanapplydifferentrolesandconstraintstothecombinationtoignoresomevalues
ControlActions timeGap states currentspeed RadarSensorData Hazardous
Decelerate
Standby ==0 >minSpeed Frontdistance>0 noFollow <(deltaX +safetyTimeGap) ==desiredspeed Frontdistance>0 yesStandby >(deltaX +safetyTimeGap) <desiredspeed Frontdistance>0 noStandby >safetyTimeGap >desiredspeed Frontdistance>0 noStandby <=safetyTimeGap ==0 Frontdistance>0 noResume ==0 ==desiredspeed Frontdistance>0 noResume <(deltaX +safetyTimeGap) <desiredspeed Frontdistance>0 yesResume >(deltaX +safetyTimeGap) >desiredspeed Frontdistance>0 noResume >safetyTimeGap ==0 Frontdistance>0 noResume <=safetyTimeGap >minSpeed Frontdistance>0 noStop ==0 ==0 Frontdistance>0 noStop <(deltaX +safetyTimeGap) >minSpeed Frontdistance>0 noStop <=safetyTimeGap >desiredspeed Frontdistance>0 no
ContextTableofcontrolactionDecelerateincontextnotprovided
Automatically Generate LTL formulae
18/26
u ACCsoftwarecontrollerprovides asafetycriticalaction:acceleratesignal
Controlactions
ProcessModelvariables Hazardous
AccelerateSignal
timeGap CurrentSpeed RadarData states
<(deltaX +safeTimeGap)
==desiredspeed Frontdistance>0 Cruise Yes
>safeTimeGap <desiredspeed Frontdistance>0 Cruise No
<safeTimeGap >Desiredspeed Frontdistance>0 follow Yes (H1,SSR1)
RefinethesoftwaresafetyRequirements
𝑆𝑆𝑅#.%:ACCshouldnotprovideaccelerated signalwhentheTimGap islessorequalthesafeTimeGap whileACCinfollowmodecurrentspeed isgreaterthandesiredspeed.
GenerateLTLformula
𝐿𝑇𝐿#.% G ((states=follow)&(timeGap<safeTimeGap)&(currentspeed>DesiredSpeed)&frontdistance >0 )->! ((controlAction=Accelerate)))
Step 2 : Constructing the safe behavioural model of software controller
19/26
Softwaresafetyrequirements
Contexttables
u Toverifythedesign&implementation ofsoftwarecontrolleragainst theSTPAresultsandgeneratethesafety-based testcases:
Ø Eachsoftwarecontrollermustbemodelledinasuitablebehaviouralmodel
Ø ThemodelshouldbeconstrainedbySTPAsafetyrequirements
Controlstructure&processmodel
Asafebehavioural modelofsoftwarecontrollerSoftwareSpecification
UMLstateflownotation
Ø Syntaxofeachtransitionofthesafebehaiovural model:
STPAResults
State0[STPAsafetyrequirement]
State1
Step 2 : The safe behavioural model of ACC software controller
20/26
SoftwareController&processmodelvariables
[currentSpeed ==desiredSpeed &&timGap>(deltaX+safeTimeGap) &&ACCMode ==Cruise]
Transition:(safetyrequirement)
AsafebehaviouralmodelofACCsoftwareController
SequentialProcessvariables
ParallelProcessvariables
ContextTable
Step 3.1 : Automatically generate Verification Model of SBM
21/26
u To check whether the safe behavioural model satisfy the STPA safety requirements, we developed a tool called STPATCGenerator which automatically converts the safe behavioural model into a input language of model checker suchas SMV (SymbolicModel Verifier ) model
SimulinkStateflow(dynamic)
STPAProcessModel(static)
ThegeneratedSMVmodelbySTPATCGeneratortool
Step 3.1 : Check Correctness of Safe Behavioural Model of SW Controller
22/26
u Second,wedevelopedaplug-inbasedonXSTAMPPcalledSTPAverifiertoverifytheLTLformulaewithNuSMV modelcheckertool
Step 3.2 : Safety-based Test Cases Generating
23/26
u Togeneratesafety-based testcasesbasedonSTPAresults,
Ø Weautomatically convertsafebehaviouralmodel intoextended finite statemachine.
Ø WeuseEFSMasinputtotheSTPATCGenerator togeneratetestcasesforeachSTPASSR.
Safety-basedTestCasesSTPATCGenerartorTool
Safebehaviouralmodel TraceabilitymatrixEFSMModel
Stateflow TreeofSBM ExtendedfinitestatemachinediagramofSBM
The Results of Test Cases Generating
24/26
u We generated automatically 18 test cases which cover the safe behavioural of the ACC softwarecontroller with the state coverage =7/7, transition coverage =18/32, and the STPA SafetyRequirements coverage 38/38.
TestSteps :20TestAlgorithm:Both(DFS&BFS)StopCondition=AllSTPARequriements
Verifying STPA Safety Requirements at the implementation level
25/26
u WeuseSTPAverifiertoverifytheLTLformulaewithSPINmodelcheckertoolbasedontheverificationmodelwhichisextracteddirectlyfromCsourcecodeofACCbyModex tool
Conclusion & Future Work
u Conclusion:Ø We presented a safety engineering approach based on STPA to develop a safe
software. It can be integrated into a software development process or applieddirectly on existing software.
Ø It allows the software and safety engineers to work together during developmentprocess of software for safety-critical systems.
Ø We conducted a case study to evaluate STPA Swiss during developing a simulator ofACC with LEGO-mindstorm roboter at our institute.
u Future (recent) Work:
Ø We conducted a case study with our industrial partner to investigate theeffectiveness of applying the STPA Swiss approach to a real system.
Ø We plan to position the STPA Swiss approach into an automotive developmentprocess of our industrial partner.
26/26
e-mailphone +49(0)711685-
fax +49(0)711685-
UniversitätStuttgart
Thankyou!
AsimAbdulkhaleq,M.Sc.
8845888389
Instituteof SoftwareTechnology
www.xstampp.de
Joint Work with: Prof. Dr. Stefan Wagner
