Sensors 2020, 20, x; doi: FOR PEER REVIEW www.mdpi.com/journal/sensors

Type of the Paper (Article, Review, Communication, etc.) 1

SimTalk: Simulation of IoT Applications 2

Yun-Wei Lin1, Yi-Bing Lin2,*, and Tai-Hsiang Yen2 3

1 College of Artificial Intelligence, National Chiao Tung University (NCTU), Taiwan; jyneda@nctu.edu.tw 4 2 Department of Computer Science, NCTU, Taiwan; liny@nctu.edu.tw, ksoy.cs08g@nctu.edu.tw 5 * Correspondence: liny@nctu.edu.tw; 6

Received: date; Accepted: date; Published: date 7

Abstract: Correct implementation and behavior investigation of Internet of Things (IoT) 8

applications are seldom investigated in the literature. This paper shows how the simulation 9 mechanism can be nicely integrated into an IoT application development platform for correct 10 implementation and behavior investigation. We use an IoT application development platform 11 called IoTtalk as an example to describe how the simulation mechanism called SimTalk can be built 12 into this IoT platform. We first elaborate on how to implement the simulator for an input IoT device 13 (a sensor). Then we describe how an output IoT device (an actuator) can be simulated by an 14 animated simulator. We use a smart farm application to show how the simulated sensors are used 15 for correct implementation. We use applications including interactive art (skeleton art and water 16 dance) and pendulum physics experiment as examples to illustrate how IoT application behavior 17 investigation can be achieved in SimTalk. As the main outcome of this paper, the SimTalk 18 simulation codes can be directly reused for real IoT applications. Furthermore, SimTalk is nicely 19 integrated with an IoT application verification tool to formally verify the IoT application 20 configuration. Such features have not been found in any IoT simulator in the world. 21

Keywords: Simulation; IoT, sensor; actuator; smart farm; interactive art; physics experiments 22

23

1. Introduction 24

Many smart applications have been developed with Internet of Things (IoT) technology, 25 including home automation [1], smart aquarium [2] [3], intelligent campus [4] [5], precision 26 agriculture [6] [7], interactive art and entertainment [8], [9], [10], and more. However, it is seldom 27 mentioned how they are corrected implemented, especially for the existing or envisioned 28 applications in remote sensing. To develop these applications, simulations provide a cost-effective 29 verification approach to end-to-end execution. Through simulation, we can also evaluate the 30 conceivability of applying particular techniques to the target IoT applications, which shed light on 31 directions for possible future implementation. We will elaborate on existing IoT simulation 32 solutions in Section 2. These solutions provide guidelines to implement the real IoT applications. 33 However, the simulation codes of these solutions cannot be directly reused for real applications due 34 to their “discrete event” nature. Furthermore, since the codes of the real applications are separately 35 developed, it does not guarantee that the codes for real IoT applications are consistent with the 36 simulation codes. An extra verification process is required. 37

To resolve this issue, this paper proposes SimTalk based on an IoT development platform 38 called IoTtalk [14]. The underlying concept of SimTalk is to develop a time-driven simulation that 39 can automatically translate the simulation codes to those for the real IoT applications and vice versa. 40 Therefore, when we complete the simulation, the codes can be automatically translated into real IoT 41 applications running on IoTtalk. 42

IoTtalk offers a graphical user interface (GUI) to describe the relationship between sensors and 43 actuators graphically, allowing simple data manipulation and transfer between IoT devices to occur. 44 After an IoT service has been developed, IoTtalk GUI binds the network application program with 45

Sensors 2020, 20, x FOR PEER REVIEW 2 of 19

the real sensors and the actuators with a button click. Since the IoTtalk application programs are 46 implemented in Python, the IoT service is immediately provisioned without compilation when the 47 real IoT devices are bound to the network application program. 48

In this paper, we extend IoTtalk with the simulation functionality by providing a simulation 49 soft switch in the IoTtalk GUI. Before the real IoT devices are bound to the IoT applications, the 50 developer can use SimTalk to bind the simulated sensor corresponding to a real sensor, set up 51 specific traffic patterns to the simulated sensor to drive the IoT service, and then observe its behavior 52 for correctness and function improvement. The paper is organized as follows. (2.5) (3.2) Section 2 53 surveys the related IoT simulation solutions. Section 3 provides an overview to the IoTtalk 54 architecture. Section 4 proposes the SimTalk architecture based on IoTtalk. Section 5 discusses the 55 details of SimTalk implementation for the sensors. Section 6 elaborates on the simulators for the 56 SimTalk actuators. 57

2. Related Work 58

A good survey of IoT simulation is given in [29], which compared the state-of-the-art IoT 59 simulation solutions. This survey points out that an IoT research project typically consists of two 60 phases. 61

62 Phase 1. A proof-of-concept is realized in the virtual domain using simulation. 63 Phase 2. The real IoT application is implemented and experimented on a testbed. 64 65 Many simulation studies address Phase 1 in [29]. One of these studies [30] proposed 66

agent-based adaptive parallel discrete-event simulation to enhance scalability and to permit 67 simulation of largescale smart cities. In [28], the authors proposed YAFS, a discrete-event fog 68 computing simulator to model the relationships among the real IoT applications, network 69 connections and infrastructure characteristics. In particular, the authors modeled three scenarios for 70 dynamic allocation of new application modules, dynamic failures of network nodes and user 71 mobility along the topology. IOTSim [26] is a simulator that enables simulation of IoT big data 72 processing using MapReduce model in a cloud computing environment. In [25], the authors 73 proposed an agent-oriented approach for modeling IoT networks. Specifically, by using the 74 Omnet++ simulation platform, the ACOSO model is exploited to simulate IoT networks of various 75 scales. Then the simulation results are used to analyze the bottlenecks at communication level. In 76 [27], the authors also used Omnet++ to simulate the IoT applications with hardware in the loop. The 77 resulting discrete-event simulation increases quality and significance of the modeling results, and 78 enables the analysis of components that are not available at early stages of the development cycle. 79

The state-of-the-art simulation solutions described above live up to the goal of Phase 1, and the 80 simulation results provide very good guidelines to implement the real IoT applications in Phase 2. 81 However, the simulation codes of these solutions cannot be directly reused for real applications due 82 to the “discrete event” nature of the codes (where the clock of the simulation is advanced by an 83 event scheduler based on the timestamps of the events, which is not found in the real applications). 84 Furthermore, since the codes of the real applications are separately developed in Phase 2, it does not 85 guarantee that the codes in Phase 2 are consistent with the simulation codes in Phase 1. An extra 86 verification process is required. 87

Unlike the above discrete-event simulation solutions, SimTalk follows the time-driven 88 simulation approach that does not need any event scheduler used in an event-driven simulation, 89 and can be implemented in a real IoT development environment (like IoTtalk) by using the real 90 time advancing mechanism. With SimTalk, the development of an IoT application project 91 seamlessly advances from Phase 1 to Phase 2 by simply changing the execution time units. There is 92 no need to verify if the codes in both phases are consistent because they are the same in SimTalk. 93

