Software Engineering for Safety : A RoadmapIntroductionSlide 3Keys Areas in SE for SafetyHazard AnalysisSafety Requirements Specification and AnalysisDesigning for SafetyTestingCertification and StandardsResourcesDirections for future WorkFault TreesDirections………….Directions……..Directions…..Conclusion....Software Engineering for Software Engineering for Safety : A RoadmapSafety : A RoadmapPresentation by:Presentation by:Manu D VijManu D VijCS 599 Software Engineering for Embedded SystemsIntroductionIntroduction•Wide Spread Use of Safety - Critical Wide Spread Use of Safety - Critical Systems and their reliance on Systems and their reliance on SoftwareSoftware•““The Nation depends on fragile The Nation depends on fragile software”software”Keys Areas in SE for SafetyKeys Areas in SE for Safety•Hazard AnalysisHazard Analysis•Safety requirements specification Safety requirements specification and analysisand analysis•Designing for safetyDesigning for safety•TestingTesting•Certification and StandardsCertification and Standards•ResourcesResourcesHazard AnalysisHazard Analysis•Core of the development of safe systemsCore of the development of safe systems•Identification and Analysis:Identification and Analysis:–CriticalityCriticality–Likelihood of OccurrenceLikelihood of Occurrence•Which Hazards to avoid ?Which Hazards to avoid ?•Determination of s/w components that can Determination of s/w components that can contribute or prevent hazardcontribute or prevent hazard•Safety requirements and constraints on Safety requirements and constraints on design of systemdesign of systemSafety Requirements Safety Requirements Specification and AnalysisSpecification and Analysis•Formal Specification:Formal Specification:–Ease and AccuracyEase and Accuracy–Investigate if safety properties are preservedInvestigate if safety properties are preserved–Automated check availabilityAutomated check availability•Interactive theorem provers, Model checkersInteractive theorem provers, Model checkers•SafetySafety Software Requirements Software Requirements RequirementsRequirements•SpecTRM ----- Embedded SystemsSpecTRM ----- Embedded SystemsDesigning for SafetyDesigning for Safety•Design for SafetyDesign for Safety–PreventionPrevention–Detection and ControlDetection and Control•Design Trade OffsDesign Trade Offs–Safety Vs Other features e.g. Fault ToleranceSafety Vs Other features e.g. Fault Tolerance–Issues involved are moral, legal, finance……Issues involved are moral, legal, finance……•Vulnerability to simple design errorsVulnerability to simple design errors–Tendency to neglect small errorsTendency to neglect small errors–““Small Errors have small consequence”– not in SoftwareSmall Errors have small consequence”– not in Software•Limited use of known design techniquesLimited use of known design techniques–Good design techniques are ignoredGood design techniques are ignoredTestingTesting•Critical for safe system in:Critical for safe system in:–DevelopmentDevelopment–CertificationCertification•Assumptions about:Assumptions about:–EnvironmentEnvironment–UsersUsers–OperationsOperations•Is it enough ?Is it enough ?Certification and StandardsCertification and Standards•CertificationCertification–More complicatedMore complicated–Less well definedLess well defined•StandardsStandards–““What standards are appropriate for large, safety-critical What standards are appropriate for large, safety-critical systems composed of subsystems from different domains”systems composed of subsystems from different domains”–Problems: Problems: • Lack of guidance in existing standardsLack of guidance in existing standards• Poor integration of software issues with system safetyPoor integration of software issues with system safety•Heavy burden of making a safety case for certificationHeavy burden of making a safety case for certification–Recommendations:Recommendations:•Classifying and evaluating standards according to Classifying and evaluating standards according to products, process and resourcesproducts, process and resources•Constructing domain specific standards for productsConstructing domain specific standards for productsResourcesResources•Books…. LevensonBooks…. Levenson•Bowen’s website…. Publications, Bowen’s website…. Publications, Conferences, RISKforumConferences, RISKforum•IEEE videoIEEE videoDirections for future WorkDirections for future Work•Integration of informal and Integration of informal and formal methodsformal methods –Key Areas:Key Areas:•Automatic translation of informal Automatic translation of informal notation into formal models notation into formal models•Lightweight formal methodsLightweight formal methods•Integration of previously distinct Integration of previously distinct formal methods. formal methods.Fault TreesFault Trees•hazard events hazard events represented by represented by nodesnodes•AND/OR gatesAND/OR gates•domino effectdomino effect•errors in the errors in the requirements phaserequirements phaseexample taken from: example taken from: http://www.cs.cmu.edu/~kohttp://www.cs.cmu.edu/~koopman/des_s99/safety_critiopman/des_s99/safety_critical/cal/Directions………….Directions………….•Constraints on safe product families and Constraints on safe product families and safe reusesafe reuse –Two key research areas:Two key research areas:•Safety Analysis of product familiesSafety Analysis of product families–A GoalA Goal•Safety reuse of COTS softwareSafety reuse of COTS software–Two ProblemsTwo ProblemsDirections……..Directions……..•Testing & EvaluationTesting & Evaluation–Requirements-based testingRequirements-based testing–Evaluation from multiple sourcesEvaluation from multiple sources–Model consistencyModel consistency–Virtual environment simulationsVirtual environment simulations•Runtime monitoringRuntime monitoringDirections…..Directions…..•Education:Education:–Scientific rather than methodical coursesScientific rather than methodical courses–TextbooksTextbooks–AwarenessAwareness•Related FieldsRelated Fields–Security & SurvivabilitySecurity & Survivability•Techniques quite similarTechniques quite similar•Security Vs SafetySecurity Vs Safety–Software ArchitectureSoftware Architecture•Safety consequence
View Full Document