Received 18 May 2016; accepted 26 July 2016; published 29 July 2016

ABSTRACT

In accordance with the requirements of expanding Machine-To-Machine communication (M2M), the network overlay is in progress in several domains such as Smart Grid. Consequently, it is predictable that opportunities and cases of integrating yielded data from devices such as sensors will increase more. Accordingly, the importance of Ontology and Information Models (IM) which normalize the semantics including sensor expressions, have increased, and the standards of these definitions have been more important as well. So far, there have been multiple initiatives for standardizing the Ontology and IM in regards to the sensors expression such as Sensor Standards Harmonization by the National Institute of Standards and Technology (NIST), W3C Semantic Sensor Network (SSN) and the recent W3C IoT-Lite Ontology. However, there is still room to improve the current level of the Ontology and IM on the viewpoint of the implementing structure. This paper presents a set of IMs on abstract sensors and contexts in regards to the phenomenon around these sensors from the point of view of a structure implementing these specified sensors. As several previous studies have pointed out, multiple aspects on the sensors should be modeled. Accordingly, multiple sets of Ontology and IM on these sensors should be defined. Our study has intended to clarify the relationship between configurations and physical measured quantities of the structures implementing a set of sensors. Up to present, they have not been generalized and have remained unformulated. Consequently, due to the result of this analysis, it is expected to implement a more generalized translator module easily, which aggregates the measured data from the sensors on the middleware level managing these Ontology and IM, instead of the layer of user application programs.

Keywords:

Sensor, Information Model, Ontology, Semantic Integration, Data Aggregation

1. Introduction

Standardizing the Ontology and Information Model (IM), which normalize the semantics of various objects such as sensor devices, has been in progress. (In the following, we will call “the Ontology and IM” as simply “IM”, as far as not specialized cases.) In accordance with the requirements of expanding Machine-To-Machine communication (M2M), it has been required to share the events and measured data yielded by various types of sensors among multiple machines and equipments. In particular, the more emergences of the scalable and integrated computational environments using Cloud computing there are, the more demands to make an overlay network by integrating the various and ad hoc sensor networks there will be. In order to respond to these demands, it is also required to share the context in regards to these events and measured data yielded by various sensors in a system with the same views and granularities without any dependency on particular matters of their manufacturers. Accordingly, Ontology and IM which normalize the semantics including sensor expressions and meta data, should be generalized as much as possible. Additionally, it is crucial to provide them as a service by storing these Ontology and IM in a common repository.

So far, there have been multiple efforts and initiatives for standardizing the Ontology and IM in regards to the sensors expression. One of the representative Ontologies is that by the W3C Semantic Sensor Network Incubator Group (W3CSSNIG), which describes sensors, observations and the events around sensors [1] - [3] . Whereas, another type of the Ontology and IM which gives us the categories and attributes of sensors by defining a sensor as a component of an artificial structure has traditionally existed [4] [5] . In general, various Ontology and IM are required based on multiple viewpoints and the seamless integration among them are ideally expected. Thus, there have been harmonizing activities such as Sensor Standards Harmonization by the National Institute of Standards and Technology (NIST) [6] . However, it has appeared a little ineffective on the viewpoint of the structures.

The issues to realize the seamless integration among the Ontology and IM have still remained even today when the Internet of Things (IoT) has got momentum. For example, Sensor Capability Information Model has been defined newly in [7] [8] . According to their explanation, a comprehensive standardized information infrastructure that enables sensors in their fields to observe more precisely and to facilitate cooperative observation effectively, are often shortened. In particular, the current existing approach has been insufficient in order to express the various aspects owned by sensor devices. Therefore, it looks integration oriented. In their approach, a new structure as a sensing system which includes multiple physical sensors is modeled, and several capabilities are specified to express that structure. In particular, [8] explain to us about the case of Earth observation sensors in detail. However, they are specific in the field of Geospatial Sensors and not generalized. The current insufficient maturity level of the defined Ontology and IM, together with the integration among them has negatively affected the progress of IoT [9] . That is why most of IoT applications have a certain tendency of being isolated application silos. [9] also point out the issues of Semantic Sensor Network (SSN). These are definitely insufficient accounts to actuation and other realms for IoT and its complexity. Accordingly, the new IoT-Lite Ontology has also been proposed [10] . This is more integration-oriented due to the adding of new entities such as “iot-lite:Object”, “iot-lite:Service”, rather than the existing entity of “ssn: Device”. However, it still seems to be unclear to serve expressing structures implementing the elemental physical sensors. A weakness in integration among them could potentially become an obstacle for implementing applications with severe requirements in their specifications. For instance, aggregation and calculation processes from raw data observed from various sensors are definitely required in the case of capturing the physical measured quantities of the structures such as behaviours’ parameters in robotics. The weakness in integration as one of its qualities could force us to deal with them in ad hoc approaches, and it is quite unproductive.

This paper presents a set of IMs on abstract sensors and contexts in regards to the phenomenon around these sensors from the point of view of a structure implementing these specified sensors. As mentioned earlier, the seamless integration among various Ontology and IM based on multiple viewpoints are required. The major aim of our study is to clarify and to formulate the relationship between configurations and physical measured quantities of the structures implementing a set of sensors. Up to present, they have not been generalized and have remained unformulated. Due to the above, it becomes easy to implement a more generalized translator module, which aggregates the measured data from the sensors. Then, it will convert the aggregation results into more abstract information on the middleware layer managing these Ontology and IM, instead of the layer of user application programs. This means that it would not be necessary to execute the costly preprocesses such as calculating the group average among huge numbers of values yielded by multiple sensors by the application layer. Therefore, it is expected that this could lead to high productivity in developing the new services.

