Int. J. Product Lifecycle Management, Vol. 13, No.

3, 2021 265

An approach and an illustrative case study for a

hybrid development process in mechatronic system
design

Sagar Mule and Peter Hehenberger*

Institute for Agile Transformation,
University of Applied Sciences Upper Austria,
Stelzhamerstraße 23, 4600 Wels, Austria
Email: sagarmule20@gmail.com
Email: peter.hehenberger@fh-wels.at
*Corresponding author

Régis Plateaux and Olivia Penas

ISAE-Supméca,
Laboratoire Quartz EA7393,
3 rue Fernand Hainaut, 93400 Saint-Ouen, France
Email: regis.plateaux@supmeca.fr
Email: olivia.penas@supmeca.fr

Stanislao Patalano and Ferdinando Vitolo

Fraunhofer J-Lab IDEAS,
University of Naples Federico II,
Naples, Italy
Email: patalano@unina.it
Email: ferdinando.vitolo@unina.it

Abstract: In Industry 4.0, the growing incorporation of cyber-physical systems

(CPS) into manufacturing facilities composed of mechatronic products brings
the need of reducing development cost while maintaining the quality and in
parallel the need to adapt changes in the product development. It is then
essential to identify the criticalities of mechatronic system development and to
introduce an optimised product development approach. As a result, our research
work focuses on combining traditional and agile approaches to improve
mechatronic products development. To illustrate the advantages of such
hybridisation, we propose a first hybrid approach along with the case study,
consisting of some elements of the Scrum method into the V-model which
include the freedom to propagate necessary changes in product architecture
during the development of its different modules. This new approach also
focuses on the required guidelines to adopt and use for enhanced mechatronic
products development and criteria for evaluation of the proposed method.
Finally, in order to provide flexibility in product architecture and modules
design, the hybrid development process is presented with illustrative case
study.

Copyright © 2021 Inderscience Enterprises Ltd.

266 S. Mule et al.

Keywords: mechatronic products development; hybrid approach; agile

approach; scrum; V-model; case study; black box analysis; white box analysis;
model-in-loop; MIL; software-in-loop; SIL; hardware-in-loop; HIL.

Reference to this paper should be made as follows: Mule, S., Hehenberger, P.,
Plateaux, R., Penas, O., Patalano, S. and Vitolo, F. (2021) ‘An approach and an
illustrative case study for a hybrid development process in mechatronic system
design’, Int. J. Product Lifecycle Management, Vol. 13, No. 3, pp.265–289.

Biographical notes: Sagar Mule is a research associate at the University of

Applied Sciences Upper Austria. His research is focused on the hybridisation of
the agile approach for the development of mechatronic product and product
service system.

Peter Hehenberger is a Professor for Integrated Product Development and the

Head of the Research Group ‘Smart Mechatronics Engineering’ at the School
of Engineering, University of Applied Sciences Upper Austria, Wels/Austria.
His core competencies cover ‘Model-based mechatronic system design’. He is
a member of IFAC TC4.1 Mechatronics, IFIP WG5.1 (‘Global Product
development for the whole life-cycle’) and Design Society, where he
co-chaired a SIG on CPS-Design (from 2015–2019).

Régis Plateaux received an Automated Production Master 2 degree (ENS

Cachan, Paris, 2004), Industrial Engineering PhD degree (ECP, 2011). He is a
Lecturer and the Head of Mechatronic and Complex Systems Department. His
main research topics are algebraic topology, mechatronic design, design,
systems engineering (MBSE) and ontology to define gates to generate and
maintain the consistency between the different levels of design, from
requirements to simulation.

Olivia Penas received his MSc in Material Science Engineering in 1999, PhD
in Physics of Materials (Smart Space composites) in 2002 from INSA Lyon
(France), and HDR degree (French habilitation to supervise PhD) in 2019. She
was the Head of the Research Technical Support Teams of Supmeca in 2006,
then the Deputy Director of LISMMA Laboratory in 2013 and Research
Deputy Director of Supmeca (Paris) since 2015. Her main research topics are
systems engineering (MBSE), agility, design metrics, mechatronic design and
multi-physics conceptual design.

Stanislao Patalano is a Full Professor for Drawing and Methods of Industrial

Engineering at the University of Naples Federico II. He is a Regular Professor
of Modelling and Virtual Prototyping, Drawing for Mechatronics and Industrial
Technical Drawing. He received his Master’s in Mechanical Engineering in
1997 and PhD in Machine Design from the University of Naples Federico II in
2001. From 2011, he is the Head of COGITO Laboratory (COmputer
GeometrIc modelling and simulaTiOn) part of the UNINA DII – Fraunhofer
IWU Joint Lab IDEAS ‘Interactive DEsign and Simulation’.

Ferdinando Vitolo holds a Post-Doc. in Industrial Engineering at the University

of Naples Federico II. His major research interests are focused on mechanical
design, methodologies for advanced CAD modelling, system engineering and
knowledge based engineering, mechatronic systems and object oriented
programming. He received his Master’s in Mechanical Engineering in 2012 and
PhD in Industrial Engineering from University of Naples Federico II in 2017.
 An approach and an illustrative case study for a hybrid development 267

This paper is a revised and expanded version of a paper entitled ‘A new agile
hybridisation approach and a set of related guidelines for mechatronic product
development’ presented at IFIP WG 5.1 17th International Conference on
Product Lifecycle, Rapperswil, Switzerland, 5–8 July 2020.

1 Introduction

The new era of Industry 4.0 requires us to use various information technologies in order
to fulfil the goal towards automation and smart factories. In order to reach that goal,
industries demand new approaches for more efficient product development, especially for
the mechatronic products as they can be backbones of internet of things (IoT) and
cyber-physical systems (CPS). A common goal of Industry 4.0 steers everyone towards
the most effective interactions of the machine, internet and human for creating a better
environment for production, notably in a context of market uncertainty, increasing
product complexity and frequently changing requirements. The traditional approach,
which provides rigidity to the product development based on sequential processes,
usually in a top-down framework and with a fixed team structure (Beaumont et al., 2017),
is no longer sufficient to respond to the current context. Thus, the need for more flexible
product development methods leads industries towards agile approaches. The research
issue is then how to improve mechatronic systems development in such a context,
because this is a prerequisite for enabling complex systems of systems engineering with
standardised interfaces and cooperation enhancement (Hehenberger and Bradley, 2016).
Our research approach is to propose hybrid approaches to efficiently develop
mechatronic systems by combining agile and traditional product development methods.
Extensive literature research and semi-structured interview method has allowed
extracting the information on agile methods, their use in the development of
mechatronics product development and their crucial aspects for adoption in mechatronic
systems development as well as their use in a hybrid approach. This research helps to
break down the steps during mechatronic product development and to assign the agile
approach to some relevant phases. Finally, in order to provide flexibility in product
architecture and modules design, a first hybridisation of the V-model with scrum is
presented with illustrative case study.
Industry 4.0 arises from the increased complexity of products, the market
customisation, the drive towards digitisation, the ubiquitous internet and the global
competition to produce a better product in less time, while improving the human
interaction with the production facility. This term was coined in Germany in 2011 to
revolutionise production systems with the help of internet, rapid prototyping techniques,
artificial intelligence and cloud computing (Erboz, 2017). Other reasons to focus on
Industry 4.0 were to improve the communication between machines and humans. The
fascination for this aspect aims at reducing human errors, maximising the efficiency of
the machines with human skills in problem-solving and strategic decision making
(Gorecky et al., 2014).
Finally, two crucial elements of Industry 4.0 are the IoT and CPS.
268 S. Mule et al.

