Modeling and reasoning of IoT architecture in semantic ontology dimension

Journal Pre-proof Modeling and reasoning of IoT architecture in semantic ontology dimension Guang Chen, Tonghai Jiang, Meng Wang, Xinyu Tang, Wenfei Ji

PII: DOI: Reference:

S0140-3664(19)31891-2 https://doi.org/10.1016/j.comcom.2020.02.006 COMCOM 6206

To appear in:

Computer Communications

Received date : 2 December 2019 Revised date : 2 January 2020 Accepted date : 3 February 2020 Please cite this article as: G. Chen, T. Jiang, M. Wang et al., Modeling and reasoning of IoT architecture in semantic ontology dimension, Computer Communications (2020), doi: https://doi.org/10.1016/j.comcom.2020.02.006. This is a PDF file of an article that has undergone enhancements after acceptance, such as the addition of a cover page and metadata, and formatting for readability, but it is not yet the definitive version of record. This version will undergo additional copyediting, typesetting and review before it is published in its final form, but we are providing this version to give early visibility of the article. Please note that, during the production process, errors may be discovered which could affect the content, and all legal disclaimers that apply to the journal pertain. © 2020 Published by Elsevier B.V.

Journal Pre-proof

lP repro of

Modeling and Reasoning of IoT Architecture in  Semantic Ontology Dimension  GuangChen1,2,4*, TonghaiJiang1,3, MengWang1,4, XinyuTang1,4, WenfeiJi1,2,4  1

  The Xinjiang Technical Institute of Physics & Chemistry, Chinese Academic of Science, Urumqi 830011, China.    University of Chinese Academy of Sciences, Beijing 100049, China.  3  Xinjiang Laboratory of Minority Speech & Language Information Processing, Chinese Academy of  ScienceUrumqi 830011, China.  4  Jiangsu CAS Nor‐West star Information Technology Co.,Ltd, Wuxi 214135, China.  Email: [email protected], [email protected] , [email protected],2,4,    *  Correspondence Email: [email protected]; Tel.:+86‐1816‐893‐7637 (G.C.)  2

Abstract:  The  architecture  for  IoT  is  the  primary  foundation  for  designing  and  implementing  the  System of Internet of things. This paper discusses the theory, method, tools and practice of modeling  and  reasoning  the  architecture  of  the  Internet  of  Things  system  from  the  dimension  of  semantic  ontology. This paper breaks the way of static ontology modeling, and proposes an implementation  framework for real‐time and dynamic ontology modeling of the IoT system from the running system.  According  to  the  actual  needs  of  the  health  cabin  IoT  system  and  the  combination  of  theory  and  practice,  the  system  architecture  model  of  the  semantic  ontology  dimension  of  IoT  is  built.  Then,  based on the reasoning rules of the ontology model, the model is reasoned by Pellet reasoning engine  which injects the atom of the custom reasoning built‐ins into the source code. In this way we have  realized the automatic classification and attribute improvement of resources and behaviors of the IoT  system, the real‐time working state detection and fault diagnosis of the IoT system, and the automatic  control of the IoT system and resources.  Keywords: IoT; Architecture; Ontology; modeling; reasoning   

rna

1. Introduction 

Jou

Internet of Thing (IoT) refers to a dynamic loosely coupled system which combines various kinds  of  information  sensing  devices,  such  as  RFID,  sensing  devices  and  control  devices  that  can  execute  certain  commands  to  affect  the  environment  through  a  variety  of  networking  technologies  and  the  Internet[1].  Different  from  the  traditional  Internet,  the  Internet  of  Things  integrates  physical  space,  information  space  and  social  space[2].  It  has  special  characteristics  different  from  the  traditional  Internet[1],  including  heterogeneity,  large‐scale,  interaction  with  the  physical  world,  resource  constraints, dynamics and incompleteness. These characteristics make the design and implementation  of the Internet of Things face great challenges.  The architecture of the Internet of things is a graphical or formal model based on mathematics,  formal language with precise semantics and specifications, or formal description method, which aims  at the architecture of the Internet of things from different perspectives and dimensions. Furthermore,  the system architecture model which extracts the key features of the system from the specific Internet  of things system is further abstracted and generalized, so that it can provide reference for the design or  modeling  of  other  Internet  of  things  system,  and  the  built  Internet  of  things  architecture  model  is  called the reference model of Internet of things architecture.  Because of the dynamic and incomplete nature, the IoT system often has very rich and complex  operation  state.  How  to  real‐time  perceive  the  running  status  of  each  component  resource  and  determine  whether  there  are  anomalies  in  the  Internet  of  Things  system  based  on  some  underlying  sensing  data  is  an  urgent  problem  to  be  solved.  It  is  the  motive  of  this  paper  to  explore  a  model  knowledge which is less intrusive to the existing Internet of Things system and can acquire advanced 

Journal Pre-proof

1.1. Ontology Modeling Theory 

lP repro of

operating  state  of  the  Internet  of  Things  system  by  automatic  reasoning  based  on  the  basic  factual  behavior of the Internet of Things.    The traditional method achieves this goal by specially constructing the Internet of Things service  for system anomaly monitoring and judgment. It not only needs to invest in certain development, but  also  can  not  carry  out  dynamic  expansion,  resulting  in  the  increase  of  the  maintenance  cost  of  the  Internet of Things system. In recent years, in order to solve the interoperability problem of resources in  heterogeneous Internet of Things systems, the research of Internet of Things has gradually introduced  semantic  web  technology  into  the  Internet  of  Things[3].  The  ontology  and  modeling  capabilities  provided by the Semantic Web enable resources in the Internet of Things to be described in a unified  machine‐understandable manner.  The reasoning technology  based on  ontology model also makes  it  possible  to  automatically  extract  and  infer  the  working  state  information  of  high‐level  Internet  of  Things from low‐level sensor data. The ability of semantic ontology free modeling and extension can  also  effectively  solve  the  problems  brought  by  the  dynamic  expansion  of  physical  network  system  resources.  In  this  paper,  the  architecture  of  Internet  of  Things  system  is  modeled  from  the  dimension  of  semantic  ontology.  Relying  on  the  technology  of  semantic  ontology  modeling  and  reasoning,  the  automatic  identification,  real‐time  state  monitoring,  fault  diagnosis  and  automatic  control  of  the  resources of the Internet of Things system are accomplished. Based on the semantic ontology modeling  of the Internet of Things (IoT) system for temperature control in the elderly health cabin, this paper  discusses  the  method  and  practice  of  using  semantic  ontology  to  model  the  architecture  of  the  IoT  system and model reasoning. 

Jou

rna

Ontology  modeling  theory  has  undergone  a  process  of  continuous  development  and  improvement, and is still in the process of sustainable development. The content involved is extensive  and rich. Due to the limitation of space, the specific grammatical rules of modeling theory will not be  listed one by one in this paper, but the more official introduction of theoretical rules will be cited.  As early as 2000, Tim Berners‐Lee, the father of the World Wide Web, proposed the concept and  hierarchy  of  the  Semantic  Web[4].  Based  on  URI  [5](Uniform  Resource  Identifier)  and  XML  [6](  Extensible Markup Language), W3C formally released the first basic ontology modeling language RDF  [7](  Resource  Description  Framework)  in  2004.  RDF  defines  property  (the  connection  relationship  between ontology resources ) and resources in the form of triples. This become the basis of semantic  web  and  knowledge  atlas  for  knowledge  entity  relationship  representation.  Until  now,  the  representation of atomic knowledge in mainstream knowledge atlas and semantic ontology exists in  the form of triples. However, RDF is limited in expressing concepts, classes and attributes of entities. It  can only be regarded as the original ontology language.    In  order  to  further  expand  the  ability  of  ontology  modeling  and  expression,  on  the  basis  of  inheriting  RDF  grammar,  W3C  developed  OWL[8](Web  Ontology  Language)  which  is  an  ontology  language oriented to Semantic Web. OWL extends the modeling ability of describing SimpleClasses,  Individuals,  Simple  Properties,  and  Property  Characteristics  and  Property  Restrictions.  OWL  also  defines the description class rules of Ontology Mapping, which enables ontology modeling to derive  new  classes  or  attributes  in  the  form  of  Equivalence  on  the  basis  of  existing  classes  and  attributes.  Introducing Ontology on the basis of RDF greatly enriches the expressive ability of ontology modeling.  The introduction of Ontology on the basis of RDF greatly enriches the expressive power of ontology  modeling, but this is still not enough. For  example, even  if there  are already basic Person and  Data  Property has Age, it is still impossible to express the concept of PigSign Person whose age mod 12 is  zero (in 2019) through ontology mapping.  In  order  to  expand  OWLʹs  modeling  and  expression  ability  more  freely.  W3C  defines  SWRL[9](Semantic Web Rule Language) based on RuleML[10]. SWRL extends the expressive power of  OWL description language by describing Axioms in ontology modeling. A SWRL is divided into two 

