Mechatronic Reference Model for Innovation: Connecting Complex Design to Business Issues Through the Concepts of Cycles and Revisions

Abstract

This article presents a study that combined theoretical and empirical methods in a longitudinal approach to develop and validate the Mechatronic Reference Model for Innovation (MRM4i), a detailed framework for designing and developing mechatronic products. The text aims to present the model in terms of cycles and revisions and to compare it with the V- and W-models for mechatronic design, as well as with previous reference models in new product development (NPD). The primary characteristic of the MRM4i is to connect traditional concepts of new product development reference models—such as phases, decisions, documents, and prototypes—with the core principles of mechatronic design, as outlined in the V-Model and W-Model. The concepts and their implementation were exemplified through a longitudinal case study at a company, in which technical artifacts for four mechatronic products were presented and discussed, and compared to V/W-Models. Validation issues are outlined, and future research directions are presented.

1. Introduction

Industry 4.0 (i4.0) is the fourth industrial revolution paradigm, a set of digital technologies that represent physical counterparts and enable significant increases in productivity in supply chain operations [1,2]. Among the concepts of cloud computing, big data, analytics, artificial intelligence, additive manufacturing, and the internet of things, the idea of cyber–physical systems underpins the core technological enablers for i4.0 [1,3]. Mechatronics is a 1960s concept that, in today’s context, is better defined as the technologies that connect the digital and physical worlds, both in companies and at home [3,4]. Mechatronic new product development is a research topic with multiple bases [5], and in this article, it is explored through an integrated view that connects the main technical content related to the design of such products to the business issues related to their production and marketing.

Knudsen et al. [6] examined the American Product Development Management Association (PDMA) and found that the use of new product development (NPD) reference models is standard in the industry. However, applying models designed to represent the NPD is not straightforward [7,8]. On the one hand, models may reflect far more aspects of reality than a given company considers necessary to improve its processes [9,10]. However, the company’s reality may seem more complex to those involved in its daily operations, making it difficult to understand certain management concepts and recognize how the model can contribute to business practice [11,12].

The present work is based on research in which a reference model was developed for small- and medium-sized enterprises developing mechatronic products. The model’s original content was tested for its ability to generate operational results in the NPD of a mechatronics company and in master’s and undergraduate projects. Posteriorly, its concepts and NPD sequences were applied to develop mechatronic products [13,14] and general project planning predictions [15,16]. The results, both theoretical and applied, contributed to consolidating methodological reflections on the use of reference models. Part of these reflections concerns the fundamental concepts necessary for applying the model, which are considered generalizable to models beyond the one described here. Therefore, the detailed methodology for developing the model, its in-depth description, and its detailed practical validation are beyond the scope of this article, which instead focuses on demonstrating its implementation with the concepts of cycles and revisions, and compares its outputs to the V-Model (VDI, 2004) [17] and W-Model [18] for mechatronics.

Mechatronic products are those whose core functionality is delivered by systems that integrate mechanical, electronic, and software technologies [19,20] and are traditionally developed by companies operating in high-tech markets. Designing this type of product requires significant effort to organize personnel from different specialties and to structure a production system capable of manufacturing or managing a supply chain for mechanical and electronic components in an integrated manner [21,22].

Even traditional sectors have adopted mechatronic solutions to advance technology [23,24], underscoring the practical importance of a management solution that integrates these technologies into a coherent framework. Currently, mechatronic design is understood as the basis for cyber–physical systems, extending beyond physically integrated systems [25] to encompass complex solutions based on Internet of Things (IoT) concepts [3]. These solutions require the traditional cycle of measurement (sensing), computation (processing), and actuation (actuators), as characterized in control theory [26]. That is the basis for this article.

This research effort started with a fundamental research question: (1) Which reference model integrates the complete and interdepartmental efforts a company needs to make to launch successful mechatronic products into the market? We hoped to identify a model and apply it in mechatronic companies. Our theoretical research, however, did not identify a complete reference from strategy to launch that addressed mechatronic products. That is the research gap addressed in the end. Despite this, we identified the V- and W-models as the two primary references in mechatronics, widely accepted as roadmaps for the design of such products. Furthermore, we pivoted our research question to: (2) how can NPD concepts be applied to the most common mechatronic models—the V-Model and W-Model—to enable their use in the same way as these traditional models in an integrated path from strategy throughout post-launching efforts in mechatronic NPD?

The Mechatronic Reference Model for Innovation (MRM4i) has this specific value; its application surpasses conventional models by integrating additional NPD concepts to represent the full new-product development process for a mechatronic product. MRM4i integrates engineering design with manufacturing homologation, market-entry strategies, and product certification, enabling a company to innovate with mechatronic solutions. The objective of this paper is to present the new model and compare it with the V/W models.

The following section provides an overview of the methodology for constructing the reference model, followed by a theoretical discussion on reference models, a theoretical analysis of mechatronic design in the state-of-the-art literature, the application of the modeling concepts in the MRM4i framework, and examples of the longitudinal tests in the research that gave rise to this text.

2. Method of Developing the Reference Model

2.1. General Research Method

The general model for this research followed the hypothetico-deductive method, as outlined by Popper [27]. According to the author, the hypothetical-deductive method should follow the following sequence of steps: (1) identify a problem, usually resulting from conflicts with expectations regarding the description, explanation, or possibility of applying existing theories; (2) propose a new solution to the identified problem (a new theory); (3) deduce, from the proposed theory, its consequences in the form of testable propositions; (4) conduct tests, through observations and experiments, to refute the propositions; and (5) reformulate falsified hypotheses (propositions) or provisionally ratify the propositions that passed the refutation tests. Below, we will discuss how the work addresses the steps of the hypothetical-deductive method.

In terms of Problem Identification, the literature review enabled us to identify a set of technical texts on the work’s main areas. The analysis of this material is consolidated in the next section. To determine the research problem presented in the Introduction, business process modeling theory is used to conduct a systematic analysis of selected texts on new product development and mechatronics. This was achieved by analyzing the presence of business process content types in NPD theories. This stage of the work is summarized in Section 3.

The new solution proposed in this work is the model itself, developed according to the methodology presented in Section 4. From the new solution, we deduced testable propositions. The propositions were from two different approaches. Firstly, the set of concepts used to systematize the model must maintain high internal consistency. This means that when applying a given element of the model, the result must be consistent with the underlying theoretical framework. In this sense, the concept of process area capability levels [28] was used to guide the model’s application. Therefore, the results of the application must be consistent with the theory developed by CMMI: the process areas in which the model was applied to a greater degree should show a greater increase in their capability level (PROP_1). The analysis of this proposition is presented in Barbalho and Rozenfeld [29] and summarized in Section 5.7.

The second approach to testing the proposed solution is based on the central concept underlying the work: that, when applied, a NPD reference model should produce significant improvements in process performance. This idea, although it motivated the work, is not proven by NPD theory. Therefore, the second proposition regarding the model’s use is that its application should significantly improve NPD performance indicators (PROP_2). The analysis of this proposition is also presented in Barbalho and Rozenfeld [29].

The next step in the hypothetical-deductive method is to perform tests. The tests performed with the reference model involve applying it to a real-world project. The first model application tests took place between September 2003 and March 2005. The leading researcher was integrated into a project team at a company that develops mechatronic products. Throughout the period under consideration, demand for applying the mechatronic model within the company was met. In the sequence, the model is currently in use at the first company, but other uncontrolled applications were identified to support process improvement. Concurrently, a set of controlled applications was developed to support mechatronic product development and simulate mechatronic NPD. Among all mapped applications, we selected the first company, given that 18 years have elapsed since 2005, when the MRM4i was fully integrated with its NPD through certified protocols within the company’s quality system. These applications are presented in Section 5.

Reformulation of hypotheses is the final step and involves reflection on the model’s application and the results obtained. This analysis is in the concluding remarks of this article.

2.2. Methodology for Creating the MRM4i

Figure 1 presents the methodology used, which began with study planning, including defining the model’s objective and identifying the foundational literature to generate version V0.

The content of version V0 was used to conduct a detailed analysis of the NPD process at a company developing mechatronic products, employing a case study approach [30]. This analysis was conducted through participant observation [31,32]. At this stage, the researcher was integrated into the design team for a mechatronic product, carrying out daily activities that were systematically recorded in a field notebook. This phase lasted six months. The traditional guidelines in Eisenhardt [33] for running three to five case studies as a minimum were not addressed, since the research methodology was based on participant observation, an ethnographic-based research approach, where, when applied in companies, the researcher has tasks to perform, and is involved in the value chain of the running processes. It is not feasible to execute more than one application in a sound research effort [34].

The “Identifying Content Types for the Model” stage involved determining which aspects of a business process to model, based on process modeling theories [12,35]. These identified aspects were further complemented by elements extracted from the bibliographies on NPD and mechatronics. The authors also analyzed technical standards, such as ISO (International Organization for Standardization) [36] and IEC (International Electrotechnical Commission) [37] standards, which are essential for developing new products in highly competitive markets, including medical equipment and consumer goods. The content analysis technique, specifically its categorical analysis variant [38,39], was applied in this stage of the study. The results are summarized in Section 3.1.

The types of content to be modeled guided the refinement of the reference model into a version with the required level of granularity to adapt it to a general mechatronic company. This enabled improvements in the company’s NPD based on its propositions—in other words, making its application possible. The application of the reference model involved using it in real-world projects. It was conducted using the concepts and techniques of action research, as outlined by Thiollent [40] and Coughlan and Coghlan [31], over an initial 24-month period. The researcher was once again integrated into the company’s project team, where the case study was conducted, and began implementing improvements to its NPD based on managers’ demands, data from the previously conducted case study, and a capability evaluation based on the CMMI capability and maturity levels [28].

At the end of the 24-month period, a new CMMI-based capability study was conducted to compare the final level of process capability with the initial level for mechatronic NPD within the company. Additionally, a questionnaire was developed to assess the application’s impact and gather feedback from the company’s NPD participants on the work’s limitations. Seventeen NPD participants were interviewed, including the primary functional managers involved, all project leaders, and selected team members. These results were presented in Barbalho and Rozenfeld [29,41] and summarized in Section 5.7. The data collected were analyzed, and a final systematization of the model was developed (“Version V3 of the model”).

Analyzing the differences among the model versions, V0 was well suited to the NPD literature, with sound modeling methods for gathering information not only on the steps involved in developing a new product but also on the organizational units involved and the main information flows between phases in a stage-gate approach. Nevertheless, it was generic; it could be applied to any product a company develops, but it lacked the in-depth approach needed to support designers in their tasks and to identify the holistic steps the whole company needs to advance the development process. Version V1 follows the case study conducted through participant observation. As the researcher was responsible for ensuring the product met certification standards, and given its proximity to electronics, power supply, electromagnetic immunity, and compatibility, these discipline-specific issues were addressed in version V1. Systems engineering elements were also incorporated into the model in the first versions, enabling the deployment of systems, subsystems, and components (SSCs).

Version V2 was developed after analyzing the model’s content types, with most of the material presented in Table 1 already analyzed. Consequently, version V2 was a highly mechatronic version with cycles to identify sensing demands, select components, and integrate drivers, instrumentation, control software, and actuator elements, along with the corresponding setups. At that time, the leading researcher’s certification role had evolved to process certifications in accordance with ISO 9001 [36] and specific rules for medical equipment, including resolutions from the Brazilian health surveillance agency. These elements were integrated in version V2. All these previous versions were systematized in an Excel spreadsheet.

The evolution from V2 to V3 was gradual, as the researcher experienced continuous professional growth within the company, which had become a leading supplier to the Brazilian Space Agency and had assumed management functions in that capacity. In April 2005, version V3 was started during a company’s sabbatical. It lasted six months and was thoroughly reviewed and documented in a document with illustrative figures and a few templates. The text was first published on the company’s homepage and later made available as a free tool on the research group’s website. The V3 version includes improvements based on practical experience managing highly complex mechatronic projects, as well as advances in certifying medical equipment for the European and North American markets.

At 18 years after the initial systematization, the model is used nationwide, with its phased version available via an online tool. Some controlled applications have been developed by the primary author and his research group. One of these applications was systematized in this paper, with a focus on design cycles and revisions, and is based on the longitudinal case of the company in which it was previously developed; the company continues to apply the model to the products it develops and produces, 18 years after the first implementation.

2.3. Methodology for the Present Article

Since 2012, the primary researcher has been a full professor at a large Brazilian university. He teaches a post-graduation course based on the MRM4i, called Mechatronic Product Design. During this period, the course included a theoretical analysis of recent advances in mechatronic design. In the second semester of 2025, a systematic approach was adopted for these lectures to support the development of this article, following a similar approach to that of Farias and Barbalho [42], using the SCOPUS database.

The search terms used were “mechatronics” AND “new product” AND (development OR design). The total number of articles from that was 84. We analyzed the titles and abstracts of each article, reducing the total to 42. Then, we researched articles by well-known authors in Mechatronics, such as David Bradley and his partners. We found it in the SCOPUS database and supplemented it with articles from ResearchGate and results from a Google Scholar search. All the papers had their abstract analyzed. The final sample comprised 63 articles, from which we conducted the bibliometric analysis presented in Section 3.2. An additional abstract and full paper analysis reduced the sample to 10 articles, which were read in full and qualitatively analyzed. We added articles from the V and W models to this qualitative analysis, bringing the total to 16 articles in the last stage. The qualitative analysis is used to discuss the literature, references, results, and the paper’s overall concepts. This theoretical revision identified the main research gap presented in Section 1.

On the empirical side, we present realizations of the original case study, specifically comparing the MRM4i application with the V and W Models, identified in the literature review as the main references in mechatronic design. The concepts of cycles and revisions are employed in this comparison.

To validate the complete set of descriptions in this document, an interview was conducted with the company’s engineering director and the quality system manager. The main issue discussed was whether the applied MRM4i continues to evolve within the company, and the interviewees confirmed that it does. At that time, the relevant documents were gathered to substantiate this ongoing application.

3. Reference Models for the Mechatronic New Product Development Process

A process is a phenomenon that exists within companies. Processes are phenomena that occur within organizations, whether defined by their organizational chart or by adherence to a specific theoretical framework. More pragmatically, a process is “…a set of structured activities and measures aimed at resulting in a product specified for a particular customer or market” [43,44]. New product development is a “business process” [44,45]. This process strictly adheres to the organization’s core functions. It is typical of the company, the market in which it operates, and its strategy, implying that these factors differ significantly across organizations.

According to Vernadat [11], “…a process model is a consistent set of targeted and complementary models that describe the various facets of a process to meet the needs of business users.” When constructing reference models for business processes, it is essential to identify the necessary facets to ensure the process is well understood, while keeping the model accessible and not overly complex for users. In this study, these facets are referred to as “content types”. Building on these concepts, the theoretical framework was further developed by analyzing authors in business process modeling, NPD, and mechatronics to establish a comprehensive foundation for model construction. We also chose to analyze practical standards as a path to developing a more effective approach for a mechatronics company that needs to overcome market technical barriers.

At this time, we have decided not to analyze individual articles but rather entire books. In an article, it is not possible to detail a reference model in a way that enables its full utilization in a practical corporate setting. At the company level, they need access to templates and detailed examples, and only an author can deliver them in books. We then conducted an extensive literature review, drawing on the main books on NPD and mechatronics listed below and applying a categorical content analysis, following Bardin [38]. Each identified content type was recorded in a spreadsheet, and when a different content type was identified, a new list of subcategories for that type began.

3.1. Content Types of Reference Models for NPD and Mechatronics

This topic presents the facets of business processes required in a reference model, as analyzed by Vernadat [11,12], complemented by the model presented in Scheer [35,44]. The types of content suggested by these authors were used as “categories” in a content analysis of the NPD and mechatronics models of the authors listed in Table 1.

Table 1. NPD and Mechatronics Authors Analyzed in the Content Analysis.

