forked from w3c/wot-architecture
-
Notifications
You must be signed in to change notification settings - Fork 0
/
index.html
3015 lines (2974 loc) · 132 KB
/
index.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 xmlns="http://www.w3.org/1999/xhtml" lang="en">
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8" />
<meta charset="utf-8" />
<title>Web of Things (WoT) Architecture</title>
<script class="remove"
src="https://www.w3.org/Tools/respec/respec-w3c-common"></script>
<script class="remove">
var respecConfig = {
specStatus : "ED",
processVersion : 2017,
shortName : "wot-architecture",
copyrightStart : 2017,
wg : "Web of Things Working Group",
wgURI : "https://www.w3.org/WoT/WG/",
wgPublicList : "public-wot-wg",
edDraftURI : "https://w3c.github.io/wot-architecture/",
githubAPI : "https://api.github.com/repos/w3c/wot-architecture",
issueBase : "https://www.github.com/w3c/wot-architecture/issues",
editors : [ {
name : "Matthias Kovatsch",
w3cid : "75998",
company : "Huawei",
companyURL : "https://www.huawei.com/"
}, {
name : "Kazuo Kajimoto",
w3cid : "74112",
company : "Panasonic Corp.",
companyURL : "https://www.panasonic.com/"
}, {
name : "Ryuichi Matsukura",
w3cid : "64284",
company : "Fujitsu Ltd.",
companyURL : "https://www.fujitsu.com/"
}, {
name : "Michael Lagally",
w3cid : "47166",
company : "Oracle Corp.",
companyURL : "https://www.oracle.com/"
}, {
name : "Toru Kawaguchi",
w3cid : "79307",
company : "Panasonic Corp.",
companyURL : "https://www.panasonic.com/"
} ],
otherLinks : [
{
key : "Contributors",
data : [ {
value : "In the GitHub repository",
href : "https://github.com/w3c/wot-architecture/graphs/contributors"
} ]
}, {
key : "Repository",
data : [ {
value : "We are on GitHub",
href : "https://github.com/w3c/wot-architecture/"
}, {
value : "File a bug",
href : "https://github.com/w3c/wot-architecture/issues"
} ]
} ],
localBiblio : {
"CoRE-RD" : {
href : "https://tools.ietf.org/html/draft-ietf-core-resource-directory-11",
title : "CoRE Resource Directory",
status : "Internet-Draft",
publisher : "IETF",
date : "03 July 2017"
},
"WOT-SECURITY-CONSIDERATIONS" : {
href : "https://www.w3.org/TR/wot-security/",
title : "Web of Things Security and Privacy Considerations",
publisher : "W3C"
},
"IEC-FOTF" : {
href : "https://www.iec.ch/whitepaper/pdf/iecWP-futurefactory-LR-en.pdf",
title : "Factory of the future",
publisher : "IEC",
date : "October 2015"
},
"REST" : {
title : "REST: Architectural Styles and the Design of Network-based Software Architectures",
author : "Roy Thomas Fielding",
status : "PhD thesis",
publisher : "University of California, Irvine",
date : "2000"
},
"HMI" : {
title : "The Encyclopedia of Human-Computer Interaction, 2nd Ed",
author : "Mads Soegaard, Rikke Friis Dam",
publisher : "Interaction Design Foundation",
date : "2013"
},
"NORMAN" : {
title : "The Psychology of Everyday Things",
author : "Donald A. Norman",
publisher : "Basic Books",
date : "1988"
},
"MQTT" : {
title : "MQTT Version 3.1.1",
author : "Andrew Banks, Rahul Gupta",
publisher : "OASIS Standard",
date : "2014"
},
"FORMS" : {
href : "https://tools.ietf.org/html/draft-hartke-t2trg-coral",
title : "The Constrained RESTful Application Language (CoRAL)",
author : "Klaus Hartke",
publisher : "IETF",
status : "Internet-Draft",
date : "2019"
}
}
};
</script>
<style type="text/css">
a[href].internalDFN {
color: inherit;
border-bottom: 1px solid #99c;
text-decoration: none;
}
</style>
</head>
<body>
<section id="abstract">
<p>The W3C Web of Things (WoT) was created to enable
interoperability across IoT Platforms and application domains.
</p>
<p>
WoT provides mechanisms to formally describe IoT interfaces
to allow IoT devices and services to communicate with each other,
independent of their underlying implementation, and across multiple
networking protocols.
In addition WoT offers a standardized way to define and program IoT behavior.</p>
<p>This WoT Architecture document describes the abstract architecture for the W3C
Web of Things. It is derived from a set of requirements that were derived
from use cases for multiple application domains.
The architecture can be mapped onto a variety of concrete deployment scenarios,
several examples of which are given.
</p>
<p>
The document is focused on the
scope of W3C WoT standardization, which consists of three initial
building blocks. These are described by additional WoT
specifications:
</p>
<ul>
<li>the <a href="https://w3c.github.io/wot-thing-description/">WoT
Thing Description</a> ,
</li>
<li>the <a href="https://w3c.github.io/wot-binding-templates/">WoT
Binding Templates</a> , and
</li>
<li>the <a href="https://w3c.github.io/wot-scripting-api/">WoT
Scripting API</a> .
</li>
</ul>
<p>
The <a>WoT Thing Description</a> is the primary building block,
as it describes the network-facing interface of a Thing (<a>WoT
Interface</a>).
</p>
<p>
The optional <a>WoT Binding Templates</a> can be used to describe
multiple protocol bindings, sothat a <a>Thing</a> can communicate
with different <a>IoT Platforms</a> (i.e., IoT ecosystems or standards).
</p>
<p>
The optional <a>WoT Scripting API</a> enables to implement the application logic
of a Thing using a standardized contract for JavaScript.
This simplifies IoT application development and enables
portability across vendors and WoT network components.
</p>
<p>Other non-normative architectural blocks and conditions
underlying the Web of Things are also described in the context of
deployment scenarios. In particular, recommendations for security and
privacy are included, while the goal is to preserve and support
existing device mechanisms and properties. In general, W3C WoT is
designed to describe what exists rather than to prescribe what to
implement.
</p>
</section>
<section id="sotd">
<p class="ednote" title="The W3C WoT WG is asking for feedback">
Please contribute to this draft using the <a
href="https://github.com/w3c/wot-architecture/issues">GitHub
Issue</a> feature of the <a
href="https://github.com/w3c/wot-architecture/">WoT Architecture</a>
repository. For feedback on security and privacy considerations,
please use the <a href="https://github.com/w3c/wot-security/issues">WoT
Security and Privacy</a> Issues, as they are cross-cutting over all our
documents.
</p>
</section>
<section>
<h1>Introduction</h1>
<p>
The "Web of Things" (WoT) started as an academic initiative in the
form of publications and, starting in 2010, a yearly <a
href="https://webofthings.org/events/">International Workshop on
the Web of Things</a> . Its goal is to improve interoperability as well
as usability in the Internet of Things (IoT). With the increasing
role of IoT services using other web standards in commercial and
industrial applications, the W3C chartered an <a
href="https://www.w3.org/WoT/IG/">Interest Group</a> in 2015 to
identify technological building blocks for Recommendation Track
standardization. With the WoT <a href="https://www.w3.org/WoT/WG/">Working
Group</a> chartered end of 2016, the first set of WoT building blocks has
now being standardized:
</p>
<ul>
<li>the <a href="https://w3c.github.io/wot-thing-description/">WoT
Thing Description</a>,
</li>
<li>the <a href="https://w3c.github.io/wot-binding-templates/">WoT
Binding Templates</a>, and
</li>
<li>the <a href="https://w3c.github.io/wot-scripting-api/">WoT
Scripting API</a>.
</li>
</ul>
<p>This document serves as an umbrella for the W3C WoT draft
specifications and defines the basics such as terminology and the
underlying abstract architecture of the W3C Web of Things. In
particular, the purpose of this document is to provide</p>
<ul>
<li>a set of use cases that lead to the W3C WoT Architecture,</li>
<li>a set of requirements for WoT implementations,</li>
<li>an overview of the WoT building blocks being standardized
and their interplay,</li>
<li>a guideline to map the abstract architecture to software
stacks and hardware components,</li>
<li>and security considerations to be aware of when implementing
WoT building blocks.</li>
</ul>
</section>
<section id="conformance"></section>
<section>
<h1>Terminology</h1>
<p>
<em>This section is normative.</em>
</p>
<p>This document uses the following terms as defined here. The WoT
prefix is used to avoid ambiguity for terms that are defined
specifically for Web of Things concepts.</p>
<dl>
<dt>
<dfn>Action</dfn>
</dt>
<dd>An Interaction Affordance that allows to invoke a function
of the Thing, which manipulates internal state that is not directly
exposed (cf. Properties) based on internal logic or triggers a
process on the Thing.</dd>
<dt>
<dfn>Application</dfn>
</dt>
<dd>A running or periodically running process that consumes one
or more Things (read and processes there data, control their state)
and/or exposes one or more Things (provide access to locally
gathered data or computed from consumed Things, provide remote
control and management interfaces). The application can be
implemented using the Scripting API or native platform APIs. The
application may also be distributed over multiple Things and other
hosts.</dd>
<dt>
<dfn data-lt="WoT Binding Templates">Binding Templates</dfn>
</dt>
<dd>A re-usable collection of blueprints for the communication
with different IoT platforms. The blueprints includes the required
vocabulary for the Thing Description to map Interactions to
platform-specific messages as well as implementation notes for the
required protocol stacks or dedicated communication drivers.</dd>
<dt>
<dfn>Client API</dfn>
</dt>
<dd>Programming interface that allows scripts to access remote
Things over the network, local Things in a different execution
environment, or directly attached hardware (which is abstracted as
Things).</dd>
<dt>
<dfn>to consume a Thing</dfn>
</dt>
<dd>To read a Thing Description and create a Consumed Thing
software object for the application in the local runtime
environment.</dd>
<dt>
<dt>
<dfn>CoAP</dfn>
</dt>
<dd>Acronym for Constrained Application Protocol [[RFC7252]]</dd>
<dt>
<dfn>CWT</dfn>
</dt>
<dd>CBOR Web Token</dd>
<dfn>Consumed Thing</dfn>
</dt>
<dd>A software object instance created through the WoT object of
the Scripting API that represents a remote Thing used by the local
application. It is defined by the ConsumedThing interface of the WoT
Scripting API.</dd>
<dt>
<dfn>Digital Twin</dfn>
</dt>
<dd>A digital twin is a virtual representation of a device or a
group of devices that resides on a cloud server or edge device. It
can be used to represent real-world devices which may not be
continuously online, or to run simulations of new applications and
services, before they get deployed to the real devices.</dd>
<dt>
<dfn>Discovery API</dfn>
</dt>
<dd>Programming interface that allows scripts to discover other
Things (local, nearby, or remote).</dd>
<dt>
<dfn>Domain-specific vocabulary</dfn>
</dt>
<dd>Linked Data vocabulary that can be used in the WoT Thing
Description, but is not defined by W3C WoT.</dd>
<dt>
<dfn>Event</dfn>
</dt>
<dd>An Interaction Affordance that describes asynchronous push
interactions initiated by the Thing.</dd>
<dt>
<dfn>Execution Environment</dfn>
</dt>
<dd>A sandbox within the Runtime that isolates scripts running
on the same Servient.</dd>
<dt>
<dfn>to expose a Thing</dfn>
</dt>
<dd>To create an Exposed Thing software object in the local
runtime environment that enables the application to provide local
state and calls as Interactions over the network.</dd>
<dt>
<dfn>Exposed Thing</dfn>
</dt>
<dd>A software object instance created through the Server API
that is implemented locally and can be accessed over the network by
remote WoT Clients. It is defined by the ExposedThing interface of
the WoT Scripting API.</dd>
<dt>
<dfn>Hypermedia Control</dfn>
</dt>
<dd>Hypermedia controls are Web links [[!RFC8288]] and request
templates where the latter can be seen as forms to fill in
and to send to servers.</dd>
<dt>
<dfn>Interaction Affordance</dfn>
</dt>
<dd>Metadata of a Thing exposing <a>hypermedia controls</a> that describe
the possible protocol-level choices to clients, thereby
suggesting how clients may interact with the Thing.
Examples use of affordances includes, but are not limited,
getting and setting <a>properties</a>, invoking <a>actions</a>,
and subscribing to <a>events</a>.</dd>
<dt>
<dfn>Interaction Model</dfn>
</dt>
<dd>An intermediate abstraction that formalizes the mapping from
application intent to concrete protocol bindings, which are used to
interact with Web resources.</dd>
<dt>
<dfn>IoT platform</dfn>
</dt>
<dd>A specific IoT ecosystem such as OCF, oneM2M, or Mozilla
Project Things with its own specifications for application-facing
APIs, data model, and protocols or protocol configurations.</dd>
<dt>
<dfn>JSON-LD</dfn>
</dt>
<dd>
A JSON document that is augmented with support for Linked Data by
providing an
<code>@context</code>
property with a defining URI [[json-ld]].
</dd>
<dt>
<dfn>JWT</dfn>
</dt>
<dd>JSON Web Token [[RFC7519]]</dd>
<dt>
<dfn>Local Discovery</dfn>
</dt>
<dd>A discovery method that can discover Things directly
connected to a Servient (e.g., sensor or actuator that is abstracted
as Thing).</dd>
<dt>
<dfn>Manual Discovery</dfn>
</dt>
<dd>A discovery method where the URI of the used consumed Thing
Descriptions is provided manually (e.g., through user configuration
or hard-coding in a script).</dd>
<dt>
<dfn>MQTT</dfn>
<dd>
<i>Message Queuing Telemetry Transport</i> is a
publish-subscribe-based messaging protocol.[[!MQTT]]
</dd>
<dfn>Nearby Discovery</dfn>
</dt>
<dd>A discovery method where the physical location is considered
(e.g., BLE, Audio Watermarking, ...).</dd>
<dt>
<dfn>Network Discovery</dfn>
</dt>
<dd>A discovery method that can discover Things in local
networks (e.g. SSDP, mDNS/DNS-SD, ...).</dd>
<dt>
<dfn>Property</dfn>
</dt>
<dd>An Interaction Affordance that exposes internal state of the
Thing that can be directly accessed (read) and optionally
manipulated (write).Things can also choose to make Properties
observable by pushing the new state after a change.</dd>
<dt>
<dfn data-lt="WoT Protocol Binding">Protocol Binding</dfn>
</dt>
<dd>The set of mapping rules from an Interaction Affordance to
concrete messages of a specific protocol. These rules are encoded
into the TD using forms.</dd>
<dt>
<dt>
<dfn>RDF</dfn>
</dt>
<dd>The Resource Description Framework (RDF) of the Semantic Web
[[rdf-concepts]]</dd>
<dfn>Remote Discovery</dfn>
</dt>
<dd>A discovery method which supports lookup of remote Things
also beyond network boundaries, for instance by using a directory
service. The endpoint of the directory must be supported.</dd>
<dt>
<dfn>Server API</dfn>
</dt>
<dd>Programming interface that allows scripts to expose local
functionality as Things to WoT Clients.</dd>
<dt>
<dfn>Servient</dfn>
</dt>
<dd>A software stack that implements the WoT building blocks. A
Servient can host and expose Things (server role) and/or consume
Things (client role). Servients usually have multiple Protocol
Bindings to enable interaction with different platforms.</dd>
<dt>
<dfn>Subprotocol</dfn>
</dt>
<dd>An extension mechanism to a transfer protocol that must be
known to interact successfully.</dd>
<dt>
<dfn>TD</dfn>
</dt>
<dd>Short for Thing Description.</dd>
<dt>
<dfn>TD Vocabulary</dfn>
</dt>
<dd>A controlled Linked Data vocabulary by W3C WoT to tag the
metadata of Things in the WoT Thing Description including
communication metadata of WoT Binding Templates.</dd>
<dt>
<dfn>Thing</dfn>
</dt>
<dd>An abstraction of a physical or a virtual entity whose
metadata and interfaces are described by a WoT Thing Description,
whereas a virtual entity is the composition of one or more Things.</dd>
<dt>
<dfn data-lt="WoT Thing Description">Thing Description</dfn>
</dt>
<dd>Structured data describing a Thing. A TD includes metadata,
domain-specific metadata, a list of offered interactions, the
supported protocol bindings for each interaction, and links to
related Things. The Thing Description is built around a formal
Interaction Model.</dd>
<dt>
<dfn>Thing Directory</dfn>
</dt>
<dd>A directory service for TDs that provides a Web interface to
register TDs (see [[CoRE-RD]]) and look them up (e.g., using SPARQL
queries or CoRE Link Format).</dd>
<dt>
<dfn>Transfer Protocol</dfn>
</dt>
<dd>The underlying, standardized application layer protocol
without application-specific options or subprotocol mechanisms.</dd>
<dt>
<dfn>WoT</dfn>
</dt>
<dd>The Web of Things initiative and family of specifications in
the W3C.</dd>
<dt>
<dfn>WoT Client</dfn>
</dt>
<dd>An entity that can connect with a network interface
described by a WoT Thing Description (i.e., consume a Thing). WoT
Clients usually implement multiple Protocol Bindings. WoT Client is
also used to refer to a Servient in client role only.</dd>
<dt>
<dfn>WoT Interface</dfn>
</dt>
<dd>The WoT Interface is the network-facing interface that is
described by a TD. This requires the mapping rules of Protocol
Bindings between the abstract WoT Runtime (Thing level) to a
network-facing interface (protocol level).</dd>
<dt>
<dfn>WoT Object</dfn>
</dt>
<dd>The WoT object is the Scripting API entry point within a WoT
Runtime. It provides methods to discover, consume, and expose
Things.</dd>
<dt>
<dfn>WoT Runtime</dfn>
</dt>
<dd>A runtime system for application scripts with the WoT
Scripting API. Implementing a WoT Runtime is optional for Servients.
The WoT Runtime should be the component that instantiates Consumed
Things and Exposed Things as software objects, manages their state,
and generates the TDs. It communicates with other components such as
the Binding implementations and application scripts (the WoT
Scripting API being one way).</dd>
<dt>
<dfn data-lt="WoT Scripting API">Scripting API</dfn>
</dt>
<dd>The application-facing programming interface provided by a
Servient; comparable to the Web browser APIs. It is an API provided
to ease the implementation of, or to extend a WoT Runtime.</dd>
<dt>
<dfn>WoT Server</dfn>
</dt>
<dd>An entity that exposes a network interface consistent with a
WoT Thing Description. WoT Server is also used to refer to a
Servient in server role only.</dd>
</dl>
</section>
<!-- USE CASES -->
<section id="sec-use-cases" class="informative">
<h1>Use Cases</h1>
<p>
This section presents the application domains and use cases targeted
by the W3C WoT and which are used to derive the abstract architecture
discussed in <a href="#sec-building-blocks"></a>.
</p>
<p>The Web of Things architecture does not put any limitations on
use cases and application domains. Various application domains have
been considered to collect common patterns that have to be satisfied
by the abstract architecture.</p>
<p>The following sections are not exhaustive. Rather they serve as
illustrations, where connected things can provide additional benefit
or enable new scenarios.</p>
<section>
<h2>Application Domains</h2>
<section id="consumerusecases">
<h3>Consumer</h3>
<p>
In the consumer space there are multiple assets that benefit from
being connected. Lights and air conditioners can be turned off based
on room occupancy. Window blinds can be closed automatically based
on weather conditions and presence. Energy and other resource
consumption can be optimized based on usage patterns and
predictions.
</p>
<p>
The consumer use cases in this section includes Smart Home use case.
</p>
<p>
<a href="#smart-home"></a> shows an example of a Smart Home.
In this case, gateways are connected to edge devices such
as sensors, cameras and home appliances through corresponding
local communication protocols such as KNX, ECHONET, ZigBee,
DECT ULE and Wi-SUN. Multiple gateways can exist in one home,
while each gateway can support multiple local protocols.
</p>
<p>
Gateways can be connected to the cloud through the internet,
while some appliances can be connected to the cloud directly.
Services running in the cloud collect data from edge devices and
analyze the data, then provide value to users through the edge
devices and other UX devices.
</p>
<figure id="smart-home">
<img src="images/wot-use-cases/smart-home.png"
style="width: 640px;" />
<figcaption>Smart Home</figcaption>
</figure>
<p>
Smart home provides consumer benefits such as remote access and
control, voice control and home automation. Smart home also enables
device manufacturers to monitor and maintain devices remotely. Smart
home can realizes added value services such as energy management and
security surveilance.
</p>
</section>
<section id="industrialiotusecases">
<h3>Industrial</h3>
<p>
The industrial use cases in this section are applicable to
different industry verticals. <br /> Due to the nature of overlaps
in the application scenarios, different verticals have similar use
cases.
</p>
<section>
<h4>Example: Smart Factory</h4>
<p>
<a href="#smart-factory"></a> shows an example of a Smart Factory.
In this case, field-level, cell and line controllers automate different
factory equipment based on industrial communication protocols such as Profinet,
Modbus, OPC UA TSN, EtherCAT, or CAN. An industrial edge device collects selected data
from various controllers and makes it available to a cloud backend service, e.g. for
remote monitoring via a dashboard or analyzes it for preventive maintenance.
</p>
<figure id="smart-factory">
<img src="images/wot-use-cases/smart_factory_new.png"
style="width: 640px;" />
<figcaption>Smart Factory</figcaption>
</figure>
</section>
<p>Smart factories require advanced monitoring of the connected
manufacturing equipment as well of the manufactured products. They
benefit from predictions of machine failures and early discovery of
anomalies to prevent costly downtime and maintenance efforts.</p>
<p>Additionally, monitoring of connected manufacturing equipment
and the environment at the production facility for the presence of
poisonous gases, excessive nois or heat increases the safety of the
workers and reduces the risks of incidents or accidents.</p>
<p>Real-time monitoring and KPI calculations of production
equipment helps to detect productivity problems and optimize the
supply chain.</p>
</section>
<section>
<h4 id="transportationlogistics">Transportation & Logistics</h4>
<p>Monitoring of vehicles, fuel costs, maintenance needs and
assignments helps to optimize the full utilization of the vehicle
fleet.</p>
<p>Shipments can be tracked to be en-route to ensure consistent
quality and condition of the transported goods. This is especially
useful to assert the integrity of the cold-chain from warehouses to
refrigerated trucks to delivery.</p>
<p>Centralized monitoring and management of stock in warehouses
and yards can prevent out of stock and excessive stock situations.
</p>
</section>
<section>
<h4 id="utilities">Utilities</h4>
<p>Automated reading of residential and C&I (Commercial and
Industrial) meters, and billing offers continuous insights into
resource consumption and potential bottlenecks.</p>
<p>Monitoring the condition and output of distributed renewable
energy generation equipment enables optimisation of distributed
energy resources.</p>
<p>Monitoring and remote-controlling of distribution equipment
helps to automate the distribution process.</p>
<p>Continuous monitoring of generation and distribution
infrastructure is improving safety of utilities crew in the field.
</p>
</section>
<section>
<h4 id="oilandgas">Oil and Gas</h4>
<p>Offshore platform monitoring, leakage detection and
predicition of pipelines as well as monitoring and controlling the
levels in tanks and reservoirs helps to improve the industrial
safety for the workforce as well as for the environment.</p>
<p>Automated calculation of a distributed stock through various
storage tanks and delivery pipes/trucks allows for improved
planning and resource optimisation.</p>
</section>
<section>
<h4 id="insurance">Insurance</h4>
<p>Proactive Asset Monitoring of high value assets such as
connected structures, fleet vehicles, etc. mitigates the risk of
severe damage and high costs due to predictions and early detection
of incidents.</p>
<p>Usage based insurance can be offered with usage tracking and
customized insurance policies.</p>
<p>Predictive weather monitoring and re-routing fleet vehicles
to covered garages can limit loss due to hail damage, tree damage.
</p>
</section>
<section>
<h4 id="engineeringandconstruction">Engineering and
Construction</h4>
<p>Monitoring for industrial safety reduces the risks of
security hazards. Monitoring of assets at construction site can
prevent damage and loss.</p>
</section>
<section id="sec-agriculture">
<h3 id="agriculture">Agriculture</h3>
<p>Soil condition monitoring and creating optimal plans for
watering, fertilizing as well as monitoring the produce conditions
optimize the quality and output of agricultural produce.</p>
</section>
<section id="sec-healthcare">
<h3 id="healthcare">Healthcare</h3>
<p>Data collection and analytics of clinical trial data helps to
gain insights into new areas.</p>
<p>Remote patient monitoring mitigates the risk of undetected
critical situations for elderly people and patients after
hospitalization.</p>
</section>
<section>
<h3 id="environmentmonitoring-1">Environment Monitoring</h3>
<p>Environment monitoring typically relies on a lot of
distributed sensors that send their measurement data to common
gateways, edge devices and cloud services.</p>
<p>Monitoring of air pollution, water pollution and other
environmental risk factors such as fine dust, ozone, volatile
organic compound, radioactivity, temperature, humidity to detect
critical environment conditions can prevent unrecoverable health or
environment damages.</p>
</section>
<section id="smart cities">
<h3 id="smartcities">Smart Cities</h3>
<p>Monitoring of Bridges, Dams, Levees, Canals for material
condition, deterioration, vibrations discovers maintenance repair
work and prevents significant damage. Monitoring of highways and
providing appropriate signage ensures optimized traffic flow.</p>
<p>Smart Parking is optimizing and tracking the usage and
availability of parking spaces and automates billing/reservations.</p>
<p>Smart control of street lights based on presence detection,
weather predictions, etc reduced cost.</p>
<p>Garbage containers can be monitored to optimize the waste
management and the trash collection route.</p>
</section>
<section id="smart buildings">
<h3 id="smartbuildings">Smart Buildings</h3>
<p>Monitoring the energy usage throughout the building helps to
optimize resource consumption and reduce waste.</p>
<p>Monitoring the equipment in the buildings such as HVAC,
Elevators, etc. and fixing problems early improves the satisfaction
of occupants.</p>
</section>
<section id="connected car">
<h3 id="connectedcar">Connected Car</h3>
<p>Monitoring of operation status, prediction of service needs
optimizes maintenance needs and costs. Driver safety is enhanced
with notifications of an early warning system for critical road and
traffic conditions.</p>
<section id="connected car example">
<h4 id="connectedcar-example">Connected Car Example</h4>
<p>
<a href="#connected-car"></a> shows an example of a Connected Car.
In this case, a gateway connects to car components through CAN and
to the car navigation system through a proprietary interface.
Services running in the cloud collect data pushed from car
components and analyze the data from multiple cars to determine
traffic patterns. The gateway can also consume cloud services, in
this case, to get traffic data and show it to the driver through
the car navigation system.
</p>
<figure id="connected-car">
<img src="images/wot-use-cases/connected-car.png"
style="width: 500px;" />
<figcaption>Connected Car</figcaption>
</figure>
</section>
<p>Monitoring of operation status, prediction of service needs
optimizes maintenance needs and costs. Driver safety is enhanced
with notifications of an early warning system for critical road and
traffic conditions.</p>
</section>
</section>
<section id="commonusecasespatterns">
<h1>Common Patterns</h1>
<section>
This section introduces common use case patterns that illustrate how
devices/things interact with controllers, other devices, agents and
servers.
<h3>Device Controllers</h3>
<p>
The first use case is a local device controlled by user-operated
remote controller as depicted in <a href="#smart-home-device"></a> .
For example, A remote controller can access an electronic appliance
through the local home network directly. In this case, the remote
controller can be realized by a browser or native application.
</p>
<p>In this pattern, at least one device like the electronic
appliance have a server role that can accept the request from the
other devices and respond them, and sometimes start to initiate
mechanical function of it. The another device like the remote
controller have a client role that can issue a message to the other
with some requests, like to get sensor value or to turn it on.</p>
<figure id="smart-home-device">
<img src="images/wot-use-cases/smart-home-device.png"
style="width: 500px;" />
<figcaption>Device Control</figcaption>
</figure>
</section>
<section>
<h3>Thing-to-Thing</h3>
<p>
<a href="#smart-home-t2t"></a> shows an example of direct
Thing-to-Thing interaction. The scenario is as follows: a sensor
detects the change of the room condition, for example the
temperature surpassing a set threshold, and issues a control message
like "turn on" to the electronic appliance. The sensor unit can
issue some trigger messages to other devices.
</p>
<p>In this case, when two devices that have server roles are
connected, at least one device must have also a client role that
issues a message to the other to actuate.</p>
<figure id="smart-home-t2t">
<img src="images/wot-use-cases/smart-home-t2t.png"
style="width: 500px;" />
<figcaption>Control Agent</figcaption>
</figure>
</section>
<section>
<h3>Remote Access</h3>
<p class="ednote" title="TODO">Must rewrite for remote
access/control use case. Include changing uplink connectivity.</p>
<p>
The third use case is a mobile remote controller (e.g., on a
smartphone) as shown in <a href="#smart-home-multi"></a>. The remote
controller can switch communication media between cellular network
and home network such as Wi-Fi and Bluetooth. The controller choose
the home network when it's at home, and the cellular while outside.
</p>
<p>In this pattern, the remote controller and the electronic
appliance have a client role and a server role respectively as the
same as 3.2.1 device controllers.</p>
<figure id="smart-home-multi">
<img src="images/wot-use-cases/smart-home-multi.png"
style="width: 500px;" />
<figcaption>Multiple Network Interfaces</figcaption>
</figure>
</section>
<section>
<h3>Gateways</h3>
<p class="ednote" title="TODO">Must rewrite for local box/compute
node use case.</p>
<p>
<a href="#smart-home-gateway"></a> shows a use case based on a Smart
Home gateway. A smart home gateway is placed between a home network
and the Internet. The gateway manages electronic appliances inside
the house and can receive commands from a remote controller over the
Internet, e.g., from a smartphone as in the previous use case. It is
also is a virtual representation of a device. The gateways sometimes
are called the proxies.
</p>
<p>In this pattern, the home gateway have both of client and
server roles. That is, it can connect to the electronic appliance
with the client role and to the remote controller with the server
role.</p>
<figure id="smart-home-gateway">
<img src="images/wot-use-cases/smart-home-gateway.png"
style="width: 500px;" />
<figcaption>Smart Home Gateway</figcaption>
</figure>
</section>
<section>
<h3>Digital Twins</h3>
<p>A digital twin is a virtual representation, i.e. a model of a
device or a group of devices that resides on a cloud server or edge
device. It can be used to represent real-world devices which may not
be continuously online, or to run simulations of new applications
and services, before they get deployed to the real devices.</p>
<figure id="digital-twin">
<img src="images/wot-use-cases/digital-twin.png"
style="width: 500px;" />
<figcaption>Digital Twin</figcaption>
</figure>
<p>Digital twins can model a single device, or they can aggregate
multiple devices in a virtual representation of the combined
devices.</p>
<figure id="digital-twin-multiple-devices">
<img src="images/wot-use-cases/digital-twin-multiple-devices.png"
style="width: 500px;" />
<figcaption>Digital Twin for Multiple Devices</figcaption>
</figure>
<p>Digital twins can be realized in different ways, depending on
whether a device is already connected to the cloud, or whether it is
connected to a gateway, which itself is connected to the cloud.</p>
<section>
<h4>Cloud-ready Devices</h4>
<p>
<a href="#smart-home-cloud1"></a> shows an example where electronic
appliances are connected directly to the cloud. The cloud mirrors
the appliances and, acting as a digital twin, can receive commands
from remote controllers (e.g., a smartphone). Authorized
controllers can be located anywhere, as the digital twin is
globally reachable.
</p>
<figure id="smart-home-cloud1">
<img src="images/wot-use-cases/smart-home-cloud1a.png"
style="width: 500px;" />
<figcaption>Appliance twin for a Cloud-ready Devices</figcaption>
</figure>
</section>
<section>
<h3>Legacy Devices</h3>
<p>
<a href="#smart-home-cloud2"></a> shows an example where legacy
electronic appliances cannot directly connect to the cloud. Here, a
gateway is needed to relay the connection. The gateway works as:
</p>
<ul>
<li>integrator of a variety of legacy communication protocols
both in the physical and logical view</li>
<li>firewall toward the Internet</li>
<li>privacy filter which substitutes real image and/or speech,
and logs data locally</li>
<li>local agent in case the Internet connection is interrupted</li>
<li>emergency services running locally when fire alarms and
similar events occur</li>
</ul>
<p>The cloud mirrors the gateway with all connected appliances
and acts as a digital twin that manages them in the cloud in
conjunction with the gateway. Furthermore, the cloud can receive
commands from remote controllers (e.g., a smartphone), which can be
located anywhere.</p>
<figure id="smart-home-cloud2">
<img src="images/wot-use-cases/smart-home-cloud2.png"
style="width: 500px;" />
<figcaption>A Digital Twin for a Legacy Device</figcaption>
</figure>
</section>
</section>
<section>
<h3>Multi-Cloud</h3>
<p>Typical IoT deployments consist of multiple (thousands) of
devices. Without a standardized mechanism, the management of
firmware updates for specific clouds require a lot of effort and
hinders wider scale IoT adoption.</p>
<p>The primary benefit of a standardized mechanism for describing
devices and device types is the capability of deploying devices to
different cloud environments without the need of doing customization
at device software / firmware level, i.e. installing cloud specific
code to a device. This implies that the solution is flexible enough
to describe devices in a way that allows on-boarding and using
devices in multiple IoT cloud environments.</p>
<p>This drives adoption of Web of Things devices, since it
enables easy usage of new devices in an existing deployment, as well
as migration of existing devices from one cloud to the other.</p>
</section>
<section>
<h3>Cross-domain Collaboration</h3>
<p>
<a href="#cross-domain"></a> show an example of a Cross-domain
collaboration. In this case, each system involves other systems in
other domains, such as Smart Factrory with Smart City, Smart City
with Smart Home. This type of system is called "Symbiotic"
ecosystem, as shown in [[IEC-FOTF]]. There are two collaboration
models: direct collaboration and indirect collaboration. In the
direct collaboration model, systems exchange their own information
directly with each other in peer-to-peer manner. In the indirect
collaboration, systems exchange their own information via some
collaboration platform. In order to maintain and continue this
collaboration, each system provide the metadata of their ability and
interfaces and adopt itself to others.
</p>
<figure id="cross-domain">
<img src="images/cross-domain-direct.png" style="width: 500px;" />
<img src="images/cross-domain-indirect.png" style="width: 500px;" />
<figcaption>Cross-domain collaboration</figcaption>
</figure>
</section>
</section>
<section>
<h2>Summary</h2>
<p class="ednote" title="TODO">The following figure has to be
simplified to only show the abstract patterns without the
implementation and WoT details (inside the gray boxes). Instead,
common patterns can be listed at the corresponding places.</p>
<p>
The possible architecture patterns are described in the previous
section. In these patterns, some entities such as the devices
including the existing devices, the controllers, the gateways, and
the clouds are located on some places such as inside building,
outside buildings, and data centers. <a href="#usecase-overview"></a>
is an integrated overview. To specify the differences of the
entities, each entities shown in the patters is tied to each of
functional roles such as a server, a client and a proxy/gateway. That
is, the client corresponds to the application or the controller, and
the server dose to the device. The proxy/gateway is an entity that
relays the connection of the client and the server. The gateway is
sometimes distinguished from the proxy because of having the protocol
converter functionality when it's connected to the existing devices.
</p>
<figure id="usecase-overview">
<img src="images/arch-use-case-overview.png" />