Heaven or Hell

The marriage between

IEC 61508 and Scrum

Tor Stålhane, NTNU

Even Andre Karlsson, Addalot

Agile development of safety-critical software

We present two approaches to using an agile approach to the development of safety critical software.

• T. Stålhane, IDI / NTNU, present SafeScrum’s point of view

• E.A. Karlsson, Addalot, present an alternative more agile view

In the end we hope to have some points of discussion or agreement

SafeScrum

Tor Stålhane

NTNU

SafeScrum – the what’s and why’s

The top concerns of SafeScrum:

1. Comply with IEC 61508

2. Few changes to SafeScrum. Affect only the

software part – separation of concerns

3. Stay true to the most important agile

principles:

a) As little documentation as possible

b) Improve project communications

c) Embrace changes

Development process

The SafeScrum

domain

SafeScrum – Separation of concerns

The SafeScrum model

for IEC 61508

Environment

description

RAMS

validation Scrum

Backlog

SSRS

Phases 1 – 4

Operation

Phase 14

Modifications

Phase 15

Parts of Annex

A.1 – A.7B.1 – B.3

B.7 – B.9

New safety

requirements

High level

plans

Parts of Annex

A and B

Why separation of concerns

Separation of concerns in order to

• Keep the changes to the standard-defined

development process as small as possible

• Let the software developers focus on what

they are good at – producing high quality code

Add-ons to Scrum

Why do we need the add-ons

The add-ons are used to be compliant with the

IEC 61508.

• Maintain traceability of safety requirements:

– Separate functional requirements and safety

requirements

– Add a trace activity in each sprint

• Perform a RAMS validation after each sprint

Challenge – change impact analysis

To quote an anonymous developer:

“After the first increment, all the rest is

maintenance”.

We thus need

• To consider change impact analysis

throughout development

• A more complex SafeScrum model

Change Impact analysis and the product backlog

Functional and

RAMS validation

Function

product backlog

Safety

product backlog

Sprint and

validation

results

Change

Impact

Analysis

Changes to

the SSRS

Change rejected

Changes to SW

env. and HW

Changes to safety

req’s and complex

functional req’s

Changes due

to anomalies

from test

1

3

2

How do we handle the challenge

Our main concerns:

• IEC 61508 has strict requirements on change

management that need to be met

• Agile development is about embracing change

We cannot put so many restrictions on change

that we kill agility

Changes to consider

Need to consider changes

• to existing safety requirements

• that will influence code that directly or indirectly belongs to a safety

requirement.

These changes can be categorized into two classes:

• Simple changes. The developer categorizes the change as simple,

perform a CIA and document why he has made this decision

• Not-simple changes. Those that concern safety requirements

– Use trace information to see what parts of the code will be

affected

– Check the code for potential impact on safety in a code review

– Make a decision – change or not – and write a report.

Conclusion -1

IEC 61508 in an agile setting is a large topic and

include components of

Heaven – an agile way of working

Hell – a lot of rules and regulations, depending

on the SIL

Even-André Karlsson

Incremental development and Safety

© Addalot Consulting AB - All rights reserved

Prove that you have done

what is needed

Ensure that the system is

safe; safety req => solution

Ensure that no SW errors

are introduced

High level activities

� 3-7 Hazard analysis and risk assessment

� 3-8 Functional safety concept

� 4-6 Specification of the technical safety requirements

� 4-7 System design

� 4-8 Item integration and testing

� 4-9 Safety validation

� 4-10 Functional safety assessment

� 4-11 Release for production

� 6-6 Specification of software safety requirements

� 6-7 Software architectural design

� 6-8 Software unit design and implementation

� 6-9 Software unit testing

� 6-10 Software integration and testing

� 6-11 Verification of software safety requirements

16

© Addalot Consulting AB - All rights reserved

Possible safety increments/sprints

1. Safety concept (20% into dev)=> Safety requirements added to back-log

2. Defensive software design (50% into dev)

3. Safety test on sw level (60% into dev)

4. Safety verification and validation (70% into dev)

5. Review previous safety activities (80% into dev)

6. Final safety increment

Assuming 14 two weeks sprints = 28 weeks:

X X 1 X X X 2 X 3 X 4 5 X 6

6 of 14 sprints are safety focused. In addition there are safety requirements to be implemented

17

© Addalot Consulting AB - All rights reserved 18

© Addalot Consulting AB - All rights reserved

Concept activities

� 3.5 Item definition

- We assume that enough is known about the “item” after the first two functional sprints. If this changes, we have to redo/complement some of the other activities.

� 3.6 Initiation of the safety lifecycle

- It should already be clear if this is development from scratch or modifications. This presentation only discuss development from scratch, but could perhaps be applicable for modifications as well.

� 3.7 Hazard analysis and risk assessment

- One of the main activities of the first safety sprint

- 7.4.2 Situation analysis and hazard identification

- 7.4.3 Classification of hazardous events (severity, probability, controllability => ASIL)

- 7.4.4 Determination of ASIL and safety goals

- 7.4.5 Verification

� 3.8 Functional safety concept

- Another main activity of the first safety sprint

- This results in a set of “functional” safety requirements that can be implemented in sprints

19

© Addalot Consulting AB - All rights reserved

Defensive software design increment (1)

20

Note 1f will require much more work, and has to be planned up front as separate

sprints

© Addalot Consulting AB - All rights reserved

Defensive software design increment (2)

21

© Addalot Consulting AB - All rights reserved

Software safety test increment

22

© Addalot Consulting AB - All rights reserved

Conclusion

Each sprint is completed with defined exit criteria

1. Hazard analysis to determine functional safety requirements=> Hazard analysis and functional safety requirements added to backlog

2. Functional safety requirements are implemented in sprints with ”normal testing”=> Normal design, but with required safety documentation

3. ”Defensive software design” is done in separate sprint=> Analysis and documentation of ”defensive software design”

4. Additional safety testing=> Analysis and documentation of ”safety testing”

5. Safety validation is summarized in last increment=> Safety case

23

© Addalot Consulting AB - All rights reserved

Advantages of a focused incremental approach

� Focus the whole team on safety activities

� Able to bring in experts to help out

- Early sprints, experts on

- FMEA, FMECA on a high level

- FTA

- Later sprints, experts on

- Defensive programming

- Safety Testing, e.g. boundary testing, error injection

� Ensure that the safety activities are done

� Implementing the functional safety requirements in sprints will improve the ”automatic” traceability

24

Where do we go

from here

Tor Stålhane,

NTNU

Even Andre Karlsson, Addalot

Where do we differ – 1

Planning

• SafeScrum – planning is kept outside

SafeScrum. Reduces the impact on the

development process defined by the standard

• Addalot - planning is done as part of the

sprints. Involves the whole sprint team in the

process from the start

Where do we differ – 2

Process

• SafeScrum– Only the software development part is influenced

– Safety experts and domain experts are brougth in when needed

• Addalot– The whole development process is made agile

– We assume that enough is learned about the system in the first two sprints to do the safety analysis

– Focused use of safety experts – designated sprints

Where do we differ – 3 Safety concerns

• SafeScrum

– safety requirements are kept in a separate backlog but otherwise treated as other requirements

– RAMS (Reliability, Availability, Maintainability and Safety) validation added at the end of each sprint

• Addalot

– safety concerns are handled in designated sprints

– safety requirements are treated as other requirements

Summing up

Addalot:

We make the whole development process agile

NTNU / SINTEF:

We interfere as little as possible with the

process defined by the applicable standard

This is our challenge!

Questions? Comments?