Author Analyzed	Model Feature
[46]	Pioneer in presenting the NPD. Prior to his studies, the authors focused solely on engineering design methodology. His model is based on phases, activities, and inputs/outputs.
[47]	Systematization of the methodology of mechanical projects, focused on machine design. Exponent of the German School of engineering design. The model is based on activities, design principles, and inputs/outputs.
[48]	The first global study on NPD focused on the automotive industry. The authors developed several theories that remain in use today. The model is based on activities, information, and organizational structure.
[49]	Both authors were Professors at Harvard Business School. They developed aspects of linking product strategy with the design-build-test cycle and detailed elements of NPD organization.
[50]	Professor of design in England. His proposal is a model based on activities and decisions. It details a large set of NPD tools. It also addresses style and creativity in NPD.
[51]	MIT professor with a strong industry connection. The model employs a stage-gate approach, focusing on activities, inputs, outputs, and decision points. It employs an Extended Quality Function Deployment (QFD) to translate specifications and NPD activities.
[52]	MIT researchers and professors. They developed a stage-gate model in a format that compiles contributions from the above authors. The NPD is activity-based and incorporates the first exemplary contributions to NPD project management, including the Design Structure Matrix (DSM).
[53]	The authors, professors at the University of Tokyo, proposed that NPD is a knowledge-creation process. They developed a model based on knowledge-creation activities and knowledge conversion processes, with organizational enablers.
[54,55]	The model is based on the information flow required to produce the product. The author proposes creating systems to support product development and presents several data models to achieve this goal.
[56]	Model based on phases and activities. The author, however, is known for modeling decision-making activities across the NPD gates. He is considered the father of stage-gate models.
[57]	It is a stage-gate model based on phases and activities, with well-defined inputs and outputs. The product design is managed using statistical methods to verify compliance with input specifications aligned with the Six Sigma quality concept.
[28]	The Capability Maturity Model Integration (CMMI) model is based on a set of process areas. Each process area contains activities and goals. The areas are characterized by maturity and capability levels, which represent the degree to which best-practice process management is utilized.
[58,59]	Douglas’s (2002) and McManus’s (2003) proposals were analyzed. Their approaches are different but complementary. The first is based on information flow to map waste, while the second proposes using NPD tools to minimize waste in NPD activities.
[60]	A Brazilian stage-gate model based on phases and activities. Process areas are mapped based on prior literature, organizational units, and the flow of inputs and outputs across phases. Tables present NPD tools and methods.
[36,61]	Chapter 7.3 of the ISO 9001 standard [35] describes the “design and development” activities. The focus is on documentation, specifically identifying which activities must be recorded in the company’s management system, along with their inputs and outputs, for process certification.
[62]	It presents a flow of phases and activities with defined inputs and outputs. It suggests using Failure Mode and Effects Analysis (FMEA) throughout the NPD and establishes project outputs, including quality control plans.
[37,63]	Establish product quality standards for medical devices. Design outputs should demonstrate that products meet safety requirements for patients and operators. The general electromedical safety standard and some collateral norms were analyzed.
[64,65,66]	A guide describing project management best practices compiled by the Project Management Institute (PMI). The entire Project Management effort is divided into knowledge areas (process areas), and its activities are modeled using inputs, tools, methods, and outputs.
[67]	The Lean Product Development System (LPDS) is based on three dimensions: Process, Skilled people, and Tools and Technology. These dimensions are based on 13 principles that center on people and continuous improvement. Techniques such as Product Development Value Stream Mapping (PDVSM) are used to support NPD analysis and improvement projects.
[68]	Institute of Electrical and Electronics Engineers (IEEE) standard for systems engineering activities. The model is based on the description of phases and activities.
[69]	An American author who studied mechatronics in Japan, he bases his model on the technological concepts of manufacturing and design integration. However, there is little description of product development activities.
[25]	A Danish researcher who studied mechatronic design practices in Japan. The author reports on various activities, methods, and organizational forms in Japanese mechatronic companies.
[70]	An English researcher compiled a comprehensive set of technologies and design principles from mechanics, electronics, and software to generate mechatronic product solutions.
[19]	Book by the author whose focus is on the design methodology of mechatronic systems, especially on the specification of the systems and the development of the mechatronic product concept. It also discusses aspects of user interfaces and manufacturing technology.
[17]	It deals with micro- and macro-level design. The micro level focuses on problem-solving in engineering design. At the macro level, the model presented the deployment of system-level requirements on the first leg and the verification and validation steps on the second leg. Each step has milestones, tasks, and results.

Table 1. NPD and Mechatronics Authors Analyzed in the Content Analysis.

Author Analyzed	Model Feature
[46]	Pioneer in presenting the NPD. Prior to his studies, the authors focused solely on engineering design methodology. His model is based on phases, activities, and inputs/outputs.
[47]	Systematization of the methodology of mechanical projects, focused on machine design. Exponent of the German School of engineering design. The model is based on activities, design principles, and inputs/outputs.
[48]	The first global study on NPD focused on the automotive industry. The authors developed several theories that remain in use today. The model is based on activities, information, and organizational structure.
[49]	Both authors were Professors at Harvard Business School. They developed aspects of linking product strategy with the design-build-test cycle and detailed elements of NPD organization.
[50]	Professor of design in England. His proposal is a model based on activities and decisions. It details a large set of NPD tools. It also addresses style and creativity in NPD.
[51]	MIT professor with a strong industry connection. The model employs a stage-gate approach, focusing on activities, inputs, outputs, and decision points. It employs an Extended Quality Function Deployment (QFD) to translate specifications and NPD activities.
[52]	MIT researchers and professors. They developed a stage-gate model in a format that compiles contributions from the above authors. The NPD is activity-based and incorporates the first exemplary contributions to NPD project management, including the Design Structure Matrix (DSM).
[53]	The authors, professors at the University of Tokyo, proposed that NPD is a knowledge-creation process. They developed a model based on knowledge-creation activities and knowledge conversion processes, with organizational enablers.
[54,55]	The model is based on the information flow required to produce the product. The author proposes creating systems to support product development and presents several data models to achieve this goal.
[56]	Model based on phases and activities. The author, however, is known for modeling decision-making activities across the NPD gates. He is considered the father of stage-gate models.
[57]	It is a stage-gate model based on phases and activities, with well-defined inputs and outputs. The product design is managed using statistical methods to verify compliance with input specifications aligned with the Six Sigma quality concept.
[28]	The Capability Maturity Model Integration (CMMI) model is based on a set of process areas. Each process area contains activities and goals. The areas are characterized by maturity and capability levels, which represent the degree to which best-practice process management is utilized.
[58,59]	Douglas’s (2002) and McManus’s (2003) proposals were analyzed. Their approaches are different but complementary. The first is based on information flow to map waste, while the second proposes using NPD tools to minimize waste in NPD activities.
[60]	A Brazilian stage-gate model based on phases and activities. Process areas are mapped based on prior literature, organizational units, and the flow of inputs and outputs across phases. Tables present NPD tools and methods.
[36,61]	Chapter 7.3 of the ISO 9001 standard [35] describes the “design and development” activities. The focus is on documentation, specifically identifying which activities must be recorded in the company’s management system, along with their inputs and outputs, for process certification.
[62]	It presents a flow of phases and activities with defined inputs and outputs. It suggests using Failure Mode and Effects Analysis (FMEA) throughout the NPD and establishes project outputs, including quality control plans.
[37,63]	Establish product quality standards for medical devices. Design outputs should demonstrate that products meet safety requirements for patients and operators. The general electromedical safety standard and some collateral norms were analyzed.
[64,65,66]	A guide describing project management best practices compiled by the Project Management Institute (PMI). The entire Project Management effort is divided into knowledge areas (process areas), and its activities are modeled using inputs, tools, methods, and outputs.
[67]	The Lean Product Development System (LPDS) is based on three dimensions: Process, Skilled people, and Tools and Technology. These dimensions are based on 13 principles that center on people and continuous improvement. Techniques such as Product Development Value Stream Mapping (PDVSM) are used to support NPD analysis and improvement projects.
[68]	Institute of Electrical and Electronics Engineers (IEEE) standard for systems engineering activities. The model is based on the description of phases and activities.
[69]	An American author who studied mechatronics in Japan, he bases his model on the technological concepts of manufacturing and design integration. However, there is little description of product development activities.
[25]	A Danish researcher who studied mechatronic design practices in Japan. The author reports on various activities, methods, and organizational forms in Japanese mechatronic companies.
[70]	An English researcher compiled a comprehensive set of technologies and design principles from mechanics, electronics, and software to generate mechatronic product solutions.
[19]	Book by the author whose focus is on the design methodology of mechatronic systems, especially on the specification of the systems and the development of the mechatronic product concept. It also discusses aspects of user interfaces and manufacturing technology.
[17]	It deals with micro- and macro-level design. The micro level focuses on problem-solving in engineering design. At the macro level, the model presented the deployment of system-level requirements on the first leg and the verification and validation steps on the second leg. Each step has milestones, tasks, and results.

Content analysis of reference models for NPD and mechatronics, along with the authors’ and practitioners’ standards listed in Table 1, identified various content types to include in the business process model for developing a mechatronic product. These types of content encompass both structural elements—such as activities, inputs, and outputs—and methods typically involving mechatronic design (e.g., Failure Mode and Effect Analysis—FMEA, Design Structure Matrix—DSM, and Function-Behavior Structure—FBS), as well as strategic and organizational aspects, including performance objectives, decisions, and success factors. Furthermore, it encompasses technological and methodological dimensions, including resources, technology, methodologies, and design principles.

Table 2. Types of Content Resulting from the Analyses of Authors on Modeling, NPD, and Mechatronics.

Content Types	Definition
Performance objectives	The process seeks global objectives.
Activities	What needs to be done to meet performance objectives.
Inputs	Materials, information, and other services are used in the activities.
Outputs	Results of an activity. They have similar characteristics to inputs.
Events/messages	State of a process demonstrating the completion of one activity and the state of readiness to begin another.
Decisions	Logic for resolving pending issues faced throughout the process.
Process	Integrating a vision that summarizes the context of the activities.
Performance factors	Indicators based on performance objectives enable informed decisions about the process and its activities.
Information	Data used and generated by the process and its activities.
Organization	An organizational unit in which activities are carried out.
Roles	The responsibilities of an organizational unit can be distinguished by its competence in performing a specific activity.
Competences	Skills required by the organizational unit to carry out activities and the profile of the personnel participating in the process.
Resources	Equipment and devices that are generally used in an activity.
Technology	Enterprise communications software and infrastructure.
Time	Temporal pattern that characterizes the process and its activities.
Cost	A cost standard that characterizes the process and its activities.
Knowledge	Type of knowledge generated throughout projects: tacit or explicit, and how they are generated and transformed in the company.
Methods	Structured sets of steps, forms, and analysis methodologies related to some “output” or “decision” of the NPD.
Process areas	A cluster of best practices related to a theme that is present in various phases of the NPD.
Design principles	Design rules applicable to a given engineering field.
Design technologies	Physical principles and devices used in engineering design.
Models	Graphic, virtual, or physical representations of the product at different stages of its development (prototypes).

summarizes these content types and their definitions.

The analysis presented in the following section was conducted to further explore the use of reference models in NPD, particularly for mechatronic products. As presented in our methodology section, this analysis was intended to actualize the reference list in Table 1.

3.2. Current Discussion on Reference Models in Mechatronic Design and Development

The emergence of Industry 4.0, beginning in the late 2000s, introduced new demands for the industry, particularly affecting the development of mechatronic products. In this context, to understand these transformations and analyze how emerging digital resources have changed or complemented the aforementioned classic reference models (Table 1), an exploratory analysis of recent publications, approximately from 2007 to the present, was conducted, selected from the Scopus database applying the strings “mechatronics”, “engineering design”, and “new product development” with variations. The sample enables us to identify relevant trends, which are presented below, supported by publication distribution charts, keywords, and collaboration networks.

Figure 2 shows the distribution of publications by year in the sample analyzed. The sample contains documents published between 2007 and 2025. The highest number of records was published in 2014 during the period under analysis.

Figure 3 presents the distribution of scientific production by country. The graph shows the top 10 countries by contributions. Traditionally dominant players, such as Germany, France, and the United Kingdom, remain highly productive. Other countries with articles in the research area studied were Brazil, the United States, Canada, China, Sweden, Italy, and the Netherlands.

To generate the co-authorship map, a minimum threshold of one document per author was applied. As a result, all 175 authors met this criterion and were included in the analysis. Because some items in the dataset were not connected, the software offered the option to display only the most extensive connected set of authors, which consisted of 19 items and was selected. Consequently, Figure 4 presents the visualization of the largest co-authorship network, highlighting the main collaborative clusters identified in the analyzed dataset. The largest co-authorship network, underscoring the centrality of prominent authors, such as T. Tomiyama, who serves as a bridge between different research groups. Subnetworks are also observed around collaborators such as B. Vogel-Heuser, P. Hehenberger, C. Alvarez, and D. Bradley, who stand out for their contributions to mechatronic systems design and integration. This structure suggests the existence of consolidated communities that share methodological frameworks and have worked to update product development models.

This analysis of the co-authorship network is informed by the predominant research themes among its main contributors. The work of groups around authors such as Komoto and Tomiyama is fundamental, focusing on overcoming the inherent complexity of mechatronic design through advanced computer-aided systems architecture tools. Their proposals, based on extended Function-Behavior-Structure (FBS) modeling, aim to formalize the conceptual design phase and manage system decomposition, interface analysis, and consistency across disciplines [71,72,73]. However, as identified in their own reviews and by others in the network, a significant challenge persists: the integration gap between domain-specific tools and the automation of design practices, particularly for control software and for software generation and verification [74].

Furthermore, the network’s activity reflects a response to the paradigm shifts introduced by Industry 4.0, with research expanding into Cyber–Physical Systems (CPS) and Digital Twins [3]. This represents a shift beyond traditional sequential models toward dynamic, data-driven frameworks that support integration across the entire product lifecycle, from design and simulation to predictive maintenance. Thus, the collaboration map not only reveals a structured academic linkage but also traces the evolution of research priorities, from fundamental modeling tools to the urgent need for interoperable, automated, and lifecycle-oriented development frameworks for modern mechatronics.

To generate the entire co-authorship map, a minimum of 1 document per author was also required. Thus, all 175 authors met this criterion and were included in the analysis. Unlike the previous visualization, this one displayed the entire author network, including those without direct connections. In this way, Figure 5 presents a comprehensive overview of the co-occurrence network, enabling identification of both the main collaborative clusters and the authors who work more independently within the analyzed set. The fragmented picture that emerges reveals several smaller, less connected clusters. This dispersion reflects the diversity of approaches and the heterogeneity of contexts in which studies on mechatronic products are being developed [75]. Although the presence of consolidated centers reinforces the field’s maturity, the coexistence of isolated groups may indicate that the field is still evolving, absorbing contributions from diverse scientific traditions and industrial applications, as reported by Faria and Barbalho [42].

On the other hand, Figure 6 presents the keyword co-occurrence network derived from the analyzed bibliographic corpus. The network structure reveals the main thematic focuses and interrelationships that characterize contemporary research on mechatronic NPD, as examined in Palsodka et al. [76].

To generate the keyword co-occurrence map, a minimum threshold of 4 occurrences per term was set. Out of a total of 1716 terms identified, 89 met this criterion and were considered in the analysis. Next, the software calculated the relevance score for each term, and 53 of the most relevant terms were selected, accounting for approximately 60% of the total—VOSviewer version 1.6.20 clusters keywords according to their co-occurrence and relevance.

The relevance of each cluster lies not in its individual words, but in the central narrative they articulate. The purple cluster, for example, shows a relationship among terms such as concurrent engineering (CE), the internet, and enterprises, signaling that CE, a 90s concept, remains relevant in current internet-based enterprises. The yellow cluster highlights terms with strong co-occurrence, such as W-model, validation, interaction, subsystem, and system model, indicating the need for rigorous frameworks to define complex systems and validate their behavior. The W-model, a variant of the V-Model, was the only design framework explicitly present in our keyword analysis.

In the green cluster, the terms mechatronic design, challenge, dependency, solution, and mechatronic product form its core. Dependency is a crucial keyword, as it describes the complex interrelationships among parameters across different domains that can lead to design conflicts. In other words, it is not the disciplines themselves that generate challenges, but rather the hidden dependencies and unwanted couplings between them. The dark blue cluster groups terms such as knowledge, management, goal, engineer, reduction, and the FBS linkage method. “Knowledge management” here refers not to documentation but to the codification of the logic underlying design decisions so that they can be reused, shared, and taught.

In the light blue cluster, the words process, design process, development process, designer, and robot are central. This cluster recalls that every technical system exists within a human and organizational context. A robot is not just a product; it is a complex “context of use” that involves human–robot interaction. This cluster also calls for a process to develop sound mechatronic products and systems. Finally, the red cluster contains terms such as system architecture, computer, performance, control, conceptual design, new product, and product family. Research in this area focuses on designing scalable, modular architectural platforms that enable the development of multiple products (product families) and improve performance in terms of costs and time-to-market.

Finally, analyzing these papers, sorted by publication year, revealed the evolution of research priorities in mechatronic NPD. This pathway can be structured into three main, overlapping phases, reflecting the research community’s response to technological and market changes:

