Lines Matching full:and
10 and what the Zephyr Project and the Zephyr Safety Working Group / Committee try to achieve.
13 of the Zephyr RTOS and project members who want to contribute to the safety aspects of the
20 is, what standard we aim to achieve and what quality standards and processes need to be implemented
26 This document is a living document and may evolve over time as new requirements, guidelines, or
32 #. The Zephyr Safety Committee will review these changes and provide feedback or acceptance of
41 <https://en.wikipedia.org/wiki/IEC_61508>`__ standard and the Safety Integrity Level (SIL) 3 /
50 *Compliant development. Compliance with the requirements of this standard for the avoidance and
57 electrical, electronic, and programmable electronic safety-related systems. Here's an overview of
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
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
80 documented and that there is full traceability from the safety requirements to the final system
81 design and implementation.
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
86 systems are designed and implemented to the highest level of safety integrity.
93 safety perspective and to be usable for certification purposes. But software quality is not an
95 as an existing pre-condition and therefore the "quality managed" status should be pursued for any
102 b. Requirements and requirements tracing
109 c. Encapsulated single functionality (if not fitable and manageable in safety)
115 pre-condition and what needs to be done to achieve an auditable code base from the safety
122 The coding guidelines are the basis to a common understanding and a unified ruleset and development
123 style for industrial software products. For safety the coding guidelines are essential and have
126 developing software and thus to minimize the overall **error rate** of the complete software
129 Also the **IEC 61508 standard** sets a pre-condition and recommendation towards the use of coding
132 Requirements and requirements tracing
135 Requirements and requirement management are not only important for software development, but also
136 very important in terms of safety. On the one hand, this specifies and describes in detail and on a
137 technical level what the software should do, and on the other hand, it is an important and
140 and tracing in hand, it can now be verified whether the functionality has been tested and
144 requirements and requirements tracing.
150 was developed for and does not execute any unforeseen instructions. If the entire code is tested
151 and has a high (ideally 100%) test coverage, it has the additional advantage of quickly detecting
152 faulty changes and further minimizing the error rate. However, it must be noted that different
153 requirements apply to safety for test coverage, and various metrics must be considered, which are
162 described and justified in the documentation.
167 To create and maintain a structured software product it is also necessary to consider individual
168 software architecture designs and implement them in accordance with safety standards because some
169 designs and implementations are not reasonable in safety, so that the overall software and code
171 already been implemented in the Zephyr project and need to be verified by the Safety Committee /
172 Safety Working Group and the safety architect.
181 the advantage in safety that interfaces between different components and layers can be shown at a
182 very high level, and thus it can be determined which functionalities are safety-relevant and can be
183 limited. Furthermore, various analyses and documentations can be built on top of this architecture,
184 which are important for certification and the responsible certification body.
194 Encapsulated single functionality (if not reasonable and manageable in safety)
197 Another requirement for the overall system and software environment is that individual
201 possibility through the use of Kconfig and its flexible configurability.
203 Processes and workflow
208 :alt: Safety process and workflow overview
211 Safety process and workflow overview
214 development of the Zephyr project. To ensure understanding, a few points need to be highlighted and
215 some details explained regarding the role of the safety architect and the role of the safety
222 (`Quality`_) and safety processes within this scope. The Safety Architect works alongside the
228 and decisions of minor changes in the safety scope to be able to react to safety-relevant
229 changes that are not conformant. If a pull request or issue introduces a significant and
236 "auditable" state, and ideally no further changes should be necessary or made to the code base.
239 and the auditable branch were created. In this case, the Safety Committee, together with the
246 analyses, tests, and documents are created and conducted which must be created and conducted
247 during the certification, and which are prescribed by the certifying authority and the standard
248 being certified. If the certification body approves everything at this stage and the safety
249 process is completed, a safety release can be created and published.
255 a path to merge these changes back into the main branch so that they are not lost, and to have
259 Safety should not block the project and minimize the room to grow in any way.
262 **TODO:** Find and define ways, guidelines and processes which minimally impact the daily work
263 of the maintainers, reviewers and contributors and also the safety architect itself.