Figure 1 depicts the overview of the scope that the proposed IM deals with. In this IM, a sensor is primarily regarded as an abstract component, and we define it as an entity being categorized and having attributes. Additionally, the IM will also provide a context in regards to the phenomenon and the role around that sensor from the point of view of the structure implementing that specified sensor. Additionally, we explain the results, issues and potential solutions, which were extracted through comparing the proposed IM to the existing Ontology and IM, and mapping that IM to a practical case.

The remainder of this paper is organized as follows. In Section 2 we talk about the related works, especially with respect to the Ontology for sensor fields. In Section 3, we detail our comprehensive IM. In Section 4, we clarify our assumptions about how our IM will be deployed into the implemented architecture and under use cases. In Section 5, we mention the results of our multiple evaluations and clarify our insights. Firstly, we will outline several related works, then, mention the results of our evaluation and how they correspond to our IM. Secondly, we deal with the encountered issues in our actual implementation, in particular, a semantics gap between our IM and IEEE1888. Thirdly, we discuss the operational requirements, and finally we assess the potentiality to the standardization. Section 6 is our conclusion.

2. Related Works

It is required to identify our targeting position before the survey of related works. Firstly, in Section 2.1 we clarify the corresponding position of our IM in a space categorizing the views of modeling and interpreting the objects. In Section 2.2, we talk about the related works corresponding to “Sensors in sensing” category, then in Section 2.3, we talk about the related works corresponding to “Sensors as Physical Components” category. Finally, other studies will be explained in Section 2.4.

2.1. Position of Our IM in the Space Categorizing the Views of Modeling

When categorizing the existing Ontology and IMs on the viewpoints of modeling and interpretations of the sensors, there are at least three categorical aspects about sensors as depicted in Figure 2. The first is “Sensors in sensing” on the left side of Figure 2. The second is “Sensors as Physical Components” on the right side. The

last is “Sensors from other viewpoints”. The major instance of the first category is Semantic Sensor Network (SSN) by W3C Semantic Network Incubator Group (W3CSSNIG) and it covers the Ontological items about event, stimulus and observations around sensors [1] - [3] . The second one is based on the Product Ontology which has mainly been developed in the area of the Continuous Acquisition and Life-cycle Support (CALS). When the sensor is regarded as a component, this Ontology is available for identifying the category of a sensor and specifying its features on the identified category, [4] [5] . The both of them have been expanded on individual motivation and needs during the individual developing stages. Most of the previous efforts to define the existing Ontology and IMs might reflect from any thoughts of these two categorical aspects, and some cases could include both of them. In this sense, there could be a distribution about how close individual Ontology and IMs are plotted to each side.

Our IM could mainly be placed in the middle area including both aspects. In particular, the Partial IM explained in later Section 3.1 and 3.2 are reflected from the concepts of “Sensors as Physical Components” in Figure 2. On the other hand, Partial IM with regards to Raw Event Data from Sensors and Aggregated Data mentioned in later Section 3.3 corresponds to the concepts of “Sensors in sensing” in Figure 2.

2.2. Category of “Sensors in Sensing”

As stated previously, the typical major work in this category is SSN by W3CSSNIG [1] - [3] . Except the works by W3CSSNIG, multiple projects have tried to define similar frameworks. For example, the national project titled as “The George E. Brown Jr. Network for Earthquake Engineering Simulation (NEES)” had also disclosed their IM on the specification document [11] . [12] is the summary of their IM. In the NEES documents, they explicitly defined their requirements on sensors, such as the requirement to categorize sensors as types; furthermore they also defined the configuration model titled as “PrimaryEquipment” and “SecondaryEquipment”. They also touched on the standard for the exchange of product model data, ISO-10303 Industrial Systems and Integration-Product Data Representation and Exchange (STEP) which is introduced in the next section. However, their adoptions, especially the specifying the requirements around sensors seemed to be not rigid enough. In particular, their definition levels on the conceptual categories and attributes for sensors had remained at the following level; “sensorType” as a string is information sensed by the sensor, e.g. acceleration, pressure, displacement, strain and temperature, etc. The “outputQuantity” as a string is quantity that sensor puts out in response to the input, it can be voltage, current, charge, or human read. We have considered this level seems to be insufficient and vague for the category and attribute definitions, if aiming to establish the interoperability with using sensors. Therefore, they seemed not intent on having the exact definitions on sensors on IM, because of their rudimentary level of the definitions.

[13] introduce another implemented Ontology as a prototype at the other project. In particular, they explained their approach to build the sensor Ontology by referring SensorML, IEEE SUMO and ISO19115 with their extensions, and mapping them to Web Ontology Language (OWL). They embodied the sensor classes by using their IM. However their primary target was the image sensor for an unmanned aerial vehicle (UAV), and we are concerned about the differences derived from gaps in the features, because a generic sensor is usually related to a physical quantity. This work also took the approach to make the sensors abstract with referring SensorML as one of their bases.

There are other works, in which the context of observation, and use cases were independently dealt with. We can find out an instance of them in [14] . In accordance with the more expansion in grasping spatial and temporal events by sensors, there have been more demands in e-science whereby the results and contexts of the observations should be more thorough. In order to describe the actual observations more closely, they should be tagged with location, time, ownership, instrument and measurement. The actual data management in scientific fields has generally been specialized on individual area without normalization across them and it was difficult to exchange the data beyond the borders between fields. In their work, a guidance of IM in related to query containing What, Where, Which, When and Who is provided in order to clarify the definition scenario more. Furthermore, it also provides the basic viewpoints for defining the Ontology in a wide sense. However, there are very few explanations about the relationship with SSN.

