An approach supporting integrated modeling and

An approach supporting integrated modeling and design of complex mechatronics products by the example of automotive applications Mario HIRZ Institute of Automotive Engineering, Graz University of Technology Graz, Austria

ABSTRACT Increasing integration of electrics/electronics (E/E) systems and software into modern products has led to a significant change in value creation and development of formerly mechanically oriented industries. With rising share of information technology in previously mechanics-based products both product functionalities and customer benefit increase, but this trend requires a fundamental change in the consideration of the entire product lifecycle. This includes requirements management, product conception, the development phase, production and assembling, the in-use phase and the end-of life phase. Due to the fact, that a main portion of today’s complex products represent mechatronics systems involving mechanical, electrics/electronics and software components (to a varying share - depending on the type of product), a smart and effective integration of these historically separated disciplines plays an important role throughout the entire product lifecycle. To enable this, new development processes and approaches have to be introduced, developed and applied. The present work deals with the question how to enable interaction of the different disciplines (models) and how to integrate and evaluate all the partially conflicting influencing factors into one inclusive process to enable comprehensive system modeling throughout several phases of the product development. The automotive industry represents itself as one branch that is effected in a high degree by this topic. In this way, requirements and boundary conditions of automotive development are taken into account to present, discuss and evaluate the approach of integrated modeling, design and evaluation of complex mechatronics products.

simultaneous development of mechanical, electrical and electronics systems including software. Especially software development follows different rules than hardware development, because of differing behavior in view of complexity management, occurring errors and failure, durability and lifecycle. In this way, new approaches have to provide functionalities not only to implement e.g. an electric motor or a camera system into a digital mockup, but also features to consider functional aspects of implemented modules. For the applied development platforms, this requires interfaces between mechanical design, simulation and software development programs as well as evaluation tools for testing of complete mechatronics systems. For this purpose, indicating parameters have to be introduced, which are able of characterize product maturity in view of the development processes in all involved domains. 2. MECHATRONICS SYSTEM DEVELOPMENT PROCESS ACCORDING TO THE V-MODEL Figure 1 shows a typical development process according to the so-called V-model, applied on automotive mechatronics systems, [1]. The V-model represents a special case of waterfall models that describe sequential steps of product development, [4].

Keywords: mechatronics systems, V-model, development standards, key performance indicators, quality management 1. INTRODUCTION The steadily increasing share of E/E and software components in cars is motivated by aspects of comfort and communication, but also by continuously strengthened legislative boundary conditions for exhaust emissions and vehicle safety. In a modern midsize car, the portion of averaged value creation of E/E reaches more than 30%, and this value will further increase during upcoming years. However, E/E research and development has overtaken traditional mechanical-oriented development tasks and it will become more important during the next years, [2]. The development processes did not follow the new requirements so far, and applied development strategies, tools and methods lack in this context, too. Future comprehensive approaches have to face these new product characteristics by provision of enhanced development methods for mechatronics systems, which are able to support

Figure 1: Exemplary automotive according to the V-model.

development

process

The process begins at the top end of the left branch with product specifications that result from a list of requirements. The entire left branch focusses on product requirements definition, layout and design on system-, module- and component level including

different areas of simulation and optimization. In this way, it is divided into a sequential chronology of increasing levels of detail. The system level includes full-vehicle related development, e.g. vehicle architecture, packaging, and of course styling, [7]. After having defined main characteristics on fullvehicle level, the module level provides a breakdown of complex systems into several modules, e.g. vehicle body, drivetrain, chassis, comfort and driving assistance modules. Finally, modules are divided into their components, which are developed in the component level. Here, cross-domain implementation is performed at the bottom level of the V-model in the course of component integration. Today, this is mainly done by product-oriented processes, which focus on product characteristics and functionalities, but not on effective process integration, e.g. [8]. The right branch of the V-model includes prototyping, testing and optimization at component, module and system level. After being tested, components are built together to modules, which are integrated and tested according to their specific functionalities. In the final system level at the top end of the right branch, all elements are assembled to a full-vehicle prototype and tested for product confirmation according to initially defined specifications. Typically for development according to the V-model is a close interaction of design and testing. In this way, data and information exchange between product design (left branch) and integration & testing (right branch) support efficient improvements and optimization. In case of highly complex products, e.g. cars, the development process is run through several times, especially on module and component level. Both duration and complexity of these development cycles differ significantly in the three domains, which leads to varying levels of maturities in mechanics, electrics, hardware and software development. This represents an important challenge in the development process, because the different durations of development cycles lead to not corresponding data and information status. In general, the V-model represents itself as a well-established approach for the development of mechatronics systems, but with rising complexity and increasing share of E/E, it shows disadvantages in terms of efficient cross-domain integration. To face these challenges, future development processes have to provide functionalities for effective integration of geometric, structural and functional design, not restricted to mechanics systems, but also including hard- and software. One key of success lies in the introduction of flexible, interdisciplinary processes, which are able to consider different domain-specific methodological, functional and development-cycle-time related characteristics. In addition, data exchange and communication have to be improved by implementation of comprehensive data models, which are able to supply all involved disciplines, [3]. One important challenge in this context includes a broad evaluation of the different levels of product maturity in the involved domains. Although the V-model provides a basic strategy for integration of mechanics, electrics and informatics, continuously monitoring of the process of each domain is not sufficiently included so far. 3. DEVELOPMENT PROCESS STANDARDS AND GUIDELINES Mechatronics product development is supported by different standards and guidelines, which are defined within the three involved domains mechanics, electrics and informatics technologies. These standards and guidelines cover broad areas of development methods, technical aspects and boundary