• Fundamentals and Disciplinary Integration Phase (c. 2007–2013): focused on establishing the methodological foundations and addressing the complexity inherent in multidisciplinary integration. Research during this period was characterized by conceptual discussions of mechatronics as a unifying, intelligent engineering paradigm, emphasizing the synergy among mechanics, electronics, and software [5,77,78,79]. Proposals for comprehensive process models, such as the V-model and later the W-model, emphasized continuous verification and validation throughout all technical design phases of mechatronic NPD [80]. Some authors have focused on developing mechatronic CAD frameworks and tools to support early design phases, using FBS models and emphasizing system architecture [72]. Another recurrent topic is the early identification of key challenges, such as hidden dependencies between domains and subsystems, and the need for a common language to facilitate communication between disciplines [81,82].
• Cyber–Physical Integration and Design Automation Phase (c. 2014–2019): As systems became more complex, research began to focus on automation, knowledge management, and collaborative platforms. During this period, the concept of Cyber–Physical Systems (CPS) gained prominence, marking a decisive step toward integrating physical components with computational and communication capabilities. Mechatronics is recognized as the fundamental basis of CPS and Digital Twins. Research focuses on the deep integration between the physical and digital spaces throughout the product lifecycle [83,84]. Mechatronics is fundamental to the development of CPS, enabling closer coupling among mechanical systems, sensors, control algorithms, and communication networks. This shift established the technological and conceptual foundation that would later support advancements such as Digital Twins and Industry 4.0 architectures [3].
• This phase also brings the increasing adoption of Model-Based Systems Engineering (MBSE) approaches and languages, such as System modeling Language (SysML), used to create a central “system model” serving as a single source of information throughout the entire development cycle, and the traceability of design decisions [85]. Multidisciplinary Optimization and Knowledge Management techniques were applied to capture, reuse, and optimize design decisions, reduce development cycles, and manage complexity [86,87].
• Phase of Sustainability and Human-Centered Mechatronics (c. 2020–Present): In this phase, mechatronics increasingly incorporates the principles of sustainability and human-centered design, reflecting the need to align technological innovation with social and environmental responsibility. The concern with sustainable design is acute, focusing on applying the principles of the circular economy and sound development practices, such as modularity, robustness, and remanufacturing of mechatronic products—a particular challenge given electronic obsolescence [88]. Furthermore, the incorporation of agile methodologies and design thinking is evident in the development of complex mechatronic systems, aiming to achieve greater flexibility and responsiveness to change [20,89,90]. Finally, the application of human-centered design (HCD) principles and product-service systems (PSS) in mechatronics development is highlighted, especially in sensitive areas such as digital health (e-health), where usability, reliability, and intuitive interaction are essential factors [91].

In summary, the mechatronic product development research landscape has evolved from an initial concern with “how to effectively integrate” disciplines, through “how to automate and optimize cyber–physical systems” development process, to the current question of “how to design sustainable, and human-centered mechatronic systems” within the Industry 4.0, innovative and agile paradigm.

This trajectory, conjointly with the whole bibliometric findings, highlights that the core of the mechatronic challenge has remained constant—managing complexity and interdependencies—but that the tools, methods, and end-goals have evolved in sophistication and scope. The research community has advanced to develop interoperable, automated, and lifecycle-oriented development frameworks for modern mechatronics that underpin the creation of cyber–physical systems, which are currently cloud- and Internet of Things (IoT)-based. Despite efforts by consolidated communities to advance design frameworks for mechatronic NPD, V- and W-models remain the primary references for product design. This finding led the researchers to analyze the V and W models and their updates in greater depth to identify synergies with the research objective of proposing an integrated framework for mechatronics design and product development processes, with a focus on manufacturability and marketing for successful new product launches.

3.3. V-Model and W-Model as Mechatronic Frameworks

As presented in the last section, the most prominent frameworks for mechatronic design are the V-Model and the W-Model. The V-Model, developed by the German Association of Engineers (VDI) and known as VDI 2206, presents a “design methodology for mechatronic systems” [92]. The framework’s primary focus is to provide practical guidance for cross-domain engineering problems. It deals with micro- and macro-level design [93]. For the micro level, a cycle of problem-solving is presented starting from situation analysis/take-over of the target, passing through cycles of analyzing and synthesizing the solutions, to formal steps for evaluation, and finally a decision step from which the problem-solving cycle can proceed to a learning and further planning phase, or go back to find a better solution.

At the macro level, the traditional V-Model is presented, with the first leg devoted to system design—from system-level requirements to domain-specific design demands—and the second leg dedicated to solutions and integration, following a bottom-up validation sequence [17]. A set of V-Model runs can enable a product maturity process, progressing from partial design solutions to a commercial-ready system [92]. Graessler and Hentze [93] present a new version of VDI 2206 with the scope of “Mechatronic and Cyber–Physical Systems”. The latest version incorporates checkpoints (gates) and is friendly to agile project management, while also highlighting requirements engineering procedures. Consequently, the starting point for the new V-Model is a business case rather than a fixed requirements list, as in the previous version. The reasoning is an agile view that requirements are elicited along the development process. Finally, the end of the new V-Model marks system validation, then a transition to another project phase, a customer, or another department within the company.

W-Model, a variant of the V-Model, was proposed by Natterman and Anderl [18] based on an understanding, derived from automotive industry studies, that mechatronics is not a well-integrated paradigm. They suggested that new technologies require an “adaptronics” concept to develop products in a synergistic manner. The authors proposed a Data Management-System (DM-System) to facilitate communication among “… five elements of active structures: excitations, structural components, actuator systems, sensor systems, and signal processing.” W-Model would serve as a framework for integrating these meanings and systems. Although it has been presented as a model for Product Data Management (PDM)-based design, the W-Model proposes an intermediate step in design “modeling” by integrating solutions to discipline-specific problems. This system model “… contains requirements, functions, components, and the corresponding properties and parameters as well as their interdependencies” [94].

Other authors have proposed W-Models, such as Seyedhosseini and Keyghobadi [95] and Barbieri et al. [23]. In their subsequent contribution, Natterman and Anderl [80] identified the W-Model with a “virtual system integration” step, in which domain-specific solutions can be tested and integrated through a computer-based platform. The authors presented an example from a traditional automotive design center in Germany.

Looking at the analyzed propositions for V- and W-Models in perspective, we see that they are advancing to have structured pre-design phases, came from before the requirement list, to the process of requirement elicitation, and have being started by a business case, a typical artifact demanded for project management issues [66], and a typical output from portfolio management processes [96]. These advances align with the lifecycle demands of the new era of mechatronic design, as discussed in the last section. Despite this, even current proposals for the V-Model in the business process area do not progress beyond the initiation and execution phases and require a full lifecycle assessment, as well as the integration of environmental considerations into the design cycles. Moreover, its integration into project management is limited to a clear initiation process and neglects the planning, execution, and monitoring cycles.

These reflections led us to identify the research gap and to develop guidelines for presenting the MRM4i, which is discussed in the next section.

3.4. Research Gap Identified and Guidelines for the MRM4i Proposal

This extended analysis of the main literature proposals for roadmapping mechatronic NPD allows us to identify a gap in the integration of the proposed models with the general NPD business process, where marketing, finance, human resources, and production planning at short, medium, and long horizons must be integrated to reach effective success in the innovative efforts.

The main contribution of the MRM4i model is that, unlike literature-based models, it addresses the complexity of mechatronic product development by considering engineering design issues that integrate mechanics, electronics, and software, and by addressing industrial, supplier, certification, and commercial issues within a single framework. Despite other products presenting high levels of complexity, such as nanotechnology and pharmaceutical endeavors, these are discipline-specific efforts, whereas in mechatronics, the integration and communication questions make the idea-to-market process particularly complex [25,97,98].

The theoretical study produced guidelines for developing the reference model, which were divided into NPD- and mechatronic-based issues. The guidelines serve as the primary references, and the additional authors for each content type are listed in Table 2. The prioritization was made following the content analysis, according to Bardin [38] and Moraes et al. [39], and was validated by two senior researchers in NPD and mechatronics

To consolidate the data collected through content analysis of the researched bibliography, a comparative analysis of the discussed models was chosen. To this end, the strategy of adopting an NPD author as a primary reference was employed, complemented by an analysis of a mechatronics title. For each content type across the other authors, comparisons with the reference were performed, and the results were entered into the corresponding cells of

Table 3. Types of content modeled by PDP and mechatronics authors and standards [37,47,48,49,52,53,54,55,56,57,63].

		NPD Classical Literature										Specific NPD Theories			Standards Applicable to Mechatronic NPD							Mechatronic Theories				Mech Standard
		PUGH	P&B	C&F	W&C	BAXTER	CLAUSING	ULR&EPP	N&T	PRASAD	COOPER	CREVELING	CHRISSIS	LEAN	ISO 9001:2000	ISO 13485:2003	QS9000:APQP	Normas IEC	GSQA	PMBOK	IEEE 1220:1998	HUNT	BUUR	BRADLEYa	BRADLEYb	V-MODEL	W-MODEL
Performance objectives				+	+−					−	+−	r	−		−	−
Activities		−	−	−	−+	−	−+	+	−	−+	−+	r	−	−	−	−	−	−+	−	−	−+	−	−	−+	−	−+	−
Inputs		+−	+−	−		+−	+−	−	−	−	−		−	+−	−	−	+			−	−+					−	−
Outputs				−	−	−	+−	−	−	−	−	r	−	+−	−	−	+	−		−	−+					−	−
Events/messages
Decisions		−	−		−	−	−			−	−+	r	−		−	−	−		−		−+				−
Process		−	−	−	−	−	−+	−+	−	−+	−	r		−							−		−+		−	−	−
Performance factors				+						−+			−	−	−	−							−
Information										+−				+						−					−
Organization		−		+−	+−		−	−	−+	−	−+		−				−+		−+	+			−+	−	r
Roles
Competences				+−			+−		−	−	−+		−							+			−	−	r
Resources										+					−	−						−
Technology		+−								+												−			r		−
Time					−							r		−			−		−
Cost						−				−				+
Knowledge									+
Methods		−			−	−	−	−		−		r		−+			−+		−	−			+			−	−
Models		−	−+							−		−+									−+		+	−	r
Design principles			+−																				+
Design technologies																								+	r
Process areas				+−	+−								+−				−			+−	+

(r) means the content type is a reference; the symbol (+) represents a better modeled content type than the reference (r); and the symbol (−) represents a content modeled but not as good as the reference (r).

.

The references adopted were the design theory for Six Sigma—DFSS—[57], as it is a theory that uses the systematization of best practices as a methodology for proposing the tasks necessary for NPD in the context of Lean Six Sigma; and the publication by Bradley et al. [19] as it is a reference mechatronics book with explicit discussion in regard to how to organize the development process. Once the references were chosen, the table was filled in using the following methodology:

• The types of content modeled by the reference were marked with the symbol (r);
• Each author, sequentially and from left to right, had their description of each content type compared with the reference.
• In each cell of the table, empty content ( ) means that the content type was not modeled by the author identified in the respective column.
• If the author models the compared content type in more detail than the reference, the symbol (+) was introduced in the respective cell. If the content type is modeled but in less detail than the reference, the symbol (−) is used. If the reference does not model the content type discussed by the analyzed author, the symbol (+) is introduced, and this author becomes the reference for the analysis of others in the considered content type.
• The symbol (+−) means that the content type in the considered author is more detailed than in the reference, but less detailed than another author/standard analyzed.
• The symbol (−+) means that the detail is less, but some discussions add to the analysis performed by the reference on the content type.

Following this procedure, the results are:

1.

NPD issues:

• Use of the content proposed by Clausing [51] and Ulrich and Eppinger [52] as the starting point for developing the model. All activities/tasks, inputs, and outputs proposed by these authors for the NPD were connected.
• Use of Cooper et al. [96] as the primary reference for decisions related to the NPD;
• Jointly use Pugh [46] and Pahl et al. [47] for the consolidation of product requirements and configurations;
• Use the concept of process areas of Chrissis et al. [28] to classify the content of the model and develop the NPD diagnostic framework;
• Use of performance analysis guidelines from Clark and Fujimoto [48] as the basis for creating the measurement framework for the model’s results.

2.

Mechatronic-based issues:

• The research with mechatronics authors helped identify Buur [24] and Bradley et al. [19] as the primary references for specific themes in the field, complemented by Horovitz [99], Pressman [100], and Norton [101], which introduced content on electronics, software, and mechanics, respectively.
• Use the V-Model and variances as a reference to integrate the complex connecting demands of mechanics, electronics, and software, and their validation process, with the other concepts of NPD in mechatronics.

Along with systematizing the model, the primary references cited above were complemented by those listed in Table 3, according to the classification imposed. Starting from a blank slate would be too complex, and these guidelines proved essential for advancing the MRM4i proposal.

Moreover, articles on NPD or domain-specific reviews were used to align the MRM4i content with the current literature, according to our bibliometric review, primarily through the qualitative analyses reported in a subset of the identified articles. As the model includes 127 activities and more than 580 tasks, they were appropriately incorporated into the model description. Finally, as MRM4i is a guideline and given the complexity of modeling such a dynamic engineering field, domain-specific issues could have been superficial or lacking, necessitating company-specific work for MRM4i customization, according to the modeling literature [12,44].

4. Mechatronic Reference Model (MRM4i)

Figure 7 illustrates the sequence of MRM4i phases, structured according to the value aggregation chain technique described by Scheer [35]. This technique provides a systematic approach to modeling and analyzing the different stages of a process, emphasizing how value is incrementally added at each phase.

The MRM4i phases are defined by the results (documents—outputs) they generate, following the definition of “value information” first discussed by Clark and Fujimoto [48]. Their denomination and meaning are:

• Strategy: definition of the strategic objectives to be pursued in each product line (PL). Generates a document called “product strategy”.
• Portfolio: definition of the portfolio of each PL. Document: “product portfolio”. The product portfolio, unlike the product strategy, is a list of current and proposed projects within a product line. It is also classified using a company-specific scoring model, financial expectations for each product, and a balancing analysis of the entire product line, with and without the planned portfolio. The “product portfolio” document presents a prioritized list based on the analysis outlined above.
• Specifications: define specifications. Document: “product specifications”. Before this phase, we do not focus on the product under development; instead, we make general decisions about the entire set of products a company delivers. To start the specifications phase, the previous “product portfolio” document presents a business case, statement of work, or market opportunity description to guide the specification effort.
• Project planning: definition of the project plan. Document: “project plan”. This project plan focuses on defining the project manager and the core project team, identifying the primary stakeholders, and assessing risks. The full set of planning, including an executable resource plan, an acquisition plan, a definitive project team, and quality measures for the entire set of specifications, is not yet feasible. Only in the next phase, conception, will we have a technical plan specifying which functions will be implemented in which technical domain.
• Conception: definition of the main components and principles of the solution for the main functions of the mechatronic product. Document: “product conception”. The conception should not be confused with the product concept, which provides a quick overview of the product’s differences from the company’s previous offerings and compares it to other marketed products. The conception has a deep technical basis, identifying which engineering domain is responsible for each element of the primary product function. A singular characteristic of mechatronic products is that the same function can be implemented across different domains, with both positive and negative impacts. In MRM4i, these decisions must be taken in the conception phase.
• Technical planning: detailing the project plan based on the defined design. Document: “project plan (revised)”. This phase is short, and basically, it revises the project plan according to the product conception, and a set of modeling documents is generated, such as function-behavior diagrams, and software planning models like use case diagrams, class diagrams, and sequence diagrams, according to the Unified Modeling Language (UML) artifacts [102]. If, on the one hand, technical planning implements the mechatronic modeling for the new product, on the other hand, the scope artifacts, such as work breakdown structure and its dictionary (when necessary), the resulting schedule and budget, the elements of resources, stakeholders and communication, as well as the demanded acquisitions, and consequently the risks associated with the project effort, must pass thought a general review, once conceptual decisions can have changed the basic design previously planned.
• Technical design: technical solutions for the main functions of the product. Document: “Design Baseline_1”. The primary mechatronic cycle, incorporating domain-specific and integrative solutions for the product’s primary function, is running. An alpha prototype is the most effective way to verify compliance between the parameters reached for the solutions implemented on it and the specifications revised in the previous phase.
• Optimization: solutions for secondary functions and analysis necessary to increase robustness and reliability. Results in the “Design Baseline_2”. The value created in the previous phase, together with the project team’s knowledge of the design trade-offs involved in incorporating the primary product function into the specification parameters, forms the basis for the initial design of the entire product architecture. Functions such as power supply, structural design, style, human interface, and general support must be incorporated into the prototype to produce a beta version closer to the final solution. Moreover, elements of the solutions to the primary product functions can be adjusted when conducting optimization analyses, such as robust design, reliability, and failure analysis, as well as other tests to identify potential errors or anomalous behavior. As mechatronic products involve applying control theory to machines, fine-tuning is an inevitable process that can lead to changes. Most discussions on the V-Model, W-Model, and their variants focus on the technical design and optimization phases, with their predecessor activities already presented.
• Homologation: approval of the manufacturing and assembly processes of the product. Document: “Design Baseline_3”. Despite the implementation of previous phases and the availability of solutions for the entire product specifications, significant differences in manufacturing and assembly arise when solutions are produced in small batches compared with commercial production. The homologation phase focuses on aligning manufacturing and assembly processes with the goals for commercial volumes. It must, for example, fine-tune dies, clamp parts onto manufacturing machines, and plan more effective labor allocation for assembly tasks performed by less-experienced manual operators. These solutions require close collaboration between design and manufacturing professionals and are far from the V and W Model prescriptions and from mechatronic authors. These issues are better addressed in the production and industrial engineering literature, such as Boothroyd et al. [103], Clark and Fujimoto [48], Clausing [51], and, more recently, Zorowski [104]. Eventually, changes are necessary to the entire design solution, beginning with the optimization phase, thereby justifying the need for a new design baseline. Commonly, homologation requires new prototypes to train line operators, distinct from the beta prototype, which is often led by the design team.
• Validation: validation and certification, resulting in the “ Design Baseline_5”. Following the previous phase, the company has verified that the new mechatronic product can be produced at higher volumes, as identified in its business case for strategic planning. Still, mechatronic products commonly require certification for safety reasons. They have electrically powered solutions and automatically perform functions. These solutions are used in critical areas such as fly-by-wire in aeronautics, space applications that cannot be maintained, and medical and hospital applications for life support. Despite all mechatronic products having certification issues, the primary references, such as the V-Model and W-Model, do not address them. Although certification tests are considered from the NPD beginning, with product specifications developed for verification, and given that the product must have already been tested in previous phases, an accredited product must be tested in an accredited laboratory. There is a formal process for lab accreditation; consequently, a mechatronic product must be tested in these labs, where standards specialists evaluate it. Technical documents, such as user and service manuals, are also analyzed during these certification runs. Finally, after certification laboratories approve the product, it must be documented in accordance with the national board of product approval, which varies by economic sector. Typically, these boards require extensive design, manufacturing, assembly, and quality-assurance documentation to enable the product launch. The design of MRM4i enables these documents to be drafted incrementally.
• Launch: product launch. Document: “Product Baseline_configuration_1”. All documents product are consolidated in the company’s quality systems. Additionally, the commercial sector develops its folders and promotional materials to launch the product.
• Monitoring: monitoring of the results achieved with the product and management of the modifications made in the initial production configuration. Document: “Engineering changes report”. This phase extends until product recalls, decommissioning, and market withdrawal.

