Safety Concerns

M

Thread Starter

mark tompkins

Hi,

I'm really enjoying this discussion, and wish everyone all the best of luck on this project! I have some prior experience in process control
(I currently work in mobile dispatching now), so in some respects, I'm retired from my controls career. I always felt that there was a need for this kind of thing. The topic is just too big to allow any proprietary interests to mis-manage. But before I join in, I need to understand some things.

I am jumping in the middle, so if this has already been dealt with, my apologies in advance.

I'd like to voice my concerns regarding safety:

The Safety Issue

The appeal of creating an open source project to deal with a very high risk software project is courageous. It is likely that if this project is successful, it will make the world a much better place. A fundamental raison d'etre is to enhance safety, by creating enhanced quality, consistency, and usability.

But let's not forget - the risk. Or rather, the risks (off hand, I'm sure there are more):

1. If the LinuxPLC fails to work properly (programmer error), there could be serious property damage, or loss of life. At what point, and under what conditions, will software produced by this project be deemed ready for prime time? In the mean time, what measures are being taken to make sure that no one uses the alpha/beta software inappropriately? Perhaps that is a long ways in the future. However, I think that safety must be the highest priority. Period.

2. If people misuse it, then what? Who's liable? Is there any way to protect against misuse? If the software is freely available, what is there to stop anyone (engineer or no) who is under constraints to cut corners using a half-baked tool?

3. Upgrades to production systems. Will every version of the software be tested to ensure compatibility with all prior versions? Will there
be an explicitly defined policy for implementing new version upgrades? Is the product being architected so that it can be upgraded while it is
running?

4. Liability. If there ultimately is a catastrophe caused by the use of software created using this project, for whatever reason, what then?

There is a responsibility present with these efforts that doesn't exist for those people who are commited to slaying the evil empire. One of
the smartest things Bill Gates ever did was to make sure that it would be very difficult to use his products for real time systems. It freed
him to generate revenue by charging for upgrades of buggy code. It may turn out to be his downfall. If so, then history will record it. I
think it is up to everyone to make sure that the decision by LinuxPLC to assume the risk doesn't ultimately benefit proprietary interests, for
all the wrong reasons.

I think that the this project is ideal for Open Source development. And, I think that the direction that it is currently on is the correct
one (build something, test it, re-think the concept). However, I think that the aspects of this project that make it different from
applications that are not safety critical must be clearly understood in advance. And they must be properly managed. If it hasn't already been
done, policies and practices need to be designed and implemented to take care of safety issues.

Otherwise, LinuxPLC could turn into a real nightmare.

best regards,

Mark




_______________________________________________
LinuxPLC mailing list
[email protected]org
http://linuxplc.org/mailman/listinfo/linuxplc
 
C

Curt Wuollet

> 1. If the LinuxPLC fails to work properly (programmer error), there
> could be serious property damage, or loss of life. At what point, and
> under what conditions, will software produced by this project be deemed
> ready for prime time? In the mean time, what measures are being taken
> to make sure that no one uses the alpha/beta software inappropriately?
> Perhaps that is a long ways in the future. However, I think that safety
> must be the highest priority. Period.

I agree. But, due to the very nature of the project, development code will be available. As volunteers, with no implied warranty or guarantee we must disclaim any and all responsibility. We have no contractural obligation at all. All risks are borne by the user and it must be so stated.

> 2. If people misuse it, then what? Who's liable? Is there any way to
> protect against misuse? If the software is freely available, what is
> there to stop anyone (engineer or no) who is under constraints to cut
> corners using a half-baked tool?

Nothing, in exactly the same sense as if he were to write it himself.

> 3. Upgrades to production systems. Will every version of the software
> be tested to ensure compatibility with all prior versions? Will there
> be an explicitly defined policy for implementing new version upgrades?
> Is the product being architected so that it can be upgraded while it is running?

Very unlikely. It is almost guaranteed that the software will evolve incompatibly from version to version.

> 4. Liability. If there ultimately is a catastrophe caused by the use
> of software created using this project, for whatever reason, what then?

As long as it is stated up front that we can't be held responsible, the person who actually did the deed would be responsible.

> There is a responsibility present with these efforts that doesn't exist
> for those people who are commited to slaying the evil empire. One of
> the smartest things Bill Gates ever did was to make sure that it would
> be very difficult to use his products for real time systems. It freed
> him to generate revenue by charging for upgrades of buggy code. It may
> turn out to be his downfall. If so, then history will record it. I
> think it is up to everyone to make sure that the decision by LinuxPLC to
> assume the risk doesn't ultimately benefit proprietary interests, for
> all the wrong reasons.

