forked from w3c/wot-thing-description
-
Notifications
You must be signed in to change notification settings - Fork 0
/
report.html
6546 lines (6199 loc) · 296 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,.05);
border-radius: 3px;
margin: 0;
padding: .2em .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:public-wot-wg@w3.org">wot-wg@w3.org</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.