In the year 2014, several fatal accidents took place that killed more than 90 persons: Due to a badly dimensioned ignition lock, the vehicle’s ignition turned off inadvertently under certain circumstances. This caused a loss of electricity to the steering and braking systems. These incidents highlight the significant influence mechanical components in the vehicle may have on the electronic and software components.
On the other hand, the influences from the electrical systems, with their risks and dangers, were considered for quite some time by standards like ISO26262: Where, for each project developing an electromechanical steering system, a safety goal is defined to prevent unintended-steering, i.e. steering movements due to faults in the electronic system. Furthermore, requirements for electronic and software development processes are also contained within the Automotive SPICE® standard.
Since there are mutual influences between the mechanical, software and electric/electronic design aspects – why is there no standard to formulate requirements for mechanical development processes to define relationships to the “rest” of the system?
The question becomes more and more urgent since in the last decades not only the mechanical systems, but also their development processes, have changed significantly: From static mechanical drawings to significant model based engineering practices, supported heavily by software simulation and analysis tools.
Modern product engineering utilizes software development tools in nearly all phases of the development lifecycle. This has caused an increase in the number of intermediate and final work products which teams create and use to design and analyze their product. This requires even greater support and demand for processes like configuration and change request management.
Furthermore, higher computing performance and new production methods have both significantly changed the mechanical systems. Shapes with a considerably higher complexity can be developed and produced. The production lines are developed in parallel with the product. This dependency leads to very high costs and effort to be spent when changes are introduced after the design freeze – in contrast to software. Therefore, front loading and high process quality in the engineering processes are indispensable for the mechanical aspects of a product’s design.
These points, among others, have led to the foundation of an intacs (international assessor certification scheme) working group to develop a process model for mechanical engineering. Contributors to this working group have been well-known companies like Conti Temic microelectronic GmbH, Hilti AG, Mando Corporation Europe GmbH, Robert Bosch GmbH or ZF Friedrichshafen AG. The working group used the plug in concept of Automotive SPICE® 3.0 which defines process interfaces for mechanical or electrical engineering processes to create the standard (Figure 1). Management and supporting processes have not been changed as well as the generic practices of Automotive SPICE®. The processes have to be reused according to the plug in concept but interpreted for the mechanical engineering context.
Figure 1: Plug in concept of Automotive SPICE®
As basis for the definition of the mechanical engineering standard, the software engineering processes of Automotive SPICE® – 3.0 SWE.1 to SWE.6 – have been used. Nevertheless, the process structure has been adapted: Consequently, Mechanical SPICE distinguishes between a system and a component level (Figure 2). The mechanical component is defined as an atomic part, like a screw. A mechanical system, on the other hand, is defined as an assembly of at least two mechanical components. For both levels, mechanical system and mechanical component, processes for specifying requirements, creating a design, executing tests against the design and against the requirements have been defined. On mechanical component level, one additional process for producing the component itself has been defined.
Figure 2: System and component structure
The software engineering processes of Automotive SPICE® – in contrast – require the creation of software requirements (SWE.1) and a software architecture (SWE.2) on system level as well as the creation of a detailed design (SWE.3) on component level together with the corresponding tests (SWE.4 to SWE.6).
There are several reasons for introducing the additional requirements process on the mechanical component level:
- Creating component requirements facilitates the definition of product building blocks. Each building block is completely specified: Functionality and characteristics by requirements, implementation by drawings and models.
- The technical documentation for external sourcing of components is defined: The component requirements serve as “customer” requirements for the supplier, the tests against these requirements as approval tests.
- Some companies develop mechanical components exclusively. Here, the component requirements form the basis of the product documentation.
The Automotive SPICE® software processes have been also adapted on a more detailed level to create the mechanical engineering standard:
- New Base Practices have been defined, to be used in a mechanical context.
- Content has been interpreted for the mechanical engineering environment, like dynamic behavior of mechanical products.
- Definition of new processes, like MCE.3: Mechanical Component Production.
The main difference between the processes of software construction and mechanical production is the need for a mechanical production strategy to define manufacturing and production aspects as well as in-line and end-of-line production tests.
Furthermore, an interface to the production processes has been introduced in the mechanical engineering standard which is implemented by creating a Production Strategy (MCE.3.BP1). Additionally, the processes MSE.1 Mechanical System Requirements Analysis and MCE.1 Mechanical Component Requirements ask for the definition of requirements for production. On the other hand, Automotive SPICE® mentions the “production” of software in only one Base Practice: SWE.3 BP8 Develop software units.
Another important aspect of Mechanical SPICE is the consideration of different instances of one specific product version. Produced software exists only in one instance per product version and can be reproduced multiple times – in contrast to mechanical products where production processes and their tolerances must be considered. This fact leads to additional requirements for traceability and configuration management.
To integrate existing standards, the working group performed a mapping of Mechanical SPICE to ISO/TS16494.
The first pilot projects already gathered experiences using Mechanical SPICE. The products of most automotive Tier One suppliers require a strong interaction between mechanical and electronic functionality. This is why some OE customers also enforce a strong cooperation of the respective development departments and impose an enhanced assessment scope from “software only” to “system including mechanics” and therefore identify broader improvement opportunities.
While the concepts in the V model are familiar to mechanical engineers, concepts of the Mechanical SPICE standard require additional time for explanation during interviews. This needs to be considered during assessment planning and reflected in the agenda.
Software departments have been working for quite some time to fulfill Automotive SPICE® requirements and have introduced adequate software, system and electronics tools and methods to implement the processes – in contrast to mechanical development departments. This focus of Automotive SPICE® assessments to system and software in the past led to incompatible tool interfaces, e.g. in requirements engineering from system to mechanical requirements. Thus, traceability is often not established. Furthermore, the inefficiencies caused by the usage of different tools and methods for requirements engineering increase costs – time and money.
A harmonized process interface is the precondition for an efficient and reliable implementation of safety requirements as indicated to be necessary in the introduction. Until now, suppliers have compensated for the lack of traceability with their deep product understanding. While this informal traceability may have worked for small projects and teams, this will no longer be the case for larger projects and teams. Especially when considering the complex system challenges facing the automotive industry with sophisticated system of systems development required to successfully bring autonomous driving to the market.
Andrei Donciuc is a Senior Process Consultant at Kugler Maag Cie. He has about 5 years of experience assisting medium-size companies as well as international corporations. Mr. Donciuc is an intacs™-certified Provisional Assessor and has provided support as systems engineer, developer, tester and consultant.
Thomas Gabler is a Senior Process Consultant at Kugler Maag Cie. with more than 15 years of industry and about 5 years of consulting experience. He has developed a lot of safety critical hardware for military and aerospace applications and performed many safety assessments and equipment reliability analyzes.