The entire MRM4i process integrates mechatronic engineering design theories (see Table 3) with a primary focus on design solutions. It also incorporates new product development theories that emphasize the need for concurrent collaboration among engineering, manufacturing, and marketing departments to produce successful products [48,105]. It also implements a systematic approach to product design, focusing on understanding and prioritizing the product’s main functions [47] to be addressed in the conception and technical design phases.

The mechatronic approach begins with sound strategic and portfolio decisions that account for the flexibility and amplitude of product functions enabled by cyber–physical reasoning [3]. On the other hand, the MRM4i expands the most usual mechatronic frameworks with the suggested applications of optimization strategies that are mandatory in some mechatronic markets as space and defense, with an approach to homologate the production lines according to an integrated view of low and high volume production, as medical equipment and the automotive industry, and finally bring lights to the certification and validation processes, mandatory for all mechatronic solutions.

The colors used to represent the NPD phases in the mechatronic reference model are derived from product standardization. In this field, red indicates a lack of safety, yellow suggests a need for attention, and green indicates regular product operation [37,63]. In the model developed, the colors have the function of facilitating the transmission of the idea that, in the initial phases, there is a great uncertainty related to the expected results for the products that may become part of the portfolio of a company, according to the concept of “development funnel” [49,106].

The degree of uncertainty is higher in the strategy phase, as there are no concrete details about the products to be developed to meet the planned objectives. This initial uncertainty is significantly reduced only during the project’s planning phase (when the colors transition from red to yellow). At this point, it becomes possible to predict project deadlines and costs. From the technical design phase, the product goes from abstraction to concrete design solutions. From the homologation phase, the product design is unlikely to be discontinued. This is because practical marketing work on product positioning will have been conducted, along with a high investment in the physical, personal, and commercial infrastructure required to introduce the product into production lines.

The elliptical shape in the model’s representative figure aims to convey that the intermediate phases of the NPD consume most of the effort in developing a new product. It demonstrates that these intermediate stages are filled with engineering design tasks, which makes them longer than the previous stages. Moreover, in the intermediate stages, the project requires engineering, marketing, manufacturing, finance, human resources, and infrastructure provision. The technical scope and effort required by the company are significantly greater than in the extreme phases. Although there is no measure of the NPD timeframe, the equal-length value chain steps indicate the effort required for each NPD phase.

The model’s decision structure is also illustrated in Figure 7. Decisions occur at the end of each phase, and the figure depicts the types of decisions that occur during NPD. The decisions described in () are portfolio reviews, conducted for a specific set of products. In the strategy phase, the set is all the company’s products. All the items in the portfolio are from a specific LDP. The gates illustrated by () are business-focused decisions based on project performance indicators. The gates represented by () are technical decisions made during peer review meetings that implement the second leg of the V and W models, and gate () indicates the closure of a particular development project after the product ramp-up.

Note that the model comprises 127 activities, organized into the 12 phases outlined above. The final version was developed in web publishing software, and a website was created. Thus, a comprehensive set of navigation tools based on hyperlinks and hypertext was made possible. For each activity, a detailed implementation breakdown is provided, including descriptions of 587 tasks. A paragraph outlines the scope and how each task will be performed. Its input and output information are described. This detail escapes the scope of this article. Next, we discuss the key concepts for implementing the V- and W-models in mechatronic engineering design.

4.1. Relation to V-Models: Cycles and Technical Revisions in MRM4i

The V-Model’s primary focus is design-verification cycles, starting with systems and progressing to subsystems and components [92,93]. It is widely accepted as a reference for mechatronic design cycles, but it does not include representations of the necessary connections between a specific design effort and the value chain for a successful new product launch. This includes identifying market and technological opportunities (strategy and portfolio phases) and launching and managing the product post-launch. Although a product modeling stage has been added before the verification and validation phase [18], the W-Model does not address these essential activities to guarantee NPD success. As already presented, the MRM4i contribution is to connect mechatronic engineering design to the business issues related to the successful market introduction of new products.

Although the main activities in the intermediate phases (from specification to validation) must focus on ensuring the designed product meets its specifications, the strategic and portfolio dimensions are continuously evaluated. Additionally, the manufacturing, quality, and supply chain must be designed in parallel with the procurement and commissioning of new equipment. Eventually, new factories demanded the start-up of production. Moreover, depending on the product’s level of innovation, new markets need to be researched and developed before an effective market launch. Finally, integrating product characteristics, the bill of materials, and the information technology infrastructure required to monitor product configuration and customer relationship tools is also required before making a product launch decision.

This set of activities is far from the strict V-Model tasks, and our review of the literature shows that there is no conceptual reference model for managing this complexity in a meaningful way. The relations between the MRM4i and V-Model are represented in Figure 8.

Figure 8 presents how the V-Model interacts with MRM4i. It begins with the specifications, in which all MRM4i activities are precisely within the scope of the new V-Model [93], emphasizing a requirements-elicitation cycle. The next phase, the project plan, is not addressed in the V or W-Models but is provided only as a list of specifications for a company to organize a team to comply with, except in the W-model of Natterman and Anderl [80]. The conception phase focuses on designing subsystems and components in accordance with the V- and W-models. The next phase, technical planning, is fully dedicated to modeling the new product design, including the hardware side (functions, behavior, and structure—intended product tree) and the software side (use cases, classes, and sequence diagrams). It represents the small second leg of the W-Model in Natterman and Anderl’s [18] proposal.

If we analyze the following phases in detail, both the V and W models proceed through the technical design (P7) and optimization (P8) phases (see the shaded V in Figure 8). Although they have not modeled the homologation and certification/validation steps for a mechatronic product, we represented the V-Model through the end of the validation phase (a non-painted prolongation of V, Figure 8). That is because, at this stage, the design cycles can still be run when changes are required for process homologation, product certification, or product validation. We did not paint the whole V in Figure 8 because the tasks prescribed for the homologation (P9) and validation (P10) phases are not addressed in the V- and W-Models, such as document manufacture and assembly processes, training operators, define quality control limits, and calculate processes capabilities for P9, or generate product manuals, installation, and service manuals, as well as generate technical and risk reports for certification. It is better exemplified in Figure 20, at the end of Section 5.

The recursive refinement of systems into subsystems, a core aspect of the V-model and W-models, is addressed in the MRM4i as follows. In the specification phase (P3), we have the system and a primary subsystem refinement once the requirements are being deployed using a top-down approach, such as Quality Function Deployment (QFD) or other requirement methods. It is the basis for a primary project management effort detailed on P4. In phase P5, the project team is already in charge of the project and starts work on the conception phase (P5). The discussion focuses on the allocation of solutions across the mechatronic domains. Some solutions will be mechanical, others electronic, and still others software-based. Special attention will be given to sensing-actuation solutions once specific solutions can be derived from design principles in mechanics or electronics. That discussion in the conception phase concerns the system and subsystems identified in the specification phase (P3). However, it can also include, add to, or refine subsystems within a systems engineering framework. This phase focuses on high-level component design, as the team must identify a fully feasible concept that meets product requirements. The main conceptual components must be identified and selected only to the extent necessary to realize the selected conception.

In some engineering areas, such as aerospace and aeronautics, Phase P6 is understood as the end of Phase P5 and is dedicated to architectural design, or to generating the first version of the product architecture. In the MRM4i, it is divided once the conceptual phase requires a technical gate () in peer-review meetings. However, the architecture and its deployments require a managerial review (type gate) because they involve decisions regarding product modularity and platforms [107]. The product architecture includes a hardware component, in which components are specified across the entire product tree. These specifications will initiate procurement of the required materials and processes (primarily mechanical) and the analysis of datasheets for electronics and electromechanical components, including pneumatics and optomechanical solutions. On the software side, the architectural design involves producing UML artifacts, such as use cases and sequence diagrams, as well as class and entity-relationship diagrams for data structuring. All these elements in P6 represent the System, subsystem, and component design, which in MRM we call SSC deployment. The subsequent system and subsystem realizations are based on the concepts of primary and secondary functions from Pahl and Beitz and contributors, in the phases P7 and P8, respectively.

The cycle for system deployment to subsystems and components, and the corresponding bottom-up validation from V- and W-Models is modeled in the MRM4i with two concepts: cycles, to represent the design-build cycles [49,54,55,108], that are precisely the concepts of validation to the requirements for the SSCs; and the concept of revisions, derived from the “refinement” approach of Ulrich and Eppinger [52], that is a practical way of revisit the requirements and project plan along with the downstream NPD phases. These concepts are shown in Figure 9. They implement the cycles in the V and W models and extend them to all concepts addressed in MRM4i.

Cycles are defined as ways of implementing the concept of simultaneous engineering. They represent sets of activities, either within a single phase or across different phases, that must be carried out with a considerable degree of parallelism. This parallelism enables early development of solutions to design problems that, if handled sequentially, could lead to significant rework and delays in project deadlines. Cycles also represent situations in which specific partial results from a phase necessitate a return to a previous phase to review the specifications already developed.

Therefore, cycles complicate information flows within the project, making planning more difficult. To minimize cycles, the concept of “revision” was adopted, which involves reviewing certain activities performed in previous phases of the NPD without the necessity to return. In this sense, the specifications developed in the “specifications” phase (P3) are revised in the “conception” phase (P5) as a more mature understanding of the project’s technologies emerges. This process is called specification revision.

Similarly, the “technical planning” (P6) phase revises the project plan preliminarily developed in the “project planning” (P4) phase. This revision aims to deepen the project’s activity plan because, in the P6 phase, well-defined conception and abstract models, such as product architecture and software requirements analysis, already support the detailed specification of the work to be performed. Furthermore, during the gates that occur throughout a project, both the product specifications and the project plan are reviewed, which can be considered revisions.

The design cycle incorporates feedback from the “technical design” phase, informed by information gathered in the “optimization” phase. This type of feedback occurs for two reasons. First, the “technical design” phase is intended to support solutions for the product’s primary functions. In contrast, the “optimization” phase focuses on addressing secondary functions that may affect the performance of the primary solutions. Second, during the “optimization” phase, technical analyses of risks, reliability, mechanical safety factors, and signal-to-noise ratios are conducted, which may also require modifications to the solutions for the primary functions.

The process cycle involves refining the process documentation and, if necessary, modifying the baseline from the “optimization” phase to accommodate constraints within the company’s manufacturing sectors. The process cycle may necessitate revising the design cycle. Specific changes to the tolerance specifications of certain design parameters may require reassessment of the solutions developed for the primary functions.

The validation cycle takes place between the “validation” and “homologation” phases. This cycle aims to analyze the impact of incremental product changes on manufacturing costs and risks. Incremental modifications during the “validation” phase may result from adjustments needed to address issues identified during product certification testing, a common issue in mechatronics because of the inter-domain integration, and the stress imposed on the product for complying with normative requirements, or customer suggestions when testing the real product emerged from the entire NPD process.

Looking at Figure 8, a reasonable discussion would be whether it is reasonable to expect no overlap in the “Specification Revision” cycle and the “Design cycle.” Would this Figure 8 also imply that the later cycles will not affect the specifications? Does the MRM4i make provision for traceability of requirements, as in systems engineering, to aid in assessing the impact of specification changes later in the development process? The answer is that the specification revision is a prior cycle to freeze the specifications. It is not the case that the requirements will not change. It will change, but it does not demand a cycle back to the specification revision. That is why the MRM4i conceptualizes revisions as distinct from cycles: revisions are not physical prototyping cycles; they are typically knowledge- and information-based, whereas cycles involve design-build-test problem-solving.

After P6, the specification is frozen, but the requirements may change once you must procure real-world materials, components, and processes to prototype mechatronic products; their tolerances may cause their behavior to deviate from theoretical predictions. Only this issue will require changes to the requirements values, and consequently, the outputs from phase P6 will change. However, more impactful changes can emerge when the design team tests the build components, integrates them into their subsystems, and tests the entire subsystems. Progress cannot proceed as expected, and subsystem changes may be necessary, with implications for components; another design-build-test cycle is required. That is highly dynamic; in a real-world project, these design changes can occur more than once a day, and they will not be reflected in the documentation from previous gates in a cycle-back. They will change at the next gate, revising the previously frozen specifications. That is a practical way to maintain the value generated straightforwardly. It implements the role-waving planning concept from project management [66].

The gate structure proposed in the MRM4i model also aligns with the division between cycles and revisions and supports avoiding intersections between specification revisions and the design cycle. For the P6 phase, the gate is type 2, i.e., a central gate with business impacts, some of which involve major company decision-makers with complex agendas. That is a typical implementation of the gates concept, as described by Cooper et al. [96]. Indeed, the specification is frozen until the whole prototype (the Beta) is approved at the end of the optimization phase. For the MRM4i, each gate has a decision checklist and an output document to be filled. For phases P7, P8, P9, and P10, we have formal configurations to be frozen (see Section 4.2), and the requirement list is a mandatory element for product certification and approval by regulatory boards.

The W-model presents a digital integration phase in the middle of the W, as discussed in Section 3.3. MRM4i covers these applications once the previously mentioned product architecture is fully information-system-based. At an automotive Original Equipment Manufacturer (OEM), all artifacts will be created using Computer Aided Design (CAD), Product Lifecycle Management (PLM), and Enterprise Resource Planning (ERP) systems. The solutions designed on P7 will be performed using Mechanical-CAD and Electronic-CAD systems. The software solutions will be designed using the platforms already in use at the company and will commonly integrate the conceptual models into the detailed design. The necessary virtual integration among the models will be verified, and a go/no-go check will be conducted for the specified gates at the end of P5, P6, P7, and P8. The virtual integration is, therefore, not a phase, but a checked item on the prescribed gates in the MRM4i.

Whilst in an automotive OEM, these models are built on specific software platforms with known features for virtual integration; many mechatronic companies lack these packages and must integrate the whole system from standalone CAD systems, open-source software design platforms, and conventional office management systems. Therefore, in MRM4i, the integration focuses on gate checklists. This is a form of quality assurance in the development process, a software-free approach. Perhaps for an automotive OEM, applying the W-Model is preferable to relying on the MRM4i. Nevertheless, the majority of the automotive parts industry lacks such integrated systems for performing virtual modeling prior to designing its solutions.

Still thinking about virtual integration: when a company is developing a new-to-the-company product, complete virtual integration, as presented in the W-Model [80,94], is not useful, as the development team does not know what will ultimately work. This kind of virtual-integrated, system-based design will create numerous opportunities for change, thereby reducing the development process’s agility as design solutions evolve. That is another reason not to incorporate the virtual system integration and data management phase into the MRM4i.

4.2. Prototypes and Configurations in MRM4i

Prototypes and product configurations are traditional tools for monitoring the technical progress of projects. In MRM4i, as suggested by some authors [49,109], they are used as project management tools. From the “technical design” to the “validation” phase, there is a demand for the systematic use of prototypes to improve the Technology Readiness Level (TRL) of the in-development products [110]. These prototypes are tested against product specifications and, when they meet their objectives, are documented in design and product configurations.

Technology readiness for a mechatronic NPD project begins at TRL 3, once level 1 is characterized by new, untested principles that the company can develop, but not as part of the NPD process. The guidelines in Clausing [51], reinforced in Fricke et al. [111] and Salvador-Carulla et al. [112], call for incorporating only robust technologies into the NPD process. That is the same justification for not incorporating TRL 2 technologies into an NPD effort: at this level, only formulated applications exist in a laboratory context. From levels 3 to 9, the MRM4i can be applied as follows.

Even though some mechatronic companies can implement virtual prototypes, according to W-Model [80], in a Product Data Management (PMD)-based engineering effort, most of the companies do not have this possibility, and many mechatronic products do not fit the stabilized concept [46] necessary to be cost-effective to use virtual modeling. Given this, the cycles and revisions in MRM4i are driven by prototypes and configurations (Figure 10).

