Actuator behaviour modelling in IoT-Fog-Cloud simulation

Actuator model

In the layered architecture of IoT, actuators are located in the perception layer, which is often referred to as the lowest or physical layer that requires the most detailed level of abstraction in IoT.

In this paper, we are focusing mainly on software-based actuator solutions due to their increasing prevalence in the field of IoT. The DISSECT-CF-Fog actuator model is fairly abstract, hence it mainly focuses on the actuators’ core functionality and its effect on the simulation results, but it does not go deep into specific actuator-device attributes.

The actuator interface should facilitate a more dynamic device layer and a volatile environment in a simulation. Therefore, it is preferred to be able to implement actuator components in any kind of simulation scenario, if needed. In our model, one actuator is connected to one IoT device for two reasons in particular: (i) it is observing the environment of the smart device and can act based on previously specified conditions, or (ii) it can influence some low-level sensor behaviour, for instance it changes the sampling interval of a sensor, resets or completely stops the smart device.

The latter indirectly conveys the conception of a reinterpreted actuator functionality for simulator solutions. The DISSECT-CF-Fog actuator can also behave as a low-level software component for sensor devices, which makes the model compound.

The actuator model of DISSECT-CF-Fog can only operate with compact, well-defined events, that specify the exact influence on the environment or the sensor. The set of predefined events during a simulation provides a restriction to the capability of the actuator and limits its scope to certain actions that are created by the user or already exist in the simulator. A brief illustration of sensor-based events are shown in Fig. 3.

The determination of the exact event, executed by the actuator, happens in a separate, reusable and extendable logic component. This logic component can serve as an actual actuator configuration, but can also be used as a descriptor for environmental changes and their relations to specific actuator events. This characteristic makes the actuator interface thoroughly flexible and adds some more realistic factors to certain simulation scenarios.

With the help of the logic component, the actuator interface works in an automatic manner. After a cloud or fog node has processed the data generated by the sensors, it sends a response message back to the actuator, which chooses an action to be executed. This models the typical sensor-service-actuator communication direction.

Unexpected actions may occur in real-life environments, which are hard to be defined by algorithms, and the execution of some events may not require cloud or fog processes, e.g. when a sensor fails. To be able to handle such issues, the actuator component is capable of executing events apart from its predefined configuration. This feature facilitates the immediate and direct communication between sensors and actuators.

For the proper behaviour of the actuator, the data representation in the simulator needs to be more detailed and comprehensive. Consequently, this extension of the DISSECT-CF-Fog simulator introduces a new type of data fragment in the system, to store specific details throughout the life-cycle of the sensor-generated data.

Finally, the DISSECT-CF-Fog actuator should be optional for simulation scenarios. In consideration of certain scenarios, where the examined results do not depend on the existence of actuator behaviours, the simulation can be run without the actuator component. This might significantly decrease the actual runtime of the simulation, as there could potentially be some computing heavy side effects, when applying actuator functionalities.

Requirements for modelling the internet of mobile things

The proximity of computing nodes is the main principle of Fog Computing and it has numerous benefits, but mobile IoT devices may violate this criterion. These devices can move further away from their processing units, causing higher and unpredictable latency. When a mobile device moves out of range of the currently connected fog node, a new, suitable fog node must be provided. Otherwise, the quality of service would drastically deteriorate and due to the increased latencies, the fog and cloud nodes would hardly be distinguishable in this regard, resulting in losing the benefits of Fog Computing.

Another possible problem that comes with mobile devices is service migration. The service migration problem can be considered as when, where and how (W2H) questions. Service migration usually happens between two computing nodes, but if there is no fog node in an acceptable range, the service could be migrated to the smart device itself, causing lower performance and shorter battery time. However, service migration only makes sense when there are stateful services, furthermore it is beyond the topic of this paper, we consider stateless services and decisions of their transfer among the nodes only.

The physical location of fog nodes in a mobile environment is a major concern. Placing Fog Computing nodes too far from each other will result in higher latency or connection problems. In this case, IoT devices are unable to forward their data, hence they are never processed. Some devices may store their data temporarily, until they connect to a fog node, but this contradicts real-time data processing promises of fogs.

