Project: Biopharmaceutical filtration automation July 26, 2005

July 26, 2005

The foundation of our automation design is device control managed by control modules. The following device control modules are to be delivered with this project. Not listed are other control modules we will implement for simple functions that do not interface directly with I/O devices.

One control module not used for direct device control is the Acquire/Release Controller (ARC) that is used for the arbitration of shared equipment. Batch automation systems typically provide arbitration functionality for shared equipment but we have found that arbitration is often necessary when operating a facility without batch recipe management. Our solution is to push device arbitration into the controller assigning an ARC module to every shared resource. For this project, a valve manifold between the harvest tank and a filtration skid will have an ARC module. Both the harvest tank and the filtration skid must manipulate the valve manifold independently of each other. Sequence code for the harvest tank that manipulates the valve manifold must first request and acquire the manifold. If the manifold is currently acquired by another resource (for example, the filter skid), the ARC module ignores the harvest tank requests. Once the ARC is released by the filter skid, a request by the harvest tank will change the ownership to the harvest tank preventing acquisition by other users.

Another benefit of this type of arbitration is that it allows for the creation of owners (such as an operator) outside the batching system. We provide an ARC faceplate accessible to the operator by clicking on a graphic object that displays the current owner. The faceplate displays the current resource owner, and a drop down for manually requesting the resource. One of the options in the drop down is ‘Operator.’ If an operator acquires a resource—for maintenance or other manual intervention—automatic sequences will not be allowed to manipulate the resource until released by the user. The “Request” and “Release” faceplate controls are secured such that operators may request a resource but only a supervisor may release a resource
ARC operator faceplate We have implemented each control module type so that the code is never duplicated for any control module type or for any subset of a control module. For example, this project includes 106 valves to be controlled by the DVC control module. We have only one copy of the DVC code that is used by all 106 instances. The data for each instance is moved into working registers used by the DVC code, which moves the results back to the instance registers. This design significantly reduces the amount of code we must write, maintain and validate. In general, anytime we find ourselves writing duplicate code we will turn that code into some type of subroutine that can be called whenever needed.

Multiple modules use some of the same functions. For example, AI, DB, PID, PIDB, TOT, and VMC use analog input processing (rescaling, low cutoff, alarming, low pass filter, etc.). Therefore, the code for analog input processing is a subroutine called by each of these control modules, which ensures that all have the same functionality.
The next post will discuss the interlocking design strategy for the project.

Do you have experience and expertise with the topics mentioned in this content? You should consider contributing to our WTWH Media editorial team and getting the recognition you and your company deserve. Click here to start this process.