Reaping the benefits of Reusable Software Components

Safety & Security for the Connected World

Reaping the benefits of Reusable Software

Components

The conflicting demands on development

• The project triangle shows how conflicting

demands on a project have the scope to

compromise quality

• But Time and Cost are also critical to the viability of the development team

Software Reuse



Software Reuse is an attractive weapon to

use in balancing the demands of the project

triangle



But history shows us that what is proven in

one system, may not be quite so

appropriate in other circumstances



There are examples both outside the realms

Therac 25

• Later model replaced hardware interlocks with software, exposing

existing software flaws elsewhere

• Therac 25 involved in at least 6 accidents in which 100 times the correct

dose was applied

• Standards such as IEC 62304 designed to

ensure that quality is not compromised

• And yet cost and time

pressures don’t go away!

Ariane 5

• Software exception raised in the Inertial Reference System (SRI). • Design was almost exactly the

same as that used successfully on the Ariane 4, particularly in the case of the software.

• Standards such as DO-178 are designed to ensure that quality is not compromised

• And yet cost and time

The overheads of compliance

• DO-178 focuses on establishing quality software design and development practices.

• It describes the standard to which the definition of and tracing to requirements, design phases, software

development and testing needs to be applied. • It describe the

artifacts which need to be collated to

provide evidence of each completed

The principle of risk

Risk =

Probability of

hazardous event

occurring

x

Severity of event

Design Assurance Level

EFF

ORT

• The greater the risk, the higher the DAL, the

more compliance overhead increases

Safety Objectives: DO-178C

Design Assurance Level Objectives Objectives that must be verified with independence

A - Catastrophic 71 30

B - Hazardous 69 18

C - Major 62 5

D - Minor 26 2

How much Testing is Enough?

For example:



Structural Coverage:

–

Statement Coverage

–

Branch Coverage

–

MCDC (Modified Condition / Decision

Coverage)

–

Object Code Coverage



DO-178B/C level A: 100% coverage of

the Object Code

The conundrum

• Ariane 5 shows the dangers of assuming that software proven in one circumstance is necessarily acceptable for another.

• Therac 25 is an early example of the dangers of replacing hardware safety systems with inadequately proven software

• But showing that a

system is not flawed is both expensive and

Reusable Software Components

The FAA Advisory Circular AC 20-148 was

written in recognition of this conundrum.

“Because of economic incentives and advances in software component technology, software developers want to develop an RSC that can be integrated into many systems’ target computers and environments with other system software applications, as determined by the integrator or applicant.

In these cases, an RSC developer may partially satisfy the applicable

RTCA/DO-178B objectives, while the integrator or applicant completes

and shows the compliance for the integrated software package, systems aspects, and aircraft certification. Examples of potential RSCs include software libraries, operating systems, and communication protocols.”

Reusable Software Component

• What is an RSC?

A previously developed software component intended for reuse in follow-on systems in DO-178 projects

• What is AC 20-148?

Provides a means of compliance for RSC developers to take

full/partial certification credit for RSC usage in follow-on programs.

• Motivation

– Advances in system design & software component technology – Trend towards common/reusable components (eg, RTOS &

middleware)

Re-use Certification Without RSC



Reuse of COTS Product or In-House Solution

 Suppose it has been certified previously

 It is incorporated into your DO-178 system & submit for

certification

 The lessons learned from such as Ariane 5 mean that the

FAA looks for justification that the software component is appropriate for this application.

 Without an RSC, that requires all certification artifacts to be

regenerated, resubmitted and re-reviewed



Result: Time and Money are spent on

certifying the same components over and

over again.

RSC RTOS: Modularity is key

POSIX Health Monitor Cinit User Mode Supervisor Mode S y s tem S of tw a re Hardw A pplic a tion S of tw a re TCP/IP/UDP ARP/ICMP/IGMP POSIX POSIX ARINC ARINC POSIX SNMPv3 FTP/TFTP SOCKETS SOCKETS SOCKETS SNTP Partition N, Level E Partition 0, Level A/B Partition 1, Level B Partition 2, Level D

mixed criticalities and increased integration modular architecture multiple development groups

Development Team 1 Development Team 2

RSC RTOS: What is the difference?



RSC Documentation doesn’t stop with the

provision of artifacts



It includes guidelines to ensure that every

RSC RTOS: What is the difference?



This highly specified modularity means that

the RTOS can be treated as a “black box”



FAA is satisfied that the application code

cannot then cause a problem as long as

the instructions are adhered to



Adherence to those instructions is then the



In practical terms:



The Certifying Authority will not re-examine

the RSC component artifacts



Modifications / Variations – only require a

Change Impact Analysis – not a full

re-certification



Protects against hardware and software

modifications – means greater re-use and

repeatability



For the Integrator



The RSC artifacts provide educational

value to the integrator



Written guidance and tests help the

integrator to assimilate their

applications



Yields significant savings in labour

compared to conventional DO-178

artifacts.



For some systems, it is enough to know

that a system is capable of certification



For any RSC, the FAA is satisfied that

the component will ALWAYS behave as

expected.



For alternative non-RSC components,

they require evidence of that.



Whatever your application, that provides

evidence of an additional level of quality



Standards such as DO-178 seek to apply best

practice to avoid repeating the mistakes of the past



Applying best practice requires time & money –

“the project triangle”



For aviation projects, specifying an FAA

designated RSC RTOS will reduce that effort with

no compromise on quality



Projects outside the scope of DO-178 certification

can also benefit from that thoroughness of

engineering, in terms of

 Presentation of evidence

Safety & Security for the Connected World

For further information visit