IOT
INTEROPERABILITY
O
Franck Le Gall – inno
Alexandre Berge - easyGlobalMarket
PROBE-IT identity card
FP7 project: FP7‐ICT‐2011‐7
C 20
Start Date: 01/10/2011
Budget (EC contribution):
Budget (EC contribution): 1,131 k€
Duration:
24 months
Active in international level with involvment from Brazil, China and Africa
2
Enabling IoT deployments
Time to capitalize on European research
advances for IoT deployments: needs to
ensure interoperability and acceptance of its
solutions in a global context
International cooperation:
p
Ensure worldwide acceptance of solutions
Avoid unnecessary competitions and overlaps
Value chain stakeholders cooperation
Support to validation and benchmarking of
solutions, concepts, and emerging standards
3
General approach of PROBE-IT
Expected outcomes
Three main outcomes:
benchmarking of IoT deployments
provide stakeholders with decision tools
Enable identifying the best options when deploying
g IoT;;
or using
guidelines for stakeholders
Enable to plan IoT roll-out;
testing roadmap and solutions
provide
id stakeholders
t k h ld
with
ith elements
l
t tto validate
lid t
technologies conformance and interoperability.
TESTING & INTEROP
INCLUDING COAP CASE &
DEMO
OBSERVING – DOING – SUGGESTING
What will we do ?
D3.1
Technology Roadmaps consolidation
D3.3
4+ interoperability test events
Workshops
Interactions IERC
SUPPORT
NEEDS FEEDBACK
D4 2
D4.2
D4.1
Observation
analysis
Framework for IoT Testing analysis
Requirements for IoT testing
for IoT
M12
D4.3
Conclusions recommandations
M24
Roadmap for interoperability testing research
Observing: Interoperability
Sources of efforts – sources of problems
Idea
Product/service
How to specify ? To validate?
How to specify ? To validate?
Possible
automation
How to develop
test tools? Possible
automation
Areas to influence Interoperability
How to do the final check ?
Application
Modelling
Overview technical and regulatory communication standards for M2M in Smart Grid/Smart Metering (Source SMCG)
Object models
60870‐6
IEC 61968 CIM
C12.22 / C12.19
IEC 62056‐62 / IEC 62056‐61 / EN 13757‐1
COSEM metering object model, OBIS
Object models
61850‐6
ETSI M2M Service capability
Application
Layer
WEB services
IEEE 1588
SNMP, DNS
DHCP, SSH
DNP
MODBUS
Home automation
object model
IEC 62056‐53
COSEM application layer
HTTP / CoAp
OSGP
M‐Bus Ded.
Appli Layer
EN 13757‐3
PAL
Transport/
Network Layer
Wrapper TCP
TCP / UDP
Routing
Addressing, QOS, Security, Multicast IPv6 (RFC 2460) / IPv4 (RFC 791)
802.1x / EAP-TLS based Access Control Solution + 802.1AR / Other AAA / CENELEC AAA
Wireless MESH
Data Link Layer
PAL
IEEE
802 Family
Data Link
& PHY
Layer (s)
Physical
Layer
802.3
802.11
802.16
…
…
IEEE
ETSI
harmonized cellular standards Data
Link
Layer (s)
ETSI
harmonized cellular
Public Cellular
Broadband
(DSL, …)
PLC
Data
Link
Layer
Data
Link
Layer (s)
Wired
Wireless
PLC
Access Networks
M‐Bus
Optional
repeater
6LOWPAN (RFC6282)
ETSI TS
102 887‐2
FHSS
MAC
802.15.4/4e
/4e FHSS
/4e FHSS
MAC
802.15.4/4g
PHY
ETSI TS
102 887‐1
PHY
P1901.2
PHY
802 & Other
Data Links
PAL
PAL
IEC 62056‐31
Euridis Link+
EN 13757‐2
M‐Bus MAC
IEC 62056‐31
Euridis Phy
Euridis Phy
EN 13757‐2
M Bus Phy
M‐Bus Phy
New Protocols
PAL
EN 13757‐4
EN
13757‐4
Wireless
M‐Bus MAC
EN 13757‐4
Wireless
M‐Bus Phy
CEN/CENELEC
frequency access mechanisms based on regulation for wireless (physical layer standards, e.g. EN 300220, EN 300328,..)
IEEE/IETF
ETSI (HEN)
ETSI (e.g. Profile Standard)
CLC TC 13
CEN TC 294
CLC TC 205
802.1
5.4
802.15.4 MAC
6LOWPAN
D
PHY Data Link
Layer
Layer
IPv6
UDP
Layer
Transpo
rt/Netw
ork
Layer
CoAP
Applicati
ons
Layer
Various
Modeling
Applicati
onModeli
o
ng
Need for cost and time optimisation
Need global test framework and methodologies
Areas of optimization
Different ‘levels’ of Interoperability
Many definitions but
Interoperability is
generally defined as
"the ability of two or
more systems or
components to
exchange data and use
information"
PHYSICAL LAYERS TESTS FRAMEWORK
Various
Modeling
CoAP
IPv6
UDP
802.15.4 MAC
6LOWPAN
Layer
PROTOCOLS AND COMMUNICATION PROTOCOLS
AND COMMUNICATION
TESTS METHODOLOGIES
E.G. Interop
perability in
nitiatives
D
PHY Data Link
Layer
Layer
Transpo
rt/Netw
ork
Layer
Applicati
ons
Layer
SEMANTICS AND MODELING FRAMEWORK
802.1
5.4
Applicati
onModeli
o
ng
Likely areas of optimisation where
Common test framework can be developped
Doing: Organisation +4 interop
events…
t
First Probe-IT interop March 2012
IoT CoAP Plugtest
The event assessed for the first time the interoperability of different CoAP
interoperability of different CoAP
implementations for features including:
The base CoAP specification
CoAP Block Transfer
Block Transfer
CoAP Observation
The CoRE Link Format
Intended for M2M system vendors, operators, te ded o
syste e do s, ope ato s,
software vendors and research institutes.
First IoT semantic interop
DOING TOGETHER
Examples of interoperabilty initiatives
Withi the
Within
th project
j t timeframe
ti
f
: 4 events
t to
t organise
i
Oct 2011
Oct 2013
Applicati
onModeli
o
ng
semantics
SEMANTICS
Applicati
ons
Layer
Coap
Layer
Transpo
rt/Netw
ork
Layer
D
PHY Data Link
Layer
Layer
Oct 2012
PROTOCOLS AND COMMUNICATION AREA
Coap
6lowpan
6lowpan RFID NFC Zigbee Bluetooth LT ?
RFID, NFC, Zigbee, Bluetooth LT ? PHY LAYER
AREA
Suggesting :Arguments in favor of
well defined testing methodology
Some implementations may be considered conformant to
their specification but may not interoperate with other
implementations
¾
Contradiction with the final goal of networks
Some implementations may be considered not
conformant to their specification but may interoperate
with other implementations
¾
What the end-user needs is interoperability, but does he want a
product that doesn’t realize what it is design for?
We need both conformance and interoperability
17
Pillars of Interoperability
« Achieving
g interoperability
p
y is a keyy
requirement for any IoT technology to be
successfully deployed »
I t
Interoperable products
bl
d t
Consistent standards
Standardized Testing methodologies
th d l i
Well‐suited testing tools & accurate test suites
Arguments in favour of standardised
methodology and testing automation
Cost
reducing
Interoperable products
Time
Qualityy
Q
reducing
improving
CoAP conformance demonstrator
BUPT has produced a protoype CoAP
conformance test system
Aim: demonstrate that TTCN-3 is suitable
for validating CoAP implementation
Current status:
15 testcases for CoAP servers
C d
Codecs
i l
implemented
t d
Test Adapter for UDP/IP connectivity with SUT
Demonstration during workshop & Plugtests
The TTCN-3 based approach
Test System
Codeecs
Translate to/from abstract messages
abstract messages representation Templates & Matching mechanism,
Defaults,
Verdict management,
Parallel components, …
Focus on tested layer, protocol behaviour and message content
TTCN‐3 Abstract Test Suite
b
Implements connectivity to System Under Test
Test Adapter
CoAP demonstrator: test examples
Ensure that when IUT generates a CoAP message, it sends the packet
containing the Version field set to 1.
Ensure that when IUT receives a CON message and it can process it, the IUT
acknowledges this message with an acknowledgement containing the same
Message ID.
ID
Ensure that when IUT receives a NON message, it doesn't acknowledge this
message.
Ens re that when
Ensure
hen IUT receives
recei es the same CON message again then the IUT
sends ACK for this message.
Ensure that when IUT receives a GET request and IUT can process it, then
IUT sends
d a 2.05
2 05 content
t t response.
Ensure that when IUT receive the same NON messages the IUT silently ignore
each one of them.
Ensure that when IUT receives a GET request and IUT doesn’t have the
resource, then IUT sends a 4.04 not found response.
CoAP demonstrator: overview & demo
Test case:
// Ensure that when IUT receive a GET request and IUT can process it,
// then IUT sends a 2.05 content response.
testcase T02_RequestProcessing_V() runs on CoAPClient system CoAPServer {
// 1. Initialize test system (Map ports, …)
f_cfUp();
activate(a_default());
// 2. Send a request
ClientPort.send(GETRequest1);
(
q
);
Timer0.start(4.0);
// 3. Receive response and set verdict
alt{
[] ClientPort.receive(m_coapMessage(m_coapHeader_withCode(c_code205))) {
setverdict(pass);
}
[] ClientPort.receive(m_coapMessage(m_coapHeader_withCode(?))){
setverdict(fail);
}
}
}
Simple ?
Conclusion: needs to optimize?
Needs for companion
specifications/standards
Needs for methods in developing
p g test suites
Needs for horizontal approach in testing
interoperability methodologies
Needs for framework architectures
Needs for cost optimization likely through
automation
Needs for full-chain approach solutions
Interaction with IERC (AC4, SRA..)
Probe‐IT is actively contributing to IERC to research roadmaps (e.g. SRA) on testing, validation and interoperability issues in particular in delivering requirements on testing architecture and needs
Technology scope of IERC projects
Communications Interoperability
Data interoperability and semantics Special dimensions
IoT system and SW engineering
IoT living lab validation
Broad industry scope
Specific industry standards
Aerospace
Building management
Industrial and automation
Telco
Getting involved
www probe-it eu:
www.probe-it.eu:
Learn about Probe-IT
Follow progresses
Partnership
Soon a full section
dedicated to AC4 “IoT
interoperability”
interoperability
28
www.probe‐it.eu