Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reference device #69

Closed
wants to merge 4 commits into from
Closed

Reference device #69

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
4bc5020
Reference device
mlagally Feb 18, 2021
aca9083
Update index.html
mlagally Feb 18, 2021
9f13b1f
Update index.html
mlagally Feb 18, 2021
e5c999c
Update index.html
mlagally Feb 18, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
35 changes: 35 additions & 0 deletions index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -593,6 +593,41 @@ <h3 id="profile-description-methodology">Methodology</h3>
-->
</p>
</section>

<section id="reference-devices">
<h2>Reference Device</h2>
<p>
Since a profile is to be supported by a wide variety of devices, lower
bound for device characteristics and capabilities have to be selected.
Small embedded devices have very limited RAM and Flash storage among other limitations
(e.g. clock speed, power consumption) which make complex processing unfeasible.
</p>
<p>
<section>
<h3 id="use-case">Use Case</h3>
<p>
As the baseline use case we select the capability to process a full TD without additional external components.
A device in the <em>producer</em> role generates a TD and allows consumers to use telemetry and control of device actions.
In the <em>consumer</em> role a device is extracting pieces of information from a single TD to
control or read telemetry data from some other device.
</p>
<p>These devices are simple consumers/producers that just are required to consume a SINGLE TD.
</p>
</section>
<section>
<h3 id="core-device">Embedded Reference Device</h3>
The characteristics of a minimum device which can run a TCP / HTTP stack + process JSON payloads to consume and expose TDs
were identified with several model assumptions and by inspecting some real world devices.

<p>
Additionally all TDs that were used during the PlugFests showed that 95% of TDs were around 8KB in size.
</p>
<p>
A maximum size of a TD of 16 KB leaves enough headroom and can be still handled on embedded devices with 64-128KB of RAM.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As discussed in today's meeting, many WoT produces are not able to fulfill such kind of limitation. E.g., a Sentron PAC has over 50 different datapoints (s. page 99).

This 16k limit is mainly meant to address WoT consumer. But what are realistic use cases? I assume that a node that also consume TDs will always be more powerful than a WoT producer only.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sebastiankb
Thanks Sebastian, this makes the discussion much more concrete.
Which size limit would you recommend for TDs produced by this device?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So far, I see no need for such a restriction in the core profile with HTTP/JSON. But maybe I'm missing something. I would recommend that in the next session we discuss what kind of (realistic) scenarios you need for this constraint. A good orientation can be this figure here.

</p>
</section>
</section>

</section>


Expand Down