Besides simulation capability, SimTalk and IoTtalk are nicely integrated with two tools that 94 verify the correctness of SimTalk and sensor data accuracy of IoTtalk. Such features are not found in 95 any IoT simulators in the world. Based on the theory of bigraphs [12], correct configurations of IoT 96

Sensors 2020, 20, x FOR PEER REVIEW 3 of 19

devices in SimTalk are formally verified by BigraphTalk [13], a verification framework that utilizes 97 formal techniques to statically guarantee that there are no unwanted sensor-actuator configurations. 98 BigraphTalk checks for invalid connections between devices, as well as type errors, e.g., passing a 99 float to a Boolean switch. In [11] [19], methods have been proposed to guarantee that the sensor data 100 are correct. In particular, SensorTalk approach [11] has been integrated with IoTtalk to 101 automatically detect potential sensor failures and calibrates the aging sensors semi-automatically. 102 When the sensors trigger the actuators, SensorTalk can detect failures within a short detection delay 103 so that when a potential failure occurs, it is detected reasonably early without incurring too many 104 false alarms. Details of BigraphTalk and SensorTalk are out of the scope of this paper, and can be 105 found in [11] [13]. 106

3. The IoTtalk Architecture 107

As an IoT application development platform, IoTtalk is defined in two domains [14]. In the 108 device domain, an IoTtalk device (such as a PM2.5 sensor or a light actuator) consists of two 109 software components: 110

The Sensor and Actuator Application (SA; Fig. 1 (a)) is responsible for the implementation of the 111

IoT device function such as the PM2.5 algorithm or the light intensity and color circuit 112

software. 113

The Device Application (DA; Fig. 1 (b)) is responsible for communications with the IoTtalk 114

network domain. The communication technique can be wired or wireless (e.g., WiFi, LTE, 115

NB-IoT, RoLA, and more). 116 The DA/SA software of an IoT device can be automatically generated (AG; Fig. 1 (a) and (b)) or 117 manually created (Fig. 1 (c)). 118

119 Fig. 1. The IoTtalk architecture. 120

121 In the network domain, an IoTtalk server is responsible for provisioning the network 122

applications that manipulate the IoTtalk devices. An IoTtalk service or project (such as smart home or 123 smart agriculture) is a set of network applications. The server consists of several subsystems (Fig. 1 124 (d)-(k)). The Execution and Control Subsystem (EC; Fig. 1 (d)) is responsible for the control plane (the 125 Control Submodule) and the user plane (the Execution Submodule) of the end-to-end path between 126 the IoTtalk devices and the server. The Creation, Configuration and Management Subsystem (CCM; Fig. 127 1(e)) systematically creates and manages the network applications of the IoTtalk devices for the 128 corresponding IoT services. IoTtalk defines a device model for real devices with the same properties. 129 For example, a smartphone device model is mapped to various real smartphones such as iPhone, 130 iPad, Android smartphones and more. A device model consists of several device features (DFs). For 131

AG DA

SimTalk

GUI

SimTalk

Subsystem

AutoGen

Subsystem

EC

Subsystem

IoTtalk

GUI

Manual

DA/SA

AG SA

Device

Domain

CCM

SubsystemAAA

Subsystem

Network Domain (IoTtalk Server)

a

b

c d

i

j

k

h

e

g

IoTtalk

DB

f

Sensors 2020, 20, x FOR PEER REVIEW 4 of 19

example, the acceleration sensor of a smartphone is an input DF (IDF) that sends data to the EC, and 132 the speaker of the smartphone is an output DF (ODF) that receives instructions from the EC. For the 133 configuration purpose, we further partition a device model into the input and the output parts. The 134 input device model is the set of IDFs (e.g., the acceleration sensor, the gyro sensor, the camera and 135 the soft keys of a smartphone) and the output device model is the set of ODFs (e.g., the speaker and 136 the screen of the smartphone). The CCM is responsible for managing the device models and their 137 DFs, and store such information in the IoTtalk Database (DB; Fig. 1 (f)). The IoTtalk Graphical User 138 Interface (GUI, Fig. 1 (g)) is a friendly web-based user interface that allows a developer to quickly 139 establish the connections and meaningful interactions among the IoT devices. The Authentication, 140 Authorization and Accounting Subsystem (AAA; Fig. 1 (h)) is responsible for the management of user 141 accounts and access to the IoTtalk applications. Fig. 1 (d)-(h) are core components in a typical IoT 142 platform, where the developer manually creates IoT devices and IoT services through the IoTtalk 143 GUI. Two major network protocols are used in IoTtalk: Message Queueing Telemetry Transport 144 (MQTT) are used in the links (b)-(d), (c)-(d), (d)-(e) and (e)-(g). HTTPS is used in the link (e)-(g). The 145 DB interacts with the CCM through the ORM protocol. 146

Fig. 2 illustrates a smart farm service where the farmer uses the weather station (Fig. 2 (a)) and 147 the timers (Fig. 2 (b)) to control the farming actuators such as the lights (Fig. 2 (c)) and the sprayers 148 (Fig. 2 (d)) 149

150 Fig. 2. A simplified smart farm service. 151

152 Fig. 3 shows how this simplified smart farm service is created by using the IoTtalk GUI (Fig. 1 153

(g)). From the Model pulldown menu (Fig. 3 (a)), we select two input device models: the Sensors 154 model (Fig. 3 (b)) implements the DA/SA for the weather station and the Timers model (Fig. 3 (c)) 155 implements the DA/SA for multiple timers. Similarly, we select the output device model Actuators 156 (Fig. 3 (d)) that implements the DA/SA for the farming actuators. The Sensors model includes Lum-I 157 (the IDF for the luminance sensor) and Hum-I (the IDF for the humidity sensor). The Timers model 158 includes two IDFs for two timers. The Actuators model has Light-O (the ODF for the lights) and 159 Spray-O (the ODF for the sprayers). To control the lights by the luminance sensor, we simply drag a 160 line to connect Lum-I and Light-O in the GUI. In this simple smart farm service, the lights are 161 controlled by both the luminance sensor and timer 1 through the Join 1 link. Similarly, the sprayers 162 are controlled by both the humidity sensor and timer 2 through the Join 2 link. 163

By clicking the upper-right corner of the Sensors icon (Fig. 3 (e)), the SA/DA of the Sensors 164 model is bound to the real device, i.e., the weather station in Fig. 2 (a), and the service is activated for 165 execution. 166 167

SprayerSprayer

Light

Light

Sprayer

b

d

c

a

Sensors 2020, 20, x FOR PEER REVIEW 5 of 19

168 Fig. 3. IoTtalk configuration for the smart farm service. 169

170

4. The SimTalk Architecture 171

