Information technology - Sensor network testing framework

ISO/IEC 19637:2016 specifies:
- testing framework for conformance test for heterogeneous sensor networks,
- generic services between test manager (TMR) and test agent (TA) in the testing framework, and
- guidance for creating testing platform and enabling the test of different sensor network protocols.

General Information

Status
Published
Publication Date
04-Dec-2016
Current Stage
PPUB - Publication issued
Completion Date
05-Dec-2016
Ref Project

Buy Standard

Standard
ISO/IEC 19637:2016 - Information technology - Sensor network testing framework
English language
36 pages
sale 15% off
Preview
sale 15% off
Preview

Standards Content (sample)

INTERNATIONAL ISO/IEC
STANDARD 19637
First edition
2016-12-01
Information technology — Sensor
network testing framework
Technologies de l’information — Cadre général pour les essais de
réseaux de capteurs
Reference number
ISO/IEC 19637:2016(E)
ISO/IEC 2016
---------------------- Page: 1 ----------------------
ISO/IEC 19637:2016(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO/IEC 2016, Published in Switzerland

All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form

or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior

written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of

the requester.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO/IEC 2016 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/IEC 19637:2016(E)
Contents Page

Foreword ........................................................................................................................................................................................................................................iv

Introduction ..................................................................................................................................................................................................................................v

1 Scope ................................................................................................................................................................................................................................. 1

2 Normative references ...................................................................................................................................................................................... 1

3 Terms and definitions ..................................................................................................................................................................................... 1

4 Abbreviated terms .............................................................................................................................................................................................. 2

5 Overview of a sensor network testing framework (SNTF) ........................................................................................ 2

5.1 Testing requirements of sensor networks ...................................................................................................................... 2

5.2 Conceptual model of SNTF ............................................................................................................................................................ 3

5.3 Description of test manager (TMR) ...................................................................................................................................... 4

5.4 Description of test agent (TA) .................................................................................................................................................... 5

6 Testing services...................................................................................................................................................................................................... 5

6.1 General ........................................................................................................................................................................................................... 5

6.2 Module interactions through unified services ............................................................................................................. 7

6.3 Test data services (TDSs) ............................................................................................................................................................... 8

6.3.1 General...................................................................................................................................................................................... 8

6.3.2 EventReport service ...................................................................................................................................................... 9

6.3.3 EventAck service ...........................................................................................................................................................10

6.3.4 Read service ......................................................................................................................................................................11

6.3.5 Write service ....................................................................................................................................................................13

6.3.6 StartTest service ............................................................................................................................................................15

6.3.7 StopTest service .............................................................................................................................................................17

6.3.8 StartDownAndUploading service ...................................................................................................................18

6.3.9 StopDownAndUploading service ....................................................................................................................20

6.3.10 DataUploading service .............................................................................................................................................21

6.3.11 DataDownloading service .....................................................................................................................................23

6.3.12 ExecuteTesting service ............................................................................................................................................25

6.4 Testing management services .................................................................................................................................................27

6.4.1 Overview ..............................................................................................................................................................................27

6.4.2 Associate service ...........................................................................................................................................................27

6.4.3 Abort service ....................................................................................................................................................................29

6.4.4 AddressAllocation service ....................................................................................................................................30

6.4.5 Sync Service .................. .................................................... .................................................................................................32

6.4.6 DeviceStatus service ..................................................................................................................................................32

Annex A (informative) Example of the testing platform for hybrid sensor networks based

on IPv6 .........................................................................................................................................................................................................................34

Bibliography .............................................................................................................................................................................................................................36

© ISO/IEC 2016 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO/IEC 19637:2016(E)
Foreword

ISO (the International Organization for Standardization) and IEC (the International Electrotechnical

Commission) form the specialized system for worldwide standardization. National bodies that are

members of ISO or IEC participate in the development of International Standards through technical

committees established by the respective organization to deal with particular fields of technical

activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international

organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the

work. In the field of information technology, ISO and IEC have established a joint technical committee,

ISO/IEC JTC 1.

The procedures used to develop this document and those intended for its further maintenance are

described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the

different types of ISO documents should be noted. This document was drafted in accordance with the

editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).

Attention is drawn to the possibility that some of the elements of this document may be the subject of

patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of

any patent rights identified during the development of the document will be in the Introduction and/or

on the ISO list of patent declarations received (see www.iso.org/patents).

Any trade name used in this document is information given for the convenience of users and does not

constitute an endorsement.

For an explanation on the meaning of ISO specific terms and expressions related to conformity assessment,

as well as information about ISO’s adherence to the World Trade Organization (WTO) principles in the

Technical Barriers to Trade (TBT) see the following URL: www.iso.org/iso/foreword.html.

The committee responsible for this document is ISO/IEC JTC 1, Information technology.

iv © ISO/IEC 2016 – All rights reserved
---------------------- Page: 4 ----------------------
ISO/IEC 19637:2016(E)
Introduction

Sensor network is widely used around the world in multiple fields such as industrial automation,

environment monitoring, smart home, intelligent health-care and smart grid. The applications can

involve different devices supplied by different manufacturers, e.g. sensors, actuators, controllers,

routers and gateways, etc. Data can be collected and processed by use of different wired/wireless

communication technologies. Thus, various test systems should be employed to satisfy some specific

requirements. The operations of test systems is a challenge to users, if without a uniform test platform.

When designing and developing a sensor network test system, the characteristics regarding the

following aspects should be considered:

a) Sensor network heterogeneity. It is necessary to verify the interoperability of sensor networks

based on different protocols prior to system application;
b) Diversity of sensor network applications.

However, an international test standard for sensor networks which can provide guidance to design and

develop a uniform platform integrating different tests for sensor networks is still unavailable.

© ISO/IEC 2016 – All rights reserved v
---------------------- Page: 5 ----------------------
INTERNATIONAL STANDARD ISO/IEC 19637:2016(E)
Information technology — Sensor network testing
framework
1 Scope
This document specifies:
— testing framework for conformance test for heterogeneous sensor networks,

— generic services between test manager (TMR) and test agent (TA) in the testing framework, and

— guidance for creating testing platform and enabling the test of different sensor network protocols.

2 Normative references
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.

ISO and IEC maintain terminological databases for use in standardization at the following addresses:

— IEC Electropedia: available at http://www.electropedia.org/
— ISO Online browsing platform: available at http://www.iso.org/obp
3.1
analysis module

logical unit within a testing application process which is used to analyse the information from test

agent and module-based test depending on a particular strategy
3.2
test agent

device designed for different sensor network protocols or various kinds of hardware that can

communicate directly with the test manager and the systems under test
3.3
testing application process

software functional entity that performs the processing by combining test modules, analysis modules

and report modules to fulfil test purposes

Note 1 to entry: It is an application platform that supervises various operational aspects of testing activities and

entities, usually through interaction with test agents.
3.4
test module

logical unit within a testing application process that performs operations depending on a specified

testing requirements
3.5
testing platform

testing entity that could integrate different test systems for different protocols and technologies

EXAMPLE A platform can provide IPv4 and IPv6 conformance testing systems.
© ISO/IEC 2016 – All rights reserved 1
---------------------- Page: 6 ----------------------
ISO/IEC 19637:2016(E)
3.6
test report

logical unit of software within a testing application process that produces documents at the end of test

assessment
3.7
view object

logical element provided to support efficient access to data within a testing or analysis module

Note 1 to entry: It is visible on graphic user interfaces.
4 Abbreviated terms
TE auxiliary testing equipment
DUT device under test
ICS implementation conformance statement
IUT implementation under test
MIB management information base
OD object dictionary
SAPs service access points
SNTF sensor network testing framework
SUT system under test
TA test agent
TAP testing application process
TDSs testing data services
TM test module
TMR test manager
TMSs testing management services
TP test purpose
VO view object
5 Overview of a sensor network testing framework (SNTF)
5.1 Testing requirements of sensor networks

Varied with applications, sensor networks are likely employ different communication technologies and

protocols. To ensure their interconnection and operation, it is required to deploy a great number of

test systems, which are designed to test individual technologies and protocols with regard to protocol

conformance. Therefore, it is a challenging task to integrate the variety of the test systems for sensor

networks.

It is difficult to manage different test systems, make them work together and execute test cross various

technologies and protocols for specific user requirements. Various application systems need different