Journal Pre-proof

1.2. Ontology Modeling Method 

lP repro of

parts: Antecedent and Consequent, which are composed of several Atoms. Multiple SWRL rules can  be  created  simultaneously  in  ontology  modeling.  SWRL  Atom  can  be  divided  into  the  following  categories:  Class  Expression  Atom,  Property  Expersion  Atom,  Data  Range  Restriction  Atom  and  SWRL Core Build‐In Atom. SWRL defines a series of Core Built‐Ins in the swrlb description file. These  plug‐ins are used in SWRL Builtin Atom, which enriches SWRLʹs reasoning rule expression ability in  mathematical calculation, string processing and time processing.  SWRL  based  on  OWL  has  been  able  to  model  many concepts and reasoning rules in ontology  Internet  of  Things  modeling,  but  in  order  to  complete  the  modeling  of  Ontology‐based  Internet  of  Things  architecture,  this  is  still  not  enough.  For  example,  although  SWRL  can  handle  time‐related  operations well through Built‐Ins for Date, Time and Duration[9], there is no way to get the current  time, and we need to judge the working state of the sensor according  to  the  current  time  when  we  model  the  sensor.  To  this  end,  we  need  to  further  expand  the  modeling  capabilities  of  SWRL  and  implement some custom SWRL reasoning extension plug‐ins. SWRL supports user‐defined plug‐ins  grammatically,  and  uses  the  same  plug‐in  grammar  as  Core  Build‐In  to  model.  To  distinguish  between these user‐defined primitives, we call them Custrom Build‐In Atom. 

Jou

rna

In  this  section,  we  take  the  ontology  model  of  Person  in  the  social  Internet  of  things[2]  as  an  example to illustrate the ontology modeling method based on ontology modeling  theory.A  complete  ontology model of Person is shown in Figure 1. Part of the content is folded due to space constraints,  complete XML files are detailed in Appendix 1.   

Figure 1. Modeling Ontology Person Based on OWL+SWRL. 

 

Journal Pre-proof

1.3. Ontology Modeling Tool 

lP repro of

Firstly, based on OWL grammar rule[8], the basic class Person is modeled, which shown in line 6  of Figure 1.Similarly,  we establish  the  basic  class  Adult as  shown in lines 8‐10 of Figure 1. By using  the ʺsubClassOfʺ attribute, we define ʺAdultʺ as a subclass of ʺPersonʺ, and express the concept that  an adult must be a human.  Secondly, the object attribute has Child and the data attribute has Age are modeled separately, as  shown  in  lines  20‐30 of Figure 1.  The  Domain  that  qualifies  the  has  Age  attribute  is  Person and the  Range is an integer value. By adding the attribute Functional Property[8] to has Age, as shown in line  27 of Figure 1, the concept of a person can only have one age is expressed.  Thirdly, based on OWLʹs Ontology Mapping[8] grammar, we define the Parent class as shown in  lines 12‐16 of Figure 1. Parent is connected to Person through the Object Property has Child. Through  OWLʹs  grammar  rules,  we  express  the  concept  that  Parents  is  a  Person  who  has  Child  at  least  one  Person.  Then we define  two  individual  examples  of  Person ʺJinZiXuanʺ  and  ʺJinLingʺ as shown in line  33‐43  of  Figure  1.  We  describe  JinZiXuan  is  31  years  old  by  hasAge  property  andJinZiXuan  has  father‐son relationship with Jinling by has Child property.  Finally,  we  define  a  reasoning  rule  of  Adult based on SWRL grammar rule[9], as shown  in  lines  46‐114 of Figure 1, describing the concept of adult is a person older than 18 years old.  As you can see, just modeling a simple concept of Person, the file length of XML has exceeded  100 lines. Modeling directly using RDF/XML is very complex and costly to modify and maintain, and  error  prone.  And  the  reading  and  understanding  of  this  model  depends  on  the  modelerʹs  deep  understanding  of  OWL  +  SWRL  grammar  rules.  This  reduces  the  efficiency  of  Ontology‐based  modeling to a certain extent. In order to better model the semantic ontology of the Internet of Things  system, we need to explore a better ontology modeling tool to shield the specific grammatical rules of  RDF/XML, focusing on the characteristics of the Internet of Things system itself for semantic ontology  modeling. 

Jou

rna

In order to facilitate ontology development and application, many organizations or groups have  developed various types of ontology tools, such as Apollo[11], OILEd[12], OntoEditor[13], Protégé[14],  WebODE[15], and so on. Considering open source, extensive use, extensibility of plug‐ins, reasoning  engine  support,  document  richness,  this  paper  decides  to  use  Protégéas  a  modeling  tool  for  the  semantic  ontology  dimension  architecture  of  the  Internet  of  Things.  Protégéis  the  most  popular  ontology editing and modeling software developed by the Bioinformatics Research Center of Stanford  University  Medical  College  based  on  Java  language.  It  is  the  core  development  tool  of  ontology  modeling  in  Semantic  Web.  The  latest  version  is  version  5.5.0.Introduction  to  the  menu  function  of  Protégé and its detailed usage can be referred to reference[16].  Remodelling  the  Person  ontology  mentioned  in  Section  1.2  using  Protégéis  shown  in  Figure 2.  Different  views  of  Protégécan  be  used  to  model  basic  classes,  object  property,  data  property,  and  SWRL  rules  respectively.  It  is  worth  mentioning  that  Protégéalso  supports  the  graphical  display  of  the established ontology model as shown in the lower right side of Figure 2, but the graphical view  ʺOntoGraphʺ can only display the existing ontology model graphically, and cannot directly carry out  graphical modeling.  Ontology  modeling  using  Protégémakes  the  modeler  no  longer  care  about  the  complex  grammatical rules of ontology description language, but only need to understand the attributes and  constraints  of  ontology  at  the  conceptual  level  to  complete  the  domain  ontology  modeling,  which  greatly  improves  the  efficiency  of  modeling.  Because  the  ontology  model  based  on  RDF/XML  and  visual  ontology  model  based  on  Protégéis  essentially  identical,  in  order  to  save  space  and  increase  readability,  all  the  subsequent  ontology  modeling  discussions  are  given  with  the  visual  ontology  model in Protégé. 

lP repro of

Journal Pre-proof

 

Figure 2. Visual Modeling of Ontology Person with Protégé. 

It  should  be  noted  that  SWRL  only  describes  the  reasoning  rules  in  the  ontology,  but  does  not  actually implement the reasoning of these rules. In the model of Figure 2, we can clearly see that the  type  of  individual  JinZiXuan  is  only  Person  but  not  Parent  and  Adult.  This  is  because  inference  execution based on OWL grammar rules and SWRL inference rules is accomplished by reasoner.  1.4. Ontology Modeling Reasoner 

Jou

rna

The  common  inference  engines  of  ontology  models  includeJess[17]、Racer[18]、Fact++[18]、 Hermit[19]、Jena[20]and Pellet[18] and so on. Hermit reasoner has been installed in Protégé5.5, and  other reasoner, including Pellet, can be installed through Check For Plugin in the File menu. Based on  the  model  established  in  Section  1.3,  we  can  use  Pellet  reasoner  to  perform  ontology  model  reasoning.As shown  in  Figure 3,  on the Reasoner  menu,  select the  Pellet inference  engine, and then  click the Start reasoner option. It can be observed that the individual JinZiXuan has both Parent and  Adult types as shown on the right side of Figure 3. Click the ?button on the right of the type Adult, you  can see why it adds this type as shown below in Figure 3. 

  Figure 3. Ontological Reasoning Using Pellet in Protégé. 

Journal Pre-proof

Different  reasoner  have  different  support  for  OWL  grammar  rules  and  SWRL  inference  rules,  even for different types of constituent Atom in SWRL. The reasoning support of each inference engine  for OWL+SWRL is shown in Table 1.   

Reasoner  Jess  Racer  Fact++  Jena  Hermit  Pellet 

lP repro of

Table 1. Reasoner support table for ontology reasoning rules. 

OWL Ontology  Class & Property  Rules  Experation    Atom  unsupport  support  support  unsupport  support  unsupport  support  unsupport  support  support  support  support 

DataRange  Restriction Atom  support  unsupport  unsupport  unsupport  unsupport  support 

Core Build‐In  Atom  support  unsupport  unsupport  unsupport  unsupport  support 

Custrom  Build‐In Atom  unkonwn  unsupport  unsupport  unsupport  unsupport  coding support 

