| Date post: | 22-Jan-2018 |
| Category: |
Presentations & Public Speaking |
| Upload: | asim-abdulkhaleq-drrernat |
| View: | 311 times |
| Download: | 5 times |
Ph.D.DissertationDefense
ASystem-TheoreticSafetyEngineeringApproachforSoftware-IntensiveSystems
AsimAbdulkhaleq
Stuttgart,February6th 2017UniversityofStuttgart
@AbdulkhaleqAsim
06-02-2017
Ph.D.DefenseCommittee:Prof.Dr.StefanWagnerProf.Dr.NancyLevesonProf.Dr.Dr.h.c.FrankLeymannProf.Dr.UlrichHertrampfProf.Dr.RalfKüsters
www.XSTAMPP.de 1/30
SoftwareSafety
SoftwareSafety?
v Today’ssafety-criticalsystemsareincreasinglyreliantonsoftwarev E.g.Autonomousvehicleswillreplacethedrivertasksbysoftware
functionstomaketrafficmorecomfortable.
Software
ControlActions? Feedback?
>100millionlinesofcode
>70ElectronicControlUnits
(ECUS)>50softwarefunctions
Autonomousvehicle
Motivation
2/30
Agenda
v Motivation
v Introduction
Ø ProblemStatement
Ø ResearchObjectives
Ø Contributions
v Background
Ø SafetyAnalysisTechniques
Ø SoftwareVerification
v ProposedApproach
v IllustrativeExample:AdaptiveCruiseControlSystemwithStop-and-Gofunction
v Conclusion&FutureWork
Agenda
3/30
System
4/30
SoftwarebyItselfisNotHazardous
Software
ControlActions? Feedback?
Notallsoftwarefailurescancontribute(lead)to
anaccident
Wecan’ttestallthepathsthrough
thesoftware
The primary safety problem in software-intensive systems is not software “failure”but the lack of appropriate constraints on software behavior [Prof. Leveson].
Itcanleadtoinadequatecontrol
inabsenceofsoftwarefailure
Evencorrectlyimplementedsoftware
isstillunsafe
Hasnorandomfailures
Safetyisasystemproperty
Software safety is defined as a systematic approach to identify, analyze,track, and control software hazards and hazardous functions (data andcommands) to ensure safe operation within a system [NASA 2004].
SoftwareSafety
System
Software
ControlActions? Feedback?
Softwaresafetymustbeconsideredinthecontextofthesystemsafety
ProblemStatement
Verifysoftwareagainstitssafetyrequirements
SoftwareVerificationApproaches:Modelcheckers,Testingapproaches
SoftwareVerification
Identifyappropriatesoftwaresafetyrequirements
SafetyAnalysisTechniques:System-TheoreticProcessAnalysis(STPA)
SafetyAnalysis
However,thecurrentsoftwareverificationmethodsdonotexplicitlyintegratetheinformationfromthesafetyanalysis.
ProblemStatement
5/30
Research Objectives
📌 To develop a safety engineering approach based on STPA which offersseamless safety analysis and software verification activities to helpsoftware and safety engineers in:
Ø deriving the appropriate software safety requirementsØ formally verifying them, andØ generating safety-based test cases to recognize the associated software risks.
📌 To develop an open-source tool to support the proposed approach
ResearchObjectives
6/30
Developingasafetyengineering
approachbasedonSTPA
Providingformaldefinitionsandalgorithms
Developinganopen-sourcetoolcalledXSTAMPP
Evaluatingtheproposedapproach:•DevelopingasafesoftwaresimulatorofACC.
• EvaluatingtheBMWActiveCruiseControlsystem.
• EvaluatingtheContinentalautonomousvehicle.
Contributions
1 2 3 4
Contributions
7/30
WhySTPA(System-TheoreticProcessAnalysis)?
v Limitations:
❌ They assume that accidents are caused by component failures (Reliability Theory).
❌ They are not adequate to address new accidents caused by componentinteractions, software and human errors [Leveson 2011].
❌ Some of them do not provide any kind of system model.
19401950 1960 1970 1980 1990
FMEA FTA
HAZOP
ETA
[Leveson 2016]
v Thereareover100differenthazardanalysisapproaches.
TraditionalTechniques
8/30
STPASafetyAnalysisApproachv STPA(System-TheoreticProcessAnalysis)
Ø DevelopedbyProf.Leveson atMIT,USA,2004Ø BuiltonSTAMP (System-TheoreticAccidentModelandProcesses)modelbasedonsystem
andcontroltheoryratherthanreliability.Ø Treatssafetyasdynamiccontrolproblemratherthancomponentfailureproblem
Human/AutomatedController
Actuators Sensors
ControlledProcess
ControlActions
MeasuredVariables
ProcessOutputsProcessInputs
Disturbances
FeedbackVariables
ControlledVariables
Agenericcontrolloop(Leveson 2011)
MonitoredVariables
ProcessModel
AutomatedControllerControl
Algorithm
FeedbackVariablesStarting
Point
STPA/STAMP
9/30
STPAApproachProcess
Safety Analysis Report
CausalScenarios
System specification and design models
Input Start
Develop Control Structure Diagram
Hierarchical Control Structure Diagram
STPA Step 1: Identify unsafe control actions
STPA Step 2: Identify how each
unsafe control action could occur
Hierarchical Control Structure with process model
System-Level Accidents, related hazards, design and safety constraints
Unsafe Control Actions Corresponding Safety
Constraints
Fundamentals
New/Refined Safety Constraints
Results STPA Process
(CausalFactors)
STPA
Define Analysis Scope
STPAProcess
10/30
STPAinSoftwareVerificationHowtoverifysoftwareagainstSTPAresults?
SoftwareVerification
(formalverification&testing)STPAResults
Software
ControlActions?Feedback?
STPAhasnotbeenplacedinsoftwareengineeringprocess
Safetyconstraintsarewritteninnaturallanguage
satisfiednotsatisfied
STPAResultsSafetyconstraints/unsafescenarios
Itisdifficulttotransformsafetyconstraintsmanuallyintoformalspecification
ItrequiresamodeltovisualizeinformationderivedduringanSTPAsafetyanalysis
SoftwareVerification
11/30
ProposedApproach
12/30
build
ASystem-TheoreticSafetyEngineeringApproachTheproposedapproachcanbeappliedduringthedevelopmentofanewsafesoftwareoronanexistingsoftwareinsafety-criticalsystem
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 Behavioral 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
Safety Verification Report
Formal Specifications
Abdulkhaleq, A., Wagner, S., Leveson, N. (2015) A Comprehensive SafetyEngineering Approach for Software-Intensive Systems Based on STPA, ProcediaEngineering, Volume 128, 2015, Pages 2-11, ISSN 1877-7058.
ProposedApproach
13/30
u System-Level Hazards:H-1: ACC software does not maintain safedistance from front vehicle [AC-1].
u System-Level Accidents:AC-1: ACC vehicle collides with targetvehicle.
ACCSoftwareSimulatorWedevelopasoftwaresimulatorofACC
How to derive the safety requirements of ACCsoftware controller at the system level andgenerate the safety-based test cases?
Adaptive Cruise Control System (ACC): 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 a vehicle.
ACCVehicle TargetVehicle
14/30
IllustrativeExample
SafetyControlStructureDiagramHigh-levelcontrolstructureofaparticularsystem
Whatarethepotentialunsafecontrolactions?
Operator
Actuators
SpeedSensor
ControlledProcess
AccelerateDecelerateFullyStop
currentspeed
ProcessOutputsProcessInputs
Disturbances
frontdistance
Motorforces
UltrasonicSensor
speed
Motor1 Motor2
Sensor
ControllerActuatorControlledProcess
Legends:
ACCStop-and-GoFunctionSoftwareController
desiredspeedsafedistanceOn/Off
ControlStructureDiagram
15/30
UnsafeControlActionsProviding or notProviding acontrol action causes ahazard
ControlActions
Not Providingcauseshazards
Providingcauses hazards Wrongtiming orordercauseshazards
Stoppedtoosoon orappliedtoolong
Accelerate The ACCsoftwaredoesnotacceleratethespeedwhentherobotvehicleaheadissofarinthelane.[Nothazardous]
UCA1.1: The ACC softwareaccelerates the speed of therobotic vehicle when therobotic vehicle ahead is tooclose [H-1] [H-2]
UCA1.2. TheACCsoftwareacceleratesthespeedbeforetherobotvehicleaheadstartstomoveagain[H-1][H-2].
N/A
Correspondingsafetyconstraints:SC1.1:TheACCsoftwaremustnotprovidetheaccelerationsignalwhentheroboticvehicleaheadistooclose.
Translateeachhazardousitem
ACCStop-and-GoFunctionSoftwareController
AccelerateDecelerateFullyStop
Motor1 Motor2Actuators
UnsafeControlActionsTable
16/30
ProcessModel&VariablesA model required to determine the environmental & system variables thataffect the safety of the control actions.
Operator
ActuatorsSpeedsensor
AccelerateDecelerateFullyStop
currentspeed
frontdistancedesiredspeed
Ultrasonicsensor
speed
Motor1 Motor2
ControlledProcess
ProcessOutputsProcessInputsMotorforces
ACCStop-and-GoFunctionSoftwareController
safedistanceOn/Off
Disturbances
currentspeed=0>minSpeed==desiredspeed>desiredspeed<desiredspeed
ProcessModel
ACCModeStandbyResumeCruiseFollowStop
timeGap=0<=(deltaX+safetyTimeGap)>(deltaX+safetyTimeGap)>safetyTimeGap<safetyTimeGap
frontdistance<=0>0Power
ACCOffACCOn
17/30
ProcessModel
UCA 1.1: The ACC software accelerates the speed of the roboticvehicle when the robotic vehicle ahead is too close [H-1] [H-2]
GeneratingtheUnsafeControlActions(UCA)Extended Approach to STPA: Identify unsafe control actions in the STPA Step 1based on the combination of process model variables (Dr. John Thomas, MIT).
ControlActions ProcessModelVariables Hazardous?(any time,tooearly,toolate)Accelerate currentspeed timeGap ACCMode
>mindspeed <△ TimeGap+safeTimeGap follow No
<=desiredspeed TimeGap=0 follow Yes(H1, H2)
Refined UCA 1.1 : The ACC software controller provided an acceleration signal whenthe current speed is less or equal to the desired speed, time gap is equal to 0 and theACC system in follow mode.
Refined Safety Constraint RSC1.1 : The ACC software controller must not provide anacceleration signal when the current speed is less or equal to the desired speed, timegap is equal to 0 and the ACC system in follow mode.
Automaticallygeneratecorrespondingsafetyconstraints
Automaticallygenerateunsafecontrolactions
ContextTable
18/30
CausalFactors&ScenariosHow each unsafe control action could occurs in the system
UCA 1.1: The ACC software accelerates the speed of the roboticvehicle when the robotic vehicle ahead is too close [H-1] [H-2]
ActuatorsSpeedsensor
AccelerateDecelerateFullyStop
currentspeed
frontdistancedesiredspeed
Ultrasonicsensor
speed
Motor1 Motor2
ControlledProcess
ProcessOutputsProcessInputsMotorforces
ACCStop-and-GoFunctionSoftwareController
safedistanceOn/Off
Disturbances
currentspeed=0>minSpeed==desiredspeed>desiredspeed<desiredspeed
ProcessModel
ACCModeStandbyResumeCruiseFollowStop
timeGap=0<=(deltaX+safetyTimeGap)>(deltaX+safetyTimeGap)>safetyTimeGap<safetyTimeGap
frontdistance<=0>0Power
ACCOffACCOn
1.UnsafeInputsfromHigherLevels
2.UnsafeAlgorithm
3.IncorrectProcessImplementation
4.Incorrect-ProcessModels
5.FeedbackWrongorMissing
STPAStep2
19/30
FundamentalsAnalysis
Accident:AC-1 :ACCvehiclecollideswithfrontvehiclewhileACCstatusisactive.Hazards: H-1:ACCsoftwaredoesnotmaintainsafedistancefromfrontvehicle.
H-2:Anunintendedaccelerationwhenthevehicleinfrontistooclose.
STPAStep1 Unsafe ControlActionUCA1.1:TheACCsoftwareacceleratesthespeedoftheroboticvehiclewhentherobotic vehicleaheadistooclose [H-1,H-2]
Refined Unsafe Control Action RUCA 1.1: The ACC software provided anacceleration signal when the current speed is less or equal to the desired speed,time gap is equal to 0 and the ACC system in follow mode.
STPA Step2
(wrong feedback/input)
Causal Scenarios SafetyConstraints
S.1. The speed sensor provides a falsevalue to ACC software while thevehicle ahead is too close.
SC1.1. TheACCsoftware shallbeabletorecognizethefalsevalueswhicharereceivedfromthespeedsensor.
S.2. The radar sensor provides anincorrect (out of range) front distancevalue to the ACC software that allowsthe vehicle to get too close to thevehicle ahead.
SC1.2. TheACCsoftware shallbeabletorecognizetheoutofrangevaluesofthefrontdistance.
CausalFactors&ScenariosTableHow each unsafe control action could occurs in the system?
CausalFactorsTable
20/30
Formalisation ofSTPAResults
21/30
Formalisation ofSTPAResultsLinear Temporal Logic (LTL) is a popular formalism for thespecification and verification of concurrent and reactive systems.
Ø Rule 1: When CS occur in the execution path, the software must not (!) provide CA.Then, LTL formula can be expressed as: LTL = G ( CS → ! CA).
Providing or not providing a control action (CA) is based on the occurrence of the set ofvalues of process model variables and higher inputs (CS).
Abdulkhaleq,A.,Wagner,S.(2015)IntegratedSafetyAnalysisUsingSystems-TheoreticProcessAnalysisandSoftwareModelChecking.InComputerSafety,Reliability,andSecurity(Safecomp conference),LectureNotesinComputerScience,2015
E.g. The ACC software must not provide an acceleration signal whenthe current speed is less or equal to the desired speed, time gap isequal to 0 and the ACC system in follow mode.
LTL=G(((currentspeed <=desiredspeed)&(timeGap=0)&(ACCMode=follow))→!(CA=Accelerate))
Informal
Formal
LTLFormulae
22/30
GeneratingSafety-basedTestCasesfromSTPAResults
23/30
build
GeneratingSafety-basedTestCases
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 Behavioral 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
Safety Verification Report
Formal Specifications
Abdulkhaleq, A., Wagner, S., Leveson, N. (2015) A Comprehensive SafetyEngineering Approach for Software-Intensive Systems Based on STPA, ProcediaEngineering, Volume 128, 2015, Pages 2-11, ISSN 1877-7058.
ProposedApproach
24/30
Safety-basedTestCaseGenerationAlgorithmWe develop an algorithm on how to generate test cases from the STPA results:
Algorithm:
Abdulkhaleq, A., Wagner, S. (2016) A Systematic and Semi-Automatic Safety-based Test Case Generation Approach Basedon Systems-Theoretic Process Analysis. Submitted to ACM Transactions on Software Engineering and Methodology Journal.
Safe Behavioral Model
Verify ?
Safety-based Test Cases
traverse
notsatisfied
satisfied
modify
export
LTLformulae STPAResults
Traceabilitymatrix
transform
check
SMV Model
Safe Test Model
model
GeneratingSafety-basedTestCases
1 ModellingSTPAResults
2 TransformingintoaFormalModel
3 CheckingCorrectnesswithModelChecker
4 GeneratingRunnableSafeTestModel
5
Testcasesheet
transform
Safety-basedTestCases
25/30
SC1.2: The ACC software must provide an acceleration signal when thecurrent speed is less than the desired speed, front distance is greaterthan safe distance and the ACC system in resume mode.
Safety-basedTestCasesApplysearch-basedtestcasegenerationalgorithmtogeneratesafety-basedtestcasesfromthesafetestmodel
TestSuiteID 2
TestCaseID 2
RelatedSTPASCs SC1.1,SC1.2
Preconditions desiredspeed=45.0frontdistance=120.32currentspeed=44.0timeGap=1.65ACCMode=Resume
ControlAction Accelerate
Postconditions(ExpectedResults)
currentspeed=45.0ACCMode=Cruise
Safety-basedTestCases
26/30
SC1.2: The ACC software must provide an acceleration signal when thecurrent speed is less than the desired speed, front distance is greaterthan safe distance and the ACC system in resume mode.
Safety-basedTestCasesApplysearch-basedtestcasegenerationalgorithmtogeneratesafety-basedtestcasesfromthesafetestmodel
Safety-basedTestCases
26/30
Conclusion&Futurework
27/30
Conclusion
AsafetyengineeringapproachbasedonSTPAforsoftwaresystems
STPAartefactsfitwelltothesoftwareverificationactivities
AconceptonhowtoplaceSTPAinthesoftwaredevelopmentprocess
TransformingtheinformalsafetyconstraintsintoformalspecificationsinLTL
Derivingsafety-basedtestcasesfromSTPAresults
Evaluatingtheproposedapproachwithinthreecasestudies
DevelopinganopensourcetoolcalledXSTAMPP
Conclusion
28/30
e-mailphone +49(0)711685-fax +49(0)711685-
UniversitätStuttgart
Thankyou!
AsimAbdulkhaleq,M.Sc.
8845888389
Instituteof SoftwareTechnology
www.xstampp.de
AcknowledgmentsProf.Dr.StefanWagner,Prof.Dr.NancyLeveson,Prof.Dr.Dr.h.c.FrankLeymann,Prof.Dr.UlrichHertrampf,Prof.Dr.RalfKüsters,mycolleagues,friends,andfamily
30/30
