SofiaKouah kouahs@yahoo.fr RELA(CS) Laboratory University of Larbi Ben M'Hidi
Oum El Bouaghi Algeria
Ilham KITOUNI MISC Laboratory
Constantine
Abdelhamid Mehri University
Algeria
8633304D8DA72072C4F0ABEE4DBAE6C3 GROBID - A machine learning software for extracting information from scholarly documents Internet of Things IoTAA Fault diagnosis Multi-agents systems Healthcare monitoring Arduino

Internet of Things (IoT) is an advanced research area which provides deeper automation, analysis and integration of physical world into computer systems through network infrastructure. It allows interaction and cooperation between a large variety of pervasive objects over wireless and wired connections, in order to achieve specific goals. Since IoT systems present several properties such as distribution, openness, interoperability and dynamicity, their developing presents a great challenge. For that reason, a generic, multi-layer and agents based architecture for IoT systems has been proposed, called IoTAA (Internet of Things Agents Architecture). IoTAA is composed of four layers; each layer maintains and schedules special features, such as connectivity and communication between things, local coordination, global coordination, domain dependent functionalities. On the other hand, Diagnosis of the IoT systems is an important issue which aims to detect abnormalities from the system desired behavior, identify the failure causes and localize failure components. Accordingly, the paper aims to show the efficiency of IoTAA for modeling IoT diagnosis problem. The four layers are developed and furthers processing are proposed. The proposed IoTAA based diagnosis architecture is illustrated by an example of healthcare monitoring.
Introduction

Nowadays, Internet of things (IoT) is becoming a promising technology which can modernize and simplify our daily life style. Moreover, it provides a concise integration of the physical world into computer systems through network infrastructure. It sees a huge number of internet enabled devices that can network and communicate with each other and with other web-enabled gadgets. IoT refers to a state where Things (e.g. objects, environments, vehicles and clothing) will have more and more information associated with them and may have the ability to sense, communicate, network and produce new information" [Gil16]. IoT systems are widely open, dynamic and need large amount of communications, interactions and data exchanges that should be achieved in a coherent manner. An IoT system is consisting of heterogeneous physical and virtual connected components, using different languages, platforms and intelligent policies [Int15]. In fact, interaction allows limitless possibilities for objects to control and access their environment and compensates for a lack of selfsufficiency. Connected to the internet, things acquire intelligence since they tap into an exceedingly rich environment [Weg97]. According to these properties, the design domain of IoT systems is becoming increasingly attractive; as several IoT functionalities have to be modeled. While, developing IoT system is an innovative field for the imminent future of computing and communication, the development of efficient IoT systems still facing many challenging issues. Several approaches have been proposed in the literature, among others

[Kat08] [Kaz09] [Che10] [For12] [Aya12] [Cha18]

. These approaches are application domain dependent and do not take into account almost IoT systems functionalities and properties. In particular, they do not support the intelligent feature which is important to manage and control properly the objects' traffic flow and improve decision making. Recently, an alternative approach has been proposed, called IoTAA for Internet of Things Agent Architecture [Kou18]. It focuses on the Multi-Agents System (MAS) paradigm and on the principle of separating responsibilities. MAS is an efficient paradigm which considers IoT systems characteristics (i.e. distribution, heterogeneity, intelligence …etc.) and models its behaviors in wellstructured manner with respect to its functional requirements and global coherency [Kou18]. IoTAA architecture is structured in four layers: three horizontal layers and a transversal layer. The first one is a smart layer that ensures connection and communication between things and the system. The second one constitutes the intelligent core of the system which ensures local coordination and provides internal functioning. The third layer ensures coordination between the local system and the externals ones. The transversal layer provides domain dependent behavior and users interface. The intelligent aspect is ensured by means of MAS intelligence feature. Each layer is scheduled and maintained by a set of particular agents which interact together to achieve their goals. On the other hand, fault diagnosis is an important issue for developing IoT systems especially that are made up of heterogonous and distributed physical and virtual components. Since these components are strongly coupled, a failure that occurs in a given component can propagate to others with respect to the existing relationships. This can have disastrous consequences on the IoT system functioning. Accordingly, developing fault diagnosis is an important issue for improving system maintenance activities [Kos03]. In other words, their reliable execution is an important design concern. Considering the distributed aspect of the IoT system and the nature of handled information related to the usual observations and the expected system descriptions, the proposed methods [Kat05] suffer of an overall view state of the system which influences greatly diagnosis quality. From diagnosis view point, it is quite difficult to obtain concise and correct results from a centralized diagnosis process. On the other hand, a completely distributed diagnosis solution converges generally to incoherent and imprecise results. Thus, combining both alternatives gives rise to an appropriate and efficient answer, that is, diagnosis process should be semi centralized. Our contributions twofold:  First, the IoTAA-based diagnosis approach is proposed. The choice of this IoTAA fits IoT diagnosis problem requirements. The four layers are refined and fault diagnosis is introduced.

 Then, implementation issues are illustrated through an example (healthcare monitoring system). This paper is structured as follows: Firstly, section 2 provides the necessary background allied to our subject, mainly the IoT system, diagnosis and IoTAA Architecture. Next, section 3 introduces the proposed approach. Section 4 discusses some implementation issues and provides a case study dealing with diagnosis of a IoT based healthcare monitoring system. Finally, Section 5 concludes the paper and gives prospects to be continued in the future.

