The Remote Gate Diverse System

'Cloud Gate' - Millenium Park Chicago

Today's blog post is inspired by Anish Kapoor's beautiful 'Cloud Gate' in Chicago.    It is a public sculpture to play and interact with in any weather.  I aim to go see it touch it with one finger and look at the city go by one day. The blog post itself is just like that - a single touch to a gate of the kind of diverse engineering which takes place at remote locations. [The photo courtesy of  Lisa Yarost.]

Most people think of remote terminal units and remote systems as an atomic black box, doing a certain job, somewhere far off, with a means to communicate. The black box has become a citadel, a complex arrangement of interacting intelligent devices which need a gate through which to communicate.

What does it look like inside that far off citadel, and what kind of architectures support it ?.  What follows is a brief introduction to the story of the development of the Gated Diverse Architecture.

Before I go on, the architecture is relatively new, and we are still working though it's implications.  Note that the SCD5200 Station Computing device is capable of being engineered to handle all of the architectures.

It used to be that intelligent remote systems had their own IO connected up just fine, and engineering a few applications was relatively easy. Used to be that setting up a communications system was easy enough, a serial cable, a radio.  A simple polling protocol and you could make things happen fast. A lone engineer could make something happen with just one device. In the diagram immediately above, a simple client application accesses a system through an agent [a] to obtain and control data from two sets, [p,q] which represents a real-time database directly connected to [i/o] which in turn are directly hard-wired [m/a] measurement and actuation devices. True to their name most simplex systems are only available when all the links in the path to the agent [a] at least are connected and available.  Hard-wired connectivity is generally highly available so the MBTF of the system is dependent on the system itself.  Since there are no communications links which might be disconnected, no networks involved, the hard-wired simplex system turns out to be one of the most available systems that can be constructed.

Moving on, it is possible to build what is known as a diverse system.  The system operates concurrently on the same [m/a] measurement and actuation, but operates generally as an alternate path.  The system engineer makes a fully duplicated system, but does not require the systems to be identical or even of design or vendor.  They just have to function the same.  Diversity has the advantage of eliminating common mode problems with software, operating systems, and support hardware. A diverse system has much more engineering required to set up and twice as many tools to know and utilize. Diverse systems are great providing the initial investment in the functional engineering can be copied and utilized as the system is extended.

Distributed systems combine the high availability of simplex systems with the economy of graceful or partitioned failure.  In Distributed systems the IO for a particular partition of the plant is directed to a particular NODAL partition. The partition [p] and the partition [q] in the diagram represents different aspects of the plant, which if they fail will result in only part of the system being unavailable, not the whole system. Careful partitioning of the IO and the related functionality allows for a more economical and higher performance system. There is some coordination between distributed partitions, however the interaction if generally slight depending on client agents [a] requirement for data from multiple partitions. One appealing aspect of distributed systems is the ability to update and upgrade partitions of plant independently.  This mirrors the actual evolution of systems in real life.  New feeders get added to substations. New pumps get added to pump stations as capacity is enhanced. A distributed system allows for new partitions to be added without any change in the engineering or configuration of the existing partitions other than notification of the existence of the partition.

So far the diagrams have dealt with making systems more available, reducing common mode issues, and creating a distributed partitioning with practical advantages in economics and engineering. All of these architectures are not directly dealing with the issue of connected IEDs.  The GATED DIVERSE system architecture arises when many of the distributed  partitions become IEDs of diverse type and engineered separately

By incorporating a redundant system as a gateway and then having it supervise many diverse IEDs. The fundamental structure shifts the hardwired IO down through a network.  So now we have a gateway level [Much data and communications], and an Intelligent functional level [Many IEDs].  

Unfortunately pushing the functional level down into IEDs requires considerable thought as to the communications architecture and protocols.  In addition the gateway function has to be enhanced to enable it to manage not only diverse IEDs but the fact that the IED may or may not be connected or operating correctly. This adds an added dimension to the decision making and routing of control, should a communication path be down, or the device be not installed.

In upcoming posts we might explore different aspects of this architecture.  I expect you may have questions or comments so feel free to ask for and contribute to the ideas on this post... be glad to hear from you.  If by any chance you get to Chicago, go check out that wonderful Cloud Gate - touch it - an get someone to take a photo. = Chris S. Nov 2012.