conditions within the domain they are made for, but they lack in their capabilities of cross-domain integration. Exemplary, there are lots of standards covering the development of mechanical components and systems, e.g. crash- & safety standards for cars, [9]. Electric component development is also topic of several standards, e.g. regarding electromagnetic compatibility in automotive applications, [10]. Finally, the informatics domain that includes computer hard- and software, is also increasingly topic of guidelines and standardization. Due to the fact that computer-controlled functions progressively appear in automotive applications, the influence of this domain on the entire product lifecycle becomes more and more important. Since the late 90s of the past century, car manufacturer increasingly introduced E/E functions in their products, which led to significant rise of complexity, see Figure 2.

Figure 2: Increase of E/E functions in cars over the years, [11]. In this way, mechatronics systems development represents quite a challenge because of rising share of involved technical disciplines such as E/E, software and mechanics. Consequently, the development and production of these systems bear risks of possible malfunctions, which may provide risks for customer, other traffic participants and environment. In this context, an important topic is to ensure high reliability and prevention of faults. This requires improving both quality management and development processes. For that purpose, standards and guidelines have been introduced in automotive industry that focus on E/E systems but also include aspects of the entire product characteristics. These guidelines and standards fit into state of the art development processes, e.g. the V-model, and provide structures, strategies and methods to support the development processes in automotive applications. In the following, three important standards are introduced. ISO 26262, Road Vehicles – Functional Safety The ISO 26262 was published in 2011 as an international standard for the development of safety-critical electronic systems in automobiles, and it is applied more and more all over the world, [12]. The standard is based on the general IEC standard 61508, but it contains car-specific refinements. The ISO 26262 provides a comprehensive safety lifecycle that includes all phases of product conception, development, production and use, see Figure 3. Based on an evaluation of product E/E functionalities and characteristics, risk classification is performed, whereas it is recognized that risks cannot possibly be reduced to zero. But risks can be assessed qualitatively and actions can be taken to reduce them as far as is reasonably practicable. The ISO 26262 standard enhances the

IATF 16949 standard of Quality Management (QM), [13], and is structured analogous to the V-model. One important characteristic of the ISO 26262 includes the Automotive Safety Integrity Levels (ASIL) for risk classification. These levels range from ASIL A to ASIL D, with A representing the lowest risk level and D the highest. Additionally, the QM level indicates a risk level below ASIL A.

Figure 3: Overview of the Safety Lifecycle in the ISO 26262. The ISO 26262 defines a safety lifecycle that encompasses principal safety activities during concept, development and production phases. For all of these phases, actions and measures are prescribed to support analysis and evaluation of product characteristics in view of possible failures (risks) and to derive measures, mechanisms and technologies to reduce the number and effects of possible errors, [14]. ISO/IEC 15504, Automotive SPICE (ASPICE) Automotive SPICE (ASPICE) represents a domain-specific variant of the international standard ISO/IEC 15504 (SPICE Software Process Improvement and Capability Determination), [14], [15]. ASPICE supports a performance evaluation of the development processes of electronic control units and embedded systems in the automotive industry. As an international standard, ASPICE is used worldwide in automotive OEMs and supplier industry as a framework for the assessment of software development processes. Automotive SPICE provides a representative software process evaluation model including evaluation indicators and metrics that measure the process performance, Figure 4. The evaluation tasks serve as reference for maturity models, which specify requirements for process reference and process evaluation models. These reference models comprise several key components, e.g. lifecycle processes from different process categories for the process dimension and six skill levels for the capability dimension. It includes a series of process performance and process capability assessment indicators on the basis of which objective assessments are collected to enable ratings, [16]. Acquisition Process Group (ACQ)