communication interfaces and protocols, which can’t interact directly with each other.

With changing testing requirements, test system for sensor networks should be scalable and adaptable

on demand. For example, when new sensor networks are added into the application, the corresponding

test systems should be integrated into the test platform with low costs.

Annex A describes an example of a testing platform for hybrid sensor networks based on IPv6.

2 © ISO/IEC 2016 – All rights reserved
---------------------- Page: 7 ----------------------
ISO/IEC 19637:2016(E)
5.2 Conceptual model of SNTF

Figure 1 shows the concept model of SNTF. The framework consists of three parts: test manager (TMR),

test agent (TA) and system under test (SUT). As an actual management controller, the TMR conducts

a test indirectly by controlling the TA. The test activities of the TMR should be converted into unified

services and transferred to the TA. After having processed the testing services from TMR, TA conducts

test interactions directly with SUT. Therefore, TA bridges TMR and SUT while TA needs to be equipped

with the specific physical communication interface and protocol stack as in SUT.

The SUT is a system that can include only one device under test (DUT), or a DUT and some other devices

used to activate the behaviours of the specific protocol residing in DUT, which is named auxiliary testing

equipment (ATE). DUT needs to be verified for having certain required protocol implementations. SUT

contains points of control and observation at the upper or lower service boundary of the protocol

implementations that resides in DUT to execute tests. The protocol implementations during testing

is called implementations under test (IUT). Before starting performing the conformance tests, IUT

should be configured by instructions from TMR. In a complicated environment, ATE can be used to

stimulate the DUTs to ensure TAs observe the expected responses from DUT if the IUT can’t activate

some particular behaviours of protocol by itself.
Figure 1 — Conceptual model of SNTF
© ISO/IEC 2016 – All rights reserved 3
---------------------- Page: 8 ----------------------
ISO/IEC 19637:2016(E)
5.3 Description of test manager (TMR)

The TMR can support several testing application processes (TAP). Each TAP has a specific test task to

be performed. For example, it can create an application process for conformance testing of a particular

protocol, and simultaneously another application process for a different protocol.

The testing application process is designed on a component basis. There are five types of components

in a TAP:
— view object,
— test report,
— test module,
— analysis module, and
— object dictionary (OD).
Figure 2 shows the relationship of the five components.

The test module (TM) is the performer of test cases. Before executing a test, TM should be parameterized

to configure the test type for a specific protocol. If the corresponding testing requirements and testing

suits are inputted into a TM, it is instantiated. After the TM is started, the steps defined by test cases is

executed.

The analysis module (AM) shall connect test modules to collect data to analysis test activities. It

is needed to configure the corresponding report format in the AM before producing test reports.

Moreover, AM can also collect the information of the operating conditions of the TM.

The view object (VO) has parameter sets from the TMs and AMs. VO can be selected for graphical user

interfaces, which allows monitoring the real-time throughput during a certain period. VOs also can be

grouped to monitor the parameters in the relevant TMs and AMs; its visual parameters can also be

derived from different TMs or AMs.

Management information base (MIB) stores all object values of test module, view object and test report

in TMR, including the management objects for TA. The values of the objects in testing application

process can be indexed quickly from object dictionary (OD).
Figure 2 — Relationship of components in TAP
4 © ISO/IEC 2016 – All rights reserved
---------------------- Page: 9 ----------------------
ISO/IEC 19637:2016(E)
5.4 Description of test agent (TA)

A test agent (TA) is designed for individual protocol, and it can support multiple implementations of

the same protocol. The TA handles any direct communications with the SUT with the same protocol

through the test driver. Platform independence can be achieved by the test driver. The configuration

parameters of test driver are defined in the TA description.

Before performing the corresponding test operations, TA shall establish communication connection

with TM in TMR when receiving the start command from a TM. TA receives services from TM and

translates them into the appropriate messages in conformance with the protocol of SUT. Structure

model of TA is shown in Figure 3.
Figure 3 — Structure of TA
6 Testing services
6.1 General

Testing services are conceptually divided into two classes: testing data services (TDSs) and testing

management services (TMSs) as shown in Figure 4. TMSs could be used to create application

communication relationships or set the parameters of TA via Management Entry-Service Access Points

(ME-SAPs). TDSs should be used to implement testing procedures between TMR and TA via Data Entry-

