The safety-critical systems case study

Safety-critical systems engineering has to follow best practises. More specifically, safety standards (such as ISO 26262, ARP4761) provide guidance in terms of reference process models for the development and assessment of such systems. The complexity of such systems is reflected in their supply chain, which consists of a complex, geographically-distributed and heterogeneous supply network. Manufacturers rely on a number of suppliers, who are in charge of supplying software or hardware components needed for the assembly of the systems to be produced or for the automation of certain activities during the production. The reference processes recommended by the standards take into consideration the complexity of the systems and their supply network.

To be released on the market, the integrated systems must be certified. The certifica-tion process in various domains is conducted by scrutinising an argument supporting system safety [98]. In the automotive and rail domains, for instance, such argument is known as the safety case. In the aerospace domain, an explicit safety case is not required however as discussed by Holloway [69] an implicit safety case request is con-tained within the standards. Thus, all safety-critical systems must be accompanied by a safety case that provides assurance. There are two ways of providing assurance (that is building a safety case): by product and by process.

Safety cases can/should also reflect the compositional nature of the systems under

Chapter 5: A Case Study on Cloud-Based Engineering of Safety-Critical Systems

examination. Contract-based safety case fragments should be provided by suppliers and integrated within a complete safety case by the manufacturer, as the safety case structure proposed within EN50129 [3] in the rail domain might suggest. Even the provision of a safety case may follow a reference process [8].

The planning and execution of all the recommended reference processes is a time consuming and costly activity. Moreover, given the compositional and geographically distributed nature of the supply network, different interpretation of the processes may coexist resulting in conflicts and ultimately risk of low-quality products.

While the considerations listed in this chapter hold for several complex safety-critical systems, we focus on aircraft as an example of such systems. To engineer and certify an aircraft, a set of standards is at disposal to address various aspects such as safety assessment; system, software, and hardware engineering, etc. Typically, these stan-dards provide requirements that should be followed to define the process to be used during the development and assessment of the aircraft and the software and hardware to be integrated within the aircraft. To define such process, a safety manager may refer to a reference model or may define a customised one by selecting and composing compliant process elements. To do the latter, the safety manager has to identify: the tasks to be executed in the correct order to consume/produce expected artefacts, roles, specific techniques to be used and in some cases the tools to automate the tasks. A doc-ument aimed at showing process compliance by providing a process-based argdoc-ument is typically required.

Besides the process requirements, safety standards also include product requirements aimed at assessing the level of a product’s safety based on the product’s behaviour against the formulated safety requirements. Various analysis and verification results may be used to show that the product behaves as it should. Since we cannot guarantee that the final product is acceptably safe, standards are recommending to include a product-based argument to assure that the system is acceptably safe [61]. Additional requirements target the assessment process, which in many application domains is conducted by scrutinising an explicit or implicit safety case. A complete safety case as the final output of the assessment process should contain both the process and the product-based arguments to assure that the system development has not only followed the mandated process, but has also resulted in an acceptably safe product.

The case study presented in this chapter uses the Preliminary System Safety Assessment (PSSA) process from ARP4761 [2] as an example of safety-related processes. We model and execute this process in the cloud and use it to validate the claims mentioned in the Table 5.1.

Our vision is that a manufacturer models the planned safety life-cycle as well as the corresponding argumentation process. The process model enactment can be distributed geographically. The stringency (i.e., integrity level) with which the process tasks are performed is indicated via a standardised process modelling language (EXE-SPEM).

By doing this, conflicting interpretations between teams can be reduced.

Using the cloud as an enactment platform not only reduces cost (through the pay-as-you-go and on-demand acquisition models), but also provides an accessible platform for the distributed teams involved in the system engineering process. Additionally, artefacts from across the different geographical locations can be maintained centrally which together with provenance data can facilitate the collection and processing of evidence supporting the system’s safety case. Furthermore, the cloud’s elasticity allows for acquiring more computational resources as needed for computationally intensive tasks.

The evaluation of the SDaaS architecture using this case study is achieved by:

• Instantiating the SDaaS reference architecture (see Chapter 2) and using the in-stantiated prototype to support engineering of safety critical systems.

• Implementing an activity to automate the generation of a fragment of a safety argument arguing about the safety characteristics of the produced system. The fragment is generated by analysing the results of the Failure Logic Analysis (FLA) of the system [54]. The analysis captures product-related evidence (e.g., detecting partial and full mitigators of failures).

• Implementing an activity to automate evidence capturing and automatic gen-eration of process-related safety argument fragments. Process-related evidence include information about the process, stakeholders, tools and standards.

• Enacting an augmented PSSA process with automated safety argument fragments generation and presenting the generated argument fragments in visual, textual

Chapter 5: A Case Study on Cloud-Based Engineering of Safety-Critical Systems

and machine readable formats. These fragments can then be manually integrated within a complete safety case for the system.