Siemens Moore Process Automation, Inc.

PRODUCT INFORMATION
PI39-1 Rev: 4 February 2001

APACS+

TM

ARCHITECTURE

The APACS+ process automation system incorporates unique architectural structures that offer unparalleled flexibility. These structures have been developed to cost-effectively meet short-term needs and protect initial investment far into the future, all while maintaining architectural simplicity. APACS+ provides a complete control system that includes a controller and choice of client-server architectures that are either PC-based with Windows 95/Windows NT operating software or workstation-based with UNIX operating software. The controller consists of a series of plug-in modules, each dedicated to a particular task, such as control strategy execution, input/output functions, or communications functions. Operator stations can include one or more PCs running APACS+ ProcessSuite software or one or more UNIX workstations running APACS+ Process Supervisor software. The APACS+ architecture brings together control system elements in a scaleable and flexible manner. The modular controller hardware and operator interface variations allow the system to start very small and grow incrementally at minimal cost. Expansion of the system or the adaptation of new technology into the system is achieved by simply adding modules. APACS+ systems are classified by the type of high-level operator interface used. Three main types exist: APACS+ ProcessSuite-based systems, APACS+ Process Supervisorbased systems, and APACS+ generic systems. APACS+ ProcessSuite systems include a rich selection of components that run on PC platforms with Windows 95 or Windows NT. Included in ProcessSuite is the APACS+ Vision Human Machine Interface (HMI), Historian for historical data, Batch for batch control, as well as 4-mationTM and a variety of software tools to facilitate system engineering. APACS+ Process Supervisor systems are a UNIX-based APS package, which includes a powerful HMI system. Also avail-

able with APS systems are Direktor for batch control and the PI historian. Generic systems can be readily configured due to the openness of the APACS+ controller and communications systems. Virtually any commercially available HMI can readily import data from APACS+ controllers and create a powerful working system.

APACS+ ADVANCED CONTROLLER

The APACS+ advanced controller makes significant contributions to the APACS+ systems flexible architecture. It achieves this with a modular design, flexible communications buses, and several options for redundancy.

Modular Design
The flexible APACS+ architecture starts with the controllers modularity. Each module has a specific function and can be categorized into one of the following families: Control Modules A series of modules, each of which is able to execute any combination of four distinct control languages (function block, ladder logic, sequential function chart, and structured text). I/O Modules A series of modules acting as interfaces between control modules and the field signals. Communications Modules A series of modules providing expansion of local communications functions, as well as interfaces to other devices and networks.

Support Equipment
APACS+ includes a full complement of modular supporting equipment, including mounting racks, power supplies, termination strips, equipment enclosures, furniture, etc. All of this equipment is designed to simplify the engineering and construction of a complete system.

PI39-1

An APACS+ controller is created for a particular application by simply selecting functionality as individual modules and populating a ten-slot MODULRAC. In addition to the tenslot MODULRAC, there is a six-slot SIXRAC and a singleslot UNIRAC (I/O only) available. Generally (with some consideration of I/O and power wiring), wherever a MODULRAC is shown, a SIXRAC or UNIRAC could be used if desired. The ten-slot MODULRAC with modules is shown in Figure 1.

applications, reducing engineering and installation costs and simplifying maintenance.

Controller Communication
Within an APACS+ controller, there are two main bus structures: an IOBUS and a MODULBUS. A variant of MODULBUS known as MODULNET is available for added flexibility and longer distance applications. The IOBUS is used to communicate between a control module (master) and multiple I/O modules (slaves). The MODULBUS (and MODULNET) is a higher level peer-to-peer bus allowing communication between control modules and with other computer and communication modules. IOBUS The IOBUS provides a control module with dedicated, secure access to I/O points, which are terminated at the I/O modules. IOBUS is a redundant bus that has a data transmission rate of 1 mbps. The media access method is master/slave, and the electrical specification is IEEE RS485. One control module (the master) and up to 39 slave I/O modules can be distributed locally on an IOBUS. The IOBUS can be continued MODULRAC to MODULRAC using prefabricated cables, or can be run long distances up to 7500 ft. (2286 m) using Fiberoptic Extender (IFX) modules and duplex fiberoptic cables. It is also possible to have multiple controller modules in a single MODULRAC and by using Bus Diverter Modules (BDM) extend an IOBUS from each controller to one or more satellite MODULRACs containing I/O modules in a star configuration. Figure 2 shows an IOBUS configured in a single branch across a maximum of four MODULRACs. Figure 3 shows several IOBUS arranged in a star configuration with one branch using fiberoptic links.

