Altreonic will present the novel ARRL criterion at the SASSUR (Next Generation of System Assurance Approaches for Safety-Critical Systems) workshop [1] of SAFECOMP2013 on 24th September in Toulouse, France. The paper is co-authored with the Simula Research Lab in Norway (Jose Luis de la Vara) and the University of Antwerp (Vincenzo di Florio).
In summary: ....
Safety engineering standards define rigorous and controllable processes for system development. Nevertheless safety standards differences from distinct domains are non-negligible. This paper focuses in particular on the aviation, automotive and railway standards, all related to the transportation market. Many are the reasons for the observed differences, ranging from historical reasons, heuristic and established practices, and legal frameworks but also from the psychological perception of the safety risks. In particular we argue that the Safety Integrity Levels (SIL) are not sufficient to be used as a top level requirement for developing a safety critical system. We argue that Quality of Service is a more generic criterion that takes the trustworthiness as perceived by users into deeper account. In addition safety engineering standards provide very little guidance on how to compose safe systems from components, while this is the established engineering practice. We develop a novel concept called Assured Reliability and Resilience Level (ARRL) as a criterion that takes the industrial practice into account and show how it complements the Safety Integrity Level concept by taking the fault behaviour and the provided assurance into account.
The table below gives a short summary of the different ARRL levels.
|
ARRL level |
ARRL definition |
|
ARRL-0 |
The component might work (“use as is”), but there is no assurance. Hence all risks are with the user. |
|
ARRL-1 |
The component works “as tested”. No assurance is provided for the absence of any remaining issues. |
|
ARRL-2 |
The component works correctly, if no fault occurs. This means that it is guaranteed that the component has no implementation errors, which requires formal evidence as testing can only uncover testable cases. The component still provides ARRL-1 level assurance by testing as also formal evidence does not necessarily provide complete coverage but should uncover all so-called systematic faults. The component can still fail due to random errors, like an externally induced bit-flip. |
|
ARRL-3 |
The component inherits all properties of the ARRL-2 level and is in addition guaranteed to reach a fail-safe or reduced operational mode upon a fault. This requires monitoring support and architectural redundancy. The fault behavior is predictable as well as the subsequent state after a fault occurs. |
|
ARRL-4 |
The component inherits all properties of the ARRL-3 level and can tolerate one major fault. This corresponds to requiring a fault-tolerant design. This entails that the fault behavior is predictable and transparent to the external world. Transient faults are masked out. |
|
ARRL-5 |
The component inherits all properties of the ARRL-4 level but is using heterogeneous sub-components to handle residual common mode failures. |
The ARRL criterion is not a replacement for the SIL criterion but is complementary in the same sense that HARA (Hazard And Risk Analysis) and FMEA (Failure Mode Effect Analysis) are complementary. However, the ARRL criterion is a first step towards a normative criterion allowing to reuse components across different safety critical domains and across products of the same family. Further work is geared towards refining the criterion so that components can be specified in terms of carrying an ARRL level contract. This includes not only functional properties but also non-functional ones as well as a specification of the environment in which the component can be used, similar to for example the IP-codes [2], but this time also covering digital, software intensive components. The benefits of applying the ARRL criterion is that it is a quality driven one whereby a normative approach is used to classify components in terms of the fault behavior. The economic benefits are long term but clear as well, leading to more trustworthy and quality systems and products at a reduced development cost.
The ARRL criterion is also the driving force behind Altreonic's roadmap and will be reflected more explicitly as top-level requirements in the OpenComRTOS roadmap as well as in the upcoming release of GoedelWorks.
The full paper will be available after the workshop. Interested readers can request a draft (but more complete paper) by email. Meanwhile, the presentation is attached.
Share [3] |
| Attachment | Size |
|---|---|
| SASSUR_2013_full_WIP.pdf [4] | 626.65 KB |