In general, our work should be regarded as a new instance of the Ontology integration in the sensor domain. Another instance which aims at a similar purpose is for example the work explained in [15] based on the modularity. This is the work to orient the integration between sensors and Semantic Web. And they provided the novel semantic definition focusing on the sensor networks domain, and methodology to contribute interoperability, in order to tackle the issues derived from inexistent standards to realize the interoperability including high level knowledge among systems. In this work, they proposed their modularity and extension and mentioned the following three domains; External, Main and Extended domains. Furthermore, they depicted the semantic network structure showing the multiple relationships which a sensor instance has. The Categories and Attributes in our sense are expressed as Features. However the capability of expression seems to remain at the general level and they are implemented in OWL.

2.3. Category of “Sensors as Physical Components”

The representative Product Ontology in which a sensor is regarded as an electronics component, has been studied for a long time and the essential parts were mainly standardized as ISO13584-42, IEC61360-1 and IEC61360- 2 [16] - [18] . In particular, ISO13584-42 is called as Parts Library (PLIB) in general [16] . The outlines of them are summarized in many documents such as [4] . As characteristic aspects of the PLIB, there are the following six principles: The first is that the product categories are represented by classes, one of which is defined by a number of attributes, including identifying attributes. The second is that properties specify aspects by which a product can be described. They are defined by identifying and semantic attributes defining data types, units, and value lists. This property is equivalent to the Attribute in our IM. The third is that classes potentially have an inheritance which means that an instance of class has a relationship to other classes by using an “Is_A” relationship, although PLIB itself supports both of the tree-structured “Is_A” hierarchies and ‘Has_A’ relationship. The forth is that properties are related to classes by two different relationships, “Is_Defined” and “Is_ Applicable”. The fifth is that classes will be related by the case-of relationship which is mainly used for referencing elements of other Product Ontology. The sixth is that products can consist of a set of the components. One product can be a component of another product. The last principle is applicable to any objects rather than only sensors, because the product and the component are abstracted. However, the relationships between the last principles and all of the others may be meaningful for sensors in particular, because we need to clarify the relationships between sensors as components and the superior product, if trying to grasp the physical features of the product. In [19] , we can see an instance of applying the above standards [17] [18] .

In [5] , the essential structure of the Common Information Model (CIM) in RDF version of IEC61970-501 applied for smart grid is introduced as Figure 3. This is closely related to the previous PLIB. As shown in Figure 3, a class may have relationships to single or multiple properties, individual of which has the own data type. And classes related to a sensor must obey the above constraint. In [20] , the concrete instance specified by PLIB of sensors and the Product Ontology is introduced. In this work, they evaluated the actual efficiency by applying PLIB in the sensor field.

2.4. Other Categories

Besides the areas in previous sections, there are several related studies. In this section, some of them are intro-

duced. [21] is about dealing with the real time data generated by multiple sensor networks with definitions of spatial and temporal aspects, and this is oriented towards harmonizing with Geographic Information System (GIS). It includes their definition of IM containing sensors. Their IM does not contain the configuration aspect specified in PLIB and categories, although it involves the sensors’ aspects and agility. However, there are several points which we should refer to, such as harmonizing with GIS and defining a measurement consisting of relationships with multiple sensors.

[22] mention the aspect of process and architecture in integrating the multiple sensor networks. This is an explanation on the viewpoint of users of the Ontology, rather than the theory related to integrating the Ontologies. However, three instances of the Ontology are referred when translating a raw XML instance by the (Resource Description Framework) RDF Wrapper during processing these data gained through the observation with a dynamic aspect. In particular, in their RDF common model, Sensor class represented by several items such as identification, type, characteristic, temporal and spatial attributes, and Measurement class, are contained. Furthermore, the Observation and Measurement (O&M) standard is adopted. Therefore it has a close relationship with our work.

[23] propose the novel approach related to the advanced aggregation functionality, and touches on the architectures of data processing. In particular it mentions the characteristics of data and how to represent them. This suggests several important points. However, the following point as one of our motivations is still vague; how to make an interpretation from raw sensors’ data under the constraints from surrounding structures.

3. Proposed Information Model

Our IM mainly consists of the following four sub parts. The words contained in round brackets mean the schema name representing the corresponding part, and by using the prefix, the individual class assigned to which part is indicated. Furthermore, common classes across the four parts are tagged with the prefix “COM”.

1) Partial IM of Metadata in regards to Sensors and Measured Objects. (Metadata (Prefix: META))

2) Partial IM in regards to Configuration and Deployment of Sensors and Structural Measured Objects. (Configuration (Prefix: CON))

3) Partial IM in regards to Raw Event Data from Sensors and Aggregated Data. (Data (Prefix: DATA))

4) Partial IM in regards to Data Accessing. (Permission (Prefix: PER))

Besides the above four partial IMs, we define some partial IMs such as classes for managing control targets. However, these should be omitted here because of their minor roles. The adopted notation for the above partial IMs is the class chart of UML (Unified Modeling Language).

3.1. Partial IM of Metadata in Regards to Sensors and Measured Objects

Figure 4 shows class organization of this partial IM, and Table 1 gives us the definitions of individual classes.