M A S E H V S I O R B C A A F I D D D T X M M M M M M M M M

FIGURE 1 MODULRAC Populated with Modules When a module is plugged into a MODULRAC, a connector on the back of the module engages a receptacle on the MODULRAC backplane. This connection provides the physical communications and power path. When the system is online, communication takes effect as soon as the module is inserted. This hot insert feature allows on-line replacement of modules, minimizing process downtime for system maintenance. In addition, all slots in MODULRAC are identical. This allows any module to be plugged into any slot, providing maximum flexibility in initial system design and for future expansion. It also allows the use of a single-rack version across all

IOBUS "master" ACM

A I I C / / M O O

I / O

I I I / / / O O O

I / O

I I I / / / O O O

I / O

I I I / / / O O O

I / O

0 1 2

......

10 11 12

......

19

20 21 22

......

29

30 31 32

......

39

Up to 39 IOBUS "slave" I/O modules and up to 4 MODULRACS

FIGURE 2 IOBUS Configurations

PI39-1

Each ACM is IOBUS master

A B A B C D C D M M M M

.....

A B C D M M

IFX IOBUS

I I / / O O

I / O

1 2

......

39

Fiberoptic Link (shown in BDM branch, but can be used in any IOBUS expansion) IFX IOBUS

I I / / O O

I / O

1 2

......

39

I I / / O O

I / O

IOBUS

1 2

......

39

FIGURE 3 IOBUS Star Configuration and Fiberoptic Link

MODULBUS The MODULBUS (M-BUS) provides deterministic, highspeed, secure communications between control, communications, and computer modules. It is a redundant, token-passing communication bus with a data transmission rate of 5 mbps. Each M-BUS supports up to 32 drops for controllers, communications modules, and computers. Figure 4 shows a typical M-BUS configuration with its relationship to IOBUS. The maximum distance for M-BUS is 60 ft. (18.3 m) inclusive of four MODULRACs. In Figure 4, there are 5 of 32 M-BUS drops.
Workstation Workstation

MODULNET MODULNET (M-NET) provides the same secure 5 mbps communication as M-BUS, but allows expansion of the network to accommodate larger local areas of a plant. Using an M-BUS Expander Module (MBX) inserted in a MODULRAC, the M-BUS transmissions are transformed into a standard, modulated, carrierband IEEE 802.4 network called M-NET. The M-NET network allows a greater geographic distribution, up to 2000 ft. (609.6 m), of the various network modules. M-NET also has 64 drops in a single network versus the 32 drops in M-BUS. Other than the distance and the number of drops, M-NET is identical to M-BUS in that it is redundant and uses deterministic token-passing for secure communications at a 5 mbps transmission rate.

RNI MODULBUS

MODULNET/MODULBUS

A I I I I I I I I I C / / / / / / / / / M O O O O O O O O O

A I I I I I I I I I C / / / / / / / / / M O O O O O O O O O

M A I I I I I I I I B C / / / / / / / / X M O O O O O O O O

M A I I I I I I I I B C / / / / / / / / X M O O O O O O O O

IOBUS
I I I I I I I I I I / / / / / / / / / / O O O O O O O O O O

FIGURE 4 MODULBUS Configuration and IOBUS

FIGURE 5 MODULNET Configuration

PI39-1