Service Access Points (DE-SAPs). TMR can transfer testing data to TA and control TA testing behaviours.

© ISO/IEC 2016 – All rights reserved 5
---------------------- Page: 10 ----------------------
ISO/IEC 19637:2016(E)
Figure 4 — Overview of test services for sensor networks
TDSs includes:

— EventReport service: This service is used to report one or more failures or exceptions from TAs.

The content of the report can be generated dependent on changes of the test condition. EventReport

service can be retried until an EventAck service for the EventReport received.

— EventAck service: EventAck is used to acknowledge an individual EventReport service has been

received. An EventAck should result in the ceasing of the EventReport retry requests for the

corresponding individual event.

— Read service: This service is used to read value of an object from TM in TMR or TA.

— Write service: This service is used to write value of an object from TM in TMR or TA.

— StartTest service: This service is used to start a test task between TM in TMA and TA. Test cases are

executed after this service is called.

— StopTest service: This service is used to stop a test task between TM in TMR and TA. All test activities

in test system is stopped after this service is called.

— DataUploading service: This service is used to transfer a block of data from TA to TM in TMA. It

supports fragmentation to transmit a large amount of data. The destination device can reassemble

the received messages.

— DataDownloading service: This service is the same way as the DataUploading service. The difference

is that TM sends a block of data to TA.

— StartDownAndUploading service: This service is used to begin downloading or uploading of data.

— StopDownAndUploading service: This service is used to end downloading or uploading of data.

— ExecuteTesting service: This service is used to execute a test case.
TMSs includes:

— Associate service: This service provides mechanisms to create a logical connection between TA and

TM in TMR. The connection is the prerequisite for the execution of the other services between TM

and TAs.

— Abort service: This service permits to release a logic connection between TM and TAs. Communication

activities including should be stopped until a new connection has been established.

— Sync service: The service enables setting of the time for a TA associated with a TM in TMR. This is

useful for time synchronization in a test system with time constraints.
6 © ISO/IEC 2016 – All rights reserved
---------------------- Page: 11 ----------------------
ISO/IEC 19637:2016(E)

— AddressAllocation service: This service provides functions to allocate addresses for TAs. TM can

allocate a unique identification for each TA through this service.

— DeviceStatus service: This service is used for a spontaneous transmission of device status.

6.2 Module interactions through unified services

Before testing the SUT, a TM in TMR should create a communication connection with TA and SUT.

As shown in Figure 5, the TM sends an associate request message to open a connection for a specific

protocol conformance testing. The messages between TM and TA should use the same protocol. Then,

TA loads a specific individual protocol and test driver for a specific protocol used in SUT. TA acts as a

protocol translator between TM and SUT. When TM intends to terminate the communication activities,

it should initiate an Abort service request to TA. If it receives an Abort response from TA, the connection

is released successfully.
Figure 5 — Sequence diagram of creating and releasing a connection

StartTest service is used to launch a test task after a connection is opened. TA and SUT should allocate

the testing resources and provide necessary testing configurations to prepare for testing activities. Test

cases in a test suit shall be performed when TA receives ExceuteTesting request. The test results are

transmitted to TM. If an analysis module (AM) is configured by the test application process to associate

a TA, it should also receive the test results for analysis. When a test task is completed, TM sends a

StopTest to end a task. A typed sequence diagram of the messages among modules is shown in Figure 6.

© ISO/IEC 2016 – All rights reserved 7
---------------------- Page: 12 ----------------------
ISO/IEC 19637:2016(E)
Figure 6 — Sequence diagram of performing test cases
6.3 Test data services (TDSs)
6.3.1 General

This subclause specifies test data services (TDSs) in a sensor networks testing platform. Service

primitives and parameters of primitives are defined for each test data service. The names of service

access points (SAPs) through which specific service is provided are given in Table 1.

Table 1 — Data services and the names of SAPs
Service name SAP name
EventReport EventReport-SAP
EventAck EventAck-SAP
Read Read-SAP
Write Write-SAP
StartTest Start-SAP
StopTest Stop-SAP
StartDownAndUploading StartDownAndUploading-SAP
StopDownAndUploading StopDownAndUploading-SAP
8 © ISO/IEC 2016 – All rights reserved
---------------------- Page: 13 ----------------------
ISO/IEC 19637:2016(E)
Table 1 (continued)
Service name SAP name
DataUploading DataUpLoading-SAP
DataDownloading DataDownLoading-SAP
ExecuteTesting ExecuteTesting-SAP
6.3.2 EventReport service