The following discusses the MRM4i prototypes and their configurations, which have already been mentioned in relation to the gates (item 4.1):

• Conceptual prototypes—“experimental” or digital models (MATLAB, Simulink, CAD Models, etc.) used as proof-of-concept of the product regarding the main components and their physical and functional integration. That is, at least a TRL 3 prototype. It proved the concept that encompasses all primary product functions. No physical prototype is required to prove the new product’s conception.
• Alpha prototypes—used in the technical design phase to prove the effectiveness of the solutions developed for the primary functions. Once approved, MRM4i plans to freeze the “Design baseline configuration_1,” which contains solutions for the primary functions. That is a physical prototype that works in a laboratory or a minimally controlled environment. The differences between TRL 4 and TRL 5 primarily concern the relevant environment [110], but they vary significantly across product businesses. For example, in aerospace, the environmental issue has implications on the room classification (level of clean rooms), test equipment with simulations for thermal, structural, and electromagnetic stresses; but for an automotive design, it means to stress the car in a controlled circuit simulating the obstacles in a real use scene. For medical equipment, there are significant differences across relevant laboratory environments, including issues related to ethical committee enrolment. On the other hand, for a large spectrum of applications, the breadboard state, focusing on the primary functions, is more important than the environment in which it was tested. That is, the Alpha prototype can be a TRL-4 or TRL-5 solution focused on primary functions, i.e., the real differences from the following prototype.
• Beta prototypes—complete product prototypes that are used for optimization. Ultimately, the “Design baseline configuration_2” is frozen. The beta prototype is similar to those commonly utilized in the software industry where new features are launched in a “Beta version”, that is, they are ready for use, but there are myriads of possible “bugs” that only in-use applications can gather data for improvements [52], and the co-creation concept made it well-known as a development strategy for the last steps in a NPD effort [113]. Mechatronic products are often more heavily regulated than software systems, but for myriad applications, user trials are the most effective means of improving the beta prototype. In the medical, aerospace, and automotive sectors, for instance, it cannot be a useful step in an NPD effort. What is most relevant to classifying a prototype as Beta is that all functions necessary to support the design, power supply, and interfaces, as well as to pack and transport the product, are implemented and tested. Therefore, beta prototypes fall between TRL 6 and TRL 7. That is, it works in a relevant environment, and if the company wants to test the product with end users, it will do so using the beta prototype. Ultimately, all primary and secondary functions are functioning as specified.
• Homologation prototypes—used to validate the manufacturing process under normal manufacturing conditions. They are pre-production prototypes that, when approved, generate the “Design baseline configuration_3”. The TRL for homologation prototypes is TRL 8. Once the homologation phase (P9) is complete, the product design is fully supported by commercial production lines, either internally or with suppliers. There are significant differences across the manufacturing sector; for example, in aerospace, the qualification prototype is typically a single product that undergoes environmental testing in a controlled laboratory. Some tests are destructive. For medical equipment, a low batch size is used to qualify the production line for manufacturing and assembly. But for a large set of mechatronic products enabled by embedded systems, the batch size will probably be hundreds, thousands, or millions, and as these products, like common toys, educative robots, wearables in general, automated or IoT-based solutions for agriculture, livestock, forestry management, natural life monitoring, security, etc., certification is not a mandatory requirement to go to the market, and in this time, the homologation prototypes come to also be the pilot run. The most important issue is to freeze the design configuration, including all process steps necessary to manufacture the product to the same specifications as in the beta prototype.
• Pilot prototypes—pre-production prototype used together with the “Design baseline configuration_3” to validate and certify the product, after which the “Design baseline configuration_4” is generated with the final configuration of the entire product design, and manufacturing and assembly processes. One of the most difficult decisions in building the MRM4i process was the relationship between homologation (P9) and validation (P10) phases. Is it better to homologate the manufacturing process and then perform product certification, or the other way around? That is an angular decision. If a company certifies a product but it cannot be manufactured within the project cost baseline, the certification cost would be lost, and the whole effort would have to be repeated in the manufacturing and assembly processes that the company and its partners have mastered under the executable costs. If the company homologates the manufacturing and assembly processes, as well as their procurement and main suppliers, with a prototype that performs as well as the beta prototype and proceeds with certification, the possibility of major changes decreases once the whole system is under quality control parameters. That is the logic behind the phase design at the end of the engineering design in MRM4i. However, changes will occur, and a return to the process and design cycles may follow. The same reasoning applies to the customer validation process, which is also a normative process for compliance with ISO 9000 and related norms. The prototype at the end of the validation phase is a TRL-9 product, ready for market launch.
• The final design configuration is incrementally extended with commercial information (catalogs, service manuals, marketing plans, logistics plans, and production plans), generating the initial product configuration, called “Product baseline configuration_1”. The design documents for this configuration are identical to those for the representative final pilot prototypes.

4.3. Additional Discussion for MRM4i Design

The original acronym for the reference model presented in this paper is MRM (Mechatronic Reference Model). However, by searching the indexed databases, we identified a paper that used this exact acronym [114]. Despite our 2006 proposal and our 2013 Portuguese publications, it is correct to state that the paper in question predates the MRM acronyms. We have decided to review the paper for academic comparison and change our acronym to MRM4i, as presented here.

Drescher et al. [114] present their MRM process within the quality-gate model and differentiate mechatronic-specific processes from support processes. The quality-gate model proposed by the authors is intended only to address temporal aspects across the process areas and the idea-to-product timeframe. Still, the model’s main elements are present in the process areas. There is also a process area view for MRM4i, but presenting it required additional literature to underpin the modeling decisions. Additionally, in MRM4i, we preferred to focus on the stage-gate representation to visually show the reader the main steps (stages) they need to take to reach a mechatronic product, because the process area view is commonly complex, especially to know when (the moment in time for each NPD project) each activity in a process needs to be started and ended. It is easier to see in the stage-gate representation. This is a fundamental issue for practitioners: when time is the primary driver of the project budget, companies typically pay monthly salaries that should be accountable for each project underway, and they often set time-based goals for new product launches.

With respect to the process areas presented in Drescher et al. [114], there are fundamental differences in MRM4i: 1. All issues related to software, electrical/electronics, and mechanical development are in a process area called “engineering design”. Moreover, some Model-based engineering problems fall within this process area, as they are fundamental to producing a robust and reliable product. 2. Requirement engineering and Quality are in the same process area, “Product quality,” which represents the current understanding of product quality in operations management. 3. What the authors called Product management was extensively expanded into two process areas: one, “strategy deployment,” covering product strategy and portfolio management, and the other, “market development,” encompassing all issues involved in developing a new market for an innovative product. It must be carried out concurrently with the engineering issues. The opposite is a cause of significant failures in high-tech mechatronic systems. 4. Project planning, project tracking, and risk management are in the “project management” process area. 5. System engineering was called “systems architecting” when it became a model-based approach to planning and architecting how the engineering areas must integrate their results (that is an issue to discuss in a specific article). 6. We have a “supply and production design” process area that incorporates elements of system realization and supplier integration. 7. Finally, configurations and version management are similar to the process area we call “documents and configurations,” in which all issues related to documents in general, and product and design configurations in particular, are embedded. The MRM4I process areas are used to validate the model, as discussed in Section 5.2 and Section 5.7.

In general, the Drescher et al. [114] proposal is closely linked to the German school in engineering design. It is a different approach to referencing mechatronic product development, particularly by omitting the marketing component and by unnecessarily dividing project management responsibilities relative to MRM4i.

Table 1 is a subset of the complete list of books and standards used to build MRM4i. It is focused on NPD and mechatronics. A subset of books on mechanics [101], electronics [99], and software engineering [100] was excluded. A complementary set of standards for building the MRM4i was developed by the European Space Agency (ESA), outlining a process that runs from management through flight, including preliminary design, critical review, and qualification.

In particular, the main discussions in software engineering [100] were analyzed and addressed in the model. Despite software engineering beginning in the late 1960s in response to myriad problems stemming from the lack of systematic procedures to guide development, the first prescriptions were orthodox in engineering design, relying on the well-known cascade model [100]. That orthodoxy produced undesirable consequences, leading to dissatisfaction among clients and developers. The academic literature also calls for more flexible models, with the incremental and evolutionary models as the main variants.

Incremental models call for the continual refinement of both requirements and solutions [115]. It also started as a solution to resource scarcity, but today it has proven to be a successful approach for innovative systems, for which clarifying requirements is only possible by anticipating customer interaction with the system’s first versions [116]. The MRM4i is an incremental approach to mechatronic NPD, progressing from an abstract conceptual prototype to a concrete beta prototype with solutions for secondary functions. The more software-based the system is, the more incremental the development process can be. Our research group has a set of new software-based projects that began with a conceptual prototype in Figma and evolved to support the core functions of software development frameworks. An in-depth discussion of software-based applications is beyond the scope of this article. What is necessary is to explicitly state the incremental nature of the MRM4i, not only with the prototypes suggested, but with the flexible gates where intermediate solutions are only peer-reviewed and not a senior manager’s decision-making, and the concepts of cycles and revisions from which previous developments can be reviewed without causing misunderstandings of which developing stage the product is in.

The evolutionary approach to software development complements the incremental issues discussed and relies on prior decision-making to break the system into partial, valuable solutions that can already be enjoyed by early adopters, whilst advancing the system toward more robust and complete solutions based on feedback [117,118]. Methodologies generally associated with the term DevOps are inherently evolutionary and well-suited to rapidly innovative sectors. The question is whether the evolutionary approach can be separated from business issues [119]. This is addressed in MRM4i when it is embedded in strategy and portfolio decision-making, rather than after these crucial decision points. That issue is not addressed in the V- and W-Models, but in MRM4i, after phases P1 and P2, a set of requirements is elicited in P3 and revised in P5 following approval of the conceptual design. At P6, the requirement list can be decomposed into evolutionary concepts that will drive efforts in phases P7, P8, and beyond. In the field of hardware, the question of evolutionary design falls under the concept of modularization, which is a synergistic decision-making process involving top management and senior project and engineering managers [120], as presented in MRM4i.

Finally, the software world brought to the design arena the concepts of agile software development, primarily through the well-known Agile Manifesto in 2001 and later through established agile methods, such as Scrum [121] and eXtreme Programming [122]. Agile integration in new product development has been discussed for years [123], and the scale-agile concept currently links agile practices to large, long-term NPD projects [124]. However, the next-generation agile-lean paradigm is underway, with extensive case studies, such as Cooper et al. [125] (2025), that present an integration of Agile, Lean, Stage-Gate, the Scaled Agile Framework for enterprises (SAFe), and systems engineering methods.

The application of agile methods in mechatronic NPD may appear to be in conflict with guidelines and standards in some industrial sectors, such as medicine, aeronautics, automotive, and aerospace. Despite this, in contemporary industrial practice, it is not uncommon to find agile methods for short-term planning and control and traditional prescriptive practices for long-term planning and contractual agreements [126]. This is referred to as a hybrid project management approach and is a current research focus [127]. The MRM4i is an intrinsically hybrid framework. A list of prescriptive tasks for each MRM4i phase is provided; however, these are not mandatory and serve as best practices that can be used as a rolling-wave planning tool [66]. Moreover, depending on the scope of the development effort, some intermediate phases lasted more than a year, and scheduling using short sprints with concrete results is a good practice for maintaining high job performance and team motivation [128]. In the practices presented in the next section, it will be reported that this kind of integration for an aerospace project lasted a decade.

5. MRM4i Applications

5.1. General Information

The full MRM4i framework, or parts of it, was applied across a set of situations, primarily practical for companies. However, it is also scientifically reported in product design [14,129], in NPD process improvement [29,41], to plan innovative equipment and software appliances [130,131,132], to explain and document design decisions [133] (Hayata et al., 2019), and to provide a basis for NPD simulation [15,16].

In this work, we present a company-based application in which the mechatronic reference model was systematically implemented across all phases described earlier. The reported application was selected because it covers a broad range of MRM4i activities. As it was a company-based application, it helped validate the model by applying the process areas concept. Process areas are easier to communicate to non-process-improvement personnel when the entire set of activities in the stage-gate process is stratified into well-defined processes, such as documentation, requirements and quality, technical solutions, or manufacturing and supply chain development.

5.2. Method for MRM4i Application and Validation

The MRM4i application is based on the development of a capability diagnostic questionnaire. Since the concept of process capability applied from the Capability Maturity Model Integration (CMMI) suggests that a model can “…improving organizational processes in individual process areas” [28], a questionnaire was developed that reflected the MRM4i process areas described in Section 4.3 when compared to the Drescher et al. [114] proposal. It is directly based on the model’s activities.

To assess the capability of each activity in the process areas, the scale presented in Figure 11 should be used, where the definition of each capability level based on CMMI would be:

• “DOES NOT DO”—“incomplete” capability level or 0 (zero);
• “DOES”—“performed” capability level or 1 (one);
• “PLAN”—“managed” capability level, or 2 (two);
• “METHOD”—“defined” capability level, or 3 (three);
• “MEASURES”—“quantitatively managed” capability level, or 4 (four);
• “OPTIMIZES”—“optimized” capability level, or 5 (five).

Based on the questionnaire, the capability of the MRM4i process areas should be characterized. For this purpose, the activities to be listed in the “ACTIVITY” column of Figure 11, which are based on the activity flows of the phases of the MRM4i, can be broken down into their tasks (remembering, 127 activities summing up to 580 tasks) if it is considered necessary to explain them to the people to be interviewed for the characterization of the company’s NPD. Since the terms in the “CAPABILITY” column of Figure 11 may be confusing to respondents, the questionnaire is designed for direct use by the MRM4i implementer who can ask “HOW” the activity is performed to verify the interviewee’s response.

Once the questionnaire is applied, the analysis consists of calculating, on a six-point scale, the capability level of each process area. The NPD improvement proposals are then defined based on the capability diagnosis, and each capability increment that demands an improved process is identified. It should be noted that if the increase in the projected capability level for the process area (according to the projected profile concept—targeted profile, [28]) is greater than “1”, there may be implementation problems arising from the lack of maturity of the company’s NPD, and therefore, capability increases of “1” level should always be preferable.

The projected profile concept can be used to predict the results of applying MRM4i, which can then be discussed with decision-makers to clarify the application’s potential and limitations.

The MRM application method presented in this item has strong synergy with the validation of the research hypothesis constructed in item 2.1 and should allow testing of the propositions formulated; namely,

• the process areas in which there was a greater degree of application of the model should have a greater increase in their capability level (PROP_1)—if the model is applied and the final result points to an increase in the capability of the process areas in which there was a greater number of activities addressed in the application, it can be considered that there was theoretical consistency of the process areas developed, that is, that they actually represent the concept developed by Chrissis et al. [28].
• The application of the model should result in a significant improvement in NPD performance indicators (PROP_2)—regardless of the process areas in which the model was applied, the final result should indicate improvement in performance factors established in the NPD literature.

The validation of these propositions is tested through the steps illustrated in Figure 12, which are three in number: an initial testing step of PROP_1 through the application of a diagnostic questionnaire and the MRM4i itself; an intermediate test step of refuting PROP_1 and analyzing the relationship between process capability and improvement of performance indicators; and a final step of compiling lessons learned in the application of the model.

In STAGE 1, the diagnostic capability questionnaire (see Figure 11) is administered to the company to record the initial state of the process areas (initial capability level, Nci). For each activity, a strategy for applying the model is established in accordance with the procedure outlined in the projected profile concept. The model is applied, and, at the end, another application of the capability questionnaire captures the final state of the process areas (final capability level, Ncf).

The group to which the diagnostic capability questionnaire is submitted must be designated by the company’s senior management or by the person responsible for process management. It is important that the individuals to whom the questionnaire is submitted have the authority to officially represent the company in their respective areas of activity.

Once the Nci and Ncf have been determined, the degree of improvement in the process capability level is calculated using the formula:

Δc = Ncf/Nci;

(1)

The applications implemented using the reference model are then compared with the improvement strategies. The following possibilities then arise:

• Situation_1: if Δc > 1, the research hypothesis (PROP_1) is validated and the model can be considered potentially validated; and
• Situation_2: if Δc < 1, the model is not validated by the application, and therefore, its concepts must be reviewed.

If an increase in the company’s NPD capability is detected using MRM4i applications, two potential sources of error may still obscure the data required for model validation. These are: (1) the interviewee may tend to respond that there has been an improvement in the activities in which they are questioned; and (2) people evaluate capability based on the model itself, which may reinforce the tendency to consider it validated.

These sources of error imply that, in situation_1, the model may not have been validated. In other words, the application of the capability questionnaire only demonstrates that the model may be validated. Due to these potential errors, STAGE 2 of the validation of the research hypotheses is carried out, as illustrated in Figure 12, which consists of developing a second data collection tool that allows:

• submitting the results of the increase in capability of the process areas so that people who did not respond to the original questionnaire can express their opinion of agreement or disagreement with them; and
• analyzing the improvement of NPD performance indicators in the company.