IoTtalk also provides an advanced feature called AutoGen, which can automatically generate the 172 devices and the projects (services). An example is EduTalk [15] that is a physics and Python 173 programming course platform. We use AutoGen to automatically create an IoTtalk project for an 174 EduTalk course lecture to perform physics experiment through interaction with a smartphone. 175 AutoGen is also used to interwork IoTtalk with any NB-IoT systems, where IoTtalk automatically 176 creates a device called NB-IoTtalk for every NB-IoT service. This NB-IoTtalk device provides 177 interaction between the NB-IoT devices (e.g., the parking sensors) with any existing IoTtalk devices 178 to build new services [16]. Like NB-IoTtalk, AutoGen is used to interwork IoTtalk with various AI 179 tools by packaging these AI tools as IoT devices derived from the ML_device device model [17][18]. 180 This novel approach for integrating IoT with “X” systems is provided by the AutoGen Subsystem 181 (Fig. 1 (i)) that is considered as a platform to create “X-Talk” Subsystems (Fig. 1 (j)). In the current 182 IoTtalk version, X=Edu (education), NB-IoT, and AI. Every X-Talk service is associated with a 183 web-based GUI that allows the developer to set up the parameters of the automatically generated 184 device. For example, the developer uses AItalk GUI to select the machine-learning algorithms such 185 as Support Vector Machine (SVM), k Nearest Neighbor (kNN), Decision Tree, Random Forest, and 186 so on. After the developer has set up the device parameters, the AutoGen Subsystem creates the 187 device (Fig. 1 (a)-(b)). In this paper, we will focus on SimTalk, the simulation capability for IoTtalk, 188 which is built on top of the AutoGen Subsystem. The SimTalk Subsystem (Fig. 1 (j)) is associated 189 with a web-based GUI (Fig. 1 (k)) that allows the developer to set up the parameters of the 190 automatically generated device. In Fig. 1, HTTPS is used for (e)-(i) and (j)-(k). The arrow link (g)->(k) 191 represents page jumps from the IoTtalk GUI to the X-Talk GUI. 192

The idea of SimTalk is described as follows. To further explore the AutoGen feature, for every 193 real input device in a project, we can automatically create a counterpart simulated sensor to 194 faithfully simulate the behavior of that input device. The detailed functional block diagram of the 195 SimTalk and the AutoGen Subsystems in Fig. 1 are illustrated in Fig. 4. In this figure, the SimTalk 196 GUI (Fig. 4 (a)) allows the developer to set up the parameters of the simulated sensors. The SimTalk 197 Event Handler (Fig. 4 (b)) receives the instructions from the SimTalk GUI and the AutoGen 198 Subsystem (Fig. 4 (c)), and executes the Simulator Management Procedures (Fig. 4 (d)) 199 corresponding to these instructions. The execution results are saved in the SimTalk DB (Fig. 4 (e)). In 200 the AutoGen Subsystem, the AutoGen Event Handler (Fig. 4 (f)) receives the instructions from the 201 SimTalk Subsystem and the CCM (Fig. 4 (g)), and executes the AutoGen Management Procedures 202 (Fig. 4 (h)) corresponding to these instructions. 203

b

c

d f

a

g

e

Sensors 2020, 20, x FOR PEER REVIEW 6 of 19

204 Fig. 4. The SimTalk and the AutoGen Subsystems. 205

206 We note that the AutoGen Procedures are generic that apply to all X-Talks including EduTalk, 207

NB-IoTtalk, AItalk and SimTalk. 208

5. Implementing SimTalk 209

When the IoTtalk server is installed, all databases including the SimTalk database (DB; Fig. 4 (e)) 210 are initiated. When the AutoGen Subsystem is initiated, it executes the initiation program (Fig. 4 (i)) 211 to find the host of SimTalk Subsystem in the X-Talk Configuration File (Fig. 4 (j)). This host 212 information is used to invoke the SimTalk initialization program (Fig. 4 (k)) that creates the threads 213 for the SimTalk GUI and the SimTalk Event Handler. 214

We use the Sensors device model as an example to show how to set up a simulated sensor. By 215 clicking the gear icon in the upper-left corner of Sensors (Fig. 3 (b)), the Sensors DF setup table pops 216 up (Fig. 3 (f)). When we click the “Extra Setup” button (Fig. 3 (g)), the IoTtalk GUI (Fig. 4 (l)) jumps 217 to the SimTalk GUI (Fig. 4 (a)). The SimTalk GUI sends a query request to the SimTalk Event 218 Handler. The handler invokes the Query Parameters procedure (Fig. 4 (m)) to send the request to the 219 AutoGen Event Handler. Through the X-Talk HTTP Service procedure (Fig. 4 (n)), the event handler 220 forwards the query to the CCM (Fig. 4 (g)). The CCM retrieves the parameters of IDFs (i.e., Lum-I 221 and Hum-I) from the IoT DB (Fig. 1 (f)), and returns them to the SimTalk Subsystem through the 222 AutoGen Subsystem. The SimTalk Event Handler invokes the Save Parameters procedure (Fig. 4 (o)) 223 to create a record for Sensors in the SimTalk DB (Fig. 4 (e)), and saves all IDF parameters in this 224 record. 225

The handler returns the Sensors record to the SimTalk GUI. This record is used to create a 226 parameter setup window for the Sensors device model (Fig. 5 (a)), which lists Lum-I and Hum-I to 227 be simulated. In this window, when the Lum-I button (Fig. 5 (b)) is clicked, the luminance simulated 228 sensor setup window is popped up. In this window, we set up the inter-arrival times by selecting the 229 distribution (fixed, Exponential, Gamma, and more) through the corresponding pull down menu 230 (Fig. 5 (c)). Similarly, we determine the variance and the mean of the distribution through the 231 buttons in Fig. 5 (d) and (e). If all IDFs of Sensors have the same inter-arrival times, then we can set 232 up it by clicking the Sensors button (Fig. 5 (a)) with the similar setup procedure described above. 233

SimTalk GUI

SimTalk Subsystem

Management Procedures

Init

iali

zati

on SimTalk

DBQuery

Parameters

Save

Parameters

SimTalk Event Handlerb

de

k

om

a

AutoGen Subsystem

Management Procedures

Init

iali

zati

on

Delete

Device

X-Talk

HTTP Services

AutoGen Event Handlerf

h

i

nCreateDevice

q

CCM

IotTalk GUIl

g

Create

Simulator

p

X-Talk

URL

Config.

File

jc

Sensors 2020, 20, x FOR PEER REVIEW 7 of 19

234 Fig. 5. Web-based SimTalk GUI. 235