This partial IM deals with set of categories with respect to sensors and measured Objects, and attributes to define the features of categories. Typical instances of the above category of a sensor are for example “Optical Sensor” and “Current Meter”. And typical instance of an attribute is for instance “Current” as the physical quantity for “Current Meter”. Class (META) Category which means the above category has conceptually the equivalent structure of that in ISO/IEC11179 [26] . We specialize this class into particular sub categories such as class (META) DeviceCategory and class (META) ProductCategory depending on the targeted type; a sensor or a measured Object. In order to specify and identify the features of individual category, a category has relationships to one or multiple instances of class (META) Attributes. In Figure 4, we express it in a term “Attribute” based on the concept of ISO/IEC11179. However, we have another term in the equivalent concept, “Property” in CIM (Common Information Model) of IEC61970. We also specialize this class (META) Attribute according to a sensor or a measured Object. As each of the features is related to a physical unit and measured conditions, class (META) Attribute has relationships with class (META) Unit and class (META) MeasuredCondition. Class (META) Attribute also has an aggregatable structure itself to be able to have a structural data type. Only class (META) ProductAttribute has a relationship with class (META) StatisticsType. This is because of our interpretation that an entity which carries out the aggregation process of the measured data yielded from sensors, is only the measured Object embedding the sensors, rather than the sensors themselves. In this sense, our interpretation in the practical operation is regarded independently from the context that a sensor has the own internal structure, although we explicitly define class (CON) SensorSystem in Figure 5. This is substantially independent from the semantics in SSN by W3CSSNIG, which will be mentioned later. It is quite usual that the categories and attributes receive some maintenance for long term since being released. Even after being maintained, it is still required to refer the previous state of data in regards to the categories and attributes. Therefore, we need to adopt a version management. Accordingly, we also need to identify the validity of a version such as “Obsoleted” or “Valid”. Class (COM) Status which means the condition of the instance is commonly referred to for this purpose by several classes in the figures.

3.2. Partial IM in Regards to Configuration and Deployment of Sensors and Structural Measured Objects

Figure 5 depicts a class organization of this partial IM, and Table 2 gives us the definitions of individual classes. This partial IM treats the structures among sensors and measured objects and also includes the classes to describe their deployment. (CON) MeasuredObject is the class to describe a measured object and inherited into the following two subclasses, (CON) Product standing for the product in the final state, and (CON) Component which means an internal component. They have composite relationships titled as “consisting of”. A sensor corresponds to class (CON) Sensor as an abstract class, because we consider the internal assembled structure of the sensor, itself. Class (CON) Sensor and class (CON) MeasuredObject have links named as class (CON) Assignment. Otherwise, class (CON) Sensor has a relationship with class (COM) Location meaning the deployed location of the sensor through the class named as (CON) Deployment. This is because sensors as components of the sensor network are widely spread into the environment. Therefore, we need not only class (CON) Assignment, but class (CON) Deployment as well for specifying the location exactly. As class (CON) Sensor has aspects of a component, it is potentially possible to have an inheritance from class (CON) Component. In spite of considering the internal assembled structure of sensors, however, we neglect the explicit inheritance from class (CON) Component expressing the aspects of a component in our actual IM. This is because we aim to make a more flexible context and interpretation in regards to the behaviors of the measured Objects by avoiding making the tied constraints which derive from the relationships between class (CON) Sensor and class (CON) MeasuredObject. Class (CON) MeasuredObject has the relationship with the instance of class (CON) SettingCondition, because there is a possibility that the features of class (CON) MeasuredObject will be influenced by an installing and setting condition. As this class organization includes the aspect of configuration management, we also need to apply the version management here. Accordingly, it is required to identify the validity of the version. Thus, Class (COM) Status which means the condition of the instance is referred also here.

3.3. Partial IM in Regards to Raw Event Data from Sensors and Aggregated Data

Figure 6 shows class organization of this partial IM, and Table 3 gives us the definitions of individual classes. This partial IM primarily deals with the classes to express event data yielded by sensors and aggregated data. However, at the top layer of Figure 6 the relationships around class (CON) Sensor are also depicted for expressing another aspect. There are two subclasses for (CON) Sensor. The first is class (CON) GenericSensor. This is applied for generalized sensors of which an industrial standard organization such as International Organization for Standardization (ISO) specifies the standardized features. These features are usually specified in the published documents. In this case, an instance of class (META) DeviceCategory is referred as obeying the class organization in Figure 4. The second is class (CON) CustomizedSensor. This is applied for exceptional cases. Due to the rapid expansion of sensing technologies, there are potentially some special cases where a specialized sensor is developed without any standards. Accordingly, this class (CON) CustomizedSensor is prepared for these exceptional cases. In these cases, this class has the direct relationship with class (META) DeviceAttribute, because we must describe the features of sensors for whatever reasons, even though there is some ambiguity in specifying the category of the sensor.

Class (CON) Sensor has relationship with class (DATA) RawDataFromSensor, an instance of which is equivalent to the individual event yielded by a sensor. In this class, the items in regards to a physically measured quantity and the timestamp are included. Class (DATA) RawDataFromSensor can be aggregated within its

own structure, because the referred class (META) Attribute by this class also has an aggregatable structure to be able to have a structural data type as mentioned. Accordingly, subclass (DATA) SetOfRawDatafromSensor for aggregating instances of another subclass (DATA) ElementalRawDataFromSensor meaning the class for an elemental data is also defined. Class (CON) MeasuredObject has the indirect relationship with class (DATA) Extracted Fact Data for Object through class (DATA) ObservedObjectDataManagement that manages the aggregation and the context. The aggregation will generally be carried out on various viewpoints. Accordingly, this class (DATA) ObservedObjectDataManagement functions as the superior manager of set of instances of class (DATA) ExtractedFactDataForObject in order to maintain the various meta data of these viewpoints. Furthermore, class (DATA) ExtractedFactDataForObject has a relationship with class (META) ProductAttribute, because this class has the nature of aiming at features of the specified measured Object.

