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.
7/27/2019 015 Arquitectura APACS1
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
7/27/2019 015 Arquitectura APACS1
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
7/27/2019 015 Arquitectura APACS1
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
7/27/2019 015 Arquitectura APACS1
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
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
7/27/2019 015 Arquitectura APACS1
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
ProcessSuiteClient Node
OK
ProcessSuiteClient Node
OK
ProcessSuiteDevelopment Node
Hub A
Hub B
UPS
ProcessSuiteHistorian
Node
RNI
CrossoverCableProcessSuite
Tag ServerNode
ProcessSuiteTag Server
Node
OK
ProcessSuiteClient Node
OK
ProcessSuiteClient Node
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/27/2019 015 Arquitectura APACS1
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
ProcessSuiteClient Node
OK
Hub A
ProcessSuiteTagserver
Nodes
ProcessSuiteClient Node
OK
ProcessSuiteClient Node
OK
Hub B
ProcessSuiteBatch Server
Nodes
ProcessSuiteHistorianNode
ProcessSuiteDevelopment Node
OK
ProcessSuiteClient Node
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.
7/27/2019 015 Arquitectura APACS1
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
7/27/2019 015 Arquitectura APACS1
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.
7/27/2019 015 Arquitectura APACS1
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
ProcessSuiteDevelopment Node
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
ProcessSuiteDevelopment Node
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.
7/27/2019 015 Arquitectura APACS1
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
Transmission rate 1 mbps
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
Transmission rate 5 mbps
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
7/27/2019 015 Arquitectura APACS1
12/12