apacs architecture

7/27/2019 APACS Architecture

1/12

PRODUCT INFORMATION

PI39-1Rev: 4

February 2001

APACS+TM

The APACS+ process automation system incorporates unique

architectural structures that offer unparalleled flexibility.

These structures have been developed to cost-effectively meetshort-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 execu-

tion, input/output functions, or communications functions.

Operator stations can include one or more PCs running

APACS+ ProcessSuite software or one or more UNIX work-

stations running APACS+ Process Supervisor software.The APACS+ architecture brings together control system el-

ements in a scaleable and flexible manner. The modular con-

troller 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 tech-

nology into the system is achieved by simply adding mod-

ules.

APACS+ systems are classified by the type of high-level op-

erator interface used. Three main types exist: APACS+

ProcessSuite-based systems, APACS+ Process Supervisor-

based 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 Ma-

chine Interface (HMI), Historian for historical data, Batch

for batch control, as well as 4-mationTM and a variety of soft-

ware tools to facilitate system engineering.

APACS+ Process Supervisor systems are a UNIX-based APS

package, which includes a powerful HMI system. Also avail-

ARCHITECTURE

able with APS systems are Direktor for batch control and the

PI historian.

Generic systems can be readily configured due to the open-

ness of the APACS+ controller and communications systems.

Virtually any commercially available HMI can readily im-

port data from APACS+ controllers and create a powerful

working system.

APACS+ ADVANCED CONTROLLER

The APACS+ advanced controller makes significant contri-

butions 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 be-

tween control modules and the field signals.

Communications Modules A series of modules providing

expansion of local communications functions, as well as in-

terfaces to other devices and networks.

Support Equipment

APACS+ includes a full complement of modular supporting

equipment, including mounting racks, power supplies, ter-

mination strips, equipment enclosures, furniture, etc. All of

this equipment is designed to simplify the engineering and

construction of a complete system.

Siemens MooreProcess Automation, Inc.


2/122

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 ten-

slot MODULRAC, there is a six-slot SIXRAC and a single-

slot UNIRAC (I/O only) available. Generally (with some

consideration of I/O and power wiring), wherever a MODUL-

RAC is shown, a SIXRAC or UNIRAC could be used if

desired. The ten-slot MODULRAC with modules is shown

in Figure 1.

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 physi-

cal communications and power path. When the system is on-

line, 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 main-

tenance.

In addition, all slots in MODULRAC are identical. This al-

lows any module to be plugged into any slot, providing maxi-

mum flexibility in initial system design and for future expan-

sion. It also allows the use of a single-rack version across all

applications, reducing engineering and installation costs and

simplifying maintenance.

Controller Communication

Within an APACS+ controller, there are two main bus struc-

tures: 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) andmultiple I/O modules (slaves). The MODULBUS (and

MODULNET) is a higher level peer-to-peer bus allowing

communication between control modules and with other com-

puter and communication modules.

IOBUS

The IOBUS provides a control module with dedicated, se-

cure access to I/O points, which are terminated at the I/O

modules. IOBUS is a redundant bus that has a data transmis-

sion 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 mod-

ules can be distributed locally on an IOBUS. The IOBUS canbe continued MODULRAC to MODULRAC using prefabri-

cated 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 control-

ler modules in a single MODULRAC and by using Bus

Diverter Modules (BDM) extend an IOBUS from each con-

troller 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.

FIGURE 2 IOBUS Configurations

S

A

M

E

A

M

H

F

M

V

I

M

S

D

M

I

D

M

O

D

M

R

T

M

A

C

M

M

B

X

I

/

O

I

/

O

I

/

O

A

C

M

0 1 2 9. . . . . .

I

/

O

I

/

O

I

/

O

I

/

O

10 11 12 19. . . . . .

I

/

O

I

/

O

I

/

O

I

/

O

20 21 22 29. . . . . .

I

/

O

I

/

O

I

/

O

I

/

O

30 31 32 39. . . . . .

IOBUS "master" ACM

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


3/123

PI39-1

FIGURE 3 IOBUS Star Configuration and Fiberoptic Link

MODULBUS