1.1 Internet of things

IoT deals with the development of various technologies such as sensors, internet, radio
frequency identification (RFID) technique, and computers in order to realise dynamic
interactions between machine to machine and human to machine (Li and Lau, 2017).
Transparent sharing of information while providing security and using one common
language are the important issues of IoT which need to be addressed (Patel and Patel,
2016).

1.2 Cyber-physical systems

Lee (2008) defines CPS as the “integration of computation and physical processes.
Embedded computers and networks monitor and control the physical processes, usually
with feedback loops where physical processes affect computations and vice versa”. A
similar definition is given by Monostori (2018): “cyber-physical systems (CPS) are
systems of collaborating computational entities which are in intensive connection with
the surrounding physical world and its on-going processes, providing and using, at the
same time, data-accessing and data-processing services available on the internet”. This
system uses mechatronic systems to automate the production facilities using a network
will help reduce human error (Bricogne et al., 2016) and support the concept of a smart
factory with full automation (Bassi, 2017). Modelling of this complex system requires a
communication across various disciplines and a more flexible development method in
order to reduce uncertainty and improve the integration of hardware and software in the
development process (Hehenberger et al., 2016; Bricogne et al., 2016).

2 State-of-the-art

In order to provide a hybrid framework comprised of different product development

methods, it is essential to study specific methods and their important aspects while
fulfilling the derived requirements mentioned in Section 3.1. This chapter describes the
traditional as well as agile methods. It also explains the criticalities in mechatronic
product development which will be used for deriving requirements for creating a hybrid
approach for multidisciplinary product development.

2.1 Traditional product development methods

Traditional product development methods provide sequential, plan-driven and organised
approach and are well suited for the product development when requirements are fixed.
Traditional product development methods also affect project management activities such
as strict scheduling, fixed budget allocation, documentation and tracking (Chan and
Thong, 2009). Here are two of the most common traditional product development
methods.

2.1.1 Stage-gate method and waterfall

The Stage-gate method, also known as a waterfall method (referred to in the IT sector)
has a linear structure with definite stages. Each stage requires inputs from the previous
 An approach and an illustrative case study for a hybrid development 269

stage. Over the past two decades, the waterfall method has been criticised for being too
rigid. While for software product development, the incremental output is essential to
know the unforeseeable problems which arise during the development process, the
waterfall model fails to provide this incremental output over time (Agarwal et al., 2014;
Ajmal and Ali, 2016; Beaumont et al., 2017).

2.1.2 V-model
V-model was encouraged to be used in mechatronic product development. The difference
between the V-model used for software product development and V-model for
mechatronic is the function breakdown for development purpose and again integrating it
in the testing phase (Feldmüller, 2018). This difference is due to the multiple domains in
the mechatronic system. Though it is known for its plan-driven approach, it contains
iterations for refining the results (Feldmüller, 2018). An example of the V-model is
shown in Figure 1.

Figure 1 V-model

Unlike an agile approach where product requirements are not entirely fixed, in a
traditional approach, detailed requirements are given by customers in advance before
planning the project. This approach is linear and process-oriented with exceptional long
iterations. Organisational structure is also hierarchical: centralised authority steers the
project by keeping control to most of the activities. Communication is usually formal,
and should go through appropriate channels while keeping authorities informed. Formal
statements are crucial while transferring the knowledge, which makes knowledge transfer
process too bureaucratic. Also, reporting of work progress to the only manager and not to
the whole team creates misunderstanding within the team about work. Another difference
is that the traditional approach is mainly document-based (Gausemeier et al., 2011;
Bianchi et al., 2018).

2.2 Limits of traditional product development methods

Though traditional product development methods have served the industries well in the
last few decades, they failed to fulfil an essential requirement: to limit uncertainty and to
270 S. Mule et al.

provide flexibility during product development (Beaumont et al., 2017). Few

disadvantages of the traditional approach are, not suitable for breakthrough innovation,
governance of the project cannot be changed over a long period, change in requirements
cannot be adapted, tangible product can only be seen at the end, the consideration for
uncertainty is null or very low, no measure of performance is available in the middle of
the process, cost and time for each stage is not definable, the feedback from testing can
be generated only at the end (Barringer and Gresock, 2008; Hehenberger et al., 2010;
Yadav, 2012; Kannan et al., 2014; Beaumont et al., 2017; Zheng et al., 2017).

2.3 Agile methods

Based on the values of agility such as individuals and interactions over processes and
tools, working software over comprehensive documentation, customer collaboration over
contract negotiation and responding to change over following a plan (Beck et al., 2001),
software industries have successfully developed products in a flexible manner. Customer
integration within the product development process and iterative development cycles are
the backbones of the agile methods. Some of the agile methods are as follows:

2.3.1 Scrum
Flexibility in a development process is a vital characteristic, and the whole team must
work for a shared vision and goal (Mabrouk et al., 2018). A framework of this method is
easy to follow, while providing increments of a product within a short time frame, which
makes it the most popular method among all agile methods (Ghani and Bello, 2015).
Moreover, its features are not just limited to software development (Böhmer et al.,
2017b). Application of scrum for hardware product development starts with changing the
mind-set included in traditional approaches, and instead of keeping complete internal
control over the process and outcome, customer has been involved in each iteration to
define development priorities, provide feedback and eventually propose some
requirements changes. Instead of a hierarchical structure of a team, self-organising team
and transparent organisation need to be provided (Böhmer et al., 2017b). While
implementing scrum for hardware product development, few constraints need to be
considered and worked on such as the definition of the ‘done’ (deliverable),
multidisciplinary team structure and integration of the different developed modules from
different disciplines, or from different teams in case of Scrum of Scrum.
Each iteration cycle in scrum is called sprint. Sprint is an iterative way to provide the
customer with a tangible product within a fixed timeframe. This timeframe is usually one
month. The daily meeting is a part of a sprint. During this meeting, the team discusses the
work done since the last daily meeting and the work needs to be done until the next daily
meeting in a concise manner. During the sprint execution, the team develops the product
as per the sprint backlog (set of sprint requirements), and scrum master guides them if
there is any problem. Scrum master is more like a mentor of the development team. After
the sprint is done, an increment of potentially shippable product is ready. It is a tangible
product increment on which feedback can be expressed. In a review phase (named sprint
review), all stakeholders are gathered where everyone gets a deeper understanding of the
increment in the context of other factors such as marketing. During the sprint
retrospective, the feedback obtained during the sprint review is analysed and adapted for
the planning of next sprint (Böhmer et al., 2017a).
 An approach and an illustrative case study for a hybrid development 271

