Ada Europe - 1

Model-based Development ofSafety Critical Software:

Opportunities and Challenges

John McDermid, FREngProfessor of Software Engineering, University of York

Director Rolls-Royce Systems & Software Engineering UTCDirector BAE Systems Dependable Computing Systems Centre

Non-Executive Director High Integrity Solutions (HIS)

Ada Europe - 2

OverviewObjectives of model-based development

Comparisons with other areasSafety critical software development

OpportunitiesTime and Money

ChallengesFunctionalityChangeNon-functional propertiesIntegration

Conclusions

Ada Europe - 3

Model-Based DevelopmentObjectives in “traditional engineering”

Reduce risks, costs and timescales of developmentse.g. do bird strike tests only once

For example in aerospace and automotive industries

Example of Rolls-Royce engine developmentExtensive use of finite-element analysisMechanical properties of designAero-thermal design

Mechanical design very advancedPrediction of failure behaviourPrediction of impact damageEnables one-off tests validating the model

Ada Europe - 4

Cobbler’s ChildrenIn software development, little use of computer models

Extensive and expensive manual activity

Ada Europe - 5

Objectives for SCSSafety critical software has a good safety record

Safety critical software is expensiveCirca 1 kLoC per person year, but much variation

Sources of costsLow level verification

Circa 25% of cost in unit/module testRework

Producing software to flight standard three times is not uncommonErroneous requirements

Perhaps 40% of post unit test errors for simple systemsAs high as 85% for complex ones, e.g. F22

Save time and money without reducing product integrity

Ada Europe - 6

Safety Critical Software is Growing

1980

1987 1993 19981999

20042004

2014

1

10

100

1000

10000

100000

In Service Date

Cod

e Si

ze k

LoC

Ada Europe - 7

Opportunities: Time and MoneyCode generation enables reduction of cost and time

Move from V model to Y Early validation, automated analysis, greater abstraction …

DetailedDesign

Software

SoftwareSpecification

SystemSpecification

VYState of practice

Standardscompliance

Architecture

Source Code

Ada Europe - 8

Software ArchitectureArchitecture is a “high level” design model

System components and interconnections

Software architecture very broad and should coverFunctionality and interfacesData definition, data flow and information flowModing and schedulingTiming and performanceMapping to hardware Failure behaviour and safety properties …

Objective to have a rich model enablingValidation and verification against (safety) requirementsPrediction of key implementation properties, with confidence

Ada Europe - 9

But Current Models are Very Low LevelModel is functional, doesn’t address timing, failure …

Need more expressive power, and more abstraction …

Ada Europe - 10

But there is a bigger problem …

PerfectModel

GarbageModel

GarbageData

GarbageResults

PerfectData

GarbageResults

Ada Europe - 11

Analysis of Architectural ModelsTo avoid GIGO, analysis needs to address

VerificationDoes it meet the requirements?

ValidationIs it consistent and complete (both internally and externally)?Is it feasible (given the hardware resources)?Does the model meet derived safety requirements (DSRs)?Are there potentially unsafe deviations from design intent?

ApproachesReview Safety analyses, e.g. HAZOPAutomated analysis of specifications

Illustrate using extensions to Matlab/Simulink/Stateflow (MSS)

Ada Europe - 12

Illustrative Example Engine thrust reverser control

Reverses air flow to decelerate aircraftAchieved by moving “Bucket Doors”

Ada Europe - 13

Example of Automated AnalysisExample of aero-engine thrust reverser control

Aircraft deceleration using bucket doors Hazard if used in flight or asymmetrically, or at too high thrustSpecified using state machines (Stateflow in MSS )DSRs on safe operation and recovery, e.g. interlocks

Analysis via extraction of the model, DSRs and formal proof

Completeness,internal/externalconsistency,meets DSRs …

NB Software “unsafe” if its view of the world differs from reality

Ada Europe - 14

Example of DSR and AnalysisAnalysis for validation, and verification against DSRs

Automated analysis approachHealthiness checks,e.g. determinismAnnotations to defineDSRs, linked to statemachineAssumptions whichmodel behaviour ofembedding system/physicsFormal analysis tocheck DSR holdsA counterexample is given if the checkfails

Checks reduce chance of GIGO due to model errors

Ada Europe - 15

The Challenge of ChangeChange is inevitable

Benjamin Disraeli, 1867

Can reduce the likelihood of changeVerification and validation, e.g as illustrated

Can reduce the impact of changeAutomated verification and validationDesign to accommodate change

Product lines, strong similarity between productsProduce configurable assets for product lineSelect and configure for particular productsSave time, reduce risk of error and enforced changeEmbed in models, making them configurable

Ada Europe - 16

Example: Engine Starting

Ada Europe - 17

Adjust Drives - Details

Ada Europe - 18

Control over Configuration

Ada Europe - 19