236 We also need to set up the parameters for IDF value generation, including its distribution (Fig. 5 237

(g)), the mean (Fig. 5 (h)) and the variance (Fig. 5 (i)). We note that the values of some IDFs have 238 ranges. For example, the relative luminance ranges from 0 to 128000. For this kind of IDFs, the 239 simulated distributions must be finite or truncated to produce the values in the ranges restricted by 240 the upper and the lower bounds. In this case, we need to fill the lower bound value (Fig. 5 (j)) and the 241 upper bound value (Fig. 5 (k)). 242

To reproduce the same simulation sequence, the SimTalk GUI allows the user to specify the 243 seeds for random number generation through the fields “Seed” (Fig. 5 (f) and (l)). The “Trace File” 244 field (Fig. 5 (m)) allows the user to download a recorded trace to conduct trace-driven simulation. 245 Note that IoTtalk records all sensor data of a real IoT application with timestamps in specified 246 periods and saved them in a trace file. Therefore, the user can upload the trace file through the 247 “Trace File” field. We can also perform distribution-fitting that translates the measured data in the 248 trace file to a Gamma distribution [22]. In [3][6][10][14][16], we have manually conducted 249 distribution fitting to make the simulation cases more valid. Implementation of automatic 250 distribution-fitting in SimTalk will be our future work. 251

After the IDF setup is finished, we click the “Save” button (Fig. 5 (n)) to close the window. The 252 SimTalk GUI passes the setup values to the SimTalk Event Handler, and the handler invokes the 253 Save Parameters procedure to save these values into the Sensors record in the SimTalk DB. 254

When the user clicks the “Simulation button” in the IoTtalk GUI window (Fig. 6 (a)), a page 255 jump occurs and the SimTalk GUI sends the “create simulators” instruction to the SimTalk Event 256 Handler. The handler forwards the request to the CCM through the AutoGen Subsystem. The CCM 257 queries the IoTtalk DB to retrieve the IDF parameter setups of all input devices in the SmartFarm 258 project. These parameter values are returned to the AutoGen Event Handler. By invoking the X-Talk 259 HTTP Services procedure, a response with these values is sent to the SimTalk Event Handler. The 260 handler saves the parameter values in the SimTalk DB and invokes the Query Parameters procedure 261 to send a response with these parameter values to the SimTalk GUI. 262

263 Fig. 6. Web-based IoTtalk GUI (cont.). 264

265 Based on the received parameter values, the GUI pops up a window illustrated in Fig. 7 to show 266

the status of each input device model. For SmartFarm, they are Sensors and Timers. The window 267

a

b

a

b

d c

Sensors 2020, 20, x FOR PEER REVIEW 8 of 19

indicates that the Sensors device model is currently bound to a real device (Fig. 7 (a)). Therefore, the 268 user can choose to keep the binding or unbind the real device and switch Sensors to simulation 269 mode by clicking the simulator radio button (Fig. 7 (b)). The Timers device model is not bound to 270 any real device, and the user did not set up the simulator parameters. Therefore, this device model is 271 always bound to a simulated device with default parameter values (fig. 7 (c)). 272

273 Fig. 7. Web-based IoTtalk GUI (cont.) 274

275 (2.3) Note that the user can fill multiple values in each of the parameter text boxes (Fig. 5 (d), (h), 276

(e), (i)), and then the SimTalk simulation will sweep on these values. Each set of the values is 277 executed for an observation period (Fig. 7 (d)). This feature is called parameter sweeping. If the 278 parameter sweeping mode is not selected (Fig. 7 (f)), then the simulation is only executed for the first 279 set of the values. We have designed the parameter sweeping feature for SimTalk and the 280 implementation will be our future work. 281

When the user clicks the “Save” button (Fig. 7 (g)), the SimTalk GUI sends the SimTalk Event 282 Handler a “save” request with a list of the input device model names selected as simulators. The 283 handler saves this list in the SimTalk DB, invokes the Create Simulator procedure (Fig. 4 (p)) to 284 generate the SA code of each simulated device (see Appendix B for the details) and request the 285 AutoGen Subsystem to create the simulator. The AutoGen Event Handler invokes the Create Device 286 procedure (Fig. 4 (q)) to create the devices for the simulator and sends a “bind device” request to the 287 CCM. The CCM binds these simulated devices to the SmartFarm project and the simulation of 288 SmartFarm is started. A successful response is sent from the CCM to the SimTalk GUI. If the 289 simulation fails, the GUI pops up a dialog window to indicate the simulation status. 290

The SimTalk Subsystem reuses all IoT device codes in the IoTtalk application and inserts 291 random number generators into the codes with the sleep() function. Furthermore, the interactions 292 between the input devices and the output devices in SimTalk are specified in the IoTtalk GUI (Fig. 3). 293 In this way, we guarantee that the IoT device interaction in SimTalk is exactly the same as that of the 294 real applications. 295

The created simulation code will be executed to conduct time-driven simulation by advancing 296 the real clock. That is, the time advancing mechanism of SimTalk simply follows the same 297 mechanism of IoTtalk. The progress of time in SimTalk is specified in the time interval field (Fig. 5 298 (c)-(f)), and the clock of each simulated IoT device is incremented with the time units (specified in 299 Fig. 7 (e)) through time advancing of real execution of IoTtalk. Therefore, SimTalk does not need 300 any event scheduler used in the event-driven simulation. In IoTtalk, the real clock is advanced by 301 the sleep() function in a sensor device. For example, if a temperature sensor periodically sends the 302

ab

c

d e

g

f

Sensors 2020, 20, x FOR PEER REVIEW 9 of 19

measured data in every 10 minutes, then the temperature code simply calls sleep(600) in seconds. If 303 we change the time unit from “minute” to “second” then SimTalk can simulate the application 60 304 times faster than the execution of the real application in IoTtalk. That is, the unit for the time 305 intervals can be set up so that the progress of time is much faster than the real device execution. In 306 SimTalk emulation, the time intervals of the simulated IoT devices must be specified exactly the 307 same as its real device counterparts. As another example, in our work on Elevator simulation and 308 emulation [23] [24], a real elevator car takes 3.46 seconds to move up/down one floor. In the 309 simulation, the movement of all simulated cars are delayed with the sleep() function for 0.00346 310 seconds. In the emulation, sleep() must delay for exact 3.46 seconds to synchronize the simulated 311 elevator cars with the real cars. 312

In a SimTalk application, if all IoT devices are simulated devices, then SimTalk conducts 313 simulation. If some IoT devices are real, and the remaining devices are simulated (i.e., the real 314 devices are mixed with the simulated devices), then SimTalk conducts emulation. If all IoT devices 315 are real, then SimTalk become IoTtalk to run real IoT applications. To switch between SimTalk and 316 IoTtalk, one simply clicks the “Simulation” button (Fig. 6 (a)). 317

