Designing Software for Safety is an extremely complicated task, and the ISO 26262 Standard specifies several processes, methods and work products for the same. For a Software Architect who is new to Safety, this information is overwhelming.
Image courtesy: Shutterstock
Here we present an overview on what are the responsibilities of a "Safety" Software Architect and how they are different from that of a typical embedded software architect.
The Safety Software Architect also has some additional tasks:
- Decomposes the SW Safety Requirements with respect to ASIL tailoring
- Performs the Software Safety Analysis and Dependent Failure Analysis
- Support the Software Tool qualification process for tools used for SW development
- Support the qualification of Software components if necessary
Every responsibility stated above is a complex task in itself and has several dependencies that must be taken care of. In our upcoming posts, we will cover some of these in greater detail. Meanwhile, here is a mind map that shows the relationship that a Safety Software Architect has with the different parts and work products of the Standard.
Workproducts that the Software Architect is responsible for
Workproducts that the Software Architect has to support
Workproducts that the Software Architect must be informed about
What are the key challenges that a Safety Software Architect will face?
Safe Systems must be simple. And free of interference from non-safety parts. And designing a simple, technically independent system is perhaps one of the biggest challenges for a Safety Software Architect. Plus there are other non-technical ones too.
1. As with any project, there is never enough time!
This may lead to not following the processes and methods required by the Standard.
Some examples:
Tendency to deliver code before the high level design or detailed design is completed - may lead to identifying violation of Safety goals or requirements at a later phase such as during Integration testing, or during a confirmation review.
Skipping the Safety Analysis and Dependent failure analysis during the Software Architecture stage and doing it later might result in identifying Safety gaps at the fag end of the project, and at worst, may lead to the effect of not being able to achieve compliance to Safety for the targeted model year.
2. Software developers don't understand "Safety"
“Safety requires professionals. It takes specialized training and experience to define what a safe system must do and to verify that it meets its safety requirements”
Source of the text in quote: QNX White Paper qnx_10_truths_safe_systems
Software developers are often Engineers with minimal experience. They may probably be aware of Software development and related (QM) processes, but may not be aware of how to develop a detailed design or code for a Safety critical module. They may not be aware of the additional rules or restrictions that must be followed. They may not have a full understanding of the basic aspects/terms involved in Safety. In an "ideal" world, every developer who must develop a Safety module must be sufficiently trained for it. However, it may happen that they start working on Safety directly, and the formal training does not happen or happens at a later stage.
3. Solutions are decided without sufficient analysis or brainstorming
If Safety related issues are attempted to be fixed without doing a deep analysis, it may leave some other Safety violations uncovered. However, the Architect may face the pressure to offer a fast solution, in which case may not have the time to do an in-depth analysis.
It may seem like these challenges are not directly related to the role of an Architect.
It is not the job of the Architect to ensure that the developer is trained in Safety, or to ensure all processes are followed in order, isn't it? Yes but NO! They are still indirectly related. If a Safety violation is detected at the fag end of the project, it will be the responsibility of the Architect to technically analyze the associated risk and provide solutions. But this retrospection will be extremely time-consuming and complicated, and at worst case, could mean not meeting a Safety goal. It could mean someone's life.
Hence this role should strive to take a proactive approach. This can greatly reduce the occurrence of Safety violations.
Here are some suggestions to ensure that your safety architecture actually gets realized as expected. Please note that these suggestions apply even for non-safety, but we strongly recommend to do it in case for Safety for the big benefits it will reap.
1. Be firm and insist that the process of high level design->detailed design->code is followed. Raise a red flag if code is delivered without design. At least a preliminary design should be made available first before start of coding. This will get the team to have the discipline of following a process and benefiting out of it.
2. Think about project-specific design and implementation guidelines, apart from the Organization-wide guidelines. Ensure that Software developers clearly understand guidelines.
3. Be in close contact with ASIL Software developers. Do not wait until completion of development to do a detailed design or code review. Proactively perform reviews. Perform reviews in an iterative manner. Encourage developers to do static analysis in an iterative manner.
4. For some complex modules, the Architect should get more deeply involved in the detailed design of the module.
5. Ensure that corner cases get verified in SW Integration test. Usually the obvious, direct functionality will be covered by testing. But special scenarios, e.g., performance or stress scenarios, robustness related scenarios that may be discovered by high level and detailed design may not be tested. Provide specific verification criteria to Integration testers to test every corner case.
6. Synergize to create the best technical solutions. Deciding Solutions solely under stress may also lead to overlooking a scenario. Hence, whether it may be a proposal for a concept, or a solution for a Safety violation, it may be a good idea to have a brainstorming session with the team to come up with as many solutions as possible, and then decide the best one. To get varying perspectives, involve different roles in the discussion - such as a Systems Engineer, Functional Safety Engineer, Software developer and a Software Integrator.