The MODULBUS (M-BUS) provides deterministic, high-

speed, secure communications between control, communi-

cations, and computer modules. It is a redundant, token-pass-

ing communication bus with a data transmission rate of 5

mbps. Each M-BUS supports up to 32 drops for controllers,

communications modules, and computers. Figure4 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.

MODULNET

MODULNET (M-NET) provides the same secure 5 mbps

communication as M-BUS, but allows expansion of the net-

work 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 calledM-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 ver-

sus 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.

FIGURE 4 MODULBUS Configuration and IOBUS FIGURE 5 MODULNET Configuration

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

A

C

M

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

A

C

M

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

Workstation Workstation

MODULBUS

IOBUS

RNI

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

M

B

X

A

C

M

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

M

B

X

A

C

M

I

/

O

MODULNET/MODULBUS

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

IOBUS

IOBUS

IOBUS

IFX

IFX

1 2 39. . . . . .

1 2 39. . . . . .

A

C

M

B

D

M

A

C

M

B

D

M

B

D

M

A

C

M . . . . .

1 2 39. . . . . .

Each ACM is IOBUS master

Fiberoptic Link(shown in BDM branch,but can be used in any

IOBUS expansion)


4/124

PI39-1

MODULBUS/MODULNET Adapters

MODULAR/MODULNET Adapters are a series of ISA-

based 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 MODULNETInterface (MNI) ISA adapter is used to connect the PC di-

rectly to the MODULNET network. The MODULBUS/

MODULNET Interface PCI adapter (MBI/MNI) is a combi-

nation of the two ISA adapters, but in a PCI form factor.

Redundancy

The APACS+ controller incorporates a standard level of re-

dundancy. In addition, the controllers modularity supports

redundancy at an incremental level to economically accom-

modate different availability requirements.

Built-in Redundancy

Features inherent to the controller provide a certain level of

standard redundancy. For example, all of the controllers com-munication buses are redundant, and modules using them

exercise both paths. If one side should have a problem, com-

munications automatically continues on the other path.

In addition, MODULRACs backplane has three power sup-

ply buses (two on UNIRAC) to facilitate redundant and back-

up 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-mod-

ule level for control modules or on a rack-to-rack level forcomplete controller redundancy in control modules and I/O

modules. Module-to-module redundancy is easily and eco-

nomically 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-to-

rack redundancy completely duplicates a controller, includ-

ing the control module and all I/O modules, for maximum

dependability and only requires the redundancy cable con-

necting the control modules of the two identical controller

systems (as shown in Figure 7).

FIGURE 6 Module-to-Module Redundancy

FIGURE 7 Rack-to-Rack Redundancy

In both redundancy configurations, the control modules op-

erate 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 auto-matic 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 en-

tire 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 re-

dundancy 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 super-

visory functions are provided by ProcessSuite components

such as APACS+ Vision, Historian, and Batch. These sys-

tems 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 catego-

ries: continuous or batch. These categories are divided intoentry-level, single server pair and multi-server pair continu-

ous architectures and stand alone, small system, medium sys-

tem and large system batch architectures.

Both continuous and batch architecture systems require cer-

tain ProcessSuite components to be installed within the sys-

tem for it to function. Components such as 4-mation, which

is required for setup and maintenance of the APACS+ data-

base, and the APACS+ I/O server, to feed the Vision, Histo-

rian, and Batch components with APACS+ data, must be in-

stalled.

A

C

M

H

F

M

V

I

M

S

D

M

I

D

M

O

D

M

R

T

M

M

B

X

B

C

M

A

C

M

RedundancyCable

I

/

O

H

F

M

V

I

M

S

D

M

I

D

M

O

D

M

R

T

M

M

B

X

I

/

O

A

C

M

RedundancyCable

I

/

O

H

F

M

V

I

M

S

D

M

I

D

M

O

D

M

R

T

M

M

B

X

I

/

O

A

C

M


5/125

PI39-1

FIGURE 8 Entry-Level Architecture

FIGURE 9 Entry-Level Architecture with Four Nodes

APACS+ also contains a rich set of software tools to facili-