In the time-driven simulation, special treatments are required to simulate the sensors with very 318 different frequencies. Suppose that we simulate N sensors with the sampling periods 𝑡𝑛, 1 ≤ 𝑛 ≤ N, 319 where the maximal period is 𝑡𝑀 and the minimum period is 𝑡𝑚. Then the time unit for sleep() is 320 selected such that the CPU speed of SimTalk is faster than the rate to handle the 𝑠𝑚 data at the 321 frequency higher than 1/E[𝑡𝑚]. If the variances of the 𝑡𝑛 distributions are not large, then the time 322 complexity of the execution for the time-driven simulation is about the same as the discrete-event 323 simulation. On the other hand, if the variance of 𝑡𝑚 is very large, then it is possible that within two 324 samples of 𝑠𝑀 , there is only one 𝑠𝑚 sample or more than 1000 𝑠𝑚 samples. In the former case, 325 SimTalk’s CPU will loop in 𝑠𝑀’s sleep() function for a long time. Therefore, in terms of the execution 326 time, the event-driven approach is typically more efficient than time-driven if the events occur with 327 high variance. Fortunately, in most IoT applications we encountered, the sensors produce data with 328 the intervals on the same order. In the future, we will investigate the IoT applications where the 329 events occur with very high variance, and to study how SimTalk can be modified to effectively 330 simulate such applications. 331

6. Simulating Output Devices 332

In Sections 3-5, we elaborated on how to create the simulator for the input devices. Basically, 333 these simulated devices are traffic generators that drive the IoT services for correctness investigation. 334 In particular, simulation results can provide useful suggestions to design physical devices for IoT 335 field trials. For an output device model, it is important that the simulation provides two types of 336 information: 337

1. The input values sent from the EC to the ODFs of the simulated output device, and 338

2. The results produced by the output device. 339 To produce the first type of information, SimTalk utilizes the “ODF monitor” in the IoTtalk GUI (Fig. 340 6 (b)). This monitor produces the values (Fig. 6 (c)) and their timestamps (Fig. 6 (d)) received by the 341 ODF. The ODF monitor is a good mechanism for debugging. Besides the raw data shown in Fig. 2 (c) 342 and (d), the data can also be illustrated in the statistics charts as shown in Fig. 8. 343

344 Fig. 8. The time series chart of the ODF monitor (from Lum-I to Light-O). 345

346

Sensors 2020, 20, x FOR PEER REVIEW 10 of 19

To investigate the second-type information, SimTalk also provides animated simulator for the 347 output device models. An example is the skeleton ceiling light that can change the shape and the 348 light color during the night and reflect the shadow of different geometric shapes in the floor (Fig. 9 349 (a)). The shape change is achieved through compression of the skeleton stalks with various angles 350 and sizes. Therefore, the Skelton device model has three ODFs: Angle-O, Size-O and Color-O. The 351 Skelton simulator is an animation program that reuses SA of its physical counterpart to illustrate 352 compression of the stalks of the skeleton with color change. The animated Skeleton simulator is 353 implemented in Java, which continuously draws the graphical skeleton patterns with specified ODF 354 values (Fig. 9 (b)). The implementation details are given in [5]. 355

356 Fig. 9. Sekeleton: (a) Geometric-shape shadow of Skeleton; (b) Shape change of the Skeleton 357

simulator; (c) Another implementation of real Skeleton device. 358 359 The Skeleton device is connected to a web-based controller with three IDFs. Every IDF is a 3×3 360 keypad. Color-I is a 9-color palette (Fig. 10 (c)). Angle-I is a 9-number keypad (Fig. 10 (d)) that 361 produces an angle of a decimal degree n when the n-th key is pressed, where n=10,20,…,90. Size-I is 362 another 9-number keypad that produces a size m when the m-th key is pressed, where 1≤m≤9. The 363 Skeleton configuration created through the IoTtalk GUI is illustrated in the right-hand side of Fig. 364 10. A user accesses the controller (Fig. 10 (a)) through the browser of his/her smartphone. Then 365 he/she can press the keypads to interact with the Skeleton device (Fig. 10 (b)). 366 367

368 Fig. 10. IoTtalk configuration for Skeleton. 369

370 When the controller is switched to the simulation mode, the Skeleton is driven by random 371

sequences of Angel, Color, and Size. In Fig. 10, we can add another Skeleton device model (called it 372 Skeleton2) bound to a newly built Skeleton C as illustrated in Fig. 9 (c). To ensure that Skeleton C 373 correctly duplicates Skeleton A in Fig. 9 (a), the simulated controller connected to Fig. 9 (b) is also 374

a b

c

Skeleton A

Skeleton C

Simulator

Color

Angel

Size

10 20 30

40 50 60

70 80 90

1 2 3

4 5 6

7 8 9

Angel-I

Color-I

Color-O

Angel-O

Size-O

Color-I

Size-I

a b

d

c

e

c

d

e

a

Sensors 2020, 20, x FOR PEER REVIEW 11 of 19

connected to Skeleton2. When the simulation (actually, emulation) executes the input sequences 375 produced by the simulated controller, we can observe if Skeleton C in has the same behavior as the 376 simulated Skeleton (Fig. 9 (b)). If so, Skeleton C has the same behavior as Skeleton A without any 377 operation on Skeleton A. 378

The results of output device simulation can provide useful suggestions to design physical 379 devices for IoT field trials. For example, in NCTU, the IoTtalk platform is used to implement the 380 water dance service in a fountain with the sprinklers and lights. Fig. 11 shows that 6 simulated light 381 bulbs are mapped to the lights under the water of the fountain. There are also 6 sprinklers and their 382 simulated counterparts. To simplify our discussion, they are not shown. After the water-dance 383 designer is satisfied about the control sequences of the lights and the sprinklers through the 384 simulation (typically controlled by the music), he/she can bind the real lights and sprinklers 385 through the IoTtalk GUI. 386 387

388 Fig. 11. The real lights and the simulated lights in the water dance application. 389

390 We can also use simulated output devices to investigate the behavior of an input device. This 391

feature is especially useful for physics experiments. Fig. 12 shows how the behavior of a pendulum 392 (Fig. 12 (a)) can be observed by its simulation counterpart (Fig. 12 (b)). 393

In Fig. 12, the bob of the pendulum is installed an acceleration sensor and a WiFi/Bluetooth 394 wireless module. The SA of the pendulum implements the IDF Acceleration-I. When the bob 395 swings back and forth, the bob sends the acceleration values to the IoTtalk server through WiFi or 396 Bluetooth. The IoTtalk server then links Acceleration-I to the corresponding ODF of an output 397 simulator that is a 2-D pendulum animation written in VPython. The SA of the simulated 398 pendulum uses the acceleration data to calculate the motion of the bob, and illustrate the bob 399 motion through real-time animation. The animation also indicates the relative height of the 400 pendulum. This feature is valuable because the bob position cannot be observed by the student’s 401 bare eyes from the real pendulum motion. 402

Sensors 2020, 20, x FOR PEER REVIEW 12 of 19

403 Fig. 12. Simulation of Pendulum. 404

405

7. Conclusions 406