Figure 7 includes a graph of time series values of a physically measured quantity plotting by timestamps, both of which are recorded on the instances of class (DATA) RawDataFromSensor. In this case, the new instance of class (DATA) RawDataFromSensor arises within Δt as an average interval. On the other hand, there are also two graphs corresponding to other instances of class (DATA) ExtractedFactDataForObject in Figure 7. They are tagged by labels “series.1” and “series.2”. Class (DATA) ObservedObjectDataManagement corresponds to the class of managing the meta data in the aggregation such as these “series.1” and “series.2”. Regardless of number, the instance of this class can be generated depending on the aggregation conditions and context, such as how to manipulate the instances of class (DATA) RawDataFromSensor. The depicted cases in Figure 7 are assumed with only single sensor. However, the cases of multiple sensors regardless of categories can be also accepted. And class (DATA) ExtractedFactDataForObject has the relationship with class (META) ProductAttribute in Figure 6, because of referring to an instance of the MeasuredObject directly. Furthermore, in order to generate an instance of the class (DATA) ExtractedFactDataForObject by using multiple instances of class (DATA) RawDataFromSensor, there is another relationship as a constraint between them. Figure 8 depicts an example of models of the constraint. Class (CON) AttributeConstraintsForMeasuredObject is the class to manage the constraint conditions by specifying instance set of class (META) ProductAttribute, which individual instance of (CON) MeasuredObject has. An instance of the class (CON) AttributeConstraintsForMeasuredObject marshals instances of classes (CON) SpeficiedDeviceCategory and (CON) SpecifiedDeviceAttribute. These classes specify which instances of the class (META) DeviceAttribute under the class (META) DeviceCategory are related in the constraint. It is allowable to specify the complicated cases using multiple types of sensors as mentioned. However, the actual organization is influenced from the aspect of algorithms in aggregation process, and also relies on the individual requirement. Therefore, we have avoided putting the constraint into the class organization explicitly.

3.4. Outline of Partial IM in Regards to Data Accessing

This partial IM primarily deals with classes and relationships for the authentication and authorization for data access. We do not adopt the role based access control model (RBACM) in order to avoid increasing number of

classes, although it is general to apply the RBACM [27] . Detailed information with regard to this is omitted in this paper due to space constraints.

4. The Relationship between Information Model and Implemented Architecture

In this section, we clarify our assumptions about how our IM will be deployed under the configuration of the implemented architecture and use cases. As mentioned in [28] , the major stream of IM for the Smart Grid area is based on CIM as IEC61970. However, we have believed that there are potential requirements in regards to harmonization with the new architecture which has the overlay features, when considering how to take legacy and proprietary configuration into the new architecture. Our current implementation adopts IEEE1888 as specified in [29] with some modifications. Figure 9 depicts the network architecture specified in IEEE1888.

According to [29] , the outline of the architecture is specified as follows; “Gateway component has physical sensors and actuators. It generalizes the data model and the access method for those devices, encapsulating each physical (field-bus) data model and access method. Storage component archives the history of data sequences. The written values from other components should be permanently stored in the backend disks. It provides the archived values to the components that have requested them. Application component provides some particular works on sensor readings and actuator commands. It can have user interface to display the latest environmental state. It can also allow a user to input some schedules of actuator settings, and it can as well analyze some sensor data in real time and provide the result as a virtual device. Finally, Registry works as a broker of GW, storage, and APPs. The main role of registry is to bind those components appropriately and autonomously. It is separated from the data-plane.”

Figure 10 depicts the modified deployment chart in UML based on the elements in Figure 9 and shows how to deploy the classes and schemes of our IM which were defined as four partial IMs in Figures 4-6. According to the requirements of the implementation, APPs and Storages defined in Figure 9 should be specialized more as shown. The instances of any classes under the schema (DATA) such as “(DATA) RawDataFromSensor” are stored into the individual Storages. Whereas any other instances of any classes under other schemas besides (DATA) are deployed into the Registry (Repository). In particular, we assume that the Registry (Repository) should be implemented in singleton according to the characteristics of this functionality, in which the management of meta data should be centralized. However, the actual implementation of it, whether it would be implemented in singleton or decentralized approach with replicas, could depend on the requirements in regards to scalability. “(DATA) RawDataFromSensor” as event and measured data from sensors should be deployed in the spread distributed Storages because of the requirement of scalability. Accordingly, the cardinality constraint on them is specified as more than one. On the other hand, “(DATA) ObservedObjectDataManagement” and “(DATA) ExtractedFactDataForObject” which are related to aggregation, strongly depending on the meta data. Therefore, both of them should be nearly allocated to the Registry (Repository) with the close connecting, in order to avoid a needless latency caused by accessing these meta data under the distributed management.

5. Evaluations and Consideration

In this Section, we mention the results of our multiple evaluations and our consideration. In this paper, we do not touch on the evaluation from the viewpoint of aggregation for the specified structure, because the actual organization is influenced from the aspect of algorithms in aggregation process, and this seems to be beyond the scope of our paper. Therefore, the following four items are focused on. Firstly, we explain the relationship between our IM and the existing Ontology and IM, in particular, Semantic Sensor Network (SSN) by mentioning the correspondence to our schemas in Section 5.1. Secondly, we deal with the encountered issue in our actual implementation, in particular, a semantics gap between our IM and IEEE1888 in Section 5.2. This suggests to us that there is a certain requirement to put another class having a role for bridging and accommodating the structure and the granularity of the scope of observation. Through the implementation, we revealed that there is still insufficiency in our IM. Thirdly we mention in Section 5.3, issues in the practical operations. Finally, we evaluate the potentiality of standardization in Section 5.4.

