On 08/06/2013 11:27 PM, Carlos E. R. wrote:
>
> You simply do not update the machines, ever.
>
> I’m serious.
>
> They are kept on an isolated section, without network if it can be. They
> could be in kiosk mode, so that nothing can be run in them aside from
> what is strictly needed.
>
> If you consider updates, you test that on a separate machine, with
> control hardware and software, and test it. If it goes right, you
> schedule downtime to do it (and a full backup to undo the upgrade if
> needed). Even replace one machine with another, but that is not often
> feasible (calibration is gone, for instance)
>
> Yes, you can go for a full support commercial alternative, but that is
> no guarantee either (a promise of a solution leaves you dead in the
> water till it is found). You still have to test it yourself - specially
> because you have to verify that the control hardware remains working
> within parameters.
>
>
> (yes, I have worked in that sector, and updates were forbidden)
>
Wow, this is all very interesting, and great ideas to think about, too.
It is all in the theory stage for me right now, but I hope to be able to
implement this one day.
So for example, say you have an OPC server (there are some that run on
linux machines now), set up in a redundant configuration in case one
fails. The OPC server communicates with the HMIs for the operators, and
passes operator signals through to the PLCs. Then also the OPC server
takes PLC data, and makes it available to a historian through OPC,
running on another computer. This data is then made available to the
operators to look at trends, but also to managers so that they can make
decisions. So at some point, the network has to have a connection to the
outside world.
The critical components that you would have to make sure do not
experience downtime would be the OPC server and the operator HMIs,
because these directly affect plant operation. So if the data historian
was maintained separate from the OPC server, then only this machine
would have a direct line to the outside network, and it would not be
critical to plant operation. That way, being the one machine that is
most likely vulnerable to security threats, it could also be the one
machine that you could do regular security updates. The others would
only be updated during plant downtimes.
Now what I am seeing here is that a configuration like this could be
done entirely with openSUSE and would not require a support package.
Although I suppose the danger in that is that then the company has to
rely on me until other people are trained in how to use openSUSE. If I
get sick or die in a car accident before other engineers are trained in
how to use the system, they would have nobody to call.
–
G.O.
Box #1: 12.3 | KDE 4.10 | AMD Phenom IIX4 | 64 | 16GB
Box #2: 12.2 | KDE 4.9.2 | AMD Athlon X3 | 64 | 4GB
Laptop: 12.3 | KDE 4.10 | Core i7-2620M | 64 | 8GB
