2016 42th Euromicro Conference on Software Engineering and Advanced Applications
Modeling IoT Applications with SysML4IoT
Bruno Costa, Paulo F. Pires, Flvia C. Delicato
Instituto de Matemtica - IM / Programa de Ps-Graduao em Informtica - PPGI
Universidade Federal do Rio de Janeiro
Rio de Janeiro, Brazil
{brunocosta.dsn, paulo.f.pires, fdelicato}@gmail.com
Abstract The Internet of Things (IoT) is a paradigm that
refers to the ubiquitous presence around us of physical objects
equipped with sensing, networking and processing capabilities
that allow them to cooperate with each other and with their
environment to reach common goals. General objectives of IoT
are improving the quality of human life and optimizing industrial
processes, by automating tasks that humans must perform. Such
benefits are obtained by developing IoT applications. The
heterogeneity and interdisciplinary present in the development of
any IoT application classifies such a task as a Systems
Engineering problem. However, to the best of our knowledge, no
Systems Engineering approach to develop IoT applications has
been proposed so far. The objective of this paper is to introduce a
Model-Based Systems Engineering methodology for IoT
application development, focusing on the design phase, which
aims at helping organizations to develop IoT applications to fully
achieve the benefits of this new paradigm. The approach is
comprised of a method and a tool, which are aligned with proven
concepts from Systems Engineering and Software Architecture
literature.
Keywords internet of things, application, systems engineering
I. INTRODUCTION
The Internet of Things (IoT) is a novel paradigm that refers
to the ubiquitous presence around us of physical objects
equipped with sensing, networking and processing capabilities
that allow them to cooperate with each other and with their
environment to reach common goals [1]. It is expected that
such new paradigm will affect the daily life of people in many
aspects, having a significant impact on the economy. Gartner
estimates that the IoT will produce close to $2 trillion of
economic gain globally with 25 billion Internet-connected
objects by 2020 [2]. General objectives of IoT are to improve
the quality of human life and optimize industrial processes, by
automating tasks that humans must perform. It results in
several benefits, such as enhancing the comfort and security of
homes/offices, getting better and more timely healthcare, or
optimizing the energy consumption [1, 3]. Such benefits are
obtained by developing IoT applications. Despite the
considerable interest from the industry and academia, there is
no consensus about the definition of IoT application. Based on
the definition of application as introduced by ISO/IEC/IEEE
24765 standard [4] we adopt the definition of IoT application
as
a collection of automated procedures and data, integrated
with heterogeneous entities (hardware, software, and
personnel) that interact with each other and with their
environment to reach common goals.
2376-9505/16 $31.00 2016 IEEE
DOI 10.1109/SEAA.2016.19
As with traditional software development, when developing
IoT applications, stakeholders have to address issues that
concern to different life cycles phases, including design,
development, deployment, and maintenance. However, the IoT
characteristics pose a broad range of related challenges to each
phase [5]. In this paper, we focus on the design phase by
tackling the following challenges when specifying the system
model: (i) the heterogeneity of hardware devices and software
components; (ii) the lack of mechanisms to address multiple
stakeholders concerns; and, (iii) lack of a method to design
IoT applications. In the following, we detail these challenges.
Heterogeneity of hardware devices and software
components. An IoT application involves interactions among a
large number of heterogeneous software components and
hardware devices, exchanging information between them, and
interacting with their physical surroundings to reach common
goals. Such heterogeneity makes complex the task of
specifying a system model that represents precisely and in a
high-level of abstraction different hardware and software
entities, with their internal interconnections and information
flows. It also poses difficulties in reusing model elements by
other IoT applications and stakeholders. Furthermore, the
heterogeneity may hamper the communication between
different stakeholders that are working on the system model.
Lack of mechanisms to address multiple stakeholders
concerns. IoT application development is a multi-disciplined
endeavor with concerns coming from various stakeholders [6].
Similar to traditional software development, IoT application
development involves domain specialists, requirements
engineers, application engineers, and deployment managers;
however, it requires special skills of them related to the IoT
domain. Moreover, IoT application development incorporates a
new type of stakeholder: the device expert, who understands
the components and protocols of devices. The second challenge
regards the lack of characterization of such stakeholders, their
skills and responsibilities, and mechanisms to address their
specific concerns into the system model.
Lack of a method to design IoT applications. The
aforementioned challenges (heterogeneity of entities and
multiple stakeholders) classify the IoT application development
as a Systems Engineering problem. Systems Engineering (SE)
is a multidisciplinary and holistic approach used to develop
solutions for complex problems comprising hardware,
software, data, and personnel [7]. As a mature discipline, SE is
widely accepted within several industries [8] however, to the
best of our knowledge, there is no method specifically tailored
to design IoT applications.
157
 In order to address the abovementioned challenges, we