5.1. Comparison to SSN

SSN by W3CSSNIG that corresponds to the “Sensors in sensing” in Figure 2, has been reported comprehensively in [1] . [3] is a partial survey on multiple projects relating to the standardizing effort. The report in [2] corresponds to a summary of the previous [1] . And [30] discusses on the efforts of the existing IM of sensors and Semantic Sensor Web. SSN ontology was defined as Web Ontology Language (Second Edition: OWL2), and gives us the semantics of sensors and Observation related to these sensors. There are four remarkable features as follows: the first is to define the pattern of “Stimulus-Sensor-Observation”, that means the relationship among the sensors and the events captured by these sensors. The detail is depicted in Figure 11 (the original figure is Figure 2 in [2] .) The second is to assume that multiple ontologies are combined. We can confirm the relationships among multiple Ontologies in SSW as depicted in Figure 12 (the original figure is Figure 2 in [30] .) The third is an indirect relationship with the items “Unit of Measurement”, “Hierarchies of Sensor Types” and “Features”. They are explicitly dealt with in the Product Ontology. And the last is to contain the following four perspectives: The first perspective is the sensor perspective which focuses on what senses, how it senses such as degree of precision, and what is sensed. The second is the system perspective which focuses on systems of sensors and deployments. The detail is depicted in Figure 13 (the original figure is Figure 4 in [2] .) In the scope of the deployments, the various lifecycle stages such as “Installation”, “Maintenance” and “Decommissioning” are also contained except “Location”. The third perspective is the observation perspective which focuses on observation data and related metadata and the fourth is a feature and property perspective. The former observation perspective is related to the context of a stimulus as an input shown as the pattern of “Stimulus-Sensor-Observation”. And it corresponds to judgement of an event. The later feature and property perspective focus on what senses a particular property or what observations have been made about a property.

Figure 14 depicts the correspondences between SSN and our defined IM. The major differences between them are as followed:

1) There are differences on the aims and use cases between them. Our IM is mapped on the different meta category from that of SSN, when we apply the meta category about modeling features such as “conceptual model level” and “implementation model level”. SSN tends to remain at the conceptual model level, and gives us the comprehensive semantics and contexts. Whereas, in our IM, some constraints for implementation such as those

in Figure 8 and several items pointed out in Sections 3.1, 3.2 are also included. Based on this, there are some risks to retain our IM at more narrow sense. This derives from our intention that aggregation from the raw data yielded by the sensors should be treated on the middleware layer which manages our IM, instead of the layer of user application programs.

2) Our IM will give a context in regards to the phenomenon and the role around that sensor from the point of views of the structure containing that specified sensor, rather than the simplified aggregation sets of the sensor seen in general.

3) In spite of the aspects that a sensor has as a product, SSN seems to have a lack in viewing sensors explicitly on these aspects. Otherwise, the meta data in our IM prioritizes to be as a part of “Product Ontology”, sensors and measured objects are explicitly categorized and having a set of attributes to express the physical quantity. SSN has a tied relationship with OGC (Open Geospatial Consortium), and are influenced from the remote sensing area. In other words, some dependency on the particular application areas might be allowed and accepted for SSN.

The following explanations are the results of individual comparison seen in Figure 14. In our schemas such as Common, Metadata, “Unit of Measurement”, “Hierarchies of Sensor Types” and “Features” which are not regarded as the primary roles in SSN, are treated explicitly. Therefore, it is difficult to identify the direct correspondence between our Common, Metadata schemas and perspectives in SSN. However, as the sensors and features are definitely referred to, we believe that there must be some indirect links. On the other hand, Sensor Perspective of SSN explicitly includes items in regards to “Accuracy” and “Resolution”, although our IM does not include the corresponding identifiable classes. Our IM does not deal with these items, because they can generally be defined as instances of class (META) Attribute. In the remote sensing applications which SSN might primarily target, the accuracy is one of critical factors. Thus, due to these differences in background, the above conceptual gaps might arise.

Our Configuration schema corresponds to the System Perspective of SSN, although that remains at an incomplete matching. For instance, the deployment in SSN contains not only location, but the aspects of lifecycle as well. Whereas, we recognize that it corresponds to updating the state of the structures expressed as the measured Objects. And that should be handled by updating the current version of instances of class (CON) MeasuredObject. Both are considered about temporal aspects, however it is not the complete correspondence.

As for both following Perspectives in SSN, Observation Perspective and Feature & property perspective, there are some ambiguities in their correspondences to our IM. The former is related to the interpretation and context in regards to stimulus as an input specified in the Stimulus-Sensor-Observation pattern, and corresponds to judgement norms for event data. This superficially corresponds to our sub schema containing class (DATA) ExtractedFactDataForObject. However, we can recognize some differences between interpreting the aggregation results produced from events and measured data yielded by sensors in SSN and those of our IM. Accordingly, they are not conceptually in the complete correspondence. Furthermore, in some cases, interpretation during the Observation might be totally independent from just aggregating events and measured data yielded by sensors. Thus, it is hard for both Perspectives to neglect the relationships to class (DATA) RawDataFromSensor completely. Correspondence to our Permission Schema is not explicitly treated in SSN, because of its nature with regard to practical implementation. Therefore, there are no obvious relationships from our Permission Schema in Figure 14.