MODULBUS/MODULNET Adapters
MODULAR/MODULNET Adapters are a series of ISAbased or PCI-based adapter cards for connecting APACS+ to a Personal Computer (PC). A MODULBUS Interface (MBI) ISA adapter can be installed in up to four PCs for connection to the APACS+ MODULRAC. The maximum length for a MBI connection for up to four PCs is 550 ft. (167.6 m). The MODULNET Interface (MNI) ISA adapter is used to connect the PC directly to the MODULNET network. The MODULBUS/ MODULNET Interface PCI adapter (MBI/MNI) is a combination of the two ISA adapters, but in a PCI form factor. Redundancy The APACS+ controller incorporates a standard level of redundancy. In addition, the controllers modularity supports redundancy at an incremental level to economically accommodate different availability requirements. Built-in Redundancy Features inherent to the controller provide a certain level of standard redundancy. For example, all of the controllers communication buses are redundant, and modules using them exercise both paths. If one side should have a problem, communications automatically continues on the other path. In addition, MODULRACs backplane has three power supply buses (two on UNIRAC) to facilitate redundant and backup power connections. Each module connects to all power buses and uses the best power available. The power buses can be fed by individual power modules or by connections to external bulk power supplies. Optional Redundancy Module redundancy is available either on a module-to-module level for control modules or on a rack-to-rack level for complete controller redundancy in control modules and I/O modules. Module-to-module redundancy is easily and economically implemented by simply installing a twin module for control modules or communication modules adjacent to the primary module and connecting them with a redundancy cable. The redundant control modules share a common set of I/O modules (as shown in Figure 6), providing redundant control, but common I/O as an economic tradeoff. Rack-torack redundancy completely duplicates a controller, including the control module and all I/O modules, for maximum dependability and only requires the redundancy cable connecting the control modules of the two identical controller systems (as shown in Figure 7).

M I A I H V S I O R B / C / F I D D D T X O M O M M M M M M

Redundancy Cable

M I A I H V S I O R B / C / F I D D D T X O M O M M M M M M

FIGURE 7 Rack-to-Rack Redundancy In both redundancy configurations, the control modules operate in active/backup modes. The modules simultaneously and synchronously execute the control scheme. If a serious failure occurs on the active control module system, an automatic and bumpless switchover takes place and the backup control module becomes the active unit. This tightly coupled redundancy arrangement is made possible by the high-speed redundancy cable that connects the two control modules. Upon initialization (power up), the active module transfers its entire database to the backup module via the redundancy cable. During operation, the active and backup maintain identical on-line information to be ready for switchover. While the redundancy configurations in Figures 6 and 7 are shown with MODULNET communications, they also can be implemented with MODULBUS communications within the 18 ft. (6 m) distance limitation of the redundancy cable.

ProcessSuite-BASED SYSTEMS
ProcessSuite-based systems are process control systems in which the HMI (Human Machine Interface) and other supervisory functions are provided by ProcessSuite components such as APACS+ Vision, Historian, and Batch. These systems can be as small as a single controller with a single PC running the higher level functions. They can also be large systems consisting of many APACS+ controllers and network nodes for operations, maintenance, and engineering HMI, history collection, batch preparation, and scheduling. ProcessSuite systems can be further classified in two categories: continuous or batch. These categories are divided into entry-level, single server pair and multi-server pair continuous architectures and stand alone, small system, medium system and large system batch architectures. Both continuous and batch architecture systems require certain ProcessSuite components to be installed within the system for it to function. Components such as 4-mation, which is required for setup and maintenance of the APACS+ database, and the APACS+ I/O server, to feed the Vision, Historian, and Batch components with APACS+ data, must be installed.

M B A A H V S I O R B C C C F I D D D T X M M M M M M M M M

Redundancy Cable

FIGURE 6 Module-to-Module Redundancy

4

PI39-1

APACS+ also contains a rich set of software tools to facilitate system implementation, such as 4-mation with four optional configuration languages, and the APACS+ Database Automation Utility. This utility easily uploads all HMI information from APACS+ controllers to ProcessSuite operator stations to avoid entering this information multiple times.

Single-Server Cluster Architecture for Continuous Systems

The single-server cluster architecture was developed for medium-size continuous applications that require an NT solution. The single-server pair architecture was tested and validated for 2000 real I/O expanded to include up to 10 operator nodes. A typical single-server pair architecture is shown in Figure 10.
ProcessSuite Development Node

Entry-Level Architecture for Continuous Systems

The Entry-Level Architecture is a cost-effective NT solution for small continuous applications. It has been tested and validated for 500 real I/O and up to four operator nodes. The Entry-Level Architecture provides the flexibility necessary for a system to grow into a single-server or multi-server pair. Typical system layouts are shown in Figures 8 and 9. Figure 9 shows the maximum four Client Nodes.

M-BUS
OK

A I I I I I I I I I C / / / / / / / / / M O O O O O O O O O

