Update:
The first shot was fired by a Real Engineer (notice the lack of quotes)
Any IT "Professionals" care to respond (quotes still there:-)
The last few DCS posts and the comments related to them have brought out an old debate. Really it is my #1 Myth
Process Control systems are different from normal IT systems.
Or
Process Control systems are the same as normal IT systems.
(two sides of the same misunderstanding)
I want to try something new here. It may not work because I am not sure I have a critical mass of readers but it just might.
I think it will work because I have a very senior group of readers from both sides of the isle.
So here goes Open thread Tuesday.
Tell me your worst stories of “IT folk” mucking in your network and insane security mechanisms implemented by “Real” engineers.
Keep it anonymous if you want to protect the guilty.
Subscribe to:
Post Comments (Atom)
1 comment:
Honestly Jim, like doctors and vets, these are very similar practices and we stand to learn a lot from each other.
In Process Engineering, our priorities are
1) Safety
2) Reliability
3) Security
In the past, we achieved this through physical barriers. The theory was that if someone got inside the plant, they could just walk in to any building, throw the gear in "HAND" and burn up a bunch of valuable gear. Security wasn't even on the page.
Then the Internet happened. The office commandos weren't satisfied with merely talking to the operators. Now they wanted to see the data. So some bright IT guy found a way to extract the data using NetDDE from the SCADA or DCS system and everyone thought all was well with the world.
Then came viruses, worms, and other such malicious software. At first, it wasn't much of a risk, so managers looked the other way. Pretty soon, however, they figured that this was an issue.
Now they looked at their bright IT guys, and GASP! They're stumped. This stuff is happening so fast and furiously that they can't keep up. The engineers are scared too. By attrition, the operators have been retiring, and now we operate plants with many fewer operators and technicians than we used to. We don't have the staff to operate the plant by hand --even if it were possible. In many cases, it isn't.
Now you see why this fight got started. Engineers do not appreciate the "I'll fix it when it hits the field" attitude of most software and IT houses. We work long and hard to understand what we're doing BEFORE it hits the field. We will not cut any slack with an IT person who doesn't have a plan for the future.
In fairness to the IT guy, not only don't most of them have future plans, almost nobody can plan in to the future. This is a red-hot field with advances that leave everyone else gasping to keep up.
What we need, and what I personally have set up, is a hardened sacrificial database for the office droids to pound on. If they kill the database with a malformed SQL query, that's their problem. We'll backfeed the data to them when we get around to it.
In the end, however, I'm skeptical of the value in letting office commandos have direct access to process data without discussing it with an operator or the plant superintendent. The office people often don't have other background information that might help them process the data. They don't know when calibrations were done, how far off the calibrations were found to be, or what other equipment maladies may have happened while measuring the data.
I would rather they talk to the operators. Then they'll know what REALLY happened the night before...
Post a Comment