logseq/pages/@Automated Integration of Safety Mechanisms into Functional Software for Safety-relevant Systems.md

tags:: #zotero title:: @Automated Integration of Safety Mechanisms into Functional Software for Safety-relevant Systems item-type:: journalArticle original-title:: Automated Integration of Safety Mechanisms into Functional Software for Safety-relevant Systems language:: en authors:: Rolf Schmedes, Gregor Nitsche, Kim Grüttner library-catalog:: Zotero links:: Local library, Web library

• Abstract
  • Embedded systems have become indispensable in areas such as aerospace, the automotive industry, medical technology, and industrial control. Ensuring their reliable and safe operation is crucial for safeguarding human life and valuable assets. Software safety mechanisms play a key role in ensuring safety in these safety-relevant systems. International standards, such as IEC 61508, define necessary safety mechanisms to mitigate risks and achieve certification. This circumstance leads to an unchanging and recurring set of safety mechanisms that are manually re-implemented again and again from project to project. To make this software development process more efficient, this paper presents a model-based approach that utilizes a strict separation between functional and safety software to integrate safety mechanisms automatically into functional software for safety-related systems. An automated analysis of existing functional source code and the targeted hardware platform identifies possible integration points for safety mechanisms. A configuration a safety engineer creates is then used to integrate safety mechanisms from existing libraries through code generation. In addition to this approach, a prototypical implementation and its exemplary application are also described in this paper.

• Attachments

  • Schmedes et al. - Automated Integration of Safety Mechanisms into Functional Software for Safety-relevant Systems.pdf {{zotero-imported-file SJVW878V, "Schmedes et al. - Automated Integration of Safety Mechanisms into Functional Software for Safety-relevant Systems.pdf"}}