EventReport service is provided through EventReport-SAP. The EventReport-SAP is a logical interface

in the application that is issuing an EventReport. EventReport is an unconfirmed service. Table 2 lists

the primitives supported by the EventReport-SAP. Table 3 outlines the primitive parameters.

Table 2 — EventReport primitive summary
Name request indication response confirm
EventReport 6.3.2.1 6.3.2.2
Table 3 — EventReport primitive parameters
Parameter Name Description
SourceAddress The address from which the service request is sent.
DestinationAddress The address to which the service request is to be sent.
Communication mode.
Mode 0: broadcast;
1:client/server
ConnectID The unique identifier of the connection established.
It defines the message priority. Possible values: high, medi-
Priority
um or low.
EventID Unique identifier of the individual event.
It indicates if this is a communication failure, testing process
EventType
failure, device failure, module failure or a state change.
Timestamp It specifies the time at which the event was detected.
AssociatedObjectID Unique identifier of an object that generated an event.
Length The number of bytes of value.
Value The content of event
6.3.2.1 EventReport.request

This primitive requests the process of event report from the application layer. If the value of the

parameter Mode is broadcast, ConnectID should be set to 0; otherwise, it is the value of the identification

of communication connection established by source.
The parameters of this primitive are:
EventReport.request{
SourceAddress,
DestinationAddress,
Mode,
ConnectID
© ISO/IEC 2016 – All rights reserved 9
---------------------- Page: 14 ----------------------
ISO/IEC 19637:2016(E)
Priority,
EventID,
EventType,
Timestamp,
AssociatedObjectID,
Length.
Value
6.3.2.2 EventReport.indication

This primitive indicates the event report was received at the destination in the application process.

Upon receipt of this primitive, the receiver should issue EventAck request to the source. The parameters

of this primitive are:
EventReport.indication {
SourceAddress,
Mode,
ConnectID
EventID,
EventType,
Timestamp,
AssociatedObjectID,
Length.
Value
6.3.3 EventAck service

EventAck service is used to acknowledge an individual event. Table 4 lists the primitives supported by

the EventAck-SAP. Table 5 describes the primitive parameters.
Table 4 — EventAck primitive summary
Name request indication response confirm
EventAck 6.3.3.1 6.3.3.2
Table 5 — EventAck primitive parameters
Parameter Name Description
SourceAddress The address from which the service request is sent.
DestinationAddress The address to which the service request is to be sent.
Mode Communication mode.
ConnectID The unique identifier of the connection established.
10 © ISO/IEC 2016 – All rights reserved
---------------------- Page: 15 ----------------------
ISO/IEC 19637:2016(E)
Table 5 (continued)
Parameter Name Description
It defines the message priority. Possible values: high, medi-
Priority
um or low.
EventID Unique identifier of the individual event.
AssociatedObjectID Unique identifier of an object that generated an event.
Length The number of bytes of result.
Result The result after processing the event Report service.
6.3.3.1 EventAck.request

If a duplicate EventReport has been received, a duplicate EventAck should been sent. The parameter

ConnectID, EventID and AssociatedObjectID should be the same as the received EventReport service.

The parameters of this primitive are:
EventAck.request {
SourceAddress,
DestinationAddress,
Mode,
ConnectID
Priority,
EventID,
AssociatedObjectID,
Length,
Result
6.3.3.2 EventAck.indication

When the EventAck has been received, the status of event report is be cleared. The parameters of this

primitive are:
EventReport.indication{
EventID,
AssociatedObjectID,
Length.
Result
6.3.4 Read service

Read service supports client/server communication mode. It is usually used to get configuration of

Test Agent. Table 6 lists the primitives supported by the READ-SAP. Table 7 outlines the primitive

parameters.
© ISO/IEC 2016 – All rights reserved 11
---------------------- Page: 16 ----------------------
ISO/IEC 19637:2016(E)
Table 6 — Read primitive summa
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.