Lines Matching full:the
9 This document is the safety documentation providing an overview over the safety-relevant activities
10 and what the Zephyr Project and the Zephyr Safety Working Group / Committee try to achieve.
12 This overview is provided for people who are interested in the functional safety development part
13 of the Zephyr RTOS and project members who want to contribute to the safety aspects of the
19 In this section we give the reader an overview of what the general goal of the safety certification
29 #. Changes will be submitted from the interested party(ies) via pull requests to the Zephyr
32 #. The Zephyr Safety Committee will review these changes and provide feedback or acceptance of
33 the changes.
35 #. Once accepted, these changes will become part of the document.
40 The general scope of the Safety Committee is to achieve a certification for the `IEC 61508
41 <https://en.wikipedia.org/wiki/IEC_61508>`__ standard and the Safety Integrity Level (SIL) 3 /
42 Systematic Capability (SC) 3 for a limited source scope (see certification scope TBD). Since the
43 code base is pre-existing, we use the route 3s/1s approach defined by the IEC 61508 standard.
46 *Assessment of non-compliant development. Which is basically the route 1s with existing
50 *Compliant development. Compliance with the requirements of this standard for the avoidance and
56 The IEC 61508 standard is a widely recognized international standard for functional safety of
58 some of the key safety aspects of the standard:
60 #. **Hazard and Risk Analysis**: The IEC 61508 standard requires a thorough analysis of potential
61 hazards and risks associated with a system in order to determine the appropriate level of safety
64 #. **Safety Integrity Level (SIL)**: The standard introduces the concept of Safety Integrity Level
65 (SIL) to classify the level of risk reduction required for each safety function. The higher the
66 SIL, the greater the level of risk reduction required.
68 #. **System Design**: The IEC 61508 standard requires a systematic approach to system design that
69 includes the identification of safety requirements, the development of a safety plan, and the
70 use of appropriate safety techniques and measures to ensure that the system meets the required
73 #. **Verification and Validation**: The standard requires rigorous testing and evaluation of the
74 safety-related system to ensure that it meets the specified SIL and other safety requirements.
75 This includes verification of the system design, validation of the system's functionality, and
76 ongoing monitoring and maintenance of the system.
78 #. **Documentation and Traceability**: The IEC 61508 standard requires a comprehensive
79 documentation process to ensure that all aspects of the safety-related system are fully
80 documented and that there is full traceability from the safety requirements to the final system
83 Overall, the IEC 61508 standard provides a framework for the design, development, and
84 implementation of safety-related systems that aims to reduce the risk of accidents and improve
85 overall safety. By following the standard, organizations can ensure that their safety-related
86 systems are designed and implemented to the highest level of safety integrity.
90 The IEC 61508 standard was selected because it serves as a foundational functional safety standard
93 for Zephyr, as the operating system's versatility allows it to be effectively utilized across a
96 The following diagram illustrates the relationship between the IEC 61508 standard and other related
109 Quality is a mandatory expectation for software across the industry. The code base of the project
113 as an existing pre-condition and therefore the "quality managed" status should be pursued for any
114 project regardless of the functional safety goals. The following list describes the quality goals
132 In this chapter the Safety Committee describes why they need the above listed quality goals as
133 pre-condition and what needs to be done to achieve an auditable code base from the safety
135 are used to minimize the error rate during code development.
140 The coding guidelines are the basis to a common understanding and a unified ruleset and development
141 style for industrial software products. For safety the coding guidelines are essential and have
142 another purpose beside the fact of a unified ruleset. It is also necessary to prove that the
143 developers follow a unified development style to prevent **systematic errors** in the process of
144 developing software and thus to minimize the overall **error rate** of the complete software
147 Also the **IEC 61508 standard** sets a pre-condition and recommendation towards the use of coding
154 very important in terms of safety. On the one hand, this specifies and describes in detail and on a
155 technical level what the software should do, and on the other hand, it is an important and
156 necessary tool to verify whether the described functionality is implemented as expected. For this
157 purpose, tracing the requirements down to the code level is used. With the requirements management
158 and tracing in hand, it can now be verified whether the functionality has been tested and
159 implemented correctly, thus minimizing the systematic error rate.
161 Also the IEC 61508 standard highly recommends (which is like a must-have for the certification)
167 A high test coverage, in turn, is evidence of safety that the code conforms precisely to what it
168 was developed for and does not execute any unforeseen instructions. If the entire code is tested
169 and has a high (ideally 100%) test coverage, it has the additional advantage of quickly detecting
170 faulty changes and further minimizing the error rate. However, it must be noted that different
172 prescribed by the IEC 61508 standard for the SIL 3 / SC3 target. The following must be fulfilled,
179 If the 100% cannot be reached (e.g. statement coverage of defensive code) that part needs to be
180 described and justified in the documentation.
187 designs and implementations are not reasonable in safety, so that the overall software and code
189 already been implemented in the Zephyr project and need to be verified by the Safety Committee /
190 Safety Working Group and the safety architect.
195 The **IEC 61508 standard** strongly recommends a modular approach to software architecture. This
196 approach has been pursued in the Zephyr project from the beginning with its layered architecture.
197 The idea behind this architecture is to organize modules or components with similar functionality
198 into layers. As a result, each layer can be assigned a specific role in the system. This model has
199 the advantage in safety that interfaces between different components and layers can be shown at a
202 which are important for certification and the responsible certification body.
207 Encapsulated components are an essential part of the architecture design for safety at this point.
208 The most important aspect is the separation of safety-relevant components from non-safety-relevant
209 components, including their associated interfaces. This ensures that the components have no
215 Another requirement for the overall system and software environment is that individual
218 functionalities should be able to be turned off. The Zephyr Project already offers such a
219 possibility through the use of Kconfig and its flexible configurability.
231 The diagram describes the rough process defined by the Safety Committee to ensure safety in the
232 development of the Zephyr project. To ensure understanding, a few points need to be highlighted and
233 some details explained regarding the role of the safety architect and the role of the safety
234 committee in the whole process. The diagram only describes the paths that are possible when a
237 #. On the main branch, the safety scope of the project should be identified, which typically
238 represents a small subset of the entire code base. This subset should then be made auditable
240 (`Quality`_) and safety processes within this scope. The Safety Architect works alongside the
241 Technical Steering Committee (TSC) in this area, monitoring the development process to ensure
242 that the architecture meets the safety requirements.
244 #. At this point, the safety architect plays an increasingly important role. For PRs/issues that
245 fall within the safety scope, the safety architect should ideally be involved in the discussions
246 and decisions of minor changes in the safety scope to be able to react to safety-relevant
248 influential change or improvement that requires extended discussion or decision-making, the
249 safety architect should bring it to the attention of the Safety Committee or the Technical
250 Steering Committee (TSC) as appropriate, so that they can make a decision on the best course of
253 #. This section describes the certification side. At this point, the code base has to be in an
254 "auditable" state, and ideally no further changes should be necessary or made to the code base.
255 There is still a path from the main branch to this area. This is needed in case a serious bug or
256 important change is found or implemented on the main branch in the safety scope, after the LTS
257 and the auditable branch were created. In this case, the Safety Committee, together with the
258 safety architect, must decide whether this bug fix or change should be integrated into the LTS
259 so that the bug fix or change could also be integrated into the auditable branch. This
261 to the safety documentation or third as both.
263 #. This describes the necessary safety process required for certification itself. Here, the final
265 during the certification, and which are prescribed by the certifying authority and the standard
266 being certified. If the certification body approves everything at this stage and the safety
269 #. This transition from the auditable branch to the main branch should only occur in exceptional
270 circumstances, specifically when something has been identified during the certification process
271 that needs to be quickly adapted on the “auditable” branch in order to obtain certification. In
272 order to prevent this issue from arising again during the next certification, there needs to be
273 a path to merge these changes back into the main branch so that they are not lost, and to have
274 them ready for the next certification if necessary.
277 Safety should not block the project and minimize the room to grow in any way.
280 **TODO:** Find and define ways, guidelines and processes which minimally impact the daily work
281 of the maintainers, reviewers and contributors and also the safety architect itself.