forked from w3c/wot-thing-description
-
Notifications
You must be signed in to change notification settings - Fork 0
/
report.html
7513 lines (7177 loc) · 361 KB
/
report.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!doctype html>
<html lang="en">
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8" />
<title>Web of Things (WoT) Thing Description: Implementation Report</title>
<link rel="stylesheet" type="text/css" href="https://www.w3.org/StyleSheets/general.css" />
<style type="text/css" xml:space="preserve">
/*<![CDATA[*/
body {
margin: 2rem;
}
code {
background-color: rgba(27, 31, 35, 0.05);
border-radius: 3px;
margin: 0;
padding: 0.2em 0.4em;
}
h2 {
font-size: 150%;
}
h3 {
font-size: 120%;
font-weight: bold;
}
h4 {
font-size: 110%;
font-weight: bold;
}
.tocline {
list-style: none;
}
table {
margin: auto;
width: 100%;
background-color: rgb(180, 180, 180);
border: black;
border-width: 1px;
}
th {
background-color: rgb(180, 255, 180);
}
th.rotate {
/* adjust as necessary... */
height: 180px;
white-space: nowrap;
}
th.rotate > div {
transform:
/* translate(25px, 51px)
rotate(315deg);
*/ rotate(90deg);
width: 30px;
}
th.rotate > div > span {
/* border-bottom: 1px solid #ccc;
*/
padding: 5px 10px;
}
td.baseassertion {
background-color: rgb(234, 255, 234);
}
td.tabassertion {
background-color: rgb(234, 255, 255);
}
td.defassertion {
background-color: rgb(255, 255, 234);
}
td.extraassertion {
background-color: rgb(200, 200, 255);
}
td.atrisk {
/* background-color: rgb(255,200,255) */
background-color: yellow;
}
td.result {
text-align: right;
padding: 2px 4px 2px 4px;
}
td.failed {
background-color: rgb(255, 200, 200);
}
td.passed {
background-color: rgb(128, 255, 128);
}
td.secure {
background-color: rgb(0, 255, 0);
}
td.missing {
background-color: rgb(255, 100, 100);
}
.comment {
color: green;
font-style: italic;
}
.remove {
text-decoration: line-through;
color: black;
}
.new {
color: red;
}
.working {
background-color: rgb(255, 234, 234);
padding: 0.2em;
}
.fill-in {
background-color: rgb(255, 234, 234);
}
table.testlist {
border: black;
border-width: 1px;
}
table.grammars th,
table.commands th,
able.attrs th,
table.testlist th {
background-color: rgb(180, 255, 180);
font-size: 10pt;
vertical-align: top;
}
table.grammars td,
table.commands td,
table.attrs td,
table.testlist td {
/* background-color: rgb(234,255,234); */
font-size: 10pt;
vertical-align: top;
}
table.attrs {
margin-top: 5px;
}
pre.example {
font-family: "Courier New", monospace;
white-space: pre;
background-color: rgb(204, 204, 255);
padding: 0.5em;
border: none;
border-width: 0;
margin-left: 0;
font-size: 100%;
width: 100%;
}
.testimonial {
font-style: italic;
margin: 0 2rem 0 2rem;
}
.at-risk {
background-color: yellow;
}
/*]]>*/
</style>
</head>
<body>
<div class="head">
<a href="http://www.w3.org/"><img src="https://www.w3.org/Icons/w3c_home" alt="W3C" width="72" height="48" /></a>
<h1 id="h_ir">
Web of Things (WoT) Thing Description:<br />
Implementation Report
</h1>
<p><b>Version</b>: 6 Dec 2019</p>
<p>
<b>Editors</b>:<br />
Michael McCool (Intel)<br />
Ege Korkan (Siemens / Technical University of Munich)
</p>
<p class="copyright">
<a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2019
<a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a
><sup>®</sup> (<a href="http://www.csail.mit.edu/"
><acronym title="Massachusetts Institute of Technology">MIT</acronym></a
>,
<a href="http://www.ercim.org/"
><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a
>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C
<a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
<a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and
<a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.
</p>
<hr title="Separator for header" />
</div>
<h2 id="h_toc"><a id="toc" name="toc">Table of Contents</a></h2>
<ul>
<li class="tocline">
1. <a href="#intro">Introduction</a>
<ul>
<li class="tocline">1.1 <a href="#objectives">Implementation Report objectives</a></li>
<li class="tocline">1.2 <a href="#non_objectives">Implementation Report non-objectives</a></li>
</ul>
</li>
<li class="tocline">2. <a href="#cr_work">Work during the Candidate Recommendation period</a></li>
<li class="tocline">3. <a href="#participate">Participating in the Implementation Report</a></li>
<li class="tocline">
4. <a href="#pr_entrance_crit">Entrance criteria for the Proposed Recommendation phase</a>
</li>
<li class="tocline">
5. <a href="#report_reqs">Implementation Report requirements</a>
<ul>
<li class="tocline">5.1 <a href="#DetailedReqs">Detailed requirements</a></li>
<li class="tocline">5.2 <a href="#NotesOnTesting">Notes on testing</a></li>
<li class="tocline">5.3 <a href="#out_of_scope">Out of scope</a></li>
</ul>
</li>
<li class="tocline">6. <a href="#test-systems">Systems</a></li>
<ul id="systems-toc">
<!--
<li class="tocline">6.x <a href="#impl-ORG">ORG</a></li>
-->
<li class="tocline">6.1 <a href="#impl-smartthings">SmartThings</a></li>
<li class="tocline">6.2 <a href="#impl-ercim">ERCIM</a></li>
<li class="tocline">6.3 <a href="#impl-fujitsu">Fujitsu Limited</a></li>
<li class="tocline">6.4 <a href="#impl-hitachi">Hitachi, Ltd.</a></li>
<li class="tocline">6.5 <a href="#impl-huawei">Huawei Technologies</a></li>
<li class="tocline">6.6 <a href="#impl-intel">Intel Corporation</a></li>
<li class="tocline">6.7 <a href="#impl-oracle">Oracle Corporation</a></li>
<li class="tocline">6.8 <a href="#impl-panasonic">Panasonic Corporation</a></li>
<li class="tocline">6.9 <a href="#impl-siemens">Siemens AG</a></li>
<li class="tocline">6.10 <a href="#impl-ORG">Technical University of Munich</a></li>
</ul>
<li class="tocline">7. <a href="#security">Security</a></li>
<li class="tocline">
8. <a href="#test_results">Test results</a>
<ul>
<li class="tocline">8.1 <a href="#automated_validation_results">Automated validation results</a></li>
<li class="tocline">8.2 <a href="#manual_validation_results">Manual validation results</a></li>
<!--
<li class="tocline">8.3 <a href="#test_interop">Interoperability results</a></li>
-->
</ul>
</li>
<li class="tocline">
<a href="#appendix">Appendix</a>
<ul>
<!--
<li class="tocline"><a href="#testspecB">Test specifications</a></li>
-->
<li class="tocline"><a href="#ack">Acknowledgements</a></li>
</ul>
</li>
</ul>
<h2 id="h_intro"><a id="intro" name="intro">1. Introduction</a></h2>
<p>
The <a href="http://www.w3.org/TR/wot-thing-description/">Web of Things (WoT) Thing Description</a> specification
entered the <a href="https://www.w3.org/TR/2019/CR-wot-thing-description-20190516/">Candidate Recommendation</a>
period for the second time on 6 November 2019.
</p>
<p>
The planned date for entering Proposed Recommendation is 10 December 2019. This document summarizes the results
from the Web of Things (WoT) TD implementer reports received and describes the process that the Web of Things
(WoT) Working Group followed in preparing this <em>Implementation Report (IR)</em>.
</p>
<h4 id="h_objectives"><a id="objectives" name="objectives">1.1 Implementation Report objectives</a></h4>
<ul>
<li>Must verify that the specification is implementable.</li>
</ul>
<h4 id="h_non_objectives">
<a id="non_objectives" name="non_objectives">1.2 Implementation Report non-objectives</a>
</h4>
<ul>
<li>The IR does not attempt full conformance testing of implementations.</li>
</ul>
<p>
Although results were generated with a combination of automated and manual tests, the automated tests were only
meant to provide assistance to implementers in preparing their individual implementation test reports.
</p>
<h2 id="h_cr_work"><a id="cr_work" name="cr_work">2. Work during the Candidate Recommendation period</a></h2>
<p>During the CR period, the Working Group carried out the following activities:</p>
<ol>
<li>Clarification and improvement through the exposition of the specification</li>
<li>
Disposing of comments that were communicated to the WG during the CR period. These comments and their resolution
are detailed in the
<a href="https://github.com/w3c/wot-thing-description/issues">GitHub Issue tracker</a>
with the label
<a href="https://github.com/w3c/wot-thing-description/issues?q=label%3A%22CR+period%22">CR period</a>.
</li>
<li>Preparation of this Implementation Report.</li>
</ol>
<h2 id="h_participate"><a id="participate" name="participate">3. Participating in the Implementation Report</a></h2>
<p>
Implementers were invited to contribute to the assessment of the
<a href="https://www.w3.org/TR/2019/CR-wot-thing-description-20190516/"
>Web of Things (WoT) Thing Description Candidate Recommendation</a
>
by submitting implementer reports describing the coverage of their implementations with respect to the test
assertions outlined in the <a href="#automated_validation_results">table below</a>.
</p>
<p>
Implementer reports were collected through the W3C WoT Interest Group's
<a href="https://www.w3.org/2016/07/wot-ig-charter.html#scope">PlugFest</a> activity and collected in the GitHub
repository
<a href="https://github.com/w3c/wot/tree/master/testing/tests/2019-05/">https://github.com/w3c/wot</a>
under <code>testing/tests/2019-05/</code>.
</p>
<p>
Comments on this document, or requests made for further information were posted to the Working Group's public
mailing list <a href="mailto:[email protected]">[email protected]</a> (<a
href="http://lists.w3.org/Archives/Public/public-wot-wg/"
>archive</a
>) and as issues on the GitHub repository
<a href="https://github.com/w3c/wot-thing-description/issues">https://github.com/w3c/wot-thing-description</a>.
</p>
<h2 id="h_pr_entrance_crit">
<a id="pr_entrance_crit" name="pr_entrance_crit">4. Entrance criteria for the Proposed Recommendation phase</a>
</h2>
<p>
The Web of Things (WoT) Working Group established the following entrance criteria for the Proposed Recommendation
phase in the Request for CR:
</p>
<ol>
<li>
Sufficient reports of implementation experience have been gathered to demonstrate that Things can be described
by Thing Descriptions in sufficient detail to allow interoperabilty.
</li>
<li>Specific Implementation Report requirements (<a href="#report_reqs">outlined below</a>) have been met.</li>
<li>
The Working Group has formally addressed and responded to all public comments received by the Working Group.
</li>
</ol>
<p>
All three of these criteria have been met.
<!--
Hard to count since some implementations have multiple components, and some are shared. Omit.
A total of N implementations were documented by M different organizations.
-->
The testimonials below indicate the broad base of support for the specification. All of the required features had
at least two implementations. All of the optional features also received at least one implementation. However,
these optional features do not have conformance requirements that have an impact on interoperability.
</p>
<h2 id="h_report_reqs"><a id="report_reqs" name="report_reqs">5. Implementation Report requirements</a></h2>
<h4 id="h_DetailedReqs"><a id="DetailedReqs" name="DetailedReqs">5.1 Detailed requirements</a></h4>
<ol>
<li>
Testimonials from implementers are included in the IR when provided to document the utility and implementability
of the specification.
</li>
<li>
IR must cover all specified features in the specification. For each feature the IR should indicate:
<ul>
<li>Feature status: required, optional, other.</li>
<li>Feature utility/usefulness based on feedback from implementers.</li>
<li>Implementability of the feature specification.</li>
</ul>
</li>
<li>
Feature status is a factor in test coverage in the report:
<ul>
<li>
Required specification features must have at least two implementations. Implementations that do not
implement a required specification feature must document the reason for not implementing the feature.
</li>
<li>
Optional specification features must have at least one implementation. Implementations that do not implement
an optional specification feature should document the reason for not implementing the feature.
</li>
</ul>
</li>
</ol>
<p>
Feature status is in practice indicated by
<a href="https://tools.ietf.org/html/rfc2119">RFC 2119</a> assertions associated with the feature. Features
defined using any assertions containing the words MUST are considered required. Features defined using MAY and
SHOULD assertions are considered optional.
</p>
<h4 id="h_NotesOnTesting"><a id="NotesOnTesting" name="NotesOnTesting">5.2 Notes on testing</a></h4>
<ol>
<li>
An implementer report must indicate the outcome of evaluating the implementation with respect to each of the
assertions defined in the specification. Possible outcomes are <code>pass</code>, <code>fail</code>, or
<code>not-impl</code> (not implemented).
</li>
</ol>
<h4 id="h_out_of_scope"><a id="out_of_scope" name="out_of_scope">5.3 Out of scope</a></h4>
<p>This implementation Report will not cover:</p>
<ul>
<li>Conformance testing results</li>
<li>Interoperability testing results</li>
<li>All possible combinations of metadata that TDs could describe</li>
</ul>
<h2 id="h_systems"><a id="test-systems" name="test-systems">6. Systems</a></h2>
<p>
This section contains descriptions of each of the implementations of the WoT Thing Description specification from
all organizations that submitted implementer reports. Each implementation represents a working system that either
exposes or consumes at least one WoT Thing Description. Implementations that expose a network interface described
by a Thing Description will be referred to as "servers". Implementations that consume Thing Descriptions
will be referred to as "clients". Note that these terms will be used with these specific definitions in
the following regardless of which device initiates network requests. Normally the client initiates requests and
the server responds. However, in some protocols or sub-protocols that support push notifications (such as webhooks
or MQTT) the usual relationship of initiator/responder may be reversed. In some cases a given implementation may
be used for multiple Things and a single Thing may also act as both client and server on multiple interfaces.
</p>
<p>
We only count systems with mostly independent code bases as distinct implementations. There are however some cases
(documented in the following) where implementations shared components but were still considered substantially
independent implementations. In cases where a substantial component was shared across implementations the features
supported by that component were only counted once.
</p>
<div id="systems-impl">
<!-- system implementation descriptions will be inserted here -->
<div class="impl" id="impl-smartthings">
<h3>SmartThings</h3>
<div class="testimonial">
<p>
Three implementations were created, all of which are TD Producers and demonstrate how existing ecosystems
can be supported.
</p>
</div>
<h4 id="impl-SmartThings-1">Implementation 1: TD Producer</h4>
<p>TD which exposes a dimmable light on the Philips Hue hub.</p>
<h4 id="impl-SmartThings-2">Implementation 2: TD Producer</h4>
<p>TD which exposes a dimmable, color control, light on the IKEA Tradfri hub.</p>
<h4 id="impl-SmartThings-3">Implementation 3: TD Producer</h4>
<p>TD which exposes a Motion sensor and Illuminance sensor supported by Node-Red.</p>
</div>
<div class="impl" id="impl-ercim">
<h3>ERCIM</h3>
<div class="testimonial">
<p>
<a href="https://github.com/draggett/arena-webhub">Arena Web Hub</a>
is an open source node-based application server for the Web of Things that has been implemented with support
from the European Commission for the
<a href="https://www.f-interop.eu">F-Interop project</a>
as a means to demonstrate high level interoperability testing for the Web of Things.
</p>
<p>
One of the example applications is a browser-based test suite for both client and server in respect to the
contract implied by a Thing Description. This uses a specially designed Thing Description, together with
associated client and server applications, and has been developed to cover the constraints implied by the
data schemas defined by the Thing Description specification.
</p>
<p>
Other example applications include remote control of a cyber-physical system, a digital twin for a smart
light, and multi-channel data streaming for remote diagnosis of cardiac problems. All of these applications
combine an exposed thing with a web page for the associated user interface.
</p>
</div>
<h4 id="impl-ercim-arena-client">Arena Client: TD Consumer</h4>
<p>
This is a browser-based JavaScript library designed to support multiple server platforms, including the Arena
Web Hub, Eclipse ThingWeb (node-wot), and Mozilla's Things Gateway.
</p>
<h4 id="impl-ercim-arena-webhub">Arena WebHub: TD Producer</h4>
<p>
Arena Web Hub is a secure by design application server with support for HTTPS and WebSockets. HTTPS is used
together with a bearer token for access control, along with support for Server-Sent Events and Long Polling.
You can get or set the values of all properties in a single transaction. The WebSockets sub-protocol is
initiated via a protocol upgrade request from HTTPS, and includes suppport for properties, actions and events.
This makes use of a RESTful request/response pattern with the same status codes as for HTTPS. Arena has
minimal dependencies on other modules and can be installed via npm or a git clone of the open source
repository. Applications can combine the producer and consumer modules as needed.
</p>
</div>
<div class="impl" id="impl-fujitsu">
<h3>Fujitsu Limited</h3>
<div class="testimonial">
<p>
Fujitsu supports this specification to connect any kinds of devices used in a various fields and to lead
them to operate from the cloud services. The WoT gateway can bring the devices to the WoT world easily,
since it can provide adaptation functionality to convert their proprietary i nterfaces to the WoT interface.
</p>
</div>
<h4 id="impl-fujitsu-gateway">Fujitsu WoT gateway: TD Producer and Consumer</h4>
<p>
The Fujitsu WoT gateway has an API similar to Scripting API. This API enables developers to make device
adapters to convert their propriety interface to WoT and create applications to handle their devices using
with WoT interface. These adapters can be attached and detached easily using with OSGi framework, since the
adapters are developed as OSGi bundles (plug-ins) and installed to the WoT gateway just before the devices to
be connected.
</p>
<p>
Multi-layered gateways are effective for the large scale system. Mainly lower gateways can connect physical
devices and upper gateways aggregate lower gateways. This configuration can cover the huge number of devices
connected to widely deployed gateways. If the upper gateway and lower gateways deploy on the cloud and on the
local network respectively, for example, inside buildings, the applications can monitor and control the
devices on the buildings beyond firewall and NAT. In the WoT plugfest, Fujitsu set up the upper gateway on the
internet and the lower gateways on the local networks in the smart home and at the plugfests site.
</p>
<h4 id="impl-fujitsu-WoT-sensors">WoT sensors: TD Producer</h4>
<p>
The WoT sensors includes a Wi-Fi communication unit that has a WoT stack on it and easily make compatible WoT
devices using sensors units. This communication unit has a common interface like I2C and GPIO for the
connections.
</p>
<h4 id="impl-fujitsu-legacy-adapter">Legacy devices with WoT adapters: TD Producer</h4>
<p>
Home appliances and facilities like window blinds in the smart home can be connected with adapters to convert
the propriety interface like ECHONET Lite to WoT. Rotating light that has EtherCAT interface can be done in
the same way.
</p>
<h4 id="impl-fujitsu-node-red">Node-RED including Node generators: TD Consumer</h4>
<p>
The pre-proccesing mechanism for Node-RED is supported to generate the nodes on Node-RED corresponding to the
shadow devices on the WoT gateway. This is composed of a retriever of TDs on the gateway and the node
generator provided by Hitachi and offers a good application development environment to quickly set up.
</p>
</div>
<div class="impl" id="impl-hitachi">
<h3>Hitachi, Ltd.</h3>
<div class="testimonial">
<p>
Hitachi understands the importance of standardization to make the world seamlessly connected, and strongly
supports W3C's activities.
</p>
<p>
Hitachi expects that standardization of Web of Things enables easy integration accross various Things and
IoT platforms. We create a tool for rapid application development using
<a href="https://nodered.org/">Node-RED</a>, called
<a href="https://github.com/k-toumura/node-red-nodegen/tree/webofthings">Node generator</a>.
</p>
</div>
<h4 id="impl-hitachi-nodegen">Node generator for Node-RED: TD Consumer</h4>
<p>
Node generator is command line tool to generate Node-RED node modules from several various sources including
Thing Description of Web of Things. Using this tool, node developers can dramatically reduce their time to
implement Node-RED node modules.
</p>
</div>
<div class="impl" id="impl-huawei">
<h3>Huawei Technologies</h3>
<div class="testimonial">
<p>
Huawei supports this specification as a practical solution to counter fragmentation in the IoT. W3C Web of
Things aligns, for instance, with oneM2M, where WoT Thing Descriptions are considered as a solution for the
so-called Interworking Proxies. A particularly noteworthy benefit of W3C Web of Things is that it applies to
any IoT application domain, from consumer electronics to heavy industries.
</p>
<p>
At this stage, Huawei focuses on supporting the standardization process. The implementations cover features
of the comprehensive and versatile specification that are not sufficiently covered by others.
</p>
</div>
<h4 id="impl-huawei-californium">WoT-enabled Californium (Cf) CoAP framework: TD Producer</h4>
<p>
<a href="https://www.eclipse.org/californium/">Eclipse Californium</a> is a comprehensive implementation of
the Constrained Application Protocol (RFC 7252). It supports all DTLS security schemes, PSK,
certificates, and RawPublicKey. By providing WoT Thing Descriptions (TDs), CoAP servers implemented by
Californium – or any other CoAP implementation – become part of the Web of Things. Huawei
provides TDs for the Californium demo apps, in particular
<a href="https://github.com/eclipse/californium/tree/2.0.x/demo-apps/cf-secure">cf-secure</a> to demonstrate
the feasibility to describe CoAPS security schemes.
</p>
<h4 id="impl-huawei-php">Meta-Interaction Thing: TD Producer</h4>
<p>
This implementation supports the full range of meta-interactions possible for Things. They are declared and
described through the <code>forms</code> array within the TD root object and allow to read/write all
Properties or to read/write multiple Properties.
</p>
<p>
The Meta-Interaction Thing also supports language negotiation and secures one Property with Digest and another
with a fictional Useless Web Token (UWT) that is described through a TD Context Extension (security scheme
<code>bearer</code> with <code>format</code> set to the UWT class name).
</p>
</div>
<div class="impl" id="impl-intel">
<h3>Intel Corporation</h3>
<div class="testimonial">
<p>
Intel supports this specification as it enables interoperation between devices from different manufacturers,
supporting the growth of an ecosystem of interoperating IoT services and easing barriers to adoption.
</p>
<p>
Three separate implementations were developed, all based on Node.js. The core implementations focused on
basic local network access without built-in security. A separate project, used by all three implementations,
provided security (encryption and authentication) by means of a reverse proxy. For the purposes of
validation this reverse proxy was considered a shared component of all three implementations, and the
features it implemented were only counted once in the results.
</p>
</div>
<h4 id="impl-intel-security">Security Proxy: Shared Component</h4>
<p>
This component, shared across all implementations provided by Intel, was a reverse proxy service that provided
authentication (via various mechanisms indicated by the schemes indicated in the Thing Description) and
encrypted transport termination. The reverse proxy service was made accessible over a secure tunnel, and
depending on the circumstances, was run in the cloud, on a gateway computer, or locally on a device. As this
component implemented the security features in all other implementations from Intel, for the purposes of
validation these features are only recorded as being supported in a single implementation.
</p>
<h4 id="impl-intel-ocf">OCF Metadata Translator: TD Producer</h4>
<p>
This implementation translated metadata made available by devices implemented using the OCF standard and
re-expressed that metadata in the form of WoT Thing Descriptions. The actual network interfaces were however
provided either by the OCF devices themselves directly via CoAP, or via a CoAP/HTTP bridge developed by OCF.
The metadata translator also had the ability to add semantic markup to the generated WoT Thing Descriptions,
using a database that related OCF Resource Types to iotschema.org capabilities. It also had the capability to
register generated TDs with directory services. Secure interfaces (e.g. HTTPS combined with an authentication
scheme) were provided via a reverse proxy attached to the HTTP interface provided by the OCF CoAP/HTTP bridge.
</p>
<p>
The OCF devices were based on the OCF Smart Home Demo and included both real and simulated devices. Real
devices used for testing included
</p>
<ol>
<li>ON\OFF Lights (various: MOSFET, Relay, LEDs),</li>
<li>RGB Light,</li>
<li>Potentiometer (analog input),</li>
<li>Toggle Switch,</li>
<li>Pushbutton,</li>
<li>IR Motion Sensor,</li>
<li>Illuminance Sensor, and</li>
<li>Buzzer.</li>
</ol>
There were also multiple instances of many of these devices, each given unique identifiers.
<p></p>
<h4 id="impl-intel-speak">WebSpeak: TD Producer</h4>
<p>
This implementation provided a service to convert text to speech. English text set to its network interface
was spoken audibily. This service was used to test several accessibility scenarios, including automatic
conversion of visible status and event information to spoken announcements in order to support blind users.
This implementation only supported an HTTP network interface, without security. Secure interfaces (eg HTTPS
combined with an authentication scheme) were provided via a reverse proxy attached to the HTTP interface. The
TDs for this service were generated using a template mechanism, and the service also had the capability to
automatically register these TDs with a directory service.
</p>
<h4 id="impl-intel-camera">Simple Web Camera: TD Producer</h4>
<p>
This implementation provided a service to capture still images from a camera and provide them over its network
interface. This was used to test various aspects of actions, including support for inputs and outputs with
different content types. The service was also capaple of introspecting the parameters made available via any
particular attached video4linux camera and made those parameters available as WoT Thing Description
properties. This implementation only supported an HTTP network interface, without security. Secure interfaces
(eg HTTPS combined with an authentication scheme) were provided via a reverse proxy attached to the HTTP
interface. The TDs for this service were generated using a template mechanism, and the service also had the
capability to automatically register these TDs with a directory service.
</p>
<h4 id="impl-intel-inference">Object Identifier: TD Producer</h4>
<p>
This implementation provided a service to detect, recognize, and localize objects in an image using a
hardware-accelerated neural network. This was implemented using a service running on a gateway. This was used
to test various aspects of actions, including support for inputs and outputs with different content types, but
in an opposite way to the camera. The camera accepted JSON to localize a region of interest and output an
image; the object identification service took a JPEG image and output JSON listing the objects recognized and
their location. This implementation only supported an HTTP network interface, without security. Secure
interfaces (eg HTTPS combined with an authentication scheme) were provided via a reverse proxy attached to the
HTTP interface. The TDs for this service were generated using a template mechanism, and the service also had
the capability to automatically register these TDs with a directory service.
</p>
</div>
<div class="impl" id="impl-oracle">
<h3>Oracle Corporation</h3>
<div class="testimonial">
<p>
Oracle supports this specification as it enables manufacturers of IoT cloud platforms and applications to
integrate devices across multiple vendors, who describe their features and functionality in a uniform way.
This enables application scenarios that allow monitoring and control of devices from different
manufacturers. Flexible rules can be used to define alert conditions that trigger actions on devices based
on sensor data from other devices. Sensor data combined with big data analytics can be used to predict
maintenance needs of devices to prevent downtime.
</p>
<p>
A common way of describing devices grows the ecosystem of devices that can be easily integrated into cloud
platforms out of the box and thus enables creating digital twins of physical devices for asset monitoring,
production monitoring, fleet management, and the management of buildings and smart cities.
</p>
<p>
Oracle offers an IoT Cloud Service that enables management of devices, messages and alerts. This platform is
complemented with cloud applications for asset monitoring, production monitoring, fleet management,
connected workers and others. The IoT Cloud Service interoperates with WoT servients as described in the
sections below.
</p>
<p>
Oracle's Asset Monitoring application is used to define scenarios that combine devices from different
manufacturers. Flexible rules trigger actions and issue alerts based on sensor data from other devices. In
several scenarios (home, industrial, smart energy) devices from various manufacturers, including Fujitsu,
Intel, Panasonic, KETI and others were integrated into a combined use case. Devices include home devices
(e.g. smart lamps, air conditioners, window blinds, cleaners, robots) and industrial devices (e.g. alert
lights, pumps, valves, liquid sensors, environment monitors, solar chargers, speech output). These devices
were controlled by rules that were triggered by events on various sensors, e.g. draining a tank when a
critical environment condition happens, indicating the water level in a tank with RGB lamps and a numeric
display panel, and more.
</p>
</div>
<h4 id="impl-oracle-converters">Thing Description to Device Model Converters: Shared Component</h4>
<p>
Oracle's IoT cloud platform defines a device model abstraction that is used to describe the common
behaviour of a class of devices via properties (attributes), actions, messages and alerts. This format is
similar to the WoT thing description and thing descriptions can be converted to device models and vice
versa.<br />
Devices that are managed by the IoT cloud platform can be expose using the WoT thing description format and
devices that are described via thing descriptions can be consumed from the IoT cloud service. Oracle provides
open source implementations of converters to generate a device model from a thing description (td2dm) and vice
versa (dm2td).
</p>
<h4 id="impl-oracle-simulators">Oracle Digital Twin Simulator: TD Producer</h4>
<p>
Oracle's IoT Cloud Service includes a simulator for devices which allows to model and test asset
monitoring scenarios without having the physical device already available. This allows experimenting with
different device models and finding the right abstraction before a device is actually manufacturered and thus
reduce the implementation risk. Various device simulations were provided by Oracle:
</p>
<ul>
<li>HVAC</li>
<li>BluePump</li>
<li>Truck</li>
<li>Connected Car</li>
</ul>
<p>
These simulations were exposed via TDs that were generated from device models using the converters above. The
simulator uses HTTP/REST with JSON to interact with the devices. To facilitate easy integration and
interworking during the plug fests we used basic. In real world scenarios typically OAuth2 is used.
</p>
<p>
TD's for devices from other manufacterer were imported using the td2dm converter and simulators were
defined for the following devices:
</p>
<ul>
<li>Fujitsu's rotary beacon light</li>
<li>Intel's RGB light</li>
<li>Panasonic's air conditioner</li>
<li>Panasonic's hue light</li>
<li>Siemens Festo Plant</li>
<li>KETI environment sensor</li>
</ul>
<h4 id="impl-oracle-node-wot">Node-WoT with Oracle Binding: TD Consumer</h4>
<p>
node-wot contains a binding to Oracle's IoT Cloud Service that was kindly developed by Matthias Kovatsch.
The binding uses Oracle's JavaScript client library that encapsulates Oracle's proprietary device to
cloud communication protocol. The integration allows node-wot to expose Things to Oracle's IoT Cloud
Service. Users of the Oracle Cloud API can then read Properties and invoke Actions on the node-wot based
Things. The converters above consume the TDs and instantiate devices with the corresponding Oracle device
model in the IoT Cloud Service.
</p>
</div>
<div class="impl" id="impl-panasonic">
<h3>Panasonic Corporation</h3>
<div class="testimonial">
<p>
Panasonic supports this specification as it enables device manufacturers to describe features and
functionality of multiple devices in a uniform way. This will make it possible to build mash-up applications
easily with multiple devices not only from single vendor but also from different vendors, which will expand
the ecosystem.
</p>
<p>
Panasonic already has various IoT devices in the market and this specification is the first candidate to be
used for the directory system to discover those devices. At the moment, Panasonic implements two types of
clients (TD consumer) as well as two types of servers (TD producer), together with independent
authentication server as a shared component, for experimental purposes.
</p>
</div>
<h4 id="impl-panasonic-authentication">Authentication Server: Shared Component</h4>
<p>
This component provides authentication functionality for users who access Panasonic things (TD producers) such
as the real things or simulated things provided by other implementations. This component supports HTTPS,
receives a predetermined userid and password via an HTTP POST method and sends back a bearer token based on
JWT. The token should be placed in the Authentication request header upon access to a Thing supporting the
"bearer" security scheme. The URL and other information of this component is provided in the
security elements of the Thing Descriptions produced by Panasonic things.
</p>
<h4 id="impl-panasonic-client-browser">Browser Based Client: TD Consumer</h4>
<p>
This implementation is a TD Consumer which works on the Chrome browser. This implementation reads a Thing
Description from a designated URL via HTTP(S), expands its properties, actions and events into UI form, then
allows user to read, write or observe a property value, invoke an action, or subscribe/unsubscribe to an event
through the UI. When the TD indicates that the thing needs a bearer token, this implementation also supports
the settting of user credentials such as userid and password and retrieves the access token from the
authentication service at the URL designated in the TD, such as the Panasonic Authentication Server explained
above. This implementation also allows the manual addition of any HTTP headers to the request message sent to
the things.
</p>
<p>
This implementation basically supports only HTTP(S) and does not support CoAP and MQTT. For observe property
and events, this implementation supports both HTTP(S) long poll and a simple WebSocket protocol which contains
only a data value in its transaction. This implementation only supports application/json as message body and
does not support text/plain. Since this implementation is browser based and uses Ajax, its default mode
requires support of CORS from the server exposing the Things, unless the chrome browser is launched with the
<code>--disable-web-security</code> option.
</p>
<h4 id="impl-panasonic-client-nodered">Node-RED Based Client: TD Consumer</h4>
<p>
This implementation is a TD Consumer which works on Node-RED. This implementation reads a Thing Description
from a designated URL via HTTP(S) and from a local folder, finds a specific thing according to a semantic
annotation, and turns the thing on/off. The implementation supports only HTTP(S) with `"nosec"` and
`"basic"` authorization. For MQTT and WebSockets, this implementation needs a hard-coded URL due to
the restriction of normal Node-RED.
</p>
<h4 id="impl-panasonic-server-real">WoT Server for Real Devices: TD Producer</h4>
<p>
This implementation is a TD producer which is hosted on a cloud server and connected to real things in the lab
through a proprietary tunneling mechanism alike to remote and local WoT proxy. This implementation accepts
HTTP bindings with bearer token authorization issued by the Panasonic Authentication Server explained above.
This implementation currently provides the following things:
</p>
<ol>
<li>Two Home Air Conditioners,</li>
<li>One robotics cleaner,</li>
<li>One set of Philips Hue Lighting and</li>
<li>Two LED bulletin boards.</li>
</ol>
This implementation is based on Apache HTTP server with plugins written in PHP.
<p></p>
<h4 id="impl-panasonic-server-simulator">WoT Simulator: TD Producer</h4>
<p>
This implementation is a TD producer which is hosted on a cloud server and hosts virtual things running on the
server. This implementation accepts HTTP bindings with bearer token authorization issued by the Panasonic
Authentication Server explained above. This implementation currently provides simulation of things such as
</p>
<ol>
<li>Home Air Conditioner,</li>
<li>Robotics cleaner,</li>
<li>Philips Hue Lighting and</li>
<li>Simple LED lighting.</li>
</ol>
This implementation is based on Node.js. This implementation is portable and also can be run on a local machine
such as a Raspberry Pi.
<p></p>
</div>
<div class="impl" id="impl-siemens">
<h3>Siemens AG</h3>
<div class="testimonial">
<p>
Siemens supports this specification as it allows manufacturers to attach metadata to heterogeneous IoT
devices and services in a uniform way. The extensible model with a standardized serialization format in
particular remedies interoperability challenges with an installed base of long-lived industrial devices.
Furthermore, this specification is a central building block for several digitalization topics such as device
onboarding, device management, digital twins, and data analytics.
</p>
<p>
Siemens commits to several open-source implementations of W3C Web of Things, which are managed in the public
Eclipse Thingweb project. Siemens also implemented concepts of this specification in products and aims at
aligning the implementations and opening the features to customers once this specification reaches REC
status.
</p>
</div>
<h4 id="impl-siemens-node-wot">node-wot: TD Consumer and Producer</h4>
<p>
The node-wot implementation is a Node.js-based framework for WoT Servients. It features an implementation of
the WoT Scripting API to both consume TDs to instantiate Consumed Things and produce Exposed Things that
provide a TD. The node-wot implementation supports several Protocol Bindings including HTTP, CoAP, WebSockets,
and MQTT, with corresponding security mechanisms such as DTLS (CoAP); TLS (HTTP, MQTT), Basic, Digest, and
Bearer Token authentication (HTTP), PSK (CoAP), and username/password authentication (MQTT).
</p>
<h4 id="impl-siemens-thingweb-directory">Thingweb Directory: TD Consumer and Producer</h4>
<p>
The Thingweb Directory provides a directory service written in Java to register TDs and look them up through
queries (primarily SPARQL). The implementation consumes TDs registered with it through a web API, represent
their metadata in a KnowledgeGraph, and (re-)produces TDs to return the results of queries. Currently it
supports HTTP and CoAP bindings.
</p>
<h4 id="impl-siemens-wot-fxui">WoT-fxUI: TD Consumer</h4>
<p>
WoT-fxUI is a generic user interface (UI) for Things based on Java with JavaFX. It consumes TDs to render UI
elements that allow human users to interact with Things. The implementation currently supports HTTP and CoAP
bindings.
</p>
</div>
<div class="impl" id="impl-ORG">
<h3>Technical University of Munich</h3>
<div class="testimonial">
<p>
Technical University of Munich supports the Thing Description standardization with the testing efforts and
is interested in the development of multiple WoT standards.
</p>
<p>Multiple implementations have been provided, including TDs for closed source Philips HUE devices.</p>
</div>
<h4 id="impl-tum-micropythonbare">Bare Micropython Light Sensor: TD Producer</h4>
<p>
A light sensor that is attached to an ESP 8266 board that is programmed in Micropython. The board is resource
constrained and does not allow installation of HTTP server libraries like Flask. That is why it is called
<b>bare</b>.
</p>
<h4 id="impl-tum-pythonflask">Python Flask: TD Producer</h4>
<p>
Two implementations using the Flask library for creating an HTTP server. One of the implementations is a
camera that can take pictures and the other one is an LED Strip that allows for complex data structures.
</p>
<h4 id="impl-tum-mqtt">MQTT Publisher: TD Producer</h4>
<p>
Example of an MQTT servient that allows for observable properties. There are also examples on how to use oneOf
and null vocabulary terms. This is a running instance at the Eclipse Thingweb server that uses the
test.mosquitto online broker.
</p>
<h4 id="impl-tum-mqtt-retain">MQTT Publisher with Retain: TD Producer</h4>
<p>
Example of an MQTT servient that allows for observable and readable properties. It uses the Mosca MQTT broker
that is available from Node-Red. The values pushed are temperature values that vary between 10 and 11.
</p>
<h4 id="impl-tum-hue">Philips HUE: TD Producer</h4>
<p>
TDs for different HUE devices, including the Bridge. These TDs show that we can describe already existing
devices with TDs
</p>
</div>
</div>
<h2 id="h_security"><a id="security" name="security">7. Security</a></h2>
<p>
The
<a href="https://www.w3.org/TR/wot-thing-description">Web of Things (WoT) Thing Description</a>
specification includes features to support security. Functional aspects of assertions associated with security
features are validated in the same fashion as other functional features. In addition, however, the
<a href="https://www.w3.org/2016/12/wot-wg-2016.html">Web of Things (WoT) WG Charter</a>
requires the development of a test plan that includes adversarial testing. An appropriate security test plan,
including a description of how existing web service penetration testing tools can be used, in addition to a
description of more general security and privacy considerations, is included in
<a href="http://www.w3.org/TR/wot-security">Web of Things (WoT) Security and Privacy Guidelines</a>.
</p>
<h2 id="h_test_results"><a id="test_results" name="test_results">8. Test results</a></h2>
<p>
The aim of this section is to summarize the assertions from the
<a href="http://www.w3.org/TR/wot-thing-description">Web of Things (WoT) Thing Description</a>
specification and summarize the results from the implementation reports received in the CR period. The tables in
each section below lists all assertions derived from the
<a href="http://www.w3.org/TR/wot-thing-description">Web of Things (WoT) Thing Description</a>
specification. The results are broken into two parts: those for which automated testing has been implemented, and
those for which it has not and manual testing and reporting was necessary.
</p>
<p>The headers for these tables are described as follows:</p>
<ul>
<li>
The <b>ID</b> column uniquely identifies the assertion. and links to the assertion in the context of the
specification.
</li>
<li>The <b>Category</b> column groups assertions by function.</li>
<li>
The <b>Req</b> column is a Y/N value indicating whether the assertion is for a feature which is required. Note
however that the feature may only be required if another feature is also used or in a particular context, as
indicated in the <b>Context</b> column.
</li>
<li>
The <b>Context</b> column indicates that the "required" status of this feature depends on the use of
other features. If the context is itself optional, then the value of <b>Req</b> actually indicates whether the
feature is required if the indicated context exists.
</li>
<li>
The <b>Assertion</b> column specifies the constraint which must be met. Note that this text may contain errors
as it is automatically drawn from the specification source before ReSpec processing, so automatic content
provided by ReSpec such as section headings will be missing. If the assertion is actually given in a tabular
form in the specification, appropriate text is generated but this may not match the text in the specification
itself. To fully understand the assertion please look at the assertion in context in the specification using the
provided hyperlink.
</li>
<li>
The <b>Parent</b> column indicates another more general assertion that this one is a specialization of. A
specialization indicates a more restrictive context or provides additional detail to facilitate testing. The
more general assertion is only considered to have a "pass" status if all its required or implmented
specializations in a given implementation have a "pass" status.
</li>
<li>
The <b>Result</b> column is annotated with the number of <code>pass</code> (<b>P</b>),
<code>fail</code> (<b>F</b>), and <code>not-impl</code> (<b>N</b>) status results in the individual implementer
reports.
</li>
<li>
The <b>T</b> column indicates the total number of implementations (or implementation components in the case of
shared components) reporting a status (of any kind) on each assertion. The totals do not sum to a consistent
value since not all implementations have provided information on all assertions.
</li>
</ul>
<p>