Subject: Re: [Roll] [6tsch] comments on draft-phinney-roll-rpl-industrial-applicability

From: Michael Richardson <[email-masked]>
Date: Sat, 02 Mar 2013 11:53:35 -0500

>>>>> "Tom" == Tom Phinney <[email-masked]> writes:
    Tom> variance in cycle-to-cycle.execution time. The messaging
    Tom> involved in such automation typically require higher data rates
    Tom> than those offered by IEEE 802.15.4, and any wireless messaging

...

    Tom>    The communication between the continuous process controllers
    Tom> of a plant and the discrete automation controllers typically
    Tom> occurs on a 100 Mbit/s or faster backbone comm link. Wireless
    Tom> is not involved, and there is no reason to anticipate that it

mcr> So, given that many plants are hybrids, are you saying that
mcr> this document applies only to the process control parts of the
mcr> plant?

So, I take it that you are agreeing with this statement.

And disagreeing that "hybrid plants are also out of scope", because
all process plants have a factory automation component, but that the
factory automation component is out of scope.

Further, you have made it clear that there is no direct interconnection
between the two networks.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works 
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/

---

From: Tom Phinney <[email-masked]>
Date: Sat, 02 Mar 2013 10:58:50 -0700

> So, I take it that you are agreeing with this statement.
Essentially yes. While the higher-layer parts of industrial wireless
protocols such as WirelessHART and ISA-100.11a are more-or-less suitable
for use in the factory automation environment, in general the time
scales of required reporting and action are such that IEEE 802.15.4 will
not be appropriate. Of course there may be some parts of the plant, such
as mechanical interlocks against human intrusion, that are workable with
a 100 ms or 250 ms or even 1 s reporting delay, but that will not be
true for limit switches and other such devices in factory automation
lines that typically must report every few ms.
> factory automation component is out of scope.
Essentially yes, because the ROLL/RPL mechanism is focused on
self-organizing multi-hop networks where significant variance in
reporting delays is generally tolerable. The portions of process
automation networks where tight time constraints apply are typically one
hop off the backbone, so ROLL/RPL would be used only for self-organizing
system startup or recover after a plant disaster (e.g., explosion, fire,
tornado tearing up the plant, etc.). Likewise for most factory
automation systems, due to the information timeliness demands of the
PLCs that typically automate such processes.
> between the two networks.
If you don't consider a wired Ethernet connection between routers to be
a direct connection, then that must be the case. I personally would not
phrase it that way; rather, the two networks do not interact directly in
their network organization, although their members communicate as
directly as their differing communications technologies permit.

Note that this is also true for IEEE 802.15.4 systems that communicate
with 802.11 systems; their networks do not interact directly in their
network organization, even though they use the same spectral RF band in
the same 3D spatial region. This is particularly the case where ETSI 300
328 v1.8.1 applies, since the process system may have to use at least
fifteen IEEE 802.15.4 channels when the distances involved require
operation at greater than 10 dBm EIRP and timeliness considerations do
not permit indefinitely-repeated deferral to ongoing IEEE 802.11
transmissions.