As the Linux PLC project has no assets, is not a legal entity and cannot enter into any agreements, we must simply let the chips fall.

> I think that the this project is ideal for Open Source development.
> And, I think that the direction that it is currently on is the correct
> one (build something, test it, re-think the concept). However, I think
> that the aspects of this project that make it different from
> applications that are not safety critical must be clearly understood in
> advance. And they must be properly managed. If it hasn't already been
> done, policies and practices need to be designed and implemented to take
> care of safety issues.
>
> Otherwise, LinuxPLC could turn into a real nightmare.

I realize that these are not the answers you would like to hear, but I am making them clearly understood. This is for the forseeable future an
experimental project with an all volunteer makeup. Even if it were rational to take responsibility for how it or derivative works could be used, we quite simply can not do so. So don't count on this to run your iron lung. And don't count on having anyone to sue if you do. Those who are in a position of deploying this for remuneration do so at their own risk.. If we
were selling this it would be a whole different story. That said, I would sooner have a Linux box running my iron lung than many of the
alternatives. But then, I never said that I wasn't crazy.

In this regard, we may actually benefit from UCITA. It says essentially that any and all problems are yours when you accept the software.

Regards

cww

_______________________________________________
LinuxPLC mailing list
[email protected]
 
J
I think it is important to realize that software is NEVER to be used as a means of safety control. If I am an integrator, and build a machine using a AB PLC, and the operator opens a guard door and gets their arm chopped off
because the safety system fails to operate, AB isn't responsible, it is either me, or the maintenance staff at the customer location.

Same scenario. If the machine is built properly, the software handles events during normal operation, and during controllable and semi-controllable failures. Catastrophic failure, and operator intervention procedures should all be hard-wired with redundant circuits where
appropriate.

I don't care whose system you use, if you run an E-Stop button into a controller, and depend on the controller to stop the machine, you are asking
for trouble.

Just my $.02

--Joe

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Joe:

Not that I don't agree with you, but there is a bit of reality that needs to be considered here. If a machine operator "gets their arm chopped off", that operator's lawyer will have a field day, sueing everyone whose name was even
associated with the product. In other words, the idea is called "sue everyone, let the courts figure out who is responsible". This happens all the time and some astonishing results can and do happen. At least here in the states, there is NO SUCH THING as a logical court of law. When it comes to product liability, all a lawyer has to do is generate a bit of doubt about the "properness" of a design and millions of dollars will get handed out. Now, I don't know about
you, but I would be hard pressed to (financially) be able to defend myself here in my home town (Saginaw, MI) let alone just about any/every other jurisdiction in the country.

Ron

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
V

Vic Ellescas

I agree with Joe Jansen and Curt. Software is a software and Hardwire is a hardwire. I've seen this questions before about software safety, upgrades, and responsibility already and it's been already answered. If it looks like a PLC, acts like a PLC, talks like PLC, then it's a PLC, then I'll use it and it's my resposibility. It's open! It's like asking who's responsible for C or C++ or Perl etc? Who's responsible for Linux? Who's responsible for Y2K bug anyway?

Please continue your interesting discussions on Puffin PLC codes.

Vic Ellescas,
Controls Engineer
Sverdrup Technology


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
K

Kannan Moudgalya

Hi,

Verification of correctness of computer programs is an active area of research and there are tools using which one can improve the reliability.
Languages, such as Esterel, are designed for this purpose. Nevertheless these probably take care of only higher level programs but not low level
ones, such as, data acquisition. So the reliability of data acquisition could still be an issue.

One practical way to address this issue is to use this software in an almost production like, but NOT mission critical applications. If we can
identify the types of PLCs (including possibly the brand, model, etc.; one or two popular and perhaps reasonably priced ones will do) for which this software is being targetted, we can find volunteers who can come forward to do the testing: the volunteers can buy one or two PLC and do the testing. I don't mind doing this, if necessary.

Kannan.


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
M
At 06:23 AM 5/16/00 +0530, Kannan Moudgalya wrote:

>Verification of correctness of computer programs is an active area of
>research ...

Yep. But I vividly remember attending a presentation at the 1967 Spring Joint Computer Conference about proving program correctness.
That is now 30+ years -- a long time in 'computer time'.

While it might be an active area or research, please don't get upset if we continue on with the LinuxPLC before the research into program correctness is complete.

Mark


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
P

Paul H. Gusciora