A slightly better approach would be to install fog nodes fairly dense in space to avoid the problem discussed above. However, there might be some unnecessary nodes in the system, causing a surplus in the infrastructure, which results in resource wastage.

Considering different mobility models for mobile networks in simulation environments have been researched for a while. The survey by Camp, Boleng & Davies, 2002 presents seven entity and six group mobility models in order to replace trace files, which can be considered as the footprints of movements in the real world. Applying mobility models is a reasonable decision, because they mimic the movements of IoT devices in a realistic way. The advent of IoT and the technological revolution of smartphones have brought the need for seamless and real time services, which may require an appropriate simulation tool to develop and test the cooperation of Fog Computing and moving mobile devices.

The current extension of the DISSECT-CF-Fog was designed to create a precise geographical position representation of computing nodes (fog, cloud) and mobile devices and simulate the movements of devices based on specified mobility policies. As the continuous movement of these devices could cause connection problems we consider the following events shown in Fig. 4.

Examining the occurrence of these specific events can help in optimising the physical allocation of fog nodes depending on the mobility features of IoT devices.

Actuator implementation in DISSECT-CF-Fog

DISSECT-CF-Fog is a discrete event simulator, which means there are dedicated moments, when system variables can be accessible and modifiable. The extended classes of the timing events, which can be recurring and deferred, ensure to create the dedicated time-dependent entities in the system.

As mentioned in “Actuator Model”, a complex, detailed data representation in the simulator is mandatory in order to provide sufficient information for the actuator component. Data fragments are represented by DataCapsule objects in the system of DISSECT-CF-Fog. The sensor-generated data is wrapped in a well-parameterized DataCapsule object, and forwarded to an IoT Application located in a fog or cloud node to be processed. A DataCapsule object uses the following attributes:

• source: Holds a reference to the IoT device generating sensor data, so the system keeps track of the data source.

• destination: Holds a reference to the Application of a fog node where the data has been originally forwarded to.

• dataFlowPath: In some cases fog nodes cannot process the current data fragment, therefore they might send it to another one. This parameter keeps track of the visited fog nodes by the data before it has been processed.

• bulkStorageObject: Contains one or more sensor-generated data that has been wrapped into one DataCapsule.

• evenSize: The size of the response message sent from a fog node to the actuator component (in bytes). This helps to simulate network usage while sending information back to the actuator.

• actuationNeeded: Not every message from the IoT device requires an actuator response event. This logical value (true–false) holds true, if the actuator should take action after the data has been processed, otherwise it is false.

• fogProcess: A logical value (true–false), that is true, if the data must be processed in a fog node, and should not be sent to the cloud. It is generally set to true, when real-time response is needed from the fog node.

• startTime: The exact time in the simulator, when the data was generated.

• processTime: The exact time in the simulator, when the data was processed.

• endTime: The exact time in the simulator, when the response has been received by the actuator.

• maxToleratedDelay and priorityLevel: These two attributes define the maximum delay tolerated by the smart device and the priority of the data. Both of them could play a major role in task-scheduling algorithms (e.g. priority task scheduling), but they have no significant role in the current extension.

• actuatorEvent: This is the specific event type that is sent back to the actuator for execution.

To set these values accurately, some sensor-specific and environment-specific properties are required. The SensorCharacteristics class integrates these properties and helps to create more realistic simulations. The following attributes can be set:

• sensorNum: The number of applied sensors in a device. It is directly proportional to the size of the generated data.

• mttf: The mean time until the sensor fails. This attribute is essential to calculate the sensor’s average life expectancy, which helps in modelling sensor failure events. If the simulation’s time exceeds the mttf value, the sensor has a higher chance to fail. If a sensor fails, the actuator forces it to stop.

• minFreq and maxFreq: These two numbers represent the maximum and minimum sampling rate of the sensor. If a sensor does not have a predefined sampling rate but rather senses changes in the environment, then these are environment-specific attributes and their values could be defined by estimating the minimum and maximum time interval between state changes in the environment. These attributes are necessary to limit the possible frequency value of a sensor when the actuator imposes an event which affects the frequency.

• fogDataRatio: An estimation on how often the sensor generates data, that requires a fog process. This value is usually higher in the case of sensors that generate sensitive data or applications that require real-time response.

