How does running a PRT system compare to, say, running an
assembly line full of robots? Or how
about compared to industrial processes like a chemical plant? There is a lot of reason to ask such
questions, because the controls for such complex processes are always being
upgraded with the latest equipment, so it’s interesting to see what they are
using and why. Could such solutions be
ready-made for PRT?
Let’s start with the onboard computer. What is needed is a stripped down system, both
in terms of physical and software architectures. Half of the stuff on a typical motherboard is
completely unnecessary and therefore detrimental. Also, a
computer for industrial processes can’t run on Windows or any other ordinary desk
operating system because such systems are specifically designed to take as long
as necessary to finish a task. This is
so the time may be divided between however many programs might be running at
the time. Industrial processes, on the
other hand, usually need to perform within an exact time frame. You can’t have one robot run more slowly than
the others in an assembly line whenever it is receiving new instructions, for
example. Also, industrial control computers
need to be designed for potentially harsh environments. Dust, changes in humidity, temperature, even
insects can cause failures in PCs as well, but not catastrophic, dangerous
failures that could result in loss of life or extensive physical damage. Finally, there is great advantage to giving
industrial control computers lots of input/output terminals, something missing on
ordinary computer motherboards. These computers are often used as an
intermediary between sensors and switches, so having simple input terminals for
the sensors with corresponding outputs for those switches simplifies matters
greatly. Actually, this role (and history) of being used in place of a simple
relay or arrangement of relays is reflected in the name, trademarked by
Allen-Bradley. (A division of Rockwell Automation) They are called Programmable Logic Controllers,
or PLCs for short. (I have also seen them simply called “controllers” by other
manufacturers) Of course when they were
first invented they were really more about switching than computing. However certain capabilities, like dealing
with complex analog data or modern communications protocols have necessitated
greater and greater processing power, not to mention the desire to incorporate
more and more processes into a unified control environment. Now whole banks of PLCs can be rack mounted,
or very inexpensive and compact units are available that have only a half-dozen
input/outputs, an Ethernet or RS232 port, and little else.
Controlling large numbers of PLCs or other EDIs,
(Intelligent Electronic Devices) including from long distances, is very common.
One broadly used term for this is DCS
(Distributed Control System) and another commonly used term is SCADA, which
stands for “Supervisory Control and Data Acquisition.”
(The differences are minor, with SCADA being more data
collection oriented and DCS being more action oriented. Since PRT control is
highly involved with both, I will just keep it simple and use “SCADA.”) SCADA systems are used throughout industry - to control
traffic lights, a building’s HVAC and access, electrical grids, pipelines, wind
farms, water treatment plans - even space stations!
SCADA systems have become so commonplace that there are dozens
of venders and many internationally recognized standards, protocols and
practices. The SCADA architecture does
not necessarily require PLCs, but can also be used to control the PLC’s simpler
cousin, the RTU. Remote Terminal Units,
(Or Remote Telemetry Units) are microprocessor controlled sensor/switches with
networking capabilities. Obviously the
line between a full featured RTU and a bare-bones PLC is a very blurry one, and
getting blurrier every day. On the very
lowest end, there are also microprocessor controlled relays, sometimes called
“control relays,” which enable some rudimentary control capability from sensors
or neighboring equipment. A typical
example would be to use such a unit as a safety switch, where some sensor(s)
can cause a process to stop - say, to stop something from overflowing,
overheating, or trying to work in a flood.
The SCADA architecture is extremely flexible, in that there
are no set rules for where primary control of any given process resides. Supervisory control can be exercised from more
than one site, and much of the “decision making” can be done in the field by
PLCs, RTUs, or even hardwired relay arrays. This is facilitated by software which is
designed around ladder logic, which itself has its roots in relay design for
automation and process control. There
are a number of options for communication, and they have increasingly included
TCP/IP and Ethernet, something that has recently raised security concerns when
it was revealed that all kinds of “back doors” are easily discoverable in
systems controlling essential infrastructure such as the power grid. (The flip
side is that with such common communications protocols, standard firewalls and
other security procedures can be easily deployed and updated.) As with the field-based equipment, a real-time
environment may be required for more remote communications as well, which is a
much greater challenge than would otherwise be the case, especially with lots
of nodes over a wide area. The time lags
that we have all experienced on phones, TV or email are testament to the thorniness
of this issue. This has been partially addressed by a dozen or so Ethernet-based
solutions which separate communications channels that must perform in real-time
from other sorts of chatter. Any
distributed real-time system is restricted to relatively fewer nodes in closer
proximity, though, although dedicated infrastructure, such as fiber optic
lines, obviously change those parameters.
As might be expected, if the communication
is of a type that can tolerate quarter-second lag or more, hundreds or even
thousands of nodes can be dispersed over great distances.
As to how all of this affects the design of PRT control, the
last point is perhaps the most important. Barring an absolutely clean,
dedicated, failure-proof real-time signal to each vehicle, there is obvious
advantage to keeping millisecond decisions local. That is really not a problem, as that is what
PLCs are designed for, and clearly each vehicle needs one or two. The questions
arise a bit further up the control ladder. In switching, for example, there would be
great benefit in allowing direct, real-time communications between vehicles. I do not think this is out of the realm of
possibility with ordinary SCADA solutions, although it’s a bit unusual. It is certainly unusual in that new vehicles
would have to dynamically introduce themselves into a LAN (local area network)
whose members (and location) would be constantly changing. Ethernet, however, allows such discovery, and
as I mentioned, some variations of Ethernet allow real-time communications. These
capabilities are bound to rapidly become more versatile and easier to
implement, due to the continuing proliferation of processing power toward the
edges of the network. (i.e. the machines themselves) That is because as machines
or processes are increasingly self-directing and regulating, it means that if other
processes further downstream are affected
in any way, it may make sense to have the equipment collaborate directly rather
than via some remote control room, miles away. This has led to substantial interest in
facilitating such collaborative automation by creating software and hardware standards
specifically designed for this. I know of nothing custom tailored for vehicle-to-vehicle
collaboration yet, though, and for the foreseeable future I doubt anything will
be able to replace onboard decision-making as a backup.
While I’m crowding our minds with new acronyms, I just have
to mention one more. There is something
called PID (Proportional-Integral-Derivative) control, which falls into the
realm of tasks most PLCs can perform. It
works like this: Imagine steering a big ship.
When you turn the rudder, it takes a while for the ship to follow
suit. If you are not careful, you may
over steer, since the momentum of the turn, once started, is difficult to
stop. Or how about the velocity of
material in a pipeline - or the
pressure?... or the heat of very large amounts of material? Again, there is this quality of delay
followed by momentum. This has relevance in PRT traffic management. Consider the question of what happens when
one part of a network is heavily trafficked and another isn’t. If enough vehicles, either autonomously or by
central control, all seek the less trafficked route at once, it could create an
instant traffic jam, while the previously trafficked route could go suddenly
empty. This is clearly the type of thing
a PID controller is designed for. Isn’t
it nice to know this stuff is already on the shelf?
It is interesting how the distinction between vehicles and
robots is disappearing. What started deep
inside the family car for better fuel efficiency and braking has exploded to
the surface with self-driving features, and this is clearly the direction for
PRT as well, so it only makes sense to control PRT vehicles in the same way
that other collections of robots are controlled. It is also clear is that there is a basic
commonality between the control
requirements for PRT and many other fields, so there is no need to start from
scratch. There are sensors, and things
that must be physically or electronically done based on what they show. There are processes that must be initiated,
monitored, and terminated. There are
times when machinery must act autonomously, and times when it may be best to
control it from afar. There are times
when far-flung pieces of equipment need to receive updated numerical values or
instructions and times when similar data needs to go in the other direction. The point is that most possible PRT control topographies
are already established in other industries, and it is not just the equipment
or software. It is the human expertise. There are classes in SCADA and ladder logic
and PLC implementation, so the experts are out there as well.
Long ago, when I started this blog, I called for standardizing aspects of PRT, so that entrants to the field this could offer products built on a firmer foundation than could be found in the custom (ad hoc) solutions invented by the PRT designers themselves. This call was met with some skepticism, as there are always issues as to whose standard is better, and if the standard will become an obsolete encumbrance. The point was also made that investors in PRT companies would want patent protection and other proprietary advantages to safeguard those investments. My point, though, was that there was entirely too much trust being asked of purchasers of PRT systems. Who would want to buy a system controlled by a magical black box full of proprietary equipment? What if it doesn’t work as advertised? What if the company folds? The framework mentioned above goes a very long way toward addressing my concerns, as well of the concerns of another group who I rarely hear mentioned in conjunction with PRT - insurers. After all, large factories and refineries are presumably insured, and are run by SCADA systems, so the safety track record of given systems is a matter of public and private record. For PRT, all of this is, (in the words of Martha Stewart) “A good thing!”