Background
Internet of Things

This section reviews some IoT properties, applications and challenges. IoT system is "a system of interrelated computing devices, mechanical and digital machines, objects, animals or people that are provided with unique identifiers and the ability to transfer data over a network without requiring human-to-human or human-to-computer interaction" [Mar14]. The main feature of IoT systems is the pervasive presence of a variety of connected things or objects, such as: sensors, actuators and Radio-Frequency IDentification (RFID) tags, etc. These objects are able to interact with each other and cooperate with their neighbors to reach common goals. IoT systems present numerous properties and functionalities, such as:  openness, distribution, dynamicity and interoperability;  possibility to interconnect small devices and computers to the Internet in cheaply and easily manners by means of uniquely identifiable IP (Internet Protocol);  capabilities of sensing and actuations, embedded intelligence and communication;  self-configurability and ubiquity. Examples of IoT systems can cover practically numerous real world applications, they goes beyond the following field: Smart home, wearables objects, connected cars, Smart cities, Smart retail, Smart farming, etc. Although IoT is promising research area, it is lacking of experimentation for modeling and carrying out IoT systems. Hence, some challenging issues should be pinpointed such as: privacy and security, power consumption, analyzing and managing real-time data, resource constraints and QoS supports, Data storage (Big Data issues), standards and connectivity (Protocols, Norms, and Platforms).

Diagnosis

Fault diagnosis is usually integrated into the largest framework of monitoring, supervision and maintenance. Generally, fault diagnosis can be defined An important remark should be highlighted, which concerns fault diagnosis: in this paper, we are concerned by the third point (i.e. global diagnosis strategy). We assume that the system is diagnosable. An ongoing paper addresses the representation model and its allied reasoning algorithm that are Fuzzy Logic based. The horizontal layers ensure management of physical components and the coordination between the different parts of the system. However, the transversal one takes in charge the responsibility to assign and achieve the further suitable functioning for horizontal layers with respect to the application domain, system requirements (i.e. desired behavior) and layer nature. Furthermore, this layer interfaces the application with the potential users and participants. For more details, reader can refer to [Kou18]. responses). Each AoT has its own library which assists and resumes its behavior. Such decision doesn't require any reasoning capability. It consists of determining the suitable course of actions and the required interaction to perform the desired behavior. This sub module decides the relevant data to be stored (i.e. locally or on the cloud).  Internal Interaction Management: ensures internal interaction management between the AoT agents together and with LCA agents.  Action: After deciding about the adequate actions to be carried out, AoT acts upon its environment through its actuators. AoT's Knowledge Base includes behaviors for analyzing, controlling and storing IoT data. It is also enhanced by further knowledge which is related to the fault diagnosis (i.e. KB sop ). Things, sensors and actuators should be assigned to the different AoTs. Device assignment could be done with respect to particular parameters related to them, such as their nature, geographic location and functioning capabilities. For instances, things of the same kind could be controlled by the same AoT. Also, things, actuators and sensors located in the same region could also be managed by the same AoT.

Internet of Things Agent Architecture
Proposed Approach
Local Coordination Agent (LCA)

LCA is a deliberative agent which intends to manage and control internal behaviors of the system. LCA internal architecture is depicted by

Global Coordination Agent (GCA)

GCA is a deliberative agent which aims to manage and control social behaviors of the system. GCA internal architecture is depicted by between IoT MAS and the potential users; For instance responding to user request, showing the result, making suggestions and giving advices. It supports and provides an active assistance to users. In other words, it does not represent a simple interface between the application and users, but it contributes with them to a collaborative process for performing desired behavior.