• actuatorRatio: An estimation on how often the sensor generates data, that requires actuator action. This is typically an environment-specific attribute. The more inconsistent and variable the environment is, the higher its chance to trigger the actuator, thus the value of this attribute should be set higher. This attribute has an impact on the DataCapsule’s actuationNeeded value. If the actuatorRatio is higher, then it is more likely to set the actuationNeeded attribute to true.

• maxLatency: Its value determines the maximum latency tolerated by the device when communicating with a computing node. For instance, in the case of medical devices, this value is generally lower than in the case of agricultural sensors. Mobile devices may move away from fog nodes inducing latency fluctuations and this attribute helps to determine whether a computing node is suitable for the device, or the expected latency exceeds this maxLatency limitation, therefore the device should look for a new computing node. This attribute plays a major role in triggering fog-selection actuator events when the IoT device is moving between fog nodes.

• delay: The delay of the data generating mechanism of the sensor.

When creating an IoT device in the simulation, its SensorCharacteristics features should also be defined. This will enable the simulated device to start generating DataCapsule objects according to its characteristics. This is the start of the life-cycle of a DataCapsule object. DataCapsule objects are forwarded to a certain Application of a fog node, based on the fog selection strategy of the device.

The corresponding timed method (called (tick())) of the Application is responsible for processing the data on a fog node. If the actual fog node has adequate resources to process the received data, the processing happens, and if the actuationNeeded attribute of the processed DataCapsule object was true, then it is sent back to the actuator (i.e. the data source) expanded with a specific actuatorEvent object (denoting an action to be performed by the actuator). After the data object stored in the DataCapsule is received by the actuator, it executes the event. If the actuationNeeded attribute was false during the data processing, then the procedure mentioned before is omitted. Otherwise, if the current fog node does not have the capacity to process the data, it sends them over to another node based on the actual strategy of the Application.

The life-cycle of a DataCapsule object ends, when the actuator interface receives a notification indirectly by triggering a consumption event for which the IoT device has been subscribed to. By definition of the DataCapsule, its life-cycle can also end without actualisation events, if the actuationNeeded is set to false. A simplified demonstration of the DataCapsule’s path in the system (meaning the data flow) can be seen in Fig. 5.

The actuator model in DISSECT-CF-Fog is represented as the composition of three entities that highly depend on each other. These entities are the Actuator, ActuatorStrategy and the ActuatorEvent. The entities are serving input directly or indirectly for each other, as shown in Fig. 6.

As mentioned in “Actuator Model” the actuator model must only operate with predefined events to limit its scope to certain actions. These events are represented by the ActuatorEvent component, which is the core element of this model. By itself, the ActuatorEvent is only an interface and should be implemented in order to specify an exact action. There are some predefined events in the system: five of them are low-level, sensor-related events (as discussed in “Actuator Model”), the other five are related to the mobile functionality of the devices, but these can be extended to different types of behaviours.

Since the actuator has the ability to control the sensing process itself (Pisani et al., 2020), half of the predefined actuator events foster low-level sensor interactions. The Change filesize event can modify the size of the data to be generated by the sensor. Such behaviour reflects use cases, when more or less detailed data are required for the corresponding IoT application, or the data should be encrypted or compressed for some reason. The Increase frequency and Decrease frequency might be useful when the IoT application requires an increased time interval between the measurements of a sensor. A typical use case of this behaviour is when a smart traffic control system of a smart city monitors the traffic at night, when usually less inhabitants are located outside. The maximum value of the frequency is regulated by the corresponding SensorCharacteristics object. The Decrease frequency is the opposite of the previously mentioned one, a typical procedure may appear in IoT healthcare, for instance the blood pressure sensor of a patient measures continuously increasing values, thus more frequent perceptions are required. The minimum value of the frequency is regulated by the corresponding SensorCharacteristics. The Stop device event imposes fatal error of a device, typically occurring randomly, and it is strongly related to the mttf of the SensorCharacteristics. The mttf is considered as a threshold, before reaching it, there is only a small chance for failure, after exceeding it, the chance of a failure increases exponentially. Finally, the Restart device reboots the given device to simulate software errors or updates.

