Hello everybody .. Here is the case

Assigned for a new project (small / medium size one) that will use DCS as a control system.
Tendering for hardware only .. Software implementation will be done inhouse (By the end user engineers) .. this will include:
- IO assignment
- 3rd party Soft IO integration
- Logic/Sequence Implementation
- graphics implementation
- Alarm Configuration
- Historian Configuration
- Report customization

The main challenges are the following:
- Vendor will provide HW cabinets complete furnished and HW FAT tested .. This test I am expecting it to be very basic
- No SW FAT of course from the vendor
- No SAT or commissioning support
- Vendor refused to provide DCS "certificate of compliance"

Questions:

- By law .. "certificate of compliance" is mandatory and system can't be handed over without it - Is this correct?

- Test will be done internally (By the end user engineers) .. No FAT will be held - Is this accepted? .. By investigation I knew that "IEC 61511" recommended FAT and put FAT procedures for testing the system .. But this is recommendation .. not a must - So handing over ther project without FAT or SAT documents, just internal testing - Is this accepted?

 

By law?

You didn't say which country or region of the world this project/installation is happening in.

Many OEMs and control system integrators are now charging extra for FAT/SAT services--and those prices are high. There are two reasons for this: First, no FAT/SAT lowers the cost of the job to the Customer and frees up engineering resources for other jobs. Second, FAT/SAT is seen as a possible profit-making opportunity, and because many engineering resources dislike performing FATs/SATs and don't like interfacing with Customers or doing the set-up work for the testing they are internally complaining that it is onerous and should only be performed when the contract requires it/them to be done.

If one looks closely at the cost of an FAT/SAT included with a job versus the cost of performing an FAT/SAT as an option to a job, one will see the costs of the option are usually higher--often much higher--than the cost of including the FAT/SAT with a job.

Capitalism at its finest. "Profit is our most important product." (Actually, managers and General Managers can claim very high profit margins (percentages) by collecting extra monies for FATs/SATs--and that's how they are rated and measured, many of them: on their ability to make profits. I get it: business isn't a charity. But providing value for money should be what it's all about, and too many FATs/SATs simply don't. Read on to find out why.)

Most FATs/SATs are boondoogles for Customer personnel. Oxford's defines a boondoggle as an unnecessary, wasteful or fradulent project. I define it as a gift to certain employees to allow them to travel somewhere in the world on expenses and get away from the plant. Most FATs/SATs I have been involved with (and there have been more than a few) had a difficult time with Customer personnel being on time and on site and staying for the entire duration of the FAT/SAT. They were more interested in shopping and sight-seeing that sitting and participating in the FAT/SAT. Most of the time the people sent to the FAT/SAT are not all that technically savvy when it comes to the finer details of plant operation; most are simply interested in looking at screens/displays and finding fault with them and demanding they be changed than in observing start-up or shut-down processes being simulated. The people sent to FATs/SATs are usually being "rewarded" for being supportive of management decisions and enforcing management and safety rules and regulations. And, they don't really view the FAT/SAT as "work" so they don't really come prepared or want to be engaged as much as they should be.

Of course, there are exceptions to this stereotype, but they are few and far between. Engineering resources never know what to expect, and they can be very well prepared to demonstrate their system and even have some detailed questions they want answered to help improve their product--but, usually, the people sent to the FAT/SAT aren't the right people to properly observe and spot problems or potential problems, or they can't answer detailed questions. It's really very hit-or-miss--mostly miss in my experience, with a few notable exceptions. (And it should be the other way 'round--mostly hit and very little miss.)

Most Companies buying a control system rely on the provider to detail what should/shouldn't be done during an FAT/SAT. Very few actually participate in the process or review what will or won't be done.

Finally, an FAT/SAT is a great opportunity to fine tune processes and to share information. Often, its an opportunity squandered, at great expense.

 

Thanks CSA .. I have the same point of view with some differences.
Regarding the technical part .. it can be done, but my main concern about the official/legalization part:
- FAT/SAT documents are mandatory as a project deliverables? - My answer is yes, but what is the code/standard that support/change the answer?
- DCS certificate of compliance .. from the vendor - This is a big concern for me.