In this paper, we designed and implemented SimTalk, the simulation mechanism for an IoT 407 application development platform called IoTtalk. We first elaborated on how to implement the 408 simulator for an input IoT device (a sensor). We used a smart farm application to show how the 409 simulator of sensors is used for correct implementation. Then we described how an output IoT 410 device (an actuator) can be simulated by an animated simulator. We used applications including 411 interactive art (skeleton art and water dance) and pendulum physics experiment as examples to 412 illustrate how IoT application behavior investigation can be achieved in SimTalk. A demonstration 413 video for SimTalk is available in [20]. The source codes for developing IoT DA can be found in [21]. 414

As the main outcome of this paper, the SimTalk simulation codes can be directly reused for real 415 IoT applications and vice versa. Furthermore, SimTalk is nicely integrated with the tool 416 BigraphTalk to formally verify the IoT application configuration. Such features have not been found 417 in any IoT simulator in the world. 418

There are three directions for SimTalk future development: 419 1. Enhancing BigraphTalk to provide better simulation code verification for SimTalk 420 2. Developing distribution-fitting feature in SimTalk to replace a measured trace by a fit Gamma 421

distribution 422 3. Implementing parameter sweeping to automate the execution of SimTalk with various values. 423 424

Author Contributions: Y.-W. Lin: Design and implementation of SimTalk, Y.-B. Lin: Writing and Review, T.-H. 425 Yen: Design and implementation of SimTalk. 426

427

Funding: This research was funded by the Center for Open Intelligent Connectivity from The Featured Areas 428 Research Center Program within the framework of the Higher Education Sprout Project by the Ministry of 429 Education in Taiwan, and Ministry of Science and Technology 108-2221-E-009-047, Ministry of Economic 430 Affairs 107-EC-17-A-02-S5-007. 431

432

Conflicts of Interest: The authors declare no conflict of interest. 433

434

Appendix A. Device Feature and Model Management 435

IoTtalk provides the Device Feature and Model Management page to create and manage the 436 device features and the device models. This page includes a “Device Feature” (DF) and a “Device 437 Model” (DM) button (Figure A1 (a)), the Device Feature Window (Figure A1 (b)) and Device Model 438 Window (Figure A1 (c)). When the “Device Feature” mode is selected in the toggle button (Figure A1 439

a

b

Sensors 2020, 20, x FOR PEER REVIEW 13 of 19

(a)) the Device Feature Window is activated, and the user can create a new or edit an existing device 440 feature. On the other hand, when the “Device Model” mode is selected through the toggle button, 441 the Device Model Window pops up to allow user to create and edit the device model. 442

443 Figure A1. Device Feature and Model Management Page. 444

445 Appendix A.1. Device Feature Management 446

To access the Device Feature Window, the user clicks the “Device Feature” button to the 447 “Device Feature” mode. 448

After the “Device Feature” mode is selected, the GUI displays two radio buttons for IDF/ODF 449 type selection (Figure A2 (a)). The IDF type is automatically selected as the default type, and IoTtalk 450 obtains all DFs for the selected DF type (Figure A2 (b)). The first item of the list is “add new 451 feature”, which can be clicked to create a new DF. The details are given in the next subsection. If the 452 user presses the ODF radio button (Figure A2 (a)), all IDFs in the “DF Name” list (Figure A2 (b)) are 453 replaced by all ODFs. 454

455 Figure A2. Device Feature Window. 456

457 To create a new device feature, the user selects the “add new feature” in the “DF Name” list 458

(Figure A2 (b)), and the GUI pops the DF Parameter module (Figure A3 (a)) in the Device Feature 459 Window. The rows of the DF Parameter module are created based on the number of the 460 DF-parameters (Figure A3 (b)). The default DF-parameter number is one. For each of the 461 DF-parameters, the DF Parameter module includes the Type (i.e., the data types such as float, 462 integer, string and so on; see Figure A3 (c)), the Min (minimal) and Max (maximal) values (Figure 463 A3 (d)) and the Unit (e.g., cm, m/s2 and so on; Figure A3 (e)). For an IDF, the Min/Max values are 464 the boundary for IoTtalk simulator (SimTalk) (Figure 1 (j)). For an ODF, if the Min/Max fields are 465 not filled, the ODF-parameters take arbitrary values without range limits. The user edits them 466 according to the characteristics of the ODF provided in the manufacture’s data sheet. For example, 467 the luminance value of the Light-O has the range [0, 500]. When the user clicks the “Save” button 468

Sensors 2020, 20, x FOR PEER REVIEW 14 of 19

(Figure A3 (f)), the GUI pops a dialog box for the user to input the name of the new device feature 469 (Figure A3 (g)). Then IoTtalk stores device feature information into the DB. 470

471

472 Figure A3. Device feature creation. 473

474 From the “DF Name” list, the user selects and edits an existing DF (e.g., Acceleration; Figure 475

A4 (a)). If the user modifies the DF-parameter number (Figure A4 (b)), the DF Parameter module 476 will be redrawn based on the new number. Then the user can edit the data type, the Min/Max 477 values and the unit of each DF-parameter. After the user has completed editing the device feature 478 and clicks the “Save” button (Figure A4 (c)), a dialog box pops up for the user to reconfirm the 479 modifications (Figure A4 (d)). The device feature name is shown in this dialog box, which allows 480 the user to rename the modified device feature by a new one. When the user clicks the “OK” button 481 (Figure A4 (e)) of the dialog, IoTtalk store the information the DB. When the user clicks the “Delete” 482 button (Figure A4 (f)), IoTtalk removes the device feature from the DB. 483

484 Figure A4. Device feature modification. 485

486 Appendix A.2. Device Model Management 487

To manage the device model, the user clicks the “Device Model” button to switch to “Device 488 Model” mode (Figure A5 (a)). Then the Device Model Window is popped up (Figure A5 (b)) 489 together with Device Feature Window (Figure A5 (c)). The device Model Window shows the “DM 490 Name” pull-down menu (Figure A5 (d)) which allows the user to select a device model. The first 491 item in the list is “add new model”. This item can be clicked to create a new model. The Device 492 Feature Window is also shown in the “Device Model” mode for the user’s benefit: the user may 493 need to know the details of a specific device feature when he/she is configuring a device model. 494

Sensors 2020, 20, x FOR PEER REVIEW 15 of 19

495 Figure A5. Device Model Window. 496

497 To create a new device model, the user selects the “add new DM” in the “DM Name” 498

pull-down menu (Figure A5 (d)), and the GUI pops up the DF module (Figure A6 (a)) and the 499 “Add/Delete DF” module (Figure A6 (b)) in the Device Model Window. The DF module lists the 500 IDFs (Figure A6 (c)) and the ODFs (Figure A6 (d)) of the device model. For a new model, the DF 501 module is empty initially. The “Add/Delete DF” module shows all IDFs (Figure A6 (e)) and all 502 ODFs (Figure A6 (f)). The user can add a DF to this device model through the “Add/Delete DF” 503 module. When the user selects a DF in the “Add/Delete DF” module, the DF is automatically 504 displayed in the DF module (Figure A6 (a)). After the user has selected all desired DFs for the 505 device model and clicks the “Save” button (Figure A6 (g)), the GUI pops a dialog box for the user to 506 input the name of the new device model (Figure A6 (h)) and IoTtalk create the new device model in 507 the DB. 508

