Ethernet as a standard on the factory was really inevitable given the requirement to sync up production systems with front-office IT systems like ERP and even PLM. It is only with that kind of tight integration that companies can hope to garner the visibility and traceability necessary for boosting the efficiency of their production systems and moving to just-in-time manufacturing.
I had assumed that the migration to Ethernet was a done deal. I guess this article is saying that it is, but that not everyone has made the shift yet. I think we're also seeing something of a taxonomy/nomenclature problem, which is something that has plagued the whole discussion of fieldbuses for a long time. Namely, Ethernet isn't so much REPLACING field buses as it is BECOMING the new, de factor field bus standard (via protocols layered on top of it for safety etc.)
Ethernet has taken a really long time to move into the control world, because of the multiple silos created by different proprietary protocols and because of the big difference in functionality between control protocols and the serial, packet-based Ethernet networking protocols. The determinism issue was a real one. That's why it's taken protocols specially designed for real-time industrial control, such as EtherCAT and Ethernet Powerlink, to make that shift possible.
One of the fun side effects of IT and plant control running on the same Ethernet pipeline is the question of who's in charge? That battle has been raging for years. Some smart companies have created mixed groups with personnel from both IT and control. But that's not always the case.
They have two different views of the world. IT is concerned about security and control is concerned about uptime. In the past, control was an internal network without security issues. That's changed.
Even though Ethernet (the hardware) is becoming standard, the hiccup is the fact that each manufacturer maintains its own protocols. While you can buy an off-the-shelf industrial switch from anybody for your system, that's only half the battle. There is still no easy way (short of bridges or converters) to take Manufacturer A's product and put it into an existing system that used Manufacturer B. The issue gets blown out of proportion when dealing with non-automation people who can't quite grasp why interoperation is not so easy when "they are all ethernet, aren't they?"
You raise a really important point, Rob. And with control systems becoming a more fully blended mix of traditional automation and mainstream IT technology, it's logical that the person in charge has to straddle or have some sort of oversight of both domains. Perhaps there is an emerging new position?
Yes, it's a widespread conflict. IT says, you need these patches to ensure your security. Control says, you can't reboot these computers until we have planned downtime. The big change is that the control network is exposed to the outside world now that the plant's control network is tied in to ERP and supply chain networks.
This kind of integration is great. The finance folks know what's being consumed and what's being produced. Suppliers know what inventory has been depleted. Customers get to know when their M&Ms have shipped. But the plant is now exposed to all the contagious ills that run on the Internet.
Over 6 years of meetings between IT and Controls, there is more emphasis on security from the Controls side now that we have a greater understanding. The controls were determined that IT be "like the cable company" and provide the infrastructure only.
The largest gap now is the issue of urgency, Controls live in a world where "real-time" is milliseconds and IT's definition is hours.
Very interesting, Dave. Sounds like IT backed off once they were convinved that control got religion on the importance of security. Seems like an excellent solution. And yes, you identified another area of conflict between IT and control, the sense of time.
That's an excellent point about security, Rob. One of the good things about the pre-internet days was that, even if you could hack a machine based on one of those old proprietary standards, they weren't connected to the outside world. Now they are, and all that data is exposed.
The question of whether engineers could have foreseen the shortcut maintenance procedures that led to the crash of American Airlines Flight 191 in 1979 will probably linger for as long as there is an engineering profession.
More than 35 years later, the post-mortem on one of the country’s worst engineering disasters appears to be simple. A contractor asked for a change in an original design. The change was approved by engineers, later resulting in a mammoth structural collapse that killed 114 people and injured 216 more.
If you’re an embedded systems engineer whose analog capabilities are getting a little bit rusty, then you’ll want to take note of an upcoming Design News Continuing Education Center class, “Analog Design for the Digital World,” running Monday, Nov. 17 through Friday, Nov. 21.
Focus on Fundamentals consists of 45-minute on-line classes that cover a host of technologies. You learn without leaving the comfort of your desk. All classes are taught by subject-matter experts and all are archived. So if you can't attend live, attend at your convenience.