Customised events can be added to the simulation by defining the actuate() method of the ActuatorEvent class, that describes the series of actions to occur upon executing the event. The event is selected corresponding to the ActuatorStrategy, which is a separate and reusable logic component and indispensable according to “Actuator Model”. It is also an interface, and should be implemented to define scenario-specific behaviour. Despite its name, the ActuatorStrategy is capable of more than just simulating the configuration of an actuator and its event selection mechanism. This logic component can also be used to model the environmental changes and their side effects.

DISSECT-CF-Fog is a general fog simulator that is capable of simulating a broad spectrum of scenarios only by defining the key features and functionalities of each element of a fog and cloud infrastructure. The ActuatorStrategy makes it possible to represent an environment around an IoT device, and make the actuator component reactive to its changes. For instance, let us consider a humidity sensor and a possible implementation of the actuator component. We can then mimic an agricultural environment in the ActuatorStrategy with the help of some well-defined conditions to react to changes in humidity values, and select the appropriate customised actuator events (e.g. opening windows, or watering), accordingly. This characteristic enables DISSECT-CF-Fog to simulate environment-specific scenarios, while maintaining its extensive and generic feature.

Finally, the Actuator component executes the implemented actions and events. There are two possible event executions offered by this object:

1. It can execute an event selected by the strategy. This is the typical usage, and it is performed automatically for devices needing actualisation, every time after the data have been processed by a computing unit, and a notification is sent back to the device.

2. Single events can also be fired by the actuator itself. If there is no need for an intermediate computing unit (i.e. data processing and reaction for the result), the actuator can act immediately, wherever it is needed as we mentioned in “Actuator Model”.

There might be a delay between receiving an ActuatorEvent and actually executing it, especially when the execution of the event is a time consuming procedure. This possible delay can be set by the latency attribute of the Actuator. By default, a device has no inherent actuator component, but it can be explicitly set by the setActuator() method in order to fulfil the optional presence of the actuator as mentioned in “Actuator Model”.

Representing IoMT environments in DISSECT-CF-Fog

The basis of mobility implementations in the competing tools usually represent the position of users or devices as two or three-dimensional coordinate points, and the distance between any two points is calculated by the Euclidean distance, whereby the results can be slightly inaccurate. To overcome this issue and have a precise model (as we stated in “Requirements for modelling the Internet of Mobile Things”), we take into account the physical position of the end users, IoT devices and data centres (fog, cloud) by longitude and latitude values. The representative class called GeoLocation calculates distance using the Haversine formula. Furthermore, applying geographical location with a coordinate system often results in a restricted map, where the entities are able to move, thus in our case worldwide use cases can be implemented and modelled.

In real life, the motion of an entity can be represented by a continuous function, however in DISSECT-CF-Fog the discrete events reflect the state of the function describing a motion, thus continuous movements are transformed into such events, for instance modifying the direction in discrete moments. Therefore, the actual position only matters and is evaluated before the decisions are made by a computing appliance or a device, for instance when the sensed data is ready to be forwarded.

As we stated in “Requirements for modelling the Internet of Mobile Things”, the mobile device movements are based on certain strategies. Currently two mobility strategies are implemented. We decided to implement one entity and one group mobility model according to Camp, Boleng & Davies (2002), but since we provide a mobility interface, the collection of the usable mobility models can be easily extended.

The goal of the (i) Nomadic mobility model is that entities move together from one location to another, in our realisation multiple locations (i.e. targets) are available. It is very similar to the public transport of a city, where the route can be described by predefined points (or bus stops), and the dedicated points (Pi) are defined as entities of the GeoLocation class. An entity reaching the final point of the route will no longer move, but may function afterwards. Between the locations, a constant v speed is considered, and there is a fixed order of the stops as follows:

$$P_1^{(lat,long)}\stackrel{v}{\to }{P}_2^{(lat,long)}\stackrel{v}{\to }...\stackrel{v}{\to }{P}_n^{(lat,long)}$$

The (ii) Random Walk mobility takes into consideration entities with unexpected and unforeseen movements, for instance the observed entity walks around the city, unpredictably. The aim of this policy is to avoid moving in straight lines with a constant speed during the simulation, because such movements are unrealistic. In this policy, a range of the entity is fixed (r), where it can move with a random speed (v). From time to time, or if the entity reaches the border of the range, the direction and the speed of the movement dynamically change (Pi). That kind of movement is illustrated in Fig. 7.

