If you are an SW SEooC developer, how do you know if you have sufficiently verified your SW? Our 2 -part videos will help you get an answer to this question. If you are new to SEooC, check out our earlier article .
If you have heard about Safety manuals but have not read one, or if you have read a Safety manual, tried to apply it and found it very challenging, this article is for you. In this blog, we talk about: Who needs a Safety manual? What is a Safety manual and what does it describe? Best Practices when working with Safety manuals Interestingly, ISO26262 never mentions “Safety manual” except in Part 11 for Semi-conductors, though its parent IEC 61508 describes the role of Safety manuals. Refer this article . Who needs a Safety manual? Let us assume that you are a Safety Manager or a Systems/Software/Hardware architect involved in the start of an Autonomous driving solution and the Safety goals of the program are at ASIL D. Your technical sales team has already shortlisted two Microcontrollers that are at ASIL D, and now you are asked to evaluate both from a Safety perspective. Your first stop for information is the Safety manual of these Micros. You look through the Safety manual to
Typically, Safety development happens in a top-down approach. We start with identifying hazards and associated Safety goals for an item for a specific vehicle. Then we identify the Safety path in the system for that Safety goal, identify the Safety related HW, SW and System elements, and finally develop these elements in compliance to ASIL. Safety Element Out Of Context (SEooC) development is different from regular Safety development in the sense that it is a bottom-up approach. We first decide what is the HW, SW or System element that must be developed as ASIL and then formulate assumptions on the ASIL level, the Safety goals, the item or System, and the context/environment in which the Safety element will be used. In short, we decide on the scope or boundary for the element. SEooC approach is used for developing SW, HW or System elements where the developer is sure that this element will be used as a Safety element in not just the context of 1 Safety program, but the Safety ele