Upload
others
View
7
Download
0
Embed Size (px)
Citation preview
D3.3
Tests and Validation Results
Editor: Yasir Saleem (IMT-TSP), Abdullah Aziz (SJU)
Submission date: 15/06/18
Version 1.0
Contact: [email protected], [email protected]
This deliverable contains detailed end-to-end interoperability testing architecture, test scenarios and
specification. It describes the test cases for interoperability of oneM2M and FiWare platforms in the presence of
Morphing Mediation Gateway. It defines the testing conventions and interoperability testing architecture that
will be used for defining test cases which will mapped to the requirements. Those defined test cases will be used
for validation and demonstration of interoperability between oneM2M and FiWare.
Editor: Yasir Saleem (IMT-TSP), Abdullah Aziz (SJU)
Deliverable nature: R
Dissemination level: PU
Contractual/actual delivery date: M24 M25
Disclaimer
This document contains material, which is the copyright of certain Wise-IoT consortium parties, and may
not be reproduced or copied without permission.
All Wise-IoT consortium parties have agreed to full publication of this document.
The commercial use of any information contained in this document may require a license from the
proprietor of that information.
Neither the Wise-IoT consortium as a whole, nor a certain part of the Wise-IoT consortium, warrant that
the information contained in this document is capable of use, nor that use of the information is free
from risk, accepting no liability for loss or damage suffered by any person using this information.
This project has received funding from the European Union’s H2020 Programme for research,
technological development and demonstration under grant agreement No 723156, the Swiss State
Secretariat for Education, Research and Innovation (SERI) and the South-Korean Institute for Information
& Communications Technology Promotion (IITP).
Copyright notice
2018 Participants in project WISE-IOT
Revision History
Revision Date Description Author (Organisation)
V0.0 2017-01-13 Setup of document Structure Abdullah Aziz (SJU)
V0.1 2017-10-04 Update the structure and architecture Abdullah Aziz (SJU)
V0.2 2017-12-04 Added the test cases for oneM2M – ASM – NGSI Abdullah Aziz (SJU),
JaeYoung Hwang (SJU)
V0.3 2017-05-16 Updated table of content according to Tasks 3.2,
3.3 and 3.4
Yasir Saleem (IMT-TSP)
V0.4 2017-07-24 Updated table of contents, added test cases for
ASM and CAG
Abdullah Aziz (SJU)
V0.5 2017-09-18 Added the test cases for NGSI – CAG – oneM2M
and Z-Wave – ZIG – oneM2M
Abdullah Aziz (SJU)
v0.7.1 2018-03-16 Integrated core contributions
- 2 Cross-domain Testing and Validation
- 3.4.4 sensiNact – oneM2M - 3.4.5 GS1 – oneM2M - 4.1 Extension of Semantic Ontology
Validator Tool - 4.2 Semantic Interoperability
Validation (1st Round)
- 5.1 oneM2M Security Component
- 5.2 LoRaWAN Security Component
Yasir Saleem (IMT-TSP)
Martin Bauer (NECLE)
Rémi Druilhe (CEA)
Minh Hoang Nguyen (KAIST)
Hamza Baqa (EGM)
Hamza Baqa (EGM) & Yasir
Saleem (IMT-TSP)
Hamza Baqa (EGM) & Se-Ra
Oh (SJU)
Hamza Baqa (EGM) & Se-Ra
Oh (SJU)
v0.7.2 2018-05-09 Integrated final contributions
Executive Summary
- 1 Introduction - 2.2 Federation Validation - 3 Technical Interoperability
Validation (finalization) - 4.3 Semantic Ontology Validation (2nd
Round) - 6 Conclusion
Proof reading and finalizing the deliverable
Yasir Saleem (IMT-TSP)
Yasir Saleem (IMT-TSP)
Yasir Saleem (IMT-TSP)
Martin Bauer (NECLE)
Abdullah Aziz (SJU)
Yasir Saleem (IMT-TSP)
Yasir Saleem (IMT-TSP)
Yasir Saleem (IMT-TSP)
v0.8 2018-06-06 Integrated newly received validation
contributions
- 3.4 Conformance Test Purposes
- 4.3.4 Bus Information System
- 4.4 Summary of Semantic Ontology
Validation Results
- 5.3 OpenAM Security Component
- 5.4 OpenIG Security Component
- 5.5 Security Validation Table
Yasir Saleem (IMT-TSP)
Abdullah Aziz (SJU)_
Yasir Saleem (IMT-TSP)
Yasir Saleem (IMT-TSP)
Hamza Baqa (EGM)
Hamza Baqa (EGM)
Hamza Baqa (EGM)
v0.9 2018-06-14 Comments addressed and editorial work, and
some missing contributions
Yasir Saleem (IMT-TSP),
Mahdi Daghmehchi (SJU),
Martin Bauer (NECLE), Hamza
Baqa (EGM)
v1.0 2018-06-15 Final check Franck Le Gall (EGM)
Table of contents
Executive summary _________________________________________ 8
Authors ______________________________________________________ 9
Glossary ____________________________________________________ 10
1 Introduction _____________________________________________ 11
1.1 Purpose of the document ______________________________________ 11
1.2 Scope of the document ________________________________________ 12
2 Cross-domain Testing and Validation ___________________ 13
2.1 Architectural Overview ________________________________________ 13
2.2 Federation Validation __________________________________________ 15
2.2.1 Registration of Local IoT Brokers ________________________________ 15
2.2.2 Querying the Federated IoT Broker ______________________________ 16
2.2.3 Discovering Local Broker(s) ______________________________________ 17
2.2.4 Querying the Local Broker _______________________________________ 18
3 Technical Interoperability Validation ___________________ 22
3.1 Overview of Testing Framework for Technical Interoperability
Validation ____________________________________________________________ 22
3.2 Interoperability Test Scenarios, Descriptions and Validation 23
3.3 Interoperability Test Cases ____________________________________ 24
3.3.1 oneM2M – ASM – NGSI ____________________________________________ 24
3.3.2 NGSI – CAG – oneM2M ____________________________________________ 25
3.3.3 Z-Wave – ZIG – oneM2M __________________________________________ 27
3.3.4 sensiNact – oneM2M ______________________________________________ 28
3.3.5 GS1 – oneM2M ____________________________________________________ 29
3.3.6 OCF – oneM2M ____________________________________________________ 30
3.3.7 LoRa – oneM2M ___________________________________________________ 31
3.4 Conformance Test Purposes ___________________________________ 32
3.4.1 Registration (REG) _______________________________________________ 34
3.4.2 Data Management and Repository (DMR) ________________________ 37
3.4.3 Subscription and Notification (SUB) _____________________________ 43
4 Semantic Ontology Validation __________________________ 45
4.1 Extension of Semantic Ontology Validator tool _______________ 45
4.1.1 Quality of Information (QoI) Module _____________________________ 46
4.2 Semantic Ontology Validation (1st Round) ____________________ 47
4.2.1 Smart Parking ____________________________________________________ 47
4.2.2 Smart Skiing ______________________________________________________ 52
4.2.3 Crowd Modelling __________________________________________________ 53
4.2.4 Bus Information System __________________________________________ 54
4.3 Semantic Ontology Validation (2nd Round) ____________________ 68
4.3.1 Smart Parking ____________________________________________________ 68
4.3.2 Smart Skiing ______________________________________________________ 70
4.3.3 Crowd Modelling __________________________________________________ 70
4.3.4 Bus Information System __________________________________________ 71
4.4 Summary of Semantic Ontology Validation Results __________ 73
5 Security Validation ______________________________________ 75
5.1 oneM2M Security Component _________________________________ 75
5.1.1 Request an Access Token _______________________________________ 75
5.1.2 Access a Protected Resource without an Access Token _______ 75
5.1.3 Access a Protected Resource with an Invalid Access Token ___ 75
5.1.4 Access a protected resource with an Valid Access Token _____ 76
5.2 LoRaWAN Security Component ________________________________ 76
5.2.1 Bit Flipping after Network Server Checked Message Integrity _ 76
5.2.2 Usurping Gateway Identity _______________________________________ 76
5.3 OpenAM Security Component _________________________________ 77
5.3.1 Request an Access Token _______________________________________ 77
5.3.2 DataStore (pass) _________________________________________________ 77
5.3.3 DataStore (fail) ___________________________________________________ 77
5.3.4 DeviceMatch ______________________________________________________ 78
5.3.5 DeviceMatch (fail) ________________________________________________ 78
5.3.6 TwoFactor (Fail) __________________________________________________ 78
5.3.7 TwoFactor (Pass) _________________________________________________ 78
5.3.8 DeviceSave (fail) __________________________________________________ 79
5.3.9 DeviceSave (pass) ________________________________________________ 79
5.4 OpenIG Security Component___________________________________ 79
5.4.1 Route ______________________________________________________________ 79
5.4.2 Route (fail) ________________________________________________________ 80
5.4.3 Header ____________________________________________________________ 80
5.4.4 Header (fail) ______________________________________________________ 80
5.4.5 Insecure Direct Object References ______________________________ 80
5.4.6 Insecure Direct Object References (fail) _________________________ 80
5.4.7 Privilege Escalation ______________________________________________ 81
5.4.8 Privilege Escalation (fail) _________________________________________ 81
5.4.9 Bypassing authorization schema _________________________________ 81
5.4.10 Bypassing authorization schema (fail) ___________________________ 81
5.5 Fiware security testing ________________________________________ 82
5.5.1 Security Group creation __________________________________________ 82
5.5.2 Security Group creation (fail) ____________________________________ 82
5.5.3 Security Group Rules creation for a Security Group _____________ 82
5.5.4 Security Group Rules creation for a Security Group (fail) _______ 82
5.6 Security validation table _______________________________________ 83
6 Conclusion ______________________________________________ 85
7 References ______________________________________________ 86
Executive summary
Wise-IoT addresses the problem of fragmentation between different IoT standards and their
ecosystems. It offers gateways for bridging these heterogeneous IoT deployments and morphing for
translating data expressed by using one ontology into data expressed by another ontology. These Wise-
IoT innovations facilitate global interoperability and mobility of IoT applications and devices.
This deliverable reports the activities of three tasks of WP3. Task 3.2 about technical interoperability
validation, Task 3.3 about data and semantic interoperability validation, Task 3.4 about security
validation, as well as technical validation of service roaming and cross-domain data reuse use case.
This deliverable is divided into four main parts. The first part focuses on the technical validation of
service roaming and cross-domain data reuse use case that is based on FIWARE/NGSI federation
approach in Section 2. Due to the current incompatibilities of different NGSI flavors (e.g., the IoT Broker
implements FIWARE NGSIv1 while the Orion Context Broker implements FIWARE NGSIv2), this
deliverable presents a technical validation of federation. It provides an architectural overview depicting
the core aspects of service roaming and cross-domain data reuse use case, as well as the required steps
needed for the federation validation together with examples of requests that are sent in the respective
steps and their responses.
The second part focuses on the technical interoperability validation and presents a testing framework
for all the components in Wise-IoT architecture in Section 3. It presents a general architecture for
interoperability testing highlighting the core components. Subsequently, it presents all the test cases in
detail to validate the interoperability between all IoT platforms/protocols used in the Wise-IoT project.
In order to validate the interoperability, all the components should pass the test cases, according to the
source and destination platform.
The third part focuses on the data and semantic ontology validation that presents an overview of
semantic ontology validator and then performs the semantic ontology validation of Wise-IoT use cases
ontologies (e.g., smart parking, smart skiing, crowd modelling and bus information system) in Section 4.
The purpose of this validation is to generate a report with identified errors in the use case ontologies
and provide feedback to the ontology designers (mainly the use case owners) to correct the identified
errors in their ontologies. The validation report mainly provides feedback on the level of interoperability
between resource descriptions of ontologies and the commonly used resource description frameworks.
The fourth and the final part presents the test cases of oneM2M and LoRaWAN security components of
Wise-IoT. Each component provides a number of test cases required for testing and validating the
security. Similar to technical interoperability validation, the individual components should validate and
pass the test cases for each scenario in order to achieve the validation.
Authors
Chapter Author (Organisation)
Chapter 1 Yasir Saleem (IMT-TSP)
Chapter 2 Martin Bauer (NECLE)
Chapter 3 Abdullah Aziz (SJU), Rémi Druilhe (CEA), Minh Hoang (KAIST),
SeungMyeong Jeong (KETI)
Chapter 4 Yasir Saleem (IMT-TSP), Hamza Baqa, Franck Le Gall (EGM)
Chapter 5 Hamza Baqa Franck Le Gall (EGM), Se-Ra Oh (SJU)
Chapter 6 Yasir Saleem (IMT-TSP)
Glossary
Term or Abbreviation Definition (Source)
AE Application Entity
ASM Adaptive Semantic Module
CAG Context-Aware Auxiliary Gateway
CSE Common Services Entity (oneM2M)
G/W Gateway
MMG Morphing Mediation Gateway
MQTT Message Queue Telemetry Transport
NGSI Next Generation Service Interface
SMG Semantic Mediation Gateway
SSN Semantic Sensor Network
W3C World Wide Web Consortium
Introduction
11
1 Introduction
Among a variety of IoT technologies, semantics is one of the most promising ones that is being studied
in many research areas and bodies involving standardization. One of the strengths of using semantic
technology is to enhance interoperability. However, many of the interworking technologies do not rely
on semantics or are not being used in the field as opposed to non-semantic interoperability schemes.
Wise-IoT aims to fulfil interoperability between different IoT technologies, especially two major IoT
platforms, i.e., oneM2M and FIWARE, with the help of semantics and demonstrates it with use case
deployments. With this approach, it will be proved how semantics in different technologies can be
leveraged to realise interoperability of heterogeneous IoT technologies.
For interoperability, the technical, semantics and security validation are important to evaluate the
adapters that are developed in WP2. Hence, there is a need to develop test cases and apply them on the
overall integrated platform to ensure that the built adapters work correctly and end-to-end integration
between the platforms is achieved. Based on this need, this deliverable firstly defines specific technical
interoperability testing plans of the integrated platform. It also specifies a set of test cases, according to
functional and technical specifications.
For semantic interoperability, a semantic ontology validation tool developed in FIESTA-IoT project [1]
has been extended in this project by EGM. This semantic ontology validation tools validates the
ontologies of Wise-IoT use cases and generate an evaluation report. The report is then sent to the use
cases ontology designers (mainly the use case owners) to provide feedback on the level of
interoperability between their resource descriptions and the commonly used resource description
frameworks, and to correct the errors in their ontology identified by the semantic ontology validation
tool.
Since security is also a major concern for interoperability in IoT, this deliverable also provides test cases
of oneM2M and LoraWAN security components of Wise-IoT.
It is important to note that for technical and security validation, the individual components need to be
validated and pass the test cases for each scenario defined for technical interoperability and security
validation, respectively.
1.1 Purpose of the document
This document contains technical validation of service roaming and cross-domain data reuse (presented
in Section 4.6 of D1.2 [2]) which is based on FIWARE/NGSI federation approach (presented in Section
2.4 of D1.2 [2]), technical interoperability validation of the overall components in Wise-IoT architecture
containing detailed end-to-end interoperability testing architecture, test scenarios and specification,
data and semantic interoperability validation of Wise-IoT use cases ontologies, and security validation.
More specifically, this deliverable describes the test cases for interoperability of source and destination
IoT platforms/protocols in the presence of Morphing Mediation Gateway (MMG). It defines the
interoperability testing architecture that is used for defining test cases which are mapped to the
requirements. Those defined test cases are used for validation and demonstration of interoperability
between source and destination IoT protocols/platforms in the presence of the respective MMG
component running in MMG manager.
Introduction
12
1.2 Scope of the document
Chapter 2 presents the technical validation of service roaming and cross-domain data reuse which is
based on FIWARE/NGSI federation approach.
Chapter 3 presents technical interoperability validation of the overall components in WISE-IoT
architecture which includes architecture for interoperability testing and test scenarios and specification.
Chapter 4 presents the data and semantic interoperability validation of Wise-IoT use cases ontologies
using semantic ontology validation tool.
Chapter 5 presents security validation.
Chapter 6 concludes the deliverable.
Cross-domain Testing and Validation
13
2 Cross-domain Testing and Validation
This chapter describes the technical validation of the service roaming and cross-domain data reuse use
case that has been described in Section 4.6 of D1.2 [2] that is based on the FIWARE / NGSI federation
approach as described in Section 2.4 of D1.2 [2].
The reason of only doing a technical validation of federation as opposed to generally using it in the real
world deployments lies in the current incompatibilities of different NGSI flavors. The IoT Broker
implements FIWARE NGSIv1, whereas the Orion Context Broker implements FIWARE NGSIv2. NGSIv2
also allows complex JSON data types as attribute values which is used for the key information models
(e.g. smart/rich parking and bus information system). These complex JSON datatypes are not supported
in NGSIv1. On the other hand, NGSIv2 does not support the NGSI-9 functionality, which is needed for
federation. The crowd information model as described in Section 3.2.5 of D2.7 [3] is compatible with
NGSIv1 and thus can be used for the technical validation using IoT Brokers in different configurations.
Currently, there are ongoing activities in ETSI ISG CIM to standardize NGSI-LD, the successor of the
FIWARE NGSI flavors. NGSI-LD will support complex JSON datatypes as well as the functionality required
for federation, i.e. resolving the above-mentioned incompatibilities. The Wise-IoT partners NEC, Korea
Electronics Technology Institute (KETI) and Easy Global Market (EGM) have been instrumental in ETSI
ISG CIM to ensure that federation functionalities as well as rich modelling capabilities will be supported
in NGSI-LD. It is the goal of the partners as well as of FIWARE Foundation to evolve existing Broker
implementations to support NGSI-LD in their next versions. So the issue should be resolved and thus the
Federation approach will be generally applicable, however this will only be the case some time after the
end of the Wise-IoT project.
2.1 Architectural Overview
Figure 1 depicts the use case as shown in Section 4.6 of D1.2 [2]. In this chapter, the core aspects of this
use case are validated, i.e. an application requesting information from the Federated IoT Broker, which
in turn interacts with its Registry and with Local IoT Brokers. These components also constitute the core
part of the Information Access Layer.
Cross-domain Testing and Validation
14
Figure 1: Architecture of Service Roaming and Cross-Domain Data Reuse Use Case.
Figure 2: Architecture of the Validation Deployment
Figure 2 shows the architectural setup of the validation deployment. At the time of conducting the
validation, crowd information modelled according to FIWARE NGSIv1 (as described in Section 3.2.5 of
D2.7 [3]) is available from a lab environment at the University of Cantabria in Santander and real crowd
information from an NEC deployment in Australia.
Cross-domain Testing and Validation
15
The local IoT Brokers are both registered with their respective geographic scope at the Registry of the
Federated IoT Broker, i.e. as providing crowd information for a geographic area in Santander and as
providing crowd information for a geographic area in Australia respectively. This registration has been
done using the NGSI-9 register operation.
The crowd management application requests crowd information from the Federated IoT Broker – in
one case using a geographic scope, including or overlapping with the geographic area in Santander for
which crowd information is available, in the other case using a geographic scope including or overlapping
with the geographic area in Australia.
The Federated IoT Broker sends an NGSI-9 discovery request with the requested geographic scope to its
Registry for NGSI-10 context sources. Depending on the geographic scope, the information about the
Local IoT Broker with the crowd information from Santander or the Local IoT Broker with crowd
information from Australia will be returned.
The Federated IoT Broker then forwards the original NGSI-10 request to the Local IoT Broker whose
information was provided by the Registry. The Local IoT Broker provides the response to the Federated
IoT Broker which forwards it to the requesting crowd management application.
2.2 Federation Validation
The following table shows an overview of the different steps needed for the technical validation of the
federation use case. The following subsections describe these steps in detail together with examples of
requests that are sent in the respective steps, as well as with their responses.
Table 1. An overview of test cases of Federation
Nb Resource/Procedure FC_ID TD Description Validation
1 Local Brokers – Federation
FC_01 Local Brokers- Register- Federation Registry
Validated
2 Application - Federation FC_02 Application – Query – Fedeated IoT Broker
Validated
3 Fed. Broker – Fed. Registry FC_03 Fed. Broker – Discover – Fed. Registry
Validated
4 Fed. Broker – Local Broker FC_04 Fed. Broker –Query – Local Broker
Validated
2.2.1 Registration of Local IoT Brokers
FC-ID FC_01
Purpose Register the local IoT Brokers with the Federation Registry
Entry Criteria 1. Information about the available entities is available on the right abstraction level.
2. Geographical scope for which the IoT Broker has information is available
Test Procedure 1. IoT Broker information is being registered with Federation Registry using NGSI-9 registerContext operation.
Exit Criteria 1. Local IoT Broker is correctly registered and registration information including registration id is returned.
Cross-domain Testing and Validation
16
The local IoT Brokers have to be registered at the Registry at the federation level. This is done using the
NGSI-9 operation ‘registerContext’.
POST
http://localhost:8060/ngsi9/registerContext
HEADERS
'accept: application/json'
'content-type: application/json'
BODY
'{
"contextRegistrations": [{
"entities": [{
"id": ".*",
"isPattern": "true"
}],
"contextMetadata": [{
"name": "SimpleGeoLocation",
"type": "SimpleGeoLocation",
"value": {
"nwCorner": "43.50,-3.85",
"seCorner": "43.40,-3.75"
}
}],
"providingApplication": "http://172.17.0.1:8070/ngsi10/"
}]
}'
In this case, the local Broker for Santander is registered for any kind of entity ("id": ".*") with a
geographic location({"nwCorner": "43.50,-3.85", "seCorner": "43.40,-3.75"})
that covers the city of Santander. As the result of the successful registration, a registration identifier is
provided "c0d20-a442f-6A8Cb-3101e-4000d-10a2d5d65dd0c6903db_-_1-
c65ee0a8df56d23d847b45930f600688".
{"duration":null,"registrationId":"c0d20-a442f-6A8Cb-3101e-4000d-
10a2d5d65dd0c6903db_-_1-
c65ee0a8df56d23d847b45930f600688","errorCode":null}
2.2.2 Querying the Federated IoT Broker
FC-ID FC_02
Purpose Query the Federation Broker for Information
Entry Criteria 1. Local Brokers are registered correctly with the Federation Registry
Test Procedure 1. Application queries the Federated IoT Boker using NGSI-10 queryContext operation using geographic scope.
2. Steps in Section Erreur ! Source du renvoi introuvable. and Erreur ! Source du renvoi introuvable.
Exit Criteria 1. Requested information (possibly aggregated) is returned to the application (also see Section Erreur ! Source du renvoi introuvable.).
If an application queries the Federated IoT Broker with the NGSI-10 operation ‘queryContext’, it
provides a geographic scope. In this case an area in Santander (please note that radius is in meters).
POST
Cross-domain Testing and Validation
17
http://localhost:8060/ngsi10/queryContext
HEADERS
'accept: application/json'
'content-type: application/json'
BODY
'{
"entities": [{
"id": ".*",
"isPattern": true
}],
"restriction": {
"scopes": [{
"scopeType": "circle",
"scopeValue": {
"centerLatitude": 43.466970,
"centerLongitude": -3.801262,
"radius": 3000
}
}],
"attributeExpression": ""
}
}'
2.2.3 Discovering Local Broker(s)
FC-ID FC_03
Purpose Discover Local Brokers
Entry Criteria 1. Local Brokers are registered correctly with the Federation Registry
Test Procedure 1. Federated Broker discovers Local IoT Brokers fitting the request, in particular the geographic scope, from the Federation Registry using the NGSI-9 discoverContextAvailability operation.
Exit Criteria 1. ContextRegistration of Local IoT Brokers fitting the discovery request are returned.
With this geographic scope, the Registry is queried, using the NGSI-9
‘discoverContextAvailability’ operation.
POST
http://localhost:8060/ngsi9/discoverContextAvailability
HEADERS
'accept: application/json'
'content-type: application/json'
BODY
'{
"entities": [{
"id": ".*",
"isPattern": true
}],
"restriction": {
"scopes": [{
"scopeType": "circle",
"scopeValue": {
"centerLatitude": 43.464535,
"centerLongitude": -3.8369164,
Cross-domain Testing and Validation
18
"radius": 10.0
}
}],
"attributeExpression": ""
}
}'
If the scope is included or overlaps with the area for which a Local Broker is registered – in this case an
area in Santander – the matching Registration is returned to the Federated IoT Broker.
{
"contextRegistrationResponses":
{ "contextRegistrations": [{
"entities": [{
"id": ".*",
"isPattern": "true"
}],
"contextMetadata": [{
"name": "SimpleGeoLocation",
"type": "SimpleGeoLocation",
"value": {
"nwCorner": "43.50,-3.85",
"seCorner": "43.40,-3.75"
}
}],
"providingApplication": "http://172.17.0.1:8070/ngsi10/"
}]
}
}
2.2.4 Querying the Local Broker
FC-ID FC_04
Purpose Query Local Brokers
Entry Criteria 1. Context Registrations of Local IoT Brokers have been discovered.
Test Procedure 1. Federated Broker queries Local IoT Brokers for information.
Exit Criteria 1. Fitting information from Local IoT Brokers is returned – in case of multiple fitting Local IoT Brokers the information is aggregated.
The Federated IoT Broker extracts the URL of the local Broker(s) ("providingApplication") and
forwards the query to it (or them – if multiple had been returned) with the NGSI-10 operation
queryContext.
POST
http://172.17.0.1:8070/ngsi10/
HEADERS
'accept: application/json'
'content-type: application/json'
BODY
'{
"entities": [{
"id": ".*",
Cross-domain Testing and Validation
19
"isPattern": true
}],
"restriction": {
"scopes": [{
"scopeType": "circle",
"scopeValue": {
"centerLatitude": 43.466970,
"centerLongitude": -3.801262,
"radius": 3000
}
}],
"attributeExpression": ""
}
}'
The Local Broker evaluates the query and returns the result to the Federated IoT Broker.
{
"errorCode": null,
"contextResponses": [{
"contextElement": {
"entityId": {
"id": "sa-wfmote-1",
"type": "nle:WifiMote",
"isPattern": false
},
"attributeDomainName": null,
"domainMetadata": [{
"name": "location",
"type": "point",
"value": {
"latitude": 43.47135,
"longitude": -3.804008
}
}, {
"name": "AbstractionLevel",
"type": null,
"value": "0"
}, {
"name": "MacAddress",
"type": null,
"value": "c0:25:e9:27:a0:84"
}],
"attributes": [{
"name": "StayDurationCount",
"type": "nle:StayDurationCount",
"contextValue": "11",
"metadata": [{
"name": "StartTime",
"type": null,
"value": "2018.03.23 18:58:00:000 +0100"
}, {
"name": "EndTime",
"type": null,
"value": "2018.03.23 19:03:00:000 +0100"
}, {
Cross-domain Testing and Validation
20
"name": "Threshold",
"type": null,
"value": "300"
}, {
"name": "RemainderCount",
"type": null,
"value": "44"
}]
}, {
"name": "StayDurationAverage",
"type": "nle:StayDurationAverage",
"contextValue": "1273",
"metadata": [{
"name": "Unit",
"type": null,
"value": "Seconds"
}, {
"name": "StartTime",
"type": null,
"value": "2018.03.23 18:58:00:000 +0100"
}, {
"name": "EndTime",
"type": null,
"value": "2018.03.23 19:03:00:000 +0100"
}, {
"name": "Threshold",
"type": null,
"value": "300"
}]
}, {
"name": "CrowdEstimation",
"type": "nle:CrowdEstimation",
"contextValue": "28",
"metadata": [{
"name": "StartTime",
"type": null,
"value": "2018.03.23 18:55:00:000 +0100"
}, {
"name": "EndTime",
"type": null,
"value": "2018.03.23 19:00:00:000 +0100"
}]
}, {
"name": "PeopleFlow_From_sa-wfmote-1",
"type": "nle:PeopleFlow",
"contextValue": "14",
"metadata": [{
"name": "StartPointMoteMacAddress",
"type": null,
"value": "c0:25:e9:27:a0:84"
}, {
"name": "StartPointMoteEntityId",
"type": null,
"value": "sa-wfmote-1"
}, {
"name": "StartTime",
Cross-domain Testing and Validation
21
"type": null,
"value": "2018.03.23 18:55:00:000 +0100"
}, {
"name": "EndTime",
"type": null,
"value": "2018.03.23 19:00:00:000 +0100"
}]
}, {
"name": "PeopleFlow_From_alp-wfmote-2",
"type": "nle:PeopleFlow",
"contextValue": "0",
"metadata": [{
"name": "StartPointMoteMacAddress",
"type": null,
"value": null
}, {
"name": "StartPointMoteEntityId",
"type": null,
"value": "alp-wfmote-2"
}, {
"name": "StartTime",
"type": null,
"value": "2018.03.23 18:55:00:000 +0100"
}, {
"name": "EndTime",
"type": null,
"value": "2018.03.23 19:00:00:000 +0100"
}]
}]
},
"statusCode": {
"code": 200,
"reasonPhrase": null,
"details": null
}
}]
}
The Federated IoT Broker subsequentially returns this result to the application from which the original
request came from.
Technical Interoperability Validation
22
3 Technical Interoperability Validation
This chapter describes the technical interoperability validation of the overall components in the Wise-
IoT architecture. Technical interoperability is a technology layer, responsible to cope with the
interoperability issues. It moves data from source to destination in a way that both systems can
understand information in a well known format. In this chapter, we introduced a testing framework of
the Wise-IoT project by clearly showing the technical interoperability layer. It is important to note that
to achieve the interoperability, all components in the technical interoperability layer should validate and
pass the test cases for each scenario. In this project, we mainly targeted defining the test cases which
individual components should pass for technical interoperability validation.
3.1 Overview of Testing Framework for Technical
Interoperability Validation
Figure 3: General interoperability Architecture
Figure 3 presents the general architecture for interoperability testing. The main components in this
architecture are MMG manager which manages all MMG components, oneM2M service layer, and CIM
layer. The two layers of MMG manager play the role of technical interoperability layer in this framework.
At the bottom, there is an IoT platform which gets data from IoT devices and then sends it to the
respective MMG component running in MMG manager which then translates the data into oneM2M
format and forwards to the oneM2M service layer. Subsequently, the data with semantic information
will be read and translated by ASM which also runs in the MMG manager and stores the data in the CIM
layer. The technical interoperability layer is responsible for exchanging data from source data format to
Technical Interoperability Validation
23
destination data format and communicate over specific APIs (Application Program Interfaces) and
services. To validate the interoperability testing, every component should pass the resulted test cases
of this deliverable.
3.2 Interoperability Test Scenarios, Descriptions and
Validation
In this section, all the test cases are listed related to technical interoperability of the Wise-IoT platform.
Each component should validate the specific test case to achieve interoperability by interchanging data
formats between source and destination and communicate via different APIs.
All the components in Wise-IoT are developed and applied in various use cases such as Smart Parking,
Smart Skiing and Bus Information System. All these use cases involve various Wise-IoT components
which are validated by these test cases. The components are based on REST APIs, and to validate the
interoperability between components, each developer group of specific component executed these test
cases by consuming the REST APIs via commercial clients such as Postman. Once a component is
responding and handling REST APIs correctly and executed these test cases successfully via standard
client application, it is used in the development of multiple use cases. In this manner, all these test cases
are validated by executing these test cases via standardized client and then used them in the
development of interoperable use cases of Wise-IoT. Successful demonstration of the use cases has
been shown in various events such as “IoT Week Korea” and “ETSI IoT Week 2017”.
Table 2 presents an overview of test cases of Wise-IoT components. These test cases are discussed in
detail in subsequent sections.
Table 2. An overview of test cases of Wise-IoT components
Nb Resource/Procedure TC_ID TD Description Validation
1 oneM2M – ASM – NGSI TC_01 ASM – Discover – oneM2M Validated
2 TC_02 ASM – Subscribe – oneM2M Validated
3 TC_03 oneM2M – Notify – ASM Validated
4 TC_04 ASM – Update – NGSI Validated
5 NGSI – CAG – oneM2M TC_05 CAG – Discover – NGSI Validated
6 TC_06 CAG – Create – oneM2M Validated
7 TC_07 CAG – Subscribe – NGSI Validated
8 TC_08 NGSI – Notify – CAG Validated
9 TC_09 CAG – Update – oneM2M Validated
10 Z-Wave – ZIG – oneM2M TC_10 ZIG – Register – oneM2M Validated
11 TC_11 Z-wave – Sends – ZIG Validated
12 TC_12 ZIG – CREAT – oneM2M Validated
13 SensiNact – oneM2M TC_13 sensiNact creates AE on oneM2M
Validated
14 TC_14 sensiNact deletes AE on oneM2M
Validated
15 TC_15 sensiNact creates container on oneM2M
Validated
16 TC_16 sensiNact deletes container on oneM2M
Validated
Technical Interoperability Validation
24
17 TC_17 sensiNact creates contentInstance on
oneM2M
Validated
18 GS1_oneM2M – oneM2M TC_18 GS1_oneM2M – Subscribe – EPCIS
Validated
19 TC_19 GS1_oneM2M – create – oneM2M
Validated
20 TC_20 EPCIS – Notify - GS1_oneM2M
Validated
21 TC_21 GS1_oneM2M – Update – oneM2M
Validated
22 OCF – oneM2M TC_22 OCF-IPE – Discovery – OCF Validated
23 TC_23 OCF-IPE – Subscription – OCF
Validated
24 TC_24 OCF-IPE – Un-Subscription – OCF
Validated
25 TC_25 OCF-IPE – notification – oneM2M
Validated
26 LoRa – oneM2M TC_26 LoRa-IPE – Registration – oneM2M
Validated
27 TC_27 LoRa-IPE – Uplink – oneM2M
Validated
28 TC_28 LoRa-IPE – Downlink – oneM2M
Validated
3.3 Interoperability Test Cases
This section presents all the test cases in detail to validate the interoperability between all IoT platforms
or protocol used in the Wise-IoT project. The interoperability can be validated if the following test cases
are passed according to the source and destination platform.
3.3.1 oneM2M – ASM – NGSI
The following test cases need to be passed in order to validate the technical interoperability between
oneM2M and NGSI. The source platform is oneM2M and the destination platform is NGSI.
3.3.1.1 ASM – Discover – oneM2M
TC-ID TC_01
Purpose To test SMG discovery operation on oneM2M container resource.
Entry Criteria 3. SMG is capable of discovering the oneM2M resource. 4. oneM2M system has semantically annotated resource.
Test Procedure 2. SMG regularly initiates discovery operation. 3. Compare the set of discovered resources with the set of previous
discovery.
Exit Criteria 2. Resource is no longer available.
Technical Interoperability Validation
25
3.3.1.2 ASM – Subscribe – oneM2M
TC-ID TC_02
Purpose To test the subscription of SMG for creation of contentInstance
Entry Criteria 1. SMG is capable of discovering the oneM2M resource. 2. oneM2M system has semantically annotated resource. 3. SMG discovers the container resource.
Test Procedure 1. SMG will successfully subsribe to the creation of contenInstance resources as child resources of the discovered container resource.
Exit Criteria Success response of subscription from oneM2M.
3.3.1.3 oneM2M – Notify – ASM
TC-ID TC_03
Purpose To test the notification to SMG by oneM2M on new contentInstance
Entry Criteria 1. Required resources already created in oneM2M. 2. SMG is capable of discovering the oneM2M resource. 3. oneM2M system has semantically annotated resource. 4. SMG discovered the container resource. 5. SMG subscribes the container resource on contentInstance creation. 6. New contentInstance created under the discovered container in
oneM2M.
Test Procedure 1. oneM2M successfully notifies the SMG when the new contentInstance is created under the discovered container.
Exit Criteria Successfully notify the SMG.
3.3.1.4 ASM – Update – NGSI
TC-ID TC_04
Purpose To test the ASM call to update data in NGSI.
Entry Criteria 1. ASM is capable of discovering the oneM2M resource. 2. oneM2M system has semantically annotated resource. 3. ASM discovered the container resource. 4. ASM subscribes the container resource on contentInstance creation. 5. New contentInstance created under the discovered container in
oneM2M. 6. oneM2M notifies the ASM that new contentInstance created. 7. ASM converts the oneM2M semantic annotated data into NGSI data
structure.
Test Procedure 1. ASM calls update operation of NGSI to update the data on the basis of new contentInstance in oneM2M.
Exit Criteria ASM successfully calls the update operation of NGSI with the converted oneM2M discovered resource data into NGSI data structure.
3.3.2 NGSI – CAG – oneM2M
The following test cases need to be passed in order to validate the technical interoperability between
oneM2M and NGSI. In this case, NGSI is the source platform and the destination platform is oneM2M.
3.3.2.1 CAG – Discover – NGSI
TC-ID TC-05
Purpose To test CAG discovery operation on context broker.
Technical Interoperability Validation
26
Entry Criteria 1. CAG is up and running in the MMG manager. 2. CAG is capable of discovering the context broker. 3. Context broker has registered devices to be discovered.
Test Procedure 1. CAG has the list of devices to discover from context broker. 2. CAG initiates discovery operation on context broker with the list of
devices to be discovered.
Exit Criteria 1. CAG successfully sent discover request to context broker. 2. Context broker sent discovered devices to CAG.
3.3.2.2 CAG – Create – oneM2M
TC-ID TC_06
Purpose To test CAG create resource operation on oneM2M.
Entry Criteria 1. CAG is up and running in the MMG manager. 2. CAG is capable of discovering the context broker. 3. Context broker has registered devices to be discovered. 4. CAG already sent discover request to context broker. 5. CAG receives information of discovered devices from context broker. 6. CAG retrieves information and convert corresponding to oneM2M
resource structure.
Test Procedure 1. CAG sends create resources request to oneM2M with the converted data.
Exit Criteria 1. CAG successfully created the discovered data in oneM2M platform.
3.3.2.3 CAG – Subscribe – NGSI
TC-ID TC_07
Purpose To test CAG subscribe request to context broker for discovered devices.
Entry Criteria 1. CAG is up and running in the MMG manager. 2. CAG is capable of discovering the context broker. 3. Context broker has registered devices to be discovered. 4. CAG already sent discover request to context broker. 5. CAG receives information of discovered devices from context broker.
Test Procedure 1. CAG sends request to context broker to subscribe discovered devices.
Exit Criteria 1. CAG successfully subscribed discovered devices in context broker.
3.3.2.4 NGSI – Notify – CAG
TC-ID TC_08
Purpose To test NGSI notification to CAG on data update of discovered device.
Entry Criteria 1. CAG is up and running in the MMG manager. 2. CAG is capable of discovering the context broker. 3. Context broker has registered devices to be discovered. 4. CAG already sent discover request to context broker. 5. CAG receives information of discovered devices from context broker. 6. CAG already subscribed devices in context broker to get notification. 7. Device data is updated in context broker.
Test Procedure 1. Context broker sends notification to CAG about data update of subscribed device.
Exit Criteria 1. CAG received notification from NGSI. 2. CAG get the updated data from NGSI along with notification.
3.3.2.5 CAG – Update – oneM2M
Technical Interoperability Validation
27
TC-ID TC_09
Purpose To test CAG update resource request on oneM2M.
Entry Criteria 1. CAG is up and running in the MMG manager. 2. CAG is capable of discovering Context broker. 3. Context broker has registered devices to be discovered. 4. CAG already created the discovered devices resources in oneM2M. 5. CAG already sent discover request to context broker. 6. CAG received information of discovered devices from context broker. 7. CAG already subscribed devices in context broker to get notification. 8. Device data is updated in context broker. 9. CAG got the notification from context broker on update of data of
discovered device. 10. CAG read the updated information and converted into oneM2M resource
structure.
Test Procedure 1. CAG sends createInstance request to oneM2M to update the data of discovered devices of context broker.
Exit Criteria 1. CAG successfully update the information of discovered device in oneM2M.
3.3.3 Z-Wave – ZIG – oneM2M
The following test cases need to be passed in order to validate the technical interoperability between
oneM2M and Z-Wave. The source platform is Z-Wave and the destination platform is oneM2M.
3.3.3.1 ZIG – Register - oneM2M
TC-ID TC_10
Purpose To test ZIG create AE operation on oneM2M.
Entry Criteria 1. ZIG is up and running in the MMG manager. 2. ZIG has connected with oneM2M CSE. 3. ZIG has all information about AE and containers to create in oneM2M.
Test Procedure 1. ZIG received the information for AE from user by MMG manager. 2. ZIG will send create AE and containers request to oneM2M CSE.
Exit Criteria 1. ZIG gets the success response from oneM2M CSE.
3.3.3.2 Z-Wave – Sends – ZIG
TC-ID TC_11
Purpose To test that Z-wave is successfully sending data to ZIG.
Requirement Under Test
1. ZIG already created AE and respective contatiners in oneM2M CSE. 2. ZIG and Z-wave controller on gateway already established socket
communication.
Test Procedure 1. Z-wave controller receives new data from sensor. 2. Z-wave controller sent data to ZIG by socket communciation.
Exit Criteria 1. ZIG successfully read the data from Z-wave over socket.
3.3.3.3 ZIG – create – oneM2M
TC-ID TC_12
Purpose To test ZIG is successfully creating contentIntance in oneM2M under registered AE.
Technical Interoperability Validation
28
Requirement Under Test
1. ZIG already created AE and respective contatiners in oneM2M CSE. 2. ZIG and Z-wave controller on gateway already established socket
communication. 3. ZIG received new data from Z-wave controller by sockets. 4. ZIG converted newly received data into oneM2M standard.
Test Procedure 1. ZIG sends the create contentInstance request to oneM2M CSE under registered AE by ZIG.
Exit Criteria 1. ZIG successfully created the contentInstance in oneM2M CSE and get the success response.
3.3.4 sensiNact – oneM2M
The following test cases need to be passed in order to validate the technical interoperability between
oneM2M and sensiNact. The source platform is sensiNact and the destination platform is oneM2M.
3.3.4.1 sensiNact create AE on oneM2m
TC-ID TC_13
Purpose To test sensiNact “create AE” operation on oneM2M.
Entry Criteria 1. sensiNact is up and running. 2. sensiNact is connected to a MQTT broker. 3. oneM2M platform is connected to the MQTT broker.
Test Procedure 1. A new device appears in sensiNact. 2. sensiNact sends a “create AE” request on the MQTT broker.
Exit Criteria 1. The oneM2M AE is created.
3.3.4.2 sensiNact delete AE on oneM2m
TC-ID TC_14
Purpose To test sensiNact “delete AE” operation on oneM2M.
Entry Criteria 1. sensiNact is up and running. 2. sensiNact already created AE in oneM2M. 3. sensiNact is connected to a MQTT broker. 4. oneM2M platform is connected to the MQTT broker.
Test Procedure 1. A device disappears in sensiNact. 2. sensiNact sends a “delete AE” request on the MQTT broker.
Exit Criteria 1. The oneM2M AE is deleted.
3.3.4.3 sensiNact create container on oneM2M
TC-ID TC_15
Purpose To test sensiNact “create container” operation on oneM2M.
Requirement Under Test
1. sensiNact already created AE in oneM2M. 2. sensiNact is connected to a MQTT broker. 3. oneM2M platform is connected to the MQTT broker.
Test Procedure 1. A new service appears in sensiNact. 2. sensiNact sends a “create container” request on the MQTT broker.
Exit Criteria 1. The oneM2M container is created in the AE.
3.3.4.4 sensiNact delete container on oneM2M
TC-ID TC_16
Purpose To test sensiNact “delete container” operation on oneM2M.
Technical Interoperability Validation
29
Requirement Under Test
1. sensiNact already created AE and a container in oneM2M. 2. sensiNact is connected to a MQTT broker. 3. oneM2M platform is connected to the MQTT broker.
Test Procedure 1. A service disappear in sensiNact. 2. sensiNact send a “delete container” request on the MQTT broker.
Exit Criteria 1. The oneM2M container is deleted in the AE.
3.3.4.5 sensiNact create contentInstance on oneM2M
TC-ID TC_17
Purpose To test sensiNact “create contentInstance” operation on oneM2M.
Requirement Under Test
1. sensiNact already created AE and respective containers in oneM2M. 2. sensiNact is connected to a MQTT broker. 3. oneM2M platform is connected to the MQTT broker.
Test Procedure 1. A new value from a sensor is received by sensiNact 2. sensiNact sends a “create contentInstance” request on the MQTT broker.
Exit Criteria 1. The oneM2M contentInstance is created in the correspondig container and AE.
2. The value of the contentInstance is equal to the value of the sensor received by sensiNact.
3.3.5 GS1 – oneM2M
The following test cases need to be passed in order to validate the technical interoperability between
oneM2M and GS1. The source platform is GS1 and the destination platform is oneM2M.
3.3.5.1 GS1_oneM2M – Subscribe - EPCIS
TC-ID TC_18
Purpose To test GS1_oneM2M MMG subscribe to EPCIS .
Entry Criteria 1 EPCIS is up and running 2 GS1_oneM2M is up and running in the MMG manager. 3 GS1_oneM2M subscribes to EPCIS through context broker. 4 GS1_oneM2M is ready to get event data from EPCIS.
Test Procedure 1 GS1_oneM2M receives the configuration information from MMG manager.
2 GS1_oneM2M subscribes to EPCIS based on the configuration. 3 Simple user app is used to push test event data.
Exit Criteria 1 GS1_oneM2M receives the test event published to EPCIS.
3.3.5.2 GS1_oneM2M – Create - oneM2M
TC-ID TC_19
Purpose To test GS1_oneM2M create AE operation on oneM2M.
Entry Criteria 1 EPCIS is up and running 2 GS1_oneM2M is up and running in the MMG manager. 3 GS1_oneM2M subscribes to EPCIS 4 GS1_oneM2M creates AE and container in oneM2M.
Test Procedure 1 GS1_oneM2M has the information of AE and containers to create. 2 GS1_oneM2M sends create AE and containers to oneM2M CSE.
Exit Criteria 1 GS1_oneM2M gets the success response from oneM2M CSE.
Technical Interoperability Validation
30
3.3.5.3 EPCIS – Notify - GS1_oneM2M
TC-ID TC_20
Purpose To test GS1_oneM2M get published data from EPCIS.
Entry Criteria 1 EPCIS is up and running 2 GS1_oneM2M is up and running in the MMG manager. 3 GS1_oneM2M subscribes to EPCIS. 4 EPCIS gets event data from Busan bus Information system. 5 EPCIS notifies the new event arrival to GS1_oneM2M.
Test Procedure 1 GS1_oneM2M receives notification (plus the event) from EPCIS. 2 GS1_oneM2M gets the information from EPCIS.
Exit Criteria 1 GS1_oneM2M gets event data from EPCIS.
3.3.5.4 GS1_oneM2M – Update - oneM2M
TC-ID TC_21
Purpose To test GS1_oneM2M update the containers on oneM2M.
Entry Criteria 1 EPCIS is up and running 2 GS1_oneM2M is up and running in the MMG manager. 3 GS1_oneM2M subscribes to EPCIS 4 GS1_oneM2M creates AE and container on oneM2M CSE. 5 GS1_oneM2M receives the event information from EPCIS.
Test Procedure 1 GS1_oneM2M receives the event information from EPCIS. 2 GS1_oneM2M translates the event into oneM2M content instance and
publishes to oneM2M CSE.
Exit Criteria 1 GS1_oneM2M gets the success response upon successfully creating the contentInstance in oneM2M.
3.3.6 OCF – oneM2M
The following test cases need to be passed in order to validate the technical interoperability between
oneM2M and OCF. The source platform is OCF and the destination platform is oneM2M.
3.3.6.1 OCF-IPE – Discovery – OCF
TC-ID TC_22
Purpose To test OCF IPE discovery operation and oneM2M resource exposure.
Entry Criteria 1. OCF IPE periodically retireves OCF reosurces.
Test Procedure 1. OCF IPE encapsulates OCF resources into a <contentInstance> resource and stores it into the corresponding <container> resource.
Exit Criteria 1. OCF resource is no longer available.
3.3.6.2 OCF-IPE – Subscription – OCF
TC-ID TC_23
Purpose To test OCF IPE observes when it knows subscription to OCF device representing oneM2M resource.
Entry Criteria 1. OCF IPE subscirbes the OCF device representing <container> resource for child resource creation.
2. The other oneM2M entity creates <subscription> resource as the child of the <container> resource.
Technical Interoperability Validation
31
Test Procedure 1. OCF IPE gets notification for creation of <subscription> resource which is the child resource of OCF device representing <container> resource.
2. OCF IPE fetches the <container> resource information in the notification. 3. OCF IPE observes the corresponding OCF resource on the OCF server.
Exit Criteria 1. OCF IPE successfully observes the OCF resource.
3.3.6.3 OCF-IPE – Un-subscription – OCF
TC-ID TC_24
Purpose To test OCF IPE cancels observe operation when it knows un-subscription to OCF device representing oneM2M resource.
Entry Criteria 1. OCF IPE observes an OCF resource which corresponds with oneM2M <subscription> resource.
2. OCF IPE subscirbes the OCF device representing <container> resoure for child resource deletion.
3. The other oneM2M entity deletes <subscription> resource as the child of the <container> resource.
Test Procedure 1. OCF IPE gets notification for deletion of <subscription> resource which is the child resource of OCF device representing <container> resource.
2. OCF IPE cancels corresponding observe operation on the OCF server.
Exit Criteria 1. OCF-IPE successfully cancels the observation.
3.3.6.4 OCF-IPE – Notification – oneM2M
TC-ID TC_25
Purpose To test OCF IPE gets notification (observe response) and stores it as oneM2M resoure.
Entry Criteria 1. OCF IPE observes an OCF resource which corresponds with oneM2M <subscription> resource.
Test Procedure 1. OCF IPE gets observe response from OIC Server. 2. OCF IPE creates a <contentInstance> resource in the CSE.
Exit Criteria 1. No more observe response arrives at the IPE.
3.3.7 LoRa – oneM2M
The following test cases need to be passed in order to validate the technical interoperability between
oneM2M and LoRa. The source platform is LoRa and the destination platform is oneM2M.
3.3.7.1 LoRa-IPE – Registration – oneM2M
TC-ID TC_26
Purpose To test LoRa device registration as resource to oneM2M platform.
Entry Criteria 1. LoRa device is registered to LoRa G/W. 2. LoRa G/W forwards LoRa uplink message to LoRa IPE.
Test Procedure 1. LoRa IPE interprets LoRa message and converts into oneM2M <contentIntance> resource create request.
2. LoRa IPE sends the <contentInstance> resource create request to LoRa device representing <container> resource. (i.e. resource name of the container is the device ID)
Technical Interoperability Validation
32
3. LoRa IPE receives error response that target <container> resource does not exist.
4. LoRa IPE sends the <container> resource create request for the device and its sub <container> resources representing uplink and downlink message containers.
Exit Criteria 1. No longer LoRa uplink messages are generated by LoRa device.
3.3.7.2 LoRa-IPE – Uplink – oneM2M
TC-ID TC_27
Purpose To test LoRa uplink message delivery to oneM2M platform.
Entry Criteria 1. LoRa device is registered to LoRa G/W. 2. LoRa G/W forwards LoRa uplink message to LoRa IPE.
Test Procedure 1. LoRa IPE interprets LoRa message and converts into oneM2M <contentIntance> resource create request.
2. LoRa IPE sends the <contentInstance> resource create request to the uplink <container> resource of the LoRa device.
Exit Criteria 1. No longer LoRa uplink messages are generated by LoRa device.
3.3.7.3 LoRa-IPE – Downlink – oneM2M
TC-ID TC_28
Purpose To test LoRa downlink message delivery to loRa G/W.
Entry Criteria 1. LoRa device is registered to LoRa G/W. 2. LoRa device is registered to oneM2M platform so has the corresponding
<container> resource. 3. LoRa IPE subscribes downlink <container> resource of the devices.
Test Procedure 1. oneM2M application creates downlink <contentIntance> message into the downlink <container> resource of the LoRa device.
2. LoRa IPE gets notification of the downlink message which is new <contentIntance> creation event.
3. LoRa IPE interprets the oneM2M message into LoRa IPE. 4. LoRa IPE sends the LoRa message to LoRa G/W having LoRa device ID.
Exit Criteria 1. No longer LoRa donwlink messages are generated by apps.
3.4 Conformance Test Purposes
As shown in Figure 3, the main layer in the interoperability architecture is the oneM2M service layer
which is responsible for getting the data from all other IoT platforms by using corresponding MMG. In
this manner, all the underlying MMG components send their data to oneM2M service layer. This process
begins with the registration of each MMG component in the oneM2M service layer as oneM2M AE. All
MMG components act as an AE to send converted data to oneM2M service layer. MMG components
need to follow the oneM2M specifications to successfully communicate with the oneM2M service layer.
To validate the complete interoperability, it is necessary to validate the conformance of MMG
components with respect to oneM2M specification. As MMGs are acting as oneM2M application entities
and performing oneM2M based operations, there is a need to validate these operations by performing
some conformance testing according to the oneM2M specification.
Technical Interoperability Validation
33
Following are the specific Test Purposes for MMG AEs to validate the conformance with the oneM2M
standard. All these TPs are verified and validated as oneM2M standard and listed in technical
specification “TS-0018” of oneM2M and also implemented in Abstract Test Suit.
Table 3 presents a list of test purposes for conformance testing of MMGs as oneM2M AEs.
Table 3. Test Purposes for Conformance Testing of MMGs as AE
Nb TP_ID Test Objective Validation
1 TP/oneM2M/AE/REG//CRE/001 Check that the IUT sends an AE initial registration request with no AE-ID-STEM provided when it is started
Validated
2 TP/oneM2M/AE/REG/CRE/002 Check that the IUT sends a registration CREATE Request with the value of the attribute ATTRIBUTE_NAME of the AE resource
Validated
3 TP/oneM2M/AE/REG/DEL/001 Check that the IUT sends AE deregistration request to CSE
Validated
4 TP/oneM2M/AE/DMR/CRE/001 Check that the IUT sends a Container creation request when it is triggered
Validated
5 TP/oneM2M/AE/DMR/CRE/002 Check that the IUT sends a ContentInstance creation request when it is triggered
Validated
6 TP/oneM2M/AE/DMR/CRE/003 Check that the IUT sends a ContentInstance creation request with optional attribute ATTRIBUTE_NAME
Validated
7 TP/oneM2M/AE/DMR/UPD/001 Check that the IUT sends an UPDATE Request with the value of the attribute ATTRIBUTE_NAME of the AE resource
Validated
8 TP/oneM2M/AE/DMR/UPD/002 Check that the IUT sends an UPDATE Request with the value of the attribute ATTRIBUTE_NAME of the <container> resource
Validated
9 TP/oneM2M/AE/DMR/RET/001 Check that the IUT sends a RETRIEVE Request on the TARGET_RESOURCE_ADDRESS to CSE
Validated
10 TP/oneM2M/AE/SUB/CRE/001 Check that the IUT sends a subscription creation request
Validated
11 TP/oneM2M/AE/SUB/NTF/001 Check that the IUT sends a Notify Response to the hosting CSE when receiving a Notify request containing a single notification
Validated
Technical Interoperability Validation
34
3.4.1 Registration (REG)
3.4.1.1 Create Operation
3.4.1.1.1 TP/oneM2M/AE/REG/CRE/001
TP Id TP/oneM2M/AE/REG//CRE/001
Test objective Check that the IUT sends an AE initial registration request with no AE-ID-STEM provided when it is started
Reference TS-0001 [1], clause 10.1.1.2.2 - case C, 9.6.19
Config Id CF03
Parent Release Release 1
PICS Selection PICS_AE
Initial conditions with { the IUT never being registered and
the IUT being switched off and the IUT having got a valid APP-ID
}
Expected behaviour
Test events Direction
when { the IUT is triggered to send a valid CREATE Request containing To set to CSE_RESOURCE_ADDRESS and Resource Type set to 2 (AE) and Content containing
AE resource representation }
NA
then { the IUT sends a valid CREATE Request to CSE containing Resource Type set to 2 (AE) and To set to CSE_RESOURCE_ADDRESS and From set to empty and Content containing
AE resource representation }
CSE IUT
Technical Interoperability Validation
35
3.4.1.1.2 TP/oneM2M/AE/REG/CRE/002
TP Id TP/oneM2M/AE/REG/CRE/002
Test objective Check that the IUT sends a registration CREATE Request with the value of the attribute ATTRIBUTE_NAME of the AE resource
Reference TS-0004 [2], clause 7.4.6.1
Config Id CF03
Parent Release Release 1
PICS Selection PICS_AE
Initial conditions
with { the IUT never being registered and the IUT being switched off and the IUT having got a valid APP-ID }
Expected behaviour
Test events Direction
when { the IUT is triggered to send a valid CREATE Request containing To set to TARGET_RESOURCE_ADDRESS and Resource Type set to 2 (AE) and Content containing AE resource containing ATTRIBUTE_NAME attribute }
NA
then { the IUT sends a valid CREATE Request containing To set to TARGET_RESOURCE_ADDRESS and From set to AE_ID and Content containing AE resource containing valid ATTRIBUTE_NAME attribute }
IUT → CSE
Technical Interoperability Validation
36
3.4.1.2 Delete Operation
3.4.1.2.1 TP/oneM2M/AE/REG/DEL/001
TP Id TP/oneM2M/AE/REG/DEL/001
Test objective Check that the IUT sends AE deregistration request to CSE
Reference TS-0001 [1], clause 10.1.4.2.2
Config Id CF03
Parent Release Release 1
PICS Selection PICS_AE
Initial conditions with { the IUT being in the "initial state" the IUT having registered to CSE and
the IUT having privileges to perform DELETE operation on the resource AE to CSE
}
Expected behaviour
Test events Direction
when { the IUT is triggered to send a valid DELETE Request containing To set to AE_RESOURCE_ADDRESS }
NA
then { the IUT sends a valid DELETE Request containing To set to AE_RESOURCE_ADDRESS and From set to AE_ID }
CSE IUT
Technical Interoperability Validation
37
3.4.2 Data Management and Repository (DMR)
3.4.2.1 Create Operation
3.4.2.1.1 TP/oneM2M/AE/DMR/CRE/001
TP Id TP/oneM2M/AE/DMR/CRE/001
Test objective Check that the IUT sends a Container creation request when it is triggered
Reference TS-0001 [1], clause 10.1.1.1 and 10.2.4.1, TS-0004 [2], clause 7.2.2.1 and 7.4.7.1
Config Id CF03
Parent Release Release 1
PICS Selection PICS_AE.
Initial conditions with { the IUT being registered and
the IUT being switched on and the IUT having privileges to perform CREATE operation on resource
AE_RESOURCE_ADDRESS }
Expected behaviour
Test events Direction
when { the IUT is triggered to send a valid CREATE Request containing To set to AE_RESOURCE_ADDRESS and Resource Type set to 3 (container) and From set to AE_ID and Content containing
container resource representation }
NA
then { the IUT sends a valid CREATE Request to CSE containing To set to AE_RESOURCE_ADDRESS and Resource Type set to 3 (container) and From set to AE_ID and Content containing
container resource representation }
CSE IUT
Technical Interoperability Validation
38
3.4.2.1.2 TP/oneM2M/AE/DMR/CRE/002
TP Id TP/oneM2M/AE/DMR/CRE/002
Test objective Check that the IUT sends a ContentInstance creation request when it is triggered
Reference TS-0001 [1], clause 10.1.1.1 and 10.2.4.1, TS-0004 [2], clause 7.2.2.1 and 7.4.8.2.1
Config Id CF03
Parent Release Release 1
PICS Selection PICS_AE.
Initial conditions with { the IUT being registered and the IUT having created a container resource CONTAINER_RESOURCE_ADDRESS and
the IUT having privileges to perform CREATE operation on resource CONTAINER_RESOURCE_ADDRESS }
Expected behaviour Test events Direction
when { the IUT is triggered to send a valid CREATE Request containing To set to CONTAINER_RESOURCE_ADDRESS and Resource Type set to 4 (contentInstance) and Content containing
contentInstance resource representation }
NA
then { the IUT sends a valid CREATE Request to CSE containing To set to CONTAINER_RESOURCE_ADDRESS and Resource Type set to 4 (contentInstance) and From set to AE_ID and Content containing
contentInstance resource representation }
CSE IUT
Technical Interoperability Validation
39
3.4.2.1.3 TP/oneM2M/AE/DMR/CRE/003
TP Id TP/oneM2M/AE/DMR/CRE/003
Test objective Check that the IUT sends a ContentInstance creation request with optional attribute ATTRIBUTE_NAME
Reference TS-0001 [1], clause 10.1.1.1 and 10.2.4.1, TS-0004 [2], clause 7.2.2.1 and 7.4.8.2.1
Config Id CF03
Parent Release Release 1
PICS Selection PICS_AE
Initial conditions with { the IUT being registered and
the IUT having created a container resource CONTAINER_RESOURCE_ADDRESS through preconfiguration request and
the IUT having privileges to perform CREATE operation on resource CONTAINER_RESOURCE_ADDRESS }
Expected behaviour
Test events Direction
when { the IUT is triggered to send a valid CREATE Request containing To set to CONTAINER_RESOURCE_ADDRESS and
Resource Type set to 4 (contentInstance) and
Content containing
ContentInstance resource containing
valid ATTRIBUTE_NAME attribute
}
NA
then {
the IUT sends a valid CREATE Request containing
To set to CONTAINER_RESOURCE_ADDRESS and
Resource Type set to 4 (contentInstance) and
From set to AE_ID and
Content containing
ContentInstance resource containing
valid ATTRIBUTE_NAME attribute
3.4.2.1.3.1.1 }
CSE IUT
Technical Interoperability Validation
40
3.4.2.2 Update Operation
3.4.2.2.1 TP/oneM2M/AE/DMR/UPD/001
TP Id TP/oneM2M/AE/DMR/UPD/001
Test objective Check that the IUT sends an UPDATE Request with the value of the attribute ATTRIBUTE_NAME of the AE resource
Reference TS-0001 [1], clause 10.1.3
Config Id CF03
Parent Release Release 1
PICS Selection PICS_AE
Initial conditions with { the IUT being registered containing
a RW attribute ATTRIBUTE_NAME }
Expected behaviour
Test events Direction
when { the IUT is triggered to send a valid UPDATE Request containing To set to AE_RESOURCE_ADDRESS and Content containing AE resource containing valid ATTRIBUTE_NAME attribute }
NA
then { the IUT sends a valid UPDATE Request containing To set to AE_RESOURCE_ADDRESS and From set to AE_ID and Content containing AE resource containing valid ATTRIBUTE_NAME attribute }
IUT → CSE
Technical Interoperability Validation
41
3.4.2.2.2 TP/oneM2M/AE/DMR/UPD/002
TP Id TP/oneM2M/AE/DMR/UPD/002
Test objective Check that the IUT sends an UPDATE Request with the value of the attribute ATTRIBUTE_NAME of the <container> resource
Reference TS-0004 [2], clause 7.4.7.2.3
Config Id CF03
Parent Release Release 1
PICS Selection PICS_AE
Initial conditions with { the IUT being registered containing the IUT having created a container resource CONTAINER_RESOURCE_ADDRESS and
the IUT having privileges to perform UPDATE operation on resource CONTAINER_RESOURCE_ADDRESS }
Expected behaviour
Test events Direction
when { the IUT is triggered to send a valid UPDATE Request containing To set to CONTAINER_RESOURCE_ADDRESS and Content containing container resource containing valid ATTRIBUTE_NAME attribute }
NA
then { the IUT sends a valid UPDATE Request containing To set to CONTAINER_RESOURCE_ADDRESS and From set to AE_ID and Content containing container resource containing valid ATTRIBUTE_NAME attribute }
IUT → CSE
Technical Interoperability Validation
42
3.4.2.3 Update Operation
3.4.2.3.1 TP/oneM2M/AE/DMR/RET/001
TP Id TP/oneM2M/AE/DMR/RET/001
Test objective Check that the IUT sends a RETRIEVE Request on the TARGET_RESOURCE_ADDRESS to CSE
Reference TS-0001 [1], clause 10.1.2, TS-0004 [2], clause 7.2.2.1
Config Id CF03
Parent Release Release 1
PICS Selection PICS_AE.
Initial conditions with { the IUT being registered
and the IUT being switched on and the CSE having created a resource TARGET_RESOURCE_ADDRESS of
type RESOURCE_TYPE and the IUT having privileges to perform RETRIEVE operation on resource
TARGET_RESOURCE_ADDRESS }
Expected behaviour
Test events Direction
when { the IUT is triggered to send a valid RETRIEVE Request containing
To set to TARGET_RESOURCE_ADDRESS }
NA
then { the IUT sends a valid RETRIEVE Request containing To set to TARGET_RESOURCE_ADDRESS and From set to AE_ID }
IUT → CSE
Technical Interoperability Validation
43
3.4.3 Subscription and Notification (SUB)
3.4.3.1 Create Operation
3.4.3.1.1 TP/oneM2M/AE/SUB/CRE/001
TP Id TP/oneM2M/AE/SUB/CRE/001
Test objective Check that the IUT sends a subscription creation request
Reference TS-0001 [1], clause 10.1.1.1 and 10.2.4.1, TS-0004 [2], clause 7.2.2.1 and 7.4.9.2.1
Config Id CF03
Parent Release Release 1
PICS Selection PICS_AE.
Initial conditions with { the IUT being registered and
the IUT being switched off and the IUT having privileges to perform CREATE operation on resource
AE_RESOURCE_ADDRESS }
Expected behaviour
Test events Direction
when { the IUT is triggered to send a valid CREATE Request containing Resource Type set to 23 (subscription) and To set to AE_RESOURCE_ADDRESS and Content containing
subscription resource representation }
NA
then { the IUT sends a valid CREATE Request to CSE containing Resource Type set to 23 (subscription) and To set to AE_RESOURCE_ADDRESS and From set to AE_ID and Content containing
subscription resource representation }
CSE IUT
Technical Interoperability Validation
44
3.4.3.2 Notify Operation
3.4.3.2.1 TP/oneM2M/AE/SUB/NTF/001
TP Id TP/oneM2M/AE/SUB/NTF/001
Test objective Check that the IUT sends a Notify Response to the hosting CSE when receiving a Notify request containing a single notification
Reference TS-0001 [1], clause 6.1.12, TS-0004 [2], clause 7.5.1.2
Config Id CF03
Parent Release Release 1
PICS Selection PICS_AE
Initial conditions with { the IUT having been registered and the IUT having created subscription resource under the CSE and the IUT being reachable through a URL ACCESSIBLE_URL }
Expected behaviour
Test events Direction
when { the IUT receives a NOTIFY Request from hosting CSE
containing Content containing notification message representation
}
IUT CSE
then { the IUT sends a valid NOTIFY Response to the hosting CSE containing Response Status Code set to RESPONSE_STATUS_CODE }
CSE IUT
Semantic Ontology Validation
45
4 Semantic Ontology Validation
In this chapter an overview of the extension of the semantic ontology validation tool is provided to
highlight the main dimensions and novelty of this tool. Then it performs the first round of semantic
ontology validation of Wise-IoT use cases ontologies (e.g., smart parking, smart skiing, crowd modelling
and bus information system) and discusses the generated validation reports containing the errors in the
ontologies. The validation reports were sent to the ontology designers for the correction of errors in
ontologies and then a second round of validation was performed to verify that the ontologies are
correct.
4.1 Extension of Semantic Ontology Validator tool
An overview of semantic ontology validator has already been provided in D3.1 [4], however, for the sake
of completeness, we describe it briefly here as well.
The semantic ontology and linked-data validation is a web service integrated within a web-based client-
server architecture. A simple web client is proposed which offers an easy and intuitive user interface to
access the service. Through the Graphical User Interface (GUI), users can upload their ontology or
semantically annotated data stream to be validated against one or several reference ontologies, such as
the W3C SSN ontology and oneM2M base ontology. The semantic ontology validator checks syntactic
and semantic issues, if any, and produces a detailed test report at the end of the process which will help
the users to correct the issues.
This tool combines three main functionalities that are provided by separate tools: lexical validation of
XML/JSON format, syntactic validation of an ontology or RDF data regarding to standard specifications
(e.g., RDFS and OWL) and against a given reference ontology, and semantic validation. However, all
these current tools suffer from several limitations, such as the need of a desktop software installation
and configurations (e.g., Fluent Editor [5], Protégé [6]), and even the web-based solutions require the
setting of an appropriate environment (e.g., Moki [7]).
The suggested semantic ontology validation tool offers a user-friendly, intuitive and completely web-
based interface. It also provides the tool as a RESTful API for M2M validation, which makes the service
a relevant input for more advanced technologies (e.g., ontology alignment). Additionally, it provides a
validation example, with explanation of the validation report in order to help users to understand the
validation result. Following the report, users can make corrections to the reported errors and make their
ontology or RDF linked data valid. Thus, it is a good support to achieve interoperability.
As presented in Figure 4, the architecture of the semantic ontology validation tool is based on two major
parts: the front end and the back end. The front end takes most of the popular RDF serialization formats
as input in order to produce a set of evaluation results. In response to user interaction, the back end
parses the initial file, using either an XML or JSON parser. If there is no error, the RDF parser gets the
result as input. If it respects the specification of the RDF model, triples in this model are extracted to
serve as the input for the next validation step which is the “validation” module.
Semantic Ontology Validation
46
Figure 4. The architecture of the semantic ontology validator web app
Finally, the validation module takes the reference ontology which is constructed from the different
checked ontologies. The checked ontologies are merged into a single ontology and the triples are also
passed as input of the validation module. According to the predefined reference ontology, it checks the
syntactic errors in the document which is based on the functionalities implemented in Eyeball, a Jena
ontology validator [8]. A reasoner is used to enable the logical level verification of the RDF document,
such as the respect of subsumption relationships between classes, restrictions on class properties and
cardinality. The validation results are sent to a reporting server showing a list of errors (syntax, lexical
and logical) in JSON format, and explanations regarding the ontology affected elements. Once the report
is ready in the database, the frontend will get a notification in order to get the available ontology
validation report related to the user.
The component was initially developed as a syntactic and semantic ontology validator within the H2020
FIESTA-IoT project [1]. In WISE-IoT project, the semantic ontology validator has been extended to include
a new Quality of Information (QoI) module which includes multiple dimensions which are described
next.
4.1.1 Quality of Information (QoI) Module
The QoI module is a new dimension added to the semantic ontology validator that classifies the data
quality problems and checks syntactic accuracy, semantic accuracy, completeness, uniqueness and
timeliness dimensions. In the following description, we describe our approach to evaluate these
dimensions using data quality rules templates to express quality requirements which are automatically
used to identify deficient data. In fact, our proposed methodology attempts to raise the level of
objectivity when judging the quality, by providing a full test case file for each dimension:
4.1.1.1 Semantic & Syntactic Accuracy
It describes the proximity of data value representations of an object related to their real-world states.
We can distinguish two levels of accuracy: i) syntactic accuracy, which reflects the valid usage of the
underlying vocabularies and the valid syntax of the documents, and ii) semantic accuracy, which
Semantic Ontology Validation
47
describes the degree of correctness and precision with which the information in an information system
represents the states of the real world. Let us consider an example of a smart city use case and assume
that the ID of a specific parking spot is ParkingSpot1 while in the trust monitoring module (a SAR
component discussed in D2.6 [9]), the same parking spot is represented as ParkingSpot01. From a
syntactic perspective, it is a valid ID since it respects syntax specifications (i.e., string + integer), however
from the semantic perspective, it is an invalid ID because two parking IDs represent the same entity with
different syntax. The QoI module is capable to detect such type of errors by mainly applying three quality
rules: legal value rules, syntactic rules and legal value range rules.
4.1.1.2 Completeness
It describes the degree to which the information is not missing. We can distinguish three levels of completeness: (i) Schema completeness, which is the degree to which classes and properties are not missing in a schema, (ii) Column completeness, which is a function of the missing property values for a specific property/column, and (iii) Population completeness, which refers to the ratio between classes represented in an information system and the complete population. For smart parking use case, it is more related to the semantic descriptions of the sensors. The QoI module checks this dimension based on the properties and the vocabulary mentioned in the semantic description comparing the smart parking knowledge (i.e., smart parking ontology).
4.1.1.3 Timeliness
It reflects how up-to-date the data is with respect to the task it is used for. The data is usually being created and modified by many systems which may let some components use outdated data.
4.1.1.4 Conciseness/Uniqueness
It describes the degree to which the data is free of redundancies, in breadth, depth and scope. In smart
parking use case, let us consider the following scenario: ParkingSpot1, being represented by two
different properties in the same dataset, such as http://www.semanticweb.org/wise-
iot/ontologies/2017/1/parkingOntology.owl#ParkingSpotID and http://www.semanticweb.org/wise-
iot/ontologies/2017/1/parkingOntology.owl#name. This redundancy (‘ParkingSpotID’ and ‘name’ in this
case) can ideally be solved by fusing the two properties and keeping only one unique identifier. On the
other hand, an example of extensional conciseness is when both these identifiers of the same parking
spot have the same information associated with them in both the datasets, thus duplicating the
information.
4.2 Semantic Ontology Validation (1st Round)
This section presents the semantic interoperability validation results of the first validation round for
Wise-IoT ontologies (e.g., smart parking, smart skiing, crowd modelling and bus information system).
4.2.1 Smart Parking
For Smart Parking use case, there are two ontologies for smart parking and semantic descriptor for
parking spots. We provide a validation report for each ontology in this section.
Figure 5 presents the first round of semantic validation report for smart parking ontology. Among the
four types of validation tests, there is no error for ‘timeliness’ test. However, there are errors for
‘uniqueness’, ‘completeness’ and ‘semantic accuracy’ tests.
Semantic Ontology Validation
48
For ‘uniqueness’ test, there is one error as follows:
• On statement: _:b1001 owl:onDataRange :List[String] eye:badURI:
"http://www.semanticweb.org/wise-
iot/ontologies/2017/1/parking#List[String]" for reason:
"<http://www.semanticweb.org/wise-
iot/ontologies/2017/1/parking#List[String]> Code:
0/ILLEGAL_CHARACTER in FRAGMENT: The character violates the
grammar rules for URIs/IRIs.""
For ‘completeness’ test, there are five errors as follows:
• For statement ‘:location rdfs:range
http://www.w3.org/2003/01/geo/wgs84_pos#json’, the class is not declared in
any scheme ‘http://www.w3.org/2003/01/geo/wgs84_pos#json’.
• For statement ‘:requiredPermit rdfs:range :List[String]’, the class is not
declared in any scheme ‘:List[String]’.
• For statement ‘:permiteActiveHours rdfs:range
https://schema.org/openingHours#openingHours’, the class is not declared in
any scheme ‘https://schema.org/openingHours#openingHours’.
• For statement ‘:dateModified rdfs:range
https://schema.org/DateTime#DateTime’, the class is not declared in any scheme
‘https://schema.org/DateTime#DateTime’.
• For statement ‘:dateObserverd rdfs:range
https://schema.org/Duration#Duration’, the class is not declared in any scheme
‘https://schema.org/Duration#Duration’.
For ‘semantic accuracy’ test, there is one error as follows:
• HermiT supports all and only the datatypes of the OWL 2 datatype map, see
http://www.w3.org/TR/owl2-syntax/#Datatype_Maps. The datatype
'http://www.semanticweb.org/wise-
iot/ontologies/2017/1/parking#List[String]' is not part of the OWL 2
datatype map and no custom datatype definition is given . Therefore, HermiT cannot handle this
datatype.
{
"verdict": "FAIL",
"details": {
"owner": "wise-iot",
"extention": "owl",
"global_duration": "3407 ms",
"semantic_duration": "337 ms",
"start": "2018/02/09 11:00:02",
"results": [
{
"type": "Uniqueness",
"value": "
Semantic Ontology Validation
49
On statement: _:b1001 owl:onDataRange :List[String]
eye:badURI: "http://www.semanticweb.org/wise-
iot/ontologies/2017/1/parking#List[String]" for reason:
"<http://www.semanticweb.org/wise-
iot/ontologies/2017/1/parking#List[String]> Code:
0/ILLEGAL_CHARACTER in FRAGMENT: The character violates
the grammar rules for URIs/IRIs.""
},
{
"type": "Timeliness",
"value": ""
},
{
"type": "Completeness",
"value": "
On statement: :location rdfs:range
http://www.w3.org/2003/01/geo/wgs84_pos#json class not
declared in any schema:
http://www.w3.org/2003/01/geo/wgs84_pos#json
On statement: :requiredPermit rdfs:range :List[String]
class not declared in any schema: :List[String]
On statement: :permiteActiveHours rdfs:range
https://schema.org/openingHours#openingHours class not
declared in any schema:
https://schema.org/openingHours#openingHours
On statement: :dateModified rdfs:range
https://schema.org/DateTime#DateTime class not declared in
any schema: https://schema.org/DateTime#DateTime
On statement: :dateObserverd rdfs:range
https://schema.org/Duration#Duration class not declared in
any schema: https://schema.org/Duration#Duration"
},
{
"type": "Semantic Accuracy",
"value":
"HermiT supports all and only the datatypes of the OWL 2
datatype map, see http://www.w3.org/TR/owl2-
syntax/#Datatype_Maps. The datatype
'http://www.semanticweb.org/wise-
iot/ontologies/2017/1/parking#List[String]' is not part of
the OWL 2 datatype map and no custom datatype definition
is given; therefore, HermiT cannot handle this datatype."
}
],
"syntactic_duration": "3070 ms"
},
"status": "finished"
} Figure 5. First round of semantic validation report of Smart Parking ontology.
Semantic Ontology Validation
50
Figure 6 presents the first round of semantic validation report of semantic descriptor for parking spots
ontology. Among the four types of validation tests, there is no error for ‘uniqueness’, ‘timeliness’ and
‘semantic accuracy’ tests. However, there are errors for ‘completeness’ test.
For ‘completeness’ test, the errors are as follows:
• For statement ‘http://www.semanticweb.org/wise-iot/ontologies/2017/1/parkingOntology.owl#parkinSpgot1
park:hasCategory
"onstreet"^^http://www.w3.org/2001/XMLSchema#string’, the predicate is
not declared in any scheme ‘park:hasCategory’.
• For statement ‘http://www.semanticweb.org/wise-iot/ontologies/2017/1/parkingOntology.owl#parkinSpgot1 rdf:type
park:ParkingSpot’, the class is not declared in any scheme ‘park:ParkingSpot’.
• For statement ‘http://www.semanticweb.org/wise-iot/ontologies/2017/1/parkingOntology.owl#parkinSpgot1
park:hasName
"parkingSpot1"^^http://www.w3.org/2001/XMLSchema#string’, the
predicate is not declared in any scheme ‘park:hasName’.
• For statement ‘http://www.semanticweb.org/wise-iot/ontologies/2017/1/parkingOntology.owl#parkinSpgot1
park:hasId "abcded"^^http://www.w3.org/2001/XMLSchema#string’, the
predicate is not declared in any scheme ‘park:hasId’.
• For statement ‘http://www.semanticweb.org/wise-iot/ontologies/2017/1/parkingOntology.owl#ketiLobbyPark rdf:type
park:OnStreetParking’, the class is not declared in any scheme
‘park:OnStreetParking’.
• For statement ‘http://www.semanticweb.org/wise-iot/ontologies/2017/1/parkingOntology.owl#parkinSpgot1
park:hasRefParkingSite http://www.semanticweb.org/wise-
iot/ontologies/2017/1/parkingOntology.owl#ketiLobbyPark’, the
predicate is not declared in any scheme ‘park:hasRefParkingSite’.
• For statement ‘http://www.semanticweb.org/wise-iot/ontologies/2017/1/parkingOntology.owl#parkinSpgot1
park:hasType
"ParkingSpot"^^http://www.w3.org/2001/XMLSchema#string’, the predicate
is not declared in any scheme ‘park:hasType’.
• For statement ‘http://www.semanticweb.org/wise-iot/ontologies/2017/1/parkingOntology.owl#parkinSpgot1
park:hasDateModified "2017-04-
18T02:23:30Z"^^http://www.w3.org/2001/XMLSchema#dateTimeStamp’,
the predicate is not declared in any scheme ‘park:hasDateModified’.
Semantic Ontology Validation
51
{
"verdict": "FAIL",
"details": {
"owner": "wise-iot",
"extention": "xml",
"global_duration": "1402 ms",
"semantic_duration": "149 ms",
"start": "2018/02/09 11:04:27",
"results": [
{
"type": "Uniqueness",
"value": ""
},
{
"type": "Timeliness",
"value": ""
},
{
"type": "Completeness",
"value": "
On statement: http://www.semanticweb.org/wise-
iot/ontologies/2017/1/parkingOntology.owl#parkinSpgot1
park:hasCategory
"onstreet"^^http://www.w3.org/2001/XMLSchema#string
predicate not declared in any schema: park:hasCategory
On statement: http://www.semanticweb.org/wise-
iot/ontologies/2017/1/parkingOntology.owl#parkinSpgot1
rdf:type park:ParkingSpot class not declared in any schema:
park:ParkingSpot
On statement: http://www.semanticweb.org/wise-
iot/ontologies/2017/1/parkingOntology.owl#parkinSpgot1
park:hasName
"parkingSpot1"^^http://www.w3.org/2001/XMLSchema#string
predicate not declared in any schema: park:hasName
On statement: http://www.semanticweb.org/wise-
iot/ontologies/2017/1/parkingOntology.owl#parkinSpgot1
park:hasId
"abcded"^^http://www.w3.org/2001/XMLSchema#string
predicate not declared in any schema: park:hasId
On statement: http://www.semanticweb.org/wise-
iot/ontologies/2017/1/parkingOntology.owl#ketiLobbyPark
rdf:type park:OnStreetParking class not declared in any
schema: park:OnStreetParking
On statement: http://www.semanticweb.org/wise-
iot/ontologies/2017/1/parkingOntology.owl#parkinSpgot1
park:hasRefParkingSite http://www.semanticweb.org/wise-
iot/ontologies/2017/1/parkingOntology.owl#ketiLobbyPark
predicate not declared in any schema:
park:hasRefParkingSite
Semantic Ontology Validation
52
On statement: http://www.semanticweb.org/wise-
iot/ontologies/2017/1/parkingOntology.owl#parkinSpgot1
park:hasType
"ParkingSpot"^^http://www.w3.org/2001/XMLSchema#string
predicate not declared in any schema: park:hasType
On statement: http://www.semanticweb.org/wise-
iot/ontologies/2017/1/parkingOntology.owl#parkinSpgot1
park:hasDateModified "2017-04-
18T02:23:30Z"^^http://www.w3.org/2001/XMLSchema#dateTimeS
tamp predicate not declared in any schema:
park:hasDateModified"
},
{
"type": "Semantic Accuracy",
"value": ""
}
],
"syntactic_duration": "1253 ms"
},
"status": "finished"
} Figure 6. First round of semantic validation report of semantic descriptor for parking spots ontology.
4.2.2 Smart Skiing
Figure 7 presents the first round of semantic validation report for smart skiing ontology. Among the four
types of validation tests, there is no error for ‘uniqueness’ and ‘timeliness’ tests. However, there are
errors in ‘completeness’ and ‘semantic accuracy’ tests.
For ‘completeness’ test, there is one error as follows:
• For statement ‘:coordinates rdfs:range http://purl.org/iot/vocab/m3-
lite#Coordinate’, the class ‘http://purl.org/iot/vocab/m3-
lite#Coordinates’ does not exist in any scheme.
For ‘semantic accuracy’ test, there is one error as follows:
• The data type ‘http://purl.org/iot/vocab/m3-lite#Coordinates’ is neither
part of the OWL 2 datatype map nor custom datatype definition is provided.
{
"verdict": "FAIL",
"details": {
"owner": "wise-iot",
"extention": "owl",
"global_duration": "3502 ms",
"semantic_duration": "313 ms",
"start": "2018/02/09 10:11:51",
"results": [
{
"type": " Uniqueness", "value": ""
Semantic Ontology Validation
53
},
{
"type": "Timeliness",
"value": ""
},
{
"type": "Completeness",
"value":
"On statement: :coordinates rdfs:range
http://purl.org/iot/vocab/m3-lite#Coordinate class not
declared in any schema: http://purl.org/iot/vocab/m3-
lite#Coordinates"
},
{
"type": "Semantic Accuracy",
"value":
"http://www.w3.org/TR/owl2-syntax/#Datatype_Maps. The
datatype 'http://purl.org/iot/vocab/m3-lite#Coordinates'
is not part of the OWL 2 datatype map and no custom datatype
definition is given"
}
],
"syntactic_duration": "3189 ms"
},
"status": "finished"
} Figure 7. First round of semantic validation report of Smart Skiing ontology
4.2.3 Crowd Modelling
Figure 8 presents the first round of semantic validation report for crowd modelling ontology. Among the
four types of validation tests, there is no error for ‘timeliness’ and ‘completeness’ tests. However, there
are some errors for ‘uniqueness’ and ‘semantic accuracy’ tests.
For ‘uniqueness’ test, there is one error as follows:
• "eye:multiplePrefixesForNamespace:
"http://www.semanticweb.org/wise-
iot/ontologies/2017/2/crowdmodelling#" on prefix: "" on
prefix: "nle""
For ‘semantic accuracy’ test, there is one error as follows:
• In OWL 2 DL, ‘owl:topDataProperty’ is only allowed to occur in the super property
position of ‘SubDataPropertyOf’ axioms, but the ontology contains an axiom
DataPropertyRange (owl:topDataProperty xsd:boolean) that violates this
condition.
Semantic Ontology Validation
54
{
"verdict": "FAIL",
"details": {
"owner": "wise-iot",
"extention": "owl",
"global_duration": "1748 ms",
"semantic_duration": "40 ms",
"start": "2018/02/09 10:30:52",
"results": [
{
"type": "Uniqueness",
"value":
"eye:multiplePrefixesForNamespace:
"http://www.semanticweb.org/wise-
iot/ontologies/2017/2/crowdmodelling#" on prefix: ""
on prefix: "nle""
},
{
"type": "Timeliness",
"value": ""
},
{
"type": "Completeness",
"value": ""
},
{
"type": "Semantic Accuracy",
"value":
"Error: In OWL 2 DL, owl:topDataProperty is only allowed
to occur in the super property position of
SubDataPropertyOf axioms, but the ontology contains an
axiom DataPropertyRange(owl:topDataProperty xsd:boolean)
that violates this condition."
}
],
"syntactic_duration": "1708 ms"
},
"status": "finished"
} Figure 8. First round of semantic validation report of crowd modelling ontology
4.2.4 Bus Information System
For Bus Information System, there are three ontologies for bus estimation, bus line and bus stop. We
provide a validation report for each ontology in this section.
Figure 9 presents semantic validation report for bus estimation ontology. Among the four types of
validation tests, there is no error for ‘uniqueness’, ‘timeliness’ and ‘semantic accuracy’ tests. However,
there are some errors for ‘completeness’ test.
For ‘completeness’ test, the errors are as follows:
Semantic Ontology Validation
55
• For statement ‘http://www.semanticweb.org/wise-iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasRefBusLines
"["urn:entity:busan:transport:bus:busStop:[busLineId]"]"^^http:
//www.w3.org/2001/XMLSchema#string’, the predicate is not declared in any scheme
‘smartBus:hasRefBusLines’.
• For statement ‘_:b1001 smartBus:hasLatitude
"127.363"^^http://www.w3.org/2001/XMLSchema#double’, the predicate is
not declared in any scheme ‘smartBus:hasLatitude’.
• For statement ‘http://www.semanticweb.org/wise-iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasRefBuses
"["urn:entity:busan:transport:bus:bus:[busId]"]"^^http://www.w3
.org/2001/XMLSchema#string’, the predicate is not declared in any scheme
‘smartBus:hasRefBuses’.
• For statement ‘http://www.semanticweb.org/wise-iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasShortID
"11161"^^http://www.w3.org/2001/XMLSchema#string’, the predicate is not
declared in any scheme ‘smartBus:hasShortID’.
• For statement ‘http://www.semanticweb.org/wise-iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasAddress _:b1002’, the predicate is not declared in any scheme
‘smartBus:hasAddress’.
• For statement ‘http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasLocation _:b1001’, the predicate is not declared in any scheme
‘smartBus:hasLocation’.
• For statement ‘http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasDirection
"NA"^^http://www.w3.org/2001/XMLSchema#string’, the predicate is not
declared in any scheme ‘smartBus:hasDirection’.
• For statement ‘_:b1002 rdf:type smartBus:PostalAddress’, the class is not
declared in any scheme ‘smartBus:PostalAddress’.
• For statement ‘_:b1001 rdf:type smartBus:hasCoordinates’, the class is not
declared in any scheme ‘smartBus:hasCoordinates’.
• For statement ‘_:b1002 smartBus:hasAddressLocality "Denver"’, the
predicate is not declared in any scheme ‘smartBus:hasAddressLocality’.
• For statement ‘http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasBusStopCount
Semantic Ontology Validation
56
"[1,2]"^^http://www.w3.org/2001/XMLSchema#string’, the predicate is not
declared in any scheme ‘smartBus:hasBusStopCount’.
• For statement ‘http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo rdf:type
smartBus:busStop’, the class is not declared in any scheme ‘smartBus:busStop’.
• For statement ‘http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasDateModified "2017-04-
18T02:23:30Z"^^http://www.w3.org/2001/XMLSchema#dateTimeStamp’,
the predicate is not declared in any scheme ‘smartBus:hasDateModified’.
• For statement ‘_:b1002 smartBus:hasStreetAddress "7 S. Broadway"’, the
predicate is not declared in any scheme ‘smartBus:hasStreetAddress’.
• For statement ‘_:b1001 smartBus:hasLongitude
"36.372"^^http://www.w3.org/2001/XMLSchema#double’, the predicate is not
declared in any scheme ‘smartBus:hasLongitude’.
• For statement ‘_:b1002 smartBus:hasPostalCode "80209"’, the predicate is not
declared in any scheme ‘smartBus:hasPostalCode’.
• For statement ‘http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo smartBus:hasId
"urn:entity:busan:transport:bus:busId:[busStopId]"^^http://www.
w3.org/2001/XMLSchema#string’, the predicate is not declared in any scheme
‘smartBus:hasId’.
• For statement ‘http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasName "city
hall"^^http://www.w3.org/2001/XMLSchema#string’, the predicate is not
declared in any scheme ‘smartBus:hasName’.
• For statement ‘_:b1002 smartBus:hasAddressRegion "CO"’, the predicate is not
declared in any scheme ‘smartBus:hasAddressRegion’.
{
"verdict": "FAIL",
"details": {
"owner": "wise-iot",
"extention": "xml",
"global_duration": "1179 ms",
"semantic_duration": "11 ms",
"start": "2018/03/14 21:03:47",
"results": [
{
"type": "Uniqueness",
"value": ""
},
Semantic Ontology Validation
57
{
"type": "Timeliness",
"value": ""
},
{
"type": "Completeness",
"value": "
On statement: http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasRefBusLines
"["urn:entity:busan:transport:bus:busStop:[busLineId]"]"^
^http://www.w3.org/2001/XMLSchema#string predicate not
declared in any schema: smartBus:hasRefBusLines
On statement: _:b1001 smartBus:hasLatitude
"127.363"^^http://www.w3.org/2001/XMLSchema#double
predicate not declared in any schema: smartBus:hasLatitude
On statement: http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasRefBuses
"["urn:entity:busan:transport:bus:bus:[busId]"]"^^http://
www.w3.org/2001/XMLSchema#string predicate not declared in
any schema: smartBus:hasRefBuses
On statement: http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasShortID
"11161"^^http://www.w3.org/2001/XMLSchema#string
predicate not declared in any schema: smartBus:hasShortID
On statement: http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasAddress _:b1002 predicate not declared in any
schema: smartBus:hasAddress
On statement: http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasLocation _:b1001 predicate not declared in any
schema: smartBus:hasLocation
On statement: http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasDirection
"NA"^^http://www.w3.org/2001/XMLSchema#string predicate
not declared in any schema: smartBus:hasDirection
On statement: _:b1002 rdf:type smartBus:PostalAddress
class not declared in any schema: smartBus:PostalAddress
On statement: _:b1001 rdf:type smartBus:hasCoordinates
class not declared in any schema: smartBus:hasCoordinates
Semantic Ontology Validation
58
On statement: _:b1002 smartBus:hasAddressLocality "Denver"
predicate not declared in any schema:
smartBus:hasAddressLocality
On statement: http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasBusStopCount
"[1,2]"^^http://www.w3.org/2001/XMLSchema#string
predicate not declared in any schema:
smartBus:hasBusStopCount
On statement: http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo rdf:type
smartBus:busStop class not declared in any schema:
smartBus:busStop
On statement: http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasDateModified "2017-04-
18T02:23:30Z"^^http://www.w3.org/2001/XMLSchema#dateTimeS
tamp predicate not declared in any schema:
smartBus:hasDateModified
On statement: _:b1002 smartBus:hasStreetAddress "7 S.
Broadway" predicate not declared in any schema:
smartBus:hasStreetAddress
On statement: _:b1001 smartBus:hasLongitude
"36.372"^^http://www.w3.org/2001/XMLSchema#double
predicate not declared in any schema:
smartBus:hasLongitude
On statement: _:b1002 smartBus:hasPostalCode "80209"
predicate not declared in any schema:
smartBus:hasPostalCode
On statement: http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasId
"urn:entity:busan:transport:bus:busId:[busStopId]"^^http:
//www.w3.org/2001/XMLSchema#string predicate not declared
in any schema: smartBus:hasId
On statement: http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasName "city
hall"^^http://www.w3.org/2001/XMLSchema#string predicate
not declared in any schema: smartBus:hasName
On statement: _:b1002 smartBus:hasAddressRegion "CO"
predicate not declared in any schema:
smartBus:hasAddressRegion
"
},
{
Semantic Ontology Validation
59
"type": "Semantic Accuracy",
"value": ""
}
],
"syntactic_duration": "1168 ms"
},
"status": "finished"
} Figure 9. Semantic validation report of bus estimation ontology
Figure 10 presents semantic validation report for bus line ontology. Among the four types of validation
tests, there is no error for ‘uniqueness’, ‘timeliness’ and ‘semantic accuracy’ tests. However, there are
some errors for ‘completeness’ test.
For ‘completeness’ test, the errors are as follows:
• For statement ‘http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasName "PENACASTILLO \u0080\u0093 PLAZA DE
ITALIA"^^http://www.w3.org/2001/XMLSchema#string’, the predicate is not
declared in any scheme ‘smartBus:hasName’.
• For statement ‘http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasIntervalNorm
"P3Y6M4DT12H30M5S"^^http://www.w3.org/2001/XMLSchema#duration’,
the predicate is not declared in any scheme ‘smartBus:hasIntervalNorm’.
• For statement ‘http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasRefStartBusStop
"["urn:entity:busan:transport:bus:busStop:[busStopId]"]"^^http:
//www.w3.org/2001/XMLSchema#string’, the predicate is not declared in any
scheme ‘smartBus:hasRefStartBusStop’.
• For statement ‘http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasEndTime "2017-02-05T08:15:30-
05:09"^^http://www.w3.org/2001/XMLSchema#dateTime’, the predicate is not
declared in any scheme ‘smartBus:hasEndTime’.
• For statement ‘http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasRefBusStops
"["urn:entity:busan:transport:bus:busStop:[busStopId]"]"^^http:
//www.w3.org/2001/XMLSchema#string’, the predicate is not declared in any
scheme ‘smartBus:hasRefBusStops’.
• For statement ‘http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasStartTime "2017-02-05T08:15:30-
Semantic Ontology Validation
60
05:09"^^http://www.w3.org/2001/XMLSchema#dateTime’, the predicate is not
declared in any scheme ‘smartBus:hasStartTime’.
• For statement ‘http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasIntervalHoli
"P3Y6M4DT12H30M5S"^^http://www.w3.org/2001/XMLSchema#duration’,
the predicate is not declared in any scheme ‘smartBus:hasIntervalHoli’.
• For statement ‘http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasDateModified "2017-04-
18T02:23:30Z"^^http://www.w3.org/2001/XMLSchema#dateTimeStamp’,
the predicate is not declared in any scheme ‘smartBus:hasDateModified’.
• For statement ‘http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasLocalID
"11161"^^http://www.w3.org/2001/XMLSchema#string’, the predicate is not
declared in any scheme ‘smartBus:hasLocalID’.
• For statement ‘http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasIntervalPeak
"P3Y6M4DT12H30M5S"^^http://www.w3.org/2001/XMLSchema#duration’,
the predicate is not declared in any scheme ‘smartBus:hasIntervalPeak’.
• For statement ‘http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasShortID
"11161"^^http://www.w3.org/2001/XMLSchema#string’, the predicate is not
declared in any scheme ‘smartBus:hasShortID’.
• For statement ‘http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo rdf:type
smartBus:busLine’, the class is not declared in any scheme ‘smartBus:busLine’.
• For statement ‘http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasRefEndBusStop
"["urn:entity:busan:transport:bus:busStop:[busStopId]"]"^^http:
//www.w3.org/2001/XMLSchema#string’, the predicate is not declared in any
scheme ‘smartBus:hasRefEndBusStop’.
• For statement ‘http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo smartBus:hasId
"urn:entity:busan:transport:bus:busId:[busLineId]"^^http://www.
w3.org/2001/XMLSchema#string’, the predicate is not declared in any scheme
‘smartBus:hasId’.
{
Semantic Ontology Validation
61
"verdict": "FAIL",
"details": {
"owner": "wise-iot",
"extention": "xml",
"global_duration": "1308 ms",
"semantic_duration": "9 ms",
"start": "2018/03/14 21:02:05",
"results": [
{
"type": "Uniqueness",
"value": ""
},
{
"type": "Timeliness",
"value": ""
},
{
"type": "Completeness",
"value": "
On statement: http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasName "PENACASTILLO \u0080\u0093 PLAZA DE
ITALIA"^^http://www.w3.org/2001/XMLSchema#string
predicate not declared in any schema: smartBus:hasName
On statement: http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasIntervalNorm
"P3Y6M4DT12H30M5S"^^http://www.w3.org/2001/XMLSchema#dura
tion predicate not declared in any schema:
smartBus:hasIntervalNorm
On statement: http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasRefStartBusStop
"["urn:entity:busan:transport:bus:busStop:[busStopId]"]"^
^http://www.w3.org/2001/XMLSchema#string predicate not
declared in any schema: smartBus:hasRefStartBusStop
On statement: http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasEndTime "2017-02-05T08:15:30-
05:09"^^http://www.w3.org/2001/XMLSchema#dateTime
predicate not declared in any schema: smartBus:hasEndTime
On statement: http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasRefBusStops
"["urn:entity:busan:transport:bus:busStop:[busStopId]"]"^
^http://www.w3.org/2001/XMLSchema#string predicate not
declared in any schema: smartBus:hasRefBusStops
On statement: http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
Semantic Ontology Validation
62
smartBus:hasStartTime "2017-02-05T08:15:30-
05:09"^^http://www.w3.org/2001/XMLSchema#dateTime
predicate not declared in any schema:
smartBus:hasStartTime
On statement: http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasIntervalHoli
"P3Y6M4DT12H30M5S"^^http://www.w3.org/2001/XMLSchema#dura
tion predicate not declared in any schema:
smartBus:hasIntervalHoli
On statement: http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasDateModified "2017-04-
18T02:23:30Z"^^http://www.w3.org/2001/XMLSchema#dateTimeS
tamp predicate not declared in any schema:
smartBus:hasDateModified
On statement: http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasLocalID
"11161"^^http://www.w3.org/2001/XMLSchema#string
predicate not declared in any schema: smartBus:hasLocalID
On statement: http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasIntervalPeak
"P3Y6M4DT12H30M5S"^^http://www.w3.org/2001/XMLSchema#dura
tion predicate not declared in any schema:
smartBus:hasIntervalPeak
On statement: http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasShortID
"11161"^^http://www.w3.org/2001/XMLSchema#string
predicate not declared in any schema: smartBus:hasShortID
On statement: http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo rdf:type
smartBus:busLine class not declared in any schema:
smartBus:busLine
On statement: http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasRefEndBusStop
"["urn:entity:busan:transport:bus:busStop:[busStopId]"]"^
^http://www.w3.org/2001/XMLSchema#string predicate not
declared in any schema: smartBus:hasRefEndBusStop
On statement: http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasId
"urn:entity:busan:transport:bus:busId:[busLineId]"^^http:
//www.w3.org/2001/XMLSchema#string predicate not declared
in any schema: smartBus:hasId"
Semantic Ontology Validation
63
},
{
"type": "Semantic Accuracy",
"value": ""
}
],
"syntactic_duration": "1299 ms"
},
"status": "finished"
} Figure 10. Semantic validation report of bus line ontology
Figure 11 presents semantic validation report for bus stop ontology. Among the four types of validation
tests, there is no error for ‘uniqueness’, ‘timeliness’ and ‘semantic accuracy’ tests. However, there are
some errors for ‘completeness’ test.
For ‘completeness’ test, the errors are as follows:
• For statement ‘http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasRefBusLines
"["urn:entity:busan:transport:bus:busStop:[busLineId]"]"^^http:
//www.w3.org/2001/XMLSchema#string’, the predicate is not declared in any
scheme ‘smartBus:hasRefBusLines’.
• For statement ‘_:b1001 smartBus:hasLatitude
"127.363"^^http://www.w3.org/2001/XMLSchema#double’, the predicate is
not declared in any scheme ‘smartBus:hasLatitude’.
• For statement ‘http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasRefBuses
"["urn:entity:busan:transport:bus:bus:[busId]"]"^^http://www.w3
.org/2001/XMLSchema#string’, the predicate is not declared in any scheme
‘smartBus:hasRefBuses’.
• For statement ‘http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasShortID
"11161"^^http://www.w3.org/2001/XMLSchema#string’, the predicate is not
declared in any scheme ‘smartBus:hasShortID’.
• For statement ‘http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasAddress _:b1002’, the predicate is not declared in any scheme
‘smartBus:hasAddress’.
• For statement ‘http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasLocation _:b1001’, the predicate is not declared in any scheme
‘smartBus:hasLocation’.
Semantic Ontology Validation
64
• For statement ‘http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasDirection
"NA"^^http://www.w3.org/2001/XMLSchema#string’, the predicate is not
declared in any scheme ‘smartBus:hasDirection’.
• For statement ‘_:b1002 rdf:type smartBus:PostalAddress’, the class is not
declared in any scheme ‘smartBus:PostalAddress’.
• For statement ‘_:b1001 rdf:type smartBus:hasCoordinates’, the class is not
declared in any scheme ‘smartBus:hasCoordinates’.
• For statement ‘_:b1002 smartBus:hasAddressLocality "Denver"’, the
predicate is not declared in any scheme ‘smartBus:hasAddressLocality’.
• For statement ‘http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasBusStopCount
"[1,2]"^^http://www.w3.org/2001/XMLSchema#string’, the predicate is not
declared in any scheme ‘smartBus:hasBusStopCount’.
• For statement ‘http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo rdf:type
smartBus:busStop’, the class is not declared in any scheme ‘smartBus:busStop’.
• For statement ‘http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasDateModified "2017-04-
18T02:23:30Z"^^http://www.w3.org/2001/XMLSchema#dateTimeStamp’,
the predicate is not declared in any scheme ‘smartBus:hasDateModified’.
• For statement ‘_:b1002 smartBus:hasStreetAddress "7 S. Broadway"’, the
predicate is not declared in any scheme ‘smartBus:hasStreetAddress’.
• For statement ‘_:b1001 smartBus:hasLongitude
"36.372"^^http://www.w3.org/2001/XMLSchema#double’, the predicate is not
declared in any scheme ‘smartBus:hasLongitude’.
• For statement ‘_:b1002 smartBus:hasPostalCode "80209"’, the predicate is not
declared in any scheme ‘smartBus:hasPostalCode’.
• For statement ‘http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo smartBus:hasId
"urn:entity:busan:transport:bus:busId:[busStopId]"^^http://www.
w3.org/2001/XMLSchema#string’, the predicate is not declared in any scheme
‘smartBus:hasId’.
• For statement ‘http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasName "city
hall"^^http://www.w3.org/2001/XMLSchema#string’, the predicate is not
declared in any scheme ‘smartBus:hasName’.
Semantic Ontology Validation
65
• For statement ‘_:b1002 smartBus:hasAddressRegion "CO"’, the predicate is not
declared in any scheme ‘smartBus:hasAddressRegion’.
Semantic Ontology Validation
66
{
"verdict": "FAIL",
"details": {
"owner": "wise-iot",
"extention": "xml",
"global_duration": "1179 ms",
"semantic_duration": "11 ms",
"start": "2018/03/14 21:03:47",
"results": [
{
"type": "Uniqueness",
"value": ""
},
{
"type": "Timeliness",
"value": ""
},
{
"type": "Completeness",
"value": "
On statement: http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasRefBusLines
"["urn:entity:busan:transport:bus:busStop:[busLineId]"]"
^^http://www.w3.org/2001/XMLSchema#string predicate not
declared in any schema: smartBus:hasRefBusLines
On statement: _:b1001 smartBus:hasLatitude
"127.363"^^http://www.w3.org/2001/XMLSchema#double
predicate not declared in any schema: smartBus:hasLatitude
On statement: http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasRefBuses
"["urn:entity:busan:transport:bus:bus:[busId]"]"^^http:/
/www.w3.org/2001/XMLSchema#string predicate not declared
in any schema: smartBus:hasRefBuses
On statement: http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasShortID
"11161"^^http://www.w3.org/2001/XMLSchema#string
predicate not declared in any schema: smartBus:hasShortID
On statement: http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasAddress _:b1002 predicate not declared in any
schema: smartBus:hasAddress
On statement: http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasLocation _:b1001 predicate not declared in any
schema: smartBus:hasLocation
Semantic Ontology Validation
67
On statement: http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasDirection
"NA"^^http://www.w3.org/2001/XMLSchema#string predicate
not declared in any schema: smartBus:hasDirection
On statement: _:b1002 rdf:type smartBus:PostalAddress
class not declared in any schema: smartBus:PostalAddress
On statement: _:b1001 rdf:type smartBus:hasCoordinates
class not declared in any schema: smartBus:hasCoordinates
On statement: _:b1002 smartBus:hasAddressLocality "Denver"
predicate not declared in any schema:
smartBus:hasAddressLocality
On statement: http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasBusStopCount
"[1,2]"^^http://www.w3.org/2001/XMLSchema#string
predicate not declared in any schema:
smartBus:hasBusStopCount
On statement: http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo rdf:type
smartBus:busStop class not declared in any schema:
smartBus:busStop
On statement: http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasDateModified "2017-04-
18T02:23:30Z"^^http://www.w3.org/2001/XMLSchema#dateTimeS
tamp predicate not declared in any schema:
smartBus:hasDateModified
On statement: _:b1002 smartBus:hasStreetAddress "7 S.
Broadway" predicate not declared in any schema:
smartBus:hasStreetAddress
On statement: _:b1001 smartBus:hasLongitude
"36.372"^^http://www.w3.org/2001/XMLSchema#double
predicate not declared in any schema:
smartBus:hasLongitude
On statement: _:b1002 smartBus:hasPostalCode "80209"
predicate not declared in any schema:
smartBus:hasPostalCode
On statement: http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasId
"urn:entity:busan:transport:bus:busId:[busStopId]"^^http:
//www.w3.org/2001/XMLSchema#string predicate not declared
in any schema: smartBus:hasId
Semantic Ontology Validation
68
On statement: http://www.semanticweb.org/wise-
iot/ontologies/2017/1/smartBus.owl#bussanBusInfo
smartBus:hasName "city
hall"^^http://www.w3.org/2001/XMLSchema#string predicate
not declared in any schema: smartBus:hasName
On statement: _:b1002 smartBus:hasAddressRegion "CO"
predicate not declared in any schema:
smartBus:hasAddressRegion"
},
{
"type": "Semantic Accuracy",
"value": ""
}
],
"syntactic_duration": "1168 ms"
},
"status": "finished"
} Figure 11. Semantic validation report of bus stop ontology
4.3 Semantic Ontology Validation (2nd Round)
Based on the identified errors by semantic inteoperability validation tests in Section 4.2, the ontology
designers have fixed the errors in their ontologies which are tested again by semantic ontology validator.
This section presents the semantic interoperability validation results of the second validation cycle for
Wise-IoT ontologies (e.g., smart parking, smart skiing, crowd modelling and bus information sytem).
4.3.1 Smart Parking
Figure 12 presents the second round of semantic validation report for smart parking ontology. The
semantic ontology validation is passed for all the four tests and all the errors are resolved.
{
"verdict": "PASS",
"details": {
"owner": "wise-iot",
"extention": "owl",
"global_duration": "3407 ms",
"semantic_duration": "337 ms",
"start": "2018/04/10 18:08:52",
"results": [
{
"type": "Uniqueness",
"value": ""
},
{
"type": "Timeliness",
"value": ""
},
Semantic Ontology Validation
69
{
"type": "Completeness",
"value": ""
},
{
"type": "Semantic Accuracy",
"value": ""
}
],
"syntactic_duration": "1708 ms"
},
"status": "finished"
} Figure 12. Second round of semantic validation report of Smart Parking ontology.
Figure 13 presents the second round of semantic validation report of semantic descriptor for parking
spots ontology. The semantic ontology validation is passed for all the four tests and all the errors are
resolved.
{
"verdict": "PASS",
"details": {
"owner": "wise-iot",
"extention": "owl",
"global_duration": "1402 ms",
"semantic_duration": "149 ms",
"start": "2018/04/10 18:14:03",
"results": [
{
"type": "Uniqueness",
"value": ""
},
{
"type": "Timeliness",
"value": ""
},
{
"type": "Completeness",
"value": ""
},
{
"type": "Semantic Accuracy",
"value": ""
}
],
"syntactic_duration": "1708 ms"
},
"status": "finished"
} Figure 13. Second round of semantic validation report of semantic descriptor for parking spots ontology.
Semantic Ontology Validation
70
4.3.2 Smart Skiing
Figure 14 presents the second round of semantic validation report for smart skiing ontology. The
semantic ontology validation is passed for all the four tests and all the errors are resolved.
{
"verdict": "PASS",
"details": {
"owner": "wise-iot",
"extention": "owl",
"global_duration": "3502 ms",
"semantic_duration": "313 ms",
"start": "2018/04/10 18:19:02",
"results": [
{
"type": "Uniqueness",
"value": ""
},
{
"type": "Timeliness",
"value": ""
},
{
"type": "Completeness",
"value": ""
},
{
"type": "Semantic Accuracy",
"value": ""
}
],
"syntactic_duration": "1708 ms"
},
"status": "finished"
} Figure 14. Second round of semantic validation report of Smart Skiing ontology
4.3.3 Crowd Modelling
Figure 15 presents the second round of semantic validation report for crowd modelling ontology. The
semantic ontology validation is passed for all the four tests and all the errors are resolved.
{
"verdict": "PASS",
"details": {
"owner": "wise-iot",
"extention": "owl",
"global_duration": "1748 ms",
"semantic_duration": "40 ms",
"start": "2018/04/10 18:23:17",
"results": [
{
Semantic Ontology Validation
71
"type": "Uniqueness",
"value": ""
},
{
"type": "Timeliness",
"value": ""
},
{
"type": "Completeness",
"value": ""
},
{
"type": "Semantic Accuracy",
"value": ""
}
],
"syntactic_duration": "1708 ms"
},
"status": "finished"
} Figure 15. Second round of semantic validation report of crowd modelling ontology
4.3.4 Bus Information System
Figure 16, Figure 17 and Figure 18 present the second round of semantic validation reports for bus
estimation, bus line and bus stop ontologies, respectively. The semantic ontology validation is passed
for all the four tests and all the errors are resolved.
{
"verdict": "PASS",
"details": {
"owner": "wise-iot",
"extention": "owl",
"global_duration": "5119 ms",
"semantic_duration": "232 ms",
"start": "2018/05/14 17:51:47",
"results": [
{
"type": " Uniqueness", "value": ""
},
{
"type": " Timeliness", "value": ""
},
{
"type": " Completeness", "value": ""
},
Semantic Ontology Validation
72
{
"type": " Semantic Accuracy", "value": ""
}
],
"syntactic_duration": "4887 ms"
},
"status": "finished"
} Figure 16. Second round of semantic validation report of bus estimation ontology
{
"verdict": "PASS",
"details": {
"owner": "wise-iot",
"extention": "owl",
"global_duration": "1308 ms",
"semantic_duration": "9 ms",
"start": "2018/05/14 17:41:50",
"results": [
{
"type": " Uniqueness", "value": ""
},
{
"type": " Timeliness", "value": ""
},
{
"type": " Completeness", "value": ""
},
{
"type": " Semantic Accuracy", "value": ""
}
],
"syntactic_duration": "1299 ms"
},
"status": "finished"
} Figure 17. Second round of semantic validation report of bus line ontology
{
"verdict": "PASS",
"details": {
"owner": "wise-iot",
"extention": "owl",
"global_duration": "1179 ms",
"semantic_duration": "11 ms",
Semantic Ontology Validation
73
"start": "2018/05/14 17:55:23",
"results": [
{
"type": " Uniqueness", "value": ""
},
{
"type": " Timeliness", "value": ""
},
{
"type": " Completeness", "value": ""
},
{
"type": " Semantic Accuracy", "value": ""
}
],
"syntactic_duration": "1168 ms"
},
"status": "finished"
} Figure 18. Second round of semantic validation report of bus stop ontology
4.4 Summary of Semantic Ontology Validation Results
This section presents Table 4 summarizing the semantic ontology validation results for 1st and 2nd rounds
representing the number of the detected errors (in case of failed validation) or validation passed (in case
of successful validation).
Table 4. Summary of Semantic Ontology Validation Results for 1st and 2nd Rounds
Ontology Semantic Validation Test 1st Round Result 2nd Round Result
Smart Parking
Syntactic Accuracy Pass Pass
Semantic Accuracy 1 error Pass
Completeness 5 errors Pass
Timeliness Pass Pass
Uniqueness/Conciseness 1 error Pass
Parking Spots
Syntactic Accuracy Pass Pass
Semantic Accuracy Pass Pass
Completeness 8 errors Pass
Timeliness Pass Pass
Uniqueness/Conciseness Pass Pass
Smart Skiing
Syntactic Accuracy Pass Pass
Semantic Accuracy 1 error Pass
Completeness 1 error Pass
Timeliness Pass Pass
Uniqueness/Conciseness Pass Pass
Crowd Modelling Syntactic Accuracy Pass Pass
Semantic Ontology Validation
74
Semantic Accuracy 1 error Pass
Completeness Pass Pass
Timeliness Pass Pass
Uniqueness/Conciseness 1 error Pass
Bus Estimation
Syntactic Accuracy Pass Pass
Semantic Accuracy Pass Pass
Completeness 19 errors Pass
Timeliness Pass Pass
Uniqueness/Conciseness Pass Pass
Bus Line
Syntactic Accuracy Pass Pass
Semantic Accuracy Pass Pass
Completeness 14 errors Pass
Timeliness Pass Pass
Uniqueness/Conciseness Pass Pass
Bus Stop
Syntactic Accuracy Pass Pass
Semantic Accuracy Pass Pass
Completeness 19 errors Pass
Timeliness Pass Pass
Uniqueness/Conciseness Pass Pass
Security Validation
75
5 Security Validation
This chapter provides the test cases of oneM2M and LoRAWAN security components of Wise-IoT. To
achieve the validation, individual components should validate and pass the test cases for each scenario.
5.1 oneM2M Security Component
In this subsection, four test cases (i.e., request an access token, access a protected resource without a
token, access a protected resource with an invalid token, access a protected resource with a valid token)
are presented for validation of oneM2M security component. Note that Resource Owner Password
Credentials grant type is used when access token is requested.
5.1.1 Request an Access Token
Purpose To test a request for creating an access token.
Entry Criteria 1. Required credentials (i.e., Client ID and Client Secret) are already created in oneM2M.
2. Client is capable of sending HTTP request. 3. Client sends POST request to token endpoint of oneM2M security
component with the credentials.
Test Procedure 1. oneM2M security component validates the credentials. 2. oneM2M security component issues an access token.
Exit Criteria oneM2M security component successfully issues the access token.
5.1.2 Access a Protected Resource without an Access Token
Purpose To test whether access to protected resource is properly blocked.
Entry Criteria 1. Client is capable of sending HTTP request. 2. Resources of oneM2M are already protected by oneM2M security
component. 3. Client sends a request to protected oneM2M resource without any
access token.
Test Procedure 1. oneM2M security component checks whether an access token is in the request.
2. Error code 400 (“invalid_request”) is occurred by the oneM2M security component.
Exit Criteria Error code and description are successfully sent to the client.
5.1.3 Access a Protected Resource with an Invalid Access Token
Purpose To test whether oneM2M security component checks the validation of an access token.
Entry Criteria 1. Client is capable of sending HTTP request. 2. Resources of oneM2M are already protected by oneM2M security
component. 3. Client has an invalid access token. 4. Client sends a request to protected oneM2M resource with an invalid
access token.
Security Validation
76
Test Procedure 1. oneM2M security component validates the access token. 2. Error code 401 (“invalid_token”) is occurred by the oneM2M security
component.
Exit Criteria Error code and description are successfully sent to the client.
5.1.4 Access a protected resource with an Valid Access Token
Purpose To test access to protected resource is possible with an valid access token.
Entry Criteria 1. Client is capable of sending HTTP request. 2. Resources of oneM2M are already protected by oneM2M security
component. 3. Client has a valid access token. 4. Client sends a request to protected oneM2M resource with a valid access
token.
Test Procedure 1. oneM2M security component validates the access token. 2. If the access token is valid, oneM2M sends the resource that client wants.
Exit Criteria Client receives the resource successfully.
5.2 LoRaWAN Security Component
In this subsection, two test cases illusterating how attack scenario over the LoRa network can be defined
for the validation of a LoRaWAN security component. Their implementation however requires the
deployment of a specific LoRaWAN network with development of gateway and device test interfaces
which have been considered our of the scope of the project.
5.2.1 Bit Flipping after Network Server Checked Message Integrity
Purpose To flip a bit after the message integrity has been checked.
Entry Criteria 1. Requires a LoRaWAN device. 2. Requires a LoRaWAN Gateway. 3. Requires a LoRaWAN Network Server. 4. Requires a LoRaWAN Application Server. 5. Can intercept and modify messages between Network Server and
Application Server.
Test Procedure 1. Start the LoRaWAN system. 2. Start intercepting the messages. 3. Trigger the sending of one message by the LoRaWAN device. 4. Intercept message after Network Server integrity check. 5. Flip a bit. 6. Send the modified message to the application server.
Exit Criteria 1. Check whether the application server treated the corrupted message as a correct message.
5.2.2 Usurping Gateway Identity
Purpose To usurpe the gateway identifier so that the server would communicate with another.
Security Validation
77
Entry Criteria 1. Requires a LoRaWAN device. 2. Requires a LoRaWAN Gateway and access to its identifier. 3. Requires a LoRaWAN Malicious Gateway. 4. Requires a LoRaWAN Server.
Test Procedure 1. Start the LoRaWAN system. 2. Extract the gateway identifier. 3. Identify the malicious Gateway to the LoRaWAN server. 4. Trigger the sending of one message by the LoRaWAN Server to the
device.
Exit Criteria 1. Check whether the LoRaWAN correct gateway did not receive the message.
2. Check whether the LoRaWAN malicious gateway received the message.
5.3 OpenAM Security Component
In this subsection, ten test cases are presented for the validation of a OpenAM security component.
5.3.1 Request an Access Token
Purpose To test a request for creating an access token.
Entry Criteria Required credentials (i.e., Client ID and Client Secret) are already created in OpenAM. Client is capable of sending HTTP request. Client sends POST request to token endpoint of OpenAM security component with the credentials.
Test Procedure OpenAM security component validates the credentials. OpenAM security component issues an access token.
Exit Criteria OpenAM security component successfully issues the access token.
5.3.2 DataStore (pass)
Purpose Basic username and password authentication against the OpenAM data store
Entry Criteria OpenAM server is running. Client is capable of sending HTTP request. Client sends POST request to token endpoint of OpenAM security component with the credentials.
Test Procedure OpenAM security component validates the credentials.
Exit Criteria The username and password is correct.
5.3.3 DataStore (fail)
Purpose Basic username and password authentication against the OpenAM data store
Entry Criteria OpenAM server is running. Client is capable of sending HTTP request. Client sends POST request to token endpoint of OpenAM security component with the credentials.
Security Validation
78
Test Procedure OpenAM security component validates the credentials.
Exit Criteria The user hasn’t even got their username and password right. We definitely are not letting them in, and as such exit the chain with a FAIL.
5.3.4 DeviceMatch
Purpose Basic username and password authentication against the OpenAM data store
Entry Criteria OpenAM server is running. Client is capable of sending HTTP request. Client sends POST request to token endpoint of OpenAM security component with the right credentials.
Test Procedure First step of device match authentication
Exit Criteria The user has authenticated with username and password from a recognised device.
5.3.5 DeviceMatch (fail)
Purpose Basic username and password authentication against the OpenAM data store
Entry Criteria OpenAM server is running. Client is capable of sending HTTP request. Client sends POST request to token endpoint of OpenAM security component with the right credentials.
Test Procedure First step of device match authentication
Exit Criteria The user cannot authenticated with username and password from a recognised device.
5.3.6 TwoFactor (Fail)
Purpose Challenge the user to provide the code from a two factor mobile soft token. This second factor proves that not only does the user have the right username and password, but also that they have the mobile device they originally registered with in their possession.
Entry Criteria OpenAM server is running. Client is capable of sending HTTP request. Client sends POST request to token endpoint of OpenAM security component with the right credentials.
Test Procedure OpenAM security component validates the user device.
Exit Criteria The user has failed 2FA. At this point we don’t have the confidence this is really the user being claimed and exit with a FAIL.
5.3.7 TwoFactor (Pass)
Purpose Challenge the user to provide the code from a two factor mobile soft token. This second factor proves that not only does the user have the right username and
Security Validation
79
password, but also that they have the mobile device they originally registered with in their possession.
Entry Criteria OpenAM server is running. Client is capable of sending HTTP request. Client sends POST request to token endpoint of OpenAM security component with the right credentials.
Test Procedure OpenAM security component validates the user device.
Exit Criteria The user has authenticated with username and password from a recognised device.
5.3.8 DeviceSave (fail)
Purpose We save a record of the device so we can match it next time in the DeviceMatch step
Entry Criteria OpenAM server is running. Client is capable of sending HTTP request. Client sends POST request to token endpoint of OpenAM security component with the right credentials. Device match authentication
Test Procedure OpenAM security component validates the user device.
Exit Criteria The user is not actually being challenge for anything. Authentication is complete. We just need to save the device which will not fail
5.3.9 DeviceSave (pass)
Purpose We save a record of the device so we can match it next time in the DeviceMatch step
Entry Criteria OpenAM server is running. Client is capable of sending HTTP request. Client sends POST request to token endpoint of OpenAM security component with the right credentials. Device match authentication
Test Procedure OpenAM security component validates the user device.
Exit Criteria Authentication is failed.
5.4 OpenIG Security Component
In this subsection, five test cases are presented for the validation of a openIG security component.
5.4.1 Route
Purpose Check if the requested route is declared in OpenIG routes.
Entry Criteria OpenIG server is running. Client is capable of sending HTTP request.
Test Procedure OpenIG security component checks the routes repository.
Security Validation
80
Exit Criteria Route found
5.4.2 Route (fail)
Purpose Check if the requested route is not declared in OpenIG routes.
Entry Criteria OpenIG server is running. Client is capable of sending HTTP request.
Test Procedure OpenIG security component checks the routes repository.
Exit Criteria Route not found
5.4.3 Header
Purpose Check if the header cointains OpenIG instances
Entry Criteria OpenIG server is running. Client is capable of sending HTTP request.
Test Procedure OpenIG security component checks the header.
Exit Criteria Route found or complete.
5.4.4 Header (fail)
Purpose Check if the header doesn’t cointain OpenIG instances
Entry Criteria OpenIG server is running. Client is capable of sending HTTP request.
Test Procedure OpenIG security component checks the header.
Exit Criteria Route not found or incomplete.
5.4.5 Insecure Direct Object References
Purpose Check if an attacker can bypass authorization and access resources in the system directly, for example database records or files.
Entry Criteria OpenIG server is running. Client is capable of sending HTTP request.
Test Procedure Modify the value of the parameter used to reference objects and assess whether it is possible to retrieve objects belonging to other users or otherwise bypass authorization.
Exit Criteria The user is autorized to access the resource.
5.4.6 Insecure Direct Object References (fail)
Purpose Check if an attacker can bypass authorization and access resources in the system directly.
Entry Criteria OpenIG server is running. Client is capable of sending HTTP request.
Security Validation
81
Test Procedure Modify the value of the parameter used to reference objects and assess whether it is possible to retrieve objects belonging to other users or otherwise bypass authorization.
Exit Criteria The user is not autorized to access the resource.
5.4.7 Privilege Escalation
Purpose Check if an attacker can modify his or her privileges or roles inside the application in ways that could allow privilege escalation attacks.
Entry Criteria OpenIG server is running. Client is capable of sending HTTP request.
Test Procedure Access (drop users messages, statement of account ..) functionalities as another user in order to verify if it is possible to access a function that should not be permitted by the user's role/privilege (but might be permitted as another user).
Exit Criteria The user is autorized to access the functionality.
5.4.8 Privilege Escalation (fail)
Purpose Check if an attacker can modify his or her privileges or roles inside the application in ways that could allow privilege escalation attacks.
Entry Criteria OpenIG server is running. Client is capable of sending HTTP request.
Test Procedure Access (drop users messages, statement of account ..) functionalities as another user in order to verify if it is possible to access a function that should not be permitted by the user's role/privilege (but might be permitted as another user).
Exit Criteria The user is not autorized to access the functionality.
5.4.9 Bypassing authorization schema
Purpose Check if an attacker can access the application as an administrative user and track all the administrative functions..
Entry Criteria OpenIG server is running. Client is capable of sending HTTP request.
Test Procedure analyze an application that uses a shared directory to store a file for different users. Suppose that files should be accessible only by the user test1 with roleA. Verify if user test2 with roleB can access that resource.
Exit Criteria The user is autorized to access as an admin.
5.4.10 Bypassing authorization schema (fail)
Purpose Check if an attacker can access the application as an administrative user and track all the administrative functions..
Entry Criteria OpenIG server is running. Client is capable of sending HTTP request.
Security Validation
82
Test Procedure analyze an application that uses a shared directory to store a file for different users. Suppose that files should be accessible only by the user test1 with roleA. Verify if user test2 with roleB can access that resource.
Exit Criteria The user is not autorized to access as an admin.
5.5 Fiware security testing
In this subsection, four test cases are presented for validation of Fiware security component. Note that
Resource Owner Password Credentials grant type is used when access token is requested.
5.5.1 Security Group creation
Purpose Create a Security Group
Entry Criteria A registered user in OpenStack environment
Test Procedure The user requests creation of a Security Group with name “SGtest”.
Exit Criteria OpenStack creates the corresponding Security Group with the name “SGtest”.
5.5.2 Security Group creation (fail)
Purpose The user cannot create a Security Group
Entry Criteria A registered user in OpenStack environment
Test Procedure The user requests creation of a Security Group with name “SGtest”.
Exit Criteria Then OpenStack creates the corresponding Security Group with the name “SGtest”.
5.5.3 Security Group Rules creation for a Security Group
Purpose Create a Security Group Rules for a Security Group
Entry Criteria A registered user in OpenStack environment A Security Group previously created with name “SGtest”.
Test Procedure The user requests creation of a Security Group with name “SGtest”.
Exit Criteria OpenStack creates the corresponding Security Group with the name “SGtest”.
5.5.4 Security Group Rules creation for a Security Group (fail)
Purpose The user cannot create a Security Group Rules for a Security Group
Entry Criteria A registered user in OpenStack environment A Security Group previously created with name “SGtest”.
Test Procedure The user requests creation of a Security Group with name “SGtest”.
Exit Criteria OpenStack cannot create the corresponding Security Group with the name “SGtest”.
Security Validation
83
5.6 Security validation table
Table 5 summarizes the validation of security components.
Table 5. Summary of security validation tests
Nb Resource/Procedure Description Validation
1 OpenAM Request an Access Token Validated
DataStore (fail) Validated
2 DataStore Validated
3 DeviceMatch Validated
4 DeviceMatch Validated
5 TwoFactor Validated
6 TwoFactor (fail) Validated
7 DeviceSave Validated
8 DeviceSave(fail) Validated
9 OpenIG Route Validated
10 Header Validated
11 Insecure Direct Object References
Validated
12 Privilege Escalation Validated
13 Bypassing authorization schema
Validated
14 Route (fail) Validated
15 Header (fail) Validated
16 Insecure Direct Object References (fail)
Validated
17 Privilege Escalation (fail) Validated
18
oneM2M
Bypassing authorization schema (fail)
Validated
19 Access a Protected Resource without an Access Token
Validated
20 Request an Access Token Validated
21 Access a Protected Resource with an Invalid Access Token
Validated
22 Access a Protected Resource with an Invalid Access Token
Validated
23 Access a protected resource with an Valid Access Token
Validated
24 Access a Protected Resource with an Access Token
Validated
Security Validation
84
25 LoRaWAN Security Bit Flipping after Network Server Checked Message Integrity
Not tested
26 Usurping Gateway Identity
Not tested
27 Fiware Security Group creation Validated
28 Security Group creation (fail)
Validated
29 Security Group Rules creation for a Security Group
Validated
30 Security Group Rules creation for a Security Group (fail)
Validated
Conclusion
85
6 Conclusion
This deliverable presented the interoperability tests from four perspectives: cross-domain testing and
validation, technical interoperability validation, data and semantic interoperability validation, and
security validation.
The cross-domain testing and validation focuses on the technical validation of the service roaming and
cross-domain data reuse use case that is based on FIWARE/NGSI federation approach. Due to the current
incompatibilities of different NGSI flavors (e.g., the IoT Broker implements FIWARE NGSIv1 while the
Orion Context Broker implements FIWARE NGSIv2), this deliverable presented a technical validation of
federation rather than using it in the real world deployments. It provided an architectural overview
depicting the core aspects of service roaming and cross-domain data reuse use case, as well as the
required steps needed for the federation validation together with examples of requests that are sent in
the respective steps and their responses.
The technical interoperability validation introduced a testing framework for all the components in Wise-
IoT architecture. It presented a general architecture for interoperability testing highlighting the core
components. Subsequently, it presented all the test cases in detail to validate the interoperability
between all IoT platforms/protocols used in the Wise-IoT project. In order to validate the
interoperability, all the components should pass the test cases, according to the source and destination
platform.
The data and semantic ontology validation described an overview of semantic ontology validator and
then performed the semantic ontology validation of Wise-IoT use cases ontologies (e.g., smart parking,
smart skiing, crowd modelling and bus information system). After performing semantic ontology
validation, some errors are identified which were notified to the ontology designers who correct those
errors. After correction, another round of semantic ontology validation was performed over modified
ontologies to verify the correctness of ontologies. Their results are presented in Section 4.
Finally, the test cases of oneM2M and LoRaWAN security components of Wise-IoT are presented. Each
component provided a number of test cases required for testing and validating the security. The
individual components should validate and pass the test cases for each scenario in order to achieve the
validation.
References
86
7 References
[1] "FIESTA-IoT," [Online]. Available: http://fiesta-iot.eu/.
[2] "Wise-IoT D1.2 - Wise-IoT High-level Architecture, Reference Technologies and Standards,"
http://wise-iot.eu/wp-content/uploads/2017/06/D1.2-Wise-IoT-Architecture-PU-V1.0.pdf, 2017.
[3] "Wise-IoT D2.7 - Final System," 2018.
[4] "Wise-IoT D3.1 - Integrated IoT platforms – Release 1," http://wise-iot.eu/wp-
content/uploads/2017/06/D3.1-Integrated-IoT-platforms-R1-1.0-Final.pdf, 2017.
[5] "Fluent Editor," Cognitum Artificial Intelligence, [Online]. Available:
http://www.cognitum.eu/Semantics/FluentEditor/. [Accessed May 2018].
[6] "Protégé," May 2018. [Online]. Available: https://protege.stanford.edu/.
[7] C. Ghidini, M. Rospocher and L. Serafini, "Moki: A Wiki-based Conceptual Modeling Tool," in ISWC
2010 Posters & Demonstrations Track: Collected Abstracts, 2010.
[8] "Eyeball," Apache Jena, [Online]. Available: https://jena.apache.org/documentation/tools/eyeball-
getting-started.html.
[9] "Wise-IoT D2.6 - Self-Adaptive Recommendation System," 2017, http://wise-iot.eu/wp-
content/uploads/2017/08/D2.6-Self-Adaptive-Recommendation-System-V1.02.pdf.