Different inference engines support different SWRL syntax rules and custom inference plug‐ins.  Table 1  describes  in  detail  the support of  different  inference engines for  relevant content. In  Table 1  ʺunknownʺ means that no relevant literature or experimental methods have been found, and ʺcoding  supportʺ means that the source code of the reasoner needs to be modified and recompiled to support.  Because  the  Semantic  Ontology  dimension  of  the  Internet  of  Things  architecture  modeling  not  only  needs  to  use  SWRL  Core  Build‐Ins  reasoning,  but  also  needs  to  use  Customer  Build‐Ins  reasoning  rules  such  as  ʺCurrentTimeʺ,  so  this  paper  chooses  Pellet  as  the  reasoning  engine  of  the  Internet of Things ontology model. By modifying Pelletʹs source code, some code implementations of  Custom  Build‐Ins  are  injected  into  Pellet  reasoner,  and  integrated  it  into  Protégémodeling tool.  The  implementation will be described in detail in Section 2.3.  2. Related Work 

Jou

rna

In  the  aspect  of  ontology  Internet  of  things  modeling,  some  scholars  have  carried  out  relevant  research and put forward many different ontology Internet of things models. In Reference[3], semantic  ontology technology was applied to the Internet of things system to solve the interoperability problem  between heterogeneous systems, and the framework of automatically building ontology model from  text information  source  was given,  but the  modeling method, modeling  examples and experimental  verification of ontology modeling were not provided. Reference[21] describes the modeling content of  the  Internet  of  things  system  equipment  resources  in  intelligent  manufacturing,  and  proposes  an  implementation framework for storing and invoking the ontology model. However, there is no clear  explanation  about  how  to  build  ontology  model  for  Internet  of  things  system  and  how  to  apply  it  based on ontology model.  This  paper  refers  to  the  modeling  ideas  of  some  excellent  ontology  models  of  the  Internet  of  things, and models the ontology dimension architecture model of the Internet of things system from  the three levels of behavior, resources and environment. In Section 3, the concepts and reasoning rules  involved in the ontology model of the Internet of things system are clearly explained and discussed.  Through  the  operation  simulation  of  the  Internet  of  things  system  in  Section  3,  the  creation  of  the  Internet  of  things  system  behavior  and  resource  ontology  instance  is  completed  automatically.  In  Section 1, this  paper discusses  the  theory  of semantic  ontology modeling and the  modeling method  using ontology in detail, and introduces the modeling tools and reasoning tools in detail, which lays a  good  foundation  for  building  the  Internet  of  things  architecture  model  of  semantic  ontology  dimension. In Section 4, the semantic ontology model is applied to realize the resource and behavior  classification, automatic detection of system resource composition and intelligent diagnosis of system  resource fault.  In  the  aspect  of  ontology  Internet  of  things  reasoning,  reference[22]  focuses  on  semantic  collaboration  of  different  ontology  Internet  of  things  models,  so  as  to  provide  users  with  special 

Journal Pre-proof

3. Materials and Methods   

lP repro of

services  to  meet  their  preferences,  but  does  not  provide  the  modeling  methods  and  modeling  examples  of  Internet  of  things  ontology  models.  Reference[23]  verified  the  possibility  of  ontology  Internet of things model combined with reasoning technology to obtain more abundant knowledge to  better meet the user information query. However, the implementation methods of time reasoning and  multi  event  joint  reasoning  are  not  clear  enough.  Although  Jenaʹs  reasoning  machine  and  the  algorithm of time reasoning chain are mentioned, there is no clear explanation about which technology  is used to realize the reasoning chain based on programming or reasoning rules.  On  the  basis  of  OWL  ontology  syntax  rules  and  SWRL  rules,  this  paper  implements  a  set  of  ontology  IOT  system  structure  reasoning  rules  for  automatic  classification  of  IOT  system  resources  and behaviors, component detection and fault diagnosis by customizing SWRL plug‐in primitives. In  Section 1, the reasoning tools and methods are given. In Section 3, the integration method of inference  engine supporting custom SWRL plug‐in primitives in ontology modeling tool is given in detail. 

rna

The  modeling  framework  of  OWL+SWRL  based  semantic  ontology  dimension  IoT  architecture  modeling is shown in Figure 4. 

 

Figure 4. Ontology Modeling and Implementation Framework of Internet of Things Architecture. 

Jou

In this section, we first use the ontology modeling tool Protégé to model the basic ontology model  of the Internet of Things system. The basic ontology model includes the abstract conceptual expression  of the physical environment and the resources of the Internet of Things system, as well as the SWRL  reasoning rules to determine the working status of the resources of the Internet of Things system, but it  does not contain specific instances and data.  In section 3.5, we will write an ontology modeling middleware based on Java language. Ontology  modeling  middleware  will  be  connected  to  the  sensor  control  resources  and  cloud  central  control  services  of  the  Internet  of things system in the mode  of agent to realize the transfer of sensing data  agent and control command. Ontology modeling middleware loads the concepts in the basic ontology  model, and according to the  concepts in these models and the  received perceptual data  and  control  commands,  uses  Jena  ontology  API[24]  to  automatically  create  the  corresponding  Internet  of  things  resources  or  perceptual  control  behavior  instances,  and  provides  an  HTTP  service  that  outputs  the  current ontology model of the Internet of things with perceptual facts and data.  Finally, in Section 4, we read the complete basic fact ontology with perceptual data and control  commands provided by ontology middleware output service through protégé tool, and use the pellet  CG (the implementation of the self defined inference plug‐in injected by the pellet inference engine) 

Journal Pre-proof

lP repro of

integrated in protégé after source code modification and recompilation for model reasoning, so as to  complete all the inferable Ontology attributes and data to complete the architecture modeling of the  semantic ontology dimension of the Internet of things system.  Through  the  ontology  model  service  provided  by  middleware,  we  can  get  the  latest  behavior  information of the Internet of things system in real time, and complete the real‐time reasoning of the  Internet of things ontology model according to the ontology concept and reasoning rules in the basic  ontology model, so as to realize the real‐time monitoring of the environment and resource state of the  Internet  of  things  system.  Through  the  customized  SWRL  plug‐in,  we  can  also  replace  the  central  control service to fully realize the automatic control of the Internet of things system.  3.1. Modeling Basic Ontology Model of the Internet of Things System 

rna

This  paper  refers  to  some  good  modelling  ideas  in  SSN[25]  and  reference[23],  such  as  environment, resources and behavior as the basic concepts of Internet of Things ontology, but does not  directly  use  the  conceptual  classes  or  properties  in  SSN  ontology.  For  the  purpose  of  satisfying  the  simulation  experiment  and  introducing  the  ontology‐based  architecture  modeling  method  to  the  readers, a simplified basic ontology model of the Internet of Things system is established as shown in  Figure 5. The model contains only the basic concepts and attributes, and there is no specific example of  IoT system components. The complete model file is detailed in Appendix 8. 

 

Figure 5. Basic Ontology Model of Internet of Things System. 

Jou

As shown in Figure 5, the Internet of Things system conceptually includes the IoT System class  representing  the  IoT  system  itself,  the  Environment  class  representing  the  physical  environment  in  which  the  IoT  system  is  located,  and  the  Resource  class  representing  the  component  resources  (including sensors and cloud control services) in the IoT System and Behavior class which represents  the  behavior  of  the  Internet  of  Things  system  generated  by  resources.  Each  class  is  subdivided  into  several subclasses, such as Resrouce, which can be divided into Sensor, Service and Controller from  the  perspective  of  resource  function.  From  the  point  of  view  of  the  state  of  resources,  Resource  can  also be divided into Working Resource, Fault Resource and currently Unknown Resource.  Each  class  in  the  Internet  of  Things  system  will  derive  different  Object  Property  and  Data  Prpoerty.  Object  Property  are  connected  to  other  individuals  in  the  ontology  model,  while  Data  Property  are  directly  connected  to  a  specific  value.  Take  resource  as  an  example,  it  contains  Object  Property  belong  System  that  can  be  connected  to  an  instance  of  an  IoT  System,  indicating  that  the 

Journal Pre-proof

lP repro of

resource belongs to the Internet of Things system. It also includes Data Property exec Behavior and  take Behavior points connected to the behavior class which indicates that this IoT system resource has  generated some behavior or receives the behavior of other resources.  3.2. Modeling SWRL Reasoning Rules of Internet of Things System 

Based on the established ontology model of the Internet of Things system, we can further model  the SWRL reasoning rules of the Internet of Things system as shown in Figure 6. Detailed reasoning  rules  function  description  will  be  discussed  in  Section  4  with  specific  reasoning  requirements  of  Internet of Things ontology model.    iot:Behavior(?b)^iot:targetURI(?b, ?burl)^iot:Resource(?r)^iot:identyURI(?r, ?r Behavior Attribute Rule 01

url)^swrlb:resolveURI(?burl, ?rurl, "http") ->

iot:targetResource(?b, ?r)^iot:takeBehavior(?r, ?b)