Actually, some companies make triple-mode (and higher) redundant PLCs for safety interlocks used in the petrochemical industry. Triconex (bought by
Foxboro, bought by Siebe) makes one that works quite nicely. Boards can be removed while the system is running. When the boards are re-inserted, they synchronize program code and current state and regain design redundancy
very quickly (a matter of seconds).

With this type of system hardware, the biggest risk of failure comes from sensor and/or actuator failure, followed by bad programming. It is often
hard to test the equipment which is expected to run for 24+ months without scheduled shutdown. The only solution to date is to program for and
schedule periodic testing online: bypassing the actuator (which has contacts to tell the program that a test is occuring), simulating an input
to a sensor that should result in actuators moving, and watching the signal propagate all the way through the logic to one actuator moving.

Under most conditions the software protects the plants. The only other thing protecting the plants are mechanical devices (rupture disks, relief valves, fusable links). The software tries to keep those from actuating.

BTW: although Triconex (and Honeywell FSC Fail-Safe Controller) achieve synchronization and voting on a proprietary bus, the same thing could
happen on an Ethernet link. DEC essentially used equivalent logic to implement DecClusters. When one node (Joe) of the N in the cluster stops
responding, the other n-1 nodes exchange messages like "Hey, where's Joe?", "Do you see Joe?" "He was here a moment ago" until they finally reach
consensus and vote Joe out of the cluster. If Joe becomes visable again, the other nodes make certain that Joe is synchronized before admitting it to the cluster.

Paul H. Gusciora
San Rafel, CA

Algorithms are free. What is expensive is interfaces to algorithms, and the engineering interface to apply them.


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Paul H. Gusciora:
> When one node (Joe) of the N in the cluster stops responding, the other
> n-1 nodes exchange messages like "Hey, where's Joe?", "Do you see Joe?"
> "He was here a moment ago" until they finally reach consensus and vote
> Joe out of the cluster.

This algorithm must get really fascinating with Byzantine faults.


Jiri
--
Jiri Baum <[email protected]>
Windows is not popular. Windows is *widespread*. Linux is popular.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
J

Johan Bengtsson

Folks, he's still here! I have not seen him, but I have heard from him... <grin>


/Johan Bengtsson

----------------------------------------
P&L, the Academy of Automation
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------
 
P

Paul H. Gusciora

I apologize for selecting "Joe" for the node name in the hypothetical example. I should have picked something computerlike like "Tron", "Hal", or
"Sal".

BTW: The DEC clustering software really worked. But there were big spikes in network traffic during voting a node in or out of the cluster. It was even more exciting with disk arrays with multiple ports for several cluster nodes to directly access -- there was a mechanism to share information about disk activity.

Maybe we could prevail on the new owners of DEC (Compaq I think?) to release the source of VMS. Although I prefer flavors of Unix for ease of
command line scripting, VMS was just about bullet-proof and used its hardware effectively. It remained completely responsive to high priority UI
tasks even with low-priority CPU intensive and disk intensive tasks saturating CPU and I/O -- unlike NT workstation which seems to lock up for
many minutes with low cpu and I/O activity after initiating a network directory service. Part of the efficiency is due to VMS having 16 priority
levels (+16 more "real-time" priority levels) -- NT only has 3 (+1 for the null task), and queueing I/O according to the base priority of a task. The scheduler increased priority of tasks (up to 3) if the task was suspended, I/O bound or system service bound, and decreased the priority (but no lower than the base priority) if the task was CPU bound. VMS also allowed explicit control of virtual memory working set (default, minimum, and maximum) per task. The only better scheduler (maybe just as good) seems to be used by VM/CP for IBM mainframes running VM/CMS, VM/TSO, and now
VM/Linux.

Paul H. Gusciora
San Rafel, CA

Algorithms are free. What is expensive is interfaces to algorithms, and the
engineering expertise to apply them.


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C
Hi Paul,

I wouldn't be at all surprised if they have this stuff for DEC UNIX^h^h^h^h^h^h^h^hOSF1^h^h^h^hTru-64 :^) Before the Alpha they clustered Vaxen and other low power boxes for high availability. I wouldn't work too hard to get VMS except for my museum. Look what the guy did after that. And this is from someone who has a PDP/11 in their basement. BSD UNIX saved DEC from collapsing much sooner. They made some of the best products at the time, they simply didn't read the writing on the wall. (Like some other companies we know) I'll
spare you the telling quotes from their illustrious leader. The legacy lives on however, by this time nest year we will be running our enterprise system on a big, nasty, Alpha box with Red Hat Linux. :^)

Regards,
cww

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Top