2.3.2 Kanban
Kanban is an agile product development method with no iteration but only increments in
the product. This term has migrated from the logistic application, where it was used to
show the availability of material and keeping the inventory at an optimum level. Kanban
method works on a continuous run of completing the tasks in a to-do list. Kanban has no
specific framework, which makes it ideal to use it in any phase of an innovation process
(Böhmer et al., 2015).
The backbone of this method is its tool, Kanban board. This tool helps the team to
visualise the progress at each phase. It uses cards with tasks written on it, in a column
which describes the status of that task.

2.3.3 Other agile methods

Other agile methods are feature driven development, extreme programming and
Hackathon. Most of these agile methods are not suitable for hardware or mechatronic
product development as these methods are software product oriented (Böhmer et al.,
2015).
Along with this, a direct change from traditional to agile is difficult as the employees
have usually the mind-set developed from traditional approach. For scrum, framework is
easier to understand but sometimes hard to follow due to the lack of self-discipline
(Böhmer et al., 2017b). Issues with individual approaches for mechatronic product
development required hybridisation of these approaches in order to take benefits from
both approaches.

2.4 Hybrid approach

Many academics have researched about hybrid approach along with the creation of a
framework. Mabrouk et al. (2018) described the coupling of the scrum method with a
model-based system engineering (MBSE) method to make it more reliable and flexible. It
is a Scrum method with the addition of three main aspects: black-box analysis, white box
analysis and physical prototype increment. In this framework, the black-box analysis
generates the requirements by exploring all the views of the system related to its
stakeholders, considering all lifecycle phases. This preliminary analysis aims at reducing
further changes in the product backlog, which is an essential point as changes occurred
later in hardware or mechatronics product development are costly. Moreover, in case of
requirements change during the development process, the black box analysis helps to
trace all requirements so that they can be tracked. The white box analysis generates the
partial incremental architecture of the system based on the prioritised set of functions
selected from each sprint backlog. In this analysis, some components are allocated to
those functions to progressively define the system architecture. At the end, those
incorporated components are validated as per the requirements set in the black box
analysis.
The vertical agile approach, proposed Klein and Reinhart (2016) (Klein et al., 2016)
as explained by Feldmüller (2018), is another hybrid approach, based on the hybridisation
of the development of the different branches from mechatronics: mechanics is being
developed with a traditional method, while informatics and electronics are being
simultaneously developed with agile method. Integration of the outcome of each cycle
272 S. Mule et al.

from the agile approach into the traditional one is challenging and requires efforts in
communicating. The outcome of informatics is communicated to the mechanics
development team, in order to get feedback to the next iteration in the cycle. Each cycle
in informatics or electronics develops a particular set of functions which are checked at
the end of the cycle with its integration with the mechanical development. Timeline is set
in order to synchronise all functions of electronics and informatics with mechanics.
Even if existing hybrid approaches have been proposed for mechatronics
development, they do not propose any analysis to provide a customised hybrid approach
depending on the constraints, objectives of the mechatronic product and company
organisation.

2.5 Criticalities in mechatronic system development

In mechatronic systems development, combining constraints, knowledge and more
importantly, teams from more than three different domains is difficult. Technological
advancement in each segment is at a different pace from other segments. There are many
challenges in the field of mechatronic which are categorised into two areas, product
development and organisational. Few authors have described the challenges in
mechatronic which are listed as follows (Boucher and Houlihan, 2008; Torry-Smith et al.,
2013; Bricogne et al., 2016; Böhmer et al., 2017a; Böhmer, 2018).

2.5.1 Product and development process related

Long development duration, product complexity, large number of modules, technological
innovation at a different rate in a different segment, fast pace of innovations in software
and electronics, different element lifecycles, upgrades frequently needed, product
customisation, changes in requirements, ineffective product development process,
challenges of adopting agile, expensive verification of physical prototype, expensive
computational analysis in the design phase, virtual testing affected by the dependency on
design suppliers, one design tool to integrate the design of each element, meeting design
requirements in the final product, unpredictable behaviour of a virtual prototype.

2.5.2 Organisation related

Communication within a multidisciplinary team, synergy of cross-functional teams,
information flow from different departments, difficulty to find experts in the field, failing
to comprehend the effect of design change over all disciplines, lack of knowledge about
all elements of mechatronic, low market penetration, complex teams structure, ownership
of individual segment, complex internal and external stakeholder dependency.
Most of these challenges regarding the complexity of mechatronic products
development affect products, development process and organisational structure. Other
significant challenges deal with prototyping and communication in cross-functional
teams. As a result, a new approach is needed to improve mechatronic products
development, taking into account these critical specificities, in an uncertain, rapid
changing market context.
 An approach and an illustrative case study for a hybrid development 273

2.6 Matrix relating selected methods to criteria

Table 1 summarises chapter 2 and gives an overview on the main criteria for mechatronic
design (which are derived from the criticalities in Section 2.5).
Table 1 Matrix relating selected methods to criteria

The link to the stated criteria which is Criteria

mainly consider by the selected Product and development Organisation
methods is marked with an ‘X’ process related related

Multidisciplinar

(HIL, SIL, MIL)

Communication

Team structure
documentation
Virtual models
Fast iterations

Knowledge
handling
Product
y views
Methods

Traditional product development methods

Stage-gate method and waterfall X X X X
V-model X X X X
Agile methods
Scrum X X X X
Kanban X X X X
Hybrid approach
Scrum plus MBSE X X X X X
Vertical agile approach X X X X

Stage-gate/waterfall lacks on flexibility for breakthrough innovation and changes in

requirements cannot be adapted easily. The bureaucratic and governance of the project
cannot be changed over a long period. The main disadvantage of the V-model is that
changes in requirements cannot be adapted in the middle of the development cycle.
Scrum has the main advantages, which it is useful for any product and can work with
uncertain or volatile requirements. But there are some weaknesses in mastering complex
mechatronic systems with several modelling view. The lack of documentation hinders the
handover or sharing of tasks, where explanation of tasks needs to be written. Kanban is
flexible to adopt change at all time, need no predefined roles or process and have a
transparent workflow, but it is no specific framework for using multidisciplinary
approaches.
As also mentioned in Section 2.4 the existing hybrid approaches focus only minor to
organisational aspects. All these arguments motivate our proposal for a new agile
hybridisation approach.

3 Proposal for an agile hybridisation approach

