How to apply agile framework in automotive software development
Latest update time：2021-01-01
Reads：
Author: Abhi Rangineni
Translation: Mucheng
1
Preface
In order to ensure the safety and traceability of safety-critical systems in automobiles and to clarify liability identification, the automotive software industry now generally adopts standards such as ISO 26262 and ASPICE as software development methods and processes. . Most suppliers in the automotive industry adopt the traditional "waterfall process" or "V-shaped process" for software development and compile a large number of related supporting documents. This process is not only cumbersome, but also increasingly unsuitable for today's rapidly changing market needs.
There is no doubt that developing automobile control software is a "system engineering". As defined by the current "V-shaped process", first "freeze" the requirements and then let the software and testing teams start their work. This is actually a difficult thing to achieve in engineering practice. Because customer requirements are often constantly changing, and the software team's initial understanding of the requirements is likely to be incorrect.
In fact, in every automotive software project, the software team must go through multiple "loop iterations" to compile a qualified software system, and engineers' precious time and resources are often wasted in these long loop iterations. waste. In order to cope with the increasingly challenging market, more and more software teams now tend to use agile frameworks for software development, and use this to shorten software iteration time and achieve better results while ensuring software security and completeness. Collaboration among cross-functional teams.
However, for most automotive suppliers, agile development processes are currently only used in the product development phase, rather than the entire process of mass production, because agile development processes are still considered to “not meet all aspects of safety-related software development”. Require". Agile frameworks are gaining more and more attention as OEMs such as General Motors and Volvo require suppliers to release software based on Agile Cadence milestones set by OEMs. But the industry is still largely confused about how to apply agile frameworks in the development of safety-critical systems.
So, can the application of agile framework also be ASPICE compliant? Can the application of agile framework continue to follow the ISO26262 standard?
Although applying the ASPICE process does not necessarily guarantee product quality, every high-quality quality process (whether it is an agile process or a traditional V-shaped development process) should comply with the spirit and principles of ASPICE and ISO 26262.
Like any other process, agile processes only work effectively if they are applied correctly by the development team. Copying so-called "agile" processes from other industries in the automotive industry does not necessarily lead to success. If the agile development process is applied to the automotive industry, it must be modified and tailored according to the characteristics of the automotive industry that emphasizes safety and responsibility. This article aims to explore a method of applying agile framework to software development in the automotive industry on the premise of complying with ASPICE and ISO26262 standards.
2
Automotive Software Agile Team
Like traditional agile teams, automotive software agile development teams must also be composed of "cross-functional teams". In addition, if the project team consists of different teams distributed around the world, it will be difficult to establish an agile framework for the project.
Table 1: Automotive Agile Team Composition
Table 1 shows the size and composition of an automotive agile team applying the agile framework discussed in this article. Team members must be able to peer review each other's work to ensure that each work goes through the proper review and approval process.
3
Automotive Software Agile Team Member
Every agile team member must aim to become a "full stack expert"
(Translator's Note: The original text is Generalizing Specialist)
. This means that they have a good knowledge of all aspects of the system they are designing (systems, software, testing and security) while also having a deep and specialized understanding in their own field. To an agile automotive team, such team members are more valuable than pure “experts.” Building such a team of people certainly takes time, but
agile teams
with "T-shaped
[1]
" skills are likely to be more successful.
(Translator’s note: I actually don’t agree with this paragraph. The author thinks of the project team in a somewhat idealistic way. The actual situation is often that if a team member is trained to be a “full-stack expert”, then the first thing he does is The thing is to either change jobs or seek a technical manager position instead of being willing to continue to be a development engineer in the team...because that's who I am haha)
4
Automotive software
agile
development framework
This article discusses how to apply agile development to the typical CV (Concept Validation) and DV (Design Validation) phases of any safety-critical automotive product development. During the CV phase, the focus of product development is to develop a working system and produce an "appropriate" amount of documentation to ensure that a certain level of "due diligence" has been performed during the product development process. Then, the DV stage should reconstruct the software developed in the CV stage to comply with relevant security requirements, industry standards, laws and regulations. Testing in the DV phase should be biased towards proving the safety of the system, such as performing FIT (Fault Insertion Tests) to prove that the software system not only functions correctly but also has complete diagnostic coverage.
Each CV/DV phase can be divided into three different sub-phases to fit the agile framework:
-
Pre-Sprint - analysis, planning and preparation phase
-
Sprint - Applying agile frameworks to develop products
-
Post Sprint – Retrospective and Wrapping Up Phase
Figure 1: A typical automotive software CV phase development process using agile framework
Figure 1 shows a high-level summary of typical CV phases of automotive product development, and also shows the output products obtained when each sub-phase is completed. Figure 1 also compares the agile framework with the traditional V-shaped process to ensure that the software meets the requirements of ASPICE and IS026262 at the end of the sub-phase.
Pre-Sprint stage
During this phase, the software team comes together to discuss and compile key inputs and precursors required for software development. Sprint planning will also be done at this stage. This will help the team clarify its goals and give all team members a clear and unified project plan and project goals.
The Agile Manifesto states that the most effective way to communicate information within a development team is through face-to-face discussion. In the Pre-Sprint phase, face-to-face discussions must be conducted to ensure that the team has unified CV goals, specific delivery dates, milestones, and a clear program board (Program Board).
Figure 2: Pre-Sprint phase
During the CV period, the Pre-Sprint phase generally lasts 4-6 weeks and reaches a DIA (Development Interface Agreement, Development Interface Agreement), system-level requirements and FSC/TSC (Functional Safety Concept) with the participation of all team members. / Technical Safety Concept technical safety concept). These documents will serve as anchors to guide the agile team through the entire CV sprint and ensure that the CV phase has clear goals and task planning.
For the DV phase, Pre-Sprint takes a little longer (8-12 weeks). The Pre-Sprint of the DV stage requires a detailed and systematic analysis of requirements on the working system produced in the CV stage, and conducts HARA (Harzard Analysis, Risk Assessment) and software FMEA to finally form a qualified Safety Case.
(Translator's Note: I'm not sure how to translate Safety Case. It refers to a collection of all safety-related documents. Once compiled successfully, it enters frozen mode to serve as safety guidance for subsequent software development. If a safety liability occurs in the product in the future In the event of an accident, Safety Case is also an important basis for dividing liability.
)
At the end of this phase, the team will create a clear DV backlog
(set of tasks to be performed?)
to guide the team to achieve clear product security goals during the Sprint phase.
Sprint phase:
The Pre-sprint phase sets clear goals for the project, while the Sprint phase is the core of the automotive software agile framework. The agile team will use this to prepare software requirements documents and complete software and conduct complete testing. Each Sprint will last 4 to 6 weeks. It is important to note that each Sprint should iterate out a new, working or "demonstratable" software. If there is no "working" software or product at a project stage, the project is definitely not suitable for the agile development framework. For example, the output of this project phase cannot be a DOORS module
(Translator's Note: DOORS is a common requirements management software in the automotive industry)
, nor a Word document, but must be "working": it can be an executable file, Or a runnable simulation program.
Figures 1 and 4 show the working process of the software Sprint phase. The software is developed iteratively in each Sprint and gradually matures as the Sprint progresses. An obvious advantage of this development process is that it combines the writing of software requirements documents with software implementation. If some software is not designed correctly, the corresponding requirements document will be rewritten, the software will be refactored and the new changes will be quickly integrated, and feedback from testing will be quickly available. In a way, each Sprint represents a mini V-shaped cycle. Therefore, by definition, when each Sprint is completed, the team produces a working software, as well as requirements documents and test case documents that match the content of the software. This makes the entire software development process very flexible and ready to respond to any new requirements from all parties. When faced with new requirements, all the team needs to do is evaluate them and introduce them into the next Sprint.
Figure 3. Sprint phase
For Sprints in the CV phase, the team's goal is to have a working software with all its related documentation complete by the time all Sprints are completed. Perhaps the system still cannot be applied to public roads, but it must have enough safety mechanisms to meet the requirements for use in a closed test field (this is why FSC and TSC must be established during the CV stage).
For the Sprint in the DV phase, the team's goal is to reconstruct the software in the CV phase based on security requirements analysis and complete the preparation of all diagnostic functions at the end of the Sprint. This software must be fully tested to verify all functionality and security. The software produced in the final DV phase needs to be usable on public roads.
Figure 4: Development process of automotive software DV phase using agile framework
Post-Sprint phase
In addition, another important task of the Post-Sprint phase is to improve the traceability documentation from the requirements document to the test document so that compliance with the ASPICE process can be achieved at the end of the phase.
5
write at the end
Through the discussion in this article, applying agile frameworks in automotive software development can also highly meet the requirements of ASPICE and ISO26262. Compared with traditional "waterfall" or "V-shaped" processes, this approach is more suitable for the current rapidly changing automotive market. Synchronously writing requirements documents and software and conducting iterative testing during the CV process will significantly reduce the time wasted in the "long loop" in the traditional development process. During the DV process, the software is reconstructed based on security analysis to ensure the security of the software and fully comply with the requirements of ASPICE and ISO26262.
Finally, the industry has generated a wealth of lessons over the years on how to develop safe automotive systems. If you do not truly establish an agile framework that suits the characteristics of the automotive industry, and rush into this "agile" trend, you will only create a software system that lacks security and completeness, and make the public lose their hard-won confidence in the automotive industry. trust. I hope this article proves that it is possible to apply agile frameworks to automotive software development, and that the benefits of applying agile frameworks will far outweigh the losses caused by the transition to agile frameworks.
We have formed a reader discussion group. If you are interested, you are welcome to reply to " Mucheng Reader " in the background to learn how to join the group.
Read the original text and follow Mucheng Zhihu column
Technical exchange group: YasmineMiao (WeChat)
Submission cooperation: 18918250345 (WeChat)
京公网安备 11010802033920号