System Engineering Process Group (SYS)

ACQ.3

SYS.1

Contract Agreement

Requirements Elicitation

MAN.3 Project Management

SYS.2

ACQ.4

SYS.5

System Requirements Analysis

Supplier Monitoring

ACQ.11 Technical Requirements

Management Process Group (MAN)

MAN.5

System Qualification Test

SYS.3

SYS.4

System Architectural Design

System Integration and Integration Test

Risk Management

MAN.6 Measurement

ACQ.12 Legal and Administrative Requirements

Software Engineering Process Group (SWE) SWE.1

ACQ.13

SWE.6

Software Requirements Analysis

Project Requirements

ACQ.14 Request for Proposals

Software Qualification Test

SWE.2

SWE.5

Software Architectural Design

Software Integration and Integration Test

SWE.3

ACQ.15

Software Detailed Design and Unit Construction

Supplier Qualification

Supply Process Group (SPL)

Reuse Process Group (REU)

SWE.4 Software Unit Verification

REU.2 Reuse Program Management

Supporting Process Group (SUP)

SPL.1 Supplier Tendering

SUP.1

SUP.2

SUP.4

SUP.7

Quality Assurance

Verification

Joint Review

Documentation

SPL.2

SUP.8

SUP.9

SUP.10

Configuration Management

Problem Resolution Management

Change Request Management

Product Release

Primary Life Cycle Processes

Organizational Life Cycle Processes

Process Improvement Process Group (PIM) PIM.3 Process Improvement

Supporting Life Cycle Processes

Figure 4: Automotive SPICE 3.0 process reference model, [15].

In this way, the ASPICE process assessment models include a collection of best practices for the automotive industry. The models enable evaluation and comparison of OEMs and supplier processes, methods, workflows and outcomes. Although Automotive SPICE focusses on system engineering and software development, it refers to the development of entire mechatronic systems in automotive applications in a certain way. In accordance to the general development process (Vmodel), the standard Automotive SPICE additionally offers a framework for the entire product development procedure that includes defined processes for project management, requirements management, configuration management, risk management, supplier qualification and acquisition. Capability Maturity Model Integration CMMI Capability Maturity Model Integration models are a collection of best practices that support companies to improve their processes. These models are developed by product teams from industry, similar to Automotive SPICE, but are not industryspecific. CMMI includes a model for process improvement of products and services, which consists of five maturity levels that are achieved by implementation of specific and generic goals of these maturity levels, Figure 5. In order to achieve an objective, generic and specific practices or acceptable alternatives must be fulfilled. Typically, organizations implementing CMMI improve their performance in terms of productivity, predictability and quality of the products. This makes processes more predictable and increases development effectivity, [15], [17].

Figure 5: CMMI maturity levels, [17]. CMMI represents an extensive process approach, which is very widespread among automotive and other industry, especially in North America. CMMI and Automotive SPICE have different concepts and approaches, but they are not mutually incompatible. Each of the two models contains aspects that are not present in the other standard. Because of structural differences, mapping CMMI to Automotive SPICE is therefore not completely feasible. Nevertheless, CMMI and automotive SPICE can be used together, and an integration of the process models makes sense in order to meet both requirements and further increase of process capability, [18], [19]. Both standards cover the four categories of process areas associated with software product development: process management, project management, engineering and support. CMMI on the one hand covers some disciplines and process areas that ASPICE does not cover. These include e.g. integrated supplier management, integrated teaming as well as decision analysis and solution. On the other hand, Automotive SPICE covers some areas that are not fully covered by CMMI, e.g. supplier monitoring and reuse program management, [20]. Besides the mentioned development process standards and guidelines that include comprehensive product development, monitoring and optimization measures in view of E/E development, there are various additional standards and

guidelines addressing quality management in different phases of product lifecycle. These general standards represent guidance and tools to ensure that the products are able to meet customer’s and legislative requirements and high quality, e.g. ISO 9000 [21], ISO 9001 [22], ISO 9004 [23], ISO/TS 16949 [24], ISO/IEC 90003 [25], ISO/IEC 25000ff [26], ISO/IEC 15504 [27], ISO 26262 [28], VDI 2221 [29], VDI 2206 [30]. In addition, specific quality management methods and tools are integrated into development processes, e.g. Quality Function Deployment (QFD) [5], Failure Mode and Effects Analysis (FMEA), Fault Tree Analysis (FTA) [31], Statistical Process Control (SPC) [32], Poka-Yoke [33] and Total Quality Management (TQM) [34].

