D3 - Wise-IoTwise-iot.eu/wp-content/uploads/2018/09/D3.3-Tests... · 4.4 Summary of Semantic Ontology Validation Results _ 73 5 Security Validation _ 75 5.1 oneM2M Security

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


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




Martin Bauer (NECLE)

Abdullah Aziz (SJU)




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


Abdullah Aziz (SJU)_



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.


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.


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.


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


17

http://localhost:8060/ngsi10/queryContext

HEADERS



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



BODY

'{

"entities": [{

"id": ".*",

"isPattern": true

}],

"restriction": {

"scopes": [{


"scopeValue": {




18

"radius": 10.0

}

}],


}

}'

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



BODY

'{

"entities": [{

"id": ".*",


19

"isPattern": true

}],

"restriction": {

"scopes": [{


"scopeValue": {



"radius": 3000

}

}],


}

}'

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"

}, {


20

"name": "Threshold",

"type": null,

"value": "300"

}, {

"name": "RemainderCount",

"type": null,

"value": "44"

}]

}, {

"name": "StayDurationAverage",

"type": "nle:StayDurationAverage",


"metadata": [{

"name": "Unit",

"type": null,

"value": "Seconds"

}, {


"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",


"metadata": [{


"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",


"metadata": [{

"name": "StartPointMoteMacAddress",

"type": null,

"value": "c0:25:e9:27:a0:84"

}, {

"name": "StartPointMoteEntityId",

"type": null,

"value": "sa-wfmote-1"

}, {



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",


"metadata": [{

"name": "StartPointMoteMacAddress",

"type": null,

"value": null

}, {

"name": "StartPointMoteEntityId",

"type": null,

"value": "alp-wfmote-2"

}, {


"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


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


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.


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


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.


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


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


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.


28


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


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.


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.


29


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.


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


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.


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


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.


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


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)


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.


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


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


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



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


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


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



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


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


37

3.4.2 Data Management and Repository (DMR)


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


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


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


38



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



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


39



Test objective Check that the IUT sends a ContentInstance creation request with optional attribute ATTRIBUTE_NAME


Config Id CF03




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


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


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



Initial conditions with { the IUT being registered containing

a RW attribute ATTRIBUTE_NAME }

Expected behaviour


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


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



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


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


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



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


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


43

3.4.3 Subscription and Notification (SUB)


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


Config Id CF03




the IUT being switched off and the IUT having privileges to perform CREATE operation on resource

AE_RESOURCE_ADDRESS }

Expected behaviour


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


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



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


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.


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


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.


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": "


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.


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’.


park:hasName

"parkingSpot1"^^http://www.w3.org/2001/XMLSchema#string’, the

predicate is not declared in any scheme ‘park:hasName’.


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’.


park:hasRefParkingSite http://www.semanticweb.org/wise-

iot/ontologies/2017/1/parkingOntology.owl#ketiLobbyPark’, the

predicate is not declared in any scheme ‘park:hasRefParkingSite’.


park:hasType

"ParkingSpot"^^http://www.w3.org/2001/XMLSchema#string’, the predicate

is not declared in any scheme ‘park:hasType’.


park:hasDateModified "2017-04-

18T02:23:30Z"^^http://www.w3.org/2001/XMLSchema#dateTimeStamp’,

the predicate is not declared in any scheme ‘park:hasDateModified’.


51

{

"verdict": "FAIL",

"details": {


"extention": "xml",



"start": "2018/02/09 11:04:27",

"results": [

{


"value": ""

},

{


"value": ""

},

{


"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



rdf:type park:ParkingSpot class not declared in any schema:

park:ParkingSpot



park:hasName

"parkingSpot1"^^http://www.w3.org/2001/XMLSchema#string

predicate not declared in any schema: park:hasName



park:hasId

"abcded"^^http://www.w3.org/2001/XMLSchema#string

predicate not declared in any schema: park:hasId


iot/ontologies/2017/1/parkingOntology.owl#ketiLobbyPark

rdf:type park:OnStreetParking class not declared in any

schema: park:OnStreetParking



park:hasRefParkingSite http://www.semanticweb.org/wise-

iot/ontologies/2017/1/parkingOntology.owl#ketiLobbyPark

predicate not declared in any schema:

park:hasRefParkingSite


52



park:hasType

"ParkingSpot"^^http://www.w3.org/2001/XMLSchema#string

predicate not declared in any schema: park:hasType



park:hasDateModified "2017-04-

18T02:23:30Z"^^http://www.w3.org/2001/XMLSchema#dateTimeS

tamp predicate not declared in any schema:

park:hasDateModified"

},

{


"value": ""

}

],


},


} 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.


• 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": {


"extention": "owl",



"start": "2018/02/09 10:11:51",

"results": [

{

"type": " Uniqueness", "value": ""


53

},

{


"value": ""

},

{


"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"

},

{


"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"

}

],


},


} 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:


iot/ontologies/2017/2/crowdmodelling#" on prefix: "" on

prefix: "nle""


• 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.


54

{

"verdict": "FAIL",

"details": {


"extention": "owl",



"start": "2018/02/09 10:30:52",

"results": [

{


"value":

"eye:multiplePrefixesForNamespace:


iot/ontologies/2017/2/crowdmodelling#" on prefix: ""

on prefix: "nle""

},

{


"value": ""

},

{


"value": ""

},

{


"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."

}

],


},


} 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.



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’.


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’.


smartBus:hasShortID

"11161"^^http://www.w3.org/2001/XMLSchema#string’, the predicate is not

declared in any scheme ‘smartBus:hasShortID’.


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’.



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’.



smartBus:hasBusStopCount


56

"[1,2]"^^http://www.w3.org/2001/XMLSchema#string’, the predicate is not

declared in any scheme ‘smartBus:hasBusStopCount’.


iot/ontologies/2017/1/smartBus.owl#bussanBusInfo rdf:type

smartBus:busStop’, the class is not declared in any scheme ‘smartBus:busStop’.



smartBus:hasDateModified "2017-04-


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’.


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’.



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": {


"extention": "xml",



"start": "2018/03/14 21:03:47",

"results": [

{


"value": ""

},


57

{


"value": ""

},

{


"value": "




"["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




"["urn:entity:busan:transport:bus:bus:[busId]"]"^^http://

www.w3.org/2001/XMLSchema#string predicate not declared in

any schema: smartBus:hasRefBuses



smartBus:hasShortID

"11161"^^http://www.w3.org/2001/XMLSchema#string

predicate not declared in any schema: smartBus:hasShortID



smartBus:hasAddress _:b1002 predicate not declared in any

schema: smartBus:hasAddress



smartBus:hasLocation _:b1001 predicate not declared in any

schema: smartBus:hasLocation




"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


58

On statement: _:b1002 smartBus:hasAddressLocality "Denver"


smartBus:hasAddressLocality




"[1,2]"^^http://www.w3.org/2001/XMLSchema#string





smartBus:busStop class not declared in any schema:

smartBus:busStop






smartBus:hasDateModified

On statement: _:b1002 smartBus:hasStreetAddress "7 S.

Broadway" predicate not declared in any schema:

smartBus:hasStreetAddress

On statement: _:b1001 smartBus:hasLongitude



smartBus:hasLongitude

On statement: _:b1002 smartBus:hasPostalCode "80209"


smartBus:hasPostalCode



smartBus:hasId

"urn:entity:busan:transport:bus:busId:[busStopId]"^^http:

//www.w3.org/2001/XMLSchema#string predicate not declared

in any schema: smartBus:hasId




hall"^^http://www.w3.org/2001/XMLSchema#string predicate

not declared in any schema: smartBus:hasName

On statement: _:b1002 smartBus:hasAddressRegion "CO"


smartBus:hasAddressRegion

"

},

{


59


"value": ""

}

],


},


} 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.




smartBus:hasName "PENACASTILLO \u0080\u0093 PLAZA DE

ITALIA"^^http://www.w3.org/2001/XMLSchema#string’, the predicate is not




smartBus:hasIntervalNorm

"P3Y6M4DT12H30M5S"^^http://www.w3.org/2001/XMLSchema#duration’,

the predicate is not declared in any scheme ‘smartBus:hasIntervalNorm’.



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’.



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’.



smartBus:hasRefBusStops



scheme ‘smartBus:hasRefBusStops’.



smartBus:hasStartTime "2017-02-05T08:15:30-


60

05:09"^^http://www.w3.org/2001/XMLSchema#dateTime’, the predicate is not

declared in any scheme ‘smartBus:hasStartTime’.



smartBus:hasIntervalHoli


the predicate is not declared in any scheme ‘smartBus:hasIntervalHoli’.








smartBus:hasLocalID


declared in any scheme ‘smartBus:hasLocalID’.



smartBus:hasIntervalPeak


the predicate is not declared in any scheme ‘smartBus:hasIntervalPeak’.



smartBus:hasShortID





smartBus:busLine’, the class is not declared in any scheme ‘smartBus:busLine’.



smartBus:hasRefEndBusStop



scheme ‘smartBus:hasRefEndBusStop’.



"urn:entity:busan:transport:bus:busId:[busLineId]"^^http://www.



{


61

"verdict": "FAIL",

"details": {


"extention": "xml",



"start": "2018/03/14 21:02:05",

"results": [

{


"value": ""

},

{


"value": ""

},

{


"value": "



smartBus:hasName "PENACASTILLO \u0080\u0093 PLAZA DE

ITALIA"^^http://www.w3.org/2001/XMLSchema#string

predicate not declared in any schema: smartBus:hasName




"P3Y6M4DT12H30M5S"^^http://www.w3.org/2001/XMLSchema#dura

tion predicate not declared in any schema:




smartBus:hasRefStartBusStop

"["urn:entity:busan:transport:bus:busStop:[busStopId]"]"^


declared in any schema: smartBus:hasRefStartBusStop



smartBus:hasEndTime "2017-02-05T08:15:30-

05:09"^^http://www.w3.org/2001/XMLSchema#dateTime

predicate not declared in any schema: smartBus:hasEndTime



smartBus:hasRefBusStops



declared in any schema: smartBus:hasRefBusStops




62

smartBus:hasStartTime "2017-02-05T08:15:30-

05:09"^^http://www.w3.org/2001/XMLSchema#dateTime


smartBus:hasStartTime















smartBus:hasLocalID


predicate not declared in any schema: smartBus:hasLocalID









smartBus:hasShortID





smartBus:busLine class not declared in any schema:

smartBus:busLine



smartBus:hasRefEndBusStop



declared in any schema: smartBus:hasRefEndBusStop



smartBus:hasId

"urn:entity:busan:transport:bus:busId:[busLineId]"^^http:


in any schema: smartBus:hasId"


63

},

{


"value": ""

}

],


},


} 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.





"["urn:entity:busan:transport:bus:busStop:[busLineId]"]"^^http:


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’.




"["urn:entity:busan:transport:bus:bus:[busId]"]"^^http://www.w3

.org/2001/XMLSchema#string’, the predicate is not declared in any scheme

‘smartBus:hasRefBuses’.



smartBus:hasShortID





smartBus:hasAddress _:b1002’, the predicate is not declared in any scheme

‘smartBus:hasAddress’.



smartBus:hasLocation _:b1001’, the predicate is not declared in any scheme

‘smartBus:hasLocation’.


64




"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’.




"[1,2]"^^http://www.w3.org/2001/XMLSchema#string’, the predicate is not

declared in any scheme ‘smartBus:hasBusStopCount’.



smartBus:busStop’, the class is not declared in any scheme ‘smartBus:busStop’.






• 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’.



"urn:entity:busan:transport:bus:busId:[busStopId]"^^http://www.






hall"^^http://www.w3.org/2001/XMLSchema#string’, the predicate is not



65

• For statement ‘_:b1002 smartBus:hasAddressRegion "CO"’, the predicate is not

declared in any scheme ‘smartBus:hasAddressRegion’.


66

{

"verdict": "FAIL",

"details": {


"extention": "xml",



"start": "2018/03/14 21:03:47",

"results": [

{


"value": ""

},

{


"value": ""

},

{


"value": "




"["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


predicate not declared in any schema: smartBus:hasLatitude




"["urn:entity:busan:transport:bus:bus:[busId]"]"^^http:/

/www.w3.org/2001/XMLSchema#string predicate not declared

in any schema: smartBus:hasRefBuses



smartBus:hasShortID





smartBus:hasAddress _:b1002 predicate not declared in any

schema: smartBus:hasAddress



smartBus:hasLocation _:b1001 predicate not declared in any

schema: smartBus:hasLocation


67




"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"


smartBus:hasAddressLocality




"[1,2]"^^http://www.w3.org/2001/XMLSchema#string





smartBus:busStop class not declared in any schema:

smartBus:busStop







On statement: _:b1002 smartBus:hasStreetAddress "7 S.

Broadway" predicate not declared in any schema:

smartBus:hasStreetAddress

On statement: _:b1001 smartBus:hasLongitude



smartBus:hasLongitude

On statement: _:b1002 smartBus:hasPostalCode "80209"


smartBus:hasPostalCode



smartBus:hasId

"urn:entity:busan:transport:bus:busId:[busStopId]"^^http:


in any schema: smartBus:hasId


68




hall"^^http://www.w3.org/2001/XMLSchema#string predicate

not declared in any schema: smartBus:hasName

On statement: _:b1002 smartBus:hasAddressRegion "CO"


smartBus:hasAddressRegion"

},

{


"value": ""

}

],


},


} 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": {


"extention": "owl",



"start": "2018/04/10 18:08:52",

"results": [

{


"value": ""

},

{


"value": ""

},


69

{


"value": ""

},

{


"value": ""

}

],


},


} 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": {


"extention": "owl",



"start": "2018/04/10 18:14:03",

"results": [

{


"value": ""

},

{


"value": ""

},

{


"value": ""

},

{


"value": ""

}

],


},


} Figure 13. Second round of semantic validation report of semantic descriptor for parking spots ontology.