iot:Behavior(?b)^iot:fromURI(?b, ?burl)^iot:Resource(?r)^iot:identyURI(?r, ?rur Behavior Attribute Rule 02

l)^swrlb:resolveURI(?burl, ?rurl, "http") ->

iot:fromResource(?b, ?r)^iot:execBehavior(?r, ?b) Behavior Classification Rule 01

iot:Behavior(?b)^iot:temperature(?b, ?t) -> iot:Perception(?b)

Behavior Classification Rule 02

iot:Behavior(?b)^iot:commander(?b, ?com) -> iot:Controlling(?b)

iot:Behavior(?b)^iot:happenedTime(?b, ?st)^iot:belongSystem(?b, ?s)^iot:current Behavior Classification Rule 03

Time(?s, ?et)^cascg:durInSec(?dur, ?st, ?et)^swrlb:lessThan(?dur, 10) -> iot:RecentBehavior(?b)

iot:belongSystem(?b, ?s)^iot:temperature(?b, ?t)^iot:hasEnvironment(?s, ?e)^iot Environment Attribute Rule 01

:RecentBehavior(?b)^iot:Perception(?b)^cascg:newestBehavior(?b, "Perception") -> iot:hasTemperature(?e, ?t)

Environment Attribute Rule 02

iot:Environment(?e)^iot:belongSystem(?e, ?s)^iot:currentTime(?s, ?t) -> iot:currentTime(?e, ?t)

cascg:noBehavior(?r, "All", "All")^iot:Resource(?r) -> iot:UnknowResource(?r)

Resource Classification Rule 02

iot:Perception(?p)^iot:targetResource(?p, ?r) -> iot:Service(?r)

Resource Classification Rule 03

iot:Perception(?p)^iot:fromResource(?p, ?r) -> iot:Sensor(?r)

Resource Classification Rule 04

iot:Controlling(?b)^iot:fromResource(?b, ?r) -> iot:Service(?r)

Resource Classification Rule 05

iot:Controlling(?b)^iot:targetResource(?b, ?r) -> iot:Controler(?r)

rna

Resource Classification Rule 01

Resource Classification Rule 06

iot:Sensor(?s)^iot:execBehavior(?s, ?b)^iot:temperature(?b, ?t) -> iot:TemperatureSensor(?s)

Jou

iot:TemperatureSensor(?s)^cascg:noBehavior(?s, "All", "Recent") ->

Resource Failure Rule 01

iot:FaultResource(?s)^iot:faultReason(?s, "No temperature perception in 10 seconds")

Resource Failure Rule 02

iot:TemperatureSensor(?r)^iot:RecentBehavior(?b)^iot:execBehavior(?r, ?b) -> iot:WorkingResource(?r) iot:Controler(?c)^iot:takeBehavior(?c, ?b)^iot:RecentBehavior(?b)^cascg:latestB

Resource Failure Rule 03

ehavior(?c, "Take", ?b)^iot:responseCode(?b, ?code)^swrlb:notEqual(?code, 200) ->

iot:FaultResource(?c)^iot:faultReason(?c, "Latest received control command processing failed")

Resource Failure Rule 04

iot:Controler(?c)^iot:takeBehavior(?c, ?b)^iot:RecentBehavior(?b)^cascg:latestB ehavior(?c, "Take", ?b)^iot:responseCode(?b, ?code)^swrlb:equal(?code, 200) ->

Journal Pre-proof

iot:WorkingResource(?c) iot:Controler(?c)^cascg:noBehavior(?c, "Take", "Recent")^cascg:httpTestStatus(?c, "Test", ?code)^swrlb:notEqual(?code,

Resource Failure Rule 05

lP repro of

200)^swrlb:stringConcat(?rea, "Response failed, return ", ?code) -> iot:FaultResource(?c)^iot:faultReason(?c, ?rea) iot:Controler(?c)^cascg:noBehavior(?c, "Take",

Resource Failure Rule 06

"Recent")^cascg:httpTestStatus(?c, "Test", ?code)^swrlb:equal(?code, 200) -> iot:WorkingResource(?c)

iot:Service(?s)^cascg:noBehavior(?s, "Exec", "Recent") -> Resource Failure Rule 07

iot:FaultResource(?s)^iot:faultReason(?s, "No controller control commands have been sent recently")

iot:Service(?s)^iot:takeBehavior(?s, ?b)^iot:RecentBehavior(?b)^cascg:latestBeh Resource Failure Rule 08

avior(?s, "Take", ?b)^iot:responseCode(?b, ?code)^swrlb:notEqual(?code, 200) -> iot:FaultResource(?s)^iot:faultReason(?s, "Sensor Data Acceptance Failure") iot:Service(?s)^iot:execBehavior(?s, ?b1)^iot:RecentBehavior(?b1)^iot:takeBehav ior(?s, ?b2)^iot:RecentBehavior(?s)^cascg:latestBehavior(?s,

Resource Failure Rule 09

"Take", ?b2)^iot:responseCode(?b2, ?code)^swrlb:equal(?code, 200) -> iot:WorkingResource(?s)

iot:Service(?s)^iot:execBehavior(?s, ?b1)^iot:RecentBehavior(?b1)^cascg:noBehav

Resource Failure Rule 10

ior(?s, "Take", "Recent") -> iot:WorkingResource(?s)

System Composition Rule 01

iot:Environment(?e)^iot:belongSystem(?e, ?s) -> iot:hasEnvironment(?s, ?e)

System Composition Rule 02

iot:UnknowResource(?r)^iot:belongSystem(?r, ?s) -> iot:hasUnknowResource(?s, ?r)

System Composition Rule 03

iot:hasSensor(?sys, ?s)

iot:Sensor(?s)^iot:FaultResource(?s)^iot:belongSystem(?s, ?sys) -> iot:hasFaultSensor(?sys, ?s)

rna

System Composition Rule 04

iot:Sensor(?s)^iot:WorkingResource(?s)^iot:belongSystem(?s, ?sys) ->

System Composition Rule 05

System Composition Rule 06

iot:hasService(?sys, ?s) iot:Service(?s)^iot:belongSystem(?s, ?sys)^iot:FaultResource(?s) -> iot:hasFaultService(?sys, ?s) iot:Controler(?c)^iot:belongSystem(?c, ?s)^iot:WorkingResource(?c) -> iot:hasController(?s, ?c) iot:Controler(?c)^iot:belongSystem(?c, ?s)^iot:FaultResource(?c) ->

Jou

System Composition Rule 07

iot:Service(?s)^iot:belongSystem(?s, ?sys)^iot:WorkingResource(?s) ->

System Composition Rule 08

iot:hasFaultController(?s, ?c)

Figure 6. SWRL Reasoning Rules of Internet of Things System. 

The  reasoning  rules  include  the  rules  to  improve  the  resource  attributes  and  the  relationship  between the resource composition of the IoT system, and the rules to perceive and judge the working  status of each resource in the current IoT system. Taking the ʺBehavior Classification Rule 03ʺ of the  Internet  of  Things  system  as  an  example,  we  believe  that  the  Recent  Behavior  occurring  within  10  seconds  before  the  current  time  whitch  can  be  relied  on  to  judge  the  current  working  status  of  the  Internet  of  Things  system.  The  reasoning  of  reasoning  rules  can  depend  on  the  results  of  other  reasoning rules. As shown in Figure 6, ʺResource Fault Rule 02ʺ is based on the reasoning results of  Recent Behavior expressed by ʺBehavior Classification Rule 03ʺ. Further reasoning can determine that 

Journal Pre-proof

lP repro of

the  sensor has Working  Resource  statue if  the behavior  of temperature sensing  is implemented and  this behavior is Recent Behavior.  In  particular,  we  use  some  Custrom  Build‐In  Atom  in  some  SWRL  reasoning  rules,  such  as  ʺdurInSecʺ in ʺBehavior Classification Rule 03ʺ.The function of this Build‐In Atom is to calculate how  many seconds have elapsed from the occurrence time to the current time according the execution time  of  IoT  behavior,  so  as  to further  judge whether the  IoT  behavior  is  a  recent  behavior  by  comparing  whether the result is less than 10.This Build‐In Atom is not the SWRL Core Built‐Ins Atom, but our  own defined Atom. At present, the SWRLTab page provided by Protégé5.5 version can not support  the  input  of  Custom  Build‐In  Atom  very  well.  These  Atoms  are  manually  modified  and  entered  by  modifying  the  corresponding  basic  ontology  OWL  files,  whitch  based  on  RDF/XML  grammar  of  SWRL.Protégé5.5  can  show  these  Custom  Build‐In  Atom,  but  cannot  be  modified  and  saved.  The  native  Pellet  reasoner  integrated  in  Protégécan  not  directly  support  the  reasoning  of  these  Custom  Built‐Ins Atoms. We need to modify the source code of Pellet and inject our Custom Built‐Ins into the  registration class of Pellet to achieve reasoning support.  3.3. Implementing Custom Built‐Ins in SWRL rules 

