https://www.mdu.se/

 Safety-critical systems usually need to comply with a domain-specific safety standard, which often require a safety case in form of an explained argument supported by evidence to show that the system is acceptably safe to operate in a given context. Developing such systems to comply with a safety standard is a time-consuming and costly process. Reuse within development of such systems is used to reduce the cost and time needed to both develop the system and the accompanying safety case. Reuse of safety-relevant components that constitute the system is not sufficient without the reuse of the accompanying safety case artefacts that include the safety argument and the supporting evidence. The difficulties with reuse of the such artefacts within safety-critical systems lie mainly in the nature of safety being a system property and the lack of support for systematic reuse of such artefacts.

In this thesis we focus on developing the notion of safety contracts that can be used to facilitate systematic reuse of safety-relevant components and their accompanying artefacts. More specifically, we explore the following issues: in which way such contracts should be specified, how they can be derived, and in which way they can be utilised for reuse of safety artefacts. First, we characterise the contracts as either “strong” or “weak” to facilitate capturing different behaviours reusable components can exhibit in different systems. Then, we present methods for deriving safety contracts from failure analyses. As the basis of the safety-critical systems development lies in the failure analyses and identifying which malfunctions eventually can lead to accidents, we deem that the basis for specifying the safety contracts lies in capturing information identified by such failure analyses within the contracts. Finally, we provide methods for generative reuse of the safety case artefacts by utilising the safety contracts. Moreover, we define a safety contracts development process as guidance for systematic reuse based on the safety contracts. We use a real-world case to demonstrate the proposed process. 

Safety critical systems are those systems whose failure could result in loss of life, significant property damage, or damage to the environment. These systems require high quality and dependability levels in them, where system safety is a major property that should be adequately assured to avoid any severe outcomes. Many safety critical systems in different domains (e.g., avionics, railway, automotive, etc.) are subject to a certification. The certification process is based on an evaluation of whether the associated hazards to a system are mitigated to an acceptable level. Safety cases are often required to demonstrate how a regulatory body can reasonably conclude that a system is acceptably safe from the evidence available. The development of safety cases has become common practice in many safety critical system domains. However, safety cases are costly since they need significant amount of time and efforts to produce. This cost can be dramatically increased (even for already certified systems) due to system changes as they require maintaining the safety case before it can be submitted for certification. Anticipating potential changes is useful since it reveals traceable consequences that will eventually reduce the maintenance efforts. However, considering a complete list of anticipated changes is difficult. What can be easier though is to determine the flexibility of system components to changes.

Sensitivity analysis has been proposed as a useful tool to measure the flexibility of the different system properties to changes. Furthermore, the concept of contracts have been proposed as a means for facilitating the change management process due to their ability to record the dependencies among system's components. In this thesis, we use sensitivity analysis to support changes prediction and prioritisation. We also use safety contracts to record the information of changes that will ultimately advise the engineers what to consider and check when changes actually happen.