2.9 The role of development tools
Many processes in Automotive SPICE can and should be supported by the use of tools. For example, traceability, performing traceability by hand is time consuming and error prone. An appropriate tool will streamline the process and provide the value from the practice. Users should be involved when selecting tools, e.g., in their practical evaluation. The areas which benefit most from tool are described in the following.
Specialized tools versus tools that support the entire lifecycle
One can observe two approaches in the industry:
- Using tools that support the entire lifecycle
- Benefits: The use of integrated solutions minimizes tool breakage and ensures traceability from requirements through design, coding and integration to the corresponding test case “under one roof”. The exchange of information between teams is simpler.
- Disadvantages: The complexity and size of these systems has its price. Often the user base is very large and involves many different departments and locations. All of them have different requirements. The IT department has strict requirements on security, availability,
data integrity, and maintainability. This can take a long time and not all parties will be satisfied at the end.
- Use of tools that are tailored to specific tasks
- Benefits: This allows a tailor-made and cost effective solution with high performance and user acceptance. These tools can be quickly acquired, tailored, and installed.
- Disadvantages: Because different teams use different tools tool breakage can’t be avoided. A typical example is bidirectional traceability which requires individual interfaces to be implemented.
Either way, tools must be adapted to the needs of the organization. Often this is not the case which leads to inefficient workarounds by the developers.
DOORS is a common tool in the automotive industry and is often used for test management as well. Often an additional file server for documents is used. The reason is that documents from other tool environments are difficult or impossible to manage in DOORS. DOORS supports
- Uniquely identifying, prioritizing and categorizing requirements
- Developing bidirectional traceability between requirements, design, test, and verification criteria
- Providing versioning and history of individual requirements (Why, when, and by whom was this requirements changed?)
- Establishing baselines and baseline sets; however, this refers to DOORS modules only. Documents on file servers are not part of the DOORS created baseline record.
There are also other tools available to support traceability. For example, requirements may be created using Microsoft Office programs. Tags can be defined individually for the identification of requirements. The documents are imported into a data base thereby implementing traceability across documents in various formats. Tool breakages can thus be avoided.
One of the most important tools in the management of work products are configuration management systems. Tools that support the entire life cycle offer this feature together with the versioning of various work products. Configuration and version management are particularly necessary for managing work products of the engineering processes. Of particular importance are tools for source code and build management. They support baselining and versioning of individual source files, binary executables, configuration files, operating system, compilers and libraries. Error-free reproducibility of the software from these components has to be guaranteed.
Also branching and merging are supported to allow, for instance, parallel development of different customer versions. Most tools are not suitable for pure document management. Document management tools are used instead which support also long-term archiving.
The automotive industry requires parallel development in different engineering disciplines (for example, hardware, mechanics and software). Thus, several systems are needed simultaneously for managing mechanical construction CAD data, hardware layout and circuit diagrams in the hardware, and management of source code. For the interdisciplinary baselining there are two typical solutions:
- Forming local baselines in the different tools; the IDs of the local baselines are specified in a table under a global ID.
- Forming local baselines in the different tools; the IDs of the local baselines are specified in one of the tools (usually the tool of software teams) and included in an overall baseline.
Problem and change management
For the processes SUP.9 and SUP.10 there is often one common tool in use. There are commercial tool suites available as well as open source tools. The latter usually offer cost-effective and flexible solutions. Most of the problem and change management tools are applied in the development. However, it may be useful to record problems in the field and provide an appropriate evaluation of the problem causes. Since the introduction of the ISO 26262 safety standard the documentation and impact analysis of problems and changes gain increasing importance.
Test management tools support traceability to the entire left-hand branch of the V-model. These tools simplify the creation, management, and automation of test cases. Nevertheless, at the system level test cases that are purely based on requirements are often not sufficient. The reason for this is that large amounts of standard tests are not based on written requirements, but have evolved over the years from the experience of many test drivers. This is typical for most mature ECU (Electronic Control Unit) products in the automotive industry such as engine control and chassis control.
Specific tools are required for white box testing on unit test level. These tools have gained importance since the introduction of ISO 26262 as measuring test depth and coverage, which vary depending upon the ASIL level (e.g. ASIL D Units require 100% MCDC coverage), requires suitable tools.
Model-based development tools
There is a trend in the automotive industry towards model-based development and code generation. It is best if these tools support their own configuration management and trace-ability features to avoid typical
problems encountered when storing their output files in traditional source CM tools. Additionally, it is sometimes not possible to use the generated code, especially in hardware-dependent components such as drivers. Often hand-coding is required to exploit the available memory optimally.
If you wish to continue to the next chapter click here: