-Internet of Things (IoT) is a pervasive technology covering many applications areas (Smart Mobility, Smart Industry, Smart Healthcare, Smart Building, etc.). Its success and the technology evolution allow targeting more complex and critical applications such as the management of critical infrastructures and cooperative service robotics, which requires real time operation and a higher level of intelligence in the monitoring-control command for decision-making. Furthermore, these applications type need to be fully validated in advance considering that bugs discovered during real operation could cause significant damages. In order to avoid these drawbacks, IoT developers and system integrators need advanced tools and methodologies. This paper presents a methodology and a set of tools, defined and developed in the context of the BRAIN-IoT European Union (EU) project. The overall framework includes both Open semantic models to enforce interoperable operations and exchange of data and control features; and Model-based development tools to implement Digital Twin solutions to facilitate the prototyping and integration of interoperable and reliable IoT system solutions. After describing the solution developed, this paper also presents concrete use cases based on the two critical systems mentioned above, leveraging the application scenarios used to validate the concepts developed and results obtained by the BRAIN-IoT project. Index Terms-Model-Based System Engineering, Internet of Things, Digital Twin, Brain-IoT
Nowadays, the IoT concept is adopted in new application
domains, allowing fast digitalization of contemporary society
[
Recently, several approaches have been proposed to ease the development of IoT systems (see section III-A). However, these solutions do not generally support all the functionalities required by next-gen IoT applications and focus only on development, not supporting the other phases of the application life-cycle, e.g., deployment, validation, monitoring and adaptation at runtime. Currently, the market asks for IoT solutions supporting business critical tasks that can be deployed rapidly and with low costs. Such solutions need to allow the design of applications involving several interconnected heterogeneous platforms and smart things and, at the same time, be able to deploy, monitor and evolve the designed complex solution adapting automatically and at runtime to environmental changes.
This paper is organized as follow: Section II presents the motivation and the requirements that has led to the development of the BRAIN-IoT Modeling & Verification Framework presented in this work. In Section III-A, some existing model-based system engineering approaches are discussed. Then, the BRAIN-IoT modeling methodology is introduced in Section IV and the implementation of the methodology is illustrated in Section V. Next, two use cases, in Section VI, are exploited to demonstrate the functionalities provided by the BRAIN-IoT Modeling & Verification Framework. Finally, Section VII concludes the paper.
The design of an IoT system today presents considerable complexity. Several factors contribute to this complexity: first, an understanding of IoT is still too focused on IoT technologies and objects (device types, communication protocols, cloud, database type, etc.). Such a vision loses sight of the true purpose of the system to develop and leads most of the time to unsatisfactory solutions. Then, the wide variety of IoT systems, in terms of their deployment, is a technological Copyright © 2020 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0). source of complexity: IoT systems can be considered with a ”local” deployment such as an automatic lighting system of a house (measurement, storage, data analysis and execution of the application on a single ”device” connected to the owner’s smartphone), or systems with a ”highly distributed” architecture such as a weather forecasting system (sensor networks for data capture capabilities, plus a cloud for storing, analyzing data and running the end-user application). Another aspect concerns the need to integrate legacy systems, i.e., IoT systems not designed from “zero”, the problem is then to create new innovative services on the basis of existing infrastructures. In this case, it is necessary to ”connect” what exists and then develop / integrate supporting components (authentication, monitoring, data distribution, data analysis, etc.). The objective of this work is to develop a framework that supports the designer of complex next-gen IoT applications, easing the use of disruptive technologies, e.g., Digital Twins.
For this scope, the solution proposed needs to allow i) modelling several aspects of an IoT system: the physical layer, the IoT devices, the system layer, the system behaviors and the interactions among the components. ii) Composing IoT services also provided by different IoT platforms, using a model-based design approach and semantically annotated data formats to support interoperability among heterogeneous systems. iii) Formally verifying and validating the models designed with the framework. iv) The automatic generation of code from the models to be deployed on real devices. v) Supporting the co-simulation approach, with the creation of a mixed reality environment, where virtual and real entities can interact with each other. vi) Monitoring the IoT applications at run-time, keeping the models and the physical world synchronized with each other. The next section will provide a state-of-the-art (sota) of the solutions available to design and manage next-gen IoT applications.
A system design process that adheres to the principles and
methods related to ”system engineering” allows to understand
the design phase of a complex system w.r.t. expected
functionality, cost, time, and quality. In the area of critical systems,
system engineering is in full development and benefits from
domain-specific and often user-specific solutions. Model-based
system engineering is a strong trend, and recent projects such
as AGeSys [
In the field of IoT, however, the offer has not yet reached
this level of maturity, even though stakeholders are investing
heavily in the implementation of model-based design solutions
for distributed software architectures, such as Ericsson for
network software through its development solution based on
the Papyrus [
More specifically, in the field of IoT system engineering,
the Internet of Things - Architecture (IoT-A) project [
In the world of standards, the international standardization
organization Object Management Group (OMG) has developed
the System Modeling Language (SysML) [
Like embedded real-time systems, execution platforms are
a prime concern for IoT systems. The problem of platform
modeling and application allocation on the execution
platforms, in the field of embedded real-time systems, has been
addressed by the OMG in the context of the Modeling and
Analysis of Real-Time and Embedded systems (MARTE) [
The authors have identified that no one of the approaches described above is able to satisfy all the requirements listed in Section II. Besides, methodologies proposed for the IoT domain today do not benefit from dedicated model-based development tools. Indeed, either these methodologies target closed systems (e.g. critical embedded systems) or their only goal is to only establish a guideline for the design process. In the latter case, neither languages, nor development techniques, are defined. However, the choice of a modelling language, and its dedicated tools that will exploit the models, is imperative for the development of well-suited integrated development towards real devices and external services through metaenvironment for the specific needs of the IoT domain. data generation, and human-friendly monitoring of device behaviors. Then, the system-level model will be refined as B. Progrees Beyond SOTA a formal software-level model whose correctness will be
In this paper, the authors propose system engineering so- checked by using the statistic modeling checking and formal lution for the IoT domain. The proposed solution combines verification. The obtained correct software model is used by a standard languages with methodologies, while remaining open code generator to generate the software artefacts. Finally, IoT to domain-specific practices. Furthermore, the approach fosters devices can be modeled as the refined physical-level models tools related to the modelling languages and methodologies. to validate and test the IoT applications before deploying to The authors of this work believe this solution aims at filling the real physical infrastructure. Hence, it allows to have three the gaps in the current system engineering offering for IoT different abstraction level models, including the system-level systems, while not omitting current developer practices. architecture models, software-level components models, and
The solution provides such main features: i) Modelling physical-level IoT devices, the focus of each abstraction level methodology: A lightweight methodology accompanies IoT is as follows: i) system-level models focuses on composability Modelling Language (IoT-ML). Using the language’s capacity of services provided by the IoT devices/platforms and the to describe different levels of abstraction, the methodology overall system behaviors. The system model also serves as an proposes to model entities representing system, software, and aggregator of blocks that are refined in lower level models, i.e., hardware components. By relating such components among the software and device described further. Finally, the authors them, and by linking them to their domain-specific represen- of this paper promote exploitation of the system model, not tation and tools, the authors of this paper promote a system just for design, but also to help deployment, fast prototyping, holistic view of the whole IoT solution. ii) System behavior and human-friendly monitoring of behaviors at runtime. ii) modeling: It is based on IoT-ML and integrated with World software-level models are the formal models of computation Wide Web Consortium (W3C) Web of Things (WoT) Thing with their formal validation capabilities, and their runtime to Description (TD), thus the service provided by the IoT devices, guarantee execution conformity to formal specifications, are communication protocol and its data structure can be modeled obtained from the system-level models through the syntactical as well. iii) IoT physical layer modeling and validation: It transformation. iii) IoT physical device models allow the models the IoT devices, BRAIN-IoT adopted the digital twin virtual representation of the edge domain of an IoT system concept to provide the ability for system application validation following a Digital Twin approach, i.e., the possibility to on the modeled IoT devices before deploying in the production combine a virtual world with a physical one to validate the environment. iv) Models@Runtime: One particular aspect that behavior and performances of a complete system or a system is not well explored in the IoT domain, and critical embedded of systems in various steps. This is necessary when the system systems domain altogether, is the human-friendly monitoring is complex (the number of devices is high, from 100’s to of system state at runtime, directly through the system models. 1000’s) and/or in the case of critical systems. These models A model-based runtime monitoring approach usually helps allow the modeling and simulation of the components performidentify and fix deviations observed at runtime, compared to ing the sensing / actuating, computing and communication formal specifications defined in the models. In the BRAIN- functions, which are the fundamental functions of an IoT IoT solution, not only is runtime formal validation a priority, system. This approach could also facilitate the carry-out of but the authors also wish to benefit from monitoring to enable data analysis. However, to design and validate the physical behavior explanations friendly to humans. v) Code generation: device, the digital twin model must be refined. This paper The code to be deployed is automatically generated from the describes the additional modeling levels required to perform models. such design. The additional models will allow designing and
As mentioned, the core of the system engineering solution validating both the hardware components and the embedded proposed for IoT is based on IoT-ML and its Papyrus tooling. software them. The main expected benefits are twofold: first, However, as a reminder, this work wishes to promote integra- the elimination of the main bugs impacting the behavior and tion of domain practices through linking artefacts or refining the performances of the end devices (e.g., power consumption, models. The following sections describe some domain-specific reach) and the whole system; second, the increase of the languages and tools that refine entities in the system model. system robustness to facilitate and accelerate the complete system deployment in a more secure manner.
posed BRAIN-IoT. As the primary objective, BRAIN-IoT aims to allow modeling in different abstraction layers. Firstly, it designs the system-level model composed by the involved components’ functionalities and interactions based on the system requirements. The system model also eases the linking
dation framework developed to implement the methodology described in Section IV. BRIAN-IoT Modelling & Validation Framework defines a domain-specific Modelling Language describing IoT devices capabilities and system-level behaviors; it also provides toolset supporting the syntax of the modelling language, allowing model verification, model checking, automatic code generation to provide rapid model-based development approach, and Models@Runtime monitoring features. The components in the BRAIN-IoT modeling & Validation framework are shown as in Fig. 1.
There are four main components in the BRAIN-IoT Modelling & Validation Framework: BRAIN-IoT Modelling Languages and Modelling Tools, BRAIN-IoT Code Generators, and BRAIN-IoT Repository. The detailed introduction for each component are presented in the following subsections.
The BRAIN-IoT Modelling Language is decomposed for three purposes: the system modelling language, the software modelling language, and the physical layer modelling language. Each of these modelling languages suits a different concern according to the abstraction layer. As a reminder, these abstraction layers are the system behavior, the software, and the physical layer. The authors of this paper believe using a domain-specific language, and de-facto common practice, suits the needs and habits of the domain-specific developer. Relationships are manually input to relate elements of each abstraction layer. This allows to have a holistic view of the whole architecture. Each of the following sub-sections describe a particular modelling language for a particular abstraction layer.
system modelling language of BRAIN-IoT. It federates the specifications of heterogeneous sub-systems within a global IoT system. The language provides the necessary constructs to design the structural and behavioural system architecture of the system, entities abstracting the software, and entities abstracting the execution platform. At its conceptual core, IoTML integrates the concepts present in the IoT-A architecture reference model. Such a model is shown in Fig.2, extracted from the standard.
Fig. 2. IoT-A concepts in IoT-ML
generic modelling language with heavy roots in the objectoriented community. A UML profile is an extension of UML. It is composed of stereotypes that give additional syntax and semantics to the base UML elements that the stereotype extends. IoT-ML aggregates syntax and semantics from standard UML profiles to benefit from the languages they implement. SysML is used to benefit from its ability to describe and trace requirements. MARTE is used not only for the design of realtime embedded systems design, but also because it fosters the construction of models that may be used to make quantitative predictions taking into account IoT characteristics. IoT-ML takes a subset of stereotypes from such standards, and adds new stereotypes of its own representing concepts of IoT-A that are not present in MARTE or SysML. For example Virtual Entity, that can be both software and hardware, is a concept that does not exist in the UML standard profiles.
As a UML-based model, IoT-ML is a graphical modelling language. The language focuses on structural modelling. Such models are represented in UML composite structure diagrams. Components have internal structures that show parts exposing their interfaces through ports that are then connected together.
IoT-ML also focuses on behavioral modelling in the form of UML state-machines. In such models, the behavior represents the component’s different states. States can pass from one to the other, based on captured events. Events may be due to operation calls or signalling. Specific behaviors may be executed upon transitioning across states, or entering / exiting / staying in a state.
While IoT-ML can already be used for domain-generic IoT
systems modeling, within BRAIN-IoT, the authors of this
paper have showcased that the core of IoT-ML (based on
MARTE, SysML, extended with IoT-A concepts) is generic
and rich enough to build domain-specific extensions for both
IoT standards and IoT technologies. Indeed, IoT-ML has been
extended with new concepts for the W3C TD standard. For
example, the main concept of the W3C TD is the Thing,
which can be either software or hardware or both. To showcase
IoT-ML for a particular IoT technology, the authors of this
work chose to integrate sensiNact [
Thanks to the profile mechanism of UML, all these domainspecific stereotypes can co-exist with the core IoT-ML stereotypes on the same UML base elements. Otherwise said, a same structural or behavioral element, of an IoT-ML architecture model, can be annotated with information specific to W3C TD or sensiNact. This fosters model re-use, separation of concerns, and model consistency through annotating the same base elements.
The mission of W3C WoT (Web of Things) is to counter the fragmentation in the IoT world through standardized complementing building blocks - e.g., metadata and Application Programming Interfaces (APIs) - based on Web technology. WoT enables easy integration and interoperability across IoT platforms and application domains. Therefore, the goal of WoT is to preserve and complement existing IoT standards and solutions like for the BRAIN-IoT domains Robotics and Critical Water Infrastructure. In this context, the usage of WoTcompliant Thing Descriptions (TDs) lays the foundation of interoperable standardized solutions for the various BRAINIoT domains and avoids their silo-like separation in order to overcome the problematic diversity of IoT systems.
There are several prominent W3C standard recommendations for WoT based on the W3C WoT architecture1; the WoT Architecture specification describes the abstract architecture for the W3C WoT. This abstract architecture is based on a set of requirements that were derived from use cases for multiple application domains. A set of modular building blocks is also identified whose detailed specifications are given in other documents. The architecture document describes how these building blocks are related and work together. Systems
based on WoT architecture may cross different domains and integrate several vocabularies and ontologies.
The WoT Thing Description (TD)2 can be considered as the entry point of a Thing (much like the index.html of a Web site). Its specification is the core enabling technology. Different application layer protocols and media types can be described in a TD .
A TD abstracts the capabilities of individual Things into 3 categories called Interaction Affordances: Properties for sensing and controlling parameters, Actions for invocation of physical (and hence time-consuming) processes, and Events for the push model of asynchronous communication. A TD includes information models representing functions, transport protocol description for operating on information models, security information and general metadata about the device.
In summary, a WoT TD comprises the application logic requirements (e.g., values and alerts of a Thing). Devices are required to put a TD either inside them or at locations external to the devices, and to make the TD accessible so that other components can find and access them. As soon as available for a Thing, its TD can be used for flexible implementation and simulation (if required). To support the implementation, WoT Scripting API 3 specifies a common programming interface for Thing implementations as well as Consumer applications implemented by different programming languages.
time: While IoT-ML is expressive enough to encompass IoT design, only with its modelling tools can exploit the full benefits of this formalism. One of the main goals of the IoTML modelling tools is to help deployment and connect it to deployed devices at runtime. This is accomplished through model transformation. Since IoT-ML, in BRAIN-IoT, has extensions specific to other IoT standards and technologies, the modelling tool offers transformation tools to go from one formalism to the other. The goal of such transformations is to bridge the gap between the runtime and the system model.
The IoT-ML models are made in the Papyrus modeller tool.
The modelling tool is a typical Eclipse Eclipse Modeling
Framework (EMF) [
An IoT-ML model, with TD stereotypes annotating its base
elements, can be transformed to a TD in the JSON-based
Serialization for Linked Data (JSON-LD) physical format. As
a reminder, the TD files in JSON-LD are embedded on the
real devices and polled at runtime. The authors of this paper
believe this accelerates deployment of interfaces described in
the system model. Furthermore, it bridges the gap between a
natural way of describing architecture by the system engineers,
and the text-based interface description by the developer. The
importance to foster such a collaboration is explained in [
Using the same shared architecture model, the authors of this work can also transform the structure of the architecture 2https://w3c.github.io/wot-thing-description/ 3https://w3c.github.io/wot-scripting-api/ into a sensiNact data model. The behaviors in the architecture, and deterministic model of the end-device specifications. It represented as state-machines, are transformed to equivalent abstracts the internal architecture of the end-device, as well as sensiNact domain-specific language scripts. By then connect- the embedded software. The BB model takes as input a file ing to the sensiNact gateway, the data model and its sensiNact containing the data values that would be obtained from a real scripts can be run to monitor devices variables, and prototype sensor operating in real conditions. system-level behaviors w.r.t. the runtime devices that should b) White box model: The second step of the top-down comply to the system model. methodology is the creation of a white box (WB) model of the
One last feature of the IoT-ML modelling tool is its ability to end-device representing the internal architecture of the device. monitor its state machines. Although the connection between This architecture is composed of one or several sensors IoT-ML and sensiNact allows us to monitor variables and or actuators, a micro-controller, and one or several conactuate devices, and therefore validate that the runtime is nectivity elements. Sensors are typically exposing an Interconsistent with the system model, it is not always sufficient to integrated-circuit (I2C) interface for digital data (or I/Os for understand the internal behaviors of the devices. For example, analogue one), to let the microcontroller (MCU) read and actuating a device, and noticing a variable change, may not be write into registers to gather the data from the sensor, while sufficient to understand what’s happening for the human being. the connectivity Internet Protocols (IPs) can be programmed Therefore to provide human-friendly behavior explanations, it through a Serial Peripheral interface (SPI) bus or through a is possible to monitor state machines in an IoT-ML model. The Universal Asynchronous Reception and Transmission (UART) state machines are animated and they mirror what’s happening connection. The Hardware Abstraction Layer (HAL) of the in the device state machines. What triggers the animations MCU provides an API to access the hardware resources from are messages that are sent to the IoT-ML modelling tool. the embedded software.
Such messages are either sent by automatically generated code The White-box model represents this typical architecture
instrumentation points (i.e., during code generation itself of the that is described using the SystemC/TLM IEEE 1666 modeling
state machine), or by any source that builds a string respecting language [
The system model in IoT-ML, although connectable to EMUlator (QEMU) or Instruction Set Simulators, and the existing runtimes, is not sufficient to develop the actual blocks models of all the peripheral blocks. This list obviously varies that are to be deployed to form the runtime. Therefore its with each micro-controller, but usually includes the timers, the entities that represent software and hardware, must be refined, reset / clock / power controllers, the interrupt controller, and respectively, into a software architecture model and a physical the hardware accelerators available for the part number. It also architecture model. The next sections describe such models. includes I/O models - UART, GPIO, I2C or SPI controllers 2) Physical Layer Modelling Approach: The BRAIN-IoT - that are used to interact with the other elements of the Physical Layer Modeling Approach allows the refinement of end-device. The MCU is modelled to accurately represent the digital twin model to an architectural model of the physical the bus transactions initiated by the processor. The sensor design including its functional and extra-functional properties. model serves I2C requests issued by the micro-controller, This model can be directly used by the device as well as the and implements the behavior of the block, to react to the Integrated Circuits (ICs) designers as a reference model. This programming sequences. The connectivity model serves SPI proposal follows a top-down model-based design approach or UART requests issued by the micro-controller, and implecomposed of black box and white box models, called virtual ments the behavior of the block, to react to the programming twins. They are functionally equivalent to the physical IoT sequences. In the current developments, the authors have devices and can be used to serve different purposes. One model decided to perform the communication as an abstraction of can be seamlessly replaced by the other, as they all share the all the communication data path by issuing Hypertext Transfer same functional specification that represents faithfully the IoT Protocol (HTTP) requests to the network. When detailed comdevice at its boundaries. They feature the functional and extra- munication protocol information is needed, the connectivity functional properties of the IoT device (behavior, security, models can be connected to an elaborated communication energy efficiency, reach, etc.). model including communication medium such as LoRaWAN, a) Black box model: The black box (BB) model is serving protocol-specific commands. The WB model conforms an abstract representation of the IoT device. It is a sim- to the functional contract of the end-device, as prescribed by ple service-oriented model that represents its functionality, the BB model. regardless of the internal architecture that implements its c) Benefits of the Physical Layer Modelling Approach: behavior. The BB model can be considered as the functional The benefits BRAIN-IoT physical modeling language brings reference of the end-device. It can be reused whatever the to the IoT domain are 1) Early verification of the embedded implementation choices, or even in case of replacement of software, in charge of: data gathering from sensors; local the physical device by another one, as long as the functional processing (data formatting, data analysis, power management, specification and interfaces remain unchanged. It provides the payload construction, encryption, etc.); transmission of the functional contract, the other models or the physical device encrypted data or metadata using the device connectivity shall comply to. Executable, it is a non-ambiguous, repeatable capabilities (Bluetooth, LoRa, SigFox, etc.). 2) A system verification can be achieved in advance without the debug limitations inherent to physical devices, the models offer full inspection and observabilicould yty capabilities for debug and analysis; 3) The complexity of large-scale systems (from tens to thousands of end-devices) can be addressed by instantiating the appropriate number of models in the simulation platform; 4) The system reliability is increased, as the validation strategy of the end-device is strengthened by adding scenarios focusing on device robustness considering its interaction with system environment.
Code Generator: The Behaviour, Interaction, Priority (BIP)
Modeling language, introduced in [
BIP is a highly expressive component-based language that supports the specification of composite, hierarchically structured components starting from the atomic ones. In BIP, the atomic components are finite-state automata having transitions labeled with ports and states that denote control locations where component waits for interactions. Ports are actions that can be associated with data stored in local variables and used for interactions with other components. Connectors relate ports from components by assigning them to a synchronization attribute, which may be either trigger or synchronous. A compound type defines a level of the hierarchy. It contains instances of component and connectors types (i.e., subcomponents) with connection definitions and also priorities to schedule the interactions between these components. A compound component offers the same interface as an atom, so, externally, there is no difference between a compound and an atom. Inner ports from sub-components can be exported.
The BIP formalisms allow the rigorous specification and analysis of IoT systems components behavior. Moreover, the component-based approach supported by BIP facilitates portraying behavior with reusability, and maintainability features.
The BRAIN-IoT Code Generator relies on BIP language to
describe the system behavior. It accepts as an input a formal
specification of system architecture and system behavior using
the BIP language, then it translates the system model into a
set Java code artifacts. The generated Vanilla code could be
simulated independently to the BRAIN-IoT execution platform
called Fabric [
Using BRAIN-IoT Code Generator, the mapping of a formal BIP language integrates all the structures related to components development engineering such as composability and reusability. Moreover, the target language is independent of any technology; all the existing operating systems embed the processing ability of JAVA language.
The information flow of the components described above within the BRAIN-IoT modeling & validation framework is shown in Fig. 1. It is firstly responsible for designing IoT system application, which is going to be constructed, based on the actions and relations between the available devices e.g., sensors, actuators, Cyber Physical Systems (CPSs) - and external services, e.g., weather forecast, open data, third-party IoT platforms, databases. The system level application is modelled along with the relevant IoT environment using BRAINIoT System Modeling Language (IoT-ML) through BRAINIoT modeling tool, representing the system-level behavior models and describing its self-adaptive behavior. Then, the IoT-ML model is refined to BIP model representing functional software-level components model. Finally, the BIP model is converted in source code as system behavior OSGi bundles through BRAIN-IoT Code Generator. The generated bundles are then released and stored in BRAIN-IoT repository, to be deployed and executed in the production environment. Furthermore, it also offers the ability to use developmenttime models to supervise running execution platform states. This solution enables monitoring the IoT devices’ status and system configurations. This is possible, because BRAIN-IoT modeling tool supports the Models@runtime paradigm, allowing to synchronize the system’s behavior and the real system. In addition, the generated OSGi bundles can be validated leveraging IoT device models developed with BRAIN-IoT physical layer modeling language to validate the correctness of the system behavior, before deploying in the physical world. In the BRAIN-IoT repository, stores the public/private modeling library that contains the system level models, BIP behavior models, and WoT TD for the IoT device/platform. In the BRAIN-IoT Service Artifacts library, there are System Behavior Artefacts generated from the BRAIN-IoT Code Generator.
storage area. These zones are divided by an automatic door. This door has a QR code attached on each side which is legible only when the door is closed. In the loading area there are 3 carts each with a QR code attached (different for each case) and three robots responsible for warehouse management are also located. The robots are equipped with vision cameras that allow reading the QR codes they find. The model of the robots is a RB1 base from Robotnik company. They are capable of detecting and raising carts and also transport them from one point to another in an autonomous way. The warehouse is controlled through an Orchestrator that assigns the carts to the storage areas and orchestrates the robots. On the other hand, the storage area is divided into 3 sub-zones (A, B, C) where carts can be stored. The Fig. 3 shows the scenario of the use case in the simulation environment. The logic of the system is that the robot takes the cart from the loading area and places it in the storage area, on the way, it detects an elevator door. The robot scans the QR code of the door. It then sends the QR code to a Fleet Management System (FMS) with a door open request, FMS opens the door. After the door opened, the robot will send again the QR code to the FMS with a door close request.
Firstly, the authors modeled the system level components and the interaction interfaces using IoT-ML with the BRAINIoT as shown in Fig. 4, in which, the FMS is represented by an Orchestrator, with a robot and door connected to an Orchestrator that sends commands to both devices. Moreover, the behavior of the FMS is modeled using BRAIN-IoT modeling language with BRAIN-IoT modeling tool as shown in Fig. 6, and the behavior of the door in Fig. 5
Then the system models are refined as BIP software models and as the inputs of the code generator, the generated artefacts are deployed in the robot. While the robot is running, its status and warehouse coordinates configurations will be monitored through the monitoring tools. The software architecture is as shown in Fig. 7. As a reminder, the EventBus is a service provided in BRAIN-IoT for the communication in a distributed environment and the Robotic Operating System (ROS) Edge Node is an adaptor deployed in the robot for communicating with other applications deployed in the BRAIN-IoT Fabric through the EventBus. Orchestrator Behavior represents the system level behavior and orchestrates the robot and the door. ROS Edge Node provides the adaptor for ROS environment to communicate with other components via eventBus, the current version is extended with Behavior Translator to connect Papyrus using User Datagram Protocol (UDP). Papyrus will provide the visual realtime monitoring of the robot state transitions with the state machine, it is integrated with ROS Edge Node. To demonstrate the Models@Runtime feature, here the authors monitored two aspects: one is the configuration of the warehouse coordinates, another is the runtime status of the robot.
the workflow is as following: 1) ROS Edge Node receives the command events from Orchestrator. 2) ROS Edge Node sends the command to the robot, meanwhile, it converts the command to the messages can be received by Papyrus. 3) When Papyrus receives the command transition message, it will dynamically display the state change.
b) Runtime Warehouse coordinates monitoring: Before the application is deployed, the end-user will configure the warehouse through SensiNact studio, these values will be delivered to warehouse manager through SensiNact Gateway and EventBus, then stored in three tables, which are picking points table storing the coordinates in the loading area, storage points table storing the coordinates in the storage area, and cartStorage points table storing the corresponding place point in the storage area of each cart. On the other side, during runtime, whenever a robot changes the attribute value in the table due to the mission of moving a cart, the warehouse manager will send an update event to sensiNact Gateway, then be delivered to sensiNact studio. Hence, the updates will be reflected in the sensiNact studio.
of infrastructures that are considered, in accordance with European norms, as critical, and therefore, they are bound to a series of conditions for their development, especially in the technological aspect.
In the water management sector, most of the processes are associated to disperse infrastructures in large and varied geographical sites, with numerous interactions with other elements and services related to the human activities. The sharing of information in a safe and efficient manner is a challenge to optimize the actions in urban surroundings to simplify and improve the citizen’s life. The development of models and their implementation in multi-access platforms (internal usage, clients, responsible entities, etc.), constitutes a knowledge and technological challenge for the sector. They require development for the correlation of data, its analysis and the creation of indicators and processes for a better usage of the infrastructure’s maximum potential.
In the water management use case, the scenarios aim to leverage prediction models (based on the collected data), to: increase the security of water supplies, optimize the underlying costs, enhance the services for end-users and connect the infrastructure to other urban services. Analyzing gathered data will help to create more accurate indicators for decision-making, and for real-time, smart and adaptive control procedure and generally more efficient and automated business processes. For evaluating scenarios and developments carried on during the project, a mock-up called MEDUSA was built in the facilities. In the Critical Infrastructure of Water Management System, four use cases have been defined to evaluate the main features, concepts and developments of the BRAIN-IoT project. In this paper for space reasons, only the Resilience Use Case is described. The objective of this Use Case is to validate the resilience of the system in case of hydraulic failures. Normally, the hydraulic system works according to a defined consumption curves at the entrance of the water meters sections. These curves represent the real
Fig. 8. Model of critical water infrastructure consumption in various points of Corun˜a city (Elevado, Cola and Cabecera). The curves are obtained with the opening and closure of the electric valves of every section of water meter, simulating the real consumption of the customers. The resilience of the system is validated in terms of guarantee that the consumption can be ensured in those points. One scenario is to simulate the failure of an electric valve in a pipe and to ensure that BRAIN-IoT platform can recirculate the water for another pipe, controlling the electric valves that allows that, and according to the Detection and Responsive System (DRS) that have been trained for these real failures. Another possible scenario is to simulate the failure of a flow meter and to ensure that BRAIN-IoT platform can recirculate the water for another section with the same goal of ensuring the consumption curves. DRS uses Machine Learning techniques for the detection of failures. The responsive part is based on defined rules, acting as expert system. In the scenario described above, there are three main parts involved: 1) data gathering from the IoT devices 2) An algorithm for detecting the anomalies/failure 3) Control system for reacting the abnormal situation. Point 2 and 3 will be the main components of DRS.
In the critical water infrastructure architecture (see Fig. 8), heterogeneous sensors are placed in various remote locations to collect and transmit data through a LoRaWAN network, obtaining a huge amount of data to be used for training anomalies detection algorithm with the limited number of physical devices. The authors have developed the simulated IoT devices models to generate the data. The system model performs data gathering (from an input table), data encapsulation and encryption, and data transmission to the network through HTTP requests, as an abstraction of the complete LoRaWAN communication data path: gateway + LoRa server / MQTT. Then, the data are processed and stored in the edge database. System security and robustness against vulnerabilities and attacks are guaranteed.
Fig. 9 shows an example of the simulation results, at the system level, obtained by the data transmission, data recovery, processing and display in the EMALCSA application dashboard of a water meter end device. The curves represent, for each device: i) the percentage of valve openness, ii) the water flow measured as output of the valve, iii) the saturation of the pipe.
The authors also aim implementing the control system in point 3 using the BRAIN-IoT Modeling & Validation Framework, following the proposed modeling methodology to get the intended system control models, then, generate the application artefacts. Its correctness will be validated in the simulated devices, hence the risk of physical critical infrastructure damage could be reduced before deploying to the real environment.
and Framework proposed for design and Management of next-gen IoT Systems. This solution provides a Model-Based Engineering (MBE) approach to ease the development of the IoT systems. It offers a system-level model, which captures the system functionalities and behaviors to help refinement of the software-layer modelling; it facilitates the linking towards real devices and external services through meta-data representation in WoT TD; the application code is generated from model for monitoring and controlling the IoT infrastructure; it supports the system application validation leveraging the simulated IoT devices developed with the BRAIN-IoT physical layer modeling language; finally, it allows monitoring the IoT system behaviours and its configurations in a human-friendly graphical manner through the Models@Runtime approach at the execution time.
As future work, the Modelling & Validation framework will be extended to also support AI modelling. In particular the authors will evaluate the feasibility of using system modeling languages to either describe finely machine learning algorithms, or their deployment, in the goal of accelerating development and promoting interoperability between AI (sub)systems. Furthermore, the Critical Water Infrastructure management use case will be further developed including the control part and the associated actuators models to demonstrate the complete functionalities provided by the modeling framework. Furthermore, the authors would provide a survey to some users and get some evaluations to demonstrate the benefits brought by the solutions proposed in this paper.
The work presented here was part of the project ”Brain-IoTmodel-Based fRamework for dependable sensing and Actuation in iNtelligent decentralized IoT systems” and received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 780089. The authors thank Robotnik Automation S.L.L. and EMALCSA for providing the environment, real and simulated to test the solution.