FIGURE 8

Entry-Level Architecture

ProcessSuite Client Nodes

ProcessSuite Development Node

ProcessSuite Client/Server Node

M-BUS/M-NET
OK OK OK OK

M-BUS/M-NET

Crossover Cable

A I I I I I I I I I C / / / / / / / / / M O O O O O O O O O

Hub A

Hub B

FIGURE 9 Entry-Level Architecture with Four Nodes

Process Suite Client Node Process Suite Client Node Process Suite Development Node

OK

OK

OK

Process Suite Historian Node

Hub A

Hub B

M-BUS/M-NET UPS Process Suite Tag Server Node RNI Crossover Process Suite Cable Tag Server Node M-BUS/M-NET

A I I I I I I I I I C / / / / / / / / / M O O O O O O O O O

FIGURE 10 Single-Server Cluster

5

PI39-1

Multi-Server Cluster Architecture for Continuous Systems

The multi-server cluster architecture is for systems with a real I/O count greater than 2000 I/O or for a system with isolated process areas within the plant environment. The maximum real I/O count for this architecture is 2000 I/O per server pair. A typical multi-server pair architecture is shown in Figure 11.
ProcessSuite Client Node ProcessSuite Development Node

Batch Stand-Alone Architecture

The batch stand-alone architecture was developed for very small batch applications with a limit of 250 real I/O or less and up to one client node. This option does not include redundancy. Figure 12 illustrates a typical batch stand-alone architecture.

ProcessSuite Client Node

ProcessSuite Client Node

ProcessSuite Client Node

OK

OK

OK

OK

OK

Hub B Hub A

ProcessSuite Historian Node RNI RNI UPS ProcessSuite Tag Server Node Crossover ProcessSuite Cable Tag Server Node M-BUS/M-NET ProcessSuite Tag Server Node Crossover ProcessSuite Cable Tag Server Node M-BUS/M-NET

A I I I I I I I I I C / / / / / / / / / M O O O O O O O O O

A I I I I I I I I I C / / / / / / / / / M O O O O O O O O O

FIGURE 11 Multi-Server Cluster

ProcessSuite Batch Server Node

ProcessSuite Client Node

OK

Hub A M-BUS/M-NET

A I I I I I I I I I C / / / / / / / / / M O O O O O O O O O

FIGURE 12 Batch Stand-Alone Architecture

6

PI39-1

Batch System Architecture

The batch system architecture (see Figure 13) was developed for batch applications that require redundancy for the batch process and over 15 operator displays.

Process Supervisor-Based Systems

In an APACS+ Process Supervisor-Based System, the HMI (Human Machine Interface) and other supervisory functions are provided by APACS+ Process Supervisor (APS). It is a UNIX-based workstation and is generally very cost-effective in medium to larger systems, or in systems where special functionality only available in UNIX systems is required. Process Supervisor provides data scanning, database management, and display server functions for an operator interface. Data scanning enables data exchange between the database and the APACS+ control modules. The display server provides the operator with a window into the real-time database via graphics and other tools. The single workstation can

support two monitors directly and, through the display server, it has the capability of providing multiple X-terminals with fully functional HMIs. Additional stations can be added to the network to provide higher availability, in the event of a workstation failure, and also increases the number of X-terminals available for viewing the process. A Rack-mounted Network Interface (RNI) is required for connecting the APACS+ controller on MODULBUS/ MODULNET to the plant-wide TCP/IP network, on which the APACS+ Process Supervisor resides. Figures 14 and 15 show single and dual network configurations for APACS+ Process Supervisor Systems. Note that APACS+ Process Supervisor Systems use a package known as Direktor for batch control implementation, scheduling, and operation. Plant history is collected via a PI plant historian. The ProcessSuite control node is a desktop PC running Windows NT and 4-mation. This node is used for the configuration node of the APACS+ control system.

ProcessSuite Development Node

ProcessSuite Client Node

ProcessSuite Client Node

ProcessSuite Client Node

ProcessSuite Client Node

OK

OK

OK

OK

OK

Hub A

Hub B

ProcessSuite Batch Server Nodes

ProcessSuite Historian Node

ProcessSuite Tagserver Nodes

M-BUS/M-NET Ethernet Crossover Cable

