I/A Series and SCP Software Architecture

SCP software interacts with Foxboro Evo stations through the Object Manager (OM), Alarm Manager, Historian processes, and other compound processor tasks.

The Foxboro Evo control program is stored as a set of "compounds," which are containers for a collection of blocks that perform control strategies. Compound functions include process alarm priority, sequence status notification, and phasing to level processor loading. Blocks are predefined process functions or algorithms that perform calculations. Blocks contain parameters that have values of types Real, Boolean, String, etc. and have one or more input/output. Block examples include ladder logic, sequential control, or I/O.

When a new control configuration or strategy is loaded, the Compound Summary Access (CSA) task (CSA_Server) residing on the Host WSTA checks to ensure compound name uniqueness, and then creates a unique Configurator Database for each Control Station. The Host WSTA also includes a Station Manager Application Task (smat) that checks the system health and station status.

The remaining tasks described in the following paragraphs are threaded tasks within the SCP application unless otherwise noted. The DB_Query (dbquery) task performs several types of queries on the Compound Database on behalf of a remote client. Queries are typically performed through FoxSelect/BlockSelect.

SCP OM tasks include OM Server (om_server), OM Scanner (om_scanner), and OM Reconnect (om_recon). OM relies on a communication layer (COMEX), which is a Foxboro protocol that broadcasts heartbeats and manages network faults. The OM effectively shields the user from object location concerns. Users refer to objects by name, and the OM finds the location of the named object, stores this information, and performs the requested operation on the object. The OM interface provides a full range of operations for process control and shared variables. Only location services are provided for all other object classes.

As the controls are loaded, DB_Install (dbinstl) copies the Configurator Database to control memory, installing the specified Compound Database on behalf of a remote client. This database downloads to the appropriate CP at the request of the ICC/IACC/Foxboro Evo.

The Compound Processor (cio_cp) executes the control strategies, input/output (I/O) implementation, timing, regulatory, and feedback applications. It performs most device I/O, and controls block processing. This process is associated with the advance of simulation time. In simulation, this process pauses execution when the simulation freezes or is shut down. If the simulator runs in "fast time," cio_cp runs at the same "fast time" speed. This process must run through a block cycle when initially loading controls. For this reason, after loading controls, checklist-type instructions always tell the user to run the simulator.

Download (downld) is the first task called when the CP initializes. It establishes communication between the CP and the hosting WSTA. As with a real CP, the SCP copies the checkpoint file into control memory at startup. After the System Manager detects the CP, the Download process terminates.

Compounds and blocks reside in the control database, which is the CP memory resident database that resides on each CP in the SCP computer. The checkpoint file is associated with this database. When a CP reboots, it automatically restores the CP database using the checkpoint file. As with a real CP, an SCP instance automatically restores a checkpoint file when it starts.

Data from field devices and FBMs interface the control blocks through Equipment Control Blocks (ECBs). An ECB is a data structure that holds the field data and its status. A Compound Processor processes all input ECBs, executes the compounds and their associated blocks, and then processes the output ECBs. I/O control blocks read or write their I/O values directly to and from ECBs.

SCP processing stops at the ECB level. For this reason, it is not possible to fail FBMs for hardware test purposes using the standard Graphical User Interface. However, FBM failure can be simulated through the DYNSIM interface. Additionally, some blocks (i.e., AI/AO/DI/DO) obtain status directly from the FBM. For SCP software, this status is always reported as good or unknown. The SCP software includes an emulation of several blocks and ECBs that execute directly in their FBMs, including PLB, MDACT, GDEV, and DCI output blocks.

External to the SCP application, the Foxboro Evo alarm tasks run on every system running FoxView (foxview). Foxboro Evo Control HMI alarm tasks differ and are not covered in this manual (refer to the Foxboro Evo Simulation User Guide). The main server process is the Alarm Manager (am). An alarm message is generated whenever the block detects a value has gone beyond the specified limit. Alarm messages can cause the Alarm key to flash, be logged by the Historian, and be printed, depending on the assignments made for the block's alarm group parameter and the group/device compound parameters. Alarm limits can be assigned from the Configurator or from the Block Detail Display.

In the SCP application, the Msg_Proc (msgproc) task monitors control memory for alarm message formatting in control blocks and calls Alarm Print to dispatch the message. The Alarm Print (aprint) task dispatches alarm messages to various alarm logging devices, workstations, historians, and applications. External to the SCP, the Alarm Alert (aaserver) is responsible for reporting the local CP availability to the Device Monitor. The Alarm Alert subsystem manages the Keyboard Annunciator Panel and handles the current alarm state. Three possible alarm states include acknowledged, unacknowledged, and normal.