From the past few decades, the traditional approach was dominant in the mechatronic
industry, but it fulfils very few of the current challenges faced in product development.
Using exclusively traditional product development has advantages but also
274 S. Mule et al.

disadvantages. Agility in mechatronics is beneficial to support continuous integration

within the teams from different domains and reduce the lead time to introduce new
product or updated versions of it (Eklund and Berger, 2017). But, the change could be
overwhelming to transform the organisational culture from traditional to fully agile. As a
result, our proposal is focused on a hybrid approach including more adaptability. All the
criticalities have been studied and taken into consideration while preparing this hybrid
agile framework. Hybrid approach can provide flexibility in designing the product along
with some rigidity when necessary, for example in the phases of product development
where changes could be costly and disrupt the timeline of project.

3.1 Requirements derived from main criteria

The main criteria mentioned in Section 2.5 have been translated into requirements for
building an effective product development method by following the system engineering
based requirements elicitation and architecture design (SE-READ) MBSE methodology
(Mhenni et al., 2014). This methodology includes a black-box analysis with various
views (from an external point of view) that generate all the derived requirements that the
system has to fulfil. It is more described later, as it has also been used in the hybrid
approach. The derived requirements from previous main criteria are as follows (see
Table 2).
Table 2 Requirements and their importance

Requirements Must have/nice to have

Product and development process related
Iterative way to develop product architecture Must have
Multi-disciplinary interfaces Must have
Documentation of product models Must have
Consideration of costs of development and physical prototyping Nice to have
Organisation related
Efficient communication within the development team Must have
Efficient communication with external stakeholders Nice to have
Effective change management Must have
Well-formed cross-functional team Must have

The main requirements on a now hybridisation approach are classified to their relation on
the product and development process and the involved organisation. The method should
be able to handle complex modelling for enabling faster product development. This gives
the possibility to adapt changes in product architecture, module and interfaces at any
point in the product development. It should be suited for documentation of the models
during the virtual prototyping phase.
Efficient communication within the development team is very important and leads to
an improvement in knowledge sharing capabilities between cross-functional departments.
So a single owner of the product has to solve documentation in the product development
management.
An efficient product development method for mechatronic products requires certain
qualities mentioned above. Most important requirements are based on the use of
 An approach and an illustrative case study for a hybrid development 275

iterations which can provide a better quality product. In order to create a cheaper
complex product, a product development approach should consist of a state-of-the-art,
virtual testing technologies and involvement of different stakeholders in it. The proposed
method also demands a well-defined team structure that efficiently supports
communication between internal as well as external stakeholders.

3.2 An illustration of a hybrid approach: V-model with scrum methods

To illustrate the benefits of such agile hybridisation, we present here an example of a way
to hybridise traditional and agile approach for mechatronic products development.
Due to the merits of scrum to prioritise the backlog, iterate the development, with a
full development workflow during each sprint and high compatibility with the
development of product architecture and modules of product, it has been selected for this
first hybrid approach. This hybrid framework consists of Scrum in the first half of the
V-model. The basic idea behind the framework is shown in Figure 2.

Figure 2 Basic idea of a hybrid framework – V model with scrum

This V-model is divided into three phases, product architecture design, module design
and prototyping along with testing. Among which, product development in the first two
phases will be done in iteration using the scrum method. The output of these first two
phases will be carried as an input for the next phase once the review has been done by the
team, as well as customer. Physical prototyping and testing will be done with a traditional
approach as virtual product development has undergone many iterations which would
resolve most of the issues with module design. This way, the cost associated with the
physical prototyping can be reduced, and it also reduces the possibility of any uncertainty
which might arise in the physical prototype building.
This framework is better for projects which are long-term, complex when deciding
the product backlog at once and most importantly, for the projects where test criteria and
technological aspects evolve rapidly. In a sprint for a virtual product, requirements are
finalised for the specific module, which is designed in the sprint with the use of process
flow of V-model and in the end, a virtual prototype is realised. Virtual commissioning
(VC) is introduced for reviewing the outcome. VC is the way of using 3D technology to
simulate the product and its environment and review it. Within one iteration of sprint –
276 S. Mule et al.

physical product development, two or more sprints can be carried out for virtual product
development as the time required to develop a physical and virtual product is different.
This outcome then used as a sprint backlog for the second sprint, which is implemented
here for physical prototype creation.
The detailed framework of V-model with scrum is shown in Figure 3. The
requirement gathering and analysis stage is carried out with a black-box analysis, in order
to build the requirements set by exploring all the views in agreement with the customer
and the various stakeholders (Mhenni et al., 2014). This analysis aims at increasing the
comprehensiveness of the product backlog and limiting late costly changes. It is
performed notably through the identification of the system life cycle, its context and
system-environment interactions. This analysis includes the definition of the external
interfaces, which are introduced as requirements and finally all the views analysed in the
black box analysis help to define the product backlog (Mabrouk et al., 2018). In a
traditional approach, more in-depth analysis is carried out by dealing exhaustively with
all the requirements in order to avoid further changes. In an agile approach, the customers
can change the requirements to be quickly taken into account.

Figure 3 Detailed hybrid framework – V model with scrum

The stage of building a product architecture goes through white-box analysis with the
scrum method. It defines a preliminary architecture of the system, starting by its
functions and then logical and physical modules. At the end, product architecture is
validated regarding the requirements whole set defined during the black box analysis
(Mabrouk et al., 2018), before the design and development of each component during the
following sprints.
Then a series of N scrum sprints can be carried out. For each sprint, some
requirements are prioritised and put in the sprint backlog to develop a particular module
 An approach and an illustrative case study for a hybrid development 277

allocated to a specific function. When enough virtual testing of modules has been
verified, the traditional physical prototyping can then be performed.
Virtual testing has been introduced to test the module design in the second phase of
this framework, as it provides flexibility to test and ask for feedback to customers in less
time and with no investment in a physical prototype. At the beginning of the third phase,
artefacts of this framework are referred from the conventional V-model with few changes
at the physical prototyping, testing and integration phase. The use of rapid prototyping
method is highly recommended as it could provide N physical components coming from
the N designing iterations in short duration without investing into a conventional way to
produce a prototype from suppliers. The most popular rapid prototyping method is the
additive manufacturing which is also known as 3D printing.
In order to test product architecture, virtual design of modules, hardware prototypes
and simulation techniques, from a model-based design approach, are used. Functions of
the product are tested with model-in-loop (MIL) simulation technique and software of the
respective ECU will be later checked by software-in-loop (SIL) simulation technique. In
order to test each module or increment in the absence of the full product,
hardware-in-loop (HIL) simulation technique is used as it can provide test results before
the final assembly and flexibility to iterate the development of that particular module
instantly.
MIL: MIL takes place in the initial stage of the product development where model
and environment are tested without any actual hardware components. This early testing
provides a feedback soon enough to change the architecture without the design of the
system which in turn saves the cost and time. Implementation models are used in MIL as
a substitute for a hardware model which are simulated with different aspects such as
robustness, performance and encapsulation of variety of functional characteristics of the
product (Bringmann and Krämer, 2008). These models are helpful to generate a code
further in the product development process in case the controller does not exist already.
SIL: when the model is verified in MIL, code is generated in SIL and is tested with
the same model from MIL but with the actual code of the controller (Ingalalli et al.,
2016). Virtual environment is being used while testing (Bringmann and Krämer, 2008).
HIL: the code generated and later tested in SIL, has to be tested after its installation in
the ECU, with the simulated external environment ensuring the same communication
protocol as in the real application. This test is carried out in order to receive feedback on
the hardware part of the ECU as it contains different parts and their electrical connections
which need to be tested. Also, some of the parts of the ECU are constructed by suppliers
and needs to undergo the test of complete assembly at a company (Bringmann and
Krämer, 2008).
A benefit of this framework is that, product architecture can be altered even after
building modules also, if asked by a customer in a review at the end of the second or third
phase. This framework has been built to solve the critical problems in mechatronic
product development, yet with the simple use of Scrum, which makes it easy to adopt and
use.