to control general project success by use of e.g. customer satisfaction, profitability, employee satisfaction and net profit before tax. Performance Indicators (PI) provide information of main topics in a project, e.g. process time, various metrics, profitability of customers and net profit on key product lines, [5]. Finally, Key Performance Indicators (KPI) deliver information about project performance-related issues. They can be represented by sets of parameters, which symbolize the most important measures of the current development project. In this way, KPI can be applied permanently for analysis of the daily or weekly progress and performance during the entire development phases. These indicators can represent important measurements to avoid risks and complications at the end of development or at least at the customer stage. Nevertheless, the 4. INDICATORS FOR DEVELOPMENT PROCESS generated information represents a basis to develop statements MONITORING & CONTROL about eventually necessary actions. KPI have to be defined as The mentioned development process standards, guidelines and objective, quantitative measurements to handle critical success tools are integrated into the mechatronic system development factors enabling control of status, progress, and performance process according to the V-model. In this way, they are able to trends. The combination of critical success factors, which are provide significant contribution on successful mechatronics requirements to reach development targets, and KPI as product layout, design, simulation and verification, but they qualitative and quantitative measures for the achievement of mainly focus on one development domain. Whereas the main targets, enables an efficient development project control, [35]. focus of the mentioned standards and guidelines is put on E/E In this context, the following objectives have to be considered development processes, some of the tools are also applied in for the determination of KPI: A consideration of partnerships mechanics development processes, e.g. FMEA, FTA. Within (e.g. to suppliers, customers or unions) is important for uniform the specific development domains the requirements, boundary communication and transparent decision-making. Thus, all conditions and processes are defined well. In addition, there are stakeholders in the development process have to be informed some definitions of interfaces to other domains, but the crossand have to be considered in the definition of KPI. In addition, a domain integration lacks in view of completeness and integrity. common development strategy has to be considered, as well as With rising share of E/E and software components in cars, involvement of suppliers and customers. The status of progress Project management process KPI definitionfunctions process effective and integrated development processes become more of implementation the different product according to and more important. One possibility to handle the gaps between the V-model plays an important role. The definition of KPI also Monitoring Mission Conception Definition Launch Critical Goal andto consider Visionmeasurement, success and and and Close Indictors development domains and to enable comprehensive process has reporting, and improvement of Strategy control Values initiation planning execution factors evaluation includes the definition of indicators to measure and performance to support efficient and focused decisions during evaluate development quality and product maturity. In this way, the development cycles. This requires an enforcement of the traditional quality management methods have Specification to be Testing iterative, time-depended processes of developing strategies to Milestones Faults enhanced by new approaches that supportRequirements inter-domain generate performance measurement to improve productivity. etc. etc. etc. development process management. As one potential supplement, so-called key performance indicators (KPI) are Performance and schedule able to control and monitor the development processes and even the entire product lifecycle of mechatronics systems. KPI are Reporting and Fault and monitoring change based on metrics, which are related to quantitative and Key result indicators qualitative information that is used to evaluate the fulfillment of Performance indicators development aims and goals. KPI are defined on the basisData of base a multi-layer model that includes key result indicators (KRI), Key performance indicators Scope performance indicators (PI) and finally key performance verification and Quality validation indicators (KPI). Figure 6 shows the relation of such different types of indicators. Name of institute

Costs Key performance indicators

Figure 7: Indicators supporting different aspects of project management, [5]. Performance indicators

Key result indicators

Figure 6: Different indicators for product development, [5]. Key Result Indicators (KRI) deliver information about how the project or progress is performed. This type of indicators is used