• Notes

  • Annotazioni

    (22/6/2024, 10:19:57)

    • “Ensuring their reliable and safe operation is crucial for safeguarding human life and valuable asset” (Schmedes et al., p. 1) #5fb236

  - “safety mechanisms that are manually re-implemented again and again from project to project” (Schmedes et al., p. 1) #a28ae5
  * *
  
   
  
  - “model-based approach that utilizes a strict separation between functional and safety software to integrate safety mechanisms automatically into functional software for safety-related systems” (Schmedes et al., p. 1) #a28ae5
  * *
  
   
  
  - “identifies possible integration points for safety mechanisms.” (Schmedes et al., p. 1) #ffd400
  *Interesting to see how!!! *
  
   
  
  - “software that is designed and implemented to ensure that it operates correctly and reliably, particularly in critical or hazardous situations where failures could lead to harm, injury, or damag” (Schmedes et al., p. 1) #5fb236
  * *
  
   
  
  - “Functionally safe software is the combination of functional software and safety software” (Schmedes et al., p. 1) #a28ae5
  * *
  
   
  
  - “systematic and rigorous process that considers the software’s functional and safety-related aspects.” (Schmedes et al., p. 1) #a28ae5
  * *
  
   
  
  - “Following those standards, the software design includes both the design of the functional software and the design of the safety software” (Schmedes et al., p. 1) #a28ae5
  * *
  
   
  
  - “integration of safety mechanisms increases the complexity of the overall code base” (Schmedes et al., p. 1) #5fb236
  * *
  
   
  
  - “no clear separation between functional and safety software.” (Schmedes et al., p. 1) #a28ae5
  * *
  
   
  
  - “Modifications to functional code may impact safety mechanisms and vice versa” (Schmedes et al., p. 1) #a28ae5
  * *
  
   
  
  - “Changes must be carefully analyzed to ensure they do not compromise safety requirements or introduce new risks.” (Schmedes et al., p. 1) #5fb236
  * *
  
   
  
  - “This tight coupling makes it more challenging to implement changes without affecting other aspects of the system.” (Schmedes et al., p. 1) #a28ae5
  * *
  
   
  
  - “assumption that a set of unchanging safety mechanisms must be implemented for the software system of a safety-relevant product.” (Schmedes et al., p. 1) #ffd400
  *How strong/realistic is this assumption? IN the previous paragraphs authors have stressed the fact that software systems evolve and the coupled evolution of functionalities and software mechanisms occurs and it has to be properly managed. *
  
   
  
  - “his work presents a semi-automated process for integrating safety software mechanisms for safety-relevant systems.” (Schmedes et al., p. 1) #a28ae5
  * *
  
   
  
  - “weaving that is as automated as possible.” (Schmedes et al., p. 1) #a28ae5
  *This reminds me generative programming and aspect oriented programming...... *
  
   
  
  - “The subsequent demonstration section shows the results using the example of an adaptive cruise controller.” (Schmedes et al., p. 2) #5fb236
  * *
  
   
  
  - “chapter” (Schmedes et al., p. 2) #ff6666
  *SECTION *
  
   
  
  - “unctionally safe software” (Schmedes et al., p. 2) #5fb236
  * *
  
   
  
  - “software safety mechanisms required by common standard” (Schmedes et al., p. 2) #5fb236
  * *
  
   
  
  - “guidelines for designing, implementing, and maintaining systems intended for safety-relevant applications” (Schmedes et al., p. 2) #5fb236
  * *
  
   
  
  - “in [8]” (Schmedes et al., p. 2) #ffd400
  *What's the novelty with respect to this work? *
  
   
  
  - “IEC 61508 is based on the principle that any safety-related system should either function correctly or fail predictably and safely under all possible stated conditions” (Schmedes et al., p. 2) #a28ae5
  * *
  
   
  
  - “the safety life cycle, consisting of 16 phases to achieve this objective.” (Schmedes et al., p. 2) #5fb236
  * *
  
   
  
  - “probabilistic failure approach to categorize the safety implications of a component’s failure” (Schmedes et al., p. 2) #5fb236
  * *
  
   
  
  - “hazard identification, analysis, and risk assessment” (Schmedes et al., p. 2) #5fb236
  * *
  
   
  
  - “Quantification of risk can be achieved through either qualitative or quantitative analysis techniques” (Schmedes et al., p. 2) #a28ae5
  * *
  
   
  
  - “safety integrity level (SIL)” (Schmedes et al., p. 2) #5fb236
  * *
  
   
  
  - “Safety integrity is defined as the likelihood that the safety-related system will effectively execute the necessary safety functions under all specified conditions” (Schmedes et al., p. 2) #5fb236
  * *
  
   
  
  - “Four distinct safety integrity levels outline the requirements for a particular function” (Schmedes et al., p. 2) #a28ae5
  * *
  
   
  
  - “to achieve a higher risk reduction, the safetyrelated system must have a higher reliability, which requires a correspondingly higher target SIL” (Schmedes et al., p. 2) #a28ae5
  * *
  
   
  
  - “The compatibility of those mechanisms with the presented approach will be discussed in the concluding section of this paper.” (Schmedes et al., p. 2) #ffd400
  *Their compatibility with the proposed approach has been something consedered by design, or it happend "by accidence"? *
  
   
  
  - “Safety Mechanisms” (Schmedes et al., p. 2) #5fb236
  * *
  
   
  
  - “Contracts” (Schmedes et al., p. 2) #5fb236
  * *
  
   
  
  - “Dual Modular Redundancy” (Schmedes et al., p. 3) #5fb236
  * *
  
   
  
  - “safeguarded function is initially executed redundantly” (Schmedes et al., p. 3) #5fb236
  * *
  
   
  
  - “If the results match, there is no error.” (Schmedes et al., p. 3) #a28ae5
  * *
  
   
  
  - “even an external monitoring facility, depending on the actual implementation of the mechanism.” (Schmedes et al., p. 3) #5fb236
  * *
  
   
  
  - “Time Measurement and Control Blocks” (Schmedes et al., p. 3) #5fb236
  * *
  
   
  
  - “However, the complexity compared to AOP is reduced by limiting it to the two basic types of safety mechanisms,” (Schmedes et al., p. 6) #5fb236
  * *
  
   
  
  - “better compromise between complexity and effectiveness.” (Schmedes et al., p. 7) #5fb236
  * *
  
   
  
  - “However, the main distinction from AOP is the combined, holistic view of functional source code, safety mechanisms, and the targeted hardware platform.” (Schmedes et al., p. 7) #5fb236
  * *