Modeling the architecture and behavior of embedded systems has long been a success story in the engineering of embedded systems due to the positive e ects on quality and productivity, e.g., by declarative speci cations, by enabling formal analyses, and by the generation of optimized code. These bene ts, however, can only be reaped with extensive investments in specialized languages and tools which typically come with a closed and highly restrictive ecosystem. In this paper, we report our experiences while building an internal domain-speci c language for IoT systems. We present our modeling language realized in TypeScript and integrated into the TypeScript/JavaScript ecosystem. The modeling language supports the declarative speci cation and execution of components, connectors, and state machines. We also provide a simple state space exploration to enable quality assurance techniques like test case generation and model checking. The language is illustrated by a running example with IoT devices. We believe that our solution lies at a sweet spot of providing a declarative modeling experience while reaping bene ts from modern programming languages and their ecosystem to boost productivity.
Empirical studies report that model-driven engineering is successfully employed
in the engineering of embedded systems (e.g., [
The area of Internet of Things (IoT) is an interesting domain in that regard,
since on the one hand much of the functionality is provided by embedded systems,
but on the other hand an extensive programming language ecosystem exists with
numerous libraries. In SORRIR, an ongoing research project on resilient IoT
systems, we investigated how to use model-driven engineering while exploiting
the bene ts from using TypeScript/JavaScript and its ecosystem. Our project's
focus of realizing resilient IoT systems [
The contribution of this paper is threefold: (1) an internal domain-speci c
modeling language built using TypeScript which provides modeling for
architectural con gurations [
We introduce the running example in the following section. Section 3 contains a description of the modeling language and the realized tool support. This is followed by a discussion of our experiences in Section 4. After a comparison to related work in Section 5, we conclude with an outlook on future work. 2
In the course of this paper, we will illustrate our concepts by a simpli ed parkinggarage hardware prototype, see Figure 1. Future parking garages will be enabled to o er smart services to their customers and operators as well such as on-the- y parking-space reservations or individual guiding.
These intelligent features require di erent sensor nodes and actors which communicate with a local application server (edge). To manage more than one parking garage and to control the parking tra c of a whole city or to bill customers, a cloud connection is required, too. Furthermore, a parking garage must be operational in case of faulty sensors, servers, or network connection.
The application logic is realized inside the SORRIR framework and running on local server. It consists of four di erent components. Components barrier and
barrier: Component parkingManagement: Component barrierController: Component signalController: Component
Connections
MQTT internal parkingManagement { highlighted white { are regular and posses user-de ned behavior. Component barrier performs the semantic lifting from button events to car in/out events and ensures that only one car per second can pass the \barrier". Component parkingManagement, see Figure 2, manages free parking lots. It controls the red and green LED as well as the display regarding the available parking lots in the garage. The MQTT components { highlighted blue { are special kind of I/O components provided by the SORRIR framework and implement the communication via MQTT.
On the hardware side there are two ESP8266 microcontrollers (C). The rst C (left) is used to simulate the barrier of a parking garage. Two buttons are connected to it to simulate a car entering or leaving the garage. The other C (right) is used to visualize the status of the parking garage. A small display shows the remaining free parking spaces. Additionally, a green LED lights up when there are free parking lots available, otherwise a red LED lights up.
To connect the C with the application we use MQTT and { in our case { the Eclipse Mosquitto MQTT broker6. The rmware running on the C is quite simple: it is responsible to send a corresponding MQTT message when a button is pressed or switch the LEDs as well as the display when a message is received. Apart from this, it do not have any further logic. In the course of our testbed, both Cs run a rmware generated by ESPHome7 through a simple YAML con g le. The source code of the example is online8.
parkingManagement: Component
FROM_BARRIER.CAR_IN FROM_BARRIER.CAR_OUT [freeParkingSapces - 1 > 0] / freeParkingSpaces += 1; / freeParkingSpaces -= 1;
TO_SIGNAL_CONTROLLER.LED_RED(false); TO_SIGNAL_CONTROLLER.LED_RED(false);
TO_SIGNAL_CONTROLLER.LED_GREEN(true); TO_SIGNAL_CONTROLLER.LED_GREEN(true); TO_SIGNAL_CONTROLLER.DISPLAY(freeParkingSpaces); / freeParkingSpaces = 5 TO_SIGNAL_CONTROLLER.DISPLAY(freeParkingSpaces); FROM_BARRIER: Port
FROM_BARRIER.CAR_OUT / freeParkingSpaces += 1; TO_SIGNAL_CONTROLLER.LED_RED(false); TO_SIGNAL_CONTROLLER.LED_GREEN(true); TO_SIGNAL_CONTROLLER.DISPLAY(freeParkingSpaces); FROM_BARRIER.CAR_IN [freeParkingSapces - 1 == 0] / freeParkingSpaces -= 1; TO_SIGNAL_CONTROLLER.LED_RED(true); TO_SIGNAL_CONTROLLER.LED_GREEN(false); TO_SIGNAL_CONTROLLER.DISPLAY(freeParkingSpaces); AVAILABLE
FULL
TO_SIGNAL_CONTROLLER: Port
In the following, we present the modeling language developed in the SORRIR
project. The modeling language is inspired by component-based domain-speci c
languages like Matlab/Simulink/State ow, SCADE, and ASCET. Particularly, we
draw on our previous work on the Mechatronic UML [
Listing 1.1 shows the types for the de nition of components. Type AbstractState de nes the overall state of a component. This type has two attributes covering the component's state and a queue of events. The interesting part here is the extensive usage of TypeScript generics. These generics allow us to have generic code for executing components (and later architectural con gurations and state machines) while still enjoying type safety guaranteed by the compiler. The generic parameter E covers the type of events which can be stored in the event queue and processed by the component, the generic parameter P covers the types of ports of a component. Finally, the generic parameter S enables the typing of the internal state of the component. To pass data as payload across components it is possible to extend the type Event and, for example, add a payload attribute.
The type Component de nes the structure of a component which is basically the list of component ports and two functions step and allNextStates. These two functions contain the behavior of a component. They get as input an AbstractState and return the new resulting state. It is important that these functions are side-e ect free, i.e., they do not modify some internal state, to enable state space exploration and model checking (cf. Section 3.4). Furthermore, this improves testability of the component behavior. The allNextStates function will return all potential resulting states if the component has non-deterministic behavior, e.g., when two di erent new states are possible depending on which event in the event queue is processed. Our framework includes an interpreter for the state machines providing those two functions. However, these functions can also be implemented manually, which we used for the integration IoT devices reachable via MQTT.
Listing 1.2 shows the simpli ed type de nitions for the de nition of an architectural con guration. A Connection connects (multiple) ports of (multiple) components unidirectionally for asynchronous event exchange. 1 type Connection<E> = { 2 source: { 3 readonly sourceComponent: Component<any, any>, 4 readonly sourcePort: Port<E, any>, 5 }[ ], 6 target: { 7 readonly targetComponent: Component<any, any>, 8 readonly targetPort: Port<E, any>, 9 }[ ] 10 } 11 type Configuration = { 12 readonly components: Component<any, any>[ ], 13 readonly connections: Connection<any>[ ], 14 }
Listing 1.2. Connection and Con guration de nitions
The use of the E generic in the de nition of the Connection type ensures through type checking by the TypeScript compiler that we only connect ports which share the same E event type. Hence, we do not support a connector where the source emits a subset of events of the target which in principle would be ne.
A Con guration is then just a set of components and a set of connections between them. In this type, we use any as argument for the type parameters to de ne that for the full con guration any event and port types can be used for all components and connections, while the aforementioned type de nition for connections ensures the event-type correctness for each connection individually.
Our framework executes all components of the con guration by continuously executing the step function as well as exchanging all events as de ned by the ports and connections. 3.2
The above de nitions of components can be used to develop any kind of component by creating an object in TypeScript which conforms to the aforementioned component type and particularly implementing a function which satis es the type de nition of the step and allNextStates function.
However, those fully manually implemented components do not reap the bene ts from modeling the behavior like a higher-level of behavioral speci cation and enabling quality assurance techniques like test case generation and model checking. Our aim is to nd a sweet spot for behavioral modeling which combines declarative parts and parts implemented in TypeScript while still supporting the aforementioned techniques. Based on previous experience in Mechatronic UML, we decided to realize a state machines formalism notwithstanding that other formalisms could be also employed.
Listing 1.3 shows the type de nitions for state machines. The type
StateMachineState is an alias for the AbstractState type which re nes the above introduced
generic parameter S. S is de ned as ffsm:F, my:Mg, i.e., we distinguish two parts
of the state of a state machine component. The rst part (fsm:F) covers discrete
states as used in the typical state machine formalisms|the type of the discrete
states is de ned by the type parameter F. The second part (my:M) covers an
abstract state as known from abstract state machines [
M, readonly targetState: F,
Listing 1.3. Types for State Machines
The type Transition, typed with the same generics, allows the de nition of a transition following the usual event/condition/action-paradigm. Each transition explicitly declares a source and target state as well as whether an event of a certain type E needs to arrive at a port P. The two functions condition and action deal with the abstract state part (my:M) of the state-machine state. They enable the developer to write arbitrary code which checks whether the transition is enabled (function condition evaluates to true), and if yes, creates a new abstract state based on the current state via the action function. The action function has in addition to the current state a parameter for a callback function which enables the implementation to send an event during the action possible with parameters based on the abstract state.
We believe this mix of declarative parts and manually written parts could
be a sweet spot. The declarative parts enable execution by a generic
statemachine engine whereas the manually written parts enable to reap the bene ts
of the TypeScript/JavaScript ecosystem. By developing our modeling language
as internal DSL in TypeScript, we can simply use TypeScript as action language
for both of these functions instead of manually developing an action language
like ALF [
You can see an implemented transition of ParkingManagement in Listing 1.4. For event CAR IN on port FROM BARRIER (line 4) it will switch from AVAILBLE to FULL (lines 2 .) if the number of free parking lots { stored within the internal state myState { is equal to 0 (line 5). Two events (lines 9 .) are raised to switch o the green and switch on the red LED. Additionally, an event is sent to update the number of free parking lots at the display. Finally, the updated internal state is returned (line 13). 1 { 2 sourceState: ParkingManagementStates.AVAILABLE, 3 targetState: ParkingManagementStates.FULL, 4 event: [EventTypes.CAR_IN, ParkingManagementPorts.FROM_BARRIER], 5 condition: myState => myState.freeParkingSpaces - 1 == 0, 6 action: (myState, raiseEvent) => { 7 const newFreeParkingSpaces = myState.freeParkingSpaces-1; 8 9 raiseEvent({type: EventTypes.LED_RED, port: ParkingManagementPorts.TO_SIGNAL_CONTROLLER, payload: {status: true}}); raiseEvent({type: EventTypes.LED_GREEN, port: ParkingManagementPorts.TO_SIGNAL_CONTROLLER , payload: {status: false}}); raiseEvent({type: EventTypes.DISPLAY, port: ParkingManagementPorts.TO_SIGNAL_CONTROLLER, payload: {freeSpaces: newFreeParkingSpaces}}); return { freeParkingSpaces: newFreeParkingSpaces, totalParkingSpaces: myState.totalParkingSpaces } };
Listing 1.4. Transition from AVAILABLE to FULL of ParkingManagement 10 11
To interact with hardware nodes equipped with sensors and actors we need a possibility to interact with the world outside of our application. Therefore, we add I/O components to our approach. These are special kinds of of I/Oenabled components with a prede ned internal state and behavior o ered by the underlying SORRIR framework.
Initially, we decided to implement MQTT I/O components within the SORRIR framework, because MQTT is a wide-spread, lightweight, IP-based machine-tomachine protocol for the IoT. Clients connected to a central broker can publish messages to certain topics and receive message on topics they are subscribed to.
To communicate with both microcontrollers, we added two I/O components to our running example: barrierController and signalController, see Figure 1. These MQTT components encapsulate all network and MQTT-speci c tasks, such as connecting to the broker or subscribing as well as publishing to MQTT topics.
Generally, events passed from component to component or even within a component require at least a Type and, optionally, a Port and further user-de ned attributes. MQTT, instead, requires for each message a topic and a payload. This rises the need for a function that decodes MQTT messages to Events and an encode function vice versa. In our approach, the user has to specify and pass such functions to the corresponding I/O component.
For our running example we choose MQTT to demonstrate the applicability of I/O components. Of course, it is possible to implement further protocols or techniques, such as communicating with a ZigBee gateway. 3.4
Many quality-assurance approaches used in Model-Driven Engineering use the state space of the modeled system as a basis for quality analysis. For example, model checking algorithms generate the state space of the system to check whether a speci c property, e.g., a CTL formula, is satis ed by the system model. Similarly, model-based testing approaches use the state space to generate test cases. Finally, the state space or at last an excerpt is an important tool in manual fault- nding activities as it enables developers to check how a system reacts to certain event sequences starting in a certain state.
Our approach supports such an exploration of the state space due to side-e ect free functions and explicit state objects independent of the components and state machines. Furthermore, the components' allNextStates function (cf. Listing 1.1), either manually implemented or our implemented by our interpreter for state machines, calculates all next states of a component in case of non-deterministic behavior. We additionally provide a function, which computes all next states of an architectural con guration by computing the cross product of all next states of all components. Based on these functions, our framework allows the computation of the explicit state space of the system as well as the next N states in the state space as a bounded state space exploration, with the caveat that physical parts of our IoT system needs to be replaced by components simulating the behavior.
Generally, we had positive experiences in developing the framework as well as examples including the illustrative one of Section 2.
Internal DSL embedded in TypeScript. Generally, our experiences
developing both the interfaces, the execution framework and the web frontend as
well as the illustrative examples are very positive. We do not have quantitative
data to compare our spent e ort with the e ort required for developing a similar
system in traditional meta-modeling environments like EMF. However, our
experience in developing Mechatronic UML and Henshin [
Type Checking. TypeScript provides a mature type system. We extensively use generics for typing of events, ports and component states. Hereby, we o oad type checking to the TypeScript compiler instead of manually writing a type checker (and a corresponding advanced type system) for an action language. The type checking ensures that connections only connect ports with the same set of events, i.e., the same types. The only downside is that our solution does not support connections where one port supports just a subset of events of the corresponding port on the other side of the connection.9 Our experience is furthermore that the type inference provided by the TypeScript compiler is generally helpful, with type hints only required very seldomly for type generics when instantiating components.
Pure functions. We designed the TypeScript interfaces as side-e ect-free pure functions. While this required sometimes a bit more e ort to clone and modify the data instead of modifying the data directly, we feel that this e ort is well spent as it greatly simpli es the execution framework, enables the state-space exploration and makes it easier to test the components and the execution framework itself. Unfortunately, while interfaces in TypeScript support readonly annotations for attributes, the attributes themselves could be complex object structures with non-readonly attributes. Hence, the language cannot enforce pure functions and we are dependent on the developer to only write pure functions.
Script ecosystem has been a huge bene t to us. For example, our web fronted was developed in a few hours using React. Furthermore, this also allows in principle each component to provide its own UI additions to the generic one provided by us. Similarly, the integration of the IoT microcontrollers in our illustrative example proved to be very easy. We used an existing rmware which already supports communication via MQTT. It was very easy to develop speci c bridge components that integrate any other service available via MQTT by just reusing 9 This would be possible if TypeScript allowed a super de nition in generics as in Java. existing MQTT libraries and writing a bit of glue code. Furthermore, every user of our framework can write similar components for interaction with outside services. Hence, our framework can be easily extended as needed. The only downside is that this integration of external services does not easily match our design requirement of pure functions. Thus, for activities like state-space exploration, users need to replace those components by simulated proxies. 5
In a recent study on approaches to deployment and orchestration of IoT
applications, Nguyen et al. [
When it comes to modeling languages for IoT systems, however, there are
various approaches. One of the best known is Node-RED [
Negash et al. [
In this paper we described a modeling language for the Internet of Things. The modeling language provides state-machine{based declarative components, as well as connections to form complex systems. The language is integrated in the TypeScript and JavaScript ecosystem and can be accessed via a published npm package. Further, we provide tooling for state-space exploration and graphical components for state introspection and monitoring. With this support, our system lays the foundation for test-case generation, model checking and other quality-assurance techniques.
We showed the applicability of our language, technique and tooling through a real world example. The experiences collected and described further validate our belief of approaching a sweet spot between declarative modeling as well as programming features and available ecosystem.
Our major area of future work is on extending the internal DSL with additional resilience features. First and foremost, the declarative modeling should allow for graceful degradation. We plan to enable this on the state-machine level through failure modes. These trigger annotated state transitions, but are restricted to quiescent states to preventing undesired side e ects.
The model is designed to support further resilience mechanisms. Con gurationtransformation functions, taking a con guration and producing a new one, supporting state and component replication, need to be added next. Lastly, as the Internet of Things is inherently distributed, our implementation should naturally support distributed components. This challenge can mostly be delegated to the execution environment, as it is responsible to deliver events through channels, even when they interconnect physical machines.
Once these additions are included in the language, execution environment and tooling, our system will provide a solid base for developers to create truly resilient IoT applications.
Acknowledgments. The authors acknowledge the nancial support by the Federal Ministry of Education and Research of Germany (grant nr. 01IS18068, SORRIR).