By submitting the results of the increase in capability for each process area to individuals who did not participate in the initial and final capability situation diagnosis, it is possible to verify whether the results of the first group analyzed are replicated, thereby enabling data triangulation [30]. In addition, because this last group analyzed is not the one designated by the company’s senior management, there is a relaxation of the tendency to report improvements in the process areas. Another aspect that tends to alleviate distortions from STAGE 1 of the validation is choosing, for the group to which the model is submitted in STAGE 2, operational users of the implemented improvements.

The second source of error is minimized by avoiding the direct use of the reference model’s concepts in the evaluation. That is, instead of using the model itself to verify its validity and performance, performance indicators recognized as capable of demonstrating improvement in the NPD are used. Additionally, this procedure allows relating the increased capability to improved NPD performance indicators, a relationship that has been poorly identified in the specialized literature in the area.

Based on STAGE 2, the mechatronic reference model for innovation can be validated if respondents agree with the degree of capability increase identified in STAGE 1 and report perceived improvements in NPD indicators across time, scope, cost, resource, and data management, following Clark and Fujimoto [48] and Blais and St-Pierre [134]. The agreement is sufficient to validate the research hypothesis (PROP_2), since it demonstrates that the process design based on a mix of NPD and mechatronic theory generated a reference model capable of being applied in real situations and that yields results that can be explained by the theoretical frameworks that underpinned it, in this case, the concept of process capability.

The analyses conducted in STAGES 1 and 2 of the model validation enable us to determine whether there is an increase in capability and an improvement in performance indicators when the model is considered validated. However, they do not allow us to understand what determined the validity or rejection of the model, in the sense of identifying characteristics of the application method, the market, the personnel involved, the company culture, and the challenges imposed on it, etc., that were reflected in the results of the MRM4i application.

These aspects are addressed in STAGE 3 of the MRM validation. In this step, the group surveyed in STAGE 2 is asked to comment on how they view the product development process in the company compared to the moment delimited by the initial capability situation, to comment on why the degrees of capability increase were detected, and to make general comments on the application of the mechatronic model in the company. In this way, the aim is to understand why the results were obtained in the validation process, and this entails documenting lessons learned regarding the application and development of reference models. Discussion of STAGE 3 is out of scope for this article.

STAGE 1 of applying the model is conducted using the questionnaire based on Figure 11, and STAGES 2 and 3 are conducted using a specific questionnaire developed based on the capability improvements obtained in STAGE 1, complemented by open-ended questions for interviewees to comment on those results.

5.3. Defined Application

The company whose model applications are reported here is a 40-year-old Brazilian high-tech player with business units across the industrial, medical, space, and defense sectors. It is a spin-off of the University of São Paulo (USP) that develops optomechatronic products.

The equipment selected to illustrate the framework was the ADS digital fundus camera, the CAN microscope, the i-MP photocoagulator, and the multispectral satellite camera. Various other pieces of equipment developed by the company used MRM4i as a framework. These products include a Wide Field Imager (WFI) and an Amazon WFI satellite camera, a family of odontologic microscopes, X-LINK equipment for applying ultraviolet beams for ceratocone treatment, a set of devices for slit lamp connections, families of photocoagulators based on infrared, green, and yellow beams for retinal therapies, as well as defense equipment for the Brazilian Army and aeronautics. The chosen equipment was selected due to confidentiality concerns.

The digital fundus camera is a device that photographs the patient’s retina to detect lesions that may lead to severe vision impairment or loss. The equipment comprises an image-capture unit with complex optics that illuminate the eye and capture light reflected from the patient’s retina. The captured light signal is converted into electrical pulses by a charge-coupled device (CCD) sensor and then transformed into a digital image by a camera, with resolutions ranging from 1.5 to 50 megapixels, depending on the camera model. The image is transmitted to a computer equipped with image-processing software and a database for storing information generated during the exams. Users see images on a computer monitor, a cellphone, a tablet, or photographic-quality prints.

The ophthalmic microscope supports surgeries performed on the human eye. The equipment supports traditional microscopy and provides magnification up to 60×, enabling observation of the observed structure. The Microscope-CAN project aimed to improve control systems to enable automatic adjustments based on the physician’s previous setup range and to support a plug-and-play architecture using the RedeCan control system. The photocoagulator is a device that generates laser pulses at a specified power (milliwatts, mW) over a defined duration to coagulate retinal lesions and reduce scatter. The regulatory requirements for this product are quite stringent due to the high risk to vision. The i-MP Photocoagulator project involves reviewing the treatment protocol, with a focus on variations in laser power and patient exposure time. In standard protocols, these values are defined by the treating physician. In the i-MP, the values will result from software optimization for the treatment of Age-Related Macular Degeneration (AMD).

The multispectral satellite camera project involved developing a complete subsystem to integrate with the Sino-Brazilian satellite, launched in four versions, including CBERS4-B, which is currently transmitting data for environmental monitoring of the Brazilian Amazon forest. This subsystem consists of three pieces of equipment whose functions are to capture images of the Earth in the frequency range from the beginning of the visible to the near-infrared, to process and format this signal for transmission to Earth, and to control automatic maintenance functions and reliability solutions that ensure that images received on Earth meet specific quality parameters. The equipment’s basic design is optical, featuring a closed-loop thermal-control system and open-loop systems for focus and radiometry adjustment.

The fundus camera was completed, submitted, and approved for market launch. It was the first Brazilian equipment marketed in this area, establishing itself as the leader in the ophthalmologic market in Brazil. The multispectral camera was the first designed in the global Southern Hemisphere and is the primary monitoring camera for Brazil’s space agency. The photocoagulator i-MP was intended to be systematized in a worldwide patent and has undergone clinical trials at some Brazilian sites. Still, it has not been validated, certified, or launched. The microscope was designed and optimized, but not deployed on production lines.

The primary opportunity for the MRM4i application arose when the company, which focused on medical equipment, received a call from the Brazilian Space Agency requesting that engineers manufacture a satellite camera. The demands for project management and quality systems were far from the practices in use. A framework, such as MRM4i, could provide a competitive advantage in meeting contract requirements, prompting the company to adopt it. An extensive set of procedures was developed based on MRM4i’s best practices, while accounting for the company’s prior practices in medical equipment design. The set of MRM4i applications presented spans from the strategy phase through monitoring. It is compared to what should be applied if the company were using a traditional NPD process or a V/W Model. Illustrations are provided to exemplify the applications.

5.4. Applications

5.4.1. Strategy Phase

The activities of the strategy phase are initially conducted through a closed communication channel between commercial management and the company’s president, who discuss the strategy to be adopted for the product lines (PL) and extend the discussion to the other directors. With the MRM4i application, two committees were created to advise on NPD. The first is a performance management committee on which the main researcher served. This committee gathered market- and function-based indicators and discussed them against the strategic goals set by top managers.

Although collegial discussion is emphasized in the product strategy decision-making process, the commercial director personally characterized the product lines’ situation, relying solely on sales-volume graphs rather than cash-flow data, and analyzed the competitive environment in which the company is positioned. Complementing the work of the performance committee, the engineering area, with support from the primary researcher, began monitoring the competitive environment and creating technology roadmaps for the product lines, based on the mechanical, electronics, and software skills the company was acquiring, as well as the products it was developing. Both activities are prescribed in NPD frameworks, but not as part of V/W-Models. They are listed in

Table 4. Summary of MRM4i applications in the strategy phase.

MRM4i Activities	Description	Cycles and Revisions/Qualitative Observations	How It Works on General NPD	How It Works on V/W Models
Characterize product lines	Creation of a performance management committee	Not applicable	In the same way	Does not work
Analyze the competitive environment	Environmental monitoring and creation of technology roadmaps for the main new technologies mastered	Not applicable	Without a mechatronic potential with the flexibility to add to every product	Does not work

.

The fact that V/W models do not provide guidelines for the activities in Table 4 does not mean the company would not perform them; it would do so without an integrated NPD approach.

5.4.2. Portfolio Phase

As in the strategy phase, the portfolio phase was also conducted by the President and the commercial director. In this phase, the improvements are similar to what occurred in the strategy phase, as illustrated in

Table 5. Summary of MRM4i applications in the portfolio phase.

MRM4i Activities	Description	Cycles and Revisions/Qualitative Observations	How It Works on General NPD	How It Works on V/W Models
Identify potential products	Improving the way products are implemented through analysis of the relationship between new products and the company’s strategy and technology roadmaps.	Not applicable	Without a mechatronic potential with the flexibility to add to every product	Does not work
Prioritize projects under development	Analysis of potential products in relation to the company’s strategy with prioritization.	Not applicable	Without a mechatronic point of view for product synergy	Does not work
Monitor the performance of ongoing projects	Creation of a project performance committee to analyze indicators for ongoing projects.	Not applicable	In the same way	Does not work

.

According to the company’s directors—all of whom were interviewed—both the identification of potential products and the prioritization of projects were carried out by seeking business opportunities without much regard for their compatibility with the company’s product strategy, and these were later adjusted to align with it. The main issue was the creation of a performance committee in which the primary researcher served as the engineering representative. This committee focused on strategy alignment and project performance tracking.

5.4.3. Specification Phase

Table 6. Summary of MRM4i applications in the specification phase.

MRM4i Activities	Description	Cycles and Revisions/Qualitative Observations	How It Works on General NPD	How It Works on V/W Models
Define product specifications	In the Foto i-MP project, significant effort was devoted to developing the protocol specifications. This effort was repeated in the MUX project.	For the Foto i-MP project, specifications were lightly frozen because the international market was the primary goal, and the commercial department finalized them only during the optimization phase. For the MUX project, the complete set of technical specifications was available on the client website, in accordance with the Brazilian government’s adherence to the European Space Agency guidelines. Few requirements could be negotiated, and only until the conception phase (preliminary design review for the ESA development framework).	In the same way	In the same way
Establish a product verification matrix.	For the fundus camera and MUX projects, a product verification matrix was created.	The fundus camera was advanced throughout the NPD process and was only frozen during the validation phase, based on feedback and issues identified during certification testing. For the MUX project, the verification matrix was created from the beginning and frozen during the optimization phase, in accordance with the ESA’s critical design phase.	Rarely did NPD models come with this prescription	In the same way
Document and record product specifications	This was performed systematically throughout the research projects by recording it in the project logbook.	This was undertaken as a configuration management activity and as a best practice in knowledge management, in accordance with Nonaka and Takeuchi [53] and the company’s stage-gate process [97]. It is a prescribed activity in all MRM4i phases. It complies with medical regulatory standards.	In the same way	In the same way
Identify regulatory requirements	In previous projects, this occurred reactively. All the research Projects were conducted in a planned manner.	Regulatory requirements were first identified on P3 and reviewed until P5. For medical equipment, it could be changed to P9 once lab conditions indicate a need for refinement, but this usually does not require significant design changes.	Rarely did NPD models come with this prescription	In the same way

reflects the applications of MRM4i in the product specification phase. The actions listed in the first column consist of a subset of the entire description of this phase.

The product specifications for the i-MP photocoagulator project were defined in close collaboration with the engineering team and potential product customers. Customer interviews were conducted and translated into software flowcharts. This flowchart was presented to the customer and validated. In the case of the MUX project, the specifications were generated by the customer, refined by the engineering team, and compiled into a requirements list. Figure 13 shows (a) part of the specification flowchart of the i-MP project, and (b) part of the requirements of the MUX project.

In the fundus camera project, a verification matrix was created and used to test the equipment prototypes. This approach was applied in the MUX project to identify the target values for the design’s quality metrics. It was filled out for every tested camera, from the engineering model to the CBERS-4b camera. In Figure 13, we see some requirements and how they will be verified, either through tests (T) or analysis (A), along with the project life-cycle. The specifications generated for the researched products were documented in electronic files or project notebooks, first manually and later in Microsoft OneNote as a digital project notebook, all of which were ISO 9000- and collateral-norms certified.

The company’s quality department identifies regulatory requirements. This activity was previously conducted reactively after the product failed certification tests.

5.4.4. Project Plan Phase

Table 7. Summary of MRM4i applications in the project planning phase.

MRM4i Activities	Description	Cycles and Revisions/Qualitative Observations	How It Works on General NPD	How It Works on V/W Models
Generate project WBS	Establishment of a procedure for project planning.	All artifacts in this phase were reviewed in the technical planning phase. WBS for MUX and the fundus camera were reviewed accordingly.	In the same way	Does not work
Develop a detailed schedule.	Establishment of a procedure for project planning and preparation of a schedule for the MUX.	For medical equipment, the schedule was developed on a third-monthly basis, first by the project management office and then by trained project managers. For the MUX project, the schedule was systematically detailed at the project and phase levels. It was also presented and validated with the client’s technical team during the qualification phase, a process known as validation in space missions. For both medical and space projects, the schedule ranged until the launch phase.	In the same way	Does not work
Plan necessary resources	Development of a human resources and infrastructure plan for the MUX project.	This was a mandatory plan for the MUX project. It was first proposed during the first phase of management review and was reviewed through the end of the optimization phase.	Rarely did NPD models come with this prescription	Does not work
Develop a cost structure.	Development of a cost management structure in the MUX project.	It was a mandatory plan at the beginning of the MUX project, reviewed internally only by the company’s management board, with support from the project management office, until the monitoring phase.	In the same way	Does not work
Define risk management	Development of a risk management process in the MUX project.	This was a mandatory plan for the MUX project. It was first proposed during the first phase of management review and was reviewed through the end of the launch phase.	In the same way	Does not work
Consolidate project plan	Consolidation of the MUX project plan.	The project contract required this and covered the project phases through the end of the optimization phase.	In the same way	Does not work
Document and record project planning	Establishment of a procedure for project planning.	This was undertaken as a configuration management activity and as a best practice in knowledge management, in accordance with Nonaka and Takeuchi [53] and the authors’ stage-gate process [97]. It is a prescribed activity in all MRM4i phases.

illustrates the applications of MRM4i in the project planning phase. The actions listed in the first column consist of a subset of the entire description of this phase.

The WBS for the MUX project was introduced. In this project, a detailed activity schedule was developed based on the WBS. The activities necessary to develop a given project were systematized in the fundus camera project and subsequently repeated for the Microscope-CAN and i-MP photocoagulator projects. The level of detail in these projects’ schedules does not match MUX’s, which clearly establishes contractual stipulations. Although there is no standardized format, the company’s project management procedure specifies the minimum content required for project schedules.

Resource planning, cost structure development, risk management, and project plan consolidation were undertaken to meet the MUX project’s contractual requirements. Documentation and project planning records were maintained across all projects investigated, reflecting a procedure developed to comply with ISO 9001:2015 [37] requirements within the company.

5.4.5. Conception Phase

The applications of MRM4i in the conception phase are illustrated in

Table 8. Summary of MRM4i applications in the conception phase.

MRM4i Activities	Description	Cycles and Revisions/Qualitative Observations	How It Works on General NPD	How It Works on V/W Models
To model and systematize the conception	The design of the fundus camera, the microscope-Can, and the MUX camera was modeled as a block diagram.	For the fundus camera, the concept was revised during the optimization phase and formally reported during the validation phase, when the product was submitted for certification testing. Some optimization solutions were changed, but the product conception remained unchanged. For the microscope, the conception was frozen and not changed. For the MUX project, the conception was frozen during the technical design phase because, in the conception phase (preliminary design of the space development framework), several options remained under scrutiny, particularly regarding the optical design.	In the same way	In the same way

. Product conception was not explicitly documented in the company’s files. Modeling methods such as the Pugh matrix or morphological matrix have not yet been used; the only application has been to systematize the conceptual design and make it visible to the entire project team.

The modeling of product conception within the company has traditionally been viewed as a purely mathematical formulation of basic product engineering. In planning the microscope-CAN project and in the fundus camera certification documents, efforts were made to present the product using functional diagrams that highlighted the main technologies used or integrated into it. The conception of the fundus camera project, without identifying the key technologies developed, is illustrated in Figure 14.

For the MUX project, a detailed conception was formalized in a block diagram, and reports were prepared that integrated optical, mechanical, and electrical designs for each camera operation mode. It could not be presented here due to confidentiality concerns.

5.4.6. Technical Planning Phase

Table 9. Summary of MRM4i applications in the technical planning phase.

