Siemens announced the start of the “cancellation” phase of APACS products in 2011. If you still have APACS hardware running your plant, then there’s a good chance that you’ve started looking at migration options, and Siemens recommends the SIMATIC PCS 7 line of controllers and remote I/O.
In this technical guide, We’ll focus on the steps that we take to ensure a successful phased approach, in which the control system is migrated incrementally rather than all at once. Careful planning and organization of communications between the existing APACS Advanced Control Modules (ACMs) and new PCS 7 controllers are critical. If you are unfamiliar with the topic, take a look at our other technical guide: How to Migrate from APACS to Siemens PCS 7.
Planning
The migration needs to be done in a way that makes sense both for the programming effort and for the business. The biggest benefit of doing a phased migration instead of a full replacement is that most of the plant can remain in operation while a single area is being migrated. The section of the plant being migrated to the new control system will need to be down for some duration in order to complete wire terminations to the new control system and to check out the I/O during commissioning.
For example, take a batch plant that has a liquid feed going to six reactors. To minimize the impact on the plant, you may choose to take down one reactor with each phase and tackle the liquid feed tank last (or whenever business demand is low). While work is being performed on a reactor, the programming can proceed for the next reactor so that the overall project timeline is condensed. After a reactor is on the new system, the next would be commissioned, and so on, until the entire plant is migrated.
Communications
The downside to a phased migration is that it creates extra complexity in the programming. The old and new controllers still need to be able to coordinate some tasks, as well as interlock conditions. For instance, in our batch plant example, each reactor will be migrated to PCS 7, but the feed system will remain in APACS.
Communications between the existing APACS ACMs and new PCS 7 controllers are crucial to a successful phased migration. During a phased migration, you will likely have several control modules (valves, motors, etc.) that need to be controlled by equipment modules in both APACS and PCS 7. For more information, take a look at our article: ISO-88: Setting the Standards for Control System Design.
This usually occurs with raw materials, as they typically feed many destinations, and not all those destinations will be migrated to PCS 7 at the same time. To accomplish this, we standardize the information to be passed between PCS 7 and APACS. We pack the bits into a word (16 bits) so they are all received in the same place on the other end. We have even developed a custom PCS 7 block to help us minimize the risk of connecting to the wrong control module on the other end. In PCS 7 it looks like Figure 2 shown here.
Figure 2: Custom APACS valve block and communication blocks in PCS 7.
The really nice thing about organizing the communications in this manner is that when it comes time to migrate the APACS control module to PCS 7, all we have to do is replace the APACS VlvLA block with a PCS 7 VlvL block and the equipment module will continue to function as expected.
In APACS, the same thing happens, but it just looks a little different. Take a look at Figure 3. Where the control word from PCS7 is unpacked for use in APACS, and the status bits are packed into a word to be sent to PCS7.
Figure 3: Valve block and arbitration block in APACS.
The feedback (open/close, run, etc.), error, auto mode active, interlock status, and arbitration status (we’ll get to that in a minute), are packed into a word and sent back to PCS 7, which unpacks the bits and connects to the feedback of the equipment module that currently has control of the APACS valve. A diagram of the overall interaction is shown here in Figure 4.
Figure 4: A diagram of the flow of data required to control a shared valve in APACS.
Arbitration
Since PCS 7 and APACS may both need to control the same device, there needs to be something in place to determine which system may operate the device at any given time.This is called arbitration, and you may have noticed this derived block attached to automatic command nubs of the APACS valve block:
Figure 5: The arbitration block determines which system has control over the A_OPEN and A_CLSE input nubs at the valve block.
Inside of the “arb” block, there is a bit of logic that determines which system has control over the device. The first system to request the device gets to control it, and that system maintains control until it removes the “request” bit. Normally, the A_OPEN and A_CLSE (auto open/close) are connected directly to the APACS equipment module, so this is how we bring PCS 7 control commands into the system.
If the device in APACS were not available, then the PCS 7 equipment module would not receive a response. After a certain amount of time, PCS 7 gives up, putting the equipment module on hold and prompting the operator that it could not acquire the required devices.
The same is true on the APACS side; if an equipment module in APACS requests a device that is not available, then it times out and prompts the operator.
Interlocks
Interlock conditions may also need to be communicated between the old and new controllers and some consideration should be made with regards to timing requirements. Communications between APACS and PCS 7 can be slow in some cases. If response time is critical, then you may consider hard wiring interlock inputs into the new PCS 7 controller to ensure the interlock is tripped quickly enough.
The GW_REC block in PCS 7 used to receive communications from an APACS ACM does not have structured variable outputs, unfortunately. This means the values received do not come with a status. Typically, we will send a 1 to indicate a good interlock conditions. That way, if the communication is lost and reverts to 0, it will trip any interlocks on the other end. For example, if a valve needs to be closed to run a pump, then we would send the closed feedback across the controller communications. Therefore, NOT closed would trip the interlock.
If you need to interlock off a real value, then it is best to configure the comparison logic in the originating controller and only pass a Boolean (1 or 0, with 1 being the “good” condition). In this way, you save communication resources as well as making sure the interlock is tripped on the other controller if a 0 is received.
Commissioning
Commissioning on the APACS side is rather simple because all changes can be made online while the system is running. We will typically have an offline copy of our tested program so we can simply copy and paste changes into the online system. One consideration that needs to be made is any interlock conditions originating in the PCS 7 controller needs to be in place, along with communications to APACS, before adding the interlock to APACS. You can bypass the interlock from PCS 7 temporarily until the new system has been fully commissioned. Just don’t forget to remove the bypass at the end of commissioning.
A Phased Approach Lowers Risk
APACS ACMs are going out of style, but Siemens has provided a clear path for upgrading to the latest hardware. A phased migration can be tricky, but if care is taken in the planning and configuration of communications between the controllers, then the business can continue operating with low risk to production. For more information, contact a Cross team member and our experts can help ensure your process is up to date and running as efficiently as possible.
