Scalable Incident Reporting Framework: A Sensor and IoT Research

The Internet of Things (IoT) is one of the most rapidly emerging technologies. It is observed that while many devices/machines get connected in an application, it is a challenge for the IoT application designer to keep the application scalable. Scalability is the ability of a device/application to adapt to the changes in the environment and meet the changing needs in the future. The paper presents a layered IoT architecture and discusses issues related to the scalability of each layer. The best open-source technologies are explored. A novel system architecture of a scalable IoT framework is conceptualized in this paper. An application covering vehicle accident reporting is designed with the proposed framework. The application is tested in real-time using the standalone hardware and its ability to report the incidents is confirmed. The scalability metrics of the proposed framework are evaluated and the results are reported


I. INTRODUCTION
Scalability refers to the ability of an application or a computing process to work with ease at varying capacities of increased or decreased inputs and outputs.During the recent years the IoT technology has revolutionized the communication between physical devices, making computers sense information without human intervention.The number of devices that are getting connected is ever-increasing, along with the volume of data being processed.One of the estimations suggests that the number of devices ("Things") that would be connected by 2025 is going to be around 30.9 billion [1].Therefore, as the number of devices to be handled increases, an IoT application that is developed to handle a particular number of devices will become inefficient or obsolete sooner or later.In order to design any IoT application, it is important to consider current and future workloads, data volumes, number of sensors, security patches, network traffic, etc. [1][2][3][4][5].What works in the small scale should also work in the large one.However, achieving this is a very challenging task.In this paper, the dimensions of IoT scaling are investigated and a case study on accident management using IoT is presented.

II. UNDERSTANDING IOT SCALING
In order to understand IoT scaling, the basic IoT reference model needs to be revisited (Figure 1).There are 7 conceptual layers in any IoT application.Layer 1, is the perception layer, which consists essentially of sensors and the associated hardware.With the booming areas of application of IoT, including agriculture, healthcare, industrial manufacturing, smart homes, offices, cities, and many more, the number of sensors in the perception layer is always growing.Also, already wired sensors are going to be replaced by upgraded versions.Any performing IoT infrastructure must be able to accommodate these developments in the perception layer by properly recognizing device registry and functionality.Vertical scaling refers to incorporating a better version of the device with more capacity and horizontal scaling refers to incorporating more of the same devices in the system [1,6].Layers 2 and 3 are basically communication and computing layers.The most important component of this network layers is the Gateways.Gateways moderate control and data between the endpoints of IoT devices and the edge/cloud [6,7].Important parameters such as the amount of data processing expected per device, frequency of data collection, and the types of analytical results expected are to be considered while choosing the gateways for IoT scaling.Gateways that provide multiple internet access (Ethernet, Wifi, global/ 3G/4G/5G/LTE) are preferred in this layer.The gateways that are compatible with rich mainstream protocols (such as MQTT, HTTP, Zigbee, LoRaWAN, Modbus) are best suited to make this layer scalable [6].The IoT layered reference model.
Layers 4 and 5 are basically data storage layers.The biggest challenge for scalability in databases is their "cardinality".Cardinality is the number of possible values in a database.A typical IoT deployment produces millions of values.For example, an IoT deployment with 5000 devices, each device having 100 sensors across 100 warehouse results in database cardinality of 5 millions and the number of tables goes on increasing.The table structure is not fixed.In order to address such scenarios, data storage must be carried out in a nontraditional way.No SQL databases or key-value pair databases fit into this.Zigsaw, Influx, Riak TS, mongoDB [8] are some of the preferred databases to make IoT scalable in this layer.Layers 6 and 7 provide a picture of the growing application users and the applications themselves.
Sectors such as agriculture, health, industrial manufacturing, hospitality, finance, transportation, and education have started using the benefits of IoT technology to make smart homes, smart cities, and smart life in general.These observations suggest that during IoT application development, scalability is an important factor to be considered.In this paper, a framework for designing a scalable application is discussed.