Essential for success is a close connection of KPI to strategy. In this way, KPI should be linked to strategy-related aspects, following the process of indicator definition, as shown in Figure 6. This connection of indicators to the specific project targets, and even to the company mission, vision, and values, deliver efficient measurement or evaluation possibilities, [5]. In general, KPI are characterized by the following characteristics:  KPI describe the process due to effectivity, efficiency, and quality.  KPI detect deviations and changes in processes.

 KPI are measurable and objective.  KPI include target values.  Reaching KPI targets equals reaching project targets.  The defined set of KPI has to be consistent to the project-/ company’s targets. During the whole project management process, the basis for enhanced analysis is collection of data and information, such as requirements, systems- and components-specifications, tests, faults, and milestones. Important is a cross-domain-related consideration of information that is focused on product characteristics and not on domain-oriented specification. In this way, the KPI definition process has to be performed by considering various (cross-domain) parties, views and needs during development processes to enable suitable statements and effective management. KPI can support investigations of performance and schedule, fault and change, costs, quality, as well as reporting and monitoring. Besides technological aspects, different types of perspectives can be included, e.g. company management, project management, quality assurance, and process management. Development procedures use different items to handle processes and progresses. Hence, requirements are usually a result of project specifications. Due to various development phases and project maturity, specific KPIs delivered by differently developed analysis methods enable control during every step. Examples for quality-related aspects that can be evaluated by use of KPI are, [5]:  Status and progress are applied to check the actual project status, tasks, and progresses by descriptive statistics.  Indicators of durations allow the investigation of all kinds of processing periods.  Development status tracking supports control of data quality and progress management by checking target and performance as well as linkages between items on subcomponent or module level.  Target-performance comparison enables an association of target and performance as well as investigation of deviations in development processes.  Fault estimation supports evaluation of detected and fixed faults over the project maturity or time lane.  Trend analysis supports the understanding of development processes and evaluation of tendencies of performance or progress.  Prediction of key parameters enables an estimation of the residual error and supports checking the trend of faults during development. 5. CONCLUSIONS To face the challenges in multi-domain mechatronics product development, development processes and tools have to provide much more than the traditional functionalities and data structures. In automotive industry, the implementation of development standards for mechanics components and electrics/electronics systems took place during the past decades, but an integration of the three domains mechanics, electrics and electronics/ software lacks in view of effective processes. Future-oriented process- and product models have to include complete data and information structures, providing all productand process-related information for effective cross-domain development of mechatronics systems. Besides geometrical, product structural, functional and production-related

information of mechanics and electrics & electronics hardware, this also comprises software-related requirements, structuraland functional information. Development process standards and guidelines, e.g. ISO 26262, ASPICE and CMMI have the capability to significantly improve development quality, but they are focused on electrics/electronics systems. To enable both cross-domain process integration and comprehensive development process monitoring and evaluation, additional measures have to be introduced. In this context, key performance indicators can be defined according to specific requirements derived from product specifications and development-related boundary conditions. Based on technical cross-domain characterization and process orientation, key performance indicators are able to provide a fundamental basis for monitoring, evaluation and optimization of mechatronics development processes. In this way, they show a great potential to improve integrated modeling and design of complex mechatronics products, exemplary in automotive applications. 6. REFERENCES [1] Development Method for Mechatronic Systems, VDI Guideline 2206, Association of German Engineers, 2003. [2] Hirz, M.; Dietrich, W.; Gfrerrer, A.; Lang, J.: Integrated computer-aided design in automotive development: development processes, geometric fundamentals, methods of CAD, knowledge-based engineering data management; Springer, 2013, ISBN: 9783642119392. [3] Lohöfener M.: Design of mechatronic systems and benefit of open source software tools; 9th International Workshop on Research and Education in Mechatronics, Italy, 2008. [4] Sell R.; M. Tamre: Integration of V-model and SysML for advanced mechatronics system design; International Workshop on Research & Education in Mechatronics, At ANNECY, France, 2005. [5] Ernst, M.: KPI-related analysis methods to optimize mechatronic product development processes; doctoral thesis, Institute of Automotive Engineering, University of Technology Graz, 2016. [6] Wilfinger, M.: Development process optimization of mechatronic systems in automotive applications; master thesis, Institute of Automotive Engineering, University of Technology Graz, 2017. [7] Dietrich, W; Hirz, M.; Rossbacher, P.: Integration von geometrischen und funktionalen Aspekten in die parametrisch assoziative Modellgestaltung in der konzeptionellen Automobilentwicklung; Grazer Symposium Virtuelles Fahrzeug, Austria, 2010. [8] Stadler, S.; Hirz, M.: An application of enhanced knowledge-based design in automotive seat development; Journal Computer-Aided Design and Applications 11 (3), Taylor & Francis, 2014, DOI 10.1080/16864360.2014. 863507. [9] SAE Standard J224: Collision Deformation Classification; www.sae.org, date of access: 20171210. [10] SAE Standard J1113: Electromagnetic Compatibility Measurement Procedure for Vehicle Components; www.sae.org, date of access: 20171210. [11] Hirz, M.: Automotive Mechatronics 1; lecture script at Graz University of Technology, 2017. [12] ISO Standard 26262 Road vehicles - Functional safety; International Organization for Standardization, www.iso.org, date of access: 20171210.