MRM4i Activities	Description	Cycles and Revisions/Qualitative Observations	How It Works on General NPD	How It Works on V/W Models
Define product architecture	The fundus camera architecture was modeled using information, energy, and material flows.	The fundus camera architecture was formalized during the technical planning phase. It was revised until the validation phase, at which point the product was submitted to the Brazilian Health and Food Board.	In the same way	Differently, but it works
Revise analysis of standards and norms.	A checklist of normative items to be followed in the projects was created.	A specific template was created for the fundus camera project and applied to all medical design efforts. It was first used in P3 and progressed through P9, with revisions tailored to the certification labs’ specific conditions.	Does not work	Does not work
Identify and analyze software requirements.	A software validation procedure was developed and documented in DFD and ER models used for the fundus camera and the MUX project.	DFD and ER models were standardized only for projects that are in the launch phase. For the MUX project, the approach was applied from the technical planning phase through the validation phase (qualification on the ESA framework). The fundus was systematized only at the beginning of the validation phase and was subsequently entered into the validation cycle, thereby affecting product homologation and optimization.	Does not work	Differently, but it works
Generate product tree	A product tree was developed for the MUX project.	A product tree was generated at the start of the MUX project in accordance with the Brazilian space frameworks. It effectively aligned with the product architecture during the technical planning phase and continued to evolve until product validation.	Commonly in later phases, but it works	Not work as a documentation structure
Technically plan the project.	The MUX project was meticulously planned using the detailed product tree.	According to the elaborated product tree, the project schedule and resource plan were refined, risks were re-analyzed and identified, and the necessary documents to validate each product tree branch were planned. It was revised until the product validation and launch phases.	Not working once planning is only made in a moment and not revised	Does not work
Specify interfaces and control.	In the MUX project, the interfaces between the equipment components were documented in dedicated documents.	A specific document, the interface datasheet, was developed from the beginning of the MUX project. It effectively aligned with the product architecture during the technical planning phase, evolved through product validation, and proceeded to the launch phase.	It works on some NPD frameworks	In the same way

presents the applications of MRM4i during the product’s technical planning phase.

The product architecture definition was carried out to document the fundus camera project and has also been applied to the MUX project and other Engineering initiatives. The formulated architecture served as the starting point for linking the design conception (Figure 14) to the description of the engineering solutions developed. In the fundus camera, each architectural block (see Figure 15) became a chapter of the technical report submitted to the National Health Surveillance Agency (ANVISA) [134]. It adhered to the terminology discrepancies found in the product documentation referenced throughout this topic. For example, the product architecture’s “capture unit” was referred to as the “image acquisition unit” in the technical report (see Figure 15).

An analysis of applicable standards and regulations was conducted to ensure that the fundus camera complies with specific legislation. A checklist was developed to assess the standard’s impact on products under development. This checklist is included in the MRM4i. The documentation structure for the MUX project was based on the product tree concept described in the MRM4i.

The acronyms in the product tree (Figure 16) identify the branches and link to the corresponding documents. For example, ‘EC’ stands for ‘contractor specification,’ a document prepared by the National Institute for Space Research (INPE).

In the MUX project, the WBS was structured according to the product tree, and the preliminary design phase (as defined by the space sector standards) was extensively detailed, covering mechanics, electronics, and optics. This technical planning refinement was used to support schedule management for this phase of the MUX project. It involved identifying work packages with detailed activity descriptions and schedules, including intermediate milestones traceable to the project’s contractual milestones.

The interfaces and control signals required to integrate the MUX camera were meticulously specified in both the mechanical and electronic domains. Although this was carried out in previous projects, in the MUX, the interfaces were transformed into block diagrams and documented in dedicated documents.

5.4.7. Technical Design Phase

In the technical design phase, activities related to producing solutions for the primary functions of the product, which would meet the mechatronics concept used in the MRM4i regarding the design of sensors, actuators, drivers, instrumentation, the control unit, communication protocols, and the basic engineering for the main functions, were already carried out.

If a company designs mechanical products, it must perform the activities outlined in this phase. If a new design is being conducted by a team, such as in a university competition, the cited elements must be addressed to complete the product design. The company studied in this paper performed all these design functions. The applications of the MRM4i in the technical design phase are illustrated in

Table 10. Summary of MRM4i applications in the technical design phase.

MRM4i Activities	Description	Cycles and Revisions/Qualitative Observations	How It Works on General NPD	How It Works on V/W Models
Document the technical solutions.	All projects were extensively documented from a technical standpoint using the project notebook.	These technical solutions were documented at the end of the technical design phase. For the MUX project, it was noted that, in line with the MRM4i timeframe, contract management was mandatory. For the fundus camera, documentation began during the optimization phase, once the MRM4i application started after the technical design phase, as with the photocoagulator i-MP. For the microscope-Can project, this documentation was performed as planned in the MRM4i activity descriptions. Once these descriptions were systematized, they were refined through the validation phase for the MUX project and the fundus camera.	Commonly not addressed in NPD models	In the same way

, with a focus on document and configuration management, which are common weaknesses across mechatronic companies, including the studied company.

The documentation of technical solutions was conducted within the company prior to MRM4i implementation, albeit in a personal capacity. Each engineer documented when they deemed necessary, in their own way. A procedure was planned to use the project notebook to systematically document solutions to each project’s main problems, in compliance with ISO 9001:2015 [37] design and development clauses.

With each technical design completed, a detailed record of ALPHA-type prototype configurations for testing was maintained. In addition to the technical aspects of the configuration sent for testing, the project notebook now records the differences between the prototypes and the locations of the source files for the mechanical, optical, electronic, and software components.

The documentation on the technical solutions culminated in consolidating the work developed during the product design process. Figure 17 shows the fundus camera control system, and Figure 18 shows the software architecture. This type of documentation was not included in previous projects. During the application of the MRM4i, it was incorporated into the project validation stage, as systematized in the company’s design and development procedure to comply with ISO 9001:2015 [37] and ISO 13485:2016 [61].

Technical design documentation and records were maintained for all projects studied. For the MUX project, a mandatory step is required for the government payments throughout the project life cycle. For medical equipment, it demonstrated Opto Electrônica’s compliance with ISO 9001:2015 [37] and ISO 13485:2016 [61] and was fully applied to the fundus camera project, which had entered the launch phase.

5.4.8. Optimization Phase

Table 11. Summary of MRM4i applications in the optimization phase.

MRM4i Activities	Description	Cycles and Revisions/Qualitative Observations	How It Works on General NPD	How It Works on V/W Models
Analyze product risks according to standards.	A product risk analysis procedure was developed and applied to all products except the photocoagulator i-MP.	For the fundus camera project, the process was applied from the optimization phase and cycled to the technical design phase, but it was reviewed during the validation phase. For the microscope, this was the first step in the optimization process, leading to changes in the product design. At the MUX project, a criticality analysis was initiated during the conceptual design, in accordance with Brazilian aerospace standards.	Commonly not addressed in NPD models, but predicted on regulatory standards	Not explicitly addressed
Tolerance design.	The tolerances of the fundus camera’s optical components were thoroughly analyzed, as were those of the MUX project.	Tolerance design was introduced in the company’s technical background with a strict partnership between the design and manufacturing teams. The process ranged from optimization through validation for both the fundus camera and the MUX project, with particular focus on the optical beam paths.	Commonly not addressed in NPD models	Not explicitly addressed
Test developed software	A procedure was developed to conduct software tests on equipment designs.	A total set of microcontroller software tests was performed for the fundus camera and microscope-Can projects. At the MUX project, the test equipment was a specific delivery that was thoroughly tested and documented. It encompasses the entire design, homologation, and validation cycle.	Not addressed	In the same way
Detail manufacturing and assembly processes	Detailed mechanical, electronic, and optical assembly documents were developed for the fundus camera project to facilitate the product introduction into commercial production.	For the fundus camera, manufacturability analysis and documentation began during the optimization phase and continued through homologation and validation. It was also applied to the MUX project during the conceptual design phase to the most critical components. It became apparent during the validation cycles in the optical manufacturing and assembly processes.	Not addressed	Does not work

presents the applications of MRM4i in the optimization phase, including analyses of reliability, signal-to-noise ratio, finite element analysis, design failure modes, and criticality. It also encompasses secondary functions, such as power supply, support, and fairing. Activities related to developing solutions for the secondary tasks of mechatronic products had already been carried out on the company’s previous projects. However, the analysis required to optimize the core functions and enhance the design’s robustness and effectiveness was not conducted.

The product risk analyses were standardized through a procedure that defined a sequence of steps to be carried out, using FMEA-type forms to systematize the identified risks and the corrective or preventive actions implemented and suggested, respectively. This procedure was initiated to identify product risks arising from regulatory requirements in the project notebooks. For both the medical equipment and space projects, these analyses were mandatory.

The risk analysis records were subsequently compiled into a document for the fundus camera equipment. In this document, the identified risks were systematized in an FMEA form.

An attempt was made to apply FMEA to identify design risks using a bottom-up approach based on component failure modes. This attempt was carried out as part of the Microscope-Can project and yielded promising results. A criticality analysis was performed for the MUX project, encompassing a lengthy review of more than 500 pages.

While for space projects such as the MUX project, criticality analysis supported essential design changes, for medical equipment, the team did not adopt FMEA to identify and prioritize project risks; however, they did use FMEA as a systematization tool. The tolerance design was implemented because image quality in digital retinography depends heavily on dimensional tolerances during optical manufacturing. A tolerance analysis was performed to design the dimensional chain of the lenses and spacers used in the equipment. The testing of the software developed for the fundus camera and i-MP photocoagulator projects followed a procedure that involved identifying critical parameters based on risk analyses and conducting experiments using both black-box and white-box testing. For both the medical equipment and space projects, these analyses were mandatory.

The mechanical, optical, and electronic assembly documentation for the fundus camera project was developed based on a description of the required assembly steps. The procedures initially developed were used as templates for other projects transferred to the company’s manufacturing departments.

5.4.9. Homologation Phase

At this stage, some activities require close relations between engineering and manufacturing.

Table 12. Summary of MRM4i applications in the homologation phase.

MRM4i Activities	Description	Cycles and Revisions/Qualitative Observations	How It Works on General NPD	How It Works on V/W Models
Review installation and software configuration documents.	The procedure for installing and configuring the fundus camera software was systematized and used as a reference for other projects.	For the fundus camera, this activity began in the homologation phase, was validated, returned to the design cycle, and was revised in the launch phase.	Commonly not addressed in NPD models	Does not work
Review of mechanical manufacturing and assembly documentation.	The documentation produced during the optimization phase was revised and expanded with a macro process flowchart.	To homologate the product for commercial production, this documentation was tested with homologation prototypes and refined for validation and launch. For the MUX project, these flowcharts were used to plan the manufacture of the flight models.	Commonly not addressed in NPD models	Does not work
Review electronic assembly documentation.	The electronic assembly documentation produced during the optimization phase was reviewed and expanded.	To homologate the product for commercial production, this documentation was tested with homologation prototypes and revised for validation and launch. For the MUX project, these flowcharts were used to plan the manufacture of the flight models.	Not addressed	Does not work
Analyze process failure modes.	Failure modes in mechanical, optical, and electronic assembly processes were identified, and corrective/preventive actions were established.	This step was performed for the fundus camera, subsidizing a return to the design cycle. After running the validation cycle, the product baseline configuration_1 was frozen. For the MUX project, the previous criticality analysis resulted in a qualification process for the most critical suppliers. Process failure mode analysis, combined with the design of experiments, was used to improve the optical manufacturing process.	Commonly not addressed in NPD models, but predicted on regulatory standards	Does not work
Refine supply chain and procurement documentation.	The leading suppliers for the fundus camera project were identified, and detailed contractual and production planning documentation was prepared. For the MUX project, a contractual qualification process was performed with critical suppliers.	Documents for the company’s supplier departments were developed, and the production planning and quality assurance departments were supported in purchasing quality-assured parts. For the MUX project, formal process qualification contracts were established with the most critical suppliers. In both situations, some adjustments were returned to the design cycles. Certification tests also demanded refinement to the supplier documentation.	Not addressed	Does not work
Plan product quality control	At the end of the fundus camera project, the product and assembly risks are compiled into checklists for receipt, assembly, and shipment. The same was made previously for the MUX camera.	Quality control has been in place since the beginning of the MUX project, and concurrently, the fundus camera had to be homologated with the production line operators. The homologation step demanded these documents, which are mandatory for both medical and space markets.	Some NPD models address this issue	Does not work
Approve suppliers	The suppliers of parts considered critical for the costs and assembly of the fundus camera were approved. For the MUX project, this step was mandatory.	For the MUX project, once critical parts and subsets were identified, the qualification process was conducted before the homologation phase, during which all parts and the qualification prototype were manufactured using a robust process. The fundus camera was also applied during the homologation and validation phases.	Not explicitly addressed	Does not work
Operator training	The homologation batch of the fundus camera was used for training the company’s manufacturing personnel. For the MUX, people involved in prototypes also served as assemblers in qualification and flight models.	Operator training is a typical task for the homologation and approval of new products. It is refined if any significant change is made for product validation. Typically, training is conducted when there is little likelihood of modifying the assembly process. In the case studies, only minor revisions were made with the trained personnel.	Not addressed	Does not work
Document and record the approval of the process	The approval process was documented in the project notebook, along with the related documentation.	This was undertaken as a configuration management activity and as a best practice in knowledge management, in accordance with Nonaka and Takeuchi [53] and the authors’ stage-gate process [97]. It is also a required activity under ISO 9000:2015, which requires maintaining a register for the critical analysis of design and development cycles. It is a prescribed activity in all MRM4i phases.	In the same way	Does not work

presents the applications of MRM4i in the product homologation phase. It covers applications for the fundus and MUX cameras. The other projects do not proceed to pre-launch phases.

The detailed procedures for assembling the fundus camera equipment resulted in an assembly flowchart (Figure 19). This flowchart was later analyzed to verify its suitability for the company’s manufacturing structure. Adapting the assembly flowchart to the manufacturing sector facilitated the review of the initial documentation. The review of the mechanical and electronic assembly documents adhered to the documentation standards. The process enabled the refinement of this documentation and the creation of templates for these procedures. An installation and software configuration procedure was developed for the fundus camera equipment.

The process failure mode analysis was conducted for the fundus camera project, focusing on equipment assembly and components that could pose safety risks to patients and operators. For this purpose, in addition to assembly drawings and procedures, the electrical diagrams of the circuit boards and wiring were analyzed, along with the printed circuit boards themselves, which were assembled and inserted into the equipment. In space projects, the criticality analysis performed during the conceptual design phase serves as the initial process qualification for the main manufacturing and assembly steps and for critical suppliers.

The most critical assembly parts began to undergo detailed manufacturing processes. In this case, in addition to safety risks, the risks associated with the amount of rework required to correct inevitable process failures are analyzed. This analysis produced a document that guides assembly personnel in addressing potential nonconformities identified during assembly of the part under consideration.

The supply chain and procurement documentation were detailed for the fundus camera project. Based on the assembly process failure analysis, the most critical suppliers were identified, and quality control checklists and procurement contract terms were developed. Additionally, some suppliers were visited and selected through an approval process that required prototypes to be delivered for analysis by the company’s engineering team. In the MUX project, the Brazilian space program requires these analyses and supplier documents, which formally demand a client-involved configuration control board to approve third-party manufacturing.

The procedures for assembly, integration, and testing of the fundus camera were complemented by checklists to ensure product quality throughout manufacturing and assembly. The quality control of this equipment was designed to prevent rework in the assembly and final testing departments. The transfer of parts and subassemblies from one stage to the next in the assembly process was designed to be accompanied by a checklist from the previous stage that must be properly completed, dated, and signed. For the MUX project, the assembled personnel were the same as those of the engineering prototypes. For this reason, this documentation was not necessary.

The assembly documentation, developed after being tested by the company’s specialized Research and Development team, is submitted to the manufacturing and assembly departments. Prototypes are then manufactured to train the company’s manufacturing personnel. These training sessions also enable validation of the assembly documents produced during the previous MRM4i phase and, thus, the approval of the assembly processes described in the company procedures.

The assembly documentation, developed after being tested by the company’s specialized R&D team, is submitted to the manufacturing and assembly departments. Prototypes are then manufactured to train the company’s manufacturing personnel. These training sessions also enable validation of the assembly documents produced during the previous MRM4i phase; therefore, approval of the assembly processes is mandatory before launching medical equipment.

After training, if the prototypes are verified against the design verification matrix, a record is made in the project notebook. This validates the developed process documents and their application in compliance with the company’s ISO 9001:2015 [37] procedures.

5.4.10. Validation Phase

Table 13. Summary of MRM4i applications in the validation phase.

MRM4i Activities	Description	Cycles and Revisions/Qualitative Observations	How It Works on General NPD	How It Works on V/W Models
Plan the product’s validation and certification.	The validation of the fundus camera and MUX was previously planned.	This step is phase-specific. The fundus camera involved cycles of validation, process, and design. This occurred because issues with electromagnetic emission and compatibility were not previously addressed, and once the equipment had a commercial computer integrated into its operation. For the MUX camera, all previously used lead times and work breakdowns were used to plan the phase, and it did not involve a step behind under the MRM4i cycles.	Not addressed	Does not work
Document the product according to applicable standards	The fundus camera was documented in accordance with ANVISA standards [134]. The MUX camera was documented in accordance with the Brazilian Space Agency.	The documentation for certifying the equipment at the Brazilian Surveillance Agency began in the optimization phase and was revised for validation. The MUX camera was documented from the beginning of the project, in the conceptual design phase.	Not addressed	Does not work
Validate the product	The fundus camera project was validated in partnership with ophthalmologists.	After passing the lab certification tests, the fundus camera was submitted for testing with partner ophthalmologists. Minor changes are allowed, provided they do not compromise the product’s certification configuration. This is not a step for space projects; once qualification tests are standardized, they will be used for design approval in general.	Not addressed	Does not work
Document and record the product validation	The entire validation process was documented in the project notebook.	This was performed as a configuration management activity and as a best practice in knowledge management according to Nonaka and Takeuchi (1997) [53]. It is also a required activity under ISO 9000:2015 [37], which requires maintaining a register for the critical analysis of design and development cycles. It is a prescribed activity in all MRM4i phases.	Not addressed	Does not work

