September 7, 2005
As I’ve been saying for the past few weeks, no HMI hardware has arrived this week either, so we continue to develop equipment module logic in parallel with the software design.
The automation design on this project is divided into two main documents grouped by major process system– Microfiltration (MF) and Ultrafiltration (UF). The UF system design specification will be submitted later this week. The MF system design document is roughly 150 pages and includes design details for the follow control modules.
Equipment System
Control Modules
Harvest Vessel 22
22
Harvest Vessel Temperature Control
10
MF Skid Feed
11
MF Skid Retentate
6
Shared Equipment
17
CIP Distribution
4
Misc. Support
12
PLC Peer to Peer
47
The last two control module groups may require a little explanation. The Misc. Support modules include basic application support functionality. This includes 5 DI (discrete input) modules to monitor communications with other PLC processors on the network. If communication to another PLC is lost, the local DI module will generate an alarm. The Unit Status modules described in last week’s post are included in this group as well as modules that manage the BatchEM recipe management interface similar to what is commonly known as PLI (Phase Logic Interface) with off-the-shelf recipe management products.
The PLC Peer-to-Peer modules provide monitor and control functionality across PLC processors. For example, when sanitizing the harvest tank, the piping is opened back to a fermentor, which is controlled on another PLC and the code is being developed by another integrator. Therefore, a module is required to read the transfer line trap temperature so the harvest sanitization sequence can verify achieving and maintenance of the proper temperature during the sequence. Other modules provide handshaking across PLC processors for the transfer of a batch across control hardware boundaries. Still other modules provide access to arbitrated shared equipment across PLC processors.
Experienced PLC programmers are familiar with writing code for communications across PLC processors. DCS systems have historically reduced or eliminated the need for this type of coding by automatically resolving tag references globally across the entire system including controllers. Systems that provide automatic cross controller communications simply by referencing a tag/attribute value significantly reduce initial engineering, the volume of custom code, and long-term code maintenance. The 47 modules for PLC peer-to-peer communications for the MF system are not necessary in other systems.
The MF design document includes detailed sequencing design for the following 25 equipment modules.
Harvest Vessel Agitator Control
Harvest Vessel CIP Airblow/Drain Sequence
Harvest Vessel Drain Sequence
Harvest Vessel CIP Flush Sequence
Harvest Vessel Inactivation Sequence
Harvest Vessel Level Control
Harvest Vessel Post-SIP Pressure Monitor
Harvest Vessel Pre-SIP Pressure Hold Test Sequence
Harvest Vessel Pressure Control
Harvest Vessel Post-SIP Pressure Hold Test Sequence
Harvest Vessel Purified Water Drop Control
Harvest Vessel Receive Sequence
Harvest Vessel Safe State Sequence
Harvest Vessel SIP Sequence
Harvest Vessel Temperature Control
MF Skid CIP Airblow/Drain Sequence
MF Skid Flush Sequence
MF Skid Feed Flow Control
MF Skid Filtrate Flow/Pressure Control
MF Skid CIP Flush Sequence
MF Skid Integrity Test Sequence
MF Skid Membrane Drain Control
MF Skid Concentration/Diafiltration Processing Sequence
MF Skid Retentate Pressure Control
MF Skid Safe State Sequence
All of these equipment modules are available for individual operation from the HMI. They may also be operated and sequenced through our BatchEM recipe management application. Providing access to individual phases outside of a recipe is functionality we have found to be missing in most batch applications. This design provides the maximum benefits of recipe management without eliminating the flexibility to operate the plant under exceptional conditions, which are frequently not so exceptional after all.
The UF design will be completed next week. Two weeks are scheduled for the customer to review and provide feedback on the MF design.
August 30, 2005
No HMI hardware has arrived this week either, so development of the user interface must remain on hold.
However, work continues on equipment module design in parallel with equipment module development. We expect to complete the first pass design on all equipment modules by next week. The design will then be given to the customer for review. It is normal for the customer to request a few changes with their review, but we expect these changes to be functionally minimal. Again, we have been developing equipment module code without an approved design document to stay aligned with the project schedule.
Speaking of schedule, we have received a modification to the project schedule. Originally, we planned to complete our software by the end of September for factory acceptance testing (FAT) at the skid vendor’s site in mid-October. The newly scheduled FAT date is in mid-December. However, we plan to keep our schedule unchanged. We don’t expect to need the extra time for developing the application software.
There have also been recent developments around the design for equipment status software. Biotech applications require exacting standards for cleanliness. Equipment internals must be cleaned and sterilized after each batch. A new batch cannot be started unless there is a high degree of confidence that the process is free of foreign material and microorganisms. Equipment that is cleaned is often marked “CLEAN” with a physical sign hung prominently for all to see. Manufacturing instructions often instruct the operator to verify a piece of equipment is marked CLEAN or STERILE or some other such status before proceeding with the instructions. If not properly marked, an operator will clean or steam the equipment before further processing.
Many in the industry now look to the automation system to track the processing status for a piece of equipment and to provide automatic time-based expiration of various states. This functionality has been added to the project scope. We implement this functionality through a control module called a unit status controller (USC) that provides a logical status for any piece of equipment that may have a unique and independent status. The end user has defined status for 4 distinct states:
In Use—after start of a production recipe until recipe is finished;
Post Use—after a production recipe has finished until cleaning recipes have finished successfully;
Post CIP Hold—after CIP or SIP recipe is finished successfully or until a timer expires. Upon timer expiration, the status is switched back to Post Use; and
Post SIP Hold—after SIP recipe is finished successfully and the previous status was Post CIP Hold. This status also has a timer that, when expired, automatically drops the status back to Post CIP Hold unless that timer has expired and the status is then dropped to Post Use.
This is a simplified version of the state logic, but it explains the primary functionality. The code will be developed as a state machine within the control module. States may be set by sequences—equipment modules or recipes—or by an operator from the HMI with sufficient security access. Expiration timers and the transition logic will be contained within the USC control module logic.
Until the HMI hardware arrives, we’ll continue to work on equipment modules and develop a first draft of the equipment module design document for submittal to the client.
