Reusable Software Components in Safety-Critical Real-Time Systems

Safety Critical Systems

Safety-Critical Systems (SCS) are systems that may result in harm or loss of human life when they fail to perform their function.lIn some SCS domains, e.g. automotive, railway or avionics nuclear power plants, rockets, defence equipment, the systems must be certified according to a set of domain specific safety standards. As a part of certification, a safety case in form of an explained and well founded structured argument is often required to show that the system is acceptably safe to operate.

Building a safety case is based on human reasoning and expert judgement and is mainly manual or semi-automatic work.

The use of off-the-shelf (OTS) items in SCS has been debated for many years . Some of the OTS items, as recognised by the standards, are commercial off the shelf items and software of unknown pedigree. While the first are developed by the standards, the latter are not developed to bespoke standards.

Applying CBSE for development of SCS poses particular challenges. From the perspective of safety and certification, addressing these challenges is even more important when trying to apply CBSE.

“We have become dangerously dependent on large software systems whose behaviour is not well understood and which often fail in unpredictable ways.”

US President's IT Advisory Committee, February 1999

Impact of Safety Critical System Failure

Example of Safety Critical System

Medical Science : Infusion Pumps, Robotic Surgery

Nuclear Engineering : Nuclear Reactor, Nuclear Waste Management

Aviation : Air Traffic Control, Electronic Throttle, Avionics

Spaceflight : Rocket Range

Examples of Critical System Failure due poor software quality

Therac - 25 radiation therapy machines delivered radiation overdoses to a number of patienets in Canada and the USA. Most interlocks were software based.Ariane 5 (1996) : The unmanned Ariane 5 European spacecraft was destroyed less than a minute after the launch on it's maiden flight, due to poor version of software. Mars Climate Orbiter (1999) :Loss of Spacecraft when it entered in the Martian AtmosphereUK Inland Revenue (2004) : Credit payment system lead to a $3.54 billion tax credit overpayment

Challenges posed SCS

1) Verification by testing is impossible for systems that have to operate in what has been called the ultra-dependable range. High performance, rapid, comprehensive approaches to verification will be essential if we are to have confidence in the wide variety of safety-critical systems that we expect.

2) Development time and effort for safety-critical systems are so extreme with present technology that building the systems that will be demanded in the future will not be possible in many cases.

3) Breakdowns in the interplay between software engineering and systems engineering remains a significant cause of failures. It is essential that comprehensive approaches to total system modelling be developed so that properties of entire systems can be analysed.4) Defective software specifications are implicated in many serious failures, and it is clear that we have difficulty stating exactly what software is required to do.

5) Security is becoming an increasingly important topic in the field of safety-critical systems, and it must be addressed comprehensively if safety-critical systems are to be operated successfully. The challenge here lies very much in the field of software engineering rather than security technology. The vast majority of security problems that arise in networked information systems arise because software defects make the systems vulnerable to attack.

Finally, it is important to raise awareness of the current limitations of software engineering. Engineering of safety-critical systems is a complex task involving many technical fields. Software is a key component of any safety-critical system yet far too few engineers in other disciplines understand what software can and cannot do.

Contracts

In order to support the broadening of the context and reuse between different contexts, we are proposing contracts that specify all the properties that an environment must satisfy separately from the guarantees and assumptions that are required to hold only in some context. For a primitive component type we can check that the implementation satisfies the contract by ensuring that the code will deliver guaranteed functionality in all contexts satisfying the assumptions, i.e., that the contract implications hold.

We can check consistency of its contracts and the contracts of the subcomponents in two separate steps:1. By checking that all strong assumptions in a subcomponent that are not satisfied by the composition with other subcomponents are ensured by the strong assumption in the composite component contract2. By checking that the composite component contract follows from the subcomponent contracts and the interconnections.

Pre- and Post-conditions

Telephone A

0...1027

G...P

345...640

Pre-condition ( (0 input1 1027) && (”G” input2 ”P”) ) // pre-condition statement 1; . . . statement n;Post-condition(345 output 640 ) // post-condition

A component with Pre- and Post-conditions

Updated Pre- and Post-conditions

Telephone B

-17...778

A...F

5...123

Pre-condition ( (-17 input1 1027) && (”A” input2 ”P”) ) // pre-condition statement 1; . . . statement n;Post-condition (45 < output < 640 ) // post-condition

A new environment would violate the pre- and

post-conditions unless they are updated

Reliability and Confidence for a Input

Domain

R(c)

C(c)

I(c)0 1027

A graph representing the reliability and the confidence for a input domain

Lower Reliability Requirements

R(c)

C(c)

I(c)0 1027

A component reused in a context with lower reliability requirements 

Reaching Desired Reliability

R(c)

C(c)

I(c)0 1027

The component must be run for a longer time to reach the desired reliability

Previously Experienced Reliability

R(c)

C(c)

I(c)0 1027

Previously experienced reliability cannot be utilized ifinput domains are outside historical use of the component

Conclusion

A critical system is a system where failure can lead to high economic loss, physical damage or threats to life.The dependability in a system reflects the user’s trust in that systemThe availability of a system is the probability that it will be available to deliver services when requestedThe reliability of a system is the probability that system services will be delivered as specifiedReliability and availability are generally seen as necessary but not sufficient conditions for safety and security

Conclusion

Reliability is related to the probability of an error occurring in operational use. A system with known faults may be reliableSafety is a system attribute that reflects the system’s ability to operate without threatening people or the environmentSecurity is a system attribute that reflects the system’s ability to protect itself from external attackDependability improvement requires a socio-technical approach to design where you consider the humans as well as the hardware and software

Varun Ojha – 2K11/SE/082 Sagar Singhal-2K11/SE/062 Osank Jain- 2K11/SE/046 Mohit Mehta-2K11/SE/042 Saurabh Arora-2K11/SE/064