3.3 Analysis of the adequacy of this proposal with respect to the requirements
Requirements described in Section 3.1 for the development of a hybrid approach for
mechatronic systems are cross-verified with the proposal. It has been found that most of
the requirements are fulfilled by the proposed hybrid approach. Analysis of the adequacy
278 S. Mule et al.

of the hybrid approach is explained briefly below. The framework is in compliance with
the following requirements:
• Faster product development: due to the inclusion of virtual testing and rapid
prototyping techniques, development time can be reduced.
• A method should be able to handle complex modelling: iterative approach of
designing product architecture as well as modules (enabling architecture changes)
provides an efficient way to handle complexity.
• A well-defined and iterative way to develop product architecture: the use of scrum in
the first phase to allow modification in product architecture if necessary.
• Focused on the development of each module with iteration: use of scrum in second
phase.
• Possibility to adapt changes in product architecture and module at any point in the
product development: customers are involved at the end of each phase and even after
testing of a physical prototype changes can be done in a product architecture.
• Should minimise the cost of development and of the related physical prototyping: the
use of virtual testing and 3D printing reduces uncertainty in the prototyping phase
and then the associated cost.
• Should follow values of agility: the agility values interpreted in context of hardware
product development explained by Fuchs and Golenhofen (2019) are fulfilled.
Regarding the necessity of documentation, it is an organisation’s decision to define
the requisite list of documents for their use.
• Use of virtual prototyping: possible at the end of the second phase.
• Involving customer in the review process: permitted at the end of each phase, and
after each sprint in the first and second phase.
• Evaluation of product based on the product requirements.
Some requirements are not specifically addressed:
• Efficient communication within the development team.
• Well-formed cross-functional team.
• Improvement in knowledge sharing capabilities between cross-functional
departments.
• Size of the involved team should be between 5 and 9 in one team and efficient team
structure with decision making ability of each member.
• Involving supplier and market research team in the process.
• Suited for product customisation.
• Effective change management.
Most of the essential requirements, such as the method should be flexible to adapt
changes at any point, involving the customer in the development process, and an iterative
method, are fulfilled. This approach will also result in the reduction of the cost and
 An approach and an illustrative case study for a hybrid development 279

duration of the development. Use of rapid prototyping techniques and VC have solved
problems with time and cost and provided practical and easy manoeuvring while iterating
the development cycle. Requirements from the organisational aspect are not completely
fulfilled; they will be taken as a reference for the future development of this hybrid agile
framework. Using traditional product development exclusively has advantages, and
disadvantages explained earlier in this paper. Also, the change could be overwhelming to
transform the organisational culture from traditional to fully agile. Which is why this
thesis is focused on transition in development processes from traditional to hybrid
approach with more agile mindset involved in it.

3.4 Guidelines for the implementation and use of hybrid approach

Before adopting the hybrid approach for the multidisciplinary product development, it is
crucial to mention certain key structure or guidelines an organisation should follow.
Requirements to adopt agility, use agility, requirements or change in current product
development processes and an organisational structure are mentioned in Figure 4. These
requirements are extracted from literature research and interviews.

Figure 4 Guidelines for implementation of a (hybrid) agile approach

The four core values of agility have been found efficient and useful in software industry.
Here, it has been explained how agile values from software industry could be adopted for
multidisciplinary/hardware product development.
• Mechatronic product development requires an effective communication channel
within the involved team that consists of experts from multiple domains. Increasing
complexity within a product requires complex interactions between many experts
and stakeholders (Fuchs and Golenhofen, 2019).
280 S. Mule et al.

• Comprehensive documents which are not necessary while the development of

product should be omitted except documents such as the documentation for the
concept development, technical specification, drawings and interface description
(Fuchs and Golenhofen, 2019).
• Customer involvement at early stage in order to prepare a product architecture,
features and interfaces is beneficial instead of a signing of a contract only and deliver
the product directly (Fuchs and Golenhofen, 2019).
• Adopting changes over following plan provides the assurance of meeting market
requirements more accurately. Customer differentiation is a continuous process till
the end, based on a iterative approach, allowing for the adoption of any changes to
the product throughout the development process (Fuchs and Golenhofen, 2019).
According to a four stage adoption process (Sidky et al., 2007) to confirm the adoption of
agility, an organisation needs to assess its competency. In the pre-assessment phase, the
factors which can resist this change are being identified. Those factors are:
1 no necessity of agility
2 lack of funds to support the adoption process
3 unavailability of executive support.
If these factors are pre-assessed, it will save the organisation’s time, cost and efforts in
adoption
Other guidelines to adopt and use agile method for mechatronic product development
are as follows,
• Specify a ‘done sprint’: unlike software, it is not possible every time to produce a
working prototype in hardware product development. Sometimes working prototype
is achieved only after the final iteration. The organisation must decide what could be
the outcome of each iteration in order to provide an incremental product to the
customer (Cooper and Sommer, 2016).
• Resource allocation: in the hardware product development, procurement, prototyping
and testing activities which are dependent on different teams and stakeholders can
have waiting times. During these waiting periods, a team can neither finish the sprint
which includes prototyping nor go forward with the next sprint without the outcome
of the previous sprint. Cooper and Sommer (2016) have provided a solution for
teams to work on different tasks in the meantime.
• Integrating agile approach in a traditional-model planning: coupling of traditional
agile process with traditional approach can be difficult (Cooper and Sommer, 2016).
Required skillset should be generated within teams throughout the product
development processes to support the agile approach adopted at one particular stage
or all stages.
• Tools of agile methods: it is the responsibility of an organisation to find and practice
the tools which are suitable for them. With conventional methods of tracking the
progress, managing the development is quite complicated and inefficient. For
tracking the progress, new tools should be incorporated within the system, such as
JIRA. JIRA tool helps to track the tasks, to make boards for Scrum and Kanban, to
 An approach and an illustrative case study for a hybrid development 281