I can imagine if any accident happened in the plant and investigation team couldn't find a suitable root cause .. these missed documents/procedures would be suitable for them.

 

Regarding the Law .. This plant is to be built in several places worldwide (Europe, Far East, .. etc)

 

How are you going to get a suitable answer when you can't state where the project is going to be located???

Which vendor is NOT going to certify their equipment is in compliance?

FAT/SAT deliverables are mandated by the contract. The contract states what is and isn't required, and quite often states with some VERY VAGUE terms that the local technical regulations and standards are to be followed--with no specifics whatsoever. In some places, for some industries and processes (chemical plants or refineries, for example) it's possible there are local technical regulations and standards for some parts of the equipment to be certified or tested--but you are going to have to check with each location to see what their requirements are. Some could just be insurance company requirements (don't forget those!).

Some companies have entire departments which do nothing more than research and follow technical regulations and standards and applicable laws in various parts of the world so their equipment can be certified. Does the company you are considering for supply of the equipment have such a department? (If not, perhaps it should.)

Again, it's the contract which most often defines what are the deliverables, and often the contract cite specific requirements when they are known. If the "plant" is to be built in several places around the world, I would suspect someone needs to so some researching if it hasn't already been done. This is not a simple task, either.

Good questions, all. Difficult answers.

 

First thing here is you mention 61511, so is it a safety system or a DCS?

If it is a safety system there are lots of reasons this approach might be taken, one being the requirement for competencies to managed and maybe the client does not believe the vendor has these competencies and wishes to manage that portion of engineering themselves to achieve compliance with 61511. This might be only part of many phases to get to the end product.

As for testing in general, some of the comments I see here are disturbing to say the least. A few points

1) If the customer feels that and FAT or SAT is a "boondoggle" then it is usually the clients fault for lack of adequate specification or management. Remember who holds the purse strings, this is the top level of control.

2) If 61511 applies you are obliged to aspire to test every expected combination of inputs and as many of the unexpected ones as reasonable, including things like single scan events and the like. What this tells us is that for many system a human toggling switches and turning knobs is no way ever going to cut it, so you need a simulation/test controller to sequence the inputs for you. Either I/O to I/O or reach in with OPC or similar.

3) regardless of 61511, the above mentioned approach with a test controller is really how most people should be doing things these days, but I rarely see it. The level of sophistication available for such testing is fairly high for a fairly minimal effort, there are no excuses really. You can get right up to driving I/O and having a webcam take a snap of the lights on the cards etc, using Selenium and scripting tools to drive HMI, etc etc . And also the speed at which tests can be done ar 10-20 fold of a human simulator, sometimes much more, so you can test a lot more cases, this is what you want. Especially things like single scan events, I know of at least one case where a single scan event finally lined up on controllers in service over 12 years and ended up costing <big mining company> well over a billion dollars, luckily no loss of life.

4) Vendors rarely integrate well. I am sure there are exceptions, but usually they don't pay well enough to attract or retain real talent, this is the first problem. You really need a good systems integrator, it is a specialty and the more you do the better you are at it, and tools are accumulated etc etc.

5) A good integrator will evaluate the factors involved, size, complexity, consequences of fault/failure etc and design an *appropriate* FAT and SAT. I would expect if I wasted the clients money at FAT or SAT that would be the last one I would ever be doing for those guys. That includes inadequate lame ass approaches, like no automation of testing.

6) Every single client I ever had that resisted rigour in design and testing changed their mind after they saw how much the right amount of "front end loading" in these processes saved so much time and money in subsequent parts of the exercise. It's costly to have a one day shutdown brownfields cutover extend out to two weeks of the entire plant down, I have seen it. It's especially embarrassing when it becomes obvious a modicum of testing would have identified problems quite easily.

Testing shouldn't be a joke or a waste of time, often it is the last chance to catch something before you cost the client a lot of money, or worse. Plus often it is the first real hands on involvement of the client to see exactly what they are getting and verify their intended outcomes, making them a stakeholder in outcomes.