A I I I I I I I I I C / / / / / / / / / M O O O O O O O O O

FIGURE 13

Batch Large-System Architecture

PI39-1

APS UNIX Workstation

APS UNIX Workstation

APS X-Terminals

ProcessSuite Control Node

OK

OK

OK

OK

OK

OK

Hub A RNI

A I I I I I I I I I C / / / / / / / / / M O O O O O O O O O

FIGURE 14

APACS+ Process Supervisor (APS) Single Network

APS UNIX Workstation

APS UNIX Workstation

APS X-Terminals

ProcessSuite Control Node

OK

OK

OK

OK

OK

OK

Hub A RNI

Hub A RNI

A I I I I I I I I I C / / / / / / / / / M O O O O O O O O O

FIGURE 15 APACS+ Process Supervisor (APS) Dual Network

PI39-1

COMMUNICATION WITH OTHER DEVICES AND APPLICATIONS

Remote Capabilities
The previously discussed system architectures illustrate the extensive flexibility that can be achieved using APACS+ communication buses and networks. APACS+ takes this flexibility one step further by incorporating remote communication capabilities. Three communication methods are available, two using telephone lines and a third using the Internet. The telephone line connections are best suited for troubleshooting or monitoring, while the Internet approach is an entirely new way of presenting on-line plant data for business purposes. PC ANYWHERE software runs in a remote PC and in the host PC that is local to the APACS+ system. The remote PC and the host PC are connected via modem and telephone lines. Once the connection is established, the PC running PC ANYWHERE remote mimics the monitor, the keyboard, and the mouse of the PC host to which it is connected. The use of PC ANYWHERE with the APACS+ system is illustrated in Figure 16. All of the keyboard and mouse actions normally performed on the host PC can be performed on the remote PC, with all of the host displays being duplicated on the remote PC.

The APACS+ system can include devices that support the HART (Highway Addressable Remote Transducer) communication protocol through the HART Fieldbus Module (HFM). HART devices manufactured by Siemens Moore include the XTC transmitters, XTC transmitter-controllers, and Siemens Moore FIELDPAC field-mounted controllers. The HFM supports a network of HART devices, providing an effortless method of bringing field device data onto an APACS+ IOBUS, where it can be used by any APACS+ module or station.

API Toolkit
APACS+ provides an open architecture that accommodates other applications to enhance its capabilities. Built-in provisions for other applications include Application Programming Interface (API) toolkits. The API toolkit provides software developers with tools to create applications that can directly exchange data with APACS+. To achieve this, the toolkit includes a library of predefined communications functions that are compatible with the MODULBUS format. One toolkit option provides the ability to create applications that run a PC directly connected to and communicating with MODULBUS via an MBI Card or MODULNET via an MNI Card. Another toolkit option enables interaction with APACS+ Process Supervisors real-time database.

MODBUS
An APACS+ ACM using its RS 232 serial port and the ACM Serial Communications Function Block Library provides MODBUS communication capability. The function blocks, which are configured using 4-mation, allow the ACM to be a MODBUS master or a MODBUS slave. As MODBUS master, an ACM can read and write data values from and to multiple slave devices. When an ACM is acting as a MODBUS slave, it primarily provides APACS+ data in response to requests from a MODBUS master. The slave ACM can also respond to commands from a MODBUS master to change APACS+ values.

Local Instrument Link (LIL)

The existing Local Instrument Link (LIL) data can be integrated into ProcessSuite Vision (HMI) through the Local Instrument Link I/O Server (LIL I/O Server). The LIL I/O Server runs on a Windows NT machine that communicates to the LIL via an Independent Computer Interface (ICI) 320 and Vision via Ethernet. The LIL I/O Server can be integrated to any of the preceding ProcessSuite architectures. A typical system architecture with LIL is illustrated in Figure 17 (on the next page). LIL data can also be integrated into the APACS+ controllers through the LIL function blocks.

HART Devices

Existing MYCRO Systems (Hi-Level Link)

PC ANYWHERE Remote

PC ANYWHERE 4-mation Vision

OK

OK

Modem

Modem

A I I I I I I I I I C / / / / / / / / / M O O O O O O O O O

FIGURE 16 Remote Communications Using ReachOut

9

PI39-1

ProcessSuite Development Node

