The complexity of industrial IoT systems is deemed to increase due to the growing need for data acquisition, processing, and storage techniques. Moreover, the rapid penetration of advanced machine-to-machine communications in cyber-physical systems triggers even more complexity in IoT production systems [modelingIIoT]. The design complexity of such systems has to consider different layers, including the behaviour of the building components, their inter-connectivity, not to mention the message heterogeneity [asyncAPI, IoTdesign].
Model-Driven Engineering (MDE) aims at supporting software development and analysis by promoting the adoption of models as first-class citizens. Performing early analysis on intended systems can help discover how they will behave once deployed. Furthermore, the quantitative results from the conceptual analysis of such systems can provide theoretical support for optimizing system architectures and parameters earlier enough [iotperformance]. The challenges present in IoT systems validation and verification (V&V) also poses a significant gap in certifying such systems. Different industrial model-driven approaches such as [uml4iot, MDE4IoT, sysml4IoT, sysml4IoT2] try to cope with such challenges, but we see it as not yet enough.
To cope with the complexity and heterogeneity issues at the levels of system design, operational, and deployment, we propose CHESSIoT. CHESSIoT is a multi-view modelling environment to support the design, development, and analysis of industrial IoT systems. Currently, CHESSIoT is being developed on top of the CHESS tool[CHESScomplex], a mature modelling and analysis environment for the development of complex industrial systems [CHESSIndustrial]. Since the CHESS tool has been developed to meet industrial needs [lessonCHESS], we decided to rely on it to support industrial IoT development. In addition to CHESS, CHESSIoT offers an IoT-specific modelling infrastructure where the user can specify the system’s structural and behavioural architectures, perform different real-time analyses and generate platform-specific code.
To guaranty a fully decoupled extension, CHESSIoT introduced the "IoT sub-view", and once applied in all design stages, the user will benefit from a dedicated IoT-specific modelling infrastructure consisting of specific diagrams and palettes. The CHESSIoT methodology follows a component-based approach where all system components and their internal behaviours are decomposed separately. The specified components can be annotated with extra-functional properties for analysis purposes or used to generate platform-specific code. The inner or external events can be defined using component state machines. The development of CHESSIoT is still in its early phases but with very significant progresses concerning its design capabilities.
The main contributions of this paper can be summarized as follows:
The CHESSIoT modelling environment to support the development and analysis of industrial IoT systems;
Overview of the envisioned CHESSIoT2ThingML transformation that will enable the generation of target platform code.
Description of a simple use-case on industrial real-time safety to showcase the analysis capabilities for the IoT.
Showcase the real-time schedulability analysis that can be performed on the CHESSIoT model of the presented use case.
This paper is structured as follows: Section 2 gives a concise background of the CHESS and ThingML platforms. Section 3 presents the technical specification of the proposed CHESSIoT extension. Section 4 describes the simple industrial use-case. Section 5 examines the related work. Lastly, Section 6 concludes the paper and makes an overview of our future work.
The following section gives a brief background on the CHESS tool and the motivation behind its extension. Furthermore, we will briefly present the ThingML tool and its development infrastructure and why it is crucial for the CHESSIoT code generation.
2.1 CHESS development environment
The CHESS tool is a mature cross-domain model-driven tool developed on top of the Eclipse Papyrus environment to support the modelling and analysis of dependable systems [CHESScomplex]. The CHESSML modelling language provided by CHESS is an integrated modelling language profiled from OMG standard languages: UML, SysML, and MARTE under the Papyrus modelling environment [papyrus]. The CHESSML language was designed to support the component-based development methodology. Emphasis is given to specify the non-functional properties of the modelled components, including critical properties such as time predictability, isolation, transparency, and other real-time and dependability-related characteristics [chessIoT].
The CHESS tool provides a multi-view modelling environment where each view has its own underlined constraints that enforce its specific privileges on model entities and properties that can be manipulated. Depending on the current stage of the design process, CHESS sub-views are adopted to enhance specific design properties or steps of the current process. Different tools, plugins, and languages have been integrated into CHESS to support model validation, model checking, real-time, and dependability analysis.
CHESS-based modelling and development rely on different views. The Requirement view is used to define system requirements and track their verification. The System view provides a suitable frame for system-level design activities such as contract-based design. It furthermore reinforces a couple of functional and dependability analyses. The Component view consists of two sub-views, i.e., Functional and Extra-functional views which serve for software design logic between system components and their internal compositions. The goal of the Deployment view is to model the hardware structure of the system by permitting the allocation of their corresponding software component instances. The Analysis view captures all the activities and diagrams related to the analysis capabilities of CHESS. Finally, the Instance view visualizes the resulting instance model generated after performing model-to-model transformations of the software models to hardware allocated components.
Even though CHESS has been successfully applied in different application domains such as Avionics [chessavionic], Automotive [chessautomotive], Space [chessVerification], Telecommunication [chesstelecom], and Petroleum [chesspetroleum, FTAandFMEA], its current status does not explicitly provide modelling capabilities for the IoT domain. Consequently, we aim at extending the existing modelling and analysis infrastructure starting from software modelling infrastructure.
2.2 The ThingML framework
In ThingML, a Thing can be defined by properties, functions, messages, ports, and a set of state machines. Like in UML, properties are local variables to a Thing and can be accessible only to other local behavioural parts of a Thing, such as state machines. Functions are also functional behavioural of a Thing but can also be accessed outside the owner Thing. The interaction with a Thing is enabled through required or provided ports by exchanging messages. A message can have zero or multiple parameters to specify its format. ThingML introduced another kind of a Thing called fragment which contains declarations of different Thing’s messages.
ThingML has been used in many different industrial and commercial projects [ThingMLcore]. Several research approaches have been shown interest in applying ThingML as their modelling or code generation framework. To mention a few, in [caps] ThingML has been used to generate code for CAPS, an architecture-driven modelling framework for the development of IoT Systems. In [ENACT] ThingML has been used to specify the behaviour of distributed software components, and later it has been extended with mechanisms to monitor and debug the execution flow of a ThingML program. In [cypriot], CyprIoT tool used and extended the ThingML modelling language to model the behaviour of IoT things and as a code generator for platform-specific code.
Although ThingML framework is very mature and looks very promising, it can not be one shoe fit for all aspects that involve IoT systems design and development. For instance, the ThingML framework does not provide the means to conduct any system-related analyses that are very important in the Industrial IoT domain. There is also a lack of system-level design and validation in ThingML. CHESSIoT envisions having a consolidated and fully automated environment where users can combine both ThingML and CHESS technologies for industrial IoT systems development.
3 Proposed Approach
The CHESSIoT tool has been developed on top of the recently released CHESS 1.0.0 tool [CHESScomplex]. At design time, CHESSIoT enforces that all the components and elements be IoT specific and follows the already existing CHESS modelling methodologies. In particular, systems are specified in terms of a component-based design and employing a multi-view paradigm. The CHEESIoT extension consists of four different profiles depending on the specific view and need for the particular task at hand. As an addition to the domain-specific CHESS views, CHESSIoT adds the IoT sub-view to permit the user to activate services and palettes related to the IoT domain. The CHESSIoT design extensions are available throughout the whole views provided by CHESS as long as the user activates the IoT sub-view from the toolbar. Figure 1 shows the high-level representation of the CHESSIoT extension concerning its development infrastructure, design time, and run-time modelling functionalities. As shown at the top-right of Fig. 1 CHESSIoT consists of four profiles that are singularly described as follows.
CHESSIoTSystem profile serves to cover the system-level design aspects in which the systems main blocks and their interconnections are defined. This is done in the CHESS System View invoking the IoT sub-view. As an extension of the SysML blocks, the IoT high-level blocks and their corresponding flow-ports are defined and later annotated with formal properties as contracts. In this regard, the user benefits from the system level validation and verification, contract refinements, parameterized architecture, and trade-off analysis infrastructure, all provided by the CHESS tool. For the sake of the paper scope, we do not cover such aspects in this paper.
The CHESSIoTSoftware profile provides users with modelling constructs to describe the IoT software components and their behaviours. The software design is done in the Component view. In this regard, the user can decompose the system’s software components and sub-components provided by specific palettes. In CHESSIoT the component behaviours are defined by using state machines.
Figure 2 shows the CHESSIoT software profile meta-model, which consists of the following elements:
The Virtual entity permits the definition of digital representations of physical objects in which the systems resources are allocated. This entity consistently links to its corresponding "Physical Entity" to be defined in the deployment view when performing the hardware designs;
The Virtual board enables the specification of IoT computing boards on which the application will run on. This component is a sub-component to VirtualEntity and can be connected or have reference to one or many other virtual boards. The only crucial property it poses is its state which later gets defined;
The "IoTElement" represents any other IoT Thing that comprises a system aside of being a VirtualEntity or a VirtualBoard. The internal software architecture can be specified using other internal sub-elements and the connectors and ports, while their behavioural specification is defined using custom states, events, and actions. Furthermore, the IoTElements decomposed as IoT system sub-components are then connected to define the system’s main components. To this level, the user can instantiate as many components as possible to meet any system complexity wanted.
In CHESSIoT, we have introduced a flexible event-based modelling mechanism. Normally, the UML state machine events and actions modelling process is complex and tricky when done using the normal Papyrus infrastructure. In our case, the IoTEvents and IoTActions can be modeled separately and later be invoked as many times as possible or by many different IoTElements states. An IoTState always should be linked to an "OnEntry" and an "OnExit" events, which in turn can be either generic, incoming, or an outgoing event. The IoTAction element is for sending and receiving payloads, and action types can then be associated with each event in the form of effect. A payload is any type of message exchanged between IoTElements through ports and can be reused as many times as possible. More information on this is also presented in Section 3.1.
CHESSIoTHardware profile contains a physical deployment representation of the virtual components designed in Component view. The hardware modelling activities are performed in Deployment View. The hardware design also includes the definition of target platform specifications, such as the number of processors and core units. Most of the elements in this profile rely on MARTE [MARTE].
CHESSIoTOperational profile contains all the information regarding the communication aspects of the system, and it extends the CHESS’s Component View. Ideally, the information related to communication mode, servers, communication protocols, and storage resources will be modelled and analysed using this profile. The purpose of adding this part is to support the performance analysis of the involved resource blocks.
In the end, CHESSIoT also will allow the user to generate platform-specific code employing the ThingML platform automatically. Lastly, the user will interact with a remote repository by consuming an open API pushing or pulling artefacts. The high-level description of envisioned CHESSIoT to ThingML model transformation is described in the next section.
3.1 The CHESSIoT to ThingML model transformation
Modelling software component in CHESSIoT goes hand in hand with defining its behaviours, resulting in platform-specific code. The CHESSIoT component’s semantics differs from the ThingML’s to some extent, and that is why the mapping of the elements is needed to solicit an efficient transformation. In the following, we discuss how the different CHESSIoT modelling constructs contribute to the generation of target ThingML elements.
A component: In CHESSIoT, the software components such as IoTElement, VirtualBoard, VirtualEntity are the main modeling elements. They are used to encapsulate the system’s main part structure, operations, and behaviours. These components are mapped to ThingML’s thing.
Provided/Required port: Ports are used to support the communication between two or more components exposing or requiring the interfaces from other components. In CHESSIoT, the component’s messages are passed through the port using the required or provided interface operations. During the transformation, the Required/Provided ports of the components are mapped to the required/provided port of a ThingML’s thing.
Operation: In CHESSIoT, operations specify the functional behaviour of components. During the transformation, each component’s operation is mapped to corresponding Thing’s function.
Property: Properties represent variable attributes local to a component. The property can be primitive or be an instance of other components. Same as in ThingML, properties are used to retain the variable functional value of a Thing, in which during the transformation, the component’s property will be mapped to thing’s property.
Payload: This is a standalone and straightforward object to carry information to be passed between components. The payload will be mapped to a Message in the ThingML model. In CHESSIoT, the payload can have zero or many primitive or derived properties to be defined in a message. For instance, suppose a component message to be communicated among components contains a string value, an integer or even an instance of another payload. In this case, a payload will include three different attributes, which will be represented as message arguments in ThingML.
IoTState: This serves to keep the component state from its initial participation until its disposal in the system. IoTState extends actual UML states but in addition to that, IoTState carries information related to what events need to be taken care of at a certain point in time. For instance, OnEntry or OnExit events are triggered when entering or exiting a state. An IoT state can also trigger an internal event, which corresponds to an internal action to be taken. During the transformation, the IoTState will be mapped to the ThingML state, same goes to State transition that will also be mapped to their corresponding transition provided by ThingML.
IoTEvent: Events in CHESSIoT are triggered in a different manner depending on the state of the component. An IoTvent can be incoming, outgoing, or generic, which means it can come from the inside-out, from the outside, or internal. A GenericEvent is an event that gets triggered internally to the component, for example, changing variable value. CHESSIoT events are mapped to corresponding ThingML event(s).
IoTAction: IoTAction(s) can be of different types depending on the kind of action to be performed. For instance, the SendPayload action is referred to when an OutgoingEvent is triggered to send the payload through a specified port while ReceivePayload is used on IncomingEvents to receive messages from another components. A GenericAction does not require to access the component’s ports, for example, changing the component’s property value. During the transformation, IoTActions will be mapped to corresponding ThingML actions.
State Transition: In CHESSIoT, state transitions enable transiting from the source state to a target state, abiding the trigger from the guard value. Guard expressions are boolean expressions defined based on state values. They serve to initiate a state transition by checking whether the OnExit event has been performed correctly. During the transformation, State transitions will be mapped to the corresponding transitions in ThingML.
|CHESSIoT element||ThingML element|
|Provided/required port||Provided/required port|
4 A real-time safety use case in the Industrial IoT domain
In this section, an explanatory industrial safety use case is modelled and analysed employing the proposed approach. The CHESS tool offers several analyses like dependability and real-time schedulability analyses, which are enabled once the model’s component instances are annotated with extra-functional properties. In this section, we cover only real-time schedulability analysis.
Safety in Industrial IoT systems is crucial to ensure the reliability of the system and the security of the people. Current systems impose the usage of as early detection of any potential safety-related intrusion. When not taken care of, it might bring an immense loss of assets, and in some cases, might even cost human lives as well. A few modern IoT framework configuration approaches, for example [uml4iot], have been proposed for monitoring events and act upon a given exceptional case. In the example shown in Figure 3, a basic safety system is proposed. The system objective is to gather information through specific nodes deployed into a modern environment to collect environment data, and in case of event an unprecedented issue, the system triggers an alarming mechanism to limit further damages.
The system consists of different nodes. The deployed node runs on a computing device such as Arduino Uno222https://store.arduino.cc/arduino-uno-rev3. Humidity and temperature data are collected using attached DHT-11 temperature and humidity sensor333https://components101.com/sensors/dht11-temperature-sensor, whereas the gas level data are collected through the attached MQ2-type gas sensor444https://components101.com/articles/introduction-to-gas-sensors-types-working-and-applications to detect flammable and combustible gasses. Collected data is directly sent to the remote gateway wirelessly using the attached HC-12 Wireless Transceiver555https://www.elecrow.com/download/HC-12.pdf. The system triggers a red light-emitting diode (LED) and sounds an electromechanical alarm in case of any unusual detection. Normally, this system can be used in different industrial contexts or even at home for safety purposes.
In this example, we do not cover the communication layer and the cloud-side designs. This is deemed to be done using the operational profile, which is currently yet fully developed. Besides that, the analyses being performed will be one on the ThingLayer components. More on this is discussed in Section 4.2. In the following, we present the modelling phases of the proposed system.
4.1 Modeling software components
The first step of the proposed approach consists of modelling the node’s main components, corresponding types, and the interfaces they implement. We suppose that the system requirements have been modeled in the CHESS’s requirement view. Modelling the software constructs is done in the component view. Following the approach presented before, the computing board in CHESSIoT is defined as a Virtual board, other devices such as LEDs, sensors, and buzzer are defined as IoTElements. As CHESSIoT follows a component-based approach, only one component needs to be defined, and it can be instantiated and reused as many times as possible.
A virtual entity is considered as a physical object where the computing node will be deployed. In other words, they won’t implement any interface or perform any action. As described before, the interfaces contain functional operations to be carried out during the communication, and they automatically get applied to the elements that implement them.
After defining Component, ComponentType, Interfaces elements and their corresponding Operations, each component’s internal structure is decomposed. This is done by using the UML composite structure diagram. IoTElemnts such as LED, sensors, and buzzer are considered as sub-components of the Virtual board. The internal structure is specified by defining component’s required/provided ports with the corresponding interfaces they expose or require. At this stage, CHESSIoT allows modelling the component behavioural aspects using the UML state machine. The component’s event, action, and payloads are modeled using the component’s inner class diagram and then linked back to their corresponding states. Note that the IoT sub-view element provided by CHESSIoT needs to be opened here to have the right palette containing the behavioural resources. Figure 4 shows the three different modelling parts of the internal structure of a temperature/humidity sensor.
As shown in Fig. 4, temperature/humidity sensors have only one port which provide the IsenseHumTemp interface. The behavioural modelling of it is mainly for code generation purposes. This process has to be done for each defined IoTElements. The next step is to model the node, which is a Virtual board. At this level, the IoTElement can be instantiated as many times as possible to achieve the desired structure of the node. The internal structure of the virtual board can be modeled as shown in Fig. 5. The virtual board also contains required (in red) and provided (in green) ports. The provided ports of the IoTElements have to be connected to their corresponding required ports of the board and vice-versa. The ports in yellow represent a port that provides and require an interface. This can apply to the data communication between the RFModule and the computing board.
The same as the other elements, the board’s behavior specification has to be defined too, but we won’t present it for the sake of space. The virtual entity comprises as many virtual board instances as possible and one or more power source instances. In our case, we used four board instances with one power source.
The next stage involves specifying different physical characteristics of the target platform, such as the number of processors and number of cores. This part extends the MARTE profile typically and this is done in CHESS’s deployment view. In our case, the system will be deployed to one Physical entity which will comprise four different processors. Three of the processors will run on one core each, while the fourth runs on two cores. This process is performed in Deployment view. At this stage, we generated the software and hardware instances that contain the containers and connectors representing components instances and their connectors.
4.2 Real-time schedulability analysis
CHESS tool offers the means to perform real-time analyses on the modelled instance model. Schedulability analysis is performed employing MAST [MAST], a timing analysis tool that relies on the system’s component timing requirements. To perform such analysis, the user needs to annotate the real-time temporal logic properties on each component’s operations. Those properties include the timing request type (i.e., periodic or sporadic), the worst-case execution time of a request, the priority, and the desired execution deadline. This activity is performed in the CHESS’s InstanceView.
CHESS also supports the software to hardware component allocation, which includes allocating component to processor cores. In our case, each node is allocated to one processor running on a single core, except for the second processor, which had two cores and can accommodate two nodes. For analysis purposes, we have allocated the battery unit to one processor running on one core also.
In the Analysis View, we can now specify the analysis context, which will contain the software-hardware instance specifications to run the schedulability analysis. The schedulability results indicated in Fig. 7 show that the system cannot be schedulable due to the excess memory utilization according to the specified real-time properties. We can also look at the timing deadline constraint specified is a way less than the response time. In this case, when the deadline is increased, the execution time also increases, amplifying the response time exponentially as more components are still waiting to respond to a given request. To make the system schedulable, we have reduced the worst-case execution time by 70% and fixed the deadline for all operations to 100milliseconds. We have also separated the nodes from running on the same processor and deploy the battery unit to the second processor’s second core. As presented in Fig. 7, the system has now become schedulable.
Given the schedulability information presented above, we can now know how we may go ahead with the real-case deployment e.g., by having a clear picture of processor types or core counts. Another helpful information we can account too is the event deadlines specifications. In our example, the SendPayload action is periodic, and it is deemed to be sent every 200ms (refer to figure 4), which is perfectly fine because each action in the system needs an average of 100ms to be schedulable.
5 Related Work
Modelling and analysis of the Internet of Things is not a new topic in general, several approaches have already been studied and validated, but few of them focus on the Industrial domain. This section will look briefly at some related research to our system and discuss their differences and correspondences. For the sake of the topic of interest, we will only cover the MDE approaches that extend uses Eclipse Papyrus 666https://www.eclipse.org/papyrus/ modelling as an underlying environment.
In [chessIoT], the CHESS tool has been used to model the life-cycle of scalable and distributed intelligent IoT applications. Although this was a great start towards using CHESS for modeling IoT systems, it is generic considering the specificity of IoT applications. In our approach, we emphasise decoupling the modelling environment for IoT elements to the whole CHESS platform.
In [COMFIT] the authors presented a Cloud and Model-based IDE for the Internet of Things tool (COMFIT) to target the wireless sensor networks (WSN) applications for IoT. The COMFIT modelling environment is built on top of Papyrus, and it presents a simple multi-view environment to model the system’s requirement, structural and behavioural aspects. The wireless nodes of the system and their communication links are created in the structural view, while the model activities and behaviours are modelled as functional units, which later get linked according to the desired execution sequence. Finally, the tool provides the model checking infrastructure respecting the OCL rules specified in the meta-model.
Ciccozzi et al. presented the MDE4IoT tool [MDE4IoT] developed to support the modelling of self-adaptation of connected Emergent Configurations (ECs) referred to as Things in the IoT domain. The authors present a simple smart street light case to highlight and validate their approach characterized by the multi-view and separation of concern capability of the MDE4IoT tool. The run-time adaptations are meant to be performed automatically by specific in-place model transformations that modify the source models. The generation of code from UML state machines has been addressed, whereas the fUML’s ALF complex execution behaviours of the system’s components have been only described. Although this approach is closely related to CHESSIoT, the paper still does not address any analysis aspects of the system.
In [papyrus4iot] the authors introduced Papyrus4IoT, a modelling tool developed under the S3P project. The authors presented a modelling methodology that uses the UML use case diagrams and early system conceptual system specification requirements. Later the designer can define process specification definition, functional, operational platform, and finally, the deployment is done by allocating the system’s functional blocks to the device processing units. Unlike [papyrus4iot], our emphasis is given on separation of concerns and supporting analysis that has not been addressed in [papyrus4iot].
Conzon et al. [brainIoT] have presented the BRAIN-IoT framework, an integrated modelling tool to ease rapid prototyping of intelligent cooperative IoT systems based on shared models. The constructed models are transformed into XML format before being uploaded to the BRAIN-IoT marketplace for future reuse. The model and its manifest containing the metadata about the software are passed into the BRAIN-IoT code generator which automatically generates the OSGi artifacts which are also get stored in the BRAIN-IoT marketplace.
In [uml4iot], the authors introduced UML4IoT domain-specific modelling language to tackle the Industrial Automation Thing (IAT) domain. In UML4IoT, the system’s components are transformed into IATs by IoTwrapper and later integrated into the IoT-based industrial automation environment. The RESTful paradigm is adopted for enhancing the connectivity with third-parties resources. Although their approach focuses more on the industrial use case, it differs from CHESSIoT concerning the multi-view and analysis support.
Authors in [sysml4IoT] introduced a SySML4IoT modelling and analysis platform derived from SysML to support the IoT domain. Following the IoT-A reference architectural reference in [enablingIoT], the authors introduced the SysML2NuSMV translator. The tool has later been extended by [sysml4IoTExtend] to support the design, and the usage of the public/subscribe paradigm to model the communication relationships with other systems. Although the authors suggest the system analysis by considering only the quality of service through model checking, we see it as not sufficient in the industrial IoT domain.
From the above discussion, we can see that most of the proposed UML based modelling approaches for industrial system focus more on design and code generation; we see a significant lack in the analysis mechanism of IoT systems in general with the industrial case in particular. We think that this is an excellent direction for CHESSIoT to explore to address such challenges.
6 Conclusion and future work
Developing Industrial IoT systems has to cope with several challenges, ranging from the heterogeneity in different players to the types of transferred messages. This paper has proposed the CHESSIoT extension covering the Industrial IoT domain on top of the already existing CHESS tool. CHESS is known for its success in modelling and analysis of industrial system engineering applications. We have presented an envisioned mapping from the CHESSIoT model to the ThingML model to support the code generation later. Finally, we showed a modelling and analysis example of a real-time safety use case to validate the current capabilities of the extension.
To enhance the scalability of our approach, in our plans, we would like to explore to possibilities of combining the graphical modelling with a textual-based interface. We would also want to extend different real-time and dependability analyses provided by CHESS to cover the CHESSIoT approach taking care of IoT-specific aspects in the analysis processes. ThingML platform is compelling, but as we have seen, there are still other essential aspects it can’t cover now, for example, concerning model checking and analysis. In our plans, we would like to fully automate the ThingML code generation process from CHESS, in which the platform-specific code generation will be complied and generated directly from the CHESSIoT environment. In our future, we would also like to explore the possibility of exposing the analysis infrastructure so that any external user can consume the tool remotely by consuming an open API.