160> Lessons From Industry

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!”