propose a Model-Based Systems Engineering methodology
called IDeA IoT DevProcess & AppFramework. The goals of
IDeA are as follows: (i) to furnish high-level abstractions
through meta-modeling to address the heterogeneity of
software components and hardware devices in the system
model; (ii) to provide mechanisms for multi-disciplined IoT
application design by using views and viewpoints in order to
deal with different stakeholders involved in the process; and,
(iii) to conceive a method from existing standards with
activities considered as most relevant to IoT application design.
Our proposal is evaluated trough a case study.
The remainder of this paper is organized as follows:
Section II presents a case study used to evaluate IDeA. Section
III presents the IDeA methodology, followed by the evaluation
case study in Section IV. We briefly discuss related work in
Section V and final remarks in Section VI, by pointing other
aspects that are currently being investigated.
II. CASE STUDY: SMART BUILDING IOT APPLICATION
We consider a hypothetical scenario where a company
wants to make the offices more comfortable for its employees
while reducing the energy consumption in its building system,
which consists of several buildings, each one with one or more
floors, each floor with several rooms. To achieve these
business goals, the stakeholders want to create an IoT
application that automatically configures the lighting and
temperature levels inside the rooms according to the employee
preferences. To reduce the energy waste, when a room is
empty, the devices should be automatically turned off. The
buildings have already some devices that may be used in the
IoT application: a swipe card identifies the users with a reader
located at the building entrance and in each room, and the
rooms are equipped with light and heater devices and sensors.
The design of an IoT application to address the business
goals required by the described scenario has the following
challenges. First, the heterogeneity of entities, such as different
devices and sensors. It is necessary to specify a system model
that identifies precisely the composing components, their
interconnections and information flows while promoting the
reuse of elements. The second challenge regards multiple
stakeholders involved in the process, such as device experts
and domain specialists. The third challenge is related to how
high-level business requirements should be mapped to the IoT
application. This is not as straightforward as it appears at first,
because the IoT domain is inherently interdisciplinary,
encompassing technological, human-centered, among other
issues. Therefore, there is a need for a new systematic process
specifically tailored for the IoT domain. In the following, we
present our proposed MBSE methodology aiming at tackling
these challenges.
III. IDEA: A MODEL-BASED SYSTEM ENGINEERING
METHODOLOGY TO DESIGN IOT APPLICATIONS
The following definitions from Holt and Perry [9] and
Martin [10] are used to contextualize our proposal. Model-
Based Systems Engineering (MBSE) is an approach where the
system model is the primary artefact of the application
development. The system model contains elements that can be
158
presented on diagrams with a specific graphical notation. Such
model elements enable the system to be viewed from different
viewpoints that focus on various aspects of the system while
maintaining consistency among the different views. A
Methodology can be defined as a collection of related process
(a logical sequence of tasks performed to achieve a particular
objective defines WHAT), methods (techniques, practices
and procedures for performing a task, and artifacts that are
produced defines HOW), and tools (supporting or enhance
the accomplishment of the process and methods). Regarding
Systems Engineering Standards, the ISO/IEC/IEEE 15288 [11]
is a quite mature process standard [9], and Object-Oriented
Systems Engineering Method (OOSEM) [8] is a method
standard that uses SysML to support the analysis, specification,
design, verification, and validation of complex systems.
SysML [12] is the standard general-purpose graphical
modeling language for Systems Engineering field [9].
IDeA (Figure 1) is a Model-Based Systems Engineering
methodology based well-established standards. It is composed
of a method, called IoT DevProcess and a supporting tool,
called IoT AppFramework. The IoT DevProcess is an extension
of OOSEM specially tailored for IoT application design. It was
conceived to be applied in the context of the technical process
of ISO/IEC/IEEE 15288. To support the activities of IoT
DevProcess, the IoT AppFramework provides a SysML profile
for IoT applications called SysML4IoT, which is founded on
well-defined IoT concepts. Furthermore, the tool is aligned
with proven techniques from Systems Engineering and
Software Engineering literature, such as Model Libraries [8]
and Viewpoints [13].
Figure 1 IDeA Methodology
The IDeA Methodology contributes to the state-of-the-art
of MBSE (i) by providing a profile to precisely specify
heterogeneous entities that compose an IoT application; (ii) by
identifying stakeholders involved in the application lifecycle
and related viewpoints, which are formally specified; and, (iii)
by defining a method to conceive IoT application system
model aligned with a mature MBSE approach. In the next
Subsections, we detail each contribution in light of the
challenges to design the IoT Application System Model for
the Smart Building IoT application presented in Section II.
A. (Challenge 1) Heterogeneity of hardware devices and
software components: SysML4IoT
IDeA furnishes high-level abstractions to address the
heterogeneity of hardware devices and software components in
the system model through a SysML profile named SysML4IoT.
As demonstrated by [9], the use of profiles aids stakeholders to
deal with the system complexity, increases the understanding
and communicates the system model in an unambiguous (or as
unambiguous-as-possible) manner. Furthermore, profiles
promote reuse and interoperability between software
components and systems [8].
SysML4IoT provides abstractions to specify precisely
different types of hardware devices, software services, data
flows, and personnel. The profile is strongly based on a
reference model for IoT, the IoT Domain Model (Figure 2),
introduced by a European research project, called IoT-A [14],
which aims at standardizing the IoT domain as a reference
model. In the following, we briefly describe the model
concepts, the complete explanation about the IoT Domain
Model can be found in [15].
Figure 2 IoT-A Domain Model [15]
In a generic IoT application domain, a Human User (e.g.
employee, customer) or a Digital Artifact (e.g. application,
software agent) needs to interact with a Physical Entity an
identifiable part of the physical environment that is of interest
to the application stakeholders (e.g. car, electronic appliance).
Virtual Entities are virtual representations of the physical
entities. A physical entity can be a Device (technical artefacts,
such as Arduino or Raspberry Pi), an Actuator (that changes
the state of a physical entity, such as switch on/off), a Tag (that
identifies a physical entity, such as RFID), or a Sensor (that
provides information, knowledge, or data about the physical
entity they monitor, such as temperature sensor). The
interaction between digital artifacts and physical entities is
mediated by a software Service, which exposes Resources
(software components that provide data from or are used in the
actuation on physical entities). On-Device Resources are hosted
on devices (e.g. embedded software) while Network Resources
are available somewhere in the Network (e.g. cloud-based
databases). The concept of Augmented Entity constitutes the
thing of the Internet of Things in the IoT Domain Model.
159
As a meta-model, the IoT ARM Domain Model does not
determine the notation to represent IoT applications by using
its concepts and does not establish any method to generate IoT
application system models. To the best of our knowledge, no
concrete syntax has been proposed for IoT ARM Domain
Model so far. To tackle this issue, we conceive the SysML4IoT
as a SysML profile, providing stereotypes to design IoT
applications based on the IoT Domain Model. Furthermore,
SysML4IoT is also aligned with ISO/IEC/IEEE 15288 standard,
aiming to enhance system models with Systems Engineering
concepts.
Figure 3 details important stereotypes defined in the
SysML4IoT profile. Block and Stakeholder are SysML
elements. System, System-of-Interest and Enabling System are
reused from in ISO/IEC/IEEE 15288 standard. Other elements
come from the IoT Domain Model.
Figure 3 SysML4IoT profile (partial)
In SysML4IoT, a System is a composition of Devices and
Services interacting with other Systems, Physical Entities, and
Users. A System-of-Interest is a system whose life cycle is
under consideration in the application context; in turn, an
Enabling System supports a system-of-interest during its life
cycle stages but does not necessarily contribute directly to its
objective during operation. A Service has four attributes: the
serviceType, which specifies the technology used to invoke it
(such as REST [16]); in and out, defining data types for input
parameters and output results; and, the serviceArea, to specify
the area that is affected by the service. A Resource has six
parameters: the resourceID, which is a string of characters used
to uniquely identify it, defined as a URI (Universal Resource
Identifier); the name of the resource; latitude and longitude to
define its geographical location; the parameter hostedOn refers
to the device, tag, sensor, or actuator that act as its execution
environment; and, resourceType, which specifies the type of
the resource (device, tag, sensor, or actuator). In SysML4IoT,
SysML Block is the principal extended element, since SysML
conceptualizes it as a modular unit of the system that is used to
define a type of software, hardware, data elements of the
system or a composition of them.
B. (Challenge 2) Lack of mechanisms to address multiple and the set of services available to access their resources. The
stakeholders concerns: IoT Application Viewpoints view (e.g. Figure 6) is presented through SysML Block
IoT application development is a multi-disciplined process Definition Diagram (BDD) to represent the devices, services,
where concerns from multiple stakeholders may intersect or and resources; and Internal Block Diagram (IBD), to specify
conflict [5]. An important task is the characterization of the internal configurations and information flows. The IoT Device
stakeholders involved in the IoT application life cycle. Table 1 Expert is the stakeholder that creates Virtual Entity views.
describes our envisioned stakeholders, their skills and 2) Functional Viewpoint
responsibilities. The Functional Viewpoint addresses concerns related to the
functional responsibilities of the systems components, their
Table 1 Stakeholders in IoT application development internal and external interfaces (ports and connectors) and
Stakeholder Skills Responsibilities internal structure. The Functional View (e.g. Figure 8 and
Device Deep understanding of the Specify, Figure 9) is presented through SysML Block Definition Diag
Expert protocols of the individual implement, and
devices, concepts of the IoT publish devices
ram (BDD), to represent the IoT application composition; and
Domain Model, and SysML. services. Internal Block Diagram (IBD), to specify internal
Understanding of the Define configurations and information flows. The IoT Application
Domain
Specialist application domain and application Engineer is the stakeholder that creates Functional views.
concepts of the IoT Domain requirements and
Model. the app. scope. 3) Information Viewpoint
IoT Deep understanding about Elicit the IoT is a paradigm that essentially focuses on exchanging
Requirements Requirements Engineering, application and information across heterogeneous entities. A formal
Engineer concepts of IoT Domain device specification of information structures that flows across
Model, and SysML. requirements components and devices is decisive for the success of an IoT
IoT Deep understanding about application. The Information Viewpoint addresses such concern
Specify the
Application Systems Engineering,
structure of an
by defining the data formats, structures and protocols that are
Engineer concepts of IoT Domain used by the application components when exchanging
IoT application
Model, and SysML. information. The Information View (e.g. Figure 7) is presented
IoT Deep understanding of the through SysML Block Definition Diagram (BDD) with
Deployment platforms and target area packages representing the various data structures and formats.
Application
Manager where the application will be
deployment. The IoT Application Engineer and the IoT Device Expert are
deployed, concepts of IoT
Domain Model, and UML. the stakeholders that create Information views.
4) Operational Viewpoint
Each stakeholder has particular concerns about the IoT The Operational Viewpoint addresses concerns related to
application that shall be addressed in the system model. A the behavior of the application at runtime. It allocates activities
proven technique to achieve this aim is Views & Viewpoints that realize systems requirements into components. The
[13]. A view is a representation comprised of one or more Operational View is presented through SysML Activity
architectural elements to address a set of design concerns from Diagram. The IoT Application Engineer is the stakeholder that
a specific viewpoint; a viewpoint is a specification of elements creates Operational views.
and conventions available for constructing and using a view.
Figure 4 depicts our proposed viewpoints specification 5) Deployment Viewpoint
followed by the description of each one. The examples of the The Deployment Viewpoint addresses concerns related to
views are introduced in Section VI. the environment into which the system will be deployed. The
objective is to specify the allocation of the system components
on computational nodes. It also specifies hardware constraints
and network communication protocols between nodes. The
Deployment View is presented through UML Deployment
Diagram. The IoT Deployment Manager is the stakeholder that
creates Deployment views.
C. Reuse of system model elements
To promote reusability of model elements, we propose the
use of IoT Model Libraries. A model library is a kind of
SysML package that is intended to contain reusable model
elements [8] for a given domain. In IDeA, the IoT Model
Library contains model elements, such as devices or resources,
which can be reused by stakeholders when modeling IoT
Figure 4 IoT Application Viewpoints Specification applications. The model elements that compose the IoT Model
Library are created during the life cycle of a particular IoT
1) Virtual Entity Viewpoint application, when the stakeholders create the application views.
The Virtual Entity Viewpoint addresses concerns related to Alternatively, a stakeholder can create model elements outside
virtual entities. Virtual Entity Views shall specify the devices of the IoT application life cycle, providing means for reuse.

