This section can be considered the last step of the proposed method. The main reason behind doing this as part of the dissertation is that STPA has no method of verifying that the safety constraints proposed are correct. Thus our associated research question is How to introduce STPA with assume-guarantee contract to verify safety constraints? What are the steps to verify the safety constraints against system model?
System / software verification concentrates on showing functional correctness of the system and demonstrating that the system fully satisfies all functional requirements. However, the functional require- ments do not make the system safe or reduce the risk level of the system. Therefore, the system should be
analyzed with respect to safety aspects and verified against its safety requirements at component / system level.
The overall objective of this part of the dissertation is to demonstrate the possibility of verifying safety-critical software (i.e architecture model) against safety constraints which are derived at the component / system level. Generally, to control the criticality of safety critical software, we need to identify the potential hazards using the error ontology as a guide and then demonstrate that a potential hazard could not occur (i.e the software of the system cannot contribute to an unsafe state).
The contribution of this work is to introduce the feedback control loop architecture with safety verification procedures to verify the identified safety constraints and to show that hazards have been mitigated or controlled to an acceptable level of risk. In addition, our contribution could assist stakeholders with reducing the amount of time and effort by doing safety analysis and verification of the safety requirements on the same system architecture rather than doing them separately.
The procedure consists of the following steps:
1. Identify an assume-guarantee contract for each component: This step is the construction of a feedback control loop architecture with assumptions (A) describing expectations the component makes about the environment and guarantees (G) describing the behavior the component makes about its output if the assumptions are met.
2. Identify mathematical notations for each component: This step involves identifying expressions for each component based on the mathematical notations which are described in previous sections. For example, using FS, FC, FA, FCPas functions for the components in the implementation of the component,
and using V me,CA,V ma,V c as input/output for components in the specification.
3. Identify safe behavior for the top level system: This step assists in identifying guarantee of safe behavior in the overall system which depends on the guarantee of correct output of each component in the feedback control loop architecture. The notation inside the the figure 3.4 demonstrates this. 4. Satisfy safety constraints: This step assists in verifying the identified safety requirements against
system model. We need to show that the model of the system satisfies the derived safety constraints. Previously, we built the safety constraints with regard to context of the error types. For example, our safety constraint, (The system should not accept null values), is identified as an omission error in the error ontology; it can also be mapped to one of the unsafe control actions in STPA which is (not
providing control action). If the system does not accept null values, it means the system satisfies the safety constraint against system model.
Consider figure 3.4 which introduces the feedback control loop architecture with compositional rea- soning. The main advantage of this introduction is it mitigates the unsafe control action, the wrong decision of the controller that has been made based on the received incorrect values. To eliminate this action, we can make a guarantee for the output of the sensor, at the same time, constructing an assumption input for the controller. As a result, validate that the sensor does not send incorrect values to the controller leading to a safer system. This type of analysis can provide a certainty about behavior for the system and ensure that the system is not behaving incorrectly.
Table 3.4 helps to ensure the controller does not follow/execute the unsafe control actions because there is a contract among components such as sensor-controller, controller-actuator, actuator-controlled pro- cess, and controlled process-sensor. For example, we build the following safety constraints based error on- tology context:
SC1: The controller has a guarantee to not receive null values from the sensor. (Omission error value)!! SC2: The controller has a guarantee to not receive unintended incoming values from the sensor. (Commission error value)!! SC3: The controller has a guarantee to do an action within defined time range. (Timing error)!!
When we verify the SC1, the controller mitigates one of the unsafe control actions which is [Action required but not provided] that can lead to hazards. In addition, when we verify SC2, the controller mitigates another unsafe control action which is [Unsafe action provided], and so on.
Table 3.4: Mitigating the unsafe control actions
STPA Error Ontology A/G Contract
Action required but not provided Omission service error types SC1 Unsafe action provided Commission service error types SC2 Action provided too early/too late Service timing errors SC3 Provided action stopped too soon/applied
too long
Sequence commission (early start/late ter- mination)
Chapter 4
Analysis and Evaluation
In this section, we evaluate our compositional safety analysis method, Architecture Safety Analysis Method (ASAM), used for developing safety-critical systems. Our method will allow system stakeholders or safety analysts to mitigate the effects of errors through safety constraints developed during the construction of software architecture. In the method, we focus on finding safety constraints and verifying them within the system model. To do so, we inject the AADL error ontology into the architecture model to identify the unsafe control actions and causal factors of the unsafe control actions. We verify the safety constraints that we generate within the system model to ensure the hazardous situations are sufficiently mitigated through the use of compositional reasoning on the system model.
From a technical perspective, ASAM is a new software safety analysis tool which works with AADL models annotated with an implementation of our formulas (i.e. asam annex, introduced in section 3.3) and supported by the Open Source Architectural Tool Environment (OSATE). It is used to analyze and generate a report based on information attached to each component in the feedback control architecture. In fact, ASAM provides several statements to support discovering hazards such as error statements, error propagation statements, internal failure statements and safety constraint statements that either handle or prevent hazards. The goal of the statements is to describe errors in order to determine their source and prevent propagation. If error propagation cannot be prevented, ASAM can describe how the error is eventually handled as well as what component handles it. Additionally, ASAM lets the safety analyst record the severity level of the hazard for the specific error type based on the probability of occurrence for that type of error as well as verify that a safety constraint properly mitigates the error.
Table 4.1: Evaluation Examples Overview
Safety-Critical System Examples C1 C2 C3 Adaptive Cruise Control System -(ACCS) 4.1.2 4.2.2 − Train Automated Door Control System-(TADCS) 4.1.3 4.2.3 4.3.2
Medical Embedded Device-Pacemaker (PM) 4.1.4 4.2.4 4.3.3 Infant Incubator Temperature Control System-Isolette (ISO) 4.1.5 − −
• Claim C1: Whereas STPA only finds hazards that exist in the communication between the controller and the actuator, ASAM finds errors, that may or may not lead to hazards, that exist in not only in the controller / actuator but other components as well.
• Claim C2: Each error flow in ASAM assists in identifying a safety constraint of appropriate breadth to eliminate the unsafe control actions caused by an identified error. In addition, each error flow can guide us to identify specific causes for the unsafe control action.
• Claim C3: ASAM uses verification, unlike existing safety analysis methods, to further ensure that the safety constraint fully mitigates the hazardous condition improving the quality of the safety constraints. Each claim is discussed individually in the remaining sections. Throughout the evaluation, we will use the safety-critical system examples that were described in the previous chapter such as the adaptive cruise control system (scenario 3.1.1), the train automated door control system (scenario 3.1.2), the pacemaker (scenario 3.1.3), and the isolette (scenario 3.2.1). For each of our selected examples, we will present the implementation of the scenarios, some of which will be reused across evaluations.