Lines Matching +full:- +full:- +full:no +full:- +full:function +full:- +full:coverage

9 This document is the safety documentation providing an overview over the safety-relevant activities
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
57 electrical, electronic, and programmable electronic safety-related systems. Here's an overview of
65 (SIL) to classify the level of risk reduction required for each safety function. The higher the
74 safety-related system to ensure that it meets the specified SIL and other safety requirements.
79 documentation process to ensure that all aspects of the safety-related system are fully
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
99 .. figure:: images/IEC-61508-basis.svg
102 :figclass: align-center
113 as an existing pre-condition and therefore the "quality managed" status should be pursued for any
121 c. Test coverage
129 Basic software quality standards - Safety view
133 pre-condition and what needs to be done to achieve an auditable code base from the safety
138 -----------------
147 Also the **IEC 61508 standard** sets a pre-condition and recommendation towards the use of coding
151 -------------------------------------
161 Also the IEC 61508 standard highly recommends (which is like a must-have for the certification)
164 Test coverage
165 -------------
167 A high test coverage, in turn, is evidence of safety that the code conforms precisely to what it
169 and has a high (ideally 100%) test coverage, it has the additional advantage of quickly detecting
171 requirements apply to safety for test coverage, and various metrics must be considered, which are
175 * Structural test coverage (entry points) 100%
176 * Structural test coverage (statements) 100%
177 * Structural test coverage (branches) 100%
179 If the 100% cannot be reached (e.g. statement coverage of defensive code) that part needs to be
193 --------------------------
200 very high level, and thus it can be determined which functionalities are safety-relevant and can be
205 -----------------------
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
213 ------------------------------------------------------------------------------
216 functionalities can be disabled within components. This is because if a function is absolutely
224 .. figure:: images/zephyr-safety-process.svg
227 :figclass: align-center
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
254 "auditable" state, and ideally no further changes should be necessary or made to the code base.