160
D. IoT AppFramework
The IoT Application Viewpoints, SysML4IoT, and the
support to create reusable model elements with the IoT Model
Library have been implemented in the IoT AppFramework.
The tool is a plugin for the MBSE environment No Magic
Cameo Systems Modeler [17]. The plugin is available at
http://ubicomp.nce.ufrj.br/idea.
E. (Challenge 3) Lack of a method to design IoT applications:
IoT DevProcess
We address the third challenge by the IoT DevProcess
(Figure 5). Initially we performed a quasi-systematic literature
review, based on the protocol as proposed by Dyba and
Kitchenhan [18], to search for MBSE processes and methods
for IoT application development. As an outcome, we could not
find any MBSE approach specific for IoT application domain.
Thereby, we analyzed well-stablish standards and selected the
ISO/IEC/IEEE 15288 and OOSEM to generate a method with a
subset of activities and artifacts from them specifically tailored
for IoT application development.
Figure 5 IoT DevProcess
The ISO/IEC/IEEE 15288 establishes a process framework
for describing the entire lifecycle of a complex system. It
includes agreement process (e.g. acquisition, supply),
enterprise process (e.g. investment management, resource
management), project process (e.g. planning, risk
management), and technical processes. OOSEM can be applied
over ISO/IEC/IEEE 15288 technical process as a method to
perform its activities, as demonstrated by [19].
The IoT DevProcess is an extension of the OOSEM method
specifically tailored for the IoT domain. It comprises: (i) the
allocation of activities to predefined stakeholders; (ii)
modifications on existing activities and artefacts; and, (iii) the
inclusion of new activities and artefacts (gray elements in the
SysML Activity Diagram of Figure 5). White elements are
classical OOSEM activities.
We hide activities conducted by the Domain Specialist and
IoT Deployment Manager stakeholders since they are not the
core of IoT DevProcess to generate the system model. The
161
activities of the Domain Specialist are performed in the context
of the activity Analyze Stakeholders Needs interacting with
the Requirement Manager. In turn, the IoT Deployment
Manager conducts his/her activities after the design of the
requirements, structure and behavior of the IoT application.
In the next section, we describe the activities of the IoT
DevProcess in the context of the Smart Building scenario
(Section II). The objective is to demonstrate the effectiveness
of IDeA methodology to generate the system model.
IV. EVALUATION CASE STUDY: SMART BUILDING IOT
APPLICATION SYSTEM MODEL DESIGN
A. Evaluation Scope
The goal of this section is to describe how well the
proposed methodology addresses the challenges introduced
earlier. To evaluate our approach, the IDeA methodology will
be applied to create the IoT Application System Model for the
Smart Building IoT application presented in Section II. The
focus of the modelling will be on the adjustment of temperature
and lighting levels according to the employees preferences, as
well as on the electricity usage monitoring. For lacking of
space, the models are presented in a high-level of abstraction,
not considering technical details of devices and services. Also,
we do not describe classical OOSEM activities (white action in
the SysML Activity Diagram of Figure 5). There is substantial
material in the literature that describes the execution of these
activities (primarily [8]). Finally, we focus on the Virtual
Entity View, Information View, and Functional View of the
system, which specify the structure of the IoT application.
Nevertheless, a complete description about the Smart Building
IoT application can be found at http://ubicomp.nce.ufrj.br/idea.
B. Analyze System Requirements
In this activity, the IoT Requirements Engineer specifies the
requirements for the IoT application as a black box. Device
Requirements are also specified, defining which type of
devices are needed to the application with their required
features, such as specific data formats and protocols. The
application and device requirements are modeled using SysML
Requirement Diagrams and Requirement Tables.
C. Model Virtual Entities
Once knowing the device requirements, Device Expert
stakeholders specify the devices, services and resources that
will compose the application. Each device expert is responsible
for modeling the structure and internal configurations of the
device he/she is acquainted with, composing the Virtual Entity
View. The structure of the devices, services and resources
follows the IoT Domain Model (introduced in Section III.A
and formally defined in [15]). Figure 6 depicts the Virtual
Entity View of the Smart Building IoT application.
The devices (temperature, heater, light, card, and
electricity) are composed of sensors and actuators. They host
resources exposed by services. Such services are specifications
of SysML Ports, which represent access points of a device.
They will be used by the IoT Application Engineer when
creating the Functional View IBD (Figure 9). The flow
properties specify the port direction (in or out) and the data
type that flows through the port (such data type is defined in
the Information view - Figure 7).
Both TempService_Room and LightService_Room have an
input port by which the desired temperature and lighting levels
are set and output ports by which the actual level of
temperature and lighting are requested. To set or request the
temperature and lighting levels, the services exposes the
resources, such as ActualTempResource (referencing the
Temperature Sensor) and HeaterResource (referencing the
Heater device). The internal configuration and interactions of
the Temperature, Heater, and Light Devices with their sensors
and actuators are modeled in the respective IBD (for example
Temperature Device IBD not shown due to space
limitations). In turn, CardService_Room and Electricity
Service are access points of their respective devices with only
output ports by which their resources (referencing to the
respective sensors) are requested.
Figure 6 Smart Building Virtual Entity View
Device Experts also create the Information View (Figure 7),
which determines the data format exposed by the services. In
the Smart Building IoT application, the information view
specifies only one type of data structure (EEML [20]) used to
interact with the devices services. However, it is possible to
specify more data types to be used in the devices, exposing
resources with different data structures. Alternatively, the IoT
Application Engineer can also specify data formats in the
Information view and request to the Device Experts to use it
when defining the devices services.
Figure 7 Smart Building Information View
162
D. Define Logical Architecture
After the specification of devices and services for the Smart
Building application, the IoT Application Engineer
decomposes the system into functional components that
interact with each other to satisfy the system requirements. The
first step is to create the Functional View. In such view, the
BDD describes the high-level structure of the IoT application
(Figure 8) and the IBD presents the interactions between
systems components and information flows (Figure 9).
Figure 8 Smart Building Functional View BDD
Figure 9 Smart Building Functional View IBD
The Smart Building Functional View IBD specifies that the
Smart Building application is composed of a set of devices
(which were specified by device experts in the Virtual Entity
View), a Controller, and a Repository. The application interacts
with the building environment and employees swipe cards.
The Controller is a service that acts as a central component
interacting with the devices through its services. The repository
is a database containing the employees preferences of
temperature and lighting levels.
The Smart Building Functional View IBD specifies that
when an employee enters a room and uses his/her swipe card in
the Card Device, his/her identification is sent to the controller
through a port typed as CardService_Room. The controller
requests the employees profile to the database and invokes the
temperature and lighting services to adjust the levels according
to the employees preferences. Such devices interact with the
building to monitor/adjust the temperature and light levels. The
electricity device monitors the energy usage in the building
sending this information to the Controller. It is worth to
highlight that the Controller interacts with the devices through
SysML Ports typed as the services specified by the Device
Expert in the Virtual Entity view
E. Qualitative Analysis
In the following, we analyze the use of IDeA to generate the
system model in contrast to generating it by using only SysML
(without the SysML4IoT profile and IoT Application
Viewpoints) and classical OOSEM (without the extended
activities).
1) Addressing the heterogeneity of hardware devices and
software components
The Smart Building application requires different hardware
entities, such as temperature sensors, heaters, lighting sensors,
and card devices. Each device has specific resources exposed
by software services that exchange information between them
in order to realize the IoT application requirements. By using
only SysML, both hardware devices and software components
would be modeled through generic elements, such as Blocks.
Such approach may produce an ambiguous model, once the
IoT application has elements with similar meaning (such as
device and sensor or on-device resource and services).
Furthermore, without a precise characterization of the elements
that compose the system, the communication between
stakeholders may be negatively affected.
The main objective of a system model is to aid stakeholders
to identify components, increasing the understanding of the
system and enhancing the communication [9]. Through
SysML4IoT, all hardware devices and software components are
precisely identified in the system model by using stereotypes. It
also promotes the communication between stakeholders, once
there is a common knowledge source that identifies the model
elements: the IoT Domain Model. Furthermore, by precisely
identifying the elements with the stereotypes, it is also possible
to create Model Libraries composed of specific elements, such
as device model libraries or service model libraries, promoting
reusability of model elements.
2) Addresings the lack of mechanisms to address multiple
stakeholders concerns
By using SysML, it is possible to conceive the system
model as a composition of views based on viewpoints.
However, it is necessary to identify stakeholders and their
concerns to specify these viewpoints. Such identification and
viewpoint specification may increase the time and development
costs. Furthermore, if this activity is not properly performed,
the views may not address the stakeholders concerns correctly.
The IDeA methodology provides the characterization of the
different stakeholders involved in the IoT application life cycle,
identifies their concerns and provide viewpoint specifications
that are used to generate stakeholders views.
3) Addressing the lack of a method to design IoT
applications
The OOSEM is a general-purpose MBSE method used to
design systems in any domain. By using it in the IoT
application design, we identified four issues: (i) it does not
provide specific activities related to IoT domain, such as
Model Virtual Entities; (ii) it does not prescribe activities or
artefacts regarding the reuse of IoT model elements; (iii) it
does not determine the stakeholders that are responsible to
perform the activities; and, (iv) the method is not based on the
concepts of views and viewpoints, a crucial feature of IoT
163
application development, once it is a multi-disciplined
endeavor with concerns coming from various stakeholders.
Other works have already stated that OOSEM may be
enhanced to accommodate domain specific activities (such as
[19] for submarine design). The IoT DevProcess is an
extension of such method specifically tailored for IoT domain.
It tackles the abovementioned issues by providing activities to
design IoT application system models. Moreover, it defines the
stakeholders that are responsible to perform the activities and
their generated views, besides establishing the reuse of model
elements through model libraries.
V. LIMITATIONS
We now turn to a brief discussion of the current limitations
of our methodology. First, it is required from the stakeholders a
deep understanding about the IoT-A Domain Model to
correctly specify the system model. Such reference model is
quite recent and requires significant effort to be understood as a
whole, having few concrete examples of its use. However, the
quality of any modelling activity depends on the skills of the
domain analyst and modeling IoT systems is no exception.
Furthermore, the proposed approach needs to be evaluated
through more comprehensive assessment tools. For instance, it
is important to run controlled experiments to assess the
modelling overhead of the approach in a real system
development scenario. Another aspect that must be further
analyzed is how general the modelling elements are when they
are applied in different IoT application projects. However, the
characteristics we chose for the PoC scenario (heterogeneity,
multiple stakeholders, etc.) are the ones that the literature
points out as the most common for the IoT domain.
Furthermore, we extend a mature systems engineering process,
the OOSEM, which has been used by several projects.
VI. RELATED WORK
In this section, we briefly present some model-driven
approaches for developing IoT application proposed in the
literature. It is possible to notice that none solution is based on
Systems Engineering emergent standards or Software
Architecture proven techniques, such as Views & Viewpoints.
Regarding specific methodologies to develop IoT
applications, the most similar work was proposed by Patel and
Cassou [5]. The authors present a model-driven development
framework that addresses the lack of division of roles and the
heterogeneity of devices in different life cycle phases. To
achieve such goals, they identify the stakeholders and propose
domain specific languages that provide abstractions to specify
different types of devices. The framework takes into account
development, deployment, and maintenance phases. Similar,
we also propose the identification of stakeholders roles and
mechanisms to deal with the heterogeneity of devices in the
IoT application design. However, our work provides a
methodology that can be used in conjunction to ISO/IEC/IEEE
15288, which already identifies and formalizes all activities of
an IoT application development endeavor, such as
management, enterprise, project specific activities. Moreover,
since our proposal is based on SysML, IDeA can be seamlessly
integrated into existing SysML-based projects.
 In the context of pervasive computing, Serra et al. [21]
