help with Q & A

T

Thread Starter

Tim

Hello,

I work in a power generation company that does not have a QA department. The coding is all done in PLC logic. The system goes through a static test before shipment. I am curious how QA applies to the power gen world if at all, or if this is just an idea that is in its infancy. Currently, the process is to test as much as possible prior to shipment, but system may ship without being fully tested. When this happens incomplete field testing takes up the slack. This has me particularly nervous, however, it is the culture to continue work this way and I alone cannot institute new practices. Typically, in this environment, I am curious who is liable. Is it the engineer who designed the system even though managers insist the system ship? Is it the customer for not taking responsibility with the system? Test forms are published and usually signed off by the customer. i do not know if this constitutes a legally binding responsibility or not.
 
Tim,

I would ask you to describe "fully tested."

Next, I would ask you to describe which functions are not being tested before shipment.

I would ask how you obtain the information necessary to test functions before shipment.

Based your experience with the knowledge level of Customers coming in to witness the factory testing, do you believe they are capable of determining if critical functions are working correctly or not? Do you believe the Customer personnel rely on the experience and expertise of the engineers at your company to ensure critical functions work properly either by factory testing or during commissioning?

There are several companies in the power generation business with ISO 9000/9001 certification, and TUV Certification as well. Those are both forms of Quality Assurance.

As for legal liability, if it comes to that the only winners are the lawyers--on both sides!
 
Fully tested to me means that the system behaves as dictated by the test forms. Of course, I would love to provide evidence of unit testing as well just for peace of mind internal to the company. Unfortunately, much of the PLC program is hacked together to achieve the sequences, and causes global consequences when changes occur. This instigates a policy of retesting the entire system if any change is made.

So, many times the systems go where only some of those sequences work. Someone needs to fix it out in the field. But with changes having such a large impact, I fear something accidental can happen from within the code.

As far as customer trust, I notice most customers think of 1 issue and latch onto it. Whether it be hot standby, how the generators sync, etc. Very few really want to know how all the features work and punt when they are explained. Some witness test are smoke and mirrors where the system isn't ready but demonstration proceeds as though it is.

Do those companies that have the QA you mentioned actually have a QA group for software testing and verification? I am curious if the rest of the world is a hack and slash approach when it comes to PLCs.
 
Tim,

Not being able to see the "test forms" to know what kind of detail is involved I can't really comment on that.

I can only speak for a couple of power generation companies with ISO 9000/9001 certification. It's the intent of the procedures developed as part of the certification process to ensure that critical functions (trip and control) are tested and meet technical regulations and standards.

Most of the software those companies produce are assembled from hundreds of standard routines that cover a very wide number of machines and auxiliaries. I wouldn't classify it as "hack and slash", but it would be very cost-prohibitive to write every rung or function by hand for every job. Since many units share the same auxiliaries and sequences, the software necessary to execute and monitor them can be standardized into "modules" and then these modules are assembled together to form the project that is particular to a job.

The function of factory testing in this case is to demonstrate, to ISO procedure standards, that the equipment can be started and stopped and is protected, that fuel or steam is properly controlled as best as can be simulated. And, these companies have some very good simulators--both software simulators and hardware simulators.

Is there a QA person who checks every rung or line of code, or who reviews every factory test report? No. The QA personnel for both companies is pretty much limited to checking to make sure that all the hardware is properly documented, and that wires are where they should be and the drawings reflect the as-shipped condition.

I would agree that most Customer personnel latch on to one feature or function--usually something they had to get familiar with because it was an issue some time in the past. For them, a good start is any one that ends in synchronization--regardless of the number of alarms annunciated in the process. They just keep mashing the 'Alarm Silence' button and hopin' and prayin' the unit synchs and loads. Most sites have either disabled the Alarm Printer or have long since tired of loading paper and changing ribbons, and many have disabled the audible alarm horn. If the unit doesn't synchronize they don't even know how to check which alarm is preventing them from doing so. They usually just shut the unit down and re-start it and hope and pray for the best. So, they're not the best people to send to a factory test.

I can't say for sure how companies that provide PLCs for turbine control application assemble their software. I have limited experience with PLCs as turbine control systems, but I have seen a couple of sites where it's pretty clear what you said has happened. Many people seemed to have edited the software at some point, and none of it really seems to fit together very well, and making any changes seems to result in an inability to download or some dire error message, resulting in reverting to the as-found sequencing to get the machine "running" again.

You seem to be very conscientious and honestly sincere about wanting to produce and provide quality software and projects. I hope you can reconcile your personal standards and convictions with "corporate" directives and requirements. A long time ago I learned that, "Engineering is a series of compromises." That's very true, for very many different reasons. Engineering and economics have to go hand in hand, but machinery- and human protection must take the first priority--always.
 
Top