The
Web
of
Things
is
applicable
to
multiple
IoT
domains,
including
Smart
Home,
Industrial,
Smart
City,
Retail,
and
Health
applications,
where
usage
of
the
W3C
WoT
standards
can
simplify
the
development
of
IoT
systems
that
combine
devices
from
multiple
vendors
and
ecosystems.
During
the
last
charter
period
of
the
WoT
Working
Group
several
specifications
were
developed
to
address
requirements
for
these
domains.
This
Use
Case
and
Requirements
Document
is
created
to
collect
new
IoT
use
cases
from
various
domains
that
have
been
contributed
by
various
stakeholders.
These
serve
as
a
baseline
for
identifying
requirements
for
the
standardisation
work
in
the
W3C
WoT
groups.
Status
of
This
Document
This
is
a
preview
Do
not
attempt
to
implement
this
version
of
the
specification.
Do
not
reference
this
version
as
authoritative
in
any
way.
Instead,
see
https://w3c.github.io/wot-usecases/
for
the
Editor's
draft.
This
section
describes
the
status
of
this
document
at
the
time
of
its
publication.
Other
documents
may
supersede
this
document.
A
list
of
current
W3C
publications
and
the
latest
revision
of
this
technical
report
can
be
found
in
the
W3C
technical
reports
index
at
https://www.w3.org/TR/.
Publication
as
an
Editor's
Draft
does
not
imply
endorsement
by
the
W3C
Membership.
This
is
a
draft
document
and
may
be
updated,
replaced
or
obsoleted
by
other
documents
at
any
time.
It
is
inappropriate
to
cite
this
document
as
other
than
work
in
progress.
This
document
was
produced
by
a
group
operating
under
the
W3C
Patent
Policy
.
The
group
does
not
expect
this
document
to
become
a
W3C
Recommendation.
W3C
maintains
a
public
list
of
any
patent
disclosures
made
in
connection
with
the
deliverables
of
the
group;
that
page
also
includes
instructions
for
disclosing
a
patent.
An
individual
who
has
actual
knowledge
of
a
patent
which
the
individual
believes
contains
Essential
Claim(s)
must
disclose
the
information
in
accordance
with
section
6
of
the
W3C
Patent
Policy
.
The
World
Wide
Web
Consortium
(
W3C
)
has
published
the
Web
of
Things
(WoT)
Architecture
and
Web
of
Things
(WoT)
Thing
Description
(TD)
as
official
W3C
Recommendations
in
May
2020.
These
specifications
enable
easy
integration
across
Internet
of
Things
platforms
and
applications.
The
W3C
Web
of
Thing
Architecture
[
wot-architecture
]
defines
an
abstract
architecture,
the
WoT
Thing
Description
[
wot-thing-description
]
defines
a
format
to
describes
a
broad
spectrum
of
very
different
devices,
which
may
be
connected
over
various
protocols.
During
the
inception
phase
of
the
WoT
1.0
specifications
in
2017-2018
the
WoT
IG
collected
use
cases
and
requirements
to
enable
interoperability
of
Internet
of
Things
(IoT)
services
on
a
worldwide
basis.
Thes
released
specifications
have
been
created
to
address
the
use
cases
and
requirements
for
the
first
version
of
the
WoT
specifications,
which
are
documented
in
https://w3c.github.io/wot/ucr-doc/
The
present
document
gathers
and
describes
new
use
cases
and
requirements
for
future
standardisation
work
in
the
WoT
standard.
Editor's
note
This
document
is
an
early
work
in
progress
and
is
currently
under
significant
editorial
and
content
rework.
It
is
currently
an
aggregation
of
use
case
descriptions
that
were
contributed
in
a
different
file
format
(Markdown)
Before
it
can
be
published
as
a
IG
note,
it
will
undergo
major
restructuring
and
cleanup
in
due
course.
TODO:
Give
a
domain
overview,
explain
different
horizontals
and
verticals.
2.
Conformance
As
well
as
sections
marked
as
non-normative,
all
authoring
guidelines,
diagrams,
examples,
and
notes
in
this
specification
are
non-normative.
Everything
else
in
this
specification
is
normative.
The
key
words
MUST
NOT
,
SHOULD
,
and
SHOULD
NOT
in
this
document
are
to
be
interpreted
as
described
in
BCP
14
[
RFC2119
]
[
RFC8174
]
when,
and
only
when,
they
appear
in
all
capitals,
as
shown
here.
3.
Definitions:
Terminology,
Stakeholders
and
Actors
3.1
Terminology
The
present
document
uses
the
terminology
as
the
WoT
Architecture
[
wot-architecture
].
Editor's
note
TODO:
Define
additional
terminology.
3.2
Stakeholders
Editor's
note
TODO:
Describe
stakeholder
roles
and
tasks.
device
owners
device
user
cloud
provider
service
provider
device
manufacturer
gateway
manufacturer
identity
provider
directory
service
operator?
4.
Application
Domains
and
Use
Cases
4.1
Retail
Submitter(s)
David
Ezell,
Michael
Lagally,
Michael
McCool
Reviewer(s)
Tracker
Issue
ID
Category
Class
Status
Target
Users
Retailers,
customers,
suppliers.
Motivation
Integrating
and
interconnecting
multiple
devices
into
the
common
retail
workflow
(i.e.,
transaction
log)
drastically
improves
retail
business
operations
at
multiple
levels.
It
brings
operational
visibility,including
consumer
behavior
and
environmental
information,
that
was
not
previously
possible
or
viable
in
a
meaningful
way.
It
drastically
speeds
up
the
process
of
root
cause
analysis
of
operational
issues
and
simplifies
the
work
of
retailers.
Expected
Devices
Connected
sensors,
such
as
people
counters,
presence
sensors,
air
quality,
room
ocupancy,
door
sensors.
Cloud
services.
Video
analytics
edge
services.
Expected
Data
Inventory
data,
supply
chain
status
information,
discrete
sensor
data
or
data
streams.
Dependencies
tbd
Description
Falling
costs
of
sensors,
communications,
and
handling
of
very
large
volumes
of
data
combined
with
cloud
computing
enable
retail
business
operations
with
increased
operational
efficiency,
better
customer
service,
and
even
increased
revenue
growth
and
return
on
investment.
Accurate
forecasts
allow
retailers
to
coordinate
demand-driven
outcomes
that
deliver
connected
customer
interactions.
They
drive
optimal
strategies
in
planning,
increasing
inventory
productivity
in
retail
supply
chains,
decreasing
operational
costs
and
driving
customer
satisfaction
from
engagement,
to
sale,
to
fulfilment.
Understanding
of
store
activity
juxtaposed
with
traditional
information
streams
can
boost
worker
and
consumer
safety,
comply
better
with
work
safety
regulations,
enhance
system
and
site
security,
and
improve
worker
efficiency
by
providing
real-time
visibility
into
worker
status,
location,
and
work
environment.
Variants
Use
edge
computing,
in
particular
video
analytics,
in
combination
with
IoT
devices
to
deliver
an
enhanced
customer
experience,
better
manage
inventory,
or
otherwise
improve
the
store
workflow.
Security
Considerations
In
retail,
replay
attacks
can
cause
monetary
loss,
customers
may
be
incorrectly
charged
or
over-charged.
To
avoid
replay
attacks,
"Things"
should
implement
a
sequence
number
for
each
message
and
digital
signature.
Servers
("Things"
or
"Cloud")
should
verify
the
signature
and
disallow
for
duplicated
messages.
For
"Things"
relying
on
electronic
payments,
"Things"
must
comply
with
PCI-DSS
requirements.
"Things"
must
never
store
credit
card
information.
Customer
satisfaction
and
trust
depends
on
availability,
so
attacks
such
as
Denial-of-Service
(DoS)
need
to
be
prevented
or
mitigated.
To
prevent
DoS,
implement
"Things"
with
early
DoS
detection.
Have
an
automated
DoS
system
that
will
notify
the
controlling
unit
of
the
problem.
Implement
IP
white
list,
that
could
be
part
of
the
DoS
early
detection
system.
Make
sure
your
network
perimeter
is
defended
with
up
to
date
firewall
software.
Privacy
Considerations
As
a
general
rule,
personal
consumer
information
should
not
be
stored.
That
is
especially
true
in
the
retail
industry
where
a
security
breach
could
cause
financial,
reputation,
and
brand
damage.
If
personal
or
information
that
can
identify
a
consumer
is
to
be
stored,
it
should
be
to
conduct
business
and
with
the
explicit
acknowledgment
of
the
consumer.
WoT
vendors
and
integrators
should
always
have
a
privacy
policy
and
make
it
easily
available.
By
default,
devices
should
adopt
an
opt-out
policy.
That
means,
unless
the
consumer
explicitly
allowed
for
the
data
capture
and
storage,
avoid
doing
it.
Gaps
Editor's
note
TODO:
Describe
any
gaps
that
are
not
addressed
in
the
current
WoT
work
items.
Existing
standards
Editor's
note
TODO:
Provide
links
to
relevant
standards
that
are
relevant
for
this
use
case
4.2
Audio/Video
4.2.1
Media
Use
Case
Information
Bucket
This
section
is
not
a
full
use
case
description.
It
is
rather
a
collection
of
thoughts
and
ideas
to
capture
information
and
provide
references
and
have
a
common
discussion
basis.
The
intention
is
to
trigger
new
ideas
and
collect
them
in
a
single
document
at
this
point.
The
document
is
work
in
progress.
Submitter(s)
Reviewer(s)
Tracker
Issue
ID
Category
Class
Status
Target
Users
Motivation
Expected
Devices
Expected
Data
Dependencies
-
Affected
WoT
deliverables
and/or
work
items
Description
Sync
of
media
across
different
devices:
people
in
different
homes
watch
the
same
content
at
the
same
time.
Conversation
about
content.
Multi-room
sync
playback
Multi-camera
angles
Voice
control
of
a
media
playback
device
(integration
of
smart
speakers
from
multiple
vendors)
Describe
proprietary
(vendor
specific)
device
control
interfaces
to
control
media
playback
on
TV
set.
(proprietary
implementations
exist,
open
protocol
is
proposed?)
Variants
Gaps
Editor's
note
TODO:
Provide
links
to
relevant
standards
that
are
relevant
for
this
use
case
Existing
standards
&
related
information
Editor's
note
TODO:
Provide
links
to
relevant
standards
that
are
relevant
for
this
use
case.
There
are
MANY
TV
standards
and
this
would
be
a
long
list.
Rather
leave
blank
unless
a
very
specific
standard
provides
more
insight.
A
lot
of
home
devices,
such
as
TV,
cleaner,
and
home
lighting,
connect
to
an
IP
network.
When
you
watch
a
content
program,
these
devices
should
coorperate
for
enhancing
your
expereence.
If
the
cleaning
robot
makes
a
loud
noise
while
watching
the
TV
program,
it
will
hinder
viewing.
Also,
even
if
you
set
up
the
theater
environment
with
smart
lights,
it
is
troublesome
to
operate
it
yourself
each
time
the
TV
program
switches.
Therefore,
by
WoT
device
to
operate
in
accordance
with
the
TV
program
being
viewed,
thereby
improving
the
user
experience.
WoT
devices
work
according
to
TV
programs:
Cleaning
robot
stops
at
an
important
situation,
Color
of
smart
lights
are
changed
according
to
TV
programs,
Smart
Mirror
is
notified
that
favorite
TV
show
will
start.
Expected
Devices
Hybridcast
TV
Hybridcast
Connect
application
(in
a
smartdevice
such
as
smartphone)
Cleaning
Robot
Smart
Light
(such
as
Philips
Hue)
Smart
Mirror
Expected
Data
The
trigger
value
of
the
scene
of
the
TV
program.
Hybridcast
connect
application
know
the
Thing
Description
of
the
devices
in
home.
(Discovery?)
Dependencies
Description
Home
smart
devices
behave
according
to
TV
programs.
Hybridcast
applications
in
TV
emit
information
about
TV
programs
for
smart
home
devices.
(Hybridcast
is
a
Japanese
Integrated
Broadcast-Broadband
system.
Hybridcast
applications
are
HTML5
applications
that
work
on
Hybridcast
TV.)
Hybridcast
Contact
application
receives
the
information
and
controlls
smart
home
devices.
Agricultural
corporation,
Farmer,
Manufacturers
(Sensor,
other
facilities),
Cloud
provider
Motivation
Greenhouse
Horticulture
controlled
by
computers
can
create
an
optimal
environment
for
growing
plants.
This
enables
to
improve
productivity
and
ensure
stable
vegetable
production
throughout
the
year,
independent
of
the
weather.
This
is
the
result
of
research
on
the
growth
of
plants
in
the
1980s.
For
example,
in
tomatoes,
switching
to
hydroponics
and
optimizing
the
temperature,
humidity
and
CO2
concentration
required
for
photosynthesis
resulted
in
a
five
times
increase
in
yield.
The
growth
conditions
for
other
vegetables
also
have
been
investigated,
and
this
control
system
is
applied
now.
Expected
Devices
Sensors
(
temperature,
humidity,
brightness,
UV
brightness,
air
pressure,
and
CO2)
Heating,
CO2
generator,
open
and
close
sunlight
shielding
sheet.
Expected
Data
Sensors’
values
to
clarify
the
gaps
between
conditions
for
maximizing
photosynthesis
and
the
current
environment.
Following
sensors
values
at
one
or
some
points
in
the
greenhouse:
temperature,
humidity,
brightness,
and
CO2.
Dependencies
WoT
Architecture、WoT
Thing
Description
Description
Sensors
and
some
facilities
like
heater,
CO2
generator,
sheet
controller
are
connected
to
the
gateway
via
wired
or
wireless
networks.
The
gateway
is
connected
to
the
cloud
via
the
Internet.
All
sensors
and
facilities
can
be
accessed
and
controlled
from
the
cloud.
To
maximize
photosynthesis,
the
temperature,
CO2
concentration,
and
humidity
in
the
greenhouse
are
mainly
controlled.
When
the
sunlight
comes
in
the
morning
and
CO2
concentration
inside
decreases,
the
application
turns
on
the
CO2
generator
to
keep
over
400
ppm,
the
same
as
the
air
outside.
The
temperature
in
the
greenhouse
is
adjusted
by
controlling
the
heater
and
the
sunlight
shielding
sheet.
The
cloud
gathers
all
sensor
data
and
the
status
of
the
facilities.
The
application
makes
the
best
configuration
for
the
region
of
the
greenhouse
located.
Variants
Gaps
In
the
case
of
the
wireless
connection
to
the
sensors,
the
gateway
should
keep
the
latest
value
of
the
sensors
since
the
wireless
connection
is
sometimes
broken.
The
gateway
can
create
a
virtual
entity
corresponding
to
the
sensor
and
allow
the
application
to
access
this
virtual
entity
having
the
actual
sensor
status
like
sleeping.
Existing
standards
Comments
4.3.2
Smart
Agriculture:
open-field
agriculture
Submitter(s)
Cristiano
Aguzzi
Reviewer(s)
Tracker
Issue
ID
Category
Smart
Agriculture
Class
Open
field
agriculture
Status:
WIP
Target
Users
Agricultural
corporation,
Farmer,
Manufacturers
(Sensor,
other
facilities),
Cloud
provider,
Middleware
provider,
Network
providers,
service
provider.
Motivation
Water
is
vital
for
ensuring
food
security
to
the
world’s
population,
and
agriculture
is
the
biggest
consumer
amounting
for
70%
of
freshwater.
Field
irrigation
application
methods
are
one
of
the
main
causes
of
water
wastage.
The
most
common
technique,
surface
irrigation,
wastes
a
high
percentage
of
the
water
by
wetting
areas
where
no
plants
benefit
from
it.
On
the
other
hand,
localized
irrigation
can
use
water
more
efficiently
and
effectively,
avoiding
both
under-irrigation
and
over-irrigation.
However,
in
an
attempt
to
avoid
under-irrigation,
farmers
feed
more
water
than
is
needed
resulting
not
only
to
productivity
losses,
but
also
water
wastages.
Therefore,
technology
should
be
developed
and
deployed
for
sensing
water
needs
and
automatically
manage
water
supply
to
crops.
However,
open
field
agriculture
is
characterized
by
a
quite
dynamic
range
of
requirements.
Usually,
solutions
developed
for
one
particular
crop
type
cannot
be
reused
in
other
cultivations.
Moreover,
the
same
field
can
have
different
crop
types
or
different
sizes/shapes
during
the
years,
meaning
that
technology
to
monitor
the
state
of
crop
growth
should
be
highly
configurable
and
adaptive.
Even
agriculture
and
irrigation
methods
can
change
and
also
they
are
very
different
depending
on
the
size
of
the
field
and
its
clime
type.
Consequently,
silos
applications
are
deployed
leveraging
on
IoT
technologies
to
gather
data
about
the
crop
growth
state
and
irrigation
needs.
The
Web
of
Things
may
help
to
create
a
single
platform
where
cost-effective
applications
could
adapt
seamlessly
between
different
scenarios,
breaking
the
silos
and
giving
value
both
to
the
environment
and
the
market.
Expected
Devices
Sensors:
Weather
sensors
(maybe
collected
together
inside
a
weather
station
)
temperature
air
humidity
air
pressure
pluviometer
global
solar
radiation
anemometer
(wind
speed)
wind
direction
global
solar
radiation
and
photosynthetically
active
radiation
gas/air
quality
sensor
(i.e.
CO2)
Soil
sensors
(usually
packed
together
in
soil
probes)
soil
temperature
soil
moisture/water
content
soil
conductivity
(detecting
salt
levels
in
the
soil)
water
table
sensor
Drone
sensors
camera
temperature
sensitive
camera
multispectral
camera
Actuators:
drones:
used
for
data
collection
or
pesticed/impollination
sprinklers
pumps
central
pivot
sprinklers
hose-reel
irrigation
machine
Additional
devices:
Solar
panels
Loggers:
units
that
collect
data
from
close
sensors.
Gateways
Expected
Data
Sensor
data
plays
a
central
role
in
Smart
Agriculture.
In
particular,
it
is
critical
that
the
information
sensed
is
associated
with
a
timestamp.
Common
algorithms
use
*time
series*
to
calculate
the
water
needs
of
a
crop.
Furthermore,
soil
sensors
usually
are
calibrated
over
a
specific
soil
type
(which
may
differ
even
in
the
same
geographic
region).
For
example,
the
calibration
data
for
a
soil
moisture
sensor
is
represented
by
a
function
that
maps
sensor
output
to
soil
water
content.
In
literature,
this
function
is
knowns
as
a
*calibration
curve*.
Commercial
sensors
are
precalibrated
with
a
"standard"
curve
but
on
most
occasions,
it
fails
to
accurately
measure
the
water
content.
Therefore,
it
can
be
configured
during
the
installation
phase
(which
may
happen
every
time
the
soil
is
plowed).
Finally,
a
crucial
aspect
is
forecasting.
Farmers
use
this
information
to
actively
change
their
management
procedures.
Services
exploit
it
to
suggest
irrigation
schedule
or
change
device
settings
to
behave
accordingly
to
environmental
changes.
To
summarize
here
it
is
a
list
of
most
important
expected
data
from
Open
field
agriculture:
Calibration
curve
Time
series
Forecast
data
Geolocations:
sensor
data
must
be
contextualized
in
geolocation.
Also,
geolocation
is
critical
in
massive
open
fields
to
localize
instrument
position.
Weather
data
Unit
of
measure:
commercial
soli
sensor
may
output
their
value
in
a
different
unit
of
measures
(i.e.
volts
or
%
water
in
an
m^3
of
soil)
Relative
values
Depth
position:
geolocation
is
not
sufficient
to
describe
the
parameters
of
the
soil.
Depth
is
an
additional
context
that
should
be
added
to
an
observed
value.
Device
owner
information
Battery
level
and
energy
consumption
Dependencies
WoT
Architecture,
WoT
Thing
Description
Description
In
open-field
agriculture,
the
IoT
solutions
leverage
on
different
radio
protocols
and
devices.
Usually,
radio
protocols
should
cover
long
distances
(even
kilometers)
and
be
energy
efficient.
Devices
too
need
to
be
energy
saving
as
they
are
deployed
for
months
and
sometimes
even
years
in
harsh
environments.
A
sleeping-cycle
is
one
mechanism
they
use
to
save
energy
usually
coordinated
by
*loggers/gateways*
or
preprogrammed.
*Loggers*
are
deployed
closed
to
sensor
devices
and
have
more
storage
space.
They
serve
as
buffers
between
sensors
and
higher
services.
Often
*loggers*
and
sensors
are
embedded
in
the
same
board,
otherwise,
they
are
connected
using
cables
or
close-ranged
radio
protocols.
On
the
other
hand,
*gateways*
serve
as
a
collection
point
for
data
of
an
entire
field
or
farm.
They
are
much
more
capable
devices
and
usually
are
more
energy-consuming.
In
some
deployment
scenarios,
they
host
a
full
operating
system
with
multiple
software
facilities
installed.
Otherwise,
gateways
only
serve
as
relays
of
data
sent
from
the
loggers
and
sensors
to
cloud
services
and
vice-versa.
The
cloud
services
may
be
partially
hosted
in
edge
servers
to
preserve
data
privacy
and
responsiveness
of
the
whole
IoT
solution.
Possible
cloud
services
are:
Weather
forecasting/local
weather
forecasting
Soil
digital
twin
to
simulate
and
predict
water
content
Plant
digital
twin
(growth
and
water
needs
prediction)
Irrigation
advice
service:
combining
the
previous
services
and
knowing
the
irrigation
system
topology
is
possible
to
advise
farms
with
the
best
times
to
irrigate
a
crop.
Pesticide
and
fertilize
planning
The
complete
deployment
topology
of
an
open
field
agriculture
solution
is
described
in
the
diagram
below:
Variants
Open-field
agriculture
varies
a
lot
between
geographical
location
and
methods.
For
example
in
the
SWAMP
project
there
three
different
pilots
with
different
requirement/constraints:
Efficient
localized
irrigation
and
application
of
the
right
amount
of
water
to
the
crop
arid
location
The
goal
is
to
minimize
water
consumption
but
maintaining
a
good
field
yield.
Gaps
Currently,
there
is
no
specification
on
how
to
model
device
status
(i.e.
connected/disconnected)
Examples
of
how
to
handle
a
device
calibration
phase
may
help
developers
to
use
a
standardized
approach.
Possibly
define
standard
links
types
to
define
the
relation
between
loggers
and
sensors
Handle
both
geographical
position
and
depth
information.
Ontology
class
for
battery
and
energy
consumption
Model
historical
and
forecast
data
This
use
case
is
designed
using
the
experience
gained
in
the
European-Brazil
Horizon
2020
SWAMP
project.
Please
follow
the
link
for
further
information.
Since
SWAMP
is
heavily
oriented
to
optimize
water
consumption,
this
document
just
mentioned
issues
like
plant
feeding,
fertilizing,
pollination,
yield
prediction,
crop
quality
measurement,
etc.
Nevertheless,
WoT
technologies
may
be
employed
also
in
these
scenarios.
4.3.3
Irrigation
in
outdoor
environment
Submitter(s)
Catherine
Roussey,
INRAE
[1],
France
Jean-Pierre
Chanet,
INRAE
[1],
France
Reviewer(s)
Tracker
Issue
ID
Category
Class
Status
Target
Users
device
users:
farmers
service
provider
Motivation
Depending
on
the
type
of
crops
(e.g.
maize),
cultivated
plots
may
need
specific
irrigation
processes
in
outdoor
environments.
Depending
on
the
country
there
exist
some
specific
pedo-climatic
conditions
and
some
water
consumption
restrictions.
Thus
an
irrigation
system
is
installed
on
the
plot.
It
is
used
on
a
several
days
basis
(e.g.
every
7
days),
for
each
plot.
The
goal
is
to
optimize
the
irrigation
decision
based
on
the
crop
development
stage
and
the
quantity
of
rain
that
has
already
fallen
down
on
the
plot.
For
example
an
important
rain
may
postpone
the
irrigation
decision.
This
use
case
aims
to
evaluate
the
number
of
days
to
delay
the
irrigation
system,
in
addition
to
the
basis
irrigation
frequency
(e.g.
2
delay
days
means
9
days
between
two
irrigations).
Expected
Devices
6
tensiometers
in
the
plot
(soil
moisture):
3
tensiometers
at
30
cm
depth
3
tensiometer
at
60
cm
depth
1
weather
station:
thermometer
(outdoor
temperature)
pluviometer
(rain
quantity)
1
mobile
pluviometer
(quantity
of
water
provided
by
the
watering
system)
Expected
Data
To
decide
when
to
water
a
cultivated
plot,
we
evaluate
the
crop
growth
stage,
the
root
zone
moisture
level
and
the
number
of
delay
days:
To
evaluate
the
Crop
growth
stage
,
we
need:
Min
and
max
temperature
per
day:
the
min
temperature
per
day
is
evaluated
on
the
period
[d-1
18:00,
d
18:00[.
The
*max
temperature
per
day
is
evaluated
on
the
period
[d
06:00:00,
d+1
06:00:00[.i
Growing
degree
day
values
uses
min
and
max
temperature
per
day,
the
sowing
day
and
the
type
of
seed.
The
Growing
degree
day
is
compared
to
some
thresholds
to
evaluate
the
crop
growth
stage
To
evaluate
the
Root
zone
moisture
level
,
we
need:
Mean
moisture
per
day
per
probe:
in
order
to
get
reliable
values,
each
tensiometer
sends
several
measurements
of
soil
moisture,
at
fixed
hours
of
the
day
(usually
in
the
morning),
that
are
aggregated;
their
mean
value
is
considered
For
the
set
of
3
tensiometers
localised
at
the
same
level
of
depth,
the
median
value
is
evaluated
from
their
mean
per
day
moisture
measurements.
One
tensiometer
may
not
provide
accurate
values
(the
soil
around
the
probe
is
too
dry
and
the
soil
matter
is
not
connected
to
the
probe).
The
median
value
of
three
different
tensiometers
at
the
same
depth
will
improve
the
accuracy
of
the
moisture
measurement.
Then
the
sum
of
the
two
median
values
at
two
different
depths
is
evaluated,
to
take
into
account
the
quantity
of
water
available
in
the
root
zone
volume.
This
aggregated
value
estimates
the
root
zone
moisture
level.
The
root
zone
moisture
level
is
compared
to
some
thresholds
(dependent
on
the
crop
growth
stage)
to
evaluate
if
the
crop
needs
water
or
not
at
the
end
of
the
basis
irrigation
period.
To
determine
the
number
of
delay
days
,
we
need:
The
time
period
between
two
waterings
of
the
same
plot
is
dependent
on
the
farm
and
known
by
the
farmer.
When
a
watering
is
launched,
no
new
watering
should
be
planned
during
the
basic
irrigation
frequency.
The
quantity
of
rain
that
falls
down
on
the
plot
may
postpone
the
watering
plan.
The
total
quantity
of
rain
per
day
is
compared
to
some
thresholds
to
determine
the
number
of
delay
days.
The
mobile
pluviometer
is
used
to
validate
that
the
quantity
of
water
received
by
the
crop
actually
corresponds
to
the
quantity
of
water
provided
by
the
watering
system.
At
the
end,
the
farmer
may
decide
if
he
follows
the
irrigation
recommendations
or
not.
He
could
force
the
watering
for
one
of
the
next
days.
Dependencies
-
Affected
WoT
deliverables
and/or
work
items
WoT
Architecture:
wireless
communication
in
outdoor
environments
presents
some
issues:
communication
consumes
lots
of
energy,
sensor
nodes
have
limited
energy,
weather
conditions
impact
communication
quality
WoT
Thing
Description:
the
affordance
should
be
precise
enough
to
describe
the
soil
at
a
specific
depth
or
the
root
zone
volume
or
the
min
temperature
per
day
Description
To
avoid
Property
right
and
consent
management
issues
between
farmers
and
cloud
service
providers
on
these
computed
data,
sensors
are
connected
to
the
farm
infrastructure
and
the
services
that
evaluate
aggregated
data
are
executed
locally
on
this
infrastructure.
The
weather
station
may
be
located
outside
of
the
farm.
The
tensiometers
are
located
inside
the
farm.
The
tensiometers
and
the
mobile
pluviometer
are
connected
using
wireless
communication
to
the
gateway.
The
gateway
sends
the
measurements
to
the
farm
infrastructure.
Variants:
The
crop
growth
stage
may
be
observed
by
the
farmer.
In
this
case,
he
can
force
this
value
to
update
the
service
inputs.
Security
Considerations
The
6
tensiometers
and
1
pluviometer
are
installed
on
the
plot,
but
only
the
farmer
should
be
able
to
change
their
configurations
(frequency
of
communication).
Wireless
communication
should
be
used
but
the
measurement
data
should
only
be
accessible
through
the
farm
network
infrastructure.
Privacy
Considerations
Data
concerning
quantity
of
water,
type
of
seed,
sowing
day
should
be
protected.
Gaps
The
main
potential
issues
come
from
tensiometers
located
in
the
plot,
as
they
are
known
to
be
cheap
and
easy
to
use
probes
but
not
always
reliable.
They
can
face
multiple
issues:
if
the
soil
gets
too
dry
or
the
probe
is
improperly
installed,
there
may
be
air
between
the
probe
and
the
soil,
therefore
preventing
the
probe
from
providing
accurate
conductivity
measurements.
To
be
sure
of
the
quality
of
those
measurements
each
tensiometer
sends
its
measurements
several
times
(3
to
5)
per
day.
The
tensiometer
may
send
an
inappropriate
value
due
to
the
bad
connexion
between
the
soil
and
the
probe,
that
is
the
reason
why
three
tensiometers
are
used
and
the
median
value
is
computed.
If
the
gateway
does
not
receive
the
value
of
one
sensor
during
a
whole
day,
an
alert
should
be
sent.
To
take
an
irrigation
decision,
at
least
one
measurement
per
sensor
and
per
day
should
be
provided.
The
gateway
can
create
a
virtual
entity
corresponding
to
the
sensor
and
allow
the
application
to
access
this
virtual
entity
having
the
actual
sensor
status
like
sleeping.
Sensor
nodes
deployed
in
outdoor
environments
may
take
into
account
that
their
energy
supply
device
(battery,
solar
panel)
constrains
the
lifetime
of
the
device.
Thus
they
should
be
able
to
alert
that
they
may
not
be
able
to
provide
a
service
due
to
lack
of
energy
or
they
should
be
able
to
change
their
configuration
and
switch
communication
protocols
to
save
as
much
energy
as
possible.
Moreover
wireless
communication
can
be
impacted
by
weather
conditions
or
any
outdoor
conditions.
For
example
a
tractor
that
comes
too
close
to
the
sensor
node
may
move
the
communication
device
and
destroy
some
components.
Some
kind
of
network
supervision
must
be
achieved
(for
instance
by
the
gateway)
to
check
node
availability.
This
use
case
has
been
implemented
in
France,
following
local
conditions
and
regulations.
There
exists
an
open
manual
irrigation
decision
method
called
IRRINOV®
developed
by
Arvalis
[2]
and
INRAE
dedicated
to
France
and
some
specific
crops:
maize,
wheat
and
cereals,
potatoes
and
beans.
IRRINOV®
can
be
automated
using
wireless
sensor
networks
and
semantic
web
technologies.
The
considered
network
is
of
star
type:
all
sensors
can
communicate
with
a
common
gateway,
which
is
connected
to
the
Internet.
The
IRRINOV®
implementation
was
developed
in
[3].
This
work
presents
an
expert
system
for
maize
using
drools.
It
automates
the
irrigation
decision
for
maize
based
on
sensor
measurements.
To
measure
weather
properties,
we
use
the
recommendation
provided
by
the
French
National
Weather
Institute:
Météo
France[4].
Its
web
site
defines
how
to
evaluate
the
min
and
max
temperatures
per
day
in
http://www.meteofrance.fr/publications/glossaire/154123-temperature-minimale
(in
French,
we
found
no
equivalent
description
in
English).
Agricultural
corporation,
Farmer,
Manufacturers
(Sensor,
other
facilities),
Cloud
provider,
Middleware
provider,
Network
providers,
service
provider.
Motivation
Water
is
vital
for
ensuring
food
security
to
the
world’s
population,
and
agriculture
is
the
biggest
consumer
amounting
for
70%
of
freshwater.
Field
irrigation
application
methods
are
one
of
the
main
causes
of
water
wastage.
The
most
common
technique,
surface
irrigation,
wastes
a
high
percentage
of
the
water
by
wetting
areas
where
no
plants
benefit
from
it.
On
the
other
hand,
localized
irrigation
can
use
water
more
efficiently
and
effectively,
avoiding
both
under-irrigation
and
over-irrigation.
However,
in
an
attempt
to
avoid
under-irrigation,
farmers
feed
more
water
than
is
needed
resulting
not
only
to
productivity
losses,
but
also
water
wastages.
Therefore,
technology
should
be
developed
and
deployed
for
sensing
water
needs
and
automatically
manage
water
supply
to
crops.
However,
open
field
agriculture
is
characterized
by
a
quite
dynamic
range
of
requirements.
Usually,
solutions
developed
for
one
particular
crop
type
cannot
be
reused
in
other
cultivations.
Moreover,
the
same
field
can
have
different
crop
types
or
different
sizes/shapes
during
the
years,
meaning
that
technology
to
monitor
the
state
of
crop
growth
should
be
highly
configurable
and
adaptive.
Even
agriculture
and
irrigation
methods
can
change
and
also
they
are
very
different
depending
on
the
size
of
the
field
and
its
clime
type.
Consequently,
silos
applications
are
deployed
leveraging
on
IoT
technologies
to
gather
data
about
the
crop
growth
state
and
irrigation
needs.
The
Web
of
Things
may
help
to
create
a
single
platform
where
cost-effective
applications
could
adapt
seamlessly
between
different
scenarios,
breaking
the
silos
and
giving
value
both
to
the
environment
and
the
market.
Expected
Devices
Sensors:
Weather
sensors
(maybe
collected
together
inside
a
weather
station
)
temperature
air
humidity
air
pressure
pluviometer
global
solar
radiation
anemometer
(wind
speed)
wind
direction
global
solar
radiation
and
photosynthetically
active
radiation
gas/air
quality
sensor
(i.e.
CO2)
Soil
sensors
(usually
packed
together
in
soil
probes)
soil
temperature
soil
moisture/water
content
soil
conductivity
(detecting
salt
levels
in
the
soil)
water
table
sensor
Drone
sensors
camera
temperature
sensitive
camera
multispectral
camera
Actuators:
drones:
used
for
data
collection
or
pesticed/impollination
sprinklers
pumps
central
pivot
sprinklers
hose-reel
irrigation
machine
Additional
devices:
Solar
panels
Loggers:
units
that
collect
data
from
close
sensors.
Gateways
Expected
Data
Sensor
data
plays
a
central
role
in
Smart
Agriculture.
In
particular,
it
is
critical
that
the
information
sensed
is
associated
with
a
timestamp.
Common
algorithms
use
*time
series*
to
calculate
the
water
needs
of
a
crop.
Furthermore,
soil
sensors
usually
are
calibrated
over
a
specific
soil
type
(which
may
differ
even
in
the
same
geographic
region).
For
example,
the
calibration
data
for
a
soil
moisture
sensor
is
represented
by
a
function
that
maps
sensor
output
to
soil
water
content.
In
literature,
this
function
is
knowns
as
a
*calibration
curve*.
Commercial
sensors
are
precalibrated
with
a
"standard"
curve
but
on
most
occasions,
it
fails
to
accurately
measure
the
water
content.
Therefore,
it
can
be
configured
during
the
installation
phase
(which
may
happen
every
time
the
soil
is
plowed).
Finally,
a
crucial
aspect
is
forecasting.
Farmers
use
this
information
to
actively
change
their
management
procedures.
Services
exploit
it
to
suggest
irrigation
schedule
or
change
device
settings
to
behave
accordingly
to
environmental
changes.
To
summarize
here
it
is
a
list
of
most
important
expected
data
from
Open
field
agriculture:
Calibration
curve
Time
series
Forecast
data
Geolocations:
sensor
data
must
be
contextualized
in
geolocation.
Also,
geolocation
is
critical
in
massive
open
fields
to
localize
instrument
position.
Weather
data
Unit
of
measure:
commercial
soli
sensor
may
output
their
value
in
a
different
unit
of
measures
(i.e.
volts
or
%
water
in
an
m^3
of
soil)
Relative
values
Depth
position:
geolocation
is
not
sufficient
to
describe
the
parameters
of
the
soil.
Depth
is
an
additional
context
that
should
be
added
to
an
observed
value.
Device
owner
information
Battery
level
and
energy
consumption
Dependencies
WoT
Architecture,
WoT
Thing
Description
Description
In
open-field
agriculture,
the
IoT
solutions
leverage
on
different
radio
protocols
and
devices.
Usually,
radio
protocols
should
cover
long
distances
(even
kilometers)
and
be
energy
efficient.
Devices
too
need
to
be
energy
saving
as
they
are
deployed
for
months
and
sometimes
even
years
in
harsh
environments.
A
sleeping-cycle
is
one
mechanism
they
use
to
save
energy
usually
coordinated
by
*loggers/gateways*
or
preprogrammed.
*Loggers*
are
deployed
closed
to
sensor
devices
and
have
more
storage
space.
They
serve
as
buffers
between
sensors
and
higher
services.
Often
*loggers*
and
sensors
are
embedded
in
the
same
board,
otherwise,
they
are
connected
using
cables
or
close-ranged
radio
protocols.
On
the
other
hand,
*gateways*
serve
as
a
collection
point
for
data
of
an
entire
field
or
farm.
They
are
much
more
capable
devices
and
usually
are
more
energy-consuming.
In
some
deployment
scenarios,
they
host
a
full
operating
system
with
multiple
software
facilities
installed.
Otherwise,
gateways
only
serve
as
relays
of
data
sent
from
the
loggers
and
sensors
to
cloud
services
and
vice-versa.
The
cloud
services
may
be
partially
hosted
in
edge
servers
to
preserve
data
privacy
and
responsiveness
of
the
whole
IoT
solution.
Possible
cloud
services
are:
Weather
forecasting/local
weather
forecasting
Soil
digital
twin
to
simulate
and
predict
water
content
Plant
digital
twin
(growth
and
water
needs
prediction)
Irrigation
advice
service:
combining
the
previous
services
and
knowing
the
irrigation
system
topology
is
possible
to
advise
farms
with
the
best
times
to
irrigate
a
crop.
Pesticide
and
fertilize
planning
The
complete
deployment
topology
of
an
open
field
agriculture
solution
is
described
in
the
diagram
below:
Variants
Open-field
agriculture
varies
a
lot
between
geographical
location
and
methods.
For
example
in
the
SWAMP
project
there
three
different
pilots
with
different
requirement/constraints:
Efficient
localized
irrigation
and
application
of
the
right
amount
of
water
to
the
crop
arid
location
The
goal
is
to
minimize
water
consumption
but
maintaining
a
good
field
yield.
Gaps
Currently,
there
is
no
specification
on
how
to
model
device
status
(i.e.
connected/disconnected)
Examples
of
how
to
handle
a
device
calibration
phase
may
help
developers
to
use
a
standardized
approach.
Possibly
define
standard
links
types
to
define
the
relation
between
loggers
and
sensors
Handle
both
geographical
position
and
depth
information.
Ontology
class
for
battery
and
energy
consumption
Model
historical
and
forecast
data
This
use
case
is
designed
using
the
experience
gained
in
the
European-Brazil
Horizon
2020
SWAMP
project.
Please
follow
the
link
for
further
information.
Since
SWAMP
is
heavily
oriented
to
optimize
water
consumption,
this
document
just
mentioned
issues
like
plant
feeding,
fertilizing,
pollination,
yield
prediction,
crop
quality
measurement,
etc.
Nevertheless,
WoT
technologies
may
be
employed
also
in
these
scenarios.
4.4
Smart
City
4.4.1
Smart
City
Geolocation
Submitter(s)
Jennifer
Lin
(GovTech
Singapore),
Michael
McCool
Reviewer(s)
Michael
Lagally
Tracker
Issue
ID
Category
Class
Status
Target
Users
A
Smart
City
managing
mobile
devices
and
sensors,
including
passively
mobile
sensor
packs,
packages,
vehicles,
and
autonomous
robots,
where
their
location
needs
to
be
determined
dynamically.
Editor's
note
TODO:
Stakeholders/Users
need
to
be
further
clarified.
They
include
"city
government,
people
counting
service
providers,
police,
network
providers,
...
Motivation
Smart
Cities
need
to
track
a
large
number
of
mobile
devices
and
sensors.
Location
information
may
be
integrated
with
a
logistics
or
fleet
management
system.
A
reusable
geolocation
module
is
needed
with
a
common
network
interface
to
include
in
these
various
applications.
For
outdoor
applications,
GPS
could
be
used,
but
indoors
other
geolocation
technologies
might
be
used,
such
as
WiFi
triangulation
or
vision-based
navigation
(SLAM).
Therefore
the
geolocation
information
should
be
technology-agnostic.
NOTE:
we
prefer
the
term
"geolocation",
even
indoors,
over
"localization"
to
avoid
confusion
with
language
localization.
Expected
Devices
One
of
the
following:
A
geolocation
system
on
a
personal
device,
such
as
a
smart
phone.
A
geolocation
system
to
be
attached
to
some
other
portable
device.
A
geolocation
system
attached
to
a
mobile
vehicle.
A
geolocation
system
on
a
payload
transported
by
a
vehicle.
A
geolocation
system
on
an
indoor
mobile
robot.
Expected
Data
Sensor
ID
Timestamp
of
last
geolocation
2D
location
typically
latitude
and
longitude
May
also
be
semantic,
i.e.
room
in
a
building,
exit
Optional:
Semantic
location
Possibly
in
addition
to
numerical
lat/long
location.
Altitude
May
also
be
semantic,
i.e.
floor
of
a
building
Heading
Speed
Accuracy
information
Confidence
interval,
e.g.
distance
that
true
location
will
be
within
some
probability.
Gaussian
covariance
matrix
For
each
measurement
For
lat/long,
may
be
a
single
value
(see
web
browser
API;
radius?)
Geolocation
technology
(GPS,
SLAM,
etc).
Note
that
multiple
technologies
might
be
used
together.
Include
parameters
such
as
sample
interval,
accuracy
For
each
geolocation
technology,
data
specific
to
that
technology:
GPS:
NMEA
type
Historical
data
Note:
the
system
should
be
capable
of
notifying
consumers
of
changes
in
location.
This
may
be
used
to
implement
geofencing
by
some
other
system.
This
may
require
additional
parameters,
such
as
the
maximum
distance
that
the
device
may
be
moved
before
a
notification
is
sent,
or
the
maximum
amount
of
time
between
updates.
Notifications
may
be
sent
by
a
variety
of
means,
some
of
which
may
not
be
traditional
push
mechanisms
(for
example,
email
might
be
used).
For
geofencing
applications,
it
is
not
necessary
that
the
device
be
aware
of
the
fence
boundaries;
these
can
be
managed
by
a
separate
system.
Dependencies
node-wot
Description
Smart
Cities
have
the
need
to
observe
the
physical
locations
of
large
number
of
mobile
devices
in
use
in
the
context
of
a
Fleet
or
Logistics
Management
System,
or
to
place
sensor
data
on
a
map
in
a
Dashboard
application.
These
systems
may
also
include
geofencing
notifications
and
mapping
(visual
tracking)
capabilities.
Variants
A
version
of
the
system
may
log
historical
data
so
the
past
locations
of
the
devices
can
be
recovered.
Geolocation
technologies
other
than
GPS
may
be
used.
The
payload
may
contain
additional
information
specific
to
the
geolocation
technology
used.
In
particular,
in
indoor
situations
technologies
such
as
WiFi
triangulation
or
(V)SLAM
may
be
more
appropriate.
Geofencing
may
be
implemented
using
event
notifications
and
will
require
setting
of
additional
parameters
such
as
maximum
distance.
Security
Considerations
High-resolution
timestamps
can
be
used
in
conjunction
with
cache
manipulation
to
access
protected
regions
of
memory,
as
with
the
SPECTRE
exploit.
Certain
geolocation
APIs
and
technologies
can
return
high-resolution
timestamps
which
can
be
a
potential
problem.
Eventually
these
issues
will
be
addressed
in
cache
architecture
but
in
the
meantime
a
workaround
is
to
artificially
limit
the
resolution
of
timestamps.
Privacy
Considerations
Location
is
generally
considered
private
information
when
it
is
used
with
a
device
that
may
be
associated
with
a
specific
person,
such
as
a
phone
or
vehicle,
as
it
can
be
used
to
track
that
person
and
infer
their
activities
or
who
they
associate
with
(if
multiple
people
are
being
tracked
at
once).
Therefore
APIs
to
access
geographic
location
in
sensitive
contexts
are
often
restricted,
and
access
is
allowed
only
after
confirming
permission
from
the
user.
Gaps
There
is
no
standardized
semantic
vocabulary
for
representing
location
data.
Location
data
can
be
point
data,
a
path,
an
area
or
a
volumetric
object.
Location
information
can
be
expressed
using
multiple
standards,
but
the
reader
of
location
data
in
a
TD
or
in
data
returned
by
an
IoT
device
must
be
able
to
unambiguously
describe
location
information.
There
are
both
dynamic
(data
returned
by
a
mobile
sensor)
and
static
(fixed
installation
location)
applications
for
geolocation
data.
For
dynamic
location
data,
some
recommended
vocabulary
to
annotate
data
schemas
would
be
useful.
For
static
location
data,
a
standard
format
for
metadata
to
be
included
in
a
TD
itself
would
be
useful.
Defines
lat/long/alt
coordinate
system
used
by
most
other
geolocation
standards
More
complicated
than
you
would
think
(need
to
deal
with
deviations
of
Earth
from
a
true
sphere,
gravitational
irregularities,
position
of
centroid,
etc.
etc.)
Data
schema
of
updated
proposal
is
similar
to
existing
API,
but
all
elements
are
now
optional
Data
includes
latitude,
longitude,
altitude,
heading,
and
speed
Accuracy
is
included
for
latitude/longitude
(single
number
in
meters,
95%
confidence,
interpretation
a
little
ambiguous,
but
probably
intended
to
be
a
radius)
and
altitude,
but
not
for
heading
or
speed.
See
also
related
issues
such
as
latency
defined
in
SSN
Note
that
accuracy
and
time
are
issues
that
apply
to
all
kinds
of
sensors,
not
just
geolocation.
However,
the
specific
geolocation
technology
of
GPS
is
special
since
it
is
also
a
source
of
accurate
time.
Comments
4.4.2
Interactive
Public
Spaces
Submitter(s)
Michael
McCool
Reviewer(s)
Tracker
Issue
ID
Category
Accessibility
Class
Status
Target
Users
Motivation
Public
spaces
provide
many
opportunities
for
engaging,
social
and
fun
interaction.
At
the
same
time,
preserving
privacy
while
sharing
tasks
and
activities
with
other
people
is
a
major
issue
in
ambient
systems.
These
systems
may
also
deliver
personalized
information
in
combination
with
more
general
services
presented
publicly.
A
trustful
discovery
of
the
services
and
devices
available
in
such
environments
is
a
necessity
to
guarantee
personalization
and
privacy
in
public-space
applications.
Expected
Devices
Public
spaces
supporting
personalizable
services
and
device
access.
Expected
Data
Command
and
status
information
transferred
between
the
personal
mobile
device
application
and
the
public
space's
services
and
devices.
Profile
data
for
user
preferences.
Dependencies
WoT
Thing
Description
WoT
Discovery
Optional:
WoT
Scripting
API
in
application
on
mobile
personal
device
and
possibly
in
IoT
orchestration
services
in
the
public
space.
Description
Interactive
installations
such
as
touch-sensitive
or
gesture-tracking
billboards
may
be
set
up
in
public
places.
Objects
that
present
public
information
(e.g.
a
map
of
a
shopping
mall)
can
use
a
multimodal
interface
(built-in
or
in
tandem
with
the
user's
mobile
devices)
to
simplify
user
interaction
and
provide
faster
access.
Other
setups
can
stimulate
social
activities,
allowing
multiple
people
to
enter
an
interaction
simultaneously
to
work
together
towards
a
certain
goal
(for
a
prize)
or
just
for
fun
(e.g.
play
a
musical
instrument
or
control
a
lighting
exhibition).
In
a
context
where
privacy
is
an
issue
(for
example,
with
targeted/personalized
alerts
or
advertisements),
the
user's
mobile
device
acts
as
a
mediator
for
the
services
running
on
the
public
network.
This
allows
the
user
to
receive
relevant
information
in
the
way
she
sees
fit.
Notifications
can
serve
as
triggers
for
interaction
with
public
devices
and
services
if
the
user
chooses
to
do
so.
Variants
The
user
may
have
additional
mobile
devices
they
want
to
incorporate
into
an
interaction,
for
example
a
headset
acting
as
an
auditory
aid
or
personal
speech
output
device.
Gaps
Data
format
describing
user
interface
preferences.
Existing
standards
This
use
case
is
based
on
MMI
UC
3.1.
Comments
Does
not
include
Requirements
section
from
original
MMI
use
case.
4.4.3
Meeting
Room
Event
Assistance
Submitter(s)
Michael
McCool
Reviewer(s)
Tracker
Issue
ID
Category
Accessibility
Class
Status
Target
Users
Motivation
Expected
Devices
Meeting
space
supporting
personalizable
services
and
device
access.
Expected
Data
Command
and
status
information
transferred
between
the
personal
mobile
device
application
and
the
meeting
space's
services
and
devices.
Profile
data
for
user
preferences.
Dependencies
WoT
Thing
Description
WoT
Discovery
Optional:
WoT
Scripting
API
in
application
on
mobile
personal
device
and
possibly
in
IoT
orchestration
services
in
the
meeting
space.
Description
A
conference
room
where
a
series
of
meetings
will
take
place.
People
can
go
in
and
out
of
the
room
before,
after
and
during
the
meeting.
The
door
is
"touched"
by
a
badge.
An
application
on
the
user's
mobile
device
can
activate
any
available
display
in
the
room
and
the
room
and
can
access
and
receive
notification
from
devices
and
services
in
the
room.
The
chair
of
the
meeting
is
notified
by
a
dynamically
composed
graphic
animation,
audio
notification
or
a
mobile
phone
notification,
about
available
devices
and
services,
and
can
install
applications
indicated
by
links.
The
chair
of
the
meeting
selects
a
setup
procedure
by
text
amongst
the
provided
links.
These
options
could
be,
for
example:
photo
step-by-step
instructions
(smartphone,
HDTV
display,
Web
site),
audio
instructions
(MP3
audio
guide,
room
speakers
reproduction,
HDTV
audio)
or
RFID
enhanced
instructions
(mobile
SmartTag
Reader,
RFID
Reader
for
smartphone).
The
chair
of
the
meeting
chooses
the
room
speakers
reproduction,
then
the
guiding
Service
is
activated
and
he
starts
to
set
the
video
projector.
After
some
attendees
arrive,
the
chair
of
the
meeting
changes
to
the
slide
show
option
and
continues
to
follow
the
instructions
at
the
same
step
it
was
paused
but
with
another
more
private
modality
for
example,
a
smartphone
slideshow.
Variants
The
user
may
have
additional
mobile
devices
they
want
to
incorporate
into
an
interaction,
for
example
a
headset
acting
as
an
auditory
aid
or
personal
speech
output
device.
Gaps
Data
format
describing
user
interface
preferences.
Ability
to
install
applications
based
on
links
that
can
access
IoT
services.
Existing
standards
This
use
case
is
based
on
MMI
UC
3.2.
Comments
Does
not
include
Requirements
section
from
original
MMI
use
case.
4.4.4
Cross-Domain
Discovery
in
a
Smart
Campus
Submitter(s)
Andrea
Cimmino
and
Raúl
García
Castro
Reviewer(s)
Tracker
Issue
ID
Category
Class
Status
Target
Users
device
owners
service
provider
network
operator
(potentially
transparent
for
WoT
use
cases)
directory
service
operator
Motivation
In
this
use
case
a
network
full
of
IoT
devices
is
presented,
in
which
these
devices
are
registered
in
several
Middle-Nodes.
The
challenge
presented
in
this
scenario
is
to
been
able
do
discover
the
different
sensors,
by
issues
a
SPARQL
query,
and
without
having
prior
knowledge
of
where
those
devices
are
allocated.
Therefore,
the
discovery
SPARQL
query
must
start
from
a
specific
Middle-Node
and
reach
all
those
Middle-Nodes
that
are
relevant
to
answer
the
query.
This
scenario
requires
that
discovery
does
not
only
happen
locally
when
a
Middle-Node
receives
the
query
and
checks
if
some
Thing
Description
registered
is
suitable
to
answer
the
query.
Instead,
the
scenario
requires
also
that
the
Middle-Node
forwards
the
query
through
the
network
(topology
conformed
by
the
middle-nodes)
in
order
to
find
those
Middle-Nodes
that
actually
contain
relevant
Thing
Descriptions.
Notice
from
the
following
example
that
the
query
is
not
broadcasted
in
the
network
to
prevent
flooding,
instead
the
Middle-Nodes
follow
some
discovery
heuristic
to
know
where
the
query
should
be
forwarded.
Also,
notice
that
in
this
scenario
not
all
the
Middle-Nodes
have
the
IoT
devices
registered
directly
within,
they
are
Middle-Nodes
collectors,
such
as
Middle-Node
C,
I,
G,
and
D.
Expected
Devices
Any
device
from
the
energy
context
(e.g.,
solar
panels,
smart
plugs,
or
smart
energy
meters),
devices
from
the
building
context
(e.g.,
light
bulbs,
light
switches,
occupancy
sensors,
or
thermostats),
devices
from
the
environmental
context
(e.g.,
soil
moisture,
flood
detection,
or
air
humidity),
devices
from
the
wearables
context
(e.g.,
smart
bands),
and/or
devices
from
the
water
context
(e.g.,
water
valves,
or
water
quality
sensors)
Expected
Data
Data
coming
from
different
contexts,
such
as
Energy,
Building,
Environmental
Wearables
and
Water.
Dependencies
-
Affected
WoT
deliverables
and/or
work
items
Current
WoT-Discovery
approach
Description
A
campus
has
a
wide
range
of
IoT
devices
distributed
across
their
grounds.
These
IoT
devices
belong
to
very
different
domains
in
a
smart
city,
such
as,
energy,
buildings,
environment,
water,
wearable,
etc.
The
IoT
devices
are
distributed
across
the
campus
and
belong
to
different
infrastructures
or
even
to
individuals.
A
sample
topology
of
this
scenario
could
be
the
following:
In
this
scenario,
energy-related
IoT
devices
monitor
the
energy
use
and
income
in
the
campus,
among
other
things.
From
these
measurements,
an
Energy
Management
System
may
predict
a
negative
peak
of
incoming
energy
that
would
entail
the
failure
of
the
whole
system.
In
this
case,
a
Service
or
a
User
needs
to
discover
all
those
IoT
devices
that
are
not
critical
for
the
normal
functioning
of
the
campus
(such
as
indoor
or
outdoor
illumination,
HVAC
systems,
or
water
heaters)
and
interact
with
them
in
order
to
save
energy,
by
switching
them
off
or
reducing
their
consumption.
Besides,
the
same
Service
or
User
will
look
for
those
IoT
devices
that
are
critical
for
the
well-functioning
of
the
campus
(such
as
magnetic
locks,
water
distribution
system,
or
fire/smoke
sensors)
and
ensure
that
they
are
up
and
running.
Additionally,
the
Service
or
the
User,
will
discover
relevant
people's
wearable
to
warn
them
about
the
situation.
Sample
flow:
A
service,
or
a
user,
sends
a
(SPARQL)
query
to
the
discovery
endpoint
of
a
known
Middle-Node
(which
can
be
wrapped
by
a
GUI).
The
Middle-Node
will
try
to
answer
the
query
first
checking
the
Thing
Descriptions
of
the
IoT
devices
registered
in
such
Middle-Node.
Then,
if
the
query
requires
further
discovery,
or
it
was
not
successfully
answered
the
Middle-Node
will
forward
the
query
to
its
*known*
Middle-Nodes.
Recursively,
the
Middle-Nodes
will
try
to
answer
the
query
and/or
forward
the
query
to
their
known
Middle-Nodes.
When
one
Middle-Node
is
able
to
answer
the
query
it
will
forward
back
to
the
former
Middle-Node
the
partial
query
answer.
Finally,
when
the
discovery
task
finishes,
the
former
Middle-Node
will
join
all
the
partial
query
answers
producing
an
unified
view
(which
could
be
synchronous
or
asynchronous).
For
instance,
assuming
Middle-Node
F
receives
a
query
that
asks
about
all
the
discoverable
Building
IoT
devices
in
the
campus.
First,
the
Middle-Node
F
will
try
to
answer
the
query
with
the
Thing
Descriptions
of
the
IoT
registered
within.
Since
Middle-Node
F
contains
some
Building
IoT
devices
a
partial
query
answer
is
achieved.
However,
since
they
query
asked
about
all
the
discoverable
Building
IoT
devices
Middle-Node
F
should
forward
the
query
to
its
other
known
Middle-Nodes,
i.e.,
Middle-Node
G.
This
process
will
be
repeated
by
the
Middle-Nodes
until
the
query
reaches
the
Middle-Nodes
H
and
B
which
are
the
ones
that
have
registered
Thing
Descriptions
about
IoT
buildings.
Therefore,
the
query
will
travel
through
the
topology
as
follows:
Finally,
when
Middle
Nodes
B
and
H
compute
two
partial
query
answers,
those
answers
will
be
forwarded
back
to
Middle-Node
F
which
will
join
them
with
its
former
partial
query
answer
obtained
from
its
registered
Thing
Descriptions.
Finally,
a
global
query
answer
will
be
provided.
Variants
Security
Considerations
None,
in
this
case
an
underneath
infrastructure
that
handles
security
is
assumed
Privacy
Considerations
None,
although
relevant
in
this
case
the
core
of
the
use
case
relies
on
the
feature
of
finding
across
the
network
different
IoT
devices.
It
is
assumed
that
there
is
an
underneath
infrastructure
that
handles
privacy
Gaps
Been
able
to
find
suitable
Middle-Nodes
that
are
relevant
to
answer
the
query,
with
no
prior
knowledge
Existing
standards
None
Comments
None
4.5
Health
4.5.1
Public
Health
4.5.1.1
Public
Health
Monitoring
Submitter(s)
Jennifer
Lin
(GovTech
Singapore)
Reviewer(s)
Michael
McCool,
Michael
Lagally
Tracker
Issue
ID
Category
Class
Status
Target
Users
Agencies,
companies
and
other
organizations
in
a
Smart
City
with
significant
pedestrian
traffic
in
a
pandemic
situation.
Motivation
A
system
to
monitor
the
health
of
people
in
public
places
is
useful
to
control
the
spread
of
infectious
diseases.
In
particular,
we
would
like
to
identify
individuals
with
temperatures
outside
the
norm
(i.e.
running
a
fever)
and
then
take
appropriate
action.
Actions
can
include
sending
a
notification
or
actuating
a
security
device,
such
as
a
gate.
This
mechanism
should
be
non-invasive
and
non-contact
since
the
solution
should
not
itself
contribute
to
the
spread
of
infectious
diseases.
Data
may
also
be
aggregated
for
statistics
purposes,
for
example,
to
identify
the
number
of
people
in
an
area
with
elevated
temperatures.
This
has
additional
requirements
to
avoid
double-counting
individuals.
Expected
Devices
One
of
the
following:
A
thermal
camera.
Face
detection
(AI)
service
May
be
on
device
or
be
an
edge
or
cloud
service.
Optional:
RGB
and/or
depth
camera
registered
with
the
thermal
camera
Cloud
service
for
data
aggregation
and
analytics.
Some
way
to
identify
location
(optional)
Note
that
location
might
be
static
and
configured
during
installation,
but
might
also
be
based
on
a
localization
technology
if
the
device
needs
to
be
portable
(for
example,
if
it
needs
to
be
set
up
quickly
for
an
event).
Expected
Data
Sensor
ID
Timestamp
Number
of
people
identified
with
a
fever
in
image
Estimated
temperature
for
each
person
May
be
coarse,
low/normal/high
Location
Latitude,
Longitude,
Altitude,
Accuracy
Semantic
(eg
a
particular
building
entrance)
Thermal
image
Optional:
RGB
image
Depth
image
Localization
technology
(see
localization
use
case)
Integration
with
local
IoT
devices:
gates,
lights,
or
people
(guards)
Bounding
boxes
around
faces
of
identified
people
in
image(s)
Data
that
can
be
used
to
uniquely
identify
a
face
(distinguish
it
from
others)
Aggregation
system
may
output
the
total
number
of
unique
faces
with
fever
Note
1:
the
system
should
be
capable
of
notifying
consumers
(such
as
security
personnel),
of
fever
detections.
This
may
be
email,
SMS,
or
some
other
mechanism,
such
as
MQTT
publication.
Note
2:
In
all
cases
where
images
are
captured,
privacy
considerations
apply.
It
would
also
be
useful
to
count
unique
individuals
for
statistics
purposes,
but
not
necessarily
based
on
identifying
particular
people.
This
is
to
avoid
counting
the
same
person
multiple
times.
Dependencies
node-wot
Description
A
thermal
camera
image
is
taken
of
a
group
of
people
and
an
AI
service
is
used
to
identify
faces
in
the
image.
The
temperature
of
each
person
is
then
estimated
from
the
registered
face;
for
greater
accuracy,
a
consistent
location
for
sampling
should
be
used,
such
as
the
forehead.
The
estimated
temperature
is
compared
to
high
(and
optionally,
low)
thresholds
and
a
notification
(or
other
action)
is
taken
if
the
temperature
is
outside
the
norm.
Additional
features
may
be
extracted
to
identify
unique
individuals.
Variants
Enough
information
is
included
in
the
notification
that
the
specific
person
that
raised
the
alarm
can
be
identified.
For
example,
if
an
RGB
camera
is
also
registered
with
the
thermal
camera,
then
a
bounding
box
may
be
indicated
via
JSON
and
the
RGB
image
included;
or
the
bounding
box
could
be
actually
drawn
into
the
sent
image,
or
the
face
could
be
cropped
out.
This
is
useful
if,
for
example,
a
notification
needs
to
be
sent
to
health
or
security
workers
who
need
to
identify
the
person
in
a
crowd.
Instead
of
simply
a
notification,
an
action
may
be
taken,
such
as
closing
or
refusing
to
open
a
gate
at
the
entrance
to
a
building,
to
prevent
sick
employees
from
entering
the
building.
To
generate
statistics,
for
example
to
count
the
number
of
people
with
fevers,
then
unique
individuals
need
to
be
indentified
to
avoid
counting
the
same
person
more
than
once.
The
same
sensors
might
be
used
to
determine
the
number
of
people
in
an
area
and
send
a
notification
if
crowded
conditions
are
detected,
in
order
to
support
social
distancing
behaviour
(for
instance,
supporting
an
app
that
notifies
users
when
a
destination
is
crowded)
in
a
pandemic
situation.
Cameras
that
provide
video
streams
rather
than
still
images.
Security
Considerations
Because
PII
is
involved
(see
below)
access
should
be
controlled
(only
provided
to
authorized
users)
and
communications
protected
(encrypted).
Privacy
Considerations
Images
of
people
and
their
health
status
is
involved.
If
later
these
are
made
public
then
the
health
information
of
a
particular
person
would
be
released
publically.
There
is
also
the
possibility
that
the
camera
data
could
be
in
error,
and
should
be
confirmed
with
a
more
accurate
sensor.
This
information
needs
to
be
treated
as
PII
and
protected:
only
distributed
to
authorized
users,
and
deleted
when
no
longer
needed.
However,
derived
aggregate
information
can
be
kept
and
published.
Gaps
Onboarding
mechanism
for
rapidly
deploying
a
large
number
of
devices
Standard
vocabulary
for
geolocation
information
Implementations
able
to
handle
image
payload
formats,
possibly
in
combination
with
non-image
data
(eg
images
and
JSON
in
a
single
response)
Video
streaming
support
(if
we
wish
to
serve
video
stream
from
the
camera
instead
of
still
images)
Standard
ways
to
specify
notification
mechanisms
and
data
payloads
for
things
like
SMS
and
email
(in
addition
to
the
expected
MQTT,
CoAP,
and
HTTP
event
mechanisms)
Existing
standards
Comments
May
be
additional
requirements
for
privacy
since
images
of
people
and
their
health
status
is
involved.
Different
sub-use
cases:
immediate
alerts
or
actions
vs.
aggregate
data
gathering
4.5.1.2
Interconnected
medical
devices
in
a
hospital
ICU
Submitter(s)
Taki
Kamiya
Reviewer(s)
Tracker
Issue
ID
Category
Class
Status
Target
Users
device
owners
device
user
cloud
provider
service
provider
device
manufacturer
gateway
manufacturer
identity
provider
Motivation
Preventable
medical
errors
may
account
for
more
than
100,000
deaths
per
year
in
U.S.
alone.
These
errors
are
mainly
caused
by
failures
of
communication
such
as
a
chart
misread
or
the
wrong
data
passed
along
to
machines
or
staffs.
Part
of
the
problem
could
be
solved
if
the
machines
could
speak
to
one
another.
Manufacturers
have
little
incentive
to
make
their
proprietary
code
and
data
easily
to
accessible
and
process
able
by
their
competitors’
machines.
So
the
task
of
middleman
falls
to
the
hospital
staffs.
In
addition
to
saving
lives,
a
common
framework
could
result
in
collecting
and
recording
more
clinical
data
on
patients,
making
it
easier
to
deliver
precision
medicine.
Expected
Devices
Expected
Data
Dependencies
-
Affected
WoT
deliverables
and/or
work
items
Description
Physiological
Closed-Loop
Control
(PCLC)
devices
are
a
group
of
emerging
technologies,
which
use
feedback
from
physiological
sensor(s)
to
autonomously
manipulate
physiological
variable(s)
through
delivery
of
therapies
conventionally
delivered
by
clinician(s).
Clinical
scenario
without
PCLC.
An
elderly
female
with
end-stage
renal
failure
was
given
a
standard
insulin
infusion
protocol
to
manage
her
blood
glucose,
but
no
glucose
was
provided.
Her
blood
glucose
dropped
to
33,
then
rebounded
to
over
200
after
glucose
was
given.
This
scenario
has
not
changed
for
decades.
The
desired
state
with
PCLC
implemented
in
an
ICU.
A
patient
is
receiving
an
IV
insulin
infusion
and
is
having
the
blood
glucose
continuously
monitored.
The
infusion
pump
rate
is
automatically
adjusted
according
to
the
real-time
blood
glucose
levels
being
measured,
to
maintain
blood
glucose
values
in
a
target
range.
If
the
patient’s
glucose
level
does
not
respond
appropriately
to
the
changes
in
insulin
administration,
the
clinical
staff
is
alerted.
Medical
devices
do
not
interact
with
each
other
autonomously
(monitors,
ventilator,
IV
pumps,
etc.)
Contextually
rich
data
is
difficult
to
acquire.
Technologies
and
standards
to
reduce
medical
errors
and
improve
efficiency
have
not
been
implemented
in
theater
or
at
home.
In
recent
years,
researchers
have
made
progress
developing
PCLC
devices
for
mechanical
ventilation,
anesthetic
delivery
applications,
and
so
on.
Despite
these
promises
and
potential
benefits,
there
has
been
limited
success
in
the
translation
of
PCLC
devices
from
bench
to
bedside
.
A
key
challenge
to
bringing
PCLC
devices
to
a
level
required
for
a
clinical
trials
in
humans
is
risk
management
to
ensure
device
reliability
and
safety.
The
United
States
Food
and
Drug
Administration
(FDA)
classifies
new
hazards
that
might
be
introduced
by
PCLC
devices
into
three
categories.
Besides
clinical
factors
(e.g.
sensor
validity
and
reliability,
inter-
and
intra-patient
physiological
variability)
and
usability/human
factors
(e.g.
loss
of
situational
awareness,
errors,
and
lapses
in
operation),
there
are
also
engineering
challenges
including
robustness,
availability,
and
integration
issues.
Variants
US
military
developed
ONR
SBIR
(Automated
Critical
Care
System
Prototype),
and
found
those
issues.
No
plug
and
play,
i.e.
cannot
swap
O2
Sat
with
another
manufacturer.
No
standardization
of
data
outputs
for
devices
to
interoperate.
Must
have
the
exact
make/model
to
replace
a
faulty
device
or
system
will
not
work.
Security
Considerations
Security
considerations
for
interconnected
and
dynamically
composable
medical
systems
are
critical
not
only
because
laws
such
as
HIPAA
mandate
it,
but
also
because
security
attacks
can
have
serious
safety
consequences
for
patients.
The
systems
need
to
support
automatic
verification
that
the
system
components
are
being
used
as
intended
in
the
clinical
context,
that
the
components
are
authentic
and
authorized
for
use
in
that
environment,
that
they
have
been
approved
by
the
hospital’s
biomedical
engineering
staff
and
that
they
meet
regulatory
safety
and
effectiveness
requirements.
For
security
and
safety
reasons,
ICE
F2761-09(2013)
compliant
medical
devices
never
interact
directly
each
other.
All
interaction
is
coordinated
and
controlled
via
the
applications.
While
transport-level
security
such
as
TLS
provides
reasonable
protection
against
external
attackers,
they
do
not
provide
mechanisms
for
granular
access
control
for
data
streams
happening
within
the
same
protected
link.
Transport-level
security
is
also
not
sufficiently
flexible
to
balance
between
security
and
performance.
Another
issue
with
widely
used
transport-level
security
solutions
is
the
lack
of
support
for
multicast.
Privacy
Considerations
Editor's
note
TODO:
Describe
any
issues
related
to
privacy;
if
there
are
none,
say
"none"
and
justify
References
Editor's
note
TODO:
Provide
links
to
relevant
standards
that
are
relevant
for
this
use
case
Gaps
Multicast
support.
It
has
proven
useful
for
efficient
and
scalable
discovery
and
information
exchange
in
industrial
systems.
Medical
Devices
and
Medical
Systems
-
Essential
safety
requirements
for
equipment
comprising
the
patient-centric
integrated
clinical
environment
(ICE)
-
Part
1:
General
requirements
and
conceptual
model.
The
idea
behind
ICE
is
to
allow
medical
devices
that
conform
to
the
ICE
standard,
either
natively
or
using
an
adapter,
to
interoperate
with
other
ICE-compliant
devices
regardless
of
manufacturer.
MDIRA
Version
1.0
provides
requirements
and
implementation
guidance
for
MDIRA-compliant
systems
focused
on
trauma
and
critical
care
in
austere
environments.
Johns
Hopkins
University
Applied
Physics
Laboratory
(JHU-APL)
lead
a
research
project
in
collaboration
with
US
military
to
develop
a
framework
of
autonomous
/
closed
loop
prototypes
for
military
health
care
which
are
dual
use
for
the
civilian
healthcare
system.
Comments
4.5.2
Private
Health
4.5.2.1
Health
Notifiers
Submitter(s)
Michael
McCool
Reviewer(s)
Tracker
Issue
ID
Category
Accessibility
Class
Status
Target
Users
End
user
with
a
health
problem
they
wish
to
monitor.
Health
services
provider
(doctor,
nurse,
paramedic,
etc).
Motivation
In
critical
situations
regarding
health,
like
a
medical
emergency,
media
multimodality
may
be
the
most
effective
way
to
communicate
alerts,
When
the
goal
is
to
monitor
the
health
evolution
of
a
person
in
both
emergency
and
non-emergency
contexts,
access
via
networked
devices
may
be
the
most
effective
way
to
collect
data
and
monitor
a
patient's
status.
Expected
Devices
Medical
facilities
supporting
device
and
service
access.
Expected
Data
Command
and
status
information
transferred
between
the
personal
mobile
device
application
and
the
meeting
space's
services
and
devices.
Profile
data
for
user
preferences.
Dependencies
WoT
Thing
Description
WoT
Discovery
Optional:
WoT
Scripting
API
in
application
on
mobile
personal
device
and
possibly
in
IoT
orchestration
services.
Description
In
medical
facilities,
a
system
may
provide
multiple
options
to
control
sensor
operations
by
voice
or
gesture
("start
reading
my
blood
pressure
now").
These
interactions
may
be
mediated
by
an
application
installed
into
a
smartphone.
The
system
integrates
information
from
multiple
sensors
(for
example,
blood
pressure
and
heart
rate);
reports
medical
sensor
readings
periodically
(for
example,
to
a
remote
medical
facility)
and
sends
alerts
when
unusual
readings/events
are
detected.
Variants
The
user
may
have
additional
mobile
devices
they
want
to
incorporate
into
an
interaction,
for
example
a
headset
acting
as
an
auditory
aid
or
personal
speech
output
device.
Gaps
Data
format
describing
user
interface
preferences.
Ability
to
install
applications
based
on
links
that
can
access
IoT
services.
Existing
standards
This
use
case
is
based
on
MMI
UC
3.2.
Comments
Does
not
include
Requirements
section
from
original
MMI
use
case.
4.6
Manufacturing
4.6.1
Big
Data
for
Manufacturing
Submitter(s)
Michael
Lagally
Reviewer(s)
Tracker
Issue
ID
Category
Class
Status
Target
Users
Device
owners,
cloud
provider.
Motivation
Production
lines
for
industrial
manufacturing
consist
of
multiple
machines,
where
each
machine
incorporates
sensors
for
various
values.
A
failure
of
a
single
machine
can
cause
defective
products
or
a
stop
of
the
entire
production.
Big
data
analysis
enables
to
identify
behavioral
patterns
across
multiple
production
lines
of
the
entire
production
plant
and
across
multiple
plants.
The
results
of
this
analysis
can
be
used
for
optimizing
consumption
of
raw
materials,
checking
the
status
of
production
lines
and
plants
and
predicting
and
preventing
fault
conditions.
Expected
Devices
Various
sensors,
e.g.
temperature,
light,
humidity,
vibration,
noise,
air
quality.
Expected
Data
Discrete
sensor
values,
such
as
temperature,
light,
humidity,
vibration,
noise,
air
quality
readings.
The
data
can
be
delivered
periodically
or
on
demand.
Dependencies
Thing
Description:
groups
of
devices,
aggregation
/
composition
mechanism,
thing
models
Discovery/Onboarding:
Onboarding
of
groups
of
devices
Description
A
company
owns
multiple
factories
which
contain
multiple
production
lines.
Examples
are
production
lines,
environment
sensors,
These
devices
collect
data
from
multiple
sensors
and
transmit
this
information
to
the
cloud.
Sensor
data
is
stored
in
the
cloud,
can
be
visualized
and
analyzed
using
machine
learning
/
AI.
The
cloud
service
allows
to
manage
single
and
groups
of
devices.
Combining
the
data
streams
from
multiple
devices
allows
to
get
an
easy
overview
of
the
state
of
all
connected
devices
in
the
user's
realm.
In
many
cases
there
are
groups
of
devices
of
the
same
kind,
so
the
aggregation
of
data
across
devices
can
serve
to
identify
anomalies
or
to
predict
impending
outages.
The
cloud
service
allows
to
manage
single
and
groups
of
devices
and
can
help
to
identify
abonormal
conditions.
For
this
purpose
a
set
of
rules
can
be
defined
by
the
user,
which
raises
alerts
towards
the
user
or
triggers
actions
on
devices
based
on
these
rules.
This
enables
the
early
detection
of
pending
problems
and
reduces
the
risk
of
machine
outages,
quality
problems
or
threats
to
the
environment
or
life
of
humans.
Variants
Gaps
Existing
standards
Editor's
note
TODO:
Provide
links
to
relevant
standards
that
are
relevant
for
this
use
case
Comments
See
also
Digital
Twin
use
case.
4.6.2
Multi-Vendor
System
Integration
4.6.2.1
Out
of
the
box
interoperability
Submitter(s)
Michael
Lagally
Reviewer(s)
All
WoT
members,
specifically
Sebastian
Kaebisch,
Michael
McCool,
Ege
Korkan,
Zoltan
Kis,
Takuki
Kamiya,
Ryuichi
Matsukura,
Kunihiko
Toumura,
Michael
Koster.
Tracker
Issue
ID
Category
Class
Status
Target
Users
device
owner
service
provider
cloud
provider
device
manufacturer
gateway
manufacturer
Motivation
As
an
device
owner,
I
want
to
know
whether
a
device
will
work
with
my
system
before
I
purchase
it
to
avoid
wasting
money.
Installers
of
IoT
devices
want
to
be
able
to
determine
if
a
given
device
will
be
compatible
with
the
rest
of
their
installed
systems
and
whether
they
will
have
access
to
its
data
and
affordances.
As
a
developer,
I
want
TDs
to
be
as
simple
as
possible
so
that
I
can
efficiently
develop
them.
Here
"simple"
should
relate
to
the
end
goal,
"efficiently
develop";
that
is,
TDs
should
be
straightforward
for
the
average
developer
to
complete
and
validate.
As
a
developer,
I
want
to
be
able
to
validate
that
a
Thing
will
be
compatible
with
a
Consumer
without
having
to
test
against
every
possible
consumer.
As
a
cloud
provider
I
want
to
onboard,
manage
and
communicate
with
as
many
devices
as
possible
out
of
the
box.
This
should
be
possible
without
device
specific
customization.
Dependencies
-
Affected
WoT
deliverables
and/or
work
items
WoT
Profile,
WoT
Thing
Description
Description
As
a
consumer
of
devices
I
want
to
be
able
to
process
data
from
any
device
that
conforms
to
a
class
of
devices.
I
want
to
have
a
guarantee
that
I'm
able
to
correctly
interact
with
all
affordances
of
the
Thing
that
complies
with
this
class
of
devices.
Behavioral
ambiguities
between
different
implementations
of
the
same
description
should
not
be
possible.
I
want
to
integrate
it
into
my
existing
scenarios
out
of
the
box,
i.e.
with
close
to
zero
configuration
tasks.
Variants
N/A
Gaps
Editor's
note
TODO:
Describe
any
gaps
that
are
not
addressed
in
the
current
WoT
standards
and
building
blocks
References
Editor's
note
TODO:
Provide
links
to
relevant
standards
that
are
relevant
for
this
use
case
A
digital
twin
is
the
virtual
representation
of
a
physical
asset
such
as
a
machine,
a
vehicle,
robot,
sensor.
Using
a
digital
twin
allows
businesses
to
analyze
their
physical
assets
to
troubleshoot
in
real
time,
predict
future
problems,
minimize
downtime,
and
perform
simulations
to
create
new
business
opportunities.
A
digital
twin
may
also
be
called
a
twin
or
a
shadow.
Digital
twin
technology
may
be
referred
to
as
device
virtualization.
Digital
twins
can
be
located
in
the
edge
or
in
the
cloud.
Expected
Devices
Various
devices
such
as
sensors,
machines,
vehicles,
production
lines,
industry
robots.
Digital
twin
platforms
at
the
edge
or
in
the
cloud.
Expected
Data
Machine
status
information,
discrete
sensor
data
or
data
streams.
Dependencies
WoT
Architecture
WoT
Thing
Description
WoT
Profile
WoT
Scripting?
Description
The
user
benefits
from
using
digital
twins
with
the
following
scenarios:
Better
visibility:
Continually
view
the
operations
of
the
machines
or
devices,
and
the
status
of
their
interconnected
systems.
Accurate
prediction:
Retrieve
the
future
state
of
the
machines
from
the
digital
twin
model
by
using
modeling.
What-if
analysis:
Easily
interact
with
the
model
to
simulate
unique
machine
conditions
and
perform
what-if
analysis
using
well-designed
interfaces.
Documentation
and
communication:
Use
of
the
digital
twin
model
helps
to
understand,
document,
and
explain
the
behavior
of
a
specific
machine
or
a
collection
of
machines.
Integration
of
disparate
systems:
Connect
with
back-end
applications
related
to
supply
chain
operations
such
as
manufacturing,
procurement,
warehousing,
transportation,
or
logistics.
Variants
Virtual
Twin
The
virtual
twin
is
a
representation
of
a
physical
device
or
an
asset.
A
virtual
twin
uses
a
model
that
contains
observed
and
desired
attribute
values
and
also
uses
a
semantic
model
of
the
behavior
of
the
device.
Intermittent
connectivity:
An
application
may
not
be
able
to
connect
to
the
physical
asset.
In
such
a
scenario,
the
application
must
be
able
to
retrieve
the
last
known
status
and
to
control
the
operation
states
of
other
assets.
Protocol
abstraction:
Typically,
devices
use
a
variety
of
protocols
and
methods
to
connect
to
the
IoT
network.
From
a
users
perspective
this
complexity
should
not
affect
other
business
applications
such
as
an
enterprise
resource
planning
(ERP)
application.
Business
rules:
The
user
can
specify
the
normal
operating
range
of
a
property
in
a
semantic
model.
Business
rules
can
be
declaratively
defined
and
actions
can
be
automatically
invoked
in
the
edge
or
on
the
device.
Example:
In
a
fleet
of
connected
vehicles,
the
user
monitors
a
collection
of
operating
parameters,
such
as
fuel
level,
location,
speed
and
others.
The
semantics-based
virtual
twin
model
enables
the
user
to
decide
whether
the
operating
parameters
are
in
normal
range.
In
out
of
range
conditions
the
user
can
take
appropriate
actions.
Predictive
Twin
In
a
predictive
twin,
the
digital
twin
implementation
builds
an
analytical
or
statistical
model
for
prediction
by
using
a
machine-learning
technique.
It
need
not
involve
the
original
designers
of
the
machine.
It
is
different
from
the
physics-based
models
that
are
static,
complex,
do
not
adapt
to
a
constantly
changing
environment,
and
can
be
created
only
by
the
original
designers
of
the
machine.
A
data
analyst
can
easily
create
a
model
based
on
external
observation
of
a
machine
and
can
develop
multiple
models
based
on
the
user’s
needs.
The
model
considers
the
entire
business
scenario
and
generates
contextual
data
for
analysis
and
prediction.
When
the
model
detects
a
future
problem
or
a
future
state
of
a
machine,
the
user
can
prevent
or
prepare
for
them.
The
user
can
use
the
predictive
twin
model
to
determine
trends
and
patterns
from
the
contextual
machine
data.
The
model
helps
to
address
business
problems.
Twin
Projections
In
twin
projections,
the
predictions
and
the
insights
integrate
with
back-end
business
applications,
making
IoT
an
integral
part
of
business
processes.
When
projections
are
integrated
with
a
business
process,
they
can
trigger
a
remedial
business
workflow.
Prediction
data
offers
insights
into
the
operations
of
machines.
Projecting
these
insights
into
the
back-end
applications
infrastructure
enables
business
applications
to
interact
with
the
IoT
system
and
transform
into
intelligent
systems.
Gaps
WoT
does
not
define
a
way
to
describe
the
behavior
of
a
thing
to
use
for
a
simulation.
Existing
standards
Editor's
note
TODO:
Provide
links
to
relevant
standards
that
are
relevant
for
this
use
case
Comments
4.6.4
Cross
Protocol
Interworking
Submitter(s)
Michael
Lagally
Reviewer(s)
Ege
Korkan,
Michael
McCool,
Michael
Koster,
Sebastian
Käbisch
Tracker
Issue
ID
Category
Class
Status
Target
Users
Device
owners,
cloud
providers.
Motivation
In
smart
city,
home
and
industrial
scenarios
various
devices
are
connected
to
a
common
network.
These
devices
implement
different
protocols.
To
enable
interoperability,
an
"agent"
needs
to
communicate
across
different
protocols.
Platforms
for
this
agent
can
be
edge
devices,
gateways
or
cloud
services.
Interoperability
across
protocols
is
a
must
for
all
user
scenarios
that
integrate
devices
from
more
than
one
protocol.
Expected
Devices
Various
sensors,
e.g.
temperature,
light,
humidity,
vibration,
noise,
air
quality,
edge
devices,
gateways,
cloud
servers
and
services.
Expected
Data
Discrete
sensor
values,
such
as
temperature,
light,
humidity,
vibration,
noise,
air
quality
readings.
A/V
streams.
The
data
can
be
delivered
periodically
or
on
demand.
Dependencies
WoT
Profiles.
Description
There
are
multiple
user
scenarios
that
are
addressed
by
this
use
case.
An
example
in
the
smart
home
environment
is
an
automatic
control
lamps,
air
conditioners,
heating,
window
blinds
in
a
household
based
on
sensor
data,
e.g.
sunlight,
human
presence,
calendar
and
clock,
etc.
In
an
industrial
environment
individual
actuators
and
production
devices
use
different
protocols.
Examples
include
MQTT,
OPC-UA,
Modbus,
Fieldbus,
and
others.
Gathering
data
from
these
devices,
e.g.
to
support
digital
twins
or
big
data
use
cases
requires
an
"Agent"
to
bridge
across
these
protocols.
To
provide
interoperability
and
to
reduce
implementation
complexity
of
this
agent
a
common
set
of
(minimum
and
maximum)
requirements
need
to
be
supported
by
all
interoperating
devices.
A
smart
city
environment
is
similar
to
the
industrial
scenario
in
terms
of
device
interoperability.
Devices
differ
however,
they
include
smart
traffic
lights,
traffic
monitoring,
people
counters,
cameras.
Variants
Gaps
A
common
profile
across
protocols
is
required
to
address
this
use
case.
Existing
standards
MQTT,
OPC-UA,
BACNet,
CoAP,
various
other
home
and
industrial
protocols.
Comments
4.7
Multimodal
System
Integration
4.7.1
Multimodal
Recognition
Support
Submitter(s)
Michael
McCool
Reviewer(s)
Tracker
Issue
ID
Category
Accessibility
Class
Status
Target
Users
Motivation
Recognizer
system
development
has
arrived
at
a
point
of
maturity
where
if
we
want
to
dramatically
enhance
recognition
performance,
sensor
fusion
from
multiple
modalities
is
needed.
In
order
to
achieve
this,
an
image
recognizer
should
incorporate
results
coming
from
other
kinds
of
recognizers
(e.g.
audio
recognizer)
within
the
network
engaged
in
the
same
interaction
cycle.
Expected
Devices
Audio
sensing
device
(microphone).
Video
sensing
device
(camera).
Audio
recognition
service.
Video
recognition
service.
Devices
capabale
of
presenting
alerts
in
various
modalities.
Expected
Data
Command
and
status
information
transferred
between
the
sensing
devices,
the
recognition
services,
and
the
alert
devices.
Profile
data
for
user
preferences.
Dependencies
WoT
Thing
Description
WoT
Discovery
Optional:
WoT
Scripting
API
in
application
on
mobile
personal
device
and
possibly
in
IoT
orchestration
services.
Description
An
audio
recognizer
has
been
trained
with
the
more
common
sounds
in
the
house,
in
order
to
provide
alerts
in
case
of
an
emergency.
In
the
same
house
a
security
system
uses
a
video
recognizer
to
identify
people
at
the
front
door.
These
two
systems
need
to
cooperate
with
a
remote
home
management
system
to
provide
integrated
services.
Variants
Gaps
Support
for
video
and
audio
recognition
services.
Existing
standards
This
use
case
is
based
on
MMI
UC
5.1.
Comments
Does
not
include
Requirements
section
from
original
MMI
use
case.
4.7.2
Enhancement
of
Synergistic
Interactions
Submitter(s)
Michael
McCool
Reviewer(s)
Tracker
Issue
ID
Category
Accessibility
Class
Status
Target
Users
Motivation
One
of
the
main
indicators
concerning
the
usability
of
a
system
is
the
corresponding
level
of
accessibility
provided
by
it.
The
opportunity
for
all
the
users
to
receive
and
to
deliver
all
kinds
of
information,
regardless
of
the
information
format
or
the
type
of
user
profile,
state
or
impairment
is
a
recurrent
need
in
web
applications.
One
of
the
means
to
achieve
accessibility
is
the
design
of
a
more
synergic
interaction
based
on
the
discovery
of
multimodal
Modality
Components.
Synergy
is
two
or
more
entities
functioning
together
to
produce
a
result
that
is
not
obtainable
independently.
It
means
"working
together".
For
example,
how
to
avoid
disruptive
interactions
in
nomadic
systems
(always
affected
by
the
changing
context)
is
an
important
issue.
In
these
applications,
user
interaction
is
difficult,
distracted
and
less
precise.
Discovery
and
use
of
alternative
input
and
output
devices
can
increase
synergic
interaction
offering
new
possibilities
more
adapted
to
the
current
context.
Such
a
system
can
also
enhance
the
fusion
process
for
target
groups
of
users
experiencing
permanent
or
temporary
learning
difficulties
or
with
sensorial,
emotional
or
social
impairments.
Expected
Devices
A
normal
client
computer
with
I/O
devices
that
need
to
be
emulated.
Alternative
I/O
devices
that
need
to
be
interfaced
to
the
client
system.
Expected
Data
Command
and
status
information
transferred
between
the
client
computer
and
the
alternative
I/O
devices.
Profile
data
for
user
preferences.
Dependencies
WoT
Thing
Description
WoT
Discovery
Optional:
WoT
Scripting
API
in
application
on
mobile
personal
device
and
possibly
in
IoT
orchestration
services.
Description
A
person
working
mostly
with
a
PC
is
having
a
problem
with
his
right
arm
and
hands.
He
is
unable
to
use
a
mouse
or
a
keyboard
for
a
few
months.
He
can
point
at
things,
sketch,
clap,
make
gestures,
but
he
can
not
make
any
precise
movements.
A
generic
interface
allows
this
person
to
perform
his
most
important
tasks
in
his
personal
devices:
to
call
someone,
open
a
mailbox,
access
his
agenda
or
navigate
over
some
Web
pages.
The
generic
interface
can
propose
child-oriented
intuitive
interfaces
like
a
clapping-based
interface,
a
very
articulated
TTS
component,
or
reduced
gesture
input
widgets.
Other
specialized
devices
might
include
phones
with
very
big
numbers,
very
simple
remote
controls,
screens
displaying
text
at
high
resolution,
or
voice
command
devices.
Variants
Gaps
Existing
standards
This
use
case
is
based
on
MMI
UC
5.2.
Comments
Does
not
include
Requirements
section
from
original
MMI
use
case.
4.8
Accessibility
4.8.1
Audiovisual
Devices
Acting
as
Smartphone
Extensions
Submitter(s)
Michael
McCool
Reviewer(s)
Tracker
Issue
ID
Category
Accessibility
Class
Status
Target
Users
Motivation
Many
of
today's
home
IoT-enabled
devices
can
provide
similar
functionality
(e.g.
audio/video
playback),
differing
only
in
certain
aspects
of
the
user
interface.
This
use
case
would
allow
continuous
interaction
with
a
specific
application
as
the
user
moves
from
room
to
room,
with
the
user
interface
switched
automatically
to
the
set
of
devices
available
in
the
user's
present
location.
On
the
other
hand,
some
devices
can
have
specific
capabilities
and
user
interfaces
that
can
be
used
to
add
information
to
a
larger
context
that
can
be
reused
by
other
applications
and
devices.
This
drives
the
need
to
spread
an
application
across
different
devices
to
achieve
a
more
user-adapted
and
meaningful
interaction
according
to
the
context
of
use.
Both
aspects
provide
arguments
for
exploring
use
cases
where
applications
use
distributed
multimodal
interfaces.
Expected
Devices
Mobile
phone
or
other
client
running
an
application
requiring
a
extended
and
more
accessible
user
interface.
IoT-enabled
audio-visual
devices
providing
audio
and
visual
information
display
capabilities
that
can
be
used
to
augment
the
user
interface
of
the
application.
Possible
edge
computation
services
providing
speech-to-text
or
described
video
(e.g.
object
detection)
capabilities.
Expected
Data
Visual
display
information
mapping
information
from
audio
to
visual
modalities,
for
example
text
generated
from
voice
recognition.
Text
from
an
application
that
needs
to
be
displayed
at
a
larger
size.
Visual
alerts
correspondig
to
audio
stimuli,
eg
sound
effects
in
a
game
mapped
to
visual
icons.
Visual
information
mapped
to
audio
information,
for
example,
described
video
based
on
an
AI
service
providing
object
recognition.
Dependencies
WoT
Thing
Description
WoT
Discovery
Optional:
WoT
Scripting
API
accessible
from
application
for
interacting
with
devices.
Description
A
home
entertainment
system
is
adapted
by
a
mobile
device
as
a
set
of
user
interface
components.
In
addition
to
media
rendering
and
playback,
these
Devices
also
act
as
input
or
output
modalities
for
an
application,
for
example
an
application
running
on
a
smartphone.
The
native
user
interface
on
the
application
does
not
have
to
be
manipulated
directly
at
all.
A
wall-mounted
touch-sensitive
TV
could
be
used
to
navigate
applications,
and
a
wide-range
microphone
can
handle
speech
input.
Spatial
(Kinect-style)
gestures
may
also
be
used
to
control
application
behavior.
Accessibility
support
software
on
the
smartphone
discovers
available
modalities
and
arranges
them
to
best
serve
the
user's
purpose.
One
display
can
be
used
to
show
photos
and
movies,
another
for
navigation.
As
the
user
walks
into
another
room,
this
configuration
is
adapted
dynamically
to
the
new
location.
User
intervention
may
be
sometimes
required
to
decide
on
the
most
convenient
modality
configuration.
The
state
of
the
interaction
is
maintained
while
switching
between
modality
sets.
For
example,
if
the
user
was
navigating
a
GUI
menu
in
the
living
room,
it
is
carried
over
to
another
screen
when
she
switches
rooms,
or
replaced
with
a
different
modality
such
as
voice
if
there
are
no
displays
in
the
new
location.
Variants
Modalities
may
be
translated
from
one
form
to
another
to
accomodate
accessibility
issues,
for
example,
visual
cues
into
audio
cues
and
vice-versa,
as
appropriate.
Gaps
An
AI
service
may
be
require
to
perform
modality
mapping,
for
example,
object
recognition.
Existing
standards
This
use
case
is
based
on
MMI
UC
1.1.
Comments
Does
not
include
Requirements
section
from
original
MMI
use
case.
Variant
supporting
modality
conversion
is
not
included
in
the
original
MMI
use
case.
4.8.2
Unified
Smart
Home
Control
and
Status
Interface
Submitter(s)
Michael
McCool
Reviewer(s)
Tracker
Issue
ID
Category
Accessibility
Class
Status
Target
Users
Motivation
The
increase
in
the
number
of
controllable
devices
in
an
intelligent
home
creates
a
problem
with
controlling
all
available
services
in
a
coherent
and
useful
manner.
Having
a
shared
context,
built
from
information
collected
through
sensors
and
direct
user
input,
would
improve
recognition
of
user
intent,
and
thus
simplify
interactions.
In
addition,
multiple
input
mechanisms
could
be
selected
by
the
user
based
on
device
type,
level
of
trust
and
the
type
of
interaction
required
for
a
particular
task.
Expected
Devices
Mobile
phone
or
other
client
running
an
application
providing
command
mediation
capabilities.
IoT-enabled
smart
home
devices
supporting
remote
sensing
and
actuation
functionality.
Expected
Data
Command
and
status
information
transferred
between
the
command
mediation
application
and
one
or
more
devices.
Dependencies
WoT
Thing
Description
WoT
Discovery
Optional:
WoT
Scripting
API
accessible
from
application
for
interacting
with
devices.
Description
Smart
home
functionality
(window
blinds,
lights,
air
conditioning
etc.)
is
controlled
through
a
multimodal
interface,
composed
from
modalities
built
into
the
house
itself
(e.g.
speech
and
gesture
recognition)
and
those
available
on
the
user's
personal
devices
(e.g.
smartphone
touchscreen).
The
system
may
automatically
adapt
to
the
preferences
of
a
specific
user,
or
enter
a
more
complex
interaction
if
multiple
people
are
present.
Sensors
built
into
various
devices
around
the
house
can
act
as
input
modalities
that
feed
information
to
the
home
and
affect
its
behavior.
For
example,
lights
and
temperature
in
the
gym
room
can
be
adapted
dynamically
as
workout
intensity
recorded
by
the
fitness
equipment
increases.
The
same
data
can
also
increase
or
decrease
volume
and
tempo
of
music
tracks
played
by
the
user's
mobile
device
or
the
home's
media
system.
Variants
The
intelligent
home
in
tandem
with
the
user's
personal
devices
can
additionally
monitor
user
behavior
for
emotional
patterns
such
as
'tired'
or
'busy'
and
adapt
further.
Gaps
A
service
may
be
needed
to
recognize
gestures
and
emotional
states.
Existing
standards
This
use
case
is
based
on
MMI
UC
1.2;
original
title
was
Intelligent
Home
Apparatus.
Comments
Does
not
include
Requirements
section
from
original
MMI
use
case.
4.9
Automotive
4.9.1
Smart
Car
Configuration
Management
Submitter(s)
Michael
McCool
Reviewer(s)
Tracker
Issue
ID
Category
Accessibility
Class
Status
Target
Users
Motivation
User
interface
personalization
is
a
task
that
most
often
needs
to
be
repeated
for
all
Devices
a
user
wishes
to
interact
with
recurringly.
With
complex
devices,
this
task
can
also
be
very
time-consuming,
which
is
problematic
if
the
user
regularly
accesses
similar,
but
not
identical
devices,
as
in
the
case
of
several
cars
rented
over
a
month.
A
standardized
set
of
personal
information
and
preferences
that
could
be
used
to
configure
personalizable
devices
automatically
would
be
very
helpful
for
all
these
cases
in
which
the
interaction
becomes
a
customary
practice.
Expected
Devices
Personal
mobile
device
running
an
application
providing
command
mediation
capabilities.
IoT-enabled
smart
car
supporting
remote
sensing,
actuation,
and
configuration
functionality.
Expected
Data
Command
and
status
information
transferred
between
the
personal
mobile
device
application
and
the
car's
services
and
devices.
Profile
data
for
user
preferences.
Dependencies
WoT
Thing
Description
WoT
Discovery
Optional:
WoT
Scripting
API
in
application
on
mobile
personal
device
and
possibly
in
IoT
orchestration
services
in
the
car.
Description
Basic
in-car
functionality
is
standardized
to
be
managed
by
other
devices.
A
user
can
control
seat,
radio
or
AC
settings
through
a
personalized
multimodal
interface
shared
by
the
car
and
her
personal
mobile
device.
User
preferences
are
stored
on
the
mobile
Device
(or
in
the
cloud),
and
can
be
transferred
across
different
car
models
handling
a
specific
functionality
(e.g.
all
cars
with
touchscreens
should
be
able
to
adapt
to
a
"high
contrast"
preference).
The
car
can
make
itself
available
as
a
complex
modality
component
that
wraps
around
all
functionality
and
supported
modalities,
or
as
a
collection
of
modality
components
such
as
touchscreen,
speech
recognition
system,
or
audio
player.
In
the
latter
case,
certain
user
preferences
may
be
shared
with
other
environments.
For
example,
a
user
may
opt
to
select
the
"high
contrast"
scheme
at
night
on
all
of
her
displays,
in
the
car
or
at
home.
A
car
that
provides
a
set
of
modalities
can
be
also
adapted
by
the
mobile
device
to
compose
an
interface
for
its
functionality,
for
example
to
manage
playback
of
music
tracks
through
the
car's
voice
control
system.
Sensor
data
provided
by
the
phone
can
be
mixed
with
data
recorded
by
the
car's
own
sensors
to
profile
user
behavior
which
can
be
used
as
context
in
multimodal
interaction.
Variants
Additional
portable
devices
may
be
brought
into
the
car
and
also
be
incorporated
into
an
application,
for
example,
a
GPS
navigation
system.
Gaps
Data
format
describing
user
interface
preferences.
Existing
standards
This
use
case
is
based
on
MMI
UC
2.1.
Comments
Does
not
include
Requirements
section
from
original
MMI
use
case.
4.10
Energy
/
Smart
Grids
4.10.1
Smart
Grids
Submitter(s)
Christian
Glomb
(Siemens)
Reviewer(s)
Michael
Lagally
(Oracle)
Tracker
Issue
ID
Category
Class
Status
Target
Users
Grid
operators
on
all
voltage
levels
line
Distribution
System
Operators
(DSO),
Transmission
System
Operators
(TSO)
Plant
operators
(centralized
as
well
as
de-centralized
producers)
Virtual
Power
Plant
(VPP)
operators
Energy
grid
markets
Cloud
providers
where
grid
backend
services
are
hosted
and
where
Operation
Technology
bridges
to
Information
Technology
Device
manufacturers,
owners,
and
users;
devices
include
communication
gateways,
monitoring
and
control
units
Motivation
Expected
Devices
A
smart
grid
integrates
all
players
in
the
electricity
market
into
one
overall
system
through
the
interaction
of
generation,
storage,
grid
management
and
consumption.
Power
and
storage
plants
are
already
controlled
today
in
such
a
way
that
only
as
much
electricity
is
produced
as
is
needed.
Smart
grids
include
consumers
as
well
as
small,
decentralized
energy
suppliers
and
storage
locations
in
this
control
system,
so
that
on
the
one
hand,
consumption
is
more
homogeneous
in
terms
of
time
and
space
(see
also
intelligent
electricity
consumption)
and
on
the
other
hand,
in
principle
inhomogeneous
producers
(e.g.
wind
power)
and
consumers
(e.g.
lighting)
can
be
better
integrated.
Expected
Data
Weather
and
climate
data
Metering
data
(both
production
as
well
as
consumption
as
well
as
storage,
e.g.
15
min.
intervals)
Real
time
data
from
PMUs
(Phasor
Measurement
Units)
Machine
and
equipment
monitoring
data
(enabling
health
checks)
...
Dependencies
-
Affected
WoT
deliverables
and/or
work
items
The
term
Smart
Grid
refers
to
the
communicative
networking
and
control
of
power
generators,
storage
facilities,
electrical
consumers,
and
grid
equipment
in
power
transmission
and
distribution
networks
for
electricity
supply.
This
enables
the
optimization
and
monitoring
of
the
interconnected
components.
The
aim
is
to
secure
the
energy
supply
on
the
basis
of
efficient
and
reliable
system
operation.
Variants
Decentralized
Power
Generation
While
electricity
grids
with
centralized
power
generation
have
dominated
up
to
now,
the
trend
is
moving
towards
decentralized
generation
plants,
both
for
generation
from
fossil
primary
energy
through
small
CHP
plants
and
for
generation
from
renewable
sources
such
as
photovoltaic
systems,
solar
thermal
power
plants,
wind
turbines
and
biogas
plants.
This
leads
to
a
much
more
complex
structure,
primarily
in
the
area
of
load
control,
voltage
maintenance
in
the
distribution
grid
and
maintenance
of
grid
stability.
In
contrast
to
medium
to
large
power
plants,
smaller,
decentralised
generation
plants
also
feed
directly
into
the
lower
voltage
levels
such
as
the
low-voltage
grid
or
the
medium-voltage
grid.
This
use
case
variants
also
includes
operation
and
control
of
energy
storages
like
batteries.
Virtual
Power
Plants
A
Virtual
Power
Plant
(VPP)
is
an
aggregation
of
Distributed
Energy
Resources
(DERs)
that
can
act
as
an
entity
on
energy
markets
or
as
an
ancillary
service
to
grid
operation.
The
individual
DERs
often
have
a
primary
use
on
their
own,
with
electric
generation/consumption
being
a
side-effect
resp.
secondary
use.
This
results
in
negotiations/collaborations
between
many
different
parties
e.g.
such
as
the
DER
owner,
the
VPP
operator,
the
grid
operator
and
others.
Smart
Metering
For
consumers,
a
major
change
is
the
installation
of
smart
meters.
Their
core
tasks
are
remote
reading
and
the
possibility
to
realize
fluctuating
prices
within
a
day
at
short
notice.
All
electricity
meters
must
therefore
be
replaced
by
those
with
remote
data
transmission.
Other
variants
Emergency
response,
grid
synchronization,
grid
black
start
Building
Blocks
Multi-Stakeholder
Operation:
Multiple
involved
parties
have
to
find
a
common
mode
of
operation
Device
Lifecycle
Management:
Since
the
VPP
is
a
dynamic
system
of
loosely
coupled
DERs,
the
appearance
and
disappearance
of
DERs
as
well
as
the
software
management
on
the
devices
itself
requires
a
means
to
orchestrate
the
lifecycle
of
individual
device's
respective
components.
Embedded
Runtime:
Especially
for
DERs
in
remote
locations,
maintaining
a
close
couple
control
loop
can
be
expensive
if
feasible
at
all.
Therefore,
it
is
desirable
to
be
able
to
offload
control
logic
to
the
DER
itself.
Ensemble
Discovery:
In
order
to
dynamically
find
matching
DERs
needed
for
the
operational
goal
of
a
VPP,
a
registry
with
different
options
of
DER
discovery
is
needed.
Content-Negotiation:
The
different
stakeholders
have
to
interact
and
therefore
need
a
common
data
format.
Resource
Description:
The
DER
has
to
describe
itself
to
enable
discovery
of
single
DERs
and
ensembles,
also
the
operational
data
needs
to
be
understood
by
the
different
stakeholders
without
engineering
effort.
Push
Services:
As
there
is
a
fan-out
with
many
devices
that
probably
have
a
rate-limited
connection
connecting
to
one
single
command
centre,
a
bidirectional
communication
mechanism
is
needed
rather
than
polling
for
the
reverse
direction
Object
Memory:
As
multiple
and
interchangable
stakeholders
are
involved
in
the
application,
a
backlog
of
the
object
is
beneficial
for
scrollkeeping
Non-Functionals
Privacy:
As
fine-grained
metering
informtion
provides
sensitive
data
about
a
household,
the
system
should
show
a
high
digree
of
privacy
Trust:
Since
the
data
exchange
between
the
virtual
power
plant
and
the
distributed
energy
resource
leads
to
a
physical
action
that
invokes
high
currents
and
monetary
flows,
the
integrity
of
both
parties
and
the
exchange's
data
is
crucial
Layered
L7
Communication:
Since
multiple
different
links
are
used
for
monitoring
and
control,
integration
requires
a
clear
and
consistent
seperation
of
information
from
the
used
serialization
and
application
protocols
to
enable
the
exchange
of
homogenous
information
over
heterogenous
application
layer
protocols
Gaps
Editor's note
TODO: Provide links to relevant standards that are relevant for this use case
-gaps-x" class="ednote">
Editor's note
TODO: Provide links to relevant standards that are relevant for this use case
: Describe any gaps that are not addressed in the current WoT standards and building blocks
Existing standards
IEC 61850 - International standard for data models and communication protocols IEEE 1547 - US standard for interconnecting distributed resources with electric power systems
Comments
4.11
Transportation
Submitter(s)
Zoltan Kis
Reviewer(s)
Jennifer Lin, Michael McCool
Tracker Issue ID
Category
Class
Status
Sub-categories
Transportation - Infrastructure Transportation - Cargo Transportation - People
Target Users
Smart Cities: managing roads, public transport and commuting, autonomous and human driven vehicles, transportation tracking and control systems, route information systems, commuting and public transport, vehicles, on-demand transportation, self driving fleets, vehicle information and control systems, infrastructure sharing and payment system, smart parking, smart vehicle servicing, emergency monitoring, etc. Transport companies: managing shipping, air cargo, train cargo and last mile delivery transportation systems including automated systems. Commuters: Mobility as a service, booking systems, route planning, ride sharing, self-driving, self-servicing infrastructure, etc.
Motivation
Provide common vocabulary for describing transport related services and solutions that can be reused across sub-categories, for easier interoperability between various systems owned by different stakeholders. Thing models could be defined in many subdomains to help integration or interworking between multiple systems. Transportation of goods can be optimized at global level by enhancing interoperability between vertical systems.
Expected Devices
Road information system (routes, conditions, navigation). Road control system (e.g. virtual rails). Traffic management services, e.g. intelligent traffic light system with localization and identification (by satellite, radio frequency identification, cameras etc). Emergency monitoring and data/location sharing. Airport management. Shipping docks and ports management. Train networks management. Public transport vehicles (train, metro, tram, bus, minibus), mobility as a service (ride sharing, bicycle sharing, scooters etc). Transportation network planning and management (hubs, backbones, sub-networks, last mile network). Electronic timetable management system. Vehicles (human driven, self-driving, isolated or part of fleet). Connected vehicles (cars, ships, airplanes, trains, buses etc).
Expected Data
Vehicle data (identification, location, speed, route, selected vehicle data). Weather and climate data. Contextual data (representing various risk factors, delays, etc).
Transportation system implementers will be able to use a unified data description model accoss various systems.
Variants
There will be different verticals, such as:
Smart City public transport
Smart City traffic management
Smart city vehicle management
Cargo traffic management
Cargo vehicle management
Gaps
Existing standards
Editor's note
TODO: Provide links to relevant standards that are relevant for this use case
Comments
4.12
Building Technologies
4.12.1
Smart Building
Submitter(s)
Sebastian Kaebisch (Siemens)
Reviewer(s)
Michael Lagally (Oracle)
Tracker Issue ID
Category
Class
Status
Target Users
Motivation and Description
Buildings such as office buildings, hotels, airports, hospitals, train stations and sports stadiums typically consist of heterogeneous IoT systems such as lightings, elevators, security (e.g., door control), air-conditionings, fire warnings, heatings, pools, parking control, etc. Monitoring, controlling, and management of such a heterogeneous IoT landscape is quite chellanging in terms of engeneering and maintenance.
Expected Devices
All kind of sensors and actuators (e.g., HVAC).
Expected Users
systems engineers
system administrators
third party user
Expected Data
Hetrogeneos data models from different IoT systems such as BACnet, KNX, and Modbus.
Dependencies - Affected WoT deliverables and/or work items
Construction and renovation companies often deal with the challenge of delivering target energy-efficient buildings given specific budget and time constraints. Energy efficiency, as one of the key factors for renovation investments, depends on the availability of various data sources to support the renovation design and planning. These include climate data and building material along with residential comfort and energy consumption profiles. The profiles are created using a combination of manual inputs and sensory data collected from residents.
Expected Devices
Gateway (e.g. Single-board computer with a Z-Wave controller)
Dependencies - Affected WoT deliverables and/or work items
Description
Renovation of residential buildings to improve energy efficiency depend on a wide range of sensory information to understand the building conditions and consumption models. As part of the pre-renovation activities, the renovation companies deploy various sensors to collect relevant data over a period of time. Such sensors become part of a wireless sensor network (WSN) and expose data endpoint with the help of one or more gateway devices. Depending on the protocols, the endpoints require different interaction flows to securely access the current and historical measurements. The renovation applications need to discover the sensors, their endpoints and how to interact with them based on search criteria such as the physical location, mapping to the building model or measurement type.
Variants
Security Considerations
Privacy Considerations
The TD may expose personal information about the building layout and residents.
Gaps
There is no standard vocabulary for embedding application-specific meta data inside the TD. It is possible to extend the TD context and add additional fields but with too much flexibility, every application may end up with a completely different structure, making such information more difficult to discover. In this use-case, the application specific data are:
the mapping between each thing and the space in the building model
various identifiers for each thing (e.g. sensor serial number, z-wave ID, SenML name)
indoor coordinates
There is no standard API specification for the WoT Thing Directory to maintain and query TDs.
Existing standards
OGC SensorThings
model includes a
properties
property for each Thing which is a non-normative JSON Object for application-specific information (not to be confused with TD's
properties
which is a Map of instances of PropertyAffordance
device owners : The university -> Research Group -> Specific Lab
device user : Students and potentially anyone who participates in plugfests
service provider : The university -> Research Group
network operator : The university
Motivation
This use case motivates a standardized use of shared resources. One example is when a physical resource of the Thing should not be used by multiple Consumers at the same time like the arm of the robot but its position can be read my multiple Consumers.
Expected Devices
Concrete devices are irrelevant for this use case but devices with a physical state is required. However, we have currently the following devices that are connected to Raspberry Pis where the WoT stack (node-wot or similar) is running. Concrete device models can be given upon request.
Robotic arms
Conveyor belts
Motorized sliders where the robots or devices can be mounted on
Philips Hue devices: Light bulbs, LED Strips, Motion sensors, Switch. We do not have the source code of these devices (brownfield)
Various sensors (brightness, humidity, temperature, gyroscopic sensors)
LED Screen to display messages
There are also IP Cameras but they are not WoT compatible and are not planned to be made compatible.
Expected Data
Atmospheric data of a room, machine sensors
Dependencies - Affected WoT deliverables and/or work items
We are offering a practical course for the students where they can interact fully remotely with WoT devices and verify their physical actions via video streams. We have sensors and actuators like robots. Students then build mashup applications to deepen their knowledge of WoT technologies. Official page of the course is
here
.
Variants
Security Considerations
The devices are connected to the Internet and are secured behind a router and proxy.
Privacy Considerations
none from the WoT point of view since we want the devices to be used by anyone and the devices do not share any information that is related to the students or us as the provider of the devices. However, there are cameras which can show humans entering the room as a side effect (they are meant to monitor the devices). The streams are accessible only to authorized users, the room has signs on the door and there is a cage around the area that is filmed.
Gaps
Thing Description
How to give hints that a particular action should not be used by others at the same time. A new keyword (like
"shared":true
) would be needed for devices that do not implement a describable mechanism.
How to describe the mechanism that the Thing implements to manage the shared resources. Does it happen in the security level?
Scripting API
How does the Consumer code change when this mechanism is used. Does it get settled in the implementation or scripting level.
Existing standards
Comments
4.14
Oauth2 Flows
4.14.1
OAuth2 Flows
Submitter(s)
Michael McCool, Cristiano Aguzzi
Reviewer(s)
Tracker Issue ID
Category
Class
Status
WIP
Target Users
device owner
device user
device application
service provider
identity provider
directory service
Motivation
OAuth 2.0 is an authorization protocol widely known for its usage across several web services. It enables third-party applications to obtain limited access to HTTP services on behalf of the resource owner or of itself. The protocol defines the following actors:
Client: an application that wants to use a resource owned by the resource owner.
Authorization Server: An intermediary that authorizes the client for a particular
scope
.
Resource: a web resource
Resource Server: the server where the resource is stored
Resource Owner: the owner of a particular web resource. If it is a human is usually referred to as an end-user. More specifically from the RFC:
An entity capable of granting access to a protected resource.
These actors can be mapped to WoT entities:
Client is a WoT Consumer
Authorization Server is a third-party service
Resource is an interaction affordance
Resource Server is a Thing described by a Thing Description acting as a server.
May be a device or a service.
Resource Owner might be different in each use case. A Thing Description may also combine resources from different owners or web server.
TO DO: Check the OAuth 2.0 spec to determine exactly how Resource Owner is defined. Is it the actual owner of the resource (eg running the web server) or simply someone with the rights to access that resource? The OAuth 2.0 protocol specifies an authorization layer that separates the client from the resource owner. The basic steps of this protocol are summarized in the following diagram:
Steps A and B defines what is known as authorization grant type or flow. What is important to realize here is that not all of these interactions are meant to take place over a network protocol. In some cases, interaction with with a human through a user interface may be intended. OAuth2.0 defines 4 basic flows plus an extension mechanism. The most common of which are:
code
implicit
password
(of resource owner)
client
(credentials of the client)
In addition, a particular extension which is of interest to IoT is the
device
flow. Further information about the OAuth 2.0 protocol can be found in
IETF RFC6749
. In addition to the flows, OAuth 2.0 also supports scopes. Scopes are identifiers which can be attached to tokens. These can be used to limit authorizations to particular roles or actions in an API. Each token carries a set of scopes and these can be checked when an interaction is attempted and access can be denied if the token does not include a scope required by the interaction. This document describes relevant use cases for each of the OAuth 2.0 authorization flows.
Expected Devices
To support OAuth 2.0, all devices must have the capability of:
Both the producer and consumer must be able to create and participate in a TLS connection.
The producer must be able to verify an access (bearer) token (i.e. have sufficient computational power/connectivity).
Comment:
Investigate whether DTLS can be used.
Certainly the connection needs to be encrypted; this is required in the OAuth 2.0 specification.
Investigate whether protocols other than HTTP can be used, e.g. CoAP.
found an interesting IETF draft RFC about CoAP support(encrypted using various mechanisms like DTLS or CBOR Object Signing and Encryption):
draft-ietf-ace-oauth
Expected Data
Depending on the OAuth 2.0 flow specified, various URLs and elements need to be specified, for example, the location of an authorization token server. OAuth 2.0 is also based on bearer tokens and so needs to include the same data as those, for example, expected encryption suite. Finally, OAuth 2.0 supports scopes so these need to be defined in the security scheme and specified in the form.
Dependencies - Affected WoT deliverables and/or work items
Thing Description, Scripting API, Discovery, and Security.
Description
A general use case for OAuth 2.0 is when a WoT consumer wants to access restricted interaction affordances. In particular, when those affordances have a specific resource owner which may grant some temporary permissions to the consumer. The WoT consumer can either be hosted in a remote device or interact directly with the end-user inside an application.
Variants
For each OAuth 2.0 flow, there is a corresponding use case variant. We also include the experimental "device" flow for consideration.
code A natural application of this protocol is when the end-user wants to interact directly with the consumed thing or to grant his authorization to a remote device. In fact from the
RFC6749
Since this is a redirection-based flow, the client must be capable of interacting with the resource owner's user-agent (typically a web browser) and capable of receiving incoming requests (via redirection) from the authorization server.
This implies that the code flow can be only used when the resource owner interacts directly with the WoT consumer at least once. Typical scenarios are:
In a home automation context, a device owner uses a third party software to interact with/orchestrate one or more devices
Similarly, in a smart farm, the device owner might delegate its authorization to third party services.
In a smart home scenario, Thing Description Directories might be deployed using this authorization mechanism. In particular, the list of the registered TDs might require an explicit read authorization request to the device owner (i.e. an human who has bought the device and installed it).
...
The following diagram shows the steps of the protocol adapted to WoT idioms and entities. In this scenario, the WoT Consumer has read the Thing Description of a Remote Device and want to access one of its WoT Affordances protected with OAuth 2.0 code flow.
Notice that steps (A), (B) and (C) are broken in two parts as they pass through the User-Agent.
device
The device flow (IETF
RFC 8628
) is a variant of the code flow for browserless and input-constrained devices. Similarly, to its
parent
flow, it requires a close interaction between the resource owner and the WoT consumer. Therefore, the use cases for this flow are the same as the code authorization grant but restricted to all devices that do not have a rich means to interact with the resource owner. However, differently from
code
, RFC 8628 states explicitly that one of the actors of the protocol is an
end-user
interacting with a
browser
(even if
section-6.2
briefly describes an authentication using a companion app and BLE), as shown in the following (slightly adapted) diagram:
the protocol is heavily end-user oriented. In fact, the RFC states the following
Due to the polling nature of this protocol (as specified in Section 3.4), care is needed to avoid overloading the capacity of the token endpoint. To avoid unneeded requests on the token endpoint, the client
SHOULD
only commence a device authorization request when
prompted by the user and not automatically
, such as when the app starts or when the previous authorization session expires or failAs.
TLS is required both between WoT Consumer/Authorization Server and between Browser/Authorization Server
Other user interactions methods may be used but are left out of scope
client credential
The Client Credentials grant type is used by clients to obtain an access token outside of the context of an end-user. From
RFC6749
:
The client can request an access token using only its client credentials (or other supported means of authentication) when the the client is requesting access to the protected resources under its control, or
those of another resource owner that has been previously arranged with the authorization server
(the method of which is beyond the scope of this specification).
Therefore the client credential grant can be used:
When the resource owner is a public authority. For example, in a smart city context, the authority provides a web service where to register an application id.
Companion application
Industrial IoT. Consider a smart factory where the devices or services are provisioned with client credentials.
...
The Client Credentials flow is illustrated in the following diagram. Notice how the Resource Owner is not present.
Comment: Usually client credentials are distributed using an external service which is used by humans to register a particular application. For example, the
npm
cli has a companion dashboard where a developer requests the generation of a token that is then passed to the cli. The token is used to verify the publishing process of
npm
packages in the registry. Further examples are Docker cli and OpenId Connect Client Credentials.
In order to avoid these issues, clients
SHOULD NOT
use the implicit grant (response type "token") or other response types issuing access tokens in the authorization response, unless access token injection in the authorization, response is prevented and the aforementioned token leakage vectors are mitigated.
The RFC above suggests using
code
flow with Proof Key for Code Exchange (PKCE) instead. The implicit flow was designed for public clients typically implemented inside a browser (i.e. javascript clients). As the
code
is a redirection-based flow and it requires direct interaction with the resource's owner user-agent. However, it requires one less step to obtain a token as it is returned directly in the authentication request (see the diagram below). Considering the WoT context this flow is not particularly different from
code
grant and it can be used in the same scenarios. Comment: even if the
implicit
flow is deprecated existing services may still using it.
The resource owner password credentials grant
MUST NOT
be used. This grant type insecurely exposes the credentials of the resource owner to the client. Even if the client is benign, this results in an increased attack surface (credentials can leak in more places than just the AS) and users are trained to enter their credentials in places other than the AS.
For completeness the diagram flow is reported below.
Handle the entire device lifecycle: Define terminology for lifecycle states and transitions.
Actors (represent a physical person or group of persons (company))
Manufacturer Service Provider Network Provider (potentially transparent for WoT use cases) Device Owner (User) Others?
Roles:
Depending on the use case, an actor can have multiple roles, e.g. security maintainer. Roles can be delegated.
Variants
There are (at least) two different entities to consider:
Things / Devices
Consumers, e.g. cloud services or gateways
In more complex use cases there are additional entities:
Intermediates
Directories
Gaps
The current architecture spec does not describe device lifecycle in detail. A common lifecycle model helps to clarify terminology and structures the discussion in different groups. Interaction of a device with other entities such as directories may introduce additional states and transitions.
network operator (potentially transparent for WoT use cases)
identity provider
directory service operator
Motivation
Discovery defines a distribution mechanism for the metadata contained in WoT Things Descriptions, and allows Things to advertise their capabilities and for potential consumers to find Things that match their needs. A standardized discovery mechanism is an enabler for convenient and ad-hoc orchestration of combinations of Things from different vendors while supporting appropriate security and privacy controls.
Expected Devices
Thing - any device or service that wishes to distribute (advertise) its metadata.
Consumer - any device or service that wishes to find Things whose location and metadata satisfies specified constraints.
Discovery Service - Mechanism by which metadata is distributed, which can involve a variety of services to handle spatial and semantic queries, register Thing Descriptions, provide access controls, etc.
Expected Data
Thing Descriptions - metadata describing a Thing
Dependencies - Affected WoT deliverables and/or work items
WoT Discovery
Note: this is a "horizontal" use case, and is driven by requirements in multiple verticals.
Description
A user wishing to build or instantiate an IoT service needs access to Thing Descriptions of installed and running devices satisfying specific requirements. These requirements can include being in or near a certain location, accessible using particular protocols or on a certain network, satisfying certain semantic categories, having certain capabilities, or having specific sub-APIs (interfaces). Discovery is the general process whereby WoT Thing Descriptions satisfying a specific set of such constraints are retreived by a running system.
Variants
Run-time discovery allows late binding of orchestration services to particular devices and requires that consumers be able to adapt to Thing Descriptions discovered when a service is deployed.
Development-time discovery may be useful during system development to build services that can interface to a particular class of Thing Descriptions. In this case what actually needs to be discovered Thing Models, not specific Thing Descriptions.
Security Considerations
The distribution mechanism needs to be able to clearly authenticate potential users.
The distribution mechanism for metadata should only provide metadata to authorized users.
The distribution mechanism should be able to resist denial-of-service attacks seeking to overwhelm it withi spurious requests.
The distribution mechanism should be able to preserve the integrity of metadata.
Privacy Considerations
Metadata should only be distributed to appropriate sets of requesters, with the definition of "appropriate" configurable by the source of the metadata.
Unauthorized users should not be able to access or infer information that they do not have access rights to.
Providers of metadata should be able to withdraw metadata from distribution at any time.
Metadata should not be retained indefinitely.
Gaps
The current WoT standards define a metadata format (the Thing Description) but not a means of distributing it.
Existing standards
WoT Thing Description
CoreRD
DID
Comments
Many discovery mechansims already exist but many do not satisfy all the requirements above, e.g. they may have insufficient privacy controls. A standards solution that builds upon prior work in this area is desirable.
4.17
VR/AR
4.17.1
VR/AR Virtual Guide (for gaming, medical purposes, etc.)
AR Virtual Guide
Submitter(s)
Rob Smith
Kaz Ashimura
Reviewer(s)
Michael McCool
Christine Perey
Tracker Issue ID
Category
vertical ( but quasi-horizontal from accessibility viewpoint)
Class
Status
Target Users
device owners
device user
cloud provider
service provider
device manufacturer
network operator (potentially transparent for WoT use cases)
identity provider
directory service operator
Motivation
Using a wearable semi-transparent display, users can be guided by a virtual assistant through a physical area of interest with a rendered overlay to visualize events, annotate structures and other physical features, or visualize live and historical data associated with features of interest (which may or may not be at the same physical location as the sensor generating the data). An annotated map may provide additional geospatial guidance, including identification of landmarks, locations of devices. The system may also guide the user along a specific trajectory.
Expected Devices
Display (possibly a VR Goggle) / speakers for output
3D camera / motion sensor for input (possibly microphone for speech recognition)
Wearable, semi-transparent head-mounted display
other various devices as output actuators and/or input sensors
Headphones for speakers for audio output
Recorder and Player to store and reproduce the scenes
Geopose and motion estimator (various technologies can be used)
Data processor to integrate all the related data and devices, e.g., user data, VR space, sensors, actuators, recorder/player
Data processor to integrate all data (including live an historical data and geopose), generate annotations for the display, and record/play scenes
Expected Data
location/direction/movement/acceleration information of the user
3D Position, orientation, velocity, and acceleration of the user
geolocation (latitude, longitude, altitude) information of the virtual space
Corresponding geolocation information (latitude, longitude, altitude) for all features of interest, including but not limited to physical landmarks, roads and paths, and locations of sensor's measurement points.
time synchronization of the user's sight and the virtual space movement
Timestamps to allow synchronization between the annotations and data streams and the user's movement
Dependencies - Affected WoT deliverables and/or work items
WoT Thing Description
WoT Binding Templates
WoT Discovery
Optional: WoT Scripting API accessible from application for interacting with devices.
Description
The user can travel around the real or virtual space with guidance from the virtually defined geospatial data.
The user can travel around a real space with guidance from virtually defined geospatial data projected on a head-mounted wearable display synchronized with the view of the physical environment.
The video display includes location metadata as well so that the user's virtual movement will be traced and synchronized with the map.
The wearable display can generate position and orientation (geopose) data so that the user's movement will be traced through the physical environment and can synchronized with virtual features.
The user can control the video images provided by the server, e.g., VR/AR games or medical images, based on the sensors attached the display or the VR goggle
The user can control the video images provided by the system, based sensors attached the display system or other means of control (gestures, voice input, etc.)
This mechanism is not for AR/VR specifically but can be used for video overlay in general. Also related to recording/playing/distributing of video media when the data is stored. Would be useful for simulation and debugging as well.
The technology should include synchronization of playback of stored video media and related sensors, displays, and devices as well as the display of geolocation information from the virtual map.
The background technology should include synchronization of the video media and related sensors/displays/devices as well as the geolocation information from the virtual map.
Discovery of sensors should take into account the position and field of view of the user so that data can be retreived only for the relevant features of interest.
Discovery may additionally want to consider the motion (e.g. velocity) of the user to that data soon to come into view can be prefetched.
Metadata for sensors needs to distinguish between the location of the device itself and the feature of interest it is measuring. For example, a camera might monitor traffic on a highway. The feature of interest is the location on the highway being monitored, while the location of the camera might be quite far away (e.g. mounted on top of a building).
A virtual guide for a particular geographic location, e.g. a historical site, which visualises past events and buildings in AR, or allows remotes users to explore in VR.
Two synchronized displays (for example, a phone and a headset) can offer greater insight and provide clearer guidance to the user by showing different views of the same location, e.g. a top-view map on the phone.
A VR (virtual-only) implementation may also be used, with a rendered scene replacing the real scene. This may be applicable to contexts such as a Smart City dashboard where sensor information from data needs to be viewed in context without having to actually visit the site.
The head-mounted semi-transparent display might be replaced in some contexts with a handheld display e.g. a phone or tablet. To be useful for AR however, such a device needs a back camera to simulate transparency and capture images of the real environment (optional for VR), and a way to determine its geolocation and orientation (geopose) relative to the environment.
The head-mounted display may use a camera rather than being physically transparent.
A microphone may be added for voice input, including voice commands. This avoid having to clutter the view with controls.
A 3D camera (e.g. LIDAR) may be used to capture a view of the environment, which can be helpful to establish geopose and align annotations with real features of the environment.
A virtual guide for a particular geographic location, e.g. a historical site, which visualises past events and buildings in AR, or allows remote users to explore in VR.
A medical tool which allows a patient to describe their symptoms using AR, e.g. identify a painful area on their own body, which is also modelled as a 'map' to show internal features and display a treatment guide, including any WoT medical devices.
A virtual controller for a city engineer to visualise utilities, e.g. electrical cables or water pipes, and control them. For example, a maintenance engineer could switch off an individual street lamp in order to replace the bulb using an AR menu displayed on that WoT lamppost.
A virtual controller for a city engineer to visualise utilities, e.g. electrical cables or water pipes, and control them. For example, a maintenance engineer could switch off an individual street lamp in order to replace the bulb using an AR menu displayed on that WoT-enabled lamppost.
These mechanisms can also be used for video overlay in general. The technologies are related to the recording, playing, and distribution of video content when the data is stored. Playback of stored data and movements would be useful for simulation and debugging.
Security Considerations
If an AR systems is compromised it could be used to guide a user into a dangerous situation while hiding that fact from them, e.g. encouraging them to step over a drop.
For the above reason the system should "fail gracefully" if there is any sign its integrity is compromised, and should implement mechanisms (e.g. signing) to detect tampering. Standards should be similar to other systems than can cause physical harm, e.g. automobiles.
For a "simulated" transparent head-mounted display using a camera, the system should have a fail-safe supporting an unfiltered view, which should be automatic even if the processor crashes.
For all systems the user should have a simple way (e.g. a single button push) of viewing "baseline reality".
Privacy Considerations
Systems that handle or display private data, e.g. medical applications, should respect the relevant regulations.
Private data should not be retained by the device or used for purposes other than which it was provided. This includes the location of personal devices. To display information from another's personal device, permission needs to be explicity granted by that person and this permission should be time and possibly space-limited.
Requirements
Geospatially aware discovery mechanisms that can discover features of interest close to the user.
Geospatial filters for discovery that include a pyramid-shaped region representing the field of view of the user. Note: a basic cylindrical, spherical, or rectangular filter region can be used instead and then the irrelevant results filtered out, but this is less efficient than the filter itself supporting field-of-view queries.
Geospatial data associate with the metadata for devices. Note that mobile devices may update their position more rapidly than a discovery service may be able to support. In this case the discovery service needs to take the velocity and last known position of the data source into account and compute a zone of uncertainty and return the metadata for sources that might possibly be in the field of view. For sources such as this with dynamic positions, the AR system may also communicate with data sources directly to determine their most recent geolocation.
Gaps
Geospatial queries for discovery.
Standardized encodings of geospatial metadata in TDs.
Existing standards
Comments
5.
Requirements
5.1
Functional Requirements
This section defines the properties required in an abstract Web of Things (WoT) architecture.
Editor's note
TODO: New requirements from new use cases need to be added here. Add a link to the requirements section in the github repo.
5.1.1
Common Principles
WoT architecture should enable mutual interworking of different eco-systems using web technology.
WoT architecture should be based on the web architecture using RESTful APIs.
WoT architecture should allow to use multiple payload formats which are commonly used in the web.
WoT architecture must enable different device architectures and must not force a client or server implementation of system components.
Flexibility
There are a wide variety of physical device configurations for WoT implementations. The WoT abstract architecture should be able to be mapped to and cover all of the variations.
Compatibility
There are already many existing IoT solutions and ongoing IoT standardization activities in many business fields. The WoT should provide a bridge between these existing and developing IoT solutions and Web technology based on WoT concepts. The WoT should be upwards compatible with existing IoT solutions and current standards.
Scalability
WoT must be able to scale for IoT solutions that incorporate thousands to millions of devices. These devices may offer the same capabilities even though they are created by different manufacturers.
Interoperability
WoT must provide interoperability across device and cloud manufacturers. It must be possible to take a WoT enabled device and connect it with a cloud service from different manufacturers out of the box.
5.1.2
Thing Functionalities
WoT architecture should allow things to have functionalities such as
reading thing's status information
updating thing's status information which might cause actuation
subscribing to, receiving and unsubscribing to notifications of changes of the thing's status information.
invoking functions with input and output parameters which would cause certain actuation or calculation.
subscribing to, receiving and unsubscribing to event notifications that are more general than just reports of state transitions.
5.1.3
Search and Discovery
WoT architecture should allow clients to know thing's attributes, functionalities and their access points, prior to access to the thing itself.
WoT architecture should allow clients to search things by its attributes and functionalities.
WoT architecture should allow semantic search of things providing required functionalities based on a unified vocabulary, regardless of naming of the functionalities.
5.1.4
Description Mechanism
WoT architecture should support a common description mechanism which enables describing things and their functions.
Such descriptions should be not only human-readable, but also machine-readable.
Such descriptions should allow semantic annotation of its structure and described contents.
Such description should be able to be exchanged using multiple formats which are commonly used in the web.
5.1.5
Description of Attributes
WoT architecture should allow describing thing's attributes such as
name
explanation
version of spec, format and description itself
links to other related things and metadata information
Such descriptions should support internationalization.
WoT architecture should support multiple web protocols which are commonly used.
Such protocols include
protocols commonly used in the internet and
protocols commonly used in the local area network
WoT architecture should allow using multiple web protocols to access to the same functionality.
WoT architecture should allow using a combination of multiple protocols to the functionalities of the same thing (e.g., HTTP and WebSocket).
5.1.8
Deployment
WoT architecture should support a wide variety of thing capabilities such as edge devices with resource restrictions and virtual things on the cloud, based on the same model.
WoT architecture should support multiple levels of thing hierarchy with intermediate entities such as gateways and proxies.
WoT architecture should support accessing things in the local network from the outside of the local network (the internet or another local network), considering network address translation.
5.1.9
Application
WoT architecture should allow describing applications for a wide variety of things such as edge device, gateway, cloud and UI/UX device, using web standard technology based on the same model.
5.1.10
Legacy Adoption
WoT architecture should allow mapping of legacy IP and non-IP protocols to web protocols, supporting various topologies, where such legacy protocols are terminated and translated.
WoT architecture should allow transparent use of existing IP protocols without translation, which follow RESTful architecture.
WoT architecture must not enforce client or server roles on devices and services. An IoT device can be either a client or a server, or both, depending on the system architecture; the same is true of edge and cloud services.
5.2
Non-Functional Requirements
5.2.1
Security and Privacy
5.3
Technical Requirements
Editor's note
TODO: New requirements from new use cases need to be added here.
The
W3C
WoT Thing Architecture [
wot-architecture
] defines the abstract architecture of Web of Things and illustrates it with various system topologies. This section describes technical requirements derived from the abstract architecture.
5.3.1
Components in the Web of Things and the Web of Things Architecture
The use cases help to identify basic components such as devices and applications, that access and control those devices, proxies (i.e., gateways and edge devices) that are located between devices. An additional component useful in some use cases is the directory, which assists with discovery.
Those components are connected to the internet or field networks in offices, factories or other facilities. Note that all components involved may be connected to a single network in some cases, however, in general components can be deployed across multiple networks.
5.3.2
Devices
Access to devices is made using a description of their functions and interfaces. This description is called
Thing Description (TD)
. A
Thing Description
includes a general metadata about the device, information models representing functions, transport protocol description for operating on information models, and security information.
General metadata contains device identifiers (URI), device information such as serial number, production date, location and other human readable information.
Information models defines device attributes, and represent device’s internal settings, control functionality and notification functionality. Devices that have the same functionality have the same information model regardless of the transport protocols used.
Because many systems based on Web of Things architecture are crossing system Domains, vocabularies and meta data (e.g., ontologies) used in information models should be commonly understood by involved parties. In addition to REST transports, PubSub transports are also supported.
Security information includes descriptions about authentication, authorization and secure communications. Devices are required to put TDs either inside them or at locations external to the devices, and to make TDs accessible so that other components can find and access them.
5.3.3
Applications
Applications need to be able to generate and use network and program interfaces based on metadata (descriptions).
Applications have to be able to obtain these descriptions through the network, therefore, need to be able to conduct search operations and acquire the necessary descriptions over the network.
5.3.4
Digital Twins
Digital Twins need to generate program interfaces internally based on metadata (descriptions), and to represent virtual devices by using those program interfaces. A twin has to produce a description for the virtual device and make it externally available.
Identifiers of virtual devices need to be newly assigned, therefore, are different from the original devices. This makes sure that virtual devices and the original devices are clearly recognized as separate entities. Transport and security mechanisms and settings of the virtual devices can be different from original devices if necessary. Virtual devices are required to have descriptions provided either directly by the twin or to have them available at external locations. In either case it is required to make the descriptions available so that other components can find and use the devices associated with them.
5.3.5
Discovery
For TDs of devices and virtual devices to be accessible from devices, applications and twins, there needs to be a common way to share TDs. Directories can serve this requirement by providing functionalities to allow devices and twins themselves automatically or the users to manually register the descriptions.
Descriptions of the devices and virtual devices need to be searchable by external entities. Directories have to be able to process search operations with search keys such as keywords from the general description in the device description or information models.
5.3.6
Security
Security information related to devices and virtual devices needs to be described in device descriptions. This includes information for authentication/authorization and payload encryption.
WoT architecture should support multiple security mechanism commonly used in the web, such as Basic, Digest, Bearer and OAuth2.0.
5.3.7
Accessibility
The Web of Things primarily targets machine-to-machine communication. The humans involved are usually developers that integrate Things into applications. End-users will be faced with the front-ends of the applications or the physical user interfaces provided by devices themselves. Both are out of scope of the
W3C
WoT specifications. Given the focus on IoT instead of users, accessibility is not a direct requirement, and hence is not addressed within this specification.
There is, however, an interesting aspect on accessibility: Fulfilling the requirements above enables machines to understand the network-facing API of devices. This can be utilized by accessibility tools to provide user interfaces of different modality, thereby removing barriers to using physical devices and IoT-related applications.
5.4
Requirements for individual WoT Building Blocks
5.4.1
Architecture
5.4.2
Thing Description
5.4.3
Profile
5.4.4
Binding Templates
5.4.5
Scripting
5.4.6
Discovery
5.4.7
New Building Blocks
A.
Acknowledgments
Editor's note
List all authors of contributions.
Special thanks to all authors of use case descriptions for their contributions to this document.
Many thanks to the
W3C
staff and all other active Participants of the
W3C
Web of Things Interest Group (WoT IG) and Working Group (WoT WG) for their support, technical input and suggestions that led to improvements to this document.