509 Figure A6. Device model creation. 510

511 To configure an existing device model, the user selects that device model (e.g., Smartphone; 512

Figure A7 (a)) in the “DM Name” pull-down menu. IoTtalk retrieves the DFs of the device model 513 from the DB and the GUI pops up the DF module (Figure A7 (b)) and the “Add/Delete DF” module 514 (Figure A7 (c)). 515

To obtain more details of a DF, the user moves the mouse pointer over the DF name in either 516 the DF module or the “Add/Delete DF” module (e.g., Acceleration; Figure A7 (d)). IoTtalk obtains 517 the details of the selected device feature and the GUI shows them in the Device Feature Window 518 (Figure A7 (e)). In this way, the user can conveniently investigate the details of a DF selected in the 519 Device Model Window. 520

If the user wants to delete a device feature (e.g., Microphone) from the device model, he/she 521 clicks the DF item in the DF module (Figure A7 (f)), and this device feature is shown in the 522 “Add/Delete DF” module automatically. Then the user can unselect the device feature in the 523 “Add/Delete DF” module (Figure A7 (g)) to remove it from the device model. 524

Sensors 2020, 20, x FOR PEER REVIEW 16 of 19

To configure the tag parameter, each DF item in the DF module contains a pull-down menu 525 (Figure A7 (h)). Users can set different tag for each device feature of the device model. 526

527 Figure A7. Device model modification. 528

529 After the user has completed configuring the device model and clicks the “Save” button 530

(Figure A7 (i)), a dialog pops up for the user to reconfirm the modifications (Figure A7 (j)). The 531 device model name is shown in this dialog, which allows the user to rename the modified device 532 model by a new one. When the user clicks the “OK” button (Figure A7 (k)) of the dialog, IoTtalk 533 stores the information of the specific device model in the DB. On the other hand, when the user 534 clicks the “Delete” button (Figure A7 (l)), IoTtalk removes the device model from the DB. 535

(2.4) Appendix B. Creating the Simulation Codes 536

Automatic creation of the simulated devices is achieved by the Create Simulator procedure of 537 the SimTalk Subsystem (Fig. 4 (p)). We use the Sensors device as an example to show how the Create 538 Simulator procedure generates the SA code of the simulated Sensors device. We first note that the 539 parameters of an IDF are set up by SimTalk GUI (see Fig. 5) and are stored in a record of the SimTalk 540 DB (Fig. 4 (e)). Consider the luminance sensor (Lum-I) as an example. The format of the Lum-I 541 parameters are listed in Fig. B1, where v_paras (Lines DB.02-DB.9) describes the distribution for the 542 sensor value generation and t_paras (Lines DB.10-DB.15) describes the distribution for the arrival 543 time interval generation. 544

545 Fig. B1. The Lum-I parameter record 546

547

DB. 01. 'df_name': 'Lum-I',DB. 02. 'v_paras': [{DB. 03. 'dist': 'Gamma',DB. 04. 'mean': 50000,DB. 05. 'var': 20000,DB. 06. 'min': 0,DB. 07. 'max': 128000,DB. 08. 'seed': 357323DB. 09. }],DB. 10. 't_paras': {DB. 11. 'dist': 'Gamma',DB. 12. 'mean': 10000,DB. 13. 'var': 2000,DB. 14. 'seed': 141424DB. 15. }

Sensors 2020, 20, x FOR PEER REVIEW 17 of 19

The Lum-I and Hum-I parameter records will be used by the Create Simulator procedure. In 548 this procedure, Line 1 imports host (i.e., the IoTtalk server) and simulator (i.e., the simulator class 549 in the SimTalk DB) from the config file. Line 2 imports send_event and db_session from 550 event_handler (of the SimTalk Subsystem). The send_event function is used by the SimTalk event 551 handler to communicate with the AG Subsystem. The class db_session supports the ORM protocol 552 interface to query the records from the SimTalk DB. 553

554 Line 3 defines the procedure create_simulator() with one argument sim_name (Sensors in our 555

eample). Line 4 invokes the class db_session to query the IDF parameter record of sim_name from 556 the SimTalk DB (e.g., the record described in Fig. B1). 557

558 Line 5 creates a list sim_paras. Lines 6-27 obtain the sensor parameters (e.g., Fig. B1) from the 559

SimTalk DB and store them in df_config. The code details are omitted. Line 28 collects the 560 df_config records for Lum-I and Hum-I and saves them in sim_paras. 561

562

Lines 29 and 30 load the SA text code from the file sa.py. This code is a template for the simulated 563

device. Line 31 inserts host (i.e., the IoTtalk server), dm_name (i.e., Sensors) and the simulator 564

parameters sim_paras (generated in Lines 5-28) into the SA code. 565

566

Line 32 invokes the send_event function to instruct the AutoGen Subsystem to create the simulated 567

Sensors device. 568

569

Note that the SA text code in the sa.py file is 56-line long and the details can be found in [21]. 570 571

References 572

1. C.-S. Shih, J.-J. Chou, N. Reijers, and T.-W. Kuo, “Designing CPS/IoT applications for smart buildings and 573 cities,”IET Cyber-Physical Systems: Theory Applications, vol. 1, no. 1, pp. 3–12, 2016. 574

2. C. Dupont, P. Cousin, and S. Dupont, “IoT for aquaculture 4.0 smart 575 andeasy-to-deployreal-timewatermonitoringwithIoT,”in 2018 Global Internet of Things Summit (GIoTS), 576 June 2018, pp. 1–5. 577

3. Yi-Bing Lin, Hung-Chun Tseng, "FishTalk: An IoT-based Mini Aquarium System", IEEE Access, Vol.7, 578 Issue 1, pp. 35457-35469, December, 2019. 579

4. X.Li,R.Lu, X.Liang,X. Shen, J.Chen, and X.Lin,“Smart community: an internet of things application,” IEEE 580 Communications Magazine, vol. 49, no. 11, pp. 68–75, November 2011. 581

5. Yi-Bing Lin, Li-Kuan Chen, Min-Zheng Shieh, Yun-Wei Lin, and Tai-Hsiang Yen. CampusTalk: IoT 582 Devices and Their Interesting Features on Campus Applications. IEEE Access, Vol. 6, Issue 1, pp. 583 26036-26046, December, 2018. 584

3. def create_simulator(sim_name):4. sim_record = db_session.query(simulator).filter(sim_name)