propose a domain-specific language based on UML, called
PervML, to describe pervasive systems in a technology
independent way. The main purpose of PervML is to address
the heterogeneity in the applications. Another proposal is the
DiaSuite [22], which is a development environment dedicated
to pervasive IoT application design, which relies on a domain-
specific language that allows the specification of the
applications. The stakeholders model entities in a high-level
manner to abstract the heterogeneity. The main feature that
distinguishes IDeA from those approaches is its alignment to
well-established standards. The SysML4IoT profile is based on
SysML and its meta-model is founded on both the
ISO/IEC/IEEE 15288 and the IoT-A Domain Model. Such an
alignment improves the overall comprehension of the system
elements and promotes the easy integration of IDeA with other
development approaches based of the same standards.
Regarding Web Sensor Network (WSN) approaches,
Bischoff and Kortuem [23] introduce an engineering method
called RuleCaster. The programming model logically divides
the network into spatial regions; then, the RuleCaster compiler
receives the application containing rules and the network
model describing the spatial regions. Finally, they are mapped
to devices. In turn, Taniro et al. [24] propose a model-driven
architecture framework to develop WSN applications helping
stakeholders to model functional and non-functional
requirements. The framework increases the abstraction level
and enables the automatic code generation. It also allows the
separation of different development stakeholders concerns. In
our work, sensors are modeled according to the IoT Domain
Model. Furthermore, the IDeA methodology is based on the
concept of Views and Viewpoints to separate the stakeholders
concerns. Both the IoT Domain Model and the concept of
Viewpoints are mature and well-stablished in the literature.
VII. CONCLUSIONS AND FUTURE WORK
In this paper, we presented a Model-Based Systems
Engineering methodology called IDeA, composed of the IoT
DevProcess (method) and the IoT AppFramework (tool). IDeA
provides solutions for three challenges of the current design of
IoT applications: (i) the heterogeneity of hardware devices and
software components; (ii) the lack of mechanisms to address
multiple stakeholders concerns; and, (iii) the lack of a method
to design IoT applications. As demonstrated by the case study,
the methodology can be used in the context of the
ISO/IEC/IEEE 15288 technical process to generate IoT
application system models, helping multiple stakeholders to
identify components and understand the system. Our current
and future works involve improving the methodology by
supporting other phases of the development life cycle. Another
important aspect we are planning to carry on is the systematic
evaluation of IDeA through controlled experiments.
ACKNOWLEDGMENT
This work was partially supported by Brazilian Funding
Agencies FAPERJ (under grant E_06/2015E_06/2015 for
Flavia C. Delicato) and CNPq (under grants 200757/2015-6
and 307378/2014-4 for Flavia C. Delicato, 310958/2015-6,
457783/2014, and 200758/2015-2 for Paulo F. Pires).
164
REFERENCES
[1] A. Whitmore, A. Agarwal, and L. Da Xu, The Internet of ThingsA
survey of topics and trends, Inf. Syst. Front., vol. 17, no. 2, pp. 261
274, Mar. 2015.
[2] Gartner, Gartner Says 4.9 Billion Connected Things Will Be in Use in
2015. [Online]. Available: http://goo.gl/bgWqwB. [Accessed: 07-Dec-
2015].
[3] L. Atzori, A. Iera, and G. Morabito, The Internet of Things: A survey,
Comput. Networks, vol. 54, no. 15, pp. 27872805, Oct. 2010.
[4] ISO/IEC/IEEE, Systems and software engineering -- Vocabulary. pp.
1418, 2010.
[5] P. Patel and D. Cassou, Enabling High-level Application Development
for the Internet of Things, J. Syst. Softw., vol. 103, pp. 6284, Jan.
2015.
[6] P. Patel, B. Morin, and S. Chaudhary, A model-driven development
framework for developing sense-compute-control applications, in
Proceedings of the 1st Int. Workshop on Modern Software Engineering
Methods for Industrial Automation - MoSEMInA 2014, 2014, pp. 5261.
[7] A. Kossiakoff, W. N. Sweet, S. Seymour, and S. M. Biemer, Systems
Engineering Principles and Practice, 2nd ed. 2011.
[8] S. Friedenthal, A. Moore, and R. Steiner, A Practical Guide to SysML:
The Systems Modeling Language. 2014.
[9] J. Holt and S. Perry, SysML for Systems Engineering. 2nd Edition: A
Model-Based Approach. 2013.
[10] J. N. Martin, Systems Engineering Guidebook: A Process for Developing
Systems and Products, vol. 14. CRC Press, 1996.
[11] ISO/IEC/IEEE, ISO/IEC/IEEE 15288:2015 - Systems and software
engineering - System life cycle processes, 2015.
[12] SysML 1.4 - Beta. [Online]. Available: http://goo.gl/l8IQ5P.
[Accessed: 14-Dec-2015].
[13] ISO/IEC/IEEE, ISO/IEC/IEEE 42010:2011 - Systems and software
engineering -- Architecture description, 2011.
[14] IOT-A: Internet of Things Architecture. [Online]. Available:
http://www.iot-a.eu/public. [Accessed: 20-Feb-2016].
[15] A. Bassi, M. Bauer, M. Fiedler, T. Kramp, R. van Kranenburg, S. Lange,
and S. Meissner, Eds., Enabling things to talk: Designing IoT solutions
with the IoT Architectural Reference Model. Berlin, Heidelberg:
Springer Berlin Heidelberg, 2013.
[16] B. Costa, P. F. Pires, F. C. Delicato, and P. Merson, Evaluating REST
architecturesApproach, tooling and guidelines, J. Syst. Softw., vol.
112, pp. 156180, Oct. 2015.
[17] Cameo Systems Modeler [Online]. Available:
http://mbse.nomagic.com/. [Accessed: 10-Dec-2015].
[18] T. Dyba, B. A. Kitchenham, and M. Jorgensen, Evidence-based
software engineering for practitioners, IEEE Softw., vol. 22, no. 1, pp.
5865, Jan. 2005.
[19] P. Pearce and M. Hause, ISO-15288, OOSEM and Model-Based
Submarine Design, in Systems Engineering and Test and Evaluation /
6th Asia Pacific Conference on Systems Engineering, 2012.
[20] Extended Environments Markup Language: EEML. [Online].
Available: http://www.eeml.org/. [Accessed: 20-Nov-2015].
[21] E. Serral, P. Valderas, and V. Pelechano, Towards the Model Driven
Development of context-aware pervasive systems, Pervasive Mob.
Comput., vol. 6, no. 2, pp. 254280, Apr. 2010.
[22] B. Bertran, J. Bruneau, D. Cassou, N. Loriant, E. Balland, and C.
Consel, DiaSuite: A tool suite to develop Sense/Compute/Control
applications, Sci. Comput. Program., vol. 79, pp. 3951, Jan. 2014.
[23] U. Bischoff and G. Kortuem, Rulecaster: A programming system for
wireless sensor networks, Smart Sens. Context, 2006.
[24] T. Rodrigues, F. C. Delicato, T. Batista, P. F. Pires, and L. Pirmez, An
approach based on the domain perspective to develop WSAN
applications, Softw. Syst. Model., Sep. 2015.