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 As with traditional software development, when developing
refers to the ubiquitous presence around us of physical objects IoT applications, stakeholders have to address issues that
equipped with sensing, networking and processing capabilities concern to different life cycles phases, including design,
that allow them to cooperate with each other and with their development, deployment, and maintenance. However, the IoT
environment to reach common goals. General objectives of IoT characteristics pose a broad range of related challenges to each
are improving the quality of human life and optimizing industrial phase [5]. In this paper, we focus on the design phase by
processes, by automating tasks that humans must perform. Such tackling the following challenges when specifying the system
benefits are obtained by developing IoT applications. The
model: (i) the heterogeneity of hardware devices and software
heterogeneity and interdisciplinary present in the development of
any IoT application classifies such a task as a Systems
components; (ii) the lack of mechanisms to address multiple
Engineering problem. However, to the best of our knowledge, no stakeholders concerns; and, (iii) lack of a method to design
Systems Engineering approach to develop IoT applications has IoT applications. In the following, we detail these challenges.
been proposed so far. The objective of this paper is to introduce a Heterogeneity of hardware devices and software
Model-Based Systems Engineering methodology for IoT components. An IoT application involves interactions among a
application development, focusing on the design phase, which large number of heterogeneous software components and
aims at helping organizations to develop IoT applications to fully
hardware devices, exchanging information between them, and
achieve the benefits of this new paradigm. The approach is
comprised of a method and a tool, which are aligned with proven
interacting with their physical surroundings to reach common
concepts from Systems Engineering and Software Architecture goals. Such heterogeneity makes complex the task of
literature. specifying a system model that represents precisely and in a
high-level of abstraction different hardware and software
Keywords internet of things, application, systems engineering entities, with their internal interconnections and information
flows. It also poses difficulties in reusing model elements by
I. INTRODUCTION other IoT applications and stakeholders. Furthermore, the
The Internet of Things (IoT) is a novel paradigm that refers heterogeneity may hamper the communication between
to the ubiquitous presence around us of physical objects different stakeholders that are working on the system model.
equipped with sensing, networking and processing capabilities Lack of mechanisms to address multiple stakeholders
that allow them to cooperate with each other and with their concerns. IoT application development is a multi-disciplined
environment to reach common goals [1]. It is expected that endeavor with concerns coming from various stakeholders [6].
such new paradigm will affect the daily life of people in many Similar to traditional software development, IoT application
aspects, having a significant impact on the economy. Gartner development involves domain specialists, requirements
estimates that the IoT will produce close to $2 trillion of engineers, application engineers, and deployment managers;
economic gain globally with 25 billion Internet-connected however, it requires special skills of them related to the IoT
objects by 2020 [2]. General objectives of IoT are to improve domain. Moreover, IoT application development incorporates a
the quality of human life and optimize industrial processes, by new type of stakeholder: the device expert, who understands
automating tasks that humans must perform. It results in the components and protocols of devices. The second challenge
several benefits, such as enhancing the comfort and security of regards the lack of characterization of such stakeholders, their
homes/offices, getting better and more timely healthcare, or skills and responsibilities, and mechanisms to address their
optimizing the energy consumption [1, 3]. Such benefits are specific concerns into the system model.
obtained by developing IoT applications. Despite the
considerable interest from the industry and academia, there is Lack of a method to design IoT applications. The
no consensus about the definition of IoT application. Based on aforementioned challenges (heterogeneity of entities and
the definition of application as introduced by ISO/IEC/IEEE multiple stakeholders) classify the IoT application development
24765 standard [4] we adopt the definition of IoT application as a Systems Engineering problem. Systems Engineering (SE)
as is a multidisciplinary and holistic approach used to develop
solutions for complex problems comprising hardware,
a collection of automated procedures and data, integrated software, data, and personnel [7]. As a mature discipline, SE is
with heterogeneous entities (hardware, software, and widely accepted within several industries [8] however, to the
personnel) that interact with each other and with their best of our knowledge, there is no method specifically tailored
environment to reach common goals. to design IoT applications.

2376-9505/16 $31.00 2016 IEEE 157

DOI 10.1109/SEAA.2016.19
 In order to address the abovementioned challenges, we presented on diagrams with a specific graphical notation. Such
propose a Model-Based Systems Engineering methodology model elements enable the system to be viewed from different
called IDeA IoT DevProcess & AppFramework. The goals of viewpoints that focus on various aspects of the system while
IDeA are as follows: (i) to furnish high-level abstractions maintaining consistency among the different views. A
through meta-modeling to address the heterogeneity of Methodology can be defined as a collection of related process
software components and hardware devices in the system (a logical sequence of tasks performed to achieve a particular
model; (ii) to provide mechanisms for multi-disciplined IoT objective defines WHAT), methods (techniques, practices
application design by using views and viewpoints in order to and procedures for performing a task, and artifacts that are
deal with different stakeholders involved in the process; and, produced defines HOW), and tools (supporting or enhance
(iii) to conceive a method from existing standards with the accomplishment of the process and methods). Regarding
activities considered as most relevant to IoT application design. Systems Engineering Standards, the ISO/IEC/IEEE 15288 [11]
Our proposal is evaluated trough a case study. is a quite mature process standard [9], and Object-Oriented
Systems Engineering Method (OOSEM) [8] is a method
The remainder of this paper is organized as follows:
standard that uses SysML to support the analysis, specification,
Section II presents a case study used to evaluate IDeA. Section design, verification, and validation of complex systems.
III presents the IDeA methodology, followed by the evaluation SysML [12] is the standard general-purpose graphical
case study in Section IV. We briefly discuss related work in modeling language for Systems Engineering field [9].
Section V and final remarks in Section VI, by pointing other
aspects that are currently being investigated. IDeA (Figure 1) is a Model-Based Systems Engineering
methodology based well-established standards. It is composed
II. CASE STUDY: SMART BUILDING IOT APPLICATION of a method, called IoT DevProcess and a supporting tool,
We consider a hypothetical scenario where a company called IoT AppFramework. The IoT DevProcess is an extension
wants to make the offices more comfortable for its employees of OOSEM specially tailored for IoT application design. It was
while reducing the energy consumption in its building system, conceived to be applied in the context of the technical process
which consists of several buildings, each one with one or more of ISO/IEC/IEEE 15288. To support the activities of IoT
floors, each floor with several rooms. To achieve these DevProcess, the IoT AppFramework provides a SysML profile
business goals, the stakeholders want to create an IoT for IoT applications called SysML4IoT, which is founded on
application that automatically configures the lighting and well-defined IoT concepts. Furthermore, the tool is aligned
temperature levels inside the rooms according to the employee with proven techniques from Systems Engineering and
preferences. To reduce the energy waste, when a room is Software Engineering literature, such as Model Libraries [8]
empty, the devices should be automatically turned off. The and Viewpoints [13].
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 Figure 1 IDeA Methodology
application. This is not as straightforward as it appears at first,
because the IoT domain is inherently interdisciplinary, The IDeA Methodology contributes to the state-of-the-art
encompassing technological, human-centered, among other of MBSE (i) by providing a profile to precisely specify
issues. Therefore, there is a need for a new systematic process heterogeneous entities that compose an IoT application; (ii) by
specifically tailored for the IoT domain. In the following, we identifying stakeholders involved in the application lifecycle
present our proposed MBSE methodology aiming at tackling and related viewpoints, which are formally specified; and, (iii)
these challenges. by defining a method to conceive IoT application system
model aligned with a mature MBSE approach. In the next
III. IDEA: A MODEL-BASED SYSTEM ENGINEERING Subsections, we detail each contribution in light of the
METHODOLOGY TO DESIGN IOT APPLICATIONS challenges to design the IoT Application System Model for
the Smart Building IoT application presented in Section II.
The following definitions from Holt and Perry [9] and
Martin [10] are used to contextualize our proposal. Model- A. (Challenge 1) Heterogeneity of hardware devices and
Based Systems Engineering (MBSE) is an approach where the software components: SysML4IoT
system model is the primary artefact of the application IDeA furnishes high-level abstractions to address the
development. The system model contains elements that can be heterogeneity of hardware devices and software components in

158
the system model through a SysML profile named SysML4IoT. As a meta-model, the IoT ARM Domain Model does not
As demonstrated by [9], the use of profiles aids stakeholders to determine the notation to represent IoT applications by using
deal with the system complexity, increases the understanding its concepts and does not establish any method to generate IoT
and communicates the system model in an unambiguous (or as application system models. To the best of our knowledge, no
unambiguous-as-possible) manner. Furthermore, profiles concrete syntax has been proposed for IoT ARM Domain
promote reuse and interoperability between software Model so far. To tackle this issue, we conceive the SysML4IoT
components and systems [8]. as a SysML profile, providing stereotypes to design IoT
applications based on the IoT Domain Model. Furthermore,
SysML4IoT provides abstractions to specify precisely
SysML4IoT is also aligned with ISO/IEC/IEEE 15288 standard,
different types of hardware devices, software services, data
aiming to enhance system models with Systems Engineering
flows, and personnel. The profile is strongly based on a concepts.
reference model for IoT, the IoT Domain Model (Figure 2),
introduced by a European research project, called IoT-A [14], Figure 3 details important stereotypes defined in the
which aims at standardizing the IoT domain as a reference SysML4IoT profile. Block and Stakeholder are SysML
model. In the following, we briefly describe the model elements. System, System-of-Interest and Enabling System are
concepts, the complete explanation about the IoT Domain reused from in ISO/IEC/IEEE 15288 standard. Other elements
Model can be found in [15]. come from the IoT Domain Model.

Figure 3 SysML4IoT profile (partial)

Figure 2 IoT-A Domain Model [15]
In SysML4IoT, a System is a composition of Devices and
In a generic IoT application domain, a Human User (e.g. Services interacting with other Systems, Physical Entities, and
employee, customer) or a Digital Artifact (e.g. application, Users. A System-of-Interest is a system whose life cycle is
software agent) needs to interact with a Physical Entity an under consideration in the application context; in turn, an
identifiable part of the physical environment that is of interest Enabling System supports a system-of-interest during its life
to the application stakeholders (e.g. car, electronic appliance). cycle stages but does not necessarily contribute directly to its
Virtual Entities are virtual representations of the physical objective during operation. A Service has four attributes: the
entities. A physical entity can be a Device (technical artefacts, serviceType, which specifies the technology used to invoke it
such as Arduino or Raspberry Pi), an Actuator (that changes (such as REST [16]); in and out, defining data types for input
the state of a physical entity, such as switch on/off), a Tag (that parameters and output results; and, the serviceArea, to specify
identifies a physical entity, such as RFID), or a Sensor (that the area that is affected by the service. A Resource has six
provides information, knowledge, or data about the physical parameters: the resourceID, which is a string of characters used
entity they monitor, such as temperature sensor). The to uniquely identify it, defined as a URI (Universal Resource
interaction between digital artifacts and physical entities is Identifier); the name of the resource; latitude and longitude to
mediated by a software Service, which exposes Resources define its geographical location; the parameter hostedOn refers
(software components that provide data from or are used in the to the device, tag, sensor, or actuator that act as its execution
actuation on physical entities). On-Device Resources are hosted environment; and, resourceType, which specifies the type of
on devices (e.g. embedded software) while Network Resources the resource (device, tag, sensor, or actuator). In SysML4IoT,
are available somewhere in the Network (e.g. cloud-based SysML Block is the principal extended element, since SysML
databases). The concept of Augmented Entity constitutes the conceptualizes it as a modular unit of the system that is used to
thing of the Internet of Things in the IoT Domain Model. define a type of software, hardware, data elements of the
system or a composition of them.

159
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 activities of the Domain Specialist are performed in the context
The IoT Application Viewpoints, SysML4IoT, and the of the activity Analyze Stakeholders Needs interacting with
support to create reusable model elements with the IoT Model the Requirement Manager. In turn, the IoT Deployment
Library have been implemented in the IoT AppFramework. Manager conducts his/her activities after the design of the
The tool is a plugin for the MBSE environment No Magic requirements, structure and behavior of the IoT application.
Cameo Systems Modeler [17]. The plugin is available at In the next section, we describe the activities of the IoT
http://ubicomp.nce.ufrj.br/idea. DevProcess in the context of the Smart Building scenario
E. (Challenge 3) Lack of a method to design IoT applications: (Section II). The objective is to demonstrate the effectiveness
IoT DevProcess of IDeA methodology to generate the system model.
We address the third challenge by the IoT DevProcess IV. EVALUATION CASE STUDY: SMART BUILDING IOT
(Figure 5). Initially we performed a quasi-systematic literature APPLICATION SYSTEM MODEL DESIGN
review, based on the protocol as proposed by Dyba and
Kitchenhan [18], to search for MBSE processes and methods A. Evaluation Scope
for IoT application development. As an outcome, we could not The goal of this section is to describe how well the
find any MBSE approach specific for IoT application domain. proposed methodology addresses the challenges introduced
Thereby, we analyzed well-stablish standards and selected the earlier. To evaluate our approach, the IDeA methodology will
ISO/IEC/IEEE 15288 and OOSEM to generate a method with a be applied to create the IoT Application System Model for the
subset of activities and artifacts from them specifically tailored Smart Building IoT application presented in Section II. The
for IoT application development. 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
Figure 5 IoT DevProcess Requirement Diagrams and Requirement Tables.
The ISO/IEC/IEEE 15288 establishes a process framework C. Model Virtual Entities
for describing the entire lifecycle of a complex system. It
includes agreement process (e.g. acquisition, supply), Once knowing the device requirements, Device Expert
enterprise process (e.g. investment management, resource stakeholders specify the devices, services and resources that
management), project process (e.g. planning, risk will compose the application. Each device expert is responsible
management), and technical processes. OOSEM can be applied for modeling the structure and internal configurations of the
over ISO/IEC/IEEE 15288 technical process as a method to device he/she is acquainted with, composing the Virtual Entity
perform its activities, as demonstrated by [19]. View. The structure of the devices, services and resources
follows the IoT Domain Model (introduced in Section III.A
The IoT DevProcess is an extension of the OOSEM method and formally defined in [15]). Figure 6 depicts the Virtual
specifically tailored for the IoT domain. It comprises: (i) the Entity View of the Smart Building IoT application.
allocation of activities to predefined stakeholders; (ii)
modifications on existing activities and artefacts; and, (iii) the The devices (temperature, heater, light, card, and
inclusion of new activities and artefacts (gray elements in the electricity) are composed of sensors and actuators. They host
SysML Activity Diagram of Figure 5). White elements are resources exposed by services. Such services are specifications
classical OOSEM activities. of SysML Ports, which represent access points of a device.
They will be used by the IoT Application Engineer when
We hide activities conducted by the Domain Specialist and creating the Functional View IBD (Figure 9). The flow
IoT Deployment Manager stakeholders since they are not the properties specify the port direction (in or out) and the data
core of IoT DevProcess to generate the system model. The

161
type that flows through the port (such data type is defined in D. Define Logical Architecture
the Information view - Figure 7). After the specification of devices and services for the Smart
Both TempService_Room and LightService_Room have an Building application, the IoT Application Engineer
input port by which the desired temperature and lighting levels decomposes the system into functional components that
are set and output ports by which the actual level of interact with each other to satisfy the system requirements. The
temperature and lighting are requested. To set or request the first step is to create the Functional View. In such view, the
temperature and lighting levels, the services exposes the BDD describes the high-level structure of the IoT application
resources, such as ActualTempResource (referencing the (Figure 8) and the IBD presents the interactions between
Temperature Sensor) and HeaterResource (referencing the systems components and information flows (Figure 9).
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 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
Figure 6 Smart Building Virtual Entity View (which were specified by device experts in the Virtual Entity
View), a Controller, and a Repository. The application interacts
Device Experts also create the Information View (Figure 7), with the building environment and employees swipe cards.
which determines the data format exposed by the services. In The Controller is a service that acts as a central component
the Smart Building IoT application, the information view interacting with the devices through its services. The repository
specifies only one type of data structure (EEML [20]) used to is a database containing the employees preferences of
interact with the devices services. However, it is possible to temperature and lighting levels.
specify more data types to be used in the devices, exposing
resources with different data structures. Alternatively, the IoT The Smart Building Functional View IBD specifies that
Application Engineer can also specify data formats in the when an employee enters a room and uses his/her swipe card in
Information view and request to the Device Experts to use it the Card Device, his/her identification is sent to the controller
when defining the devices services. 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
Figure 7 Smart Building Information View
Expert in the Virtual Entity view

162
E. Qualitative Analysis application development, once it is a multi-disciplined
In the following, we analyze the use of IDeA to generate the endeavor with concerns coming from various stakeholders.
system model in contrast to generating it by using only SysML Other works have already stated that OOSEM may be
(without the SysML4IoT profile and IoT Application enhanced to accommodate domain specific activities (such as
Viewpoints) and classical OOSEM (without the extended [19] for submarine design). The IoT DevProcess is an
activities). extension of such method specifically tailored for IoT domain.
1) Addressing the heterogeneity of hardware devices and It tackles the abovementioned issues by providing activities to
design IoT application system models. Moreover, it defines the
software components
stakeholders that are responsible to perform the activities and
The Smart Building application requires different hardware
their generated views, besides establishing the reuse of model
entities, such as temperature sensors, heaters, lighting sensors,
elements through model libraries.
and card devices. Each device has specific resources exposed
by software services that exchange information between them V. LIMITATIONS
in order to realize the IoT application requirements. By using
only SysML, both hardware devices and software components We now turn to a brief discussion of the current limitations
would be modeled through generic elements, such as Blocks. of our methodology. First, it is required from the stakeholders a
Such approach may produce an ambiguous model, once the deep understanding about the IoT-A Domain Model to
IoT application has elements with similar meaning (such as correctly specify the system model. Such reference model is
device and sensor or on-device resource and services). quite recent and requires significant effort to be understood as a
Furthermore, without a precise characterization of the elements whole, having few concrete examples of its use. However, the
that compose the system, the communication between quality of any modelling activity depends on the skills of the
stakeholders may be negatively affected. domain analyst and modeling IoT systems is no exception.

The main objective of a system model is to aid stakeholders Furthermore, the proposed approach needs to be evaluated
to identify components, increasing the understanding of the through more comprehensive assessment tools. For instance, it
system and enhancing the communication [9]. Through is important to run controlled experiments to assess the
SysML4IoT, all hardware devices and software components are modelling overhead of the approach in a real system
precisely identified in the system model by using stereotypes. It development scenario. Another aspect that must be further
also promotes the communication between stakeholders, once analyzed is how general the modelling elements are when they
there is a common knowledge source that identifies the model are applied in different IoT application projects. However, the
elements: the IoT Domain Model. Furthermore, by precisely characteristics we chose for the PoC scenario (heterogeneity,
identifying the elements with the stereotypes, it is also possible multiple stakeholders, etc.) are the ones that the literature
to create Model Libraries composed of specific elements, such points out as the most common for the IoT domain.
as device model libraries or service model libraries, promoting Furthermore, we extend a mature systems engineering process,
reusability of model elements. the OOSEM, which has been used by several projects.

2) Addresings the lack of mechanisms to address multiple VI. RELATED WORK