Jou

rna

In  order  to  integrate  Pellet‐CG,  our  reasoning  machine  injected  with  Custom  Built‐Ins  source  code,  in  Protégé.  We  first  download  Pelletʹs  source  code  from  GitHub  (https://github.com/stardog  ‐union/pellet/tree/maven).Pellet source package is a Maven project [26]. It needs to be imported using  IDE  integrated  with  Maven  function.  This  research  uses  Eclipse  Mars  +  Maven  2.4.3  as  the  experimental  integration  environment.  Pellet‐Maven  includes  several  sub‐projects,  including  Core  (Pellet  Core  Inference  Package,  including  Pellet  Core  Inference  Algorithms  Implementation),  Jena  (API Project of Pellet and Jena Integration), etc., but there is no Protégéplug‐in project that we need.  We need to download the plug‐in project Protege from the source code of Pellet‐Maset (Pellet 2.4.0)  (https://github.com/stardog‐union/pellet/tree/master),  import  the  project  to  Eclipe  and  modify  the  dependency of its POM file to 2.3.2 as shown in Figure 7. 

 

Figure 7. Import Pellet‐Protege and Modify Project Dependency 

It  should  be  noted  that  Pellet‐Protege  project  compilation  needs  to  rely  on  pellet‐core,  pellet‐owlapi3,  pellet‐modularity  and  other  project  dependencies,  which  provide  source  code  in 

Journal Pre-proof

lP repro of

Pellet‐Mavenʹs  sub‐projects.  Please  ensure  that  they  are  opened  in  the  IDE  or  installed  with  Maven  Install command in order to compile Pellet‐Protege Project smoothly.    Next,  we  write  our  Built‐Ins  with  reference  to  the  Custom  Built‐Ins  API  provided  by  Pellet,  as  shown  in  Figure 8.  Detailed  plug‐in  implementation  code  is shown  in  Appendix  2.Since  Pellet  does  not  provide  a  detailed  description  of  the  Built‐Ins  API,  this  study  refers  to  the  writing  method  described in reference [27]. 

 

Figure 8. Implementing of Custom Built‐Insin Pellet reasoner. 

Jou

rna

Next we inject the Custom Built‐Ins into Pelletʹs inference engine acquisition interface, as shown  in Figure 9. 

 

Figure 9. Modify inference engine interface and inject Custom Built‐Ins 

Then modify the plug‐in description file ʺplugin.xmlʺ of Protégéas shown in Figure 10. Following  the configuration of Pellet‐2.3, a custom plug‐in Pellet‐CG is injected, its name displayed in Protégé is  configured,  and  the  corresponding  implementation  class  is  the  full  project  path  of  ʺPelletIncrementalReasoerFactory” in the previous step. 

lP repro of

Journal Pre-proof

 

Figure 10. Modifying Protégé plug‐in description XML file. 

Finally,  we  can  export  the  jar  package  “pellet‐cg“  in  the  form  of  Jar  package,  and  copy  the  jar  package  to  the  ʺpluginsʺ  folder  in  the  root  directory  of  Protégé  installation.  We  can  complete  the  installation of the custom Pellet‐CG reasoning machine. Note that when exporting jar packages, you  must choose to use the META‐INF file in the project, otherwise Protégéwill not load Pellet reasoner  correctly.  3.3. Operation simulation of health cabin IoT system 

rna

In the health cabin Internet of Things system, three temperature sensors are connected to sense  indoor  temperature,  an  air  conditioning  device  is  connected  to  refrigerate,  and  a  heating  device  is  connected to heat. All devices and sensors are scheduled by cloud control service. The system needs  to ensure that the indoor temperature can reach the optimum temperature range of 26℃in an effective  time. In order to carry out simulation，we have compiled a simulation program to simulate the work  function of the IoT system for temperature control in a healthy cabin.  3.4.1. Air Physical Environment Simulation 

Jou

In  a  healthy  cabin,  the  outdoor  temperature  and indoor  temperature are  variable,  and  the  user  inputs the specific indoor and outdoor temperature when the simulation program is initialized. The  air physical environment records the indoor and outdoor temperature of the health cabin by variables.  If the indoor temperature is lower than the outdoor temperature, the indoor temperature rises by one  degree  every  60  seconds  due  to  heat  transfer,  but  the  maximum  does  not  exceed  the  outdoor  temperature.  Otherwise,  if  the  indoor  temperature  is  lower  than  the  outdoor  temperature,  the  temperature  will  drop  by  one  degree  in  60  seconds.  Operating  screenshots  of  the  air  physical  environment simulation program are shown in Figure 11. Detailed implementation codes are shown  in  Appendix  3.The  time  interval  of  temperature  change  due  to  heat  transfer  can  be  modified  by  modifying ʺHeatTransferDelayTimeʺ as shown in Figure 11. 

lP repro of

Journal Pre-proof

 

Figure 11. Operating screenshot of air physical environment simulation program 

3.4.2. Temperature Sensor Simulation 

rna

In  a  health  cabin,  temperature  sensors  collect  temperature  every  10  seconds.  The  simulation  program realizes the temperature sensorʹs perception of the environment temperature by the way of  socket  inter‐process  communication.  And  the  perceived  environment  temperature  of  the  healthy  cabin  will  be  sent  as  HTTP  request  according  to  the  access  address  of  the  Cloud  Control  Service  configured  by  the  user.  Accessing  three  sensors  to  the  system  can  be  realized  by  running  three  simultaneous  temperature  sensor  simulation  programs  in  the  same  time.  The  running  screenshot  of  the  temperature  sensor  simulation  program  is  shown  in  Figure 12.  Detailed implementation  of  Java  code is shown in Appendix 4.You can modify the sensorʹs temperature sensing interval by modifying  the ʺSensorTemperatureDelayTimeʺ variable, as shown in Figure 12.   

 

Figure 12. Screenshot of Temperature Sensor simulation program. 

Jou

3.4.3. Air Conditioning and Heating Simulation 

In  a  health  cabin,  the  air  conditioning  receives  control  commands  in  the  form  of  Http  Service,  including  the  opening,  closing  and  testing  commands  sent  by  Cloud  Control  Service.  Operating  screenshots  of  the  air  conditioning  simulation  program  are  shown  in  Figure  13.  Detailed  program  implementation  code  is shown  in  Appendix 5.When the air conditioning is in the ʺONʺ  state, it  can  affect  the  physical  environment  of  air  temperature  at  20  seconds  interval,  making  its  temperature  drop by 1  ℃.As shown in Figure 13, you can modify the time interval between the temperature drops  caused by the impact of the the air conditioning by modifying the ʺAirCoolingDelayTimeʺ. 

lP repro of

Journal Pre-proof

 

Figure 13. Operating screenshot of air conditioning simulation program. 

The  realization  of  heating  is  exactly  similar  to  that  of  air  conditioning,  which  is  not  discussed  here.  3.4.4 Cloud Control Service Simulation 

Jou

rna

In the health cabin, the Cloud Control Service service receives temperature data from all sensors,  and  compares  the  temperature  perceived  with  the  optimum  ambient  temperature  of  26  ℃.  If  the  temperature is too high, it sends the ʺONʺ command to the air conditioning, and sending the ʺOFFʺ  command  to  the  heating.  If  the  temperature  is  too  low,  turn  on  the  heating  and  turn  off  the  air  conditioning. Whether the central control service receives the temperature sensed by the temperature  sensor or not, the Cloud Control Service sends ʺTestʺ commands to the air conditioning and heating at  10  seconds  intervals  to  detect  whether  the  corresponding  controller  entity  is  still  working.  A  screenshot  of  the  program  running  for  Cloud  Control  Service  is  shown  in  Figure 14.  Detailed  Java  implementation code is shown in Appendix 6. 

 

Figure 14. Screenshot of Cloud Control Service Simulator 

3.5. Access the Ontology Modeling Middleware    In  order  to  realize  the  real‐time  automatic  creation  of  IoT  system  resources  and  behavior  instances,  we  need  to  write  IoT  system  access  middleware.  The  main  function  of  middleware  is  to  read  the  established  basic  ontology  model  of  the  Internet  of  Things  system,  monitor  all  kinds  of  behaviors  in  the  system,  including  sensing  transmission  behavior  and  controlling  command  transmission behavior, and automatically create the behavior and resource instances of the Internet of  Things system based on the concept of the basic ontology model. 

Journal Pre-proof

lP repro of

As shown in Figure 4, the best placement of middleware should be before Cloud Control Service.  Sensors  can  forward  perceived  data  to  Cloud  Control  Service  through  middleware  agents.  Cloud  Control  Service  forwards  control  commands  to  corresponding  Internet  of  Things  control  entities.  through  proxy  middleware.  A  screenshot  of  the  middleware  program  is  shown  in  Figure  15.  The  complete Java implementation code is detailed in Appendix 7. 

 

Figure 15. Ontology Modeling Middleware Operating Screenshot of Internet of Things System. 

Jou

rna

The arithmetic principle of the middleware of IoT system is as follows:  First,  use  Jena  Ontology  API  to  read  the  basic  ontology  model  established  in  Section  2.1,  and  maintain  a  real‐time  ontology  model  ʺIoT  Modelʺ  of  the  current  Internet  of  Things  system  in  the  memory of the middleware program. According to the modelerʹs naming of the current IoT system,  the  Individual  and  Environment  instances  of  the  IoT  system  are  automatically  created,  and  the  ʺbelongSystemʺ attribute is added to the environment instances.  Next, the middleware completes the proxy forwarding of the IoT system behavior according to  the user‐configured service address, implements the proxy service through the API provided by Java  HttpServer[28], and completes the data transmission of the proxy address through the API provided  by HttpURLConnection[29], and obtains the access result to return.   

 

Figure 16. Opening and refreshing ontology model of real‐time IoT system based on middleware  services 

In  the  process  of  proxy  forwarding,  the  behavior  from  the  sending  resource  to  proxied  target  resource  of  IoT  system,  including  sensing  data  and  control  commands,  is  captured.  Based  on  Jena  Ontology  API[24],  ontology  instances  of  these  behaviors  are  created  and  added  to  the  real‐time  ontology model ʺIoTModelʺ. It should be pointed out in particular that middleware only models the  basic  information,  including  the  occurrence  time  and  transmission  parameters,  captured  in  the  behavior  of  the  IoT  system.  It  does  not  make  further  model  inference  based  on  these  basic  facts. 

Journal Pre-proof

4. Results and Discussion 

lP repro of

Model  inference  and  perfection  are  based  on  Pellet  in  Protégé,whitch  we  will  discuss  it  further  in  Section 3.  Finally,  the  Ontology  Modeling  Middleware  provides  an  HTTP  service  ʺ/current‐IoT‐modelʺ  based on the HttpServer API to output the current real‐time ontology model.  Using the ʺOpen from URLʺ function of Protégé, we can directly rely on this service to open the  real‐time ontology model of the IoT system and view the real‐time Behaviors and Individuals of the  IoT  system.  And  it  can  refresh  the  latest  real‐time  ontology  model  of  the  IoT  system  at  any  time  through the way of ʺReloadʺ, as shown in Figure 16. 

Based  on  the  results  discussed  in  Section  2,  we  have  been  able  to  obtain  a  relatively  complete  real‐time  basic  fact  model  of  the  health  cabin  system,  including  the  basic  health  cabin  ontology,  operation  behavior  and  resource  instances,  through  the  output  services  provided  by  the  ontology  modeling  middleware  of  the  Internet  of  Things  system.  In  this  section,  we  will  perform  the  model  reasoning of this model, so as to complete the automatic classification of resources and behaviors of  the  IoT  system,  the  automatic  identification  of  the  components  of  the  IoT  system,  as  well  as  the  working status of the components of the IoT system, and to diagnose the causes of abnormal working  status. Based on the real‐time ontology IoT model and SWRL rules, this paper discusses the possibility  that this ontology architecture model will take over the control services for automatic control of the  Internet of Things system when the control services fail.  4.1. Resource and Behavior Classification 

Jou

rna

As shown in Figure 6, ʺBehavior Attribute Rules 01ʺ and ʺBehavior Attribute Rules 02ʺ are used to  associate  the  behavior  and  resources  of  the  Internet  of  Things  system.  From  the  behavior  of  the  Internet  of  Things  system,  the  URI  of  the  source  of  the  behavior  can  be  obtained  through  the  ʺfromURIʺ  property  and  the  resource  URI  that  receives  the  behavior  can  be  obtained  by  the  ʺtargetURIʺ property. By comparing resource URIs, the association between take Behaviior and exec  Behavior is automatically established.  As  shown  in  Figure  6,  the  behavior  of  the  Internet  of  Things  system  has  been  classified  by  ʺBehavior Classification Rules 01‐03ʺ. We believe that the behavior that contains temperature sensing  parameters is Perception, and the behavior that contains control command parameters is Conrtolling.  The behavior that occurs within 10 seconds before the current time of the Internet of Things system is  Recent Behvior.  The rules of resource classification are shown in Figure 6 as ʺResource Classification Rules 01‐06ʺ.  ʺResource  Classification  Rule  1ʺ  means  that  if  a  resource  of  an  IoT  system  has  never  produced  any  behavior, we can not determine its type and state and classify it as an Unknown Resource.ʺResource  Classification  Rule  2ʺ  based  on  the  reasoning  results  of  behavior  classification  expresses  that  the  receiving  target  of  Perception  is  a  Service,  and  ʺResource  Classification  Rule  3ʺ  expresses  that  the  sending source of Perception is a Sensor.ʺResource Classification Rules 4‐5ʺ respectively indicate that  the receiving target of Controlling(control behavior ) is a Controler, and the source must be a Service.  Finally,  based  on  the  reasoning  result  of  ʺResource  Classification  Rule  2ʺ,  we  can  make  further  reasoning  of  temperature  sensor,  which  means  that  a  Sensor  that  senses  temperature  must  be  a  Temperature Sensor.  Based on the above reasoning rules and referring to the reasoner integration method introduced  in Section 2.3, we use the Pellet‐CG reasoner with the Custom Built‐Ins such as ʺnoBehaviorʺ injected  after source code modification to reasoning results as shown in Figure 17. 

lP repro of

Journal Pre-proof

 

Figure 17. Reasoning results of resource and behavior classification in IoT system 

Figure 17 shows that resources and behaviors are automatically correlated and the classification  of  resources  and  behaviors  in  the  Internet  of  Things  system  becomes  more  detailed  after  reasoning.Examine  a  specific  ʺRes_1980...ʺ,  as  you  can  see  in  Figure  17,  it  has  been  automatically  classified as TemperatureSensor and it’s currently working statusisWorkingResource.  4.2. Resource Fault Diagnosis 

As shown in Figure 6, ʺResource Failure Rule 01‐10ʺ, SWRL is used to describe the fault rules of  temperature  sensor,  air  conditioning  or  heating  controller  and  cloud  control  service  respectively.To  better  illustrate  these  rules,  we  first  define  some  symbols.The  Resource  of  IoT  system  that  have  not  executed or received RecentBehavior (within 10 seconds) is defined asø. The Resource of IoT system have RecentBehavior, including execBehavior or takeBehavior, is defined as E.The latest behavior execution state of RecentBehavior is defined as S for success and F for failure.

rna

Firstly,  according  to  the  fault  determination  method  of  temperature  sensor,  the  fault  determination table of temperature sensor is given as shown in Table 2.  Table 2. Temperature sensor fault Diagnosis table. 

Jou

Situation  execBehavior  Result  Situation 1  E  WorkingResource  Situation 2  ø  FaultResource  Table 2  shows  a  simple  method  to  determine  the  working  status  of  temperature  sensors.  If  the  temperature sensor has not performed temperature sensing recently (within 10 seconds), as it do not  execBehavior  RecentBehavior,  then  the  temperature  sensor  is  considered  to  have  failed  (FaultResource). On the contrary, if there is a recently perceived behavior, regardless of whether the  behavior is successfully received and processed by cloud control service, the sensor is considered to  be  in  working  condition(WorkingResource).Even  if  the  cloud  control  service  fails  to  receive,  the  temperature  sensor  is  working  when  the  temperature  sensing  is  executed.As  shown  inʺResource  Failure Rule 01‐02 ʺ of Figure 6 , the decision method is expressed in SWRL.In the rule of judging no  recent behavior, the “noBehavior” Custom Built‐InsAtom is used, and the faultReason data property  is used to automatically associate a fault explanation for the resource.  As discussed in Section 2.4.4, in a healthy cabin, the Cloud Control Service receives the sensing  data  from  all  temperature  sensors,  and  judges  according  to  the  latest  temperature  perceived,  issues  the  ON  or  OFFcommand  for  air  conditioning  and  heating.Even  if  all  sensors  fail,  the  cloud  control  service  sends  Test  command  every  10  seconds  to  get  the  working  state  of  the  control 

Journal Pre-proof

resources.According  to  the  working  principle  of  cloud  control  service,  the  fault  diagnosis  table  of  cloud control service can be deduced as shown inTable 3.  Table 3. Fault Diagnosis Table for Cloud Control Service. 

lP repro of

Situation  takeBehavior  execBehavior  Result  Situation 1  S  E  WorkingResource  Situation 2  F  E  FaultResource  Situation 3  ø  E  WorkingResource  Situation 4  S  ø  FaultResource  Situation 5  F  ø  FaultResource  Situation 6  ø  ø  FaultResource  Based on the Custom Built‐Ins Atoms used by temperature sensors, we can write 6 similar fault  determination rules for cloud control service, but by observing the distribution of fault conclusions in  Table 3, we can simplify them into four 4 determination rules.As shown in Figure 6, ʺResource Failure  Rule 07ʺ expresses the main control servicedo not execBehavior RecentBehavior, then a failure must  occur  (because  at  least  the  TEST  behavior  will  be  executed),  covering  Situation  4,  Situation  5  and  Situation  6.ʺResource  Failure  Rule  08ʺ  expresses  the  sensing  behavior  of  the  temperature  sensor  recently received, but the processing fails. It can be judged that a fault occurred, covering Situation 2  and  Situation  5.It  is  not  difficult  to  see  the  Situation  that  ʺResource  Failure  Rules  7  and  8ʺ  have  overlapping Situation 5,  but it does not  affect the results  of  reasoning.When  Situation 5  occurs,  two  faultReason will occur because ʺResource Failure Rule 7 and 8ʺ are satisfied simultaneously, but the  service is still classified as FaultResource. The ʺResource Failure Rule 9 and 10ʺ cover Situation 1 and  Situation  3  respectively  as  supplements,  and  express  the  reasoning  rules  for  judging  the  working  status of the cloud control service.  According to the same formulation definition, the fault determination table of air‐conditioning or  heating control entity resources is shown inTable 4.  Table 4.Control Resource Fault Diagnosis Table. 

Jou

rna

Situation  takeBehavior  Result  Situation 1  S  WorkingResource  Situation 2  F  FaultResource  Situation 3  ø  Need Further Judge  If the  control  resource (air  conditioning  or  heating)  receives RecentBehavior, its working  status  can be accurately determined based on the handle result of the latest behavior in the RecentBehavior.  As shown in Situation 1 in Table 4, the control resource receives control command within 10 seconds  and is successfully processed, which can adequately determine that the control resource is in working  state. Convert Situation 1 and Situation 2 to SWRL rules as shown in ʺResource Failure Rule 03 and 04ʺ  in Figure 6.  However, if the control resource has not processed any RecentBehavior in the last 10 seconds, it  can  not  be  simply  judged  that  it  is  in  a  failure  state,  because  in  the  case  of  failure  of  cloud  control  service, it will also lead to air conditioning or heating not handling any control command.To further  determine the working status of control resources, we have written a CustomBuilt‐In ʺhttp TestStatusʺ  that  can  send  HTTP  requests.As  shown  in  ʺResource  Failure  Rule  05  and  06ʺ  in  Figure  6,  an  HTTP  request can be sent by passing in the controller entity (? C) and the command (Test) that needs to be  sent, and the corresponding return result (? Code) can be obtained to further determine the working  status of the control entity.This built‐in is not difficult to implement because, based on the reasoning  results of resource classification, we can explicitly extract the service address and port information of  the incoming control resource instance.  The reasoning results of the resource failure rules are shown in Figure 18. It can be seen that a  controller resource has recently been inferred as a failure state due to incorrect handling of received  control command. 

lP repro of

Journal Pre-proof

 

Figure 18. Reasoning Results of Resource Failure Rules . 

4.3. Detection of Resource Composition 

rna

Based  on  the  classification  of  behavior  and  resources  and  the  reasoning  results  of  resource  failures, we have been able to clearly model and detect reasoning rules of resource composition in the  Internet of Things system.As shown in “Resource Composition Rule 01‐08” of Figure 6, if a resource(?  R) belongs to an Internet of Things system(? S), it can automatically associate the object property of  ʺhasSensorʺ or ʺhasFault Sensorʺ for the Internet of Things system according to the failure status of the  resource.Similarly,  it  can  be  associated  with  ʺhasServiceʺ and  ʺhasFaultServiceʺ,  ʺhasControllerʺ  and  “hasFaultControllerʺ.Thus, we can get the working state of an Internet of Things system as a whole, as  shown inFigure 19, which shows the current real‐time working state of the Internet of Things system  in the health cabin. 

 

Figure 19. Reasoning results of resource composition in IoT system 

Jou

It  can  be  seen  that  the  system  is  currently  connected  to  a  sensor,  a  cloud  control  service  and  a  controller, and the controller has failed.Click on the corresponding resource link, as shown in the blue  underscore section of Figure 19, you can directly open the corresponding IoT controller resources and  show  their  specific  resource  classification  and  failure  reasons  as  shown  in  Figure  18.  When  we  re‐connect two sensors according to the system design goal, and reload the real‐time model according  to  the  method  described  in  Section  2.5,  and  reasoning  based  on  ʺPellet‐CGʺ,  we  can  see  the  latest  accessed sensors and their working status in the resource composition list shown on the right side of  Figure 19.  4.4. Automatic Control of IoT System  Based on the ʺEnvironmental Attribute Rule 01ʺ shown in Figure 6, we can accurately perceive the  real‐time temperature information of the physical environment in which the Internet of Things system  is located in the case that at  least  one temperature  sensor does  not fail. Combined  with the Custom  Built‐Ins  ʺhttpTestStatusʺ  used  in  Section  3.2,  we  can  theoretically  replace  cloud  control  service  for 

Journal Pre-proof

lP repro of

automatic control of the Internet of Things system, although we do not want to do so in principle of  not  intruding  into  the  original  Internet  of  Things  system  as  much  as  possible.Its  implementation  is  shown in Figure 6 as ʺSystem Control Rule 01‐03ʺ.  These three rules express that when the current temperature of the physical environment of the  Internet of Things is higher than 26℃, the air conditioner is turned on and the heating is turned off.  When the temperature is lower than 26 C, the air conditioner is turned off and the heating is turned on.  The air conditioner and the heating are turned off at the same time when the temperature is equal to  26℃.Although according to these three rules, there are still some gaps in the realization of automatic  control of Internet of Things system, including that we have not yet compiled rules to further classify  controller  resources  into  air‐conditioning  or  heating,  and  these  rules  are  executed  every  time  we  perform rule reasoning manually in Protégé, rather than dynamically in real time. But these problems  can  be  solved.  Depending  on  the  existing  records  of  control  behavior  of  cloudcontrol  service,  it  is  possible  to  further  identify  whether  the  controlled  entity  is  air  conditioner  or  heating.  The  second  problem can also integrate Pellet reasoner in the middleware, so as to perform real‐time reasoning and  control while temperature sensing is captured.This makes it possible for us to achieve a unified control  of  cloud  control  brain  in  all  modeled  Internet  of  Things  systems  based  on  the  semantic  knowledge  graph.  5. Conclusions 

Jou

rna

The architecture of the Internet of Things is a graphical or formal model of the composition and  working  principle  of  the  IOT  system  from  different  perspectives  and  dimensions.  It  is  the  primary  basis  for  the  design  and  implementation  of  the  IOT  system.Based  on  the  dimension  of  semantic  ontology and  the combination of theory and practice, this  paper discusses the  modeling theory and  method of semantic ontology dimension architecture model of Internet of Things system.In this paper,  a  framework  for  modeling  real‐time  dynamic  ontology  semantic  dimension  architecture  model  of  Internet  of  Things  system  is  proposed.  And  based  on  semantic  reasoning  technology,  the  model  reasoning of high‐level knowledge, which realizes resource classification and composition detection,  resource working status information and resource fault diagnosis of the Internet of Things system, is  derived from low‐level Internet of Things system behavior instances.  Future research still needs to deal with the storage and cleaning of behavior instances of Internet  of Things systems. According to the working principle of the Internet of Things system described in  Section  2.4,  a  minimum  of  180  perceptual  behaviors  will  be  generated  if  only  three  sensors  are  connected  for  10  minutes,  which  does  not  include  the  control  behavior  of  the  IoT  system  after  temperature  sensing.These  behaviors  are  currently  stored  in  the  memory  of  the  ontology  modeling  middleware  of  the  Internet  of  Things,  which  will  soon  cause  the  ontology  modeling  middleware  to  collapse  due  to  memory  overflow.  Therefore,  on  the  basis  of  guaranteeing  the  query  efficiency  of  ontology behavior in the Internet of Things, we need to study the data storage technology of ontology  instances in the Internet of Things.In addition, the real‐time state perception and fault diagnosis of the  Internet  of  Things  system  depend  on  the  recent  behavior  of  the  Internet  of  Things  system.  How  to  clean and tailor some outdated behavior of the Internet of Things system also needs further research.  In  order  to  make  better  use  of  the  semantic  ontology  dimension  of  the  Internet  of  Things  architecture model, on the basis of the discussion in Section 3.4, future research work can also study  the  technology  of  semantic  reasoning and  knowledge  graph, and  establish the central  control  cloud  brain  of  the  Internet  of  Things  system,  to  realize  real‐time  resource  state  sensing,  fault  anomaly  monitoring and more abundant intelligent semantic automatic control of Internet of Things system.  References  1. 

CHEN  Hai‐Ming,CUI  Li.Design  and  Model  Checking  of  Service  Oriented  Software  Architecture    for  Internet of Things[J].Chinese Journal of Computers,2016,39(05):853‐871.   

Journal Pre-proof

2. 

MI  Bao‐Tong,LIANG  Xun,ZHANG  Shu‐Sen.A  Survey  on  Social  Internet  of  Things[J].Chinese  Journal  of  Computers,2018,41(07):1448‐1475.   

3. 

Xu  Yuan,  Zhang  Chunhong,  Ji  Yang.  Semantic  Internet  of  Things:  Starting  with  Ontology 

lP repro of

Construction[J].Telecommunications Network Technology,2014,1(3):32‐36.    4. 

LI  Yong‐chao,  LUO  Jun‐min.  Research  on  R  easoning  on  Ontology  in  Semantic  Web[J].Computer 

5. 

Berners‐Lee,  T.  Uniform  Resource  Identifiers  (URI):  Generic  Syntax.  Availabe  online:  https://www. 

6. 

Liam. Extensible Markup Language (XML). Availabe online: https://www.w3.org/XML/   

7. 

Manola,  F.;  Miller,  E.  RDF  Primer.  Availabe  online:  https://www.w3.org/TR/2004/REC‐rdf‐primer 

Technology and Development,2007,17(1):101‐103.    ietf.org/rfc/rfc2396.txt   

‐20040210/    8. 

Smith,  M.K.;  Welty,  C.;  McGuinness,  D.L.  OWL  Web  Ontology  Language  Guide.  Availabe  online:  https://www.w3.org/TR/2004/REC‐owl‐guide‐20040210/   

9. 

Horrocks,  I.;  Patel‐Schneider, P.F.;  Boley,  H.; Tabet,  S.;  Grosof,  B.; Dean,  M.  SWRL:  A  Semantic Web  Rule Language Combining OWL and RuleML. Availabe online: https://www.w3.org/Submission/SWRL/  Overview.html   

10. 

Bassiliades,  N.  Rule  Markup  Language  Initiative.  Availabe  online:  http://wiki.ruleml.org/index.php/ 

11. 

Wei, S.; Wang, J.; Ping, L.; Min, W. APOLLO:a general framework for populating ontology with named 

RuleML_Home   

entities via random walks on graphs. In Proceedings of International Conference on World Wide Web.  12. 

Bechhofer,  S.;  Horrocks,  I.;  Goble,  C.A.;  Stevens,  R.  OilEd:  A  Reason‐able  Ontology  Editor  for  the  Semantic  Web.  In  Proceedings  of  Joint  German/austrian  Conference  on  Ai:  Advances  in  Artificial  Intelligence. 

13. 

Sure,  Y.;  Erdmann,  M.;  Angele,  J.;  rgen;  Staab,  S.;  Studer,  R.;  Wenke,  D.  OntoEdit:  Collaborative  Ontology  Development  for  the  Semantic  Web.  In  Proceedings  of  Semantic  Web‐iswc,  First 

14. 

rna

International Semantic Web Conference, Sardinia, Italy, June. 

Noy, N.F.; Sintek, M.; Decker, S.; Crubezy, M.; Fergerson, R.W.; Musen, M.A. Creating Semantic Web  contents with Protege‐2000. IEEE Intelligent Systems 2005, pp 60‐71. 

15. 

Corcho, O. Building Legal Ontologies with METHONTOLOGY and WebODE. 2005. 

16. 

Horridge,  M.  A  Practical  Guide  To  Building  OWL  OntologiesUsing  Protege  4  and  CO‐ODE  Tools.  Availabe  online:  http://mowl‐power.cs.man.ac.uk/protegeowltutorial/resources/ProtegeOWLTutorial  P4_v1_3.pdf   

18. 

Eriksson, H. Using JessTab to integrate Protege and Jess. Intelligent Systems IEEE 2003, pp 43‐50. 

Jou

17. 

Huang, T.; Li, W.; Yang, C. Comparison of Ontology Reasoners: Racer, Pellet, Fact++. In Proceedings of  Agu Fall Meeting. 

19. 

Glimm,  B.;  Horrocks,  I.;  Motik,  B.;  Stoilos,  G.;  Wang,  Z.  HermiT:  An  OWL  2  Reasoner.  Journal  of 

Automated Reasoning 2014, pp 245‐269. 

20. 

Alves,  M.B.;  Damásio,  C.V.;  Correia,  N.  SPARQL  Commands  in  Jena  Rules.  In  Proceedings  of 

International Conference on Knowledge Engineering & the Semantic Web. 

21. 

Gao Keman, Zhang Shuai, Zhao Dongfang, Liu Yi, JI Xinrong. Research on Ontology‐based Equipment  Resource 

Modeling 

and 

Management 

Informationization,2018,21(10):153‐154.   

in 

Internet 

of 

Things[J].China 

Management 

Journal Pre-proof

22. 

Ding Yafei Li Guanyu Zhang Hui. SEMANTIC SPACE‐BASED SEMANTIC COLLABOＲATION METHOD IN  SEMANTIC WEB OF THINGS[J]. Computer Applications and Software, 2016, 33(02):1‐6+16.    FENG  Jian‐Zhou1,  SONG  Sha‐Sha1,  KONG  Ling‐Fu1.  Research  on  Semantic  Association  and  Decision 

lP repro of

23. 

Method of the Internet of Things[J]. Acta Automatica Sinice, 2016, 42(11):1691‐1701.    24. 

Mcbride, B. Jena: A Semantic Web Toolkit. IEEE Internet Computing 2002, pp 55‐59. 

25. 

Compton,  M.;  Barnaghi,  P.;  Bermudez,  L.;  García‐Castro,  R.;  Corcho,  O.;  Cox,  S.;  Graybeal,  J.;  Hauswirth,  M.;  Henson,  C.;  Herzog,  A.  The  SSN  ontology  of  the  W3C  semantic  sensor  network  incubator group. Web Semantics Science Services & Agents on the World Wide Web 2012, pp 25‐32. 

26. 

DENG  Zhi‐qiang,  DENG  Lin‐qiang.  Maven  Application  In  Java  Project  Development[J].  Electronic  Component and Information Technology, 2019, 3(05):1‐4.   

27.  28. 

Kuba, M. OWL 2 and SWRL Tutorial. Availabe online: http://dior.ics.muni.cz/~makub/owl/   

ZHOU  Chang,WANG  Ze.  Design  and  Implementation  of  the  Simple  HTTP  Server[J].  Software  Engineering, 2017, 20(01):9‐11.   

29. 

Grand, M.; Knudsen, J. HttpURLConnection. In Oreilly & Associates Inc, 2019. 

 

 

Chen Guang, born in 1988. PhD. candidate. His main research interests include information processing and

 

rna

application of Internet of Thing, soft engineering, pattern recognition and multimedia technology.

Jou

Jiang Tonghai, born in 1963. PhD, professor, senior researcher at the Chinese Academy of Science, PhD supervisor. His main research interests include computer network theory and traffic engineering, big data technology, Internet of Things technology.

  Wang  Meng,  born  in  1980.  PhD,  professor.  His  main  research  interests  include  information 

Journal Pre-proof

 

lP repro of

processing, big data fusion, data clean. 

TangXinyu, born in 1975. PhD, professor, deputy researcher at the Chinese Academy of Science. His main research interests include database technology and data warehouse, data mining, data cleaning of massive data.

 

JiWenfei, born in 1991. PhD. candidate. His main research interests include information processing and application of

Jou

rna

Internet of Thing, big data fusion.

Journal Pre-proof

Conflict of Interest statement We declare that we have no financial and personal relationships with other people or

lP repro of

organizations that can inappropriately influence our work, there is no profssional or other personal interest of any nature or kind in any product, service and/or company that could be construed as influencing the position presented in, or the review of , the manuscript entitled Modeling and Reasoning of IoT Architecture in Semantic Ontology Dimension. Guang Chen

Jou

rna

2020.1.2

Journal Pre-proof

Author Statement Modeling and Reasoning of IoT Architecture in Semantic Ontology Dimension:

lP repro of

I have made substantial contributions to the conception or design of the work.

I have drafted the work or revised it critically for important intllectual content; And I have approved the final version to be published; And I agree to be accountable for all aspects of the work in ensuring that questions rlatd to th accuracy or intgrity of any part of the work are appropriately invstigated and resolved.

All persons who have made substantial contributions to the work reported in the

manuscript, including those who provided editing and writing assistance. If the manuscript does not include Acknowledgments, it is because the authors have not received substantial contributions from nonauthors. Guang Chen

Jou

rna

2020.1.2