5.2. Revealed Issues in Actual Implementation

In this section, we mention the revealed issues related to our IM in the actual implementation by using IEEE1888. The issue is that we still need to apply more of an abstract sensor model having a role for bridging and accommodating the structure and the granularity of the scope of observation. This means it will be necessary to import another layer structure in our IM. As Figure 15 depicts, the model of the relationship between sensors and values as the measured data from them is expressed as a tree structure in IEEE1888. Sensors correspond to the abstract “Points”, and events and measured data yielded by sensors are expressed as “Values”

meaning physical quantity with timestamps. And a set of “Points” are managed under an instance of “PointSet”. Identification of categorized sensor and meta information in regards to “Value” are specified through the URI attached on the individual “Point” functioning as an annotation. As a sensor is abstracted as a “Point” expressing a data source, the internal configuration of individual sensor should be treated by implementers of IEEE1888. Therefore, it is potentially allowable to map them with multiple interpretations, in particular about cardinality constraints.

The relationship is obviously simple when we make a correspondence between a sensor and a “Point” within interpretation of one-to-one. In this case, we can identify the “Point” by using the deployment information of the sensor. However, when we need to handle some complicated cases, such as sensors having the internal configuration due to their complication or sensors being expressed with multiple properties and attributes, it is required to adopt a conceptual model like CIM depicted in previous Figure 3. According to the nature of the “Point”, that should be specified by the combination consisting of the identification of the specified sensor and the specified attribute which the category of the mentioned sensor has. In this case, the sensor itself should be mapped to an instance of “PointSet”, and it is not conceptually equivalent to mapping to the “Point”. When specifying the attributes of the sensor due to the above background, only adopting IEEE1888 becomes insufficient for handling the complete information. Therefore, it is needed to implement a query processing to the Registry (Repository) in order to gain an attribute set of the specified sensor. And this procedure should be carried out as an unconventional preprocess of the protocol defined in IEEE1888. These treatments derive from the narrower scope of information defined in IEEE1888.

Furthermore, we also have concerns about the difficulty in specifying the values of attributes related to the category of the specified sensor, when considering the practical operations. Usually the compliance from standards including specifying these attributes is necessary, when a categorized sensor as a product is released into actual markets. However, complying with these by the standards completely sounds empirically difficult. Without complete compliance, it would not be guaranteed to gain or prepare the required information. This could cause some cases where values as the physical quantity yielded by sensors in unconformity could not be managed in the storages in order. If we were to ignore these compliances, the functionalities such as seeking suitable sensors to traverse by applying the standardized Ontologies, and calculating group averages among huge numbers of sensors, would depend on the high cost preprocessing, because of taking individual differences in configuration and features into account. Thus, we could greatly lose the performance of operationalization.

Conversely, we admit that we still have some solutions for managing the semantics in spite of an existing weakness. The attributes are managed as depicted in Figure 4. However, in order to make managing instances of sensors more flexible, it should be adopted to manage individual application of categories on individual sensor instances, based on the guidance specified by the class organization in Figure 4, instead of direct reference from (CON) Sensor to (META) DeviceCategory depicting in Figure 5. This has a similarity to the two relationships of “Is_Defined” and “Is_Applicable” explained in Parts Library (PLIB) of ISO13584-42 [4] [16] . Embodying the above is depicted as Figure 16. In this figure, we put a new conceptual class about sensor as Class (CON) AbstractSensor in order to introduce the common model of the individual actual sensors. Additionally, some parts of the class organization drawn in Figure 4 and Figure 5 are also imported for guiding the other native relationships. This improvement means treating differences harmoniously between the model and actual implementation by adopting the layer structure in the Ontologies and IMs. By this solution, it could be expected to fix the issues mentioned. However, as a negative influence, the entire organization of our IM implemented in the Registry (Repository) would be more complicated. And the procedures to maintain the meta data in the Registry (Repository) would also be more troublesome.

5.3. Issues in the Practical Operations and Potential Solutions

In this section, we mention the issues in the practical operations and their potential solutions

1) Due to the rapid expansion of sensing technologies, the new types of sensors which are based on the new principles of sensing, measuring, and new products have always been, invented, developed and commercialized. Thus, we need to take into account how deal with these new emerging, specialized and customized sensors. Clearly, we need to consider not only the treatment for generic sensors, but also that for customized sensors, a typical instance of which we can see in the remote sensing area. Even for customizing cases, we rigidly need to define the attributes of these categories and comply with them. In maintaining the Metadata schema, we need to start from creating an instance of class (META) Category due to constraints from reference as seen in Figure 4. However, it is really commonplace to become a time consuming work when trying to define the type of a sensor rigidly until being a matured definition, because it must rely on experts’ knowledge and discussions. Therefore, in our IM, we implemented the class (CON) CustomizedSensor, and also prepared the space for instances of class (META) DeviceCategory named as “emerging sensors”. So that, we can handle these exceptional cases in the new emerging, specialized and customized sensors, by specifying that instance “emerging sensors” and making direct links between the instance of class (CON) CustomizedSensor and new created instances under the class (META) DeviceAttribute. When dealing with modeling, it should be considered a practical and operational requirement.

