Hi,

I am glad that time critical events during emergency/alarm conditions is
being
discussed in the mailing list as it is extremely important for my work.
Thanks
to Yvonne-Anne for bringing up this important topic.

We are working towards deploying a complete 6tisch based network for
monitoring
and control for an industrial application. This industry currently uses
combination of wired and wireless infrastructure. The wireless part is used
for
not-so-critical and routing monitoring activities, whereas wired
infrastructure
is used to perform time critical parameter monitoring and control loop
operations. One of the main requirements when we completely migrate to
6tisch
network is timely handling of emergency conditions so that system trip and
shutdown are avoided.

I would like to emphasise that there is a need for urgent and additional
network
resource provisioning due to several inter-related sensors getting actuated
and
the increased monitoring rate during emergency situations. If it were to be
monitored at the normal sampling rate, the parameter could very well exceed
its
safe level in few updates and could very well lead to a system trip.

Below is one such condition that occurs in a thermal power plant where we
had

worked earlier.

When pulverized coal outlet temperature limit crosses certain limit for safe
operation of the coal mill, it could be due to several reasons such as
deviation in primary air temperature, primary air flow, mill inlet
temperature
or cold air inflow. The deviation in primary air temperature itself could be
due to problems associated with pre-heating and the deviation in cold air
inflow could be due to malfunctioning of hot air damper valve. 

It will be very helpful if we have mechanisms built into 6tisch which
enables
end application/controller, and nodes in the network to set up emergency
flows through
network bandwidth reservations in a timely manner that guarantees end-to-end
QoS till the emergency condition lasts.

Thanks & Regards

 

Senju Thomas Panicker

Senior Engineer

Control & Instrumentation Group



 

 

 

-----Original Message-----
From: 6tisch [mailto:[email protected]] On Behalf Of Yvonne-Anne
Pignolet
Sent: 29 June 2015 15:00
To: [email protected]
Subject: Re: [6tisch] 6tisch architecture and time-critical events

 

Dear all

 

Taking up some remarks by Anand and Pascal, has there been any recent
activity with respect to the topic of handling resources in emergency
scenarios?

In case there hasn't, it would like to stress that from an industrial
perspective such scenarios are very important.

 

In particular, this concerns resources such as flows that follow certain
routes, and bandwidth allocation. Depending on the traffic demands during
alarm/emergency conditions, applications may decide to pre-empt or stall
some of the ongoing traffic flows to accommodate new flows or to assign
appropriate resources to existing flows. Is there a concept of priorities of
flows envisioned in the architecture?

 

Note that if there are cascading errors this often leads to an increase in
traffic (messages to trigger logging of abnormal conditions, alarms for
operators, &). Certain protocols (e.g. GOOOSE) send bursts of messages in
such situations (e.g., three messages with a very short time interval in
between, while normally one message every few seconds is sent) One could
also envision applications having tighter control over network resources.
For instance, an application might want to (i) increase the sensing rate
(ii) activate additional sensors (iii) create special routing paths, ... In
current implementations the applications are not designed to trigger such
actions. However, the examples your point out can clearly be beneficial. As
an easy and crucial part I see priorities and bandwidths.

 

I'm very interested in any feedback to these points!

 

Best Regards

Yvonne-Anne

  

Yvonne-Anne Pignolet

Dr. Sc. ETH Zürich

ABB Corporate Research

Segelhofstrasse 1K

5400 Baden-Dättwil, Switzerland

Phone: +41 58 586 86 56

Mobile: +41 79 766 10 54

email:  <mailto:[email protected]>
[email protected]

 

 

On Mon, Feb 16, 2015 at 6:39 PM, Pascal Thubert (pthubert) <pthubert at
cisco.com> wrote:

> 

> A great thought, Anand,

>  

> 

> which has to do external control of 6top, establishing on demand path

> (tracks) etc.

> 

> I think that the next round to charter will have some deterministic/PCE in
it, that should address this scenario.

> 

> What's interesting in your suggestion is that it is midway between OTF and
classical tracks for control loops, being urgent and dynamic.

> 

> Do you have a documented use case?

> 

>  

> Pascal

> 

>  

> 

> From: 6tisch [mailto:6tisch-bounces at ietf.org] On Behalf Of 

> S.V.R.Anand

> Sent: lundi 16 février 2015 15:00

> To: 6tisch at ietf.org

> Subject: Re: [6tisch] Last call for draft-ietf-6tisch-architecture-05

> 

>  

> 

> Dear All,

> 

> I found that the architecture draft captured most of the general
requirements.

> 

> There is just one observation which I could not resist mentioning. It 

> has to do with the coupling of real-time application demands with the 

> rest of the architecture. There could be application specific "time
critical and sudden" events that might call for on-demand resource
allocation.

> While we can delegate such an event handling to NME and PCE, perhaps, 

> bringing in an application awareness to the overall architecture might be
useful so that we are not leaving out this possible scenario.

> 

> Just a thought.

> 

> Regards

> Anand

 

_______________________________________________

6tisch mailing list

 <mailto:[email protected]> [email protected]

 <https://www.ietf.org/mailman/listinfo/6tisch>
https://www.ietf.org/mailman/listinfo/6tisch


-------------------------------------------------------------------------------------------------------------------------------
[ C-DAC is on Social-Media too. Kindly follow us at:
Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]

This e-mail is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. If you are not the
intended recipient, please contact the sender by reply e-mail and destroy
all copies and the original message. Any unauthorized review, use,
disclosure, dissemination, forwarding, printing or copying of this email
is strictly prohibited and appropriate legal action will be taken.
-------------------------------------------------------------------------------------------------------------------------------

_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch

Reply via email to