Changing between Product Line Members

Ada Europe - 20

Top-Level Model – Change Localised

Ada Europe - 21

Adjust Drives – No SAV

Ada Europe - 22

Product Line ManagementBenefits

Encodes product line ideas in tools used by design engineersCan produce checks to ensure sound configurationCan verify and validate components independentlySave time, money and reduces risk

Controlled reuse

LimitationsQuite complex to encode in current tools

In MSS some ugly “mechanics” to realise variabilityHard to ensure consistent change to models held by multiple tools

Difficult to reduce/remove need for re-verificationLimited help with unpredicted changesDoesn’t directly address non-functional properties

Ada Europe - 23

Non-Functional PropertiesNon-functional is an awful term

Aspects of behaviour, not just “ideal functionality”

Range of properties of interestSome, e.g. timing, can be represented as attributesOthers, e.g. fault management, require new/modified functions

TimingCan articulate requirements for software

Deadlines, jitter, etc.Annotate models with WCET, etc. (estimates or actuals)Undertake analysis or synthesise schedules

Consider fault accommodation

Ada Europe - 24

Fault Management Code Development generally a manual process

Costly, may be more than half system codeError prone, and likely to change

Alternatively, automate configurationProvide configuration for existing product-line componentsSelect software components based on data on

Hardware failure modes (FMEAs)Configuration rules (fragments of Markov models)

Code production by reuse, not generationChange handled through selection of different code templates

Traceable behaviourFrom choice of component back to requirements

Ada Europe - 25

Software LayeringSystem functions

Drivers for devicesValidated sensor dataand actuator control

Fault managementTo produce “trusted” data for application

NB hazard if softwareview of world differsfrom reality

Abstraction from processing hardware

Operating system

ApplicationRequirements from Platform Level

Hardware Abstraction Layer (HAL)Isolation from details of Computing Hardware

HAL

Isol

atio

n fro

m d

etai

ls o

fS

enso

rs a

nd A

ctua

tors

Sensed Values

Val

idat

ed V

alue

s

Failure Managementfor embedding systemsensors and actuators

Ada Europe - 26

Fault Management LogicFault-accommodation requirements in Markov model

Can despatch (use) system “carrying” failuresDespatch analysis based on Markov modelEvaluate probability of being in non-dispatchable state, e.g. only one failure from hazardLink between safety/availability process and software design

Auto-generation ensures software and analysis in stepReuse pre-verified fault-accommodation modules

May use four valued logicWorking, undetected, detected, and confirmedTable illustrates “logical and” ([.])Used for analysis ccccc

cddddcduuucduwwcduw.

Ada Europe - 27

Example Implementation

cccccdddcdwwcdw[.]

Ada Europe - 28

Deriving Safety AnalysesBy adding failure assumptions to models, possible to generate safety analyses

Complements work onfault management

Derive safetymodels used forcertification

Several alternativeapproaches

Needs semantic model for failuresand propagation

Several challengesScale, intelligibility ofoutput, trust in tools

Requires integration

Ada Europe - 29

IntegrationNeed (at least)

Notational integrationMethod/process integration (development and safety processes)Toolset integration

NotationsExpressive enough to cover all properties of interestA “single” notation, or related views

Architecture Analysis and Definition Language (AADL) Developed out of work by Honeywell and US ArmyGood concept, with growing support

Notation, tools and SAE standardPotential for timing / reliability / safety analysis

Ada Europe - 30

Process and Toolset IntegrationMost tools are quite specialised

Do some things wellDon’t address all relevant issues, e.g. don’t model all of the architectural properties, and are unlikely to address all

Need to set upProcess models, tolink activitiesData models, to linknotations and to provide traceabilityTool infrastructurethat realises linksincluding impactanalysis HIS V-Model

S a f e t yE n g .

S a f e t yE n g in e e r in g

S a f e t yE n g in e e r in g

C o n f ig u r a t io n M a n a g e m e n t

Q u a l i t y A s s u r a n c e

V e r i f ic a t io n

P r o je c t M a n a g e m e n t

F u n c t io n a lT e s t

S y s t e mI n t e g r a t io n

T e s t in g

S o f t w a r eD e s ig n

A r c h i t e c t u r a lD e s ig n

R e q u i r e m e n t s

C e r t i f ic a t io n L ia is o n

S o f t w a r eI n t e g r a t io n

T e s t in g

M o d u le T e s t

C o d e

Ada Europe - 31

ConclusionsModel-based development important for future safety critical software developments

Believe this will become the norm, in time

So, is this the end for program level analysis?

NoCurrently, program level toolsets, e.g. SPARK Examiner better developed than modelling tools – for safety critical softwareMuch code generation will be linking pre-defined code modules

These modules need to be developed and verifiedContinued challenges in compositional verification

Model based development will shift balance …

Ada Europe - 32