stakeholders concerns In this section, we briefly present some model-driven
By using SysML, it is possible to conceive the system approaches for developing IoT application proposed in the
model as a composition of views based on viewpoints. literature. It is possible to notice that none solution is based on
However, it is necessary to identify stakeholders and their Systems Engineering emergent standards or Software
concerns to specify these viewpoints. Such identification and Architecture proven techniques, such as Views & Viewpoints.
viewpoint specification may increase the time and development
costs. Furthermore, if this activity is not properly performed, Regarding specific methodologies to develop IoT
the views may not address the stakeholders concerns correctly. applications, the most similar work was proposed by Patel and
The IDeA methodology provides the characterization of the Cassou [5]. The authors present a model-driven development
different stakeholders involved in the IoT application life cycle, framework that addresses the lack of division of roles and the
identifies their concerns and provide viewpoint specifications heterogeneity of devices in different life cycle phases. To
that are used to generate stakeholders views. achieve such goals, they identify the stakeholders and propose
domain specific languages that provide abstractions to specify
3) Addressing the lack of a method to design IoT different types of devices. The framework takes into account
applications development, deployment, and maintenance phases. Similar,
The OOSEM is a general-purpose MBSE method used to we also propose the identification of stakeholders roles and
design systems in any domain. By using it in the IoT mechanisms to deal with the heterogeneity of devices in the
application design, we identified four issues: (i) it does not IoT application design. However, our work provides a
provide specific activities related to IoT domain, such as methodology that can be used in conjunction to ISO/IEC/IEEE
Model Virtual Entities; (ii) it does not prescribe activities or 15288, which already identifies and formalizes all activities of
artefacts regarding the reuse of IoT model elements; (iii) it an IoT application development endeavor, such as
does not determine the stakeholders that are responsible to management, enterprise, project specific activities. Moreover,
perform the activities; and, (iv) the method is not based on the since our proposal is based on SysML, IDeA can be seamlessly
concepts of views and viewpoints, a crucial feature of IoT integrated into existing SysML-based projects.

163
 In the context of pervasive computing, Serra et al. [21] REFERENCES