III. BACKGROUND AND RELATED WORK
In the past, in order to scale IoT applications, many different architectures have been proposed.The most important among them are cloud-based architectures, fog-based architectures, and, edge-based architectures [1][2][3].The cloud-based technology is used in [2].In this technology, every input data from the sensors has to reach the distant servers for processing.As billions of IoT applications keep sending data to the cloud servers, the server becomes heavily loaded and there will be delayed response.In [10], a kind of modification was done for the cloud approach and small capacity servers were dynamically triggered as middle nodes in the cloud.These dynamic middle nodes were named "fog servers" [9].Experimental results in fog computing showed that the system performance is not always improved and may become worse sometimes [10].In [11,12] edge/cloud computing methods were used.In edge computing, instead of sending the sensor data to distant servers, they are processed in a machine nearest to the source (a machine at the edge of the network).This approach in edge reduces the latency and improves the IoT response time.The major players in contributing IoT scaling are Microsoft Azure, Amazon Web Services (AWS), and Google cloud [6,8,9,13].However, all these platforms follow the pay-as-you-go pricing model.In view of the needs of researchers and developers, an open-source scalable IoT framework is required.InciComm, is an open-source scalable IoT framework that is based on microservice architecture and provides improved performance.The following sections present the system architecture of the proposed InciComm scalable IoT framework.It is used to implement business rules and behavior of the use case application.The rule engine helps to map hardware pins as input and outputs during the design.Third-party services such as AWS can be included using a plugin module.As and when new devices/sensors arrive, they will be registered and the application starts performing as per the business rules specified in the rule engine.Thus, rapid development is aided by this scalable architecture.

IV. SYSTEM ARCHITECTURE
InciComm architecture is shown in Figure 2. The system architecture consists of components such as a gateway communicator, authenticator, and API modules.The system architecture contains an IoT broker module supporting MQTT, HTTP, Websockets, and CoAP protocols [6,8].The broker is an important module that acts as an interface between the input device (publisher) and the output (subscriber) device.A separate module called the device registry module exists to register the identified device with its device ID, authentication captcha, and other attributes.The architecture supports SQL and NoSQL databases, including SQLite, InfluxDB, MongoDB, and Riak T. In order to record, device metadata such as sensor type, units of data collection, etc., a metadata event manager module is included.The shadow module creates a persistent virtual version of the real device.Device shadow helps application development using REST APIs.The rule engine is another important component.It is used to implement business rules and behavior of the use case application.The rule engine helps map hardware pins as input and outputs during the design.Third-party services such as AWS cloud services can be included using a plugin module.As and when new devices/sensors arrive in the applications, they will be registered and the application starts performing as per the business rules specified in the rule engine.

V. REAL-LIFE USE CASE
Figure 3 shows the use case diagram of the application.In this use case, it is intended to use the framework to design an application that reports vehicle accidents in real-time [14,15].Device installation, application registration, authentication, sending notifications, identifying the nearest rescue responders, and identifying false positives to close the event cycle are some of the important use cases in the design.Haversine's algorithm [15,16] is used to find the nearest best location of the rescue responders.The flow of the application starts with the user installing the hardware on the vehicle and registering in the App.The user provides information about device ID, customer ID, car/vehicle ID, service ID, mobile numbers, etc.The system authenticates and sends an email with a valid username and password credentials to log in and use the application.The application becomes active automatically whenever the vehicle starts moving or is made active manually.The active device streams heartbeats to the server.The system is designed in such a way that it reports only the worst-case scenario (i.e.accident).The broker is programmed to provide QoS 1 [17].A time series with an unstructured database schema is used to store the streaming data.The vehicle health messages however are published (sent) at phased intervals as required by the user service demands.The mounted hardware prototype is shown in Figure 9 and App instances in Figure 10.