The MobilityDecisionMaker class is responsible for monitoring the position of the fog nodes and IoT devices, and making decisions knowing these properties. This class has two main methods. The (i) handleDisconnectFromNode() closes the connection with the corresponding node in case the latency exceeds the maximum tolerable limit of the device, or the IoT device is located outside of the range of the node. The (ii) handleConnectToNode() method is used, when a device finds a better fog node instead of the current one, or the IoT device runs without connection to any node, and it finds an appropriate one. These methods are directly using the actuator interface to execute the corresponding mobility-based actuator events.

As we mentioned earlier, actuation and mobility are interlinked, thus we introduce five actuator events related to mobility according to “Requirements for modelling the Internet of Mobile Things”. Position changes are done by Change position event of the actuator. The connection or disconnection methods of a device are handled by the Disconnect from node and Connect to node events, respectively. When a more suitable node is available for a device than the already connected one, the Change node actuator event is called. Finally, in some cases a node may stay without any connection options due to its position, or in cases when only overloaded or badly equipped fog nodes are located in its neighbourhood. The Timeout event is used to measure the unprocessed data due to these conditions, and to empty the device’s local repository, if data forwarding is not possible.

The logistics IoT scenario

In the first scenario, we simulated a one year long operation of a smart transport route across cities located in Hungary. This track is exactly 875 km long, and it takes slightly more than 12 h to drive through it by a car based on the Google Maps, which means the average speed of a vehicle is about 73 km/h.

We placed fog nodes in nine different cities maintained by a domestic company, and we used a single cloud node of a cloud provider located in Frankfurt. Each fog node has direct connection with the cloud node, the latency between them is set based on the values provided by the WonderNetwork service³ . A fog node forms a cluster with the subsequent and the previous fog node on the route as depicted in Fig. 8. This figure also presents the first test case (a), when the range of a fog node is considered as 25 km radius (similarly to a LoRa network). For the second test case (b), we doubled the range to 50 km radius. The IoT devices (placed in the vehicles to be monitored) were modelled with 4G network options with an average 50 ms of latency.

All vehicles were equipped by three sensors (asset tracking sensor, AIDC (automatic identification and data capture) and RFID (radio-frequency identification)) generating 150 bytes⁴ of data per sensor. A daemon service on the computational node checks the local storage for unprocessed data in every five minutes, and allocates them in a VM for processing. Each simulation run deals with increasing number of IoT entities, we initialise 2, 20 and 200 vehicles in every twelve hours, which go around on the route. Half of the created objects are intended to start their movements in the opposite direction (selected randomly).

During our experiments, we considered two different actuator strategies: the (i) RandomEvent models a chaotic system behaviour, where both mobility and randomly appearing actualisation events of a sensor can happen. The failure rate of IoT components mttf were set to 90% of a year, and avoiding unrealistically low or high data generation frequencies, we limited them to a range of one to 15 min (minFreq,maxFreq). Finally, we enhanced the unpredictability of the system by setting the actuatorRatio to 50%. The (ii) TransportEvent actuator policy defines a more realistic strategy to model asset tracking, which aims to follow objects based on a broadcasting technology (e.g. GPS). A typical use case of this, when a warehouse can prepare for receiving supplies according to the actual location of the truck. In our evaluation, if the asset was located closer than 5 km, it would send position data in every 2 min. In case of 5 to 10 km, the data frequency is 5 min, and from 10 to 30, the data generation is set to 10 min, lastly if it is farther than 30 km, it informs changes in 15 min.

The results are shown in Tables 3 and 4. The comparison are based on the following parameters: (i) VM reflects the number of created VMs during the simulation on the cloud and fog nodes, which process the amount of generated data. As we mentioned earlier, our simulation tool is able to calculate the utilisation cost of the resources based on the predefined pricing schemes (Fog+Cloud cost). Delay reflects the timespan between the time of last produced data and the last VM operation. Runtime is a metric describing how long the simulation run on the corresponding PC. The rest of the parameters are previously known, it shows the number of the defined actuator and mobility events. Nevertheless Timeout data is highlighting the amount of data lost, which could not been forwarded to any node, because the actual position of a vehicle is to far for all available nodes.

