015 arquitectura apacs1

7/27/2019 015 Arquitectura APACS1

1/12

PRODUCT INFORMATION

PI39-1Rev: 3

August 2000

APACS+TM

The APACS+ process automation system incorporates unique

architectural structures that offer unparalleled flexibility.

These structures have been developed to cost-effectivelymeet 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 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 software

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

tions 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 ex-

pansion. 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 commu-

nicate between a control module (master) and multiple I/Omodules (slaves). The MODULBUS (and MODULNET) is a

higher level peer-to-peer bus allowing communication be-

tween control modules and with other computer and commu-

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

passing communication bus with a data transmission rate of

5 mbps. Each M-BUS supports up to 32 drops for control-

lers, 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.

MODULNET

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

munication 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 distribu-

tion, up to 2000 ft. (609.6 m), of the various network mod-

ules. 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 redun-

dant and uses deterministic token-passing for secure commu-

nications 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

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)

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

A

C

M

I

/

O

I

/

O

Workstation Workstation

MODULBUS

IOBUS

RNI

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

MODULBUS


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

sonal 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 In-

terface 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 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 entire database to the backup module via the redundancy

cable. During operation, the active and backup maintain iden-

tical on-line information to be ready for switchover. While

the redundancy configurations in Figures 6 and 7 are shown

with MODULBUS communications, they also can be imple-

mented with MODULNET 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

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

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


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 facilitate

system implementation, such as 4-mation with four optional

configuration languages, and the APACS+ Database Auto-

mation Utility. This utility easily uploads all HMI informa-

tion from APACS+ controllers to ProcessSuite operator sta-

tions 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

M-BUS/M-NET

ProcessSuiteDevelopment Node

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


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


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

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

can support two monitors directly and, through the display

server, it has the capability of providing multiple X-termi-

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

telephone line connections are best suited for troubleshoot-

ing or monitoring, while the Internet approach is an entirely

new way of presenting on-line plant data for business pur-

poses.

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

mote mimics the monitor, the keyboard, and the mouse of the

PC host to which it is connected. The use of ReachOut with

the APACS+ system is illustrated in Figure 16. All of thekeyboard 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.

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 requestsfrom a MODBUS master. The slave ACM can also respond

to commands from a MODBUS master to change APACS+

values.

FIGURE 16 Remote Communications Using ReachOut

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

I

/

O

A

C

M

ReachOutRemote

OKOK

ReachOut Host4-mation

Vision

Modem Modem

HART Devices

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 aneffortless 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 Program-

ming Interface (API) toolkits. The API toolkit provides soft-

ware developers with tools to create applications that can

directly exchange data with APACS+. To achieve this, the

toolkit includes a library of predefined communications func-

tions that are compatible with the MODULBUS format. Onetoolkit 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.

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


10/1210

PI39-1

FIGURE 18 System Architecturewith HLL I/O Server

FIGURE 19 Communications with Existing

MYCRO Systems

Existing MYCRO Systems (Hi-Level Link)

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 architecturewith 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 com-

munication. 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 ex-

isting MYCRO systems to gradually and cost-effectively mi-grate 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 subj ect 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) less the length of MODULBUS

across racks

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) standard1,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.

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 [Lengthdepends on the number of drops and drop-length cable

lengths. 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 a

standard AUI connection to support all types of Ethernet

physical cables; others are media-dependent.

TABLE 1 Specifications for APACS+ Architecture


12/12

015 arquitectura apacs1

Documents