presents the applications of MRM4i during the product validation phase for the fundus camera and the MUX project, the only project that has undergone this phase.

The fundus camera project was planned to meet the validation and certification requirements for this type of product. For the MUX project, validation and certification include a qualification stage in accordance with space industry standards. Unlike the company’s previously developed projects, these projects identified the certification laboratories in advance, the procedures used to certify the products, the users to whom the fundus camera would be submitted, and the tests to be performed.

The fundus project documentation was prepared in accordance with applicable standards. A detailed technical report on the product was prepared, including its architecture (Figure 13), a project risk analysis addressing the technical requirements of the applicable standards for the equipment, based on risk records from the optimization phase, and a detailed report of experiments conducted with the developed software.

All the company’s past and ongoing projects have been validated by submitting pilot prototypes to potential clients. These tests are documented in the project notebooks.

The validation process for space projects is more complex than for medical equipment because the team is responsible for creating the test plan, testing the equipment, reporting results, and establishing appropriate validation cycles as needed. It is not recorded in the same way as medical equipment; there used to be a monthly progress report that consolidated the entire status of the designed products.

5.4.11. Launch Phase

Table 14. Summary of MRM4i applications in the launch phase.

MRM4i Activities	Description	Cycles and Revisions/Qualitative Observations	How It Works on General NPD	How It Works on V/W Models
Qualify technical assistance	Technical assistance training was conducted regarding the fundus camera project	Not applicable	Not addressed	Does not work
Consolidate commercial product configuration	The documentation generated at the end of the fundus camera project is consolidated into documents that are archived and distributed as controlled copies	These documents were initiated in the validation phase and revised according to the commercial personnel’s and technical assistance demands	Not addressed	Does not work

presents the MRM applications in the product launch phase. For space projects, such as the MUX camera, these training and documents were previously developed by the same personnel who designed and manufactured the flight models under controlled documents.

Training was conducted for the company’s technical support engineers and technicians to qualify the maintenance they provide to fundus camera customers. As this product is much more complex than the company’s previous products, this activity enabled greater integration between technical support and the project.

Once the fundus project was completed, validated, and the product was registered with the competent authorities, its documentation was consolidated into written and electronic files. Although this had occurred in previous projects, in this one the process was planned.

5.4.12. Monitoring Phase

Table 15. Summary of MRM4i applications in the monitoring phase.

MRM4i Activities	Description	Cycles and Revisions/Qualitative Observations	How It Works on General NPD	How It Works on V/W Models
Evaluate product performance in the market	New products were monitored for customer satisfaction after launch.	Not applicable	Not addressed	Does not work
Monitor manufacturing performance	The developed checklists were used to monitor manufacturing quality in the fundus project.	Not applicable	Not addressed	Does not work
Explore alternative product changes	There is an established procedure for detecting and exploring potential product improvements.	Not applicable	Not addressed	Does not work
Manage product changes	There is an established procedure for managing product changes.	Not applicable	Not addressed	Does not work

presents applications of MRM in the product-monitoring phase. The applications were limited to medical products. Once, for a space project, there was a mandatory control configuration board (CCB) for change requests that ran not only within the company but also with the contractor and other subsystem suppliers.

The company’s commercial management created a customer satisfaction monitoring service that has been used to identify opportunities for product improvements, the development of new accessories, and the introduction of new models for the company’s platform or new products in its portfolio. The performance of mechatronic equipment manufacturing has been monitored using the developed quality control checklists.

The company’s product engineering and quality sectors conduct exploration of product change alternatives and their management. A dedicated document for change requests was used to coordinate cross-departmental change management.

5.5. Summary of MRM4i Applications

The MRM4i applications were first applied when the company’s NPD efforts were under pressure. However, they were subsequently standardized within the company’s quality systems, refined, and customized as the company has expanded into new endeavors and contexts. They were the basis for certifying production lines with the Brazilian Health and Surveillance Agency and for meeting requirements for supply space systems.

After 18 years, they were still in use. The fundus camera project has evolved with the development of new technologies that integrate their capabilities into smaller devices connected to smartphones, disrupting the market. A spin-off was generated to develop this business. For the equipment presented in this paper, more than 800 units were sold from the project’s beginning to 2014, when the last unit was sold. Only technical assistance is available today, but the basic documentation presented in this paper is sufficient. The company plans to return to the full fundus camera market once mobile devices are limited to applications for simple fundus diseases.

The MUX camera and other aerospace and defense products were sold as a business unit to the SAAB Group’s Brazilian subsidiary (Akaer | Engenharia Aeroespacial), which also continues to apply MRM4i best practices. The MUX Camera is in operation, actually in the 4B version, which has been imaging Brazilian environmental resources since 2014.

5.6. Comparison to V/W Models

Figure 20 illustrates the set of applications of the MRM4i model, compared with the strict application of V/W Models at the studied company. For this purpose, only the fundus camera project was considered.

Figure 20. Illustrative comparison between MRM4i and V/W-Models for the applications presented.

Figure 20. Illustrative comparison between MRM4i and V/W-Models for the applications presented.

Figure 20 encompasses MRM4i applications from specifications (P3) to validation (P10) phases. We mapped the main documents (outputs) from P3 to P10 in a non-exhaustive manner, but only to distinguish MRM4i from the strict V/W-Model application. The figure was intentionally designed to omit cycles and revisions to simplify this discussion. It follows the fundus camera project. The main evidence is a large set of required documents that are not covered by the V/W-Models framework, represented by the small boxes outside the doted V. It does not mean that a company using V/W-Models does not generate user or service manuals (for example) for its new products; rather, it means that the company needs to integrate V/W-Models with other approaches to produce the necessary outputs in an NPD effort. With MRM4i, this step is unnecessary because the framework handles integration and facilitates communication and collaboration across engineering, manufacturing, and marketing departments.

The illustrative set of documents begins with the requirements list, which, for the fundus camera, was a sheet listing the main requirements derived from the competitive equipment analysis, rather than the models shown in Figure 13. These requirements were fixed in the walls and the project notebook. They were also the input for a product backlog scheduled across quarters, aligned with the planned timeframe as the intended baseline. For that project, the primary output of the project plan was similar to that of the other medical products exemplified. Despite the strict use of V/W Models, which do not address project management issues, we represented theproject management issues with a dotted V.

The next document or representation, depending on the contractual requirements, is the product conception, which for the fundus camera is illustrated in Figure 14. It represents the material (not in this case), energy, control, and data exchange amongst the main equipment building boxes. Commonly, the main planned components are part of the conception. In this case, the CCD is the main component of the “real-time image capture system.” A set of lenses with a beam-splitter is the central element of the capture system, as is the high-level software. A halogen lamp connected through an optical fiber is a solution for the “optical lighting system”.

The next output on this line is the product architecture derived from the conception, which represents the physical parts that implement it (Figure 15, left side). In the technical plan phase (P6), the conception is also used to generate a product tree and to detail the software requirements. The exemplified product tree (Figure 16) is the aerospace version. For medical equipment, this artifact is called a master product register, which lists all physical subsets of a product and the required quality-assurance documents.

As the project progresses, the design team is meeting the specifications for the primary functions (P7), which are typically documented in test reports during the design-build-test cycles. Hardware and software solutions are frozen, as shown in Figure 17 and Figure 18, which are fully described for internal peer review or contractual discussions. Test reports are revised during the optimization phase (P8), along with a risk analysis summarizing the main concerns identified during optimization. In some business areas, reliability, structural and thermal stresses, and other specific reports are required to ensure the entire design is ready for production-line homologation. A risk analysis with a failure mode and effects analysis (FMEA) is a commonly required report for well-designed mechatronic systems and complies with the main design and development standards.

From this point to the end, the set of required outputs for a sound, well-documented, and quality-assured product for market launch is far from the traditional V/W Models. Even in P8, when a full detailment of the manufacturing and assembly issues is required to verify product manufacturability, the V/W models omit it. In P9, one of the first activities is to explore risk analysis and other design reports to develop a process risk analysis, which can also be conducted using a process FMEA approach. In conjunction with the previous manufacturability report, the project team needs to develop manufacturing and assembly procedures, quality control procedures, and documentation to ensure proper procurement. Figure 19 presents a macro-assembly flow-chart for the fundus camera. The screen presented contains assembly parts for the “capture unit” in the product architecture (Figure 15), which implemented the optical capture and lighting systems in the product conception (Figure 14).

This set of outputs serves as input for the documentation demanded for product certification, which is the most complex case for mechatronics. The illustration in Figure 20 shows the procurement, manufacturing, assembly, and quality inputs to the service manual. The risk report is an output from the product and process risk analysis. The technical report is derived from the test reports; for clarity, this network was simplified, even though it requires additional inputs. The user manual is derived from the test reports and the risk analysis. Figure 15 (on the right) summarizes the fundus camera technical report based on the product architecture developed in phase P6.

The purpose of this section was to represent the MRM4i differences compared to the V/W Models. Obviously, a company applying V/W Models will likely use other approaches to generate the outputs required for product commercialization. The way MRM4i does it is better integrated, since the reports are built incrementally based on the product readiness.

5.7. Results of MRM4i Validation

The results summarized in this section were obtained after 24 months of model application, as illustrated in Figure 21.

Figure 21 on the left shows the results from validation STAGE 1 (Figure 12), and the figure on the right shows the results from validation STAGE 2. As indicated in Figure 12, all process areas are considered improved in the company, especially the process of “documents and configurations”, “project management” and “supply chain and operations”, which is coherent with the demands presented by the company to enter on the aerospace business area, as well as its demands for ISO 9001 certification in the medical business unit.

On the right, the results of interviews with personnel from the company’s operational NPD activities are presented. The scale is traceable to the one used in the agreement/disagreement questionnaire (+2, +1, 0, −1, −2). The indicators were selected to assess the accuracy of time planning, cost and time performance, ease of integrating new designers, access to project information, manufacturing and customer complaints, and the reduction of requirements changes.

The overall media of agreement resulted in 0.27. They consider that the model has improved most in terms of the company’s capacity to integrate new designers into its projects. Additionally, positive concerns pertain to access to project information and cost control. They consider time performance less affected and note that the model application has helped reduce complaints from internal downstream departments and customers. The lower level of improvement agreement regarding the suggested indicators, and the subjective nature of these inquiries [140] have prompted the company to objectively measure the NPD indicators, and some articles presented these data, which validated the indicators related to time management, especially for project management, and the manufacture of prototypes [141,142], as well as for documents and configurations.

As suggested by the coherence between the two graphs, the interviewee personnel considered the improvements represented by Δc [Equation (1)] to correspond to the actual final state of the NPD process in the company after the first 24 months of model implementation. Over the next 16 years, the processes implemented in the first two years have evolved, and new metrics with specific protocols to identify changes and their causes must be introduced to measure the Long-Term impact of MRM4i. This analysis is beyond the scope of this article.

6. Conclusions

This article presented a set of concepts systematized within a reference model for the development of mechatronic products. It can be said that none of the concepts addressed in the article are new. However, this work contributes a reference framework that integrates NPD concepts with mechatronic references, such as the V and W models.

Despite V, W, and other mechatronic models contributing to systematizing the demanding design cycles for such a complex product, they do not address project management issues or the manufacturing and marketing elements necessary to launch a product effectively. Contributions such as those by Albers et al. [74] and Carvalho et al. [20] sought to integrate contemporary concepts of agile project management and design thinking into mechatronic reference models. However, they are not sufficiently appropriate for approving, certifying, and validating mechatronic products, as they do not extend to manufacturing and marketing.

Even consecutive V-Model applications, as suggested by Seyedhosseini and Keyghobadi [95], did not address business issues at a best-practice level. As already mentioned, although not detailed here, MRM4i was modeled as a set of process areas, implying that engineering, manufacturing, quality management, and market development issues are addressed concurrently throughout the project lifecycle. Some mechatronic products have enabled cyber–physical solutions that create new markets, and these solutions need to be exploited to feed engineering with incrementally correct requirements. In general, our analysis suggests that the traditional V-Models are appropriate for companies working on the same product concepts and variations, not for innovative products in general.

To build the mechatronic reference model for innovation, a set of 27 books on engineering design, industrial engineering, industrial design, mechanical, software, and electronic design, as well as specific mechatronic design models, was analyzed. Additionally, a bibliometric analysis identified 63 articles focused on mechatronic product design and development, and a targeted analysis was performed. Both studies point to the lack of an integrated approach to address engineering, manufacturing, and marketing requirements for the successful launch of a new mechatronic product, which is the main contribution of our work. MRM4i was conducted using a hypothetical-deductive approach; that is, it requires submission for refutation or improvement. Among the controlled applications performed by the authors, the model was useful and well adjusted, but not yet refuted.

Along with the applications presented in this paper, the elements for the cycles and revisions were presented. Cycles and revisions are the central differentiators of the V and W models in mechatronic design, consistent with systems engineering approaches. The MRM4i concept of cycles defines the required design-build-test cycles, with both abstract and concrete prototypes used to validate solutions during problem-solving. Revisions are predicted activities to improve previously performed design or project artifacts. That is, revisions are activities for predicted cycles (contingency activities), while cycles are for non-predicted changes required to improve the product design before the launch phase.

When explaining the cycles and revisions in the MRM4i application, it became apparent that, for space projects, where project documentation is a traditional risk prediction technique, the cycles and revisions followed the prescribed sequence from design to process to validation.

However, in medical equipment design, only when launch deadlines approached and certification documentation was required did safety, robustness, and reliability requirements emerge. These cycles returned the project to the optimization phase, making homologation and validation more time-consuming. Despite this, as the MRM4i best practices were implemented as needed to support the company’s goals, these improvements persisted for almost two decades at the time of this paper’s writing.

This research raises several considerations. Theoretically, it proposes a mechatronic reference model to address technical and new-product issues concurrently, which is not well aligned with the literature. It presents an exhaustive literature review of books and articles in these areas. Our review demonstrated that the mechatronics literature has evolved from technical integration to sustainability and human-centered design, and from an engineering approach to a more project-oriented, design-focused approach. Finally, our data suggest that cycles and revisions occur under sectoral and business context drivers, whereas typical medical and space contexts imply different approaches within the same company. This can be modeled and tested in future research.

Practical implications point to a lightweight framework in which mechatronics evolved within an NPD set of best practices that help a company plan its NPD projects. Instead of planning the whole project and only after work on requirement elicitation, the company must specify the product, and revise both the specification and the project plan in a set of concurrent activities that involve the conception of the product’s primary functions. Working this way, a manager can avoid addressing a broad set of product requirements and focus on the core issues in product realization.

This will also help the team rework cycles, from the final to the initial product development phases, which has made NPD reference models in the scientific literature very unusual at the company level. Moreover, some current NPD models suggest that a detailed project plan should be developed before product conception (i.e., Rozenfeld et al., [60]), yet this implies planning for requirements that may differ significantly from those of the chosen product. It is a driver of NPD malfunctions and product changes.

It is important to note that the literature-based approach to project planning-conception is mitigated by agile methodologies; however, the original budget, contractual schedules, and resource identification and planning must deviate significantly from reality as the project progresses. That is an issue for managers to address when scheduling their mechatronic NPD projects, whether to apply MRM4i in general.

Finally, the way MRM4i relates NPD phases to documents and prototypes can guide managers in maturing their NPD efforts in a feasible, easily trackable way.

This research has limitations, as the longitudinal application was based on only a company case study. Although it is necessary to understand the full context of the model’s application, this limits the generalizability of the scientific results gathered. More controlled, scientifically reported longitudinal applications need to be reported to validate, refute, or improve the model. Another limitation concerns the set of books and standards analyzed, which is even larger and not exhaustive, and which may have omitted some important references. New references should be incorporated to improve the model and guide future research. In particular, new versions of the V and W Models warrant further research. The paper does not present technical solutions in mechatronics, despite having been used to develop some mechatronic products, as mentioned. It will be addressed in future publications.

Another limitation of this paper is the lack of quantitative validation for the model application. Despite data from implementations like those presented in this paper, a focus on indicators would require more discussion of their application in theory and practice, and some validation is reported in the cited references. The model has a CMMI-based grade for best-practice implementation. While the referenced literature supports validation using time-management indicators, additional analyses of budget adherence, cost overruns, and the number of design changes would strengthen the model’s structure and robustness. Research focused on that set of indicators is a future demand.

Future work can analyze the concepts of cycles and revisions and equate them to different approaches for using the model. Revisions reduce the likelihood of returns on already defined solutions, and the better we understand design, processes, and validation cycles, the closer we can get to establishing processes that reduce rework and increase productivity. Research on the effects of more versus fewer revisions on design changes, time-to-market, and cost overruns can improve the practical application of these practices in NPD frameworks.