VI. IMPLEMENTATION DETAILS
This section provides a high-level description of the implementation of the use case in the InciComm IoT platform.As a proof of the concept, the implementation is carried out using a Raspberry Pi mounted with sensors.The hardware connectivity schema and the actual circuit are shown in Figures 4 and 5, respectively.Three types of sensors were used to sense events such as an accident.The sensor HC-SR04 for distance measurement (S ), the sensor MP6050 for sensing abnormal gyrometric changes (S g ), and the sensor B081V6FLG1 [18,19] for sensing fire occurrences (S f ).An accident (A) is defined as a combined abnormal output of these sensors: If S d becomes zero at any time, it signals an incident of touch/impact.The intensity peak at the time of reduced distance indicates the accident.The gyroscopic parameter Sg measures the tilt in the planes and S f signals the occurrence of fire/sudden rise in temperature.The accident parameter A is calculated based on the majority vote of S d , S g , and S f .Fig. 5.
Accident reporting hardware with Raspberry Pi and sensors.

Node-red rule engine flow
A Python [8] script to sense the sensor data on board the raspberry Pi was written, tested, and saved in a file.The program reads these sensor inputs and computes the accidentreporting parameter.An InciComm account is used to log in to the IoT platform.Devices are created in the framework by using device palletes and linking the device ID with the customer ID, access tokens, and service ID details.Node-red is used as a rule engine (Figure 6) to map the Raspberry Pi pins and other hardware.A dynamic MQTT broker is used to publish and subscribe messages in the cloud/edge networks.Any number of devices can be scaled up and down in the system using this broker.Figure 7 shows the scalable application development block diagram of the framework.

VII. EXPERIMENTAL RESULTS
Initially, simulations were conducted using Node-red and MQTT broker.Three hypothetical cars were used.The payload and topics are shown in Figure 8.The MQTT server offers three QoS levels, i.e.Q0, Q1 and Q2 [17].Tests were conducted using Q0.The pay loads (messages) were exactly received for the respective topics.The messages were streamed at intervals of 10s and the broker was found to be working properly.Figure 10 shows instances of these simulations.As a second experiment, a real-time hardware device was mounted on an experimental car and its locations were traced on the carApp.At different locations, the experimental car was made to crash/tilt and the coordinates of the accident spots were shown on the map.The application was able to send to the nearby rescue responder (police and hospital) successfully.

VIII. DISCUSSION
The objective of this research was to provide a scalable IoT platform for designing IoT applications.A case study of an IoT application for reporting vehicle accidents was designed using the proposed scalable platform and its scalability was tested.The scalability tests and measured values are reported in Table II which lists the Key Performance Indices (KPI's) and the measured values.
Scalability testing is conducted in order to know the response of the system when there are workload variations.In this proposed testing, Assetto Corsa Competizione (ACC) simulations [20] are used and 5 scalability metrics are evaluated (Table II).Device provisioning rate defines the number of devices that can come in into the service of IoT application [19,21,22].A total of 200 devices per second are reported.Over The Air (OTA) update rate is found to be 40.The number of messages that are ingested into the system is 1000 messages per second.The number of messages that fail to reach their subscribers is measured by message failure rate metric and it is found to be 0.2%.The message latency or delay in reaching its subscriber is less than 40 millisecond seconds.

IX. CONCLUSIONS
In this paper, a scalable IoT framework is discussed along with an applied use case on accident reporting.The proposed framework allows the dynamic discovery of devices and data management.The proposed solution offers scalability with respect to the device deployment, number of users/inputs, and computing environment.A selected list of scalability metrics was evaluated and the scalability of the proposed framework is confirmed.The paper discussed a case study application to accident reporting and demonstrated the development and testing of the same using the proposed framework.In future work, the case study application itself needs to be improved with improved accident parameter definition.The scalability of the framework needs to be tested with the deployment of different applications other than the current case study application deployment.

Fig. 3 .
Fig. 3.Use case diagram of an accident reporting system.

Fig. 4 .
Fig.4.PIN details and connection diagram using the Raspberry Pi.

Fig. 8 .
Fig. 8. Payload and topic arrivals in hypothetical car tests.

Fig. 10 .
Fig. 10.Instances of real-time App usage and location tracking.

TABLE II .
IOT SCALABILITY METRICS