5. sim_paras = []6.-27. /*query the SimTalk DB , to obtain the df_conf

records, the details are omitted*/28. sim_paras.append(df_config)

32. send_event('AG', 'create_device', sa_code)

Sensors 2020, 20, x FOR PEER REVIEW 18 of 19

6. W.-L. Chen, Y.-B. Lin, Y.-W. Lin, R. Chen, J.-K. Liao, F.-L. Ng, Y.-Y. Chan, Y.-C. Liu, C.-C. Wang, C.-H. 585 Chiu, and T.-H. Yen, “AgriTalk: IoT for precision soil farming of turmeric cultivation,” IEEE Internet of 586 Things Journal, pp. 5209–5223, 2019. 587

7. Lan-Da Van, Yi-Bing Lin, Tsung-Han Wu, Yun-Wei Lin, Syuan-Ru Peng, Lin-Hang Kao and Chun-Hao 588 Chang, "PlantTalk: A Smartphone-based Intelligent Hydroponic Plant Box", Sensors, 2019, 19(8), 1763. 589

8. Y. Sulema, “Mulsemedia vs. Multimedia: State of the art and future trends,”in 2016 International 590 Conference on Systems, Signals and Image Processing (IWSSIP), May 2016, pp. 1–5. 591

9. X. Xiao, P. Puentes, E. Ackermann, and H. Ishii, “Andantino: Teaching children piano with projected 592 animated characters,”in Proceedings of the The 15th International Conference on Interaction Design and 593 Children, ser. IDC ’16. New York, NY, USA: ACM, 2016, pp. 37–45. 594

10. W.-S. Lai, Yi-Bing Lin, Chung-Yun Hsiao, Li-Kuan Chen, Chao-Fan Wu and Shu-Min Lin, "FrameTalk: 595 Human and Picture Frame Interaction through the IoT Technology", Mobile Networks and Applications 596 Journal,First Online: 28 May 2019. 597

11. Yi-Bing Lin, Yun-Wei Lin, Jiun-Yi Lin, Hui-Nien Hung. SensorTalk: An IoT Device Failure Detection and 598 Calibration Mechanism for Smart Farming. Sensors. 2019 Nov; 19(21): 4788. 599

12. R.Milner, The Space and Motion of Communicating Agents. Cambridge University Press, 2009. 600 13. Archibald Blair, Min-Zheng Shieh, Yu-Hsuan Hu, Sevegnani Michele, Yi-Bing Lin, "BigraphTalk: 601

Verification Design of IoT Applications". DOI: 10.1109/JIOT.2020.2964026 602 14. Yi-Bing Lin, Yun-Wei Lin, Chun-Ming Huang, Chang-Yen Chih, Phone Lin. IoTtalk: A Management 603

Platform for Reconfigurable Sensor Devices. IEEE Internet of Things Journal, 4(5) 1552-1562, October, 604 2017. 605

15. Yi-Bing Lin, EduTalk demonstration, https://youtu.be/UCk9P3cJLkk 606 16. Yi-Bing Lin, Hung-Chun Tseng, Yun-Wei Lin and Ling-Jyh Chen, "NB-IoTtalk: A Service Platform for Fast 607

Development of NB-IoT Applications", IEEE Internet of Things Journal, Vol.6, Issue 1, pp.928-939, 608 February, 2019. 609

17. Yun-Wei Lin, Yi-Bing Lin, and Chun-You Liu, "AItalk: A Tutorial to Implement AI as IoT Devices", IET 610 Networks, Vol. 8, Issue 3, pp. 195 - 202, 2019. 611

18. Yun-Wei Lin, Yi-Bing Lin, Chun-You Liu, Jiun-Yi Lin, Yu-Lin Shih, "Implementing AI as Cyber IoT 612 Devices: The House Valuation Example", IEEE Transactions on Industrial Informatics, Vol 16, Issue 4, 613 pp.2612-2620, 2020 614

19. Hussain, S.; Mokhtar, M.; Howe, J.M. Sensor Failure Detection, Identification, and Accommodation Using 615 Fully Connected Cascade Neural Network. IEEE Trans. Ind. Electron. 2014, 62, 1683–1692 616

20. Yi-Bing Lin, Simulation demonstration, https://youtu.be/EHVdq68QteU 617 21. IoTtalk, IoTtalk Learning Kit. 2020, http://liny.csie.nctu.edu.tw/#IoTtalk 618 22. Averill M. Law, "How the ExpertFit distribution-fitting software can make your simulation models more 619

valid." Proceedings of the 2011 Winter Simulation Conference (WSC). IEEE, 2011. 620 23. Lan-Da Van, Yi-Bing Lin, Tsung-Han Wu, Yu-Chi Lin. Green Elevator Scheduling Based on IoT 621

Communications. IEEE Access, Volume: 8, Issue: 1, Page(s): 38404-38415, DECEMBER 2020. 622 24. Lan-Da Van, Yi-Bing Lin, Tsung-Han Wu, Yu-Chi Lin. An Intelligent Elevator Development and 623

Management System. Accepted and to appear in IEEE Systems Journal. 624 25. Giancarlo Fortino, Wilma Russo, Claudio Savagliom, "Agent-oriented modeling and simulation of IoT 625

networks", 2016 federated conference on computer science and information systems (FedCSIS). IEEE, 626 2016. 627

26. Xuezhi Zeng, Saurabh Kumar Garg, Peter Strazdins, Prem Prakash Jayaraman, Dimitrios Georgakopoulos, 628 Rajiv Ranjan, " IOTSim: A simulator for analysing IoT applications", Journal of Systems Architecture, 629 Vol.72, pp.93-107, January, 2017. 630

27. Philipp Wehner, Diana Göhringer, " Internet of things simulation using omnet++ and hardware in the 631 loop", Components and Services for IoT Platforms, pp.77-87, 2017. 632

28. Isaac Lera, Carlos Guerrero, Carlos Juiz, "YAFS: A simulator for IoT scenarios in fog computing", IEEE 633 Access, Vol. 7, pp.91745-91758, 2019. 634

29. Maxim Chernyshev, Zubair Baig, Oladayo Bello, Sherali Zeadally, " Internet of things (iot): Research, 635 simulators, and testbeds", IEEE Internet of Things Journal, Vol.5, Issue 3, pp. 1637-1647, 2017. 636

30. Gabriele D'Angelo, Stefano Ferretti, Vittorio Ghini, "Simulation of the Internet of Things", 2016 637 International Conference on High Performance Computing & Simulation (HPCS). IEEE, 2016 638

https://youtu.be/EHVdq68QteUhttp://liny.csie.nctu.edu.tw/#IoTtalk

Sensors 2020, 20, x FOR PEER REVIEW 19 of 19

639

© 2020 by the authors. Submitted for possible open access publication under the terms

and conditions of the Creative Commons Attribution (CC BY) license

(http://creativecommons.org/licenses/by/4.0/).

640