=Paper=
{{Paper
|id=Vol-1728/paper10
|storemode=property
|title=An Iterative and Recursive Model-Based System of Systems Engineering (MBSoSE) approach for Product Development in the medical device domain
|pdfUrl=https://ceur-ws.org/Vol-1728/paper10.pdf
|volume=Vol-1728
|authors=Pierfelice Ciancia
|dblpUrl=https://dblp.org/rec/conf/ciise/Ciancia16
}}
==An Iterative and Recursive Model-Based System of Systems Engineering (MBSoSE) approach for Product Development in the medical device domain==
https://ceur-ws.org/Vol-1728/paper10.pdf
An iterative and recursive Model-based System of
Systems Engineering (MBSoSE) approach for
Product Development in the medical device domain
Ciancia, Pierfelice
Systems Engineering consultant
at FRIKART Engineering GmbH
Bern, Switzerland
pierfelice@frikart.ch
www.frikart.ch
Copyright © held by the authors.
Abstract—In this paper, an iterative and recursive method for from different MBSE methodologies have been considered
the application of a System of Systems (SoS) view to medical during the definition.
Product Development will be presented. Using a top-down
approach, the method starts with the definition of business According to the International Council on Systems
processes and leads to the definition of single systems Engineering (INCOSE) definition, a System of Systems
architectures which satisfy requirements on a System of Systems (SoS) is itself a System whose elements are further systems
level. A modeling technique based on the use of Business Process [10]. Applying MBSE to a SoS means to build up a model
Model and Notation (BPMN) and System Modeling Language which covers multiple levels of abstraction. The top level is
(SysML) will support the requirements engineer and the system the SoS level, where the scope and the main business
architect during their design activities and all stakeholders to processes are defined. On a system level, single systems
share information along the entire lifecycle. In conclusion, an inherit SoS interfaces requirements and high level
example of application in the medical device domain will be functionalities allocation. On a system element level, system
presented. requirements are allocated to single elements. The SoS
hierarchy used in this paper, according to the INCOSE
Keywords—Product Development; System of Systems (SoS); definition, is shown in Figure 1.
Systems Engineering; MBSE; iteration; recursion; top-down;
business processes; BPMN; SysML; medical devices; healthcare System of Systems
System System
I. INTRODUCTION
The added value of using Model-based Systems System element
Engineering (MBSE) techniques along the entire lifecycle of
Figure 1 – Hierarchy within a System of Systems
complex systems has been already discussed in many works
([1] [2] [3] [4] [5]). Some MBSE methodologies have been The level of detail for information at each level of
evaluated in an interesting work where differences between abstraction can be adjusted to the organization(s) needs. A
different approaches have been clearly shown [6]. A top- SoS is characterized by systems that are managerially and/or
down analysis is common in some of those methodologies, operationally independent. Usually, different development
but not all of them place emphasis on development of teams work on their definition.
business processes or link those processes in a clear and
defined way to further development steps. IBM Telelogic It is possible to describe a complex environment made of
Harmony-SE [7] is a good V-model based approach where systems interconnected between them, in the same
the model/requirements repository directly support the organization portfolio, as a SoS. Potentially, once that a
different SE processes. It uses a “service request-driven” framework has been defined, systems (made of one or more
modeling approach. INCOSE OOSEM [8] is a valid top- products) can be added or removed from the SoS. Risk
down approach where stakeholder needs are analyzed and
analysis (especially in the medical device domain) and
the main SE processes are covered following an iterative
approach. Vitech’s MBSE methodology [9] is based on a change management play a fundamental role every time a
“Onion model” which leads the development of a system on system is added or removed. Different system versions can
different level of abstractions with different level of details. be considered as different systems, if they coexist in the
The approach presented in this paper has been defined while same SoS view. The boundary of a system or a SoS is fixed
setting up the Product Development activities for a System by the organization itself with the help of a systems
of Systems in the medical device domain. Inputs coming engineer.
Copyright © 2016 da Pierfelice Ciancia. Permesso concesso a AISE di pubblicare e utilizzare.
The approach presented in this paper is based on Examples of business processes in the healthcare industry are
recursion applied to a “single system” top-down approach interactions between patients and healthcare professionals
which starts with the definition of high level business (e.g. MDs). Other processes existing in many different
requirements and goes on with the system functional analysis industries are maintenance, logistics, manufacturing,
to the definition of a system architecture. The main steps of customer care, sales, etc. In Figure 3, an example of model-
this single system approach are shown in Figure 2. based business process description is shown.
Figure 2 - Main steps of an iterative top-down approach for single systems
This approach can be applied to different domains and Figure 3 - Example of model-based businesses process description
represents a systematic way to define requirements and to While describing business processes, the involved
evaluate the effect of their changes on different levels of stakeholders only focus on “what” needs to be done and not
abstraction. The philosophy behind aims to use one model on “how”. A good technique to model business processes is
as a central source of information for all stakeholders. One to define activities performed using the SOI in a way that
of the scope of this paper is to show how business analysts single use cases can be directly derived from them.
and systems developers can work together to deal with
challenges coming from an always more complex world. B. System functional analysis
Once that some business processes are already defined, a
In Chapter 2, a detailed description of those steps is list of use cases can be traced towards them (example on
given. In Chapter 3, the same approach is extended to a Figure 4). Using the defined business process as input, a
System of Systems. In Chapter 4, an example of application systematic approach for the definition of a complete list of
in the medical device domain is shown. use cases is guaranteed. A good functional analysis can be
performed by the description of single use cases in a
II. “SINGLE SYSTEM” APPROACH graphical way. Using behavioral diagrams is possible to
The top-down approach presented in this paper is define main functionalities that need to be developed by a
characterized by iteration. Iteration steps and duration are black-box description. A lower level functionalities
tightly organization depending. People from the definition can be performed by a white-box description of
organization should define together the level of iteration. At the use cases, where the main system parts can be defined.
this purpose, methodologies like agile or lean could be
integrated to the approach presented in this paper.
One of the main scopes of this work is to highlight how
close business analysts and system developers should work
while defining scope and requirements of complex systems. Figure 4 - Example of traceability between use cases and business activities
Clarity of information shared between system stakeholders
While performing a white-box analysis, some
is directly dependent on the complexity of a system. The use
functionalities are allocated to system elements. That is a
of a systematic approach and a structured model is a good first step for definition of a system architecture.
starting point to the development of successful systems.
C. System requirements
A. Business Processes In a model-based SE perspective, the main concept is to
Business processes describe interactions and shared have a shared model between stakeholders to collect all
information between actors on a business level. At this level, requirements. Different stakeholders have different needs
stakeholders for the System of Interest (SOI) are defined and and provide different feedback. The system modeler is
requirements are described as activities that need to be usually the one responsible for keeping the model up-to-
carried out to satisfy business requirements. The scope of date. Ideally, everyone should access the model to get the
describing business processes is to focus on what are the real needed information and all changes must be evaluated in
needs and which of those needs shall be satisfied using the terms of impact to other parts of the system.
SOI. Additional requirements (functional and non- In many industries, document-based requirements
functional) can be directly defined in the business processes management is still an important issue. For instance, in the
and they are part of the model. Usually, information medical devices domain documents still play a fundamental
concerning business processes are gathered by interviews to role in regulatory matter. Using a model, it is possible to
the stakeholders and/or by meetings and/or workshops. collect all needed information and to export them as
Copyright © 2016 da Pierfelice Ciancia. Permesso concesso a AISE di pubblicare e utilizzare.
documents in the preferred format. Time saving and information concerning used technologies. Otherwise, this
enhanced change management are only two of the benefits last practice would add constraints to the definition of a
coming from the application of MBSE. system(s) solution.
Some of the use cases derived from the business
D. System architecture processes involve the use of more than one system in the
During system functional analysis, defined SoS. These use cases, which could be called “SoS use
functionalities and, then, non-functional requirements are cases”, should be described to define the interfaces between
already allocated to system elements. Some additional the systems and communication protocols.
requirements come from the development team, where
specialists provide their feedback. A functional architecture Additionally, an allocation of functionalities can be
provides a full description of the system in terms of main performed at this level too. In an early phase, when the SoS
functionalities. Some of these functionalities need a further is not yet completely defined, different alternatives of same
breakdown. Then, a physical architecture is essential for the use cases can be described and evaluated and a tradeoff
definition of the interfaces between system elements and to analysis can be performed. The use cases are traced towards
the external world and for the development of the system. the activities in the business processes. At this level, a white-
box description would be represented by several messages
shared between the systems in the SoS. Further descriptions
III. SYSTEM OF SYSTEMS APPROACH should be postponed and completed on a system level.
The iterative top-down approach described in Chapter 2
The SoS architecture simply includes the systems and
can be extended and used on different level of abstractions.
their interfaces. A tradeoff analysis can help to choose the
A SoS consists of different level of abstractions. At the top
right architecture between different candidates.
level, the “big picture” is defined and it leads the
development of single systems which are located on a lower
level of abstractions. B. System level
On a system level, the first requirements which are
While considering to apply the approach to a SoS, the inherited from the upper level are the interface requirements.
described steps can be used in a recursive way to define a Each system in the SoS needs to satisfy them, to be able to
general SoS architecture and single system architectures. communicate with the other systems and to carry on those
This concept is expressed in a graphical way in Figure 5. activities which are requested by the business processes.
Each system owns its additional stakeholder
requirements and, in some cases, it could even own specific
business requirements. Those requirements can be added to
the model on a system level and shall be satisfied by related
system requirements as well. Some of these stakeholder
requirements could lead to the definition of new use cases
Figure 5 - Main steps of an iterative and recursive top-down approach for a which do not affect the other systems. A system functional
System of Systems (SoS) analysis leads to the definition of functionalities which are
allocated to single system elements and to the creation of a
On a SoS level, the focus is on interactions between functional architecture. A physical architecture including
systems in the SoS, interfaces definition (including interfaces between system elements is the last step at this
communication protocols) and allocation of high level level.
functionalities. Further concepts related to the
communication (e.g. privacy, security, etc.) can be IV. EXAMPLE OF APPLICATION
developed at this level. On a system level, requirements
coming from the upper level are inherited during the single An added value to the described approach comes from
systems analysis, to define system architectures which shall the use of a good organized model, which allows to share
satisfy those requirements. information between the stakeholders in a clear and
systematic way.
A. System of Systems level A model can be adapted to the presented methodology
As a first step, the involved stakeholders define their own by creating the right links between its objects. The example
business processes. The business analyst builds up a business in this chapter concerns a project in the medical device
model. During this phase, business processes can be adapted domain. The involved organization aims to develop
and perfected in agreement with the stakeholder needs. independent systems and to connect them to other existing
Business processes could also include “journeys” or “stories” systems to satisfy new business requirements. Single
while describing operational processes. For instance, independent products of the company portfolio have been
“personas” definitions for therapy processes are common in classified as “single systems” and the overall picture
the medical devices industry. Ideally, the analyst models looking at the interactions between them has been defined as
solution-independent processes, focusing on the information the SoS view. The importance of considering single
shared between the actors and avoiding to give too detailed
Copyright © 2016 da Pierfelice Ciancia. Permesso concesso a AISE di pubblicare e utilizzare.
products as separate systems in the medical device domain
comes mainly because of regulatory reasons. Each system
needs to be developed as a single entity following the right
product classification and regulations. At the same time,
while talking about interconnected and interdependent
devices, a complete technical overview from a high-level
perspective is indispensable.
In this case study, all systems follow business and
marketing requirements which are specific for each of the Figure 7 - System of Systems Architecture
products. Different project managers and development
teams work on their definition in an independent way. Each The systems include insulin pumps, software systems,
of the systems need to be classified and to be compliant with clouds and other medical devices. The interfaces between
different regulatory standards. In some cases, specific the systems are described as communication protocols and
system elements are treated from marketing and regulatory are also included in the model. Complete traceability
perspectives as single products. In this context, the model between interfaces and protocol messages is guaranteed.
The protocols are defined on a SoS level. When new
plays a fundamental role in requirements allocation and
systems are incorporated into the SoS, communication
management and it gives a shared view between the systems
requirements need to be satisfied.
during the development process. Furthermore, the model
structure needs to be compliant with the systems
For each of the systems, a project leader and a
engineering methodology and the internal people development team are involved. Each team independently
organization. Some of the documents needed for regulation, carries out a stakeholder requirements analysis for its own
risk analysis and other topics are printed out directly from project. Specific use cases are defined for the single systems
the model. Figure 6 shows the concept behind the structure and non-functional requirements as well. An example of use
of the model used in this case study. case description is shown in Figure 8. On a lower level, for
req [package] Medical SoS [Traceability model]
each of the systems all functionalities coming from the SoS
Business Analysis use case and from the single stakeholder analyses are
StartEvent1
Activity1 Activity2
EndEvent1
allocated to the system elements.
STR - SoS
+ STR - Functional
+ STR - Non-functional
System of Systems
SoS Use case A SoS Use case B
«requirement»
SoS - Non-functional
Requirement
STR - System 1 STR - System 2
+ STR - Functional + STR - Functional
+ STR - Non-functional + STR - Non-functional
«requirement» «requirement»
System 1 - Non- System 2 - Non-
functional functional
Requirement Requirement
Use case X Use case Y
System 1 System 3 System 2
Figure 8 - Dynamic description of a use case
Figure 6 - Example of dependencies between objects in a model
All the involved systems are described by a system
All links between the objects in the picture are generic model which is linked to the main high-level SoS model.
dependencies and aim to show the traceability paths. A Each team works on its own model having access directly to
complete meta-model has been defined as well, but it is not the shared database. Management and business analyst can
shown in this paper. also have access to the model to work on business
requirements and to access to lower level requirements as
At the top level in the model, the business analysis leads well.
the development of the SoS. The described processes
include therapy processes (interactions between patients and Risk analysis and safety concepts are applicable to
healthcare professionals), which are described starting from different level of abstractions in the model. On a system
the definition of different “personas”. The organization level, medical devices are registered and compliant with
prioritized the description of some processes. Use cases are applicable standards. On a SoS level, the overall privacy,
defined directly from business activities analysis. The ones security and safety concepts are evaluated as well.
involving more than one system are classified as “SoS use
cases” and lead the team to the definition of interface
requirements and communication protocols between some V. CONCLUSIONS
systems. But some high-level functionalities are allocated to An iterative and recursive top-down approach for the
the systems at this level as well. Figure 7 shows the SoS application of a System of Systems view to medical Product
architecture of the case study. Development has been described. The definition of this
Copyright © 2016 da Pierfelice Ciancia. Permesso concesso a AISE di pubblicare e utilizzare.
approach has been carried out together with managers and
developers within an existing Product Development
environment and its use has been extended to other
organizations. To define the approach, different MBSE
methodologies have been evaluated. Inputs coming from
those methodologies have influenced the definition of a new
methodology which better fits the need of the involved
organization. This systematic approach involves business
and systems analysis and leads to the definition of systems
architectures that satisfy given business requirements. The
business analysis is on a SoS level and leads the
development of new services and systems. High-level
functionalities and interface requirements between single
systems are defined. Furthermore, the model is used as input
for risk analysis on both SoS and system levels.
REFERENCES
[1] INCOSE Systems Engineering Vision 2020, Sep 2007
[2] Z9: What is Model Based Systems Engineering, Hazel
Woodcock, Jan 2012
[3] A primer for MBSE – 2nd edition, D. Long, Z.Scott, Oct 2011
[4] Model Based Systems Engineering: Fundamentals and Methods,
P. Micouin, Oct 2014
[5] INCOSE Systems Engineering Vision 2025, Oct 2014
[6] Survey of Model-Based Systems Engineering (MBSE)
Methodologies, J. A. Estefan, JPL California, May 2008
[7] Systems Engineering Best Practices with the Rational Solution
for Systems and Software Engineering, H. Hoffman, IBM, Feb 2011
[8] A Practical Guide to SysML: The Systems Modeling Language,
Friedenthal, Moore, Steiner, 2008
[9] Systems Engineering (SE) 101, Long, James, Vitech Corp, 2000
[10] INCOSE Systems Engineering Handbook – 4th edition
Copyright © 2016 da Pierfelice Ciancia. Permesso concesso a AISE di pubblicare e utilizzare.