Involved in the challenges of Automotive SPICE, particularly the detailed design of your software and the unit construction? Read on for a quick overview of key information on SWE.3, a key process from VDA Scope, including a video and our free white paper.
back to Automotive SPICEAutomotive SPICE® is a trademark of VDA QMC.
The Software Detailed Design and Unit Construction process in Automotive SPICE® (also known as SWE.3) helps your organization to provide an evaluated detailed design for the software components and to specify and to produce the software units.
What is the goal of the Software detailed design? A lot of organizations and projects have problems understanding how to document the detailed design. So, what are the three aspects you should manage in this process?
The following are the most important aspects of Change Request Management in Automotive SPICE®.
Interested in finding out more about SW Detailed Design and Unit Construction (SWE.3), the Automotive SPICE® process from VDA Scope? Our free white paper provides you with a summary of all key information, including an extract from our book on Automotive SPICE® Essentials – ideal reading for anyone new to the topic of process improvements.
Often, organizations struggle how specific the detailed design should be. A good way to approach this is to remember what the purpose of the detailed design is. It is the basis for the implementation of the code and the unit test. Especially the unit verification requires a detailed description. Here, the level of coverage must be considered.
In safety-critical software ISO 26262 provides guidance. In non-safety software typically at least C0- or statement coverage, by some customers C1- or branch coverage is required. The higher the coverage goal the more detail is required by the detailed design. If you have an ASIL-B classified module a C1-coverage is expected. That means that your detailed design should identify the different branches of your software.
Need support with a key project? We’re your first port of call when it comes to management consulting and improvement programmes in electronics development.
Steffen Herrmann and the sales team
A pitfall I often encounter in assessments is the lack of detailed description of the external and internal interfaces.
Expected content of interface documentation are
Without this information a proper testing of the interfaces in the unit test is impossible.
It is okay if the external interfaces are described on architectural level and tested in the software integration test (SWE.5).
Describe the detailed design b e f o r e your implement the code. Often, the detailed design is described after the fact, meaning after the code has been written.
Why is that a problem? The unit test should check whether the code fulfils the detailed design. If you write the detailed design after documenting your code, the point of the unit test is lost.
Now, you could argue that you may not need the unit test. The point is that you should derive your detailed design form your architecture and not from the code. If the chain is broken, then suddenly the content of documentation and all the tests do not make sense anymore. So, the detailed design must be written before you start writing your code.
There is nothing wrong to iteratively develop detailed design and code step by step.
As part of our strategy to systematically improve development processes in the automotive electronics sector, we are also an official licensee of Automotive SPICE® – a trademark of the Association of the German Automotive Industry (VDA QMC).