provide an effective communication through notification feature, project timeline,

performance check of a team and report handling (Tutorialspoint, 2015).
• A continuous integration system and automation: in order to respond faster to
changes in the software product development, continuous integration of codes into
the server for testing is automated. These practices can be used in mechatronic
product development and system design phases (Johnson, 2012). In this phase of
system design, the work is done daily or weekly and will continuously get updated
on a virtual prototyping platform for quick feedback. This way, a team can save time
by one complete iteration (sprint in case of scrum-based development) as the small
defects, which will be found in a sprint review, will be surfacing while working.
• Unlike software, mechatronic product possesses substantial parts which are hard to
deliver after each iteration. Some authors have provided an alternative to hardware
prototype: the virtual prototyping. With the help of virtual prototyping, time and cost
associated with incremental prototypes will be reduced (Johnson, 2012).
• Few organisational guidelines are as follows: competence management, virtual
enterprise, knowledge-driven organisation, reconfiguration capability,
responsiveness, innovativeness, good decision making and leadership (Kettunen,
2009).
Table 3 Estimation of fitness of an organisation based on points system

Requirements Must have/nice to have Points

For adoption of agile/hybrid approach
Four agile values from software to hardware/mechatronics Must have 2
Four stage adoption process Must have 2
For using the agile/hybrid approach
Definition of ‘done sprint’ Must have 2
Resource allocation Nice to have 1
Integrating agile approach in a traditional-model planning Must have 2
Tools Nice to have 1
In product development processes
Continuous integration system and automation Must have 2
VC for prototyping Must have 2
Improvement in management or task tracking tools Nice to have 1
In organisational structure
Competence management Nice to have 1
Reconfiguration capability Must have 2
Virtual enterprise Nice to have 1
Customer integration Must have 2
Knowledge driven Must have 2
Responsiveness, innovativeness, good decision making and Nice to have 1
leadership
282 S. Mule et al.

These are the most important requirements to adopt and use in a hybrid agile approach. In
order to change the organisational culture from traditional approach to agile approach or
hybrid approach, organisation must focus on the steps of change management which can
be a topic for future work in this area.
Table 3 describes the essential requirements that an organisation must fulfil along
with the requirements that are nice to fulfil but do not restrain an organisation from
adopting a hybrid approach. Points are assigned to each requirement to calculate the
eligibility of an organisation to adopt a hybrid approach for product development.
In order to adopt a hybrid approach, the organisation needs to earn enough points
before. Figure 5 shows that the organisation’s confidence to achieve requirements
mentioned in Table 3 provides the signal to adopt the hybrid approach successfully. If the
points are in between 12–18, an organisation should assess its competences and tries to
improve it in order to be ready for smooth implementation of a hybrid approach in its
product development. As mentioned in the table above, 9 out of 15 (18 points)
requirements have to be fulfilled in order to adopt hybrid approach.

Figure 5 Effect of organisational competences on decision of adopting hybrid approach

(see online version for colours)

3.5 Criteria for evaluation of framework

Any method treated without scepticism brings issues and reduce efficiency. Continuous
improvement is critical to improve the organisational culture and gain a competitive
advantage in the market. Not only is the adoption of the product development but also the
criteria to inspect the success of its important.
Assessment wheel shown in Figure 6 is an essential tool to assess the success of a
product development method, whether it is an agile product development method or a
hybrid. Criteria are mentioned in the figure and classified in four categories:
transparency, performance, method related and leadership. The assessment wheel can
also be used to compare the assessment of each sprint and move with continuous
improvement, see, e.g., sprint 1 (blue line) to sprint 2 (red line) in Figure 6.
 An approach and an illustrative case study for a hybrid development 283

Figure 6 Assessment wheel-performance evaluation of product development method (see online

version for colours)

4 Case study

The hybrid approach (V-cycle/scrum) presented in the Section 3.2 is followed for the
case study design. This case study explains the important processes from this framework
to understand the hybrid framework by design and development of a power tool: impact
wrench (IW).

4.1 Black box analysis

The first step of the product architecture design using Scrum is to gather requirements
and analyse them carefully to limit the changes in future. In case of impact wrench
development, requirements are gathered from customers by product owner in order to be
analysed. The main purpose of the development of the IW is to build a better quality
power tool for operation related to construction. Afterwards, customers have provided
requirements that are in line with the main purpose of the product. These requirements
are created and analysed a per the lifecycle of the IW, its use, the operations on which
construction site will be fulfilled with this tool and the users which will operate this tool.
These requirements can be defined as follows:
• impact wrench with high torque capacity
• compact size
• weight should not exceed 2 kg
• tracking device needed
• long battery
• minimum vibration and noise level.
284 S. Mule et al.

These requirements have been analysed and external interfaces such as elements and
communication within those elements have been defined. Requirements for each element
that will be beneficial for the creation of the product architecture of the IW have been
generated. This process is an initial part of the product architecture design (first part of
the hybrid approach) within the first sprint. As these requirements have been analysed
rigorously, they will be subjected to less changes in future, however if changes appear
later, they could be incorporated within the product architecture in next iteration without
any difficulty.

4.2 System definition and simulation (white box analysis, MIL)

Requirements defined at the beginning, with the help of the black box analysis, are used
for the generation of the product architecture of the IW.
Mapping of functions consists of requirements, related functions, components and
departments involved for the development. This map provides a complete architecture
which is essential for the creation of product backlog which later will be used for
planning and execution. This function map is useful for transferring the concept; a
general representation of it is shown in Figure 7, which is inspired by METUS Raute
(Göpfert, 2009).

Figure 7 Metus raute (see online version for colours)

Source: Göpfert (2009)

For this product, components are derived or selected as per the requirements and a
satisfy-traceability map is created as per the relations between requirements and
components. The relations between the different IW components and the electronic
elements are simulated using MIL and the final product architecture is formed as shown
in the Figure 8. White box analysis helps to assign and validate IW elements to the
functions and requirements defined in the black box analysis. This product architecture
was shown to the customers and feedbacks were gathered, in order to immediately be
implemented in the next sprints.
 An approach and an illustrative case study for a hybrid development 285

Figure 8 Product architecture of the developed impact wrench (see online version for colours)

4.3 Virtual testing of modules (SIL)

During the module design phase using scrum, for each sprint (2 to N) one module from
the product architecture is selected. In this case of the impact wrench, the first selected
module deals with the development of the complete electric circuit assembly with the
passive HF-RFID tag. Functional behaviour of the IW mechanical unit available from the
simulation in the previous phase has been used for a SIL test of the programming of the
electronic module. Problems revealed by the virtual testing in this sprint will be solved in
the next sprint.
286 S. Mule et al.

4.4 Testing of module (HIL)

