Technology Bites Back
When Washington Irving's Rip Van Winkle awoke from his 20-year nap, he found himself in a new country. When computer users wake up on Jan. 1, 2000, they may find themselves in the old century.Year 2000 poses a myriad of problems for computers and software applications that only recognize two-digit date codes (e.
When Washington Irving's Rip Van Winkle awoke from his 20-year nap, he found himself in a new country. When computer users wake up on Jan. 1, 2000, they may find themselves in the old century.
Year 2000 poses a myriad of problems for computers and software applications that only recognize two-digit date codes (e.g "98'' for "1998''). The year 2000, read as "00," may be interpreted as the year 1900.
Automation systems use computer technology and so are subject to the same Year 2000 bugs as IT systems. What might happen if the problems are not addressed? Computers may stall, data may be lost, process views may be corrupted, and plant shutdowns could occur.
This issue's cover stories detail the Year 2000 impact on automation systems and outline a four-stage process to make your plant Year 2000 compliant.
The Year 2000 dilemma is one instance of technology biting back. We've become so reliant on computer technology that we often forget—it's only as good as it's programmed. As the old caveat goes: Garbage in, garbage out.
If computers were the breakthrough technology of the 1960s, the Internet is the breakthrough technology of the 1990s. Just as in the early days of computer-controlled plants, we need to manage expectations in applying the Internet to automation.
This issue's article, "Operator Interface Software Opens a Window on the World Wide Web," cites many fine benefits of web-enabled automation software. For instance, remote users with web browsers can monitor plants thousands of miles away. Costs for wiring, implementation, and maintenance should decrease by employing rich Internet development tools. And, since everyone knows how to use the Internet, training costs and learning curves decrease.
What could go wrong? Well, look no further than a security breach or network failure during critical data flow. The lessons we've learned in applying other commercial technologies should be remembered here as well.
First, security is everything. If web-connected users have read and write access (in other words, they can send control commands over the Internet to the server), then you must build security clearance and firewalls into the application.
Second, calculate network performance to ensure critical control responsiveness. Some good advice from Andy Swales, system architect for Schneider Automation: "Precalculate the worst-case loading on each of the segments and place blocking devices to reduce the rate of message interference from the outside. If absolute control of worst-case response time is important, choose repetitive cyclic transmission of information rather than event-driven transmission."
And finally, remember that in real life, electronics fail. Again, from Mr. Swales, "Moving the web pages from the client to the server reduces the number of critical devices, but you still must have a plan if the server itself fails."
Here are two suggestions: One, embed functionality into the automation equipment itself. Automation vendors have tried-and-true techniques to handle equipment failures. Two, centralize information on plant servers and use conventional techniques to duplicate and mirror these servers. All other plant display devices can be thin clients refreshed from the central database.
Let's apply the Internet, and its development environment, wisely to automation applications. After all, we have enough on our mind worrying about Year 2000.
Jane S. Gerold, Editorial Director email@example.com