Interpreting the results, we can observe that in case of the 25 km range, the RandomEvent drops more than half (around 56.19%) of the unprocessed data losing information, whilst the same average is about 23.4% for the TransportEvent. In case of 50 km range, there is no data dropped, because the nodes roughly cover the route and the size of gaps cannot trigger the Timeout event. In contrary, the ranges do not cover each other in case of the 25 km range, which results in zero Change node event.

Based on the Fog+Cloud cost metric, one can observe that the TransportEvent utilises the cloud and fog resources more, than the RandomEvent, nevertheless the average price of a device (applying two vehicles) is about 1197.7$, in case of 20 assets it decreases to about 206.2$, and lastly operating 200 objects reduce the price to about 50.6$, which means that the continuous load of the vehicles utilises the VMs more effectively.

Since the IoT application frequency was set to five minutes, we considered the Delay acceptable, when it was equal or less than five minutes. Based on the results, all test cases fulfilled our expectation. It is worth mentioning that mttf might be effective only in simulating years of operation, thus neither software nor hardware error is triggered (Restart/stop device) in this case. The Runtime metric also points to the usability and reliability performance of DISSECT-CF-Fog; less than three minutes was required to evaluate a one year long scenario with thousand of entities (i.e. simulated IoT devices and sensors running for a year).

Smart healthcare scenario

In the second scenario, we continued our experiments with a smart healthcare case study. In this scenario, patients wear blood pressure and heart rate monitors. We automatically adjust the data sampling period if the monitors report off nominal behaviour: (i) in case of blood pressure lower than 90 or higher than 140; (ii) in case of heart rate values lower than 60, and higher than 100.

In this scenario, each patient represents a different data flow (starting from its IoT device), similarly to the previously mentioned way. First the data is forwarded to the fog layer, if the data processing is impossible there due to overloaded resources, then the data is moved to the cloud layer to be allocated to a VM for processing. As IoT healthcare requires as low latency as possible, the frequency of the daemon services on the computational node was set to one minute. Similarly to the first scenario, one measurement of a sensor creates (a message of) 150 bytes.

We focus on the maximum number of IoT devices which can be served with minimal latency by the available fog nodes, and we are also interested in the maximum tolerable delay, if the raw data is processed in the cloud. We applied the same VM parameters as in the previous scenario, and the simulation period took one day. We did not implement mobility in this scenario, nevertheless actualisation events were still required in case of health emergency to see how the system adapts to the unforeseen data.

Similarly to the first scenario, the hospital was assumed to use a public cloud node in Frankfurt, but it was also assumed to maintain three fog nodes on the premises of the hospital. During our experiments, we considered various number of patients (100, 1,000 and 10,000), and we investigated how the operating costs and delay change and adapt to the different the number of fog VMs and actualisation events.

Since each fog node is available in the local region, the communication latency was set randomly between 10 and 20 ms (regarding to AWS⁵ ), furthermore the actuatorRatio was set to 100%, because of the vital information of the sensed data, thus each measurement required some kind of actuation. The rest of the parameters were the same we used in the logistics scenario.

Our findings are depicted in Table 5. One can observe that the increasing number of applied fog nodes reduces the average costs per patient, in case of three fog nodes the mean cost (projected on one patient) is around 83.7$. This amount of money is continuously grows as the fog nodes are omitted one by one, the corresponding average operating costs are about 97.7$, 118.7$ and 124.0$, respectively, which means maintaining fog nodes also might be economically worthy.

Figure 9 presents the delay of the IoT application concerning the number of utilised fog and cloud nodes. Using a higher number of fog nodes can foster faster data processing, however in case of 10,000 patients, the best delay is 7.74 min, which points out that the utilised resources were overloaded. In the other cases the system managed the patients’ data with less than three minutes delay, but decreasing the number of usable fog nodes can continuously increase the delay.

Lastly, we can observe that no failure happened during the evaluation (Restart/stop device), because of the reliability of medical sensors and the short time of simulation. We can also realise that our simulation tool is able to model thousands of smart objects (e.g. IoT devices and sensors), and their one day long simulated operation could be done in 11 s of elapsed time (Runtime) in the worst case.