Concerning Interface Agent structure, we admit that it could be implemented differently with respect to users' preferences and designer's requirements. Thus, we make a full abstraction about its internal architecture. This agent interacts with other agents in order to transmit requests to the concerned part in the system or to acquire the needed information that assist users. In this section, we outline the main design stepwise. The main goal of this application is to achieve an easy handheld healthcare on monitoring diabetic via breath. a) Description of medic standing and the underlying scientific phenomenon It's well known that when the body has too little insulin, it means that the cells of the body cannot take enough sugar (glucose) from the blood. So, ketones which are chemicals appear in the body when the body fat is used for energy instead of glucose. Acetone which is part of ketone bodies; is an acidic substance, naturally occurring in very small amounts in blood and urine. These substances are normally made by the body from fat and eliminated in the urine. However, they sometimes accumulate in the body, which can no longer eliminate them completely. Acidification of the blood occurs and is referred to as ketoacidosis. This acidification is toxic and can lead to disorders that can go as far as coma [Vee04]. It's also a serious complication of type 1 diabetic mellitus called a diabetic ketoacidosis (DKA). Acetone is known as a biomarker of diabetes [Wan10], and breath acetone concentration is reported to be elevated in type 1 diabetes mellitus, and it can be used to diagnose the onset of diabetes [Den04]. Therefore, measuring of Acetone level can help controlling and monitoring the diabetic patients' condition as the large number of ketones means diabetes is out of control. b) Description of the developed prototype device "Diab-check" The prototype device called "Diab-check" consists of a hardware and software as an Internet of Things (IoT) system for breath test to monitor the condition of diabetic patients. The monitoring device for ketone level by using breath measurement (See Figure 6) is constructed and the required software is developed by the team in computer science laboratories and medical research laboratory LR2M, university of Constantine, Algeria. It is presented by the logo " ". The patient breath into the prototype, thus the level of the acetone is measured, the value is adjusted by using ambient humidity and temperature degrees, the result are displayed in an LCD, sent to a mobile application and stored in the control system data base. Thus, the whole system controls the Acetone level in the breath. Such system can be helpful for different users such as Diabetic patients, patient assistant and health practitioners for patients monitoring. Accordingly, it can be used or enriched by additional features for health automation (Smart healthcare). Effectively for detecting breath acetone we use FIGARO TGS822 gas sensor. The acetone level is in unit of mmol/l, so the value of the sensor which reads in the unit of PPM must be converted to mmol/l by taking the molar weight of acetone which is 58.08. The stability of the gas sensor is depending on the value of ambient humidity and temperature. Based on the data sheet, gas sensor is stable at around 60% humidity and 28-29ºC. Thus, the two parameters should be included, therefore we use DHT11 sensor, so that the concentration of the acetone gas can be determined. Concerning microcontroller and communication technology hardware, we have used, respectively, Arduino Uno and GSM module. In addition, other materials are used such as: USB cables, LEDs, Breadboard, Connection wires, Resistances, etc...These materials are depicted by Figure 7. Components. Connection of these components is made up on Breadboard and is illustrated by Figure 8. The program that controls sensors and ensures data transmission between sensors, mobile and server applications is implemented by means of Arduino Software [Ard18] which is fully rewritten in C language. First, the code should be uploaded into the Microcontroller. After that, the sensors communicate the corresponding data to the mobile application via GSM sensor. In turn, these data are transmitted to the server application and displayed on LCD. Mobile application on Smartphone is implemented under Android platform (Figure 9).