After this sprint, prototyping of the IW mechanical unit was done. This complete
mechanical unit was integrated with the electric circuit (developed in the previous sprint)
in order to be tested. During the test, hardware components were tested along with the
physical controller installed with the programming codes tested in SIL. Compatibility of
the electronic circuit was checked with the hardware components in HIL. However, to
satisfy the requirements related to the vibration and noise, respective tests have been
carried out on the complete assembly.
This academic case study have provided a better illustration to understand the
proposed hybrid approach, as along this case study design, tools and roles for each step
have been are also well grasped and efficiently implemented.

5 Discussion and conclusions

V-model has proven to be an efficient method in both software and mechatronic industry.
Even though a product can be developed in iteration with V-model, it was limited and
needed a full development cycle to be completed before the next iteration. The proposed
hybrid approach of the V-model with scrum for developing the product architecture and
each module has provided freedom of iterating specific phases within one cycle of the
V-model. In parallel, the proposed approach underlines the use of a rapid prototyping
technique and virtual testing to improve the efficiency of the product development
method. The proposed hybrid method tackles the most critical current design issues, such
as the need of iterations within a traditional method, the need of time and cost reduction
of the development process and the need to continuously adapt the product to changing
customer requirements through iterations.
Regarding the requirements presented in Section 3.1 the category ‘must have’
(iterative way to develop product architecture, multi-disciplinary interfaces,
documentation of product models, efficient communication within the development team,
effective change management, well-formed cross-functional team) is focussed by the
hybrid approach and also fulfilled.
Along with this hybrid approach, essential guidelines for implementing and using the
hybrid agile approach are discussed. Four values of agility have guided the software
product development throughout these years. Now, their adaption for mechatronic
product development will be beneficial to provide agility for mechatronic product
development. Remaining guidelines have stated the importance of the ‘definition of
done’, resources, tools, the coupling of the two approaches and finally the virtual
prototyping.
With the use of these guidelines and the proposed hybrid approach, better quality
product is expected with less development time and cost, and most importantly,
complying with the current market needs. Further developments to the present work will
deal with the application of the proposed approach to a set of industrial use-cases, in
order to validate the actual results of the research. Moreover, presented results will be
applied in a pedagogical context for the design of a mechatronic system, modular robot.
 An approach and an illustrative case study for a hybrid development 287

References
Agarwal, A., Garg, N.K. and Jain, A. (2014) ‘Quality assurance for product development using
Agile’, ICROIT 2014 – Proceedings of the 2014 International Conference on Reliability,
Optimization and Information Technology, pp.44–47, DOI: 10.1109/ICROIT.2014.6798281.
Ajmal, S. and Ali, S. (2016) ‘Agile-waterfall hybrid model for software development processes’,
Science International, Vol. 28, No. 6, pp.5165–5170.
Barringer, B.B. and Gresock, A.R. (2008) ‘Formalizing the front-end of the entrepreneurial process
using the stage-gate model as a guide: an opportunity to improve entrepreneurship education
and practice’, Journal of Small Business and Enterprise Development, Vol. 15, No. 2,
pp.289–303, DOI: 10.1108/14626000810871682.
Bassi, L. (2017) ‘Industry 4.0: hope, hype or revolution?’, in 2017 IEEE 3rd International Forum
on Research and Technologies for Society and Industry (RTSI), Modena, pp.1–6, DOI:
10.1109/RTSI.2017.8065927.
Beaumont, M. et al. (2017) ‘Using agile approaches for breakthrough product innovation’, Strategy
and Leadership, Vol. 45, No. 6, pp.19–25, DOI: 10.1108/SL-08-2017-0076.
Beck, K. et al. (2001) ‘Manifesto for agile software development’, Agile Alliance [online]
http://agilemanifesto.org/ (accessed 20 May 2019).
Bianchi, M., Marzi, G. and Guerini, M. (2018) ‘Agile, stage-gate and their combination: exploring
how they relate to performance in software development’, Journal of Business Research,
pp.1–16, Elsevier, DOI: 10.1016/j.jbusres.2018.05.003.
Böhmer, A., Beckmann, A. and Lindemann, U. (2015) ‘Open innovation ecosystem – makerspaces
within an agile innovation process’, in ISPIM Innovation Summit, Brisbane, pp.1–11.
Böhmer, A.I. (2018) When Digital Meets Physical – Agile Innovation of Mechatronic Systems, PhD
dissertation, Faculty of Mechanical Engineering, Technische Universität München, Munich,
Germany [online] https://mediatum.ub.tum.de/doc/1430507/1430507.pdf (accessed June
2021).
Böhmer, A.I. et al. (2017a) ‘Towards agile development of physical products’, 23rd International
ICE Conference on Engineering, Technology and Innovation, Vol. 17, pp.78–85, DOI: 978-1-
5386-0774-9/17.
Böhmer, A.I., Hugger, P. and Lindemann, U. (2017b) ‘Scrum within hardware development
insights of the application of scrum for the development of a passive exoskeleton’, in 2017
International Conference on Engineering, Technology and Innovation (ICE/ITMC),
pp.790–798, DOI: 10.1109/ICE.2017.8279965.
Boucher, M. and Houlihan, D. (2008) System Design: New Product Development for Mechatronics,
Aberdeen Group [online] https://www.aberdeen.com (accessed June 2021).
Bricogne, M., Duigou, J. and Eynard, B. (2016) ‘Design processes of mechatronic systems’, in
Mechatronic Futures: Challenges and Solutions for Mechatronic Systems and their Designers,
pp.75–90, Springer, Cham, DOI: 10.1007/978-3-319-32156-1_1.
Bringmann, E. and Krämer, A. (2008) ‘Model-based testing of automotive systems’, in 2008
International Conference on Software Testing, Verification, and Validation, pp.485–493, DOI:
10.1109/ICST.2008.45.
Chan, F.K.Y. and Thong, J.Y.L. (2009) ‘Acceptance of agile methodologies: a critical review and
conceptual framework’, Decision Support Systems, Vol. 46, No. 4, pp.803–814, Elsevier B.V.,
DOI: 10.1016/j.dss.2008.11.009.
Cooper, R.G. and Sommer, A.F. (2016) ‘The agile-stage-gate hybrid model: a promising new
approach and a new research opportunity’, Journal of Product Innovation Management,
Vol. 33, No. 5, pp.513–526, DOI: 10.1111/jpim.12314.
Eklund, U. and Berger, C. (2017) ‘Scaling agile development in mechatronic organizations – a
comparative case study’, in Proceedings – IEEE/ACM 39th International Conference on
Software Engineering: Software Engineering in Practice Track, IEEE Press, Buenos Aires,
Argentina, pp.173–182, DOI: 10.1109/ICSE-SEIP.2017.25.
288 S. Mule et al.