propose a domain-specific language based on UML, called [1] A. Whitmore, A. Agarwal, and L. Da Xu, The Internet of ThingsA
PervML, to describe pervasive systems in a technology survey of topics and trends, Inf. Syst. Front., vol. 17, no. 2, pp. 261
independent way. The main purpose of PervML is to address 274, Mar. 2015.
the heterogeneity in the applications. Another proposal is the [2] Gartner, Gartner Says 4.9 Billion Connected Things Will Be in Use in
DiaSuite [22], which is a development environment dedicated 2015. [Online]. Available: http://goo.gl/bgWqwB. [Accessed: 07-Dec-
2015].
to pervasive IoT application design, which relies on a domain-
[3] L. Atzori, A. Iera, and G. Morabito, The Internet of Things: A survey,
specific language that allows the specification of the Comput. Networks, vol. 54, no. 15, pp. 27872805, Oct. 2010.
applications. The stakeholders model entities in a high-level
[4] ISO/IEC/IEEE, Systems and software engineering -- Vocabulary. pp.
manner to abstract the heterogeneity. The main feature that 1418, 2010.
distinguishes IDeA from those approaches is its alignment to [5] P. Patel and D. Cassou, Enabling High-level Application Development
well-established standards. The SysML4IoT profile is based on for the Internet of Things, J. Syst. Softw., vol. 103, pp. 6284, Jan.
SysML and its meta-model is founded on both the 2015.
ISO/IEC/IEEE 15288 and the IoT-A Domain Model. Such an [6] P. Patel, B. Morin, and S. Chaudhary, A model-driven development
alignment improves the overall comprehension of the system framework for developing sense-compute-control applications, in
elements and promotes the easy integration of IDeA with other Proceedings of the 1st Int. Workshop on Modern Software Engineering
Methods for Industrial Automation - MoSEMInA 2014, 2014, pp. 5261.
development approaches based of the same standards.
[7] A. Kossiakoff, W. N. Sweet, S. Seymour, and S. M. Biemer, Systems
Regarding Web Sensor Network (WSN) approaches, Engineering Principles and Practice, 2nd ed. 2011.
Bischoff and Kortuem [23] introduce an engineering method [8] S. Friedenthal, A. Moore, and R. Steiner, A Practical Guide to SysML:
called RuleCaster. The programming model logically divides The Systems Modeling Language. 2014.
the network into spatial regions; then, the RuleCaster compiler [9] J. Holt and S. Perry, SysML for Systems Engineering. 2nd Edition: A
Model-Based Approach. 2013.
receives the application containing rules and the network
[10] J. N. Martin, Systems Engineering Guidebook: A Process for Developing
model describing the spatial regions. Finally, they are mapped Systems and Products, vol. 14. CRC Press, 1996.
to devices. In turn, Taniro et al. [24] propose a model-driven
[11] ISO/IEC/IEEE, ISO/IEC/IEEE 15288:2015 - Systems and software
architecture framework to develop WSN applications helping engineering - System life cycle processes, 2015.
stakeholders to model functional and non-functional [12] SysML 1.4 - Beta. [Online]. Available: http://goo.gl/l8IQ5P.
requirements. The framework increases the abstraction level [Accessed: 14-Dec-2015].
and enables the automatic code generation. It also allows the [13] ISO/IEC/IEEE, ISO/IEC/IEEE 42010:2011 - Systems and software
separation of different development stakeholders concerns. In engineering -- Architecture description, 2011.
our work, sensors are modeled according to the IoT Domain [14] IOT-A: Internet of Things Architecture. [Online]. Available:
Model. Furthermore, the IDeA methodology is based on the http://www.iot-a.eu/public. [Accessed: 20-Feb-2016].
concept of Views and Viewpoints to separate the stakeholders [15] A. Bassi, M. Bauer, M. Fiedler, T. Kramp, R. van Kranenburg, S. Lange,
concerns. Both the IoT Domain Model and the concept of and S. Meissner, Eds., Enabling things to talk: Designing IoT solutions
Viewpoints are mature and well-stablished in the literature. with the IoT Architectural Reference Model. Berlin, Heidelberg:
Springer Berlin Heidelberg, 2013.
VII. CONCLUSIONS AND FUTURE WORK [16] B. Costa, P. F. Pires, F. C. Delicato, and P. Merson, Evaluating REST
architecturesApproach, tooling and guidelines, J. Syst. Softw., vol.
In this paper, we presented a Model-Based Systems 112, pp. 156180, Oct. 2015.
Engineering methodology called IDeA, composed of the IoT [17] Cameo Systems Modeler [Online]. Available:
DevProcess (method) and the IoT AppFramework (tool). IDeA http://mbse.nomagic.com/. [Accessed: 10-Dec-2015].
provides solutions for three challenges of the current design of [18] T. Dyba, B. A. Kitchenham, and M. Jorgensen, Evidence-based
IoT applications: (i) the heterogeneity of hardware devices and software engineering for practitioners, IEEE Softw., vol. 22, no. 1, pp.
5865, Jan. 2005.
software components; (ii) the lack of mechanisms to address
[19] P. Pearce and M. Hause, ISO-15288, OOSEM and Model-Based
multiple stakeholders concerns; and, (iii) the lack of a method Submarine Design, in Systems Engineering and Test and Evaluation /
to design IoT applications. As demonstrated by the case study, 6th Asia Pacific Conference on Systems Engineering, 2012.
the methodology can be used in the context of the [20] Extended Environments Markup Language: EEML. [Online].
ISO/IEC/IEEE 15288 technical process to generate IoT Available: http://www.eeml.org/. [Accessed: 20-Nov-2015].
application system models, helping multiple stakeholders to [21] E. Serral, P. Valderas, and V. Pelechano, Towards the Model Driven
identify components and understand the system. Our current Development of context-aware pervasive systems, Pervasive Mob.
and future works involve improving the methodology by Comput., vol. 6, no. 2, pp. 254280, Apr. 2010.
supporting other phases of the development life cycle. Another [22] B. Bertran, J. Bruneau, D. Cassou, N. Loriant, E. Balland, and C.
important aspect we are planning to carry on is the systematic Consel, DiaSuite: A tool suite to develop Sense/Compute/Control
applications, Sci. Comput. Program., vol. 79, pp. 3951, Jan. 2014.
evaluation of IDeA through controlled experiments.
[23] U. Bischoff and G. Kortuem, Rulecaster: A programming system for
ACKNOWLEDGMENT wireless sensor networks, Smart Sens. Context, 2006.
[24] T. Rodrigues, F. C. Delicato, T. Batista, P. F. Pires, and L. Pirmez, An
This work was partially supported by Brazilian Funding approach based on the domain perspective to develop WSAN
Agencies FAPERJ (under grant E_06/2015E_06/2015 for applications, Softw. Syst. Model., Sep. 2015.
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