as a process of three complementary tasks: fault detection, fault isolation and fault identification [Muc05]. These tasks are defined hereafter.  Fault detection: it consists in deciding whether the system works in normal conditions or whether a fault has occurred. It is a logical operation whose answer must be true or false.  Fault isolation: it is triggered whenever fault has occurred. It aims at localizing the potential components causing the fault.  Fault identification: it intends to identify the nature of the fault. In other words, it analyses specific faults parameters among others its size, criticality and significance. The fault detection operates on desired behavior model whereas both fault isolation and identification involve a faulty system behavior model under the considered faults. Topics concerning fault diagnosis field point toward several aspects and issues, among others:  The representation model of the behavior and diagnosis process.  The reasoning model (i.e. algorithm) and the associated decision making process which should comply with the representation model.  The global diagnosis strategy and the corresponding system architecture.  The consideration of some particular aspects and characteristics of the system being to be diagnosed.  The ontological structure which describes the different faults concepts and their relationship.  System diagnosability.
IoTAA [10] is multi-layer architecture (See Figure 1); it aims to provide a general framework for developing IoT systems. It is made up of four layers, structured into three horizontal layers; named respectively: Physical Component Management Layer, Local Management and Coordination Layer and Global Management and Coordination Layer; alongside a transversal layer, called Specialized Operative Management Layer.
3.1. IoTAA Diagnosis Architecture Our IoTAA based diagnosis architecture is structured as follows:  Physical Component Management Diagnosis Layer (PCM-D): is the lower horizontal layer. It monitors, manages and controls the IoT infrastructure. It is directly related to the IoT systems sensors, actuators, tags, smart devices and other terminals. PCM-D ensures the following functionalities: perception, communication and connection between things, devices and agents. Also it enables achieving management and control of IoT resources by providing local fault diagnosis, taking the adequate decision and acting accordingly in realtime. Agents of this layer are named Agents of Things (AoT). PCM-D layer interacts directly with LMC-D layer.
Figure 1 :Figure 1: Internet of Things Architecture [Kou18].  Local Management and Coordination Diagnosis Layer (LMC-D): it represents the middle layer. LMC-D ensures management of collective intelligent behavior that requires a particular decision making and enables coordination between the local agents in order to achieve a global fault diagnosis of the local system. Such responsibility can be achieved by using sophisticated protocols and exploiting information delivered from the PCM-D layer. Agents of this layer are named Local Coordination Agent (LCA). LMC-D layer interacts directly with both PCM-D and GMC-D layers. PCM-D and LMC-D layers constitute
Figure 2 :Figure 2: Class Diagram of IoTAA-D Diagnosis System.  Specialized Operative Management Diagnosis Layer (SOM-D): is deliberative layer. It models the additional functionalities that should be taken into account by the system. It depends on the functioning requirements, desired behavior and system's application domain. SOM-D transverses the horizontal layers by assigning and modeling, at each level (i.e. Layer), the suitable functionalities; with respect to horizontal layer nature and its requirements. Such assignment and modeling are done during MAS design process; they are specialized operational functions. The main SOM-D's functionalities are fault diagnosis
Figure 3 :Figure 3: Agent of Things Architecture.
Figure 4. It is structured into five components: Perception, Reasoning and Decision Making, Interlayer Interaction Management, Partial Global Diagnosis and Action.  Perception: consists of gathering and extracting relevant data from the basic layer (i.e. PCM-D layer) and its own sensors. Recall that terminals concerned by IoT system are directly connected to AoTs.  Reasoning and Decision Making: it is the core intelligent component of LCA. The designer should specify and model an adequate reasoning mode such as logic based reasoning, cases based reasoning, theorem prover, fuzzy reasoning, etc. Such choice depends on designer viewpoint and its adequacy with the application nature. The reasoning process is followed up by a decisionmaking process which is based on the reasoning process results.  Global Diagnosis: it represents the internal intelligent desired behavior that should be specified by designer as stated above. The specialized operative internal function should implement a reliable diagnosis mechanism which is based on the local diagnosis results of the involved IoT agents.  Interlayer Interaction Management: Particular protocols should be specified in this component which concern interaction between AoTs, LCAs and GCAs involved in the same IoT MAS. Standard protocols such as contract Net [Smi80], Message Queue Telemetry Transport (MQTT) [Tra09] can be reused or new ones could be proposed.  Action: After deciding about the adequate actions to be carried out, LCA acts upon its environment through its own actuators.  KB int is the internal knowledge base that includes local knowledge manipulated over LMC-D layer.
Figure 4 :Figure 4: Local Coordination Agent architecture.
Figure 5. It is structured into five components: Perception, Reasoning and Decision Making, Social Interaction Management, Meta Diagnosis and Action.  Perception: it aims at collecting relevant realtime data and detecting environment changes issued from its own sensors. The particularity of such data is that it concerns both local data and social relationship with external parts. Perception component communicates periodically the sequence of perceived Data to Decision Making component.  Reasoning and Decision Making: it intends to deliberate the appropriate course of actions that can achieve agent's goal. The designer should implement an adequate reasoning mode by taking into account system's external interactions. In the same way as LCA, the reasoning process of GCA is followed up by a decision making process. The knowledge base KB s is made up of social knowledge that can be distinguished into two categories: knowledge related to fault diagnosis and those associated to the norm, regulation and governance conformity [Lez17].  Meta Diagnosis: it represents the social intelligent desired behavior that should be specified by designer to achieve an overall diagnosis of several systems.  Social Interaction Management: it aims to ensure interactions with both GCA and LCA agents, as well, with external systems or platforms. Thus, designer should specify a welldefined interaction protocols by reusing existing standards or proposing new ones.  Action: GCA acts upon its environment through its own actuators by executing selected sequence of actions which impact among other the LCA behavior. 3.2.4. Interface Agent (IA) IA ensures system initialization, environment discovering, device configuration and all interactions International Conference on Advanced Aspects of Software Engineering ICAASE, December, 01-02, 2018 Page 66
Figure 5 :Figure 5: Global Coordination Agent architecture. Remark: All diagnosis modules are structured into three complementary modules, which represent faults detection, faults isolation and fault identification. In addition, the proposed architecture is generic in the sense that these modules could be implemented in different manners with respect to application domain and designer's choice. The same statement concerns the interactions exchanged between agents and the corresponding protocols. 4. Case Study: Diagnosis of a IoT Based Healthcare Monitoring Sensors For Diabetic Patients IoTAA-D can be implemented in several manners with respect to: application domain, diagnosis algorithms and models, MAS platforms and tools, IoT platforms, protocols and technologies [Kou18]. As an example of IoTAA-D application, let us consider an IoTAA-D diagnosis based application which diagnoses IoT system sensors of a Health Care Monitoring for Diabetic Patients. In this section, we outline the main design stepwise. The main goal of this application is to achieve an easy handheld healthcare on monitoring diabetic via breath. a) Description of medic standing and the underlying scientific phenomenon It's well known that when the body has too little insulin, it means that the cells of the body cannot take enough sugar (glucose) from the blood. So, ketones
Figure 6 :Figure 6: " Diab-check Device. c) Physical realization of "Diab-check" prototype The stepwise to design the "Diab-check" is described as follows: Firs, the following sensors are required: Gas detection sensor, Temperature sensor and Humidity sensor.
Figure 7 :Figure 7: " Diab-check" main HardwareComponents. Connection of these components is made up on Breadboard and is illustrated by Figure8. The program that controls sensors and ensures data transmission between sensors, mobile and server applications is implemented by means of Arduino Software [Ard18] which is fully rewritten in C language. First, the code should be uploaded into the Microcontroller. After that, the sensors communicate the corresponding data to the mobile application via GSM sensor. In turn, these data are transmitted to the server application and displayed on LCD. Mobile application on Smartphone is implemented under Android platform (Figure9).
Figure 8 .Figure 8. Connected Things of the "Diab-check" d) Scenario: Application of Diab-check in Health facility We consider two treatment rooms R1 and R2 which can receive respectively n (n>0) and m (m>0) diabetic patients. Each patient can be monitored by a "Dibcheck device". Each room is supervised by a health manager. The overall health facility is supervised by a health supervisor. This sample could be modeled by means of IoTAA-D as depicted in Figure 10.
Figure 9 :Figure 9: Mobile Application.
Figure 10 .Figure 10. Scenario of health facility monitoring based on IoTAA-D. In this application, agent, are implemented by means of JADE platform. Such platform choice is motivated by the fact that is the most popular FIPA-compliant agent platform in the academic and industrial community. Moreover, it is free, stable software and an open source framework which is distributed by Telecom Italia. At this stage, we describe some details that concern some agents' behavior:  Agent of Things (AoT): the assignment of sensors to agents of things is based on Diab-Check devices deployed in each room; thus, we distinguish an AoT associated to each device. AoT has a repository of stimulus response that describes the monitoring routine. Diagnosis modules are based on inference engine of Prolog language, where several inference rules are defined. Some necessary interactions can take place when there is interference between the measured data that are controlled in the same room.  Local Coordination Agent: one agent can be distinguished by room. Each local coordination agent has to coordinate, locally, agents of things together. Each Local coordination agent has a local diagnosis module that ensures diagnosis of the different devices involved by room. Such module detects anomalies and malfunctioning related to the devices. In addition, based on an inference rules, it localizes and fixes possible failures.

For instance, Figure 11 shows the deployment of agents, by room, on JADE platform.

Conclusion

IoT is a promising research area.