Erboz, G. (2017) ‘How to define Industry 4.0: main pillars of Industry 4.0.’, in 7th International
Conference on Management (ICoM 2017), Nitra, Slovakia.
Feldmüller, D. (2018) ‘Usage of agile practices in mechatronics system design potentials,
challenges and actual surveys’, in Proceedings of the 2018 19th International Conference on
Research and Education in Mechatronics, REM 2018, pp.30–35, DOI: 10.1109/
REM.2018.8421803.
Fuchs, C. and Golenhofen, F.J. (2019) ‘Agile for mechatronics and hardware’, in Mastering
Disruption and Innovation in Product Management, Springer, Cham, pp.147–164, DOI:
10.1007/978-3-319-93512-6.
Gausemeier, J. et al. (2011) ‘Integrative development of product and production system for
mechatronic products’, Robotics and Computer-Integrated Manufacturing, Vol. 27, No. 4,
pp.772–778, Elsevier, DOI: 10.1016/j.rcim.2011.02.005.
Ghani, I. and Bello, M. (2015) ‘Agile adoption in organizations’, KSII Transactions on Internet and
Information Systems, Vol. 9, No. 8, pp.3231–3248, DOI: 10.1201/b13085-13.
Göpfert, J. (2009) Modulare Produktentwicklung: Zur gemeinsamen Gestaltung von Technik und
Organisation, Books on Demand Gmbh, Norderstedt.
Gorecky, D. et al. (2014) ‘Human-machine-interaction in the Industry 4.0 era’, in 2014 12th IEEE
International Conference on Industrial Informatics (INDIN), Porto Alegre, pp.289–294, DOI:
10.1109/INDIN.2014.6945523.
Hehenberger, P. and Bradley, D. (2016) Mechatronic Futures – Challenges and Solutions for
Future Mechatronic Systems and Designers, Springer London, Berlin Heidelberg, ISBN: 978-
3-319-32154-7
Hehenberger, P. et al. (2010) ‘Hierarchical design models in the mechatronic product development
process of synchronous machines’, Mechatronics, Vol. 20, No. 8, pp.864–875, Elsevier Ltd.,
DOI: 10.1016/j.mechatronics.2010.04.003.
Hehenberger, P., Howard, T.J. and Torry-Smith, J. (2016) ‘From mechatronic systems to
cyber-physical systems: demands for a new design methodology?’, in Mechatronic Futures:
Challenges and Solutions for Mechatronic Systems and Their Designers, pp.147–163,
Springer, Cham, DOI: 10.1007/978-3-319-32156-1_1.
Ingalalli, A., Satheesh, H. and Kande, M. (2016) ‘Platform for hardware in loop simulation’, in
International Symposium on Power Electronics, Electrical Drives, Automation and Motion,
IEEE, pp.41–46.
Johnson, N. (2012) ‘Agile hardware development – nonsense or necessity ?’, in DESIGN
West 2012, San Jose, California, pp.1–7 [online] https://www.eetimes.com/
document.asp?doc_id=1279137 (accessed June 2021).
Kannan, V., Jhajharia, S. and Verma, S. (2014) ‘Agile vs. waterfall : a comparative analysis’,
International Journal of Science, Engineering and Technology Research (IJSETR), Vol. 3,
No. 10, pp.2680–2686.
Kettunen, P. (2009) ‘Adopting key lessons from agile manufacturing to agile software product
development – a comparative study’, Technovation, Vol. 29, Nos. 6–7, pp.408–422, DOI:
10.1016/j.technovation.2008.10.003.
Klein, T.P. and Reinhart, G. (2016) ‘Towards agile engineering of mechatronic systems in
machinery and plant construction’, in Procedia CIRP, Vol. l, No. pp.68–73, https://doi.org/
10.1016/j.procir.2016.07.077.
Klein, T.P., Drescher, B. and Reinhart, G. (2016) ‘Agile engineering in mechatronic education:
interdisciplinary development of a mechatronic system using scrum’, in 17th International
Conference on Research and Education in Mechatronics, REM 2016, pp.20–25,
https://doi.org/10.1109/MECATRONICS.2016.7547109.
Lee, E.A. (2008) ‘Cyber physical systems: design challenges’, in 11th IEEE international
Conference Object Oriented Real-Time Distributed Computing, ISORC, pp.363–369.
 An approach and an illustrative case study for a hybrid development 289

Li, C.H. and Lau, H.K. (2017) ‘A critical review of product safety in Industry 4.0 applications’, in
2017 IEEE International Conference on Industrial Engineering and Engineering Management
(IEEM), Singapore, pp.1661–1665, DOI: 10.1109/IEEM.2017.8290175.
Mabrouk, A. et al. (2018) ‘Integration of agility in a MBSE methodology for multidisciplinary
systems design’, in 4th IEEE International Symposium on Systems Engineering, ISSE
2018 – Proceedings, IEEE, pp.1–5, DOI: 10.1109/SysEng.2018.8544425.
Mhenni, F. et al. (2014) ‘A SysML-based methodology for mechatronic systems architectural
design’, Advanced Engineering Informatics, Vol. 28, No. 3, pp.218–231, DOI: 10.1016/
j.aei.2014.03.006, Elsevier Ltd.
Monostori, L. (2018) ‘Cyber-physical systems’, in CIRP Encyclopedia of Production Engineering,
Springer London, Berlin Heidelberg, https://doi.org/10.1007/978-3-642-35950-7_16790-1.
Patel, K.K. and Patel, S.M. (2016) ‘Internet of things-IOT: definition, characteristics, architecture,
enabling technologies, application & future challenges’, International Journal of Engineering
Science and Computing, Vol. 6, No. 5, pp.6122–6131, DOI: 10.4010/2016.1482.
Sidky, A., Arthur, J. and Bohner, S. (2007) ‘A disciplined approach to adopting agile practices: the
agile adoption framework’, Innovations in Systems and Software Engineering, Vol. 3, No. 3,
pp.203–216, DOI: 10.1007/s11334-007-0026-z.
Torry-Smith, J.M. et al. (2013) ‘Challenges in designing mechatronic systems’, Journal of
Mechanical Design, Vol. 135, No. 1, pp.1–11, DOI: 10.1115/1.4007929.
Tutorialspoint (2015) JIRA Tutorials Point – Simply Easy Learning [online]
https://www.tutorialspoint.com/jira/index.htm (accessed 1 March 2021).
Yadav, R.S. (2012) ‘Improvement in the V-model’, International Journal of Scientific and
Engineering Research, Vol. 3, No. 2, pp.2229–5518.
Zheng, C. et al. (2017) ‘Multidisciplinary design methodology for mechatronic systems based on
interface model’, Research in Engineering Design, Vol. 28, No. 3, pp.333–356, DOI:
10.1007/s00163-016-0243-2.

Abbreviations
Abbreviation Full word
IoT Internet of things
CPS Cyber-physical system
RFID Radio frequency identification
MBSE Model-based system engineering
MIL Model-in-loop
SIL Software-in-loop
HIL Hardware-in-loop