[13] IATF Standard 16949 Quality Management; VDA QMC, http://vda-qmc.de/en/certification/iatf/publications-isots16949/, date of access: 20171210. [14] Anderson, P.: Mehr Softwaresicherheit Statische Analysetools und die ISO 26262; Journal ATZ Elektronik, 1/2017. [15] Automotive Spice (ASPICE) process assessment and process reference model; SIG & VDA QMC, http://www.automotivespice.com, date of access: 20171210. [16] Adedjouma, M., et al.: Merging the Quality Assessment of Processes and Products in Automotive Domain; ProductFocused Software Improvement, Springer, 2012, ISBN: 978-3-642-31062-1. [17] CMMI Product Team: CMMI® for Development, Version 1.3; Carnegie Mellon University, Software Engineering Process Management Program, Pittsburgh, 2010. [18] AUTOSAR, Layered Software Architecture, https://www. autosar.org/fileadmin/files/standards/classic/4-3/softwarearchitecture/general/auxiliary/AUTOSAR_EXP_LayeredSo ftwareArchitecture.pdf, date of access: 20170725. [19] Fessler, G.: CMMI® und Automotive SPICE© gemeinsam nutzen; http://www.sbz-pec.de/downloads/detail/cmmi-undautomotive-spice-gemeinsam nutzen/201202aspicecmmiv6 .pdf , date of access: 20171110. [20] Sassenburg, H., Kitson, D.: A Comparative Analysis of CMMI and Automotive SPICE; http://itq.ch/pdf/sepg /CMMI &AutomotiveSPICE_305b.pdf, date of access: 20171111. [21] Raubold, U.: Lebenszyklusmanagement in der Automobilindustrie - Ein Optimierungsansatz auf Basis der auf den Lebenszyklus wirkenden Einflussfaktoren; doctoral thesis, Technische Universität Cottbus, 2010, ISBN 978-3-83492862-7, Germany. [22] International Organization for Standardization: ISO 9000 Quality management systems - Fundamentals and vocabulary; Switzerland, ISO, 2015. [23] International Organization for Standardization: ISO 9001: 2015 Quality management systems – Requirements; Switzerland: ISO, 2015. [24] International Organization for Standardization: ISO 9004: 2009 Managing for the sustained success of an organization - A quality management approach; Switzerland, ISO, 2009. [25] International Organization for Standardization: ISO/TS 16949:2009 Quality management systems - Particular requirements for the application of ISO 9001:2008 for automotive production and relevant service part organizations; Switzerland, ISO, 2009. [26] International Organization for Standardization: ISO/IEC 90003:2014 Software engineering - Guidelines for the application of ISO 9001:2008 to computer software; Switzerland, ISO, 2014. [27] International Organization for Standardization: SO/IEC 25000:2014 Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Guide to SQuaRE; Switzerland, ISO, 2014. [28] International Organization for Standardization: ISO/IEC 15504-1:2004 Information technology - Process assessment; Switzerland; ISO, 2004. [29] International Organization for Standardization: ISO 262621:2011 Road vehicles - Functional safety; Switzerland; ISO, 2011. [30] The Association of German Engineers: VDI 2221, Methodik zum Entwickeln und Konstruieren technischer Systeme und Produkte; Germany; VDI, 1993. [31] Ernst, M; Dallinger, P.; Fabian, J.; Hirz M.; Schnellbach, A.: Innovative Analysemethode in der Entwicklung mecha-

tronischer Systeme am Beispiel elektrifizierter Antriebsstränge; Elektrotechnik & Informationstechnik 132/ 3: 134– 141. DOI 10.1007/s00502-015-0292-7, Germany, Springer, 2015. [32] Shewhart, W.A.: Economic control of quality of manufactured product; ASQ Quality Press, Milwaukee, USA, 1980, ISBN 0-87389-076-0. [33] Shingo, S.: Zero Quality Control: Source Inspection and the Poka; B&T Productivity Press, Portland, Oregon, 1986, ISBN 9780915299072. [34] O’Regan, G.: Introduction to Software Quality, Springer International Publishing, Switzerland, 2014, ISBN 978-3319-06105-4. [35] Hirz, M.; Ernst, M.: Development and Manufacturing Process Optimization of Mechatronics Products by Innovative Key Performance Indicators; International Conference Management of Technology - Step to Sustainable Production, Croatia, 2017.