70

4.3.2 Smart Skiing

Figure 14 presents the second round of semantic validation report for smart skiing ontology. The


{

"verdict": "PASS",

"details": {


"extention": "owl",



"start": "2018/04/10 18:19:02",

"results": [

{


"value": ""

},

{


"value": ""

},

{


"value": ""

},

{


"value": ""

}

],


},


} 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


{

"verdict": "PASS",

"details": {


"extention": "owl",



"start": "2018/04/10 18:23:17",

"results": [

{


71


"value": ""

},

{


"value": ""

},

{


"value": ""

},

{


"value": ""

}

],


},


} 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": {


"extention": "owl",



"start": "2018/05/14 17:51:47",

"results": [

{


},

{

"type": " Timeliness", "value": ""

},

{

"type": " Completeness", "value": ""

},


72

{

"type": " Semantic Accuracy", "value": ""

}

],


},


} Figure 16. Second round of semantic validation report of bus estimation ontology

{

"verdict": "PASS",

"details": {


"extention": "owl",



"start": "2018/05/14 17:41:50",

"results": [

{


},

{


},

{


},

{


}

],


},


} Figure 17. Second round of semantic validation report of bus line ontology

{

"verdict": "PASS",

"details": {


"extention": "owl",




73

"start": "2018/05/14 17:55:23",

"results": [

{


},

{


},

{


},

{


}

],


},


} 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


Semantic Accuracy Pass Pass



Uniqueness/Conciseness Pass Pass

Smart Skiing



Completeness 1 error Pass



Crowd Modelling Syntactic Accuracy Pass Pass


74


Completeness Pass Pass


Uniqueness/Conciseness 1 error Pass

Bus Estimation






Bus Line






Bus Stop






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.


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.


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)


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


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)



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.


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.



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


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


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.


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


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


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.


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.


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.


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.


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..


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..


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


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”.


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”.


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.

Documents

D3 - Wise-IoTwise-iot.eu/wp-content/uploads/2018/09/D3.3-Tests... · 4.4 Summary of Semantic Ontology Validation Results _____ 73 5 Security Validation _____ 75 5.1 oneM2M Security

D3 - Wise-IoTwise-iot.eu/wp-content/uploads/2018/09/D3.3-Tests... · 4.4 Summary of Semantic Ontology Validation Results _ 73 5 Security Validation _ 75 5.1 oneM2M Security