APPLICATION DATA

ADQL-4
Rev: 1
October 1998

Configuring APACS+TM or QUADLOG® Control Modules

to Share Information Via MODULBUS

PURPOSE MODULRAC
In APACS+ systems that have multiple controllers, it is often
necessary to share information between their control mod- A I I I I C I I I I
C / / / / C / / / /
ules. This information exchange can be hardwired to both M O O O O M O O O O

controllers, or their control modules can be configured to share

the data over the MODULBUS (M-BUS). This bus is a local,
redundant communications bus dedicated to communications
primarily among control modules. Exchanging information
over the M-BUS has the advantage of lowering system costs
by reducing I/O and field wiring requirements. However, if
M-BUS communications are degraded or lost, it could im-
pair a system’s ability to perform its intended function.
This document explains how to configure control modules so
they can share information over the M-BUS while simulta-
neously monitoring the status of the “softwired” M-BUS data
connection. The monitoring function automatically triggers
an alarm if it detects an M-BUS communication anomaly.
EXAMPLE SYSTEM
Figure 1 shows an example of a system implementing
M-BUS communications between two control modules. Al-
though the example shows an APACS+ Advanced Control
Module (ACM) communicating with a QUADLOG Critical
Control Module (CCM), the methodologies presented in this
document apply to communications between any mix of
APACS+ or QUADLOG control modules.
General-purpose communication buses such as M-BUS re-
quire special protocols to achieve a TÜV (Technischer
Überwachungs Verein) certification per requirement
VDE0801/A1. Contact Moore for information concerning
TÜV certifications for QUADLOG systems. Generally, safety-
critical signals must be wired directly to the QUADLOG sys-
tem and then passed to the other controller’s control module,
not vice-versa.
{
{
APACS+ QUADLOG
Advanced Critical
Controller Controller
FIGURE 1 Example System Containing Two
Controllers
In this document, the control module that calculates a given
data value or receives a given data value directly from its
IOBUS is defined as the source control module. The control
module that receives the information via M-BUS is defined
as the destination control module. For reference, the IOBUS
is a local, redundant bus dedicated to data exchange between
a given control module and its associated I/O module(s).
COMMUNICATIONS AND DATA QUALITY
Each data element within an APACS+ system is assigned a
data quality value. There are four data quality values: Good,
Questionable, Unavailable, or Bad. A data element is assigned
a data quality value of Good if no problems are detected. If a
problem is detected, the data quality value assigned is based
on the problem type and its severity. In the source control
module, a data quality value other than Good represents a
possible problem with field wiring or an associated transmit-
ter. Data quality information is not sent over the M-BUS. Since
it is desirable to pass data quality information to the destina-
tion control module, it is necessary to send an additional sig-
nal containing the data quality value of the field input signal
being fed to the source control module.

1
CONFIGURATION METHODS Configuring Communications in the
Destination Control Module
Establishing Data Quality in the Source
From a configuration perspective, if the destination control
A series of Quality Check (QUAL_CK) function blocks can
module detects a problem with M-BUS communications, it
be used to test the data quality of REAL values. An example
may not pass an error message sent from the source to the
is shown in Figure 2. Although each instance of a QUAL_CK
destination. For this reason, data to be exchanged should be
block can accommodate up to 16 values, only one input is
read from the source by the destination. Figure 3 shows an
used in each block to generate a unique IOTAG_n_QUAL
example configuration implemented in the destination con-
tag for each value that is to be read.
trol module to establish a connection with a source control
module.
QUAL_CK_1
The Resource name for the source control module must be
QUAL_CK
entered at the NAME input of the Connect function block.
%IOTAG_1 IN01 OUT IOTAG_1_QUAL Once communication is established with the destination
control module, an integer (INT) value is placed on the ID
output of the function block. This value must be passed to
QUAL_CK_2 the communication function block(s) that is reading the data
QUAL_CK
from the source control module. The ERROR output of the
Connect block provides a BOOL value of TRUE if a prob-
%IOTAG_2 IN01 OUT IOTAG_2_QUAL lem is detected in the “softwired” M-BUS connection with
the source. This value is used in the destination control
module as means of indicating a problem with M-BUS com-
munications. This value is TRUE only while the problem
condition exists. The Time Off Delay (TOF) function block
FIGURE 2 Configuring a Function to Check the is used to hold the signal TRUE for the time period deter-
Data Quality of REAL Values mined by the HOLD_TIME variable. A recommended value

CONNECT_1

CONNECT MBUS_ERROR_1

TRUE EN NDR TOF

REUSE ERROR IN Q MBUS1_ERR

‘SOURCE’ NAME STATUS HOLD_TIME PT ET
ID ID_1
DEVICE

READ_1
READ READ_ERROR_1

TOF
TRUE REQ NDR
ID_1 ID ERROR IN Q READ1_ERR
‘%IOTAG_1’ VAR_01 STATUS HOLD_TIME PT ET
‘COMMS.IOTAG_1_QUAL’ VAR_02 RD_1 IOTAG_1
RD_2 IOTAG_1_QUAL

READ_2
READ READ_ERROR_2
TOF
TRUE REQ NDR
ID_1 ID ERROR IN Q READ2_ERR
‘%IOTAG_2’ VAR_01 STATUS HOLD_TIME PT ET
‘COMMS.IOTAG_2_QUAL’ VAR_02 RD_1 IOTAG_2
RD_2 IOTAG_2_QUAL

FIGURE 3 Configuring the Destination Side of M-BUS Communication

2
 COMM_ERR_DETECT ANNUNCIATE_ERR
OR HLLDA1

MBUS1_ERR IN01 OUT COM_ERR IN1 ALM1 |COM_FAILURE|

READ1_ERR IN02 EN1 EN1 NAK1
IOTAG_1_QUAL IN03 OOS STATUS
READ2_ERR IN04 CMD
IOTAG_2_QUAL IN05

FIGURE 4 Configuring an Alarm for Communication Errors

for HOLD_TIME is twice the scan rate setting for the con- Transmitting Discrete Values
troller. This ensures that sporadic errors can be detected. If a small number of discrete values are to be exchanged be-
The Read blocks shown in Figure 3 are used to read the data tween the source and destination control modules, the values
values from the source control module. Although each in- can be exchanged as described earlier for transmitting REAL
stance of a Read block can accommodate up to 13 values, values. If a large number of discrete values are to be trans-
one Read block is used for each value that is read from the mitted, they should be packed into 16-bit WORDs, then trans-
source. Each Read block reads the actual value of the tag, mitted.
and it reads the data quality value of the tag that is deter- As shown in Figure 5, the data quality of the discrete values
mined using the method shown in Figure 2. Like the Connect needs to be determined in the source control module. In this
block, the Read block generates a BOOL value of TRUE at example, a QUAL_CHK block is used to monitor the quality
its ERROR output if the read operation is not completed suc- of 15 discrete values. This is convenient since this allows 15
cessfully. This value is also applied to the Time Off Delay discrete values plus the quality value to be transmitted as a
function block so sporadic errors can be detected. If the read WORD as shown in Figure 6. If desired, the data quality value
operation is completed successfully, the value is provided at can be determined for each discrete value independently. In
the block’s RD_1 (received data) output and the associated that case, a WORD would consist of eight discrete values
data quality value is provided at the RD_2 output. and eight data quality values.
Tripping an Alarm in Response to
Communication Errors
QUAL_CK_2
An alarm should be configured to trip when an M-BUS or
QUAL_CK
read error is detected, or if the data quality value of any of the
read tags is anything other than Good. Figure 4 shows an %IOTAG_1 IN01 OUT IOTAG1_15_QUAL
example of how the error and quality signals can be moni- %IOTAG_2 IN02
tored in the destination control module. %IOTAG_3 IN03
%IOTAG_4 IN04
The signals used for indicating communication problems are
%IOTAG_5 IN05
connected to the inputs of an Or function block. The output
%IOTAG_6 IN06
of the Or block is then connected to the input of a Discrete %IOTAG_7 IN07
Alarm Function Block (HLLDA1). The ALARM1_DELAYIN %IOTAG_8 IN08
soft list value of the HLLDA1 block must be set to allow %IOTAG_9 IN09
sufficient time for the read command to be received from and %IOTAG_10 IN10
responded to by the source control module. %IOTAG_11 IN11
%IOTAG_12 IN12
Because of the asynchronous nature of M-BUS communica-
%IOTAG_13 IN13
tions, you should allow a time period equal to three times the
%IOTAG_14 IN14
longest scan rate of the control modules involved. For ex- %IOTAG_15 IN15
ample, if two control modules are involved, one with a scan
rate of 300 milliseconds and another with a scan rate of 500
milliseconds, the ALARM1_DELAYIN value should be set FIGURE 5 Configuring the Acquisition of Data
to 3 x 500 milliseconds or 1500 milliseconds. This prevents a Quality Values for Discrete Data
response from a control module with a slower scan rate from
triggering an alarm condition in a control module operating
at a faster scan rate.

3
Once the data quality is determined, the discrete values to be The resulting WORD is to be read by the destination control
transmitted are fanned-in to a WORD using the Boolean Fan module, as shown in Figure 7. Once the read function is com-
In (BFAN_IN) function block. Figure 6 details how 15 dis- plete, the WORD is fanned-out in the destination using a Fan
crete values plus one data quality value are packed into a 16- Out (FAN_OUT) function block, as shown in Figure 8.
bit WORD. This operation is also done in the source control The same techniques that were used to monitor the error out-
module. puts of the Connect and Read function blocks for the analog
values are also used for the discrete values. Figure 7 shows
FAN_IN_1_15 how the BOOL error values are generated for M-BUS com-
BFAN_IN munications. Refer to Figure 4 to see how these values and
the data quality value can be used to alert an operator or trig-
%IOTAG_1 IN01 OUT IOWORD1_15
ger an external annunciator.
%IOTAG_2 IN02
%IOTAG_3 IN03 Reducing Communications Overhead
%IOTAG_4 IN04
The configuration techniques described so far work with any
%IOTAG_5 IN05
%IOTAG_6 IN06
type of control module (ACM, ACM+, or CCM) as a destina-
%IOTAG_7 IN07
tion. However, if the destination control module is a CCM or
%IOTAG_8 IN08 ACM+, the Array Read/Write (ARRAY_RW) block can be
%IOTAG_9 IN09 used in place of the Read blocks shown in the preceding ex-
%IOTAG_10 IN10 amples.
%IOTAG_11 IN11
The ARRAY_RW block can read or write multiple values as
%IOTAG_12 IN12
a single tagged array. The array format allows for a group of
%IOTAG_13 IN13
%IOTAG_14
values to be read as if it were a single variable. This greatly
IN14
%IOTAG_15 IN15
reduces communication overhead. Since one ARRAY_RW
IOTAG1_15_QUAL IN16
block can read multiple values in one scan, a single
ARRAY_RW block can be used where multiple Read blocks
were required in the preceding examples. Also, if the
ARRAY_RW block is used to transmit discrete values, the
values can be placed in an array. This makes the fan in and
FIGURE 6 Configuring a Boolean Fan in Block to fan out functions shown in Figures 6 and 8 unnecessary.
Pack a WORD

CONNECT_1

CONNECT MBUS_ERROR_1

TRUE EN NDR TOF

REUSE ERROR IN Q MBUS1_ERR

‘SOURCE’ NAME STATUS HOLD_TIME PT ET
ID ID_1
DEVICE

READ_DISCRETE
READ READ_DISC_ERR

TOF
TRUE REQ NDR
ID_1 ID ERROR IN Q IOWORD1_15ERR
‘COMMS.IOWORD1_15’ VAR_01 STATUS HOLD_TIME PT ET
RD_1 IOWORD1_15

FIGURE 7 Configuration Arrangement to Read a WORD from a Source

4
 FAN_OUT_1_15 Figure 9 shows an example configuration that uses the
FAN_OUT ARRAY_RW function block in the destination CCM to read
discrete data placed in the global array |IO_1| in the source
IOWORD1_15 IN OUT01 IOTAG_1 control module. Data and quality values can be transmitted in
INDX OUT02 IOTAG_2 one array in this example because the data is discrete. Since
OUT OUT03 IOTAG_3
all elements in an array must be of the same data type, two
OUT04 IOTAG_4
arrays would be needed to transmit REAL data values – one
OUT05 IOTAG_5
for the data values and another for the data quality values
OUT06 IOTAG_6
(discrete data). For complete information on the ARRAY_RW
OUT07 IOTAG_7
block, refer to “QUADLOG Standard Function Blocks” (docu-
OUT08 IOTAG_8
ment number CGQL-3) or the QUADLOG help file.
OUT09 IOTAG_9
OUT10 IOTAG_10
OUT11 IOTAG_11 The Moore logo, QUADLOG, and APACS are trademarks of Moore Products Co. All other trademarks
OUT12 IOTAG_12 are the property of their respective owners.
Moore Products Co. assumes no liability for errors or omissions in this document or for the applica-
OUT13 IOTAG_13
tion and use of information included in this document. The information herein is subject to change
OUT14 IOTAG_14 without notice.
OUT15 IOTAG_15 Moore Products Co. is not responsible for changes to product functionality after the publication of this
document. Customers are urged to consult with a Moore Products Co. sales representative to confirm
OUT16 IOTAG1_15_QUAL the applicability of the information in this document to the product they purchased.

FIGURE 8 Configuration a Fan Out Block to

Unpack a WORD

CONNECT_1

CONNECT MBUS_ERROR_1

TRUE TOF
EN NDR
REUSE ERROR IN Q MBUS1_ERR
‘SOURCE’
HOLD_TIME PT ET
NAME STATUS ID_1
ID
DEVICE

IO_SRC_1[1] SRC_IO_1
IO_SRC_1[2] SRC_IO_1_QUAL
IO_SRC_1[3] SRC_IO_2
IO_SRC_1[4] SRC_IO_2_QUAL
IO_SRC_1[5] SRC_IO_3
IO_SRC_1[6] SRC_IO_3_QUAL
IO_SRC_1[7] SRC_IO_4
IO_SRC_1[8] SRC_IO_4_QUAL
IO_SRC_1[9] SRC_IO_5
IO_SRC_1[10] SRC_IO_5_QUAL

READ_1
ARRAY_RW READ_ERROR_1

TOF
TRUE REQ NDR
ID_1 ID ERROR IN Q READ1_ERR
HOLD_TIME PT ET
TRUE READ STATUS
‘|IO_1|’ D_TAG NUMMSG
IO_SRC_1 A_TAG

FIGURE 9 Configuring an Array Read/Write Block to Read Discrete Data