ProcessSuite Tag Server Node

ProcessSuite Development Node

ProcessSuite HLL I/O Server Node

OK OK

RS232

ICI 2.5

OK

OK

Hub

MLC

MLC

Hub A

RS232 or RS422
Hi-Level Link

3 5 3

3 5 3

3 5 3

3 5 3

3 5 3

3 5 3

3 5 3

3 5 3

3 5 3

3 5 3

Local Instrument Link

FIGURE 17 System Architecture with Local Instrument Link

FIGURE 18 System Architecture with HLL I/O Server

MYCRO Operator Stations

Data from existing MYCRO satellites, such as Multi-Loop Controller (MLC) and Local Expansion Satellite (LES), can be integrated into the HMI running ProcessSuite Vision through the Hi-Level Link (HLL) I/O Server. The HLL I/O Server runs on a Windows NT machine that communicates to the HLL through an ICI 2.5 and Vision via Ethernet. The HLL I/O Server can be integrated to any of the ProcessSuite architectures. Figure 18 illustrates a typical system architecture with the HLL I/O Server. APACS+ can also be integrated with existing MYCRO system products using the Link Interface Module (LIM). Figure 19 shows an APACS+ system with the LIM as a station on the HLL and in a MODULRAC where it is a drop on the MODULBUS. The LIM appears on the MYCRO HLL just as any other MYCRO satellite station does with respect to communication. It participates in the global database broadcast, sending APACS+ data across the HLL every 0.5 seconds. It also accepts commands from a MYCRO operator station, or any other master device, and interprets them for an APACS+ control module. With these capabilities, the LIM allows existing MYCRO systems to gradually and cost-effectively migrate to current, innovative APACS+ technology.

Hi-Level Link

L A I I I I I I I I I C / / / / / / / / M M O O O O O O O O

MODULRAC

FIGURE 19

Communications with Existing MYCRO Systems

SPECIFICATIONS
Table 1 contains a list of specifications related to the APACS+ architecture.
APACS+, ProcessSuite, 4-mation, MYCRO, XTC, and Siemens Moore FIELDPAC are trademarks of Siemens Moore Process Automation, Inc. All other trademarks are the property of their respective owners. Siemens Moore assumes no liability for errors or omissions in this document or for the application and use of information included in this document. The information herein is subject to change without notice. Siemens Moore is not responsible for changes to product functionality after the publication of this document. Customers are urged to consult with a Siemens Moore sales representative to confirm the applicability of the information in this document to the product they purchased.

10

PI39-1

TABLE 1 Specifications for APACS+ Architecture

COMPONENT MODULBUS

MBI Networks

SPECIFICATION Max. length across racks MODULRAC capacity Module capacity Electrical specification Transmission rate Type Max. length No. of PCs Electrical specification Type Cable types Max. length

IOBUS

MODULNET

MODULRAC capacity Module capacity Electrical specifications Transmission rate Type Max. length

Workstation Network

Electrical specification Transmission rate Type Type Protocol Transmission rate Physical cabling

DATA 60 ft. (18.3 m) 4 32 Unmodulated IEEE Standard Standard 802.4 5 mbps Redundant 550 ft. (167.6 m) max. 4 Unmodulated IEEE Standard 802.4 Redundant MBI cable: 4 m and 15 m lengths Extension cable: 50 and 150 m lengths 300 ft. (91.4 m) standard 1,500 ft. (457.2 m) extended 7,500 ft. (2,286 m) fiberoptic segments between IOBUS Fiberoptic Extenders (IFXs). One IFX supports four fiberoptic segments to allow star configurations. Each segment can have additional (nested) segments. 4 39 RS 485 1 mbps Redundant Up to 2,000 ft. (609.6 m) without repeaters [Length depends on the number of drops and drop-length cable lengths. Refer to the APACS+ MODULNET (M-NET) Installation & Service Instruction (document SD39MODULNET-1).] IEEE Standard 802.4 5 mbps Redundant carrierband Ethernet, Token Ring, etc. TCP/IP Ethernet: 10/100 mbps Token Ring: 16 mbps or 4 mbps, depending on the cable. Rack-mounted Network Interface (RNI) provides a standard AUI connection to support all types of Ethernet physical cables; others are media-dependent.

11