tate system implementation, such as 4-mation with four op-

tional configuration languages, and the APACS+ Database

Automation Utility. This utility easily uploads all HMI infor-

mation from APACS+ controllers to ProcessSuite operator

stations to avoid entering this information multiple times.

Entry-Level Architecture for

Continuous SystemsThe Entry-Level Architecture is a cost-effective NT solution

for small continuous applications. It has been tested and vali-

dated 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.

FIGURE 10 Single-Server Cluster

Single-Server Cluster Architecture forContinuous Systems

The single-server cluster architecture was developed for

medium-size continuous applications that require an NT so-

lution. The single-server pair architecture was tested and vali-

dated for 2000 real I/O expanded to include up to 10 opera-

tor nodes. A typical single-server pair architecture is shown

in Figure 10.

OK I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

A

C

M

ProcessSuiteClient Nodes

OK OK

ProcessSuiteDevelopment Node

Hub A Hub B

M-BUS/M-NET

CrossoverCable

OK

M-BUS/M-NET

ProcessSuiteClient/Server Node

OK

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

A

C

M

M-BUS/M-NET

Process SuiteClient Node

OK

Process SuiteClient Node

OK

Process SuiteDevelopment Node

Hub A Hub B

UPS

Process SuiteHistorian

Node

M-BUS/M-NET

RNICrossover

CableProcess SuiteTag Server

Node

Process SuiteTag Server

Node

OK

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

A

C

M

M-BUS



6/126

PI39-1

FIGURE 11 Multi-Server Cluster

FIGURE 12 Batch Stand-Alone Architecture

Multi-Server Cluster Architecture forContinuous 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.

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 re-

dundancy. Figure 12 illustrates a typical batch stand-alone

architecture.

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

A

C

M

M-BUS/M-NET

ProcessSuiteClient Node

OK

Hub A

ProcessSuiteBatch Server Node

OK

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/O

I

/

O

I

/

O

A

C

M

M-BUS/M-NET


OK


OK


Hub A

Hub B

UPS

ProcessSuiteHistorian

Node

RNI

CrossoverCableProcessSuite

Tag ServerNode

ProcessSuiteTag Server

Node

OK


OK


I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

A

C

M

M-BUS/M-NET

RNICrossover

CableProcessSuiteTag Server

Node

ProcessSuiteTag Server

Node

RNI


7/127

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-effec-

tive in medium to larger systems, or in systems where spe-

cial functionality only available in UNIX systems is required.

Process Supervisor provides data scanning, database man-

agement, and display server functions for an operator inter-

face. 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 data-

base via graphics and other tools. The single workstation can

FIGURE 13 Batch Large-System Architecture

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

A

C

M

M-BUS/M-NET


OK

Hub A

ProcessSuiteTagserver

Nodes


OK


OK

Hub B

ProcessSuiteBatch Server

Nodes

ProcessSuiteHistorianNode


OK


OK

Ethernet Crossover

Cable

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-ter-

minals available for viewing the process.

A Rack-mounted Network Interface (RNI) is required for con-

necting 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 Su-

pervisor Systems use a package known as Direktor for batch

control implementation, scheduling, and operation. Plant his-

tory is collected via a PI plant historian.

The ProcessSuite control node is a desktop PC running Win-

dows NT and 4-mation. This node is used for the configura-

tion node of the APACS+ control system.


8/128

PI39-1

FIGURE 14 APACS+ Process Supervisor (APS) Single Network

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

A

C

M

OK

Hub A

APS X-Terminals

OKOKOK

ProcessSuiteControl Node

OK

RNI

OK

APS UNIXWorkstation

APS UNIXWorkstation

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

A

C

M

OK

Hub A

APS X-Terminals

OKOKOK

ProcessSuiteControl Node

OK

RNI

OK

APS UNIXWorkstation

APS UNIXWorkstation

Hub A

RNI

FIGURE 15 APACS+ Process Supervisor (APS) Dual Network


9/129

PI39-1

COMMUNICATION WITH OTHER DEVICESAND APPLICATIONS

Remote Capabilities

The previously discussed system architectures illustrate the

