The importance of Simulation and Factory Acceptance Testing, Part I

I want to outline some critical steps in projects that many end users still overlook, and those are functional description definition, process simulation, and factory acceptance testing. I think that the value of a proper simulation and factory acceptance test are often overlooked by many end users when they are executing projects. However, over the years, LSI has found that proper simulation and factory acceptance testing is critical for many reasons within a project and they are not limited to the following:

  • Reduced time on-site testing and troubleshooting software
  • Faster start up
  • Less end customer changes during startup
  • Less stressful/smoother startup

In part I of this blog, we will discuss the first step in having a good simulation and factory acceptance test, and that is having a good process/functional definition. Certainly, the first component to have a good simulation and factory acceptance test is to agree on how the process works and what the end user wants to accomplish during the project. The key is to document the process and how the operator will interact with the process on the front end so that clear expectations are set and so that the software can be written as efficiently as possible. This is true of a new process or of one that is undergoing a major retrofit. I can think of two examples of where the process is existing, but where the process definition and functional specification process has been or will be critical to the success of the project. One of those is a process in a steel mill that has not changed for many years and is almost all discrete functions. The other is a feed mill that has become heavily batch oriented in which the process has changed drastically since the plant’s inception. In the first case, the code was written by the OEM in such a way that made it difficult to troubleshoot. As a matter of fact, this customer states regarding the importance of a good functional description: “Changes and improvements that have been performed on various operating systems (fluid, pneumatic, electrical, control, etc…) will impact how the original system function has changed.  In order to properly prepare for project development and implementation, you must ensure that all impact and aspects are included.  The functional description is a necessity in order to ensure all parties involved understand and agree how the system will operate.

In the latter project, 7 different programmers have touched the code and have had 7 different ideas on how to accomplish things. There is code in the PLC that is simply “dead” and does nothing at all. In both cases, the end customer wants a readable, functional, and expandable set of code in the end. The processes are vastly different, the PLC brands are different, but what is constant is that both have agreed that defining what the process does and how the code will look is a critical step in the project. From the end user standpoint, they will gain the following benefits:

  • They will be absolutely positive how each and every part of the process functions and how the software was written
  • The maintenance and operations staffs will get exactly what they want because it is well defined
  • They will have an operator training manual for training new maintenance and operations personnel

LSI has used many techniques to document processes, from flow charts, logic diagrams, HMI screen samples, and in some cases, just a plain description of the process with words. At certain times, our end users have a format that they would like us to follow, and in other cases, there is not a predefined format to follow. The most successful way to document a process and how the operator will interact with the process through the HMI is to be as graphical as possible. For that, logic diagrams and flow charts (we have even pasted sample Sequential Function Chart code from the proposed PLC program in the document as a flow chart) are extremely useful. The most important thing is that a customer can understand what is being conveyed very easily, and this is best done by producing something graphical in nature. Another benefit of this approach is given by Nick Riggio, LSI’s Golden, CO branch manager: “[taking the graphical approach above] allows for the customer and us to have code reviews along the way. They actually get to see what their code will look like in the end and comment on it during the project.” Nick also states the following: From a technical standpoint, we have to detail all of the interlocks, permissives, etc. in the process. We can also drive out any anomalies that affect the system as well. The customer will end up with more organized, robust, and easier to troubleshoot code.”

In part II of this blog, I will discuss simulation techniques and why simulation is important; and in part III I will discuss what an end customer can gain out of a good factory acceptance test.


About Jim Gavigan

Business Development Manager at Logical Systems, LLC
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s