The automotive industry is a highly competitive and regulated industry in terms of innovation and standardization. A delay in rolling out of new technology by one OEM can prove to be a blessing for another. Add to it the concept of Functional Safety (ISO 26262) and you have a plethora of parameters to meet, which only increases the time-to-market.
The race to develop robust software in a tight timeframe has prompted the automotive product engineering companies and OEMs to adopt a fast and efficient software development methodology.
While analysis records are fundamental requirement of ISO 26262 standard, AGILE methodology is more inclined towards working software than the documentation. This practice helps save a lot of time and cost. You can see the contrast very clearly here. However, since AGILE is a proven methodology for reducing development time, the automotive stakeholders decided to ditch the concept of ‘pure Agile’ and instead modify it to suit their requirements.
How do the automotive developers align Agile and ISO 26262? How does ISO 26262’s concept of extensive analysis record keeping and Agile’s ‘working software’ concept go hand in hand? We will try to answer these questions but first let us understand both Agile methodology and ISO 26262 standard in brief.
Commandments of Agile Methodology
Agile is centered around the idea of iterative development. It implies that the solution evolves as the teams interact for continuous planning and improvement through learnings. It brings about flexibility and dynamism in the problem-solving approach.
There are 4 core values that define Agile:
- Individuals and team interactions are given more importance than tools and processes
- Working software is preferred over documentation (artifacts)
- Customer collaboration is preferred over contract negotiation
- Response to changes takes precedence over adherence to a plan
Based on these core values, Agile puts customer’s satisfaction at the forefront by ensuring fast delivery of a highly efficient software. Even if the requirements change at a later stage of the development lifecycle, it is welcomed by the developers.
Team members are supposed to meet face-to-face for information exchange as Agile considers it to be the best way of interaction. Daily meetings ensure that the entire team is on the same page and none of the team members are facing any kind of issue.
Now to put things in perspective, we will delve into the Functional Safety aspect of automotive software development.
Fundamentals of Functional Safety w.r.t Automotive Hardware and Software Development
A gamut of electronic and electrical systems operates in automobiles. The risks and resulting hazards emanating from the systems must be minimized for the safety of the passengers. The aspect of safety that may be compromised due to the function of a system is called Functional Safety. It covers only the hardware and software part of a system. In the context of an automobile, ISO 26262 standard has been created to ensure functional safety.
For an automotive hardware or software to be Functional Safety compliant, it must adhere to the practices mentioned in the various parts of the ISO 26262 standard.
The standard considers a V-cycle model for product development which is iterative in nature, and hence, similar to Agile. However, ISO 26262 standard is deeply focused on analysis records which is in a sharp contrast with Agile. The analysis records assume a lot of importance in ISO 26262 compliance as they serve as the evidence to support the activities performed during the safety lifecycle.
As you may have noticed, Agile and ISO 26262 are two different worlds that the automotive industry aspires to connect. The resulting conflicts and how they are resolved make for an interesting read.
AGILE + Functional Safety: The Conflicts and Opportunities
The difference in the basic principles of both concepts brings in a lot of contradiction. While Agile’s goal is satisfaction of the customer, Functional Safety deals with mitigating risk to life. There is a huge difference there!
Following is a list of conflicts that arise when Agile and FuSa are brought together:
| ISO 26262 Standard for Functional Safety | Agile Methodology |
| Requirements are paramount and must be very clearly defined | Requirements take the form of user stories it is acceptable to accept new requirements at a later stage |
| All safety goals identified during HARA must be met | If a customer accepts a failure, it need not be removed |
| Clearly defined unit test, integration test and V&V required | Tests are flexible; no or very little documents required |
| To establish accountability, change management is documented thoroughly | More of informal and verbal information exchange is encouraged to reduce development time |
| Interaction with non-Agile team and including hardware development is common | Agile is meant for software development only as it finds its roots in IT related development |
| Whether it is a working or non-working software, a record must be maintained in either case | Agile is only focused on continuous delivery of working software without worrying too much about maintaining record of every small detail |
While the conflicts appear discouraging, they in fact pave the way for a thoughtful implementation of Agile methodology in a safety lifecycle.
A little tweaking of Agile methodology conjures up the magic. It begins with pre-defined compliance workflow and approval process workflow and is executed by carefully planned scrum meetings and user roles.
Agile Practices Suitable for Safety Critical Software (SCSW) Development
There are more than 70 identified Agile practices and most of them cannot be used as-is during an ISO 26262 compliant software development. One such subset or Agile practice is Scrum which is modified for SCSW.
Let’s look at the roles, workflows and artifacts to be considered in Scrum.
Understanding the various roles:
| Product Owner (PO) | Scrum Master | Development Team | Safety Manager |
| Accountable for the product and its ISO 26262 compliance
Supported by the Safety Manager, PO creates safety related backlogs. Eg. Safety mechanism development |
Ensures that the organization-specific processes and safety-related processes are adhered to.
FuSa achievement related information is shared by Scrum Master |
Derives, implements, and tests Software safety requirement (SSR)
Performs safety analyses such as FMEA, FTA, DFA, etc. Ensures test coverages, ISO 26262 programming guidelines, tool confidence, etc. are followed |
Ensures that the team adheres to the safety plan and organization-specific processes
Supports the PO in activities including safety-related backlog creation Works with the development team in all safety-related activities |
Agile & ISO 26262 Workflow and Artifacts
Sprint Planning I & II: Sprint planning is an extremely important activity attended by the Product Owner, Scrum Master and the scrum team. In the Sprint Planning I phase, the Product Owner introduces the main sprint task to the team. In the 2nd sprint planning phase, the team creates a Sprint Backlog and also a Sprint Retrospective.
Daily Scrum Meeting: This is a communication activity highly recommended for the adoption of Agile in ISO 26262 software development. The focus of the meeting is to discuss and solve the current problems faced by teams and plan for the future. A safety expert must be involved in this meeting in order to assess the safety impact of the completed work.
Sprint Review: A sprint review meeting is conducted after each sprint and is a very important aspect of SafeScrum. During a sprint review, a coded and tested piece of software is presented for review. All kinds of errors such as modelling errors, tool errors or source code errors are reviewed at this stage.
Retrospective: This is among the communication activities performed at the end of one or more sprints. This activity is helpful in ensuring that the team is working in the right direction and if any improvement is required.
Backlog Refinement: During the sprint planning, the requirements are split into safety and non-safety critical requirements. After the splitting, each of these requirements are inserted into backlogs. The safety requirements are also tagged based on the ASIL value. This backlog needs to be refined by the Product Owner, Scrum Master and Safety Manager. This refinement leads to better understanding of the requirements and their efficient implementation.
The artifacts from the Scrum are Product backlog, sprint backlog, task board and a few more.
Key Takeaways
Various instances of combining Agile with ISO 26262 have provided ample evidence that it can be quite beneficial. Not only does this union promote faster time-to-market, but the developers also get complete control over the processes without worrying about the traceability issues. Additionally, Agile practices can support the V-model of development if used in a pragmatic manner. This makes the adoption of Agile in ISO 26262 software development even more realistic.