extensive flexibility that can be achieved using APACS+ com-

munication buses and networks. APACS+ takes this flexibil-

ity one step further by incorporating remote communication

capabilities. Three communication methods are available, two

using telephone lines and a third using the Internet. The tele-

phone 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 ANY-

WHERE 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 Fig-

ure 16. All of the keyboard and mouse actions normally per-formed on the host PC can be performed on the remote PC,

with all of the host displays being duplicated on the remote

PC.

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 mas-

ter, an ACM can read and write data values from and to mul-

tiple slave devices. When an ACM is acting as a MODBUS

slave, it primarily provides APACS+ data in response to re-quests from a MODBUS master. The slave ACM can also

respond to commands from a MODBUS master to change

APACS+ values.

HARTDevices

FIGURE 16 Remote Communications Using ReachOut

The APACS+ system can include devices that support the

HART (Highway Addressable Remote Transducer) commu-

nication 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+ mod-

ule or station.

API Toolkit

APACS+ provides an open architecture that accommodates

other applications to enhance its capabilities. Built-in provi-

sions 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 in-

cludes a library of predefined communications functions that

are compatible with the MODULBUS format. One toolkit

option provides the ability to create applications that run aPC 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.

Local Instrument Link (LIL)

The existing Local Instrument Link (LIL) data can be inte-

grated into ProcessSuite Vision (HMI) through the Local In-

strument 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 sys-tem 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.

Existing MYCRO Systems (Hi-Level Link)

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

A

C

M

PC ANYWHERERemote

OKOK

PC ANYWHERE4-mationVision

Modem Modem


10/1210

PI39-1

FIGURE 18 System Architecturewith HLL I/O Server

FIGURE 19 Communications with Existing

MYCRO Systems

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 archi-

tectures. Figure 18 illustrates a typical system architecture

with the HLL I/O Server.

APACS+ can also be integrated with existing MYCRO sys-

tem 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 broad-

cast, sending APACS+ data across the HLL every 0.5 sec-

onds. 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-ef-

fectively migrate to current, innovative APACS+ technology.

OK


OK

ProcessSuiteHLL I/O Server Node

Hub

Hi-LevelLink

RS232

MLC MLC

ICI 2.5

MODULRAC

MYCRO Operator Stations

Hi-Level Link

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

A

C

M

L

I

M

FIGURE 17 System Architecture with LocalInstrument 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

OK


OK

ProcessSuiteTag Server Node

Hub A

Local Instrument Link

RS232 orRS422

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 i ncluded 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.


11/1211

PI39-1

COMPONENT SPECIFICATION DATA

MODULBUS Max. length across racks 60 ft. (18.3 m)

MODULRAC capacity 4

Module capacity 32

Electrical specification Unmodulated IEEE Standard Standard 802.4

Transmission rate 5 mbps

Type Redundant

MBI Networks Max. length 550 ft. (167.6 m) max.

No. of PCs 4

Electrical specification Unmodulated IEEE Standard 802.4

Type Redundant

Cable types MBI cable: 4 m and 15 m lengths

Extension cable: 50 and 150 m lengths

IOBUS Max. length 300 ft. (91.4 m) standard

1,500 ft. (457.2 m) extended7,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.

MODULRAC capacity 4

Module capacity 39

Electrical specifications RS 485


Type Redundant

MODULNET Max. length Up to 2,000 ft. (609.6 m) without repeaters [Length

depends on the number of drops and drop-length cablelengths. Refer to theAPACS+ MODULNET (M-NET)

Installation & Service Instruction (document

SD39MODULNET-1).]

Electrical specification IEEE Standard 802.4


Type Redundant carrierband

Workstation Network Type Ethernet, Token Ring, etc.

Protocol TCP/IP

Transmission rate Ethernet: 10/100 mbps

Token Ring: 16 mbps or 4 mbps, depending on the cable.

Physical cabling Rack-mounted Network Interface (RNI) provides astandard AUI connection to support all types of Ethernet

physical cables; others are media-dependent.

TABLE 1 Specifications for APACS+ Architecture


12/12

apacs architecture

Documents