2) When importing the data contents of the Metadata schema from multiple data sources to make the Metadata be more of an expressional richness, we need to clarify the contexts of instances of class (META) Attribute in the importing process. In our actual evaluation on the class organization in Figure 4, we referred to the ECALS dictionary which has a strong reputation [31] . However, we found out that there were some shortages of definitions, especially for that of (META) DeviceAttribute in that dictionary. For instance, we could not find anything about “Electric Current” for “Electric Current Sensors”, rather than the defined “Terminal Value”. This is because this dictionary was originally aimed to establish standardized expressions of the electronic components and devices mostly for electronic commerce, and there are some mismatches of the purposes with others like SSN. Eventually, these mismatches derive from the differences of viewpoints related to use cases. Therefore, it is naturally required in defining the instances of class (META) Attribute, to use them differently for different objectives after clarifying their suitable contexts. This seems to be related to the two relationships of “Is_De- fined” and “Is_Applicable” between the Properties and the Classes in PLIB of ISO13584-42 [4] [16] , as already pointed out.

5.4. Evaluations on the Potentiality of New Standardization and the Native Flexibility

Finally in this section, we evaluate our proposing IM on the two viewpoints about the potentiality of new standardization and the native flexibility. As for the possibility to the new standardization, it is still insufficient and there is room for improvement because of the following two reasons: The first reason is its insufficient basic stance. The two following points are to be considered: the first one is to reveal several issues that have arisen in integrating pieces in the multiple standards, which have evolved independently or under loose relationships in their focused domains. And the second is just to propose some potential solutions with evaluation results. In this sense, our work is not intentional for establishing the new standards.

The second reason is the native orientation which our IM has. Based on the following assumption on the standardization activities, it is obvious; as the industrial standard should be defined to establish a common understanding on the trendy major challenges at that time, the targeted challenges and basic models, furthermore stances and strategies on them could naturally change according to expansion of the focused areas. In this sense, it might be quite difficult that a standard itself can enjoy its own position without any evolutions or declinations. Accordingly, it should be naturally accepted that the standards themselves should have changeable and integrative abilities as their natives. In the case of the natives of IMs, it might be more general to express them as a conceptual and meta model rather than those as an implementing and architecture oriented model. However, there are naturally certain cases where IMs themselves should be reconfigured at the implementation stage due to solving various constraints. As mentioned previously, our IM is not purely oriented to a conceptual model, and partly includes some elements influenced by the implementation. This means that there is certain disadvantage for standardization in what it is natively.

However, we also need to take another view point in regards to the flexibility to changes into our account. That is about whether the class organization is defined at the level of the first order language of the targeted space or on the upper level as the meta language. As pointed out previously, Sensor Perspective of SSN explicitly includes items in regards to “Accuracy” and “Resolution”. Whereas, our IM does not contain these items, because they can be defined as instances of class (META) Attribute. This derives from our stance and policy in which the class organization should be abstracted as much as possible. Under this policy, the differences among the implemented IMs become flexibly manageable and supportable by manipulating and replacing the content instances. In this sense, the native flexibility of our IM should not be denied, in all fairness.

As our conclusion, we can say here that there are still some issues for being contributable directly to standardization activities without any improvement; however we can also highlight that our IM has sufficiently the flexibility, the capability to which has been required in standards for a long time. In particular, it is still difficult to completely exclude the caused ambiguities when importing and integrating with another independent element, although there has been a long term effort to develop and improve on the modeling sensors themselves, their behaviors and their contexts by many initiatives such as SSN. This fact about that ambiguity suggests that there are still other potentialities of similar risks in future due to another requirement about importing an independent element. In this sense, it should not be negatively conservative to consider establishing a new standardization which can be responsible for the requirements of sensitivity to the integration. We believe that due to our work on this IM, we can make a sufficient contribution towards this.

6. Conclusions

In accordance with expanding the network overlay, it is foreseeable to increase the opportunities of the data integration in sensor network areas. Accordingly, we presented our IM, which is highlighted on the integration from the point of view of a structure containing the specified sensors in this paper. Our IM is proposed due to responding to the potential requirements for suitable solutions to the above. The above points have been vague in the existing Ontology and IM. Additionally, we pointed out the issues through our following evaluations; comparison to the existing Ontology and IM, and mapping it to the actual implementation. The comprehensive conclusions are summarized as follows:

1) We clarified the relationship between configurations and physical measured quantities of the structures implementing a set of sensors.

2) As the results of comparison to SSN, we reconfirmed that our IM is oriented to architecture and actual implementation due to taking the practical operations into account.

3) However, we confirmed that we could relatively make a balance in building our IM by integrating the partial related Ontologies and IMs which have individual backgrounds and outlooks. Furthermore, we also confirmed the differences between them. And we also confirmed the pros and cons for pushing the standardization. In particular, those in the native flexibility were identified.

We believe that our evaluation including the consideration is a meaningful and remarkable step for improving and developing the Ontology on sensors for more capability and also for promoting the continuous semantic integration. However, we revealed the issue that we need to further implement a concept of an abstract sensor model for accommodating the structure and granularity of the scope of observation. As mentioned, this is caused by an assumption gap with respects to cardinality constraints between our IM and a particular protocol. This suggests a requirement of a multiple layer structure in our IM.

As for the future works, the above provisions should be verified more through the actual implementation. And it is also required to purify our IM more into a conceptual and meta model which is contributable for the standardization. Furthermore, we have also felt that it is required to clarify the meta features in regard to “acceptability and flexibility to integration” across the partial Ontologies and IMs.

Acknowledgements

Prof. Hayashi of the University of Aizu gave us several helpful comments on this research. Here, we express our appreciation and gratitude.

Cite this paper

Shinji Kikuchi,Akihito Nakamura,Daishi Yoshino, (2016) Evaluation on Information Model about Sensors Featured by Relationships to Measured Structural Objects. Advances in Internet of Things,06,31-53. doi: 10.4236/ait.2016.63003

References