ISO 10368:1992

Internationale
STANDAR0 10368
First edi tion
1992-07-0 1
---- --
eppp---.--- ---------- --~--
Freight thermal Containers -- IRemote condition
monitoring
Conieneurs 3 caract&istiyues fhermiques --- Systeme de pilotage 2
distance des groupes frigorifiques
__m-p-.------
-- __-_, ---.- _--1__ ---
-- -.--- -- ___--_____
.___ ,v__l__l________. - __- ---- --- .---. -*-ev.----- -.--. --_-e-v
-----.-_-_-
_--- .--._ _----
~-. _. -___-
_~- .-~
Reference number
--
-.__---.- _____ --.- ___-__ ISO 10368: 1992(E)

Contents
paw
Section 1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .~.~.~.~.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .-.
Normative references . .
1.2
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . .
Section 2 Performance requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1 Scope . .
................................ 3
22 . Reyuirements .
..............................................................
2.2.1 System coniponents
2.2.2 Performance function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.3 ?erformance constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Section 3 System compatibility requirements . . . .1.1.1.~.
.................................. 8
3.1 Scope .
3.2 Cornmunications protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .*.-.
. . . . . . . . . . .I. 9
3.2.1 MMU to MDCU communications
MDCU to LRCD communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2.2
3.2.3 MDCU to HRCD communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.2.4 RCD to controller communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.2.5 State diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.2.6 Error detection algorithm . . . . . .-._. 52
3.3 Data-logging formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.1 Control words . . . . . . . . . . .1~.
3.3.2 Headers . . . . . . . . . . . . . . . . .*. . . . . . . . . . . . . . . . . . .
3.3.3 Readings .,.,.
3.3.4 Block 0 definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . s. 59
3.3.5 Event marks . . . . . . . . .*.*. 59
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
0 ISO 1992
All rights reserved. No part of this publication may be reproduced or utilized in any ferm
or by any means, electronie or mechanical, including photocopying and microfilm, without
Permission in writing from the publisher.
International Organization for Standardization
Case Postale 56 l CH-1211 Geneve 20 * Switzerland
Printed in Switzerland
ii
. . . . . . . . . . . . . . . . . . . . . . .-. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.4 Message definitions
............. .................................... 59
3.4.1 Message packet exchange
3.4.2 Extended commands . . . 61
.................................................................................
3.4.3 Notation 61
Echo . .
3.4.4 61
.....................................................................
3.4.5 Controller read 61
3.4.6 Controller write . 65
3.4.7 Enter untimed process . .
....... .......................... ......... ..................
3.4.8 Enter timed process 72
........................
3.4.9 Undefined . . . 74
3.4.10 Reserved . 74
3.4.11 Illegal . . 74
3.5 Low data rate physical requirements - LDCU to LRCD . 75
3.5.1 Frequency . 75
3.5.2 Modulation method . . . . . . . . . . . . . . . . .* *.,.,.
3.53 Baud rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
3.5.4 Transmission mode . . . . . . . . . . . . . . . . .~.-.
3.5.5 lnjection mode ,.~.,.,.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5.6 Receiver sensitivity 75
. . . . . . . . . . . . . . . . . . . . . . . .s.
3.5.7 Non-transmission impedance 75
3.5.8 Bit synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
3.5.9 Carrier setup time . . . . . . . . . . . . . . .m. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
3.5.10 Out-of-band filtering requirements for “high data rate
I-.,,.~*.,.
compatibility” 76
3.6 High data rate phvsical requirements - HDCU to HRCD . 76
.
3.6.1 Modulation method - Broad band . . . . .-. 76
3.6.2 Transmission mode . . 77
3.6.3 Injec:tion mode . . 77
.................................................. 77
3.6.4 OutpuVinput impedance .
3.6.5 Power density function . . 77
3.6.6 Synchronization method . . 78
......................... ...........................
3.6.7 Demodulation method . 78
. . .
lli
.............................................................
3.6.8 Receiver sensitivity
.................................................................
3.6.9 Data link protocol
3.6.10 Out-of-band filtering requirements for “low data rate”
.......................................................................
compatibility
Annex
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .s.
. . . . . . . . . . . .r.
A Bibliography
Foreword
ISO (the International Organization for Standardization) is a worldwide
federation of national Standards bodies (ISO member bodies). The work
of preparing International Standards is norrnally carried out through ISO
technical committees. Esch member body interested in a subject for
which a technical committee has been established has the right to be
represented on that committee. International organizations, govern-
mental and non-governmental, in liaison with ISO, also take part in the
work. ISO collaborates closely with the International Electrotechnical
Commission (IEC) on all matters of electrotechnical standardization.
Draft International Standards adopted by the technical committees are
circulated to the member bodies for voting. Publication as an Inter-
national Standard requires approval by at least 75% of the member
bodies casting a vote.
International Standard ISO 10368 was prepared by Technical Committee
ISWTC 104, Freight Containers, Sub-Committee SC 2, Specific purpose
Containers.
Annex A of this International Standard is for information only.

Introduction
During the preparation of this International Standard, information was
gathered on Patents upon which application of this Standard might de-
pend.
For the low data rate System of 3.5, the relevant Patents were identified
as belonging to
Thermo King Corporation
314 W. 90th Street
Minneapolis, Minnesota 55420
USA
For the high data rate System of 3.6, the relevant Patents were identified
as belonging to
Adaptive Networks Incorporated
1505 Commonwealth Ave.
Suite 30
Brighton, Massachusetts 02135
USA
ISO cannot give authoritative or comprehensive information about the
evidente, validity or scope of patent and Iike rights. The patent holders
have stated that licences will be granted under reasonable terms and
conditions. Communications on this subject should be addressed to ei-
ther Thermo Kinq Corporation or Adaptive Networks Incorporated.
\
- Remote condition monitoring
Freight thermal Containers
Section 1: General
1.1 Scope
This International Standard establishes the information and interfaces required to permit complying central
monitoring and control Systems employed by one carrier or terminal to interface and communicate with com-
plying remote communication devices of differing manufacture and configuration used by other carriers and
.
terminals.
The data-logging formats and message protocols outlined in this International Standard apply to all currently
available data rate transmission techniques. These formats and protocols also apply to all future techniques
designed to be an ISO Standard compatible System.
The Performance requirements for the monitoring, communication and control System are given in section 2.
The System compatibility requirements are given in section 3. All sections of this International Standard apply
to all implernentations, except where specified.
1.2 Normative references
The following Standards contain provisions which, through reference in this text, constitute provisions of this
International Standard. At the time of publication, the editions indicated were valid. All Standards are subject
to revision, and Parties to agreements based on this International Standard are encouraged to investigate the
possibility of applying the most recent editions of the Standards indicated below. Members of IEC and ISO
maintain registers of currently valid International Standards.
ISO 1496.2:1988, Series I freight Containers - Specification anal testing -- Part 2: Thermal Containers.
ISO 971 l-2: 1990, Freight Containers - Information related to Containers on board vessels - Part 2: Telex data
transmission.
1.3 Definitions
For the purposes of this International Standard, the following definitions apply.
1.3.1 remote communications device (RCD): Device which is physically a part. of the refrigeration rnachinery
and which communicates with any complying central monitoring and control Systems (CMCSs) using the re-
frigeration machinery power distribution System as the data transmission medium. See figures 1 and 2.
There are two distinct types of RCD:
- a stand-alone remote communications device (sRCD) (see 1.3.9);
- an integrated remote communications device (iRCD) (see 1.3.10).
An sRCD is defined as a device which cannot implement the hardware write messages defined in 3.4.6.1.
1.3.2 central monitoring and control System (CMCS): System consisting of hardware and Software which
monitors and controls one or more remote communications devices (RCDs). A typical System consists sf at
least
a) Operator interface devices,
b) a master monitoring unit (MMU), and
c) power line data link equipment, such as a multiple data rate central control unit (MDCU).
1.3.3 master monitoring unit (MMU): Central processing unit such as a Computer which contains specific
hardware and Software to control the entire remote condition monitoring System. lt is the interface between the
human Operator and the network.
1.3.4 multiple data rate central control unit (MDCU): Device which forms the link between the master moni-
toring unit (MMU) and the three-Phase power line bus which contains the individual remote communications
devices (RCDs). An MDCU consists of two components as follows:
central control un it capable of receiving and transmitting at the data rates which meet the requirements
a) a
of . this International Standard;
b) a central control interface.
1.3.5 high data rate remote communications device (HRCD): Remote communications device (RCD) which
transmits data at a high data rate, e.g. 19 200 baud.
1.3.6 low data rate remote communications device (LRCD): Remote communications device (RCD) which
communicates data at a low data rate, e.g. 1 200 baud.
1.3.7 high data rate central control unit (HDCU): Device which links the master monitoring unit (MMU) and the
power line network, communicating with the high data rate remote communications devices (HRCDs).
1.3.8 low data rate central control unit (LDCU): Device which links the master monitoring unit (MMU) and the
power line network, communicating with the low data rate remote communications devices (LRCDs).
1.3.9 stand-alone remote communications device (sRCD): Slave remote communications device (RCD) which,
with limited capabilities, merely monitors a Container refrigeration unit. An sRCD ca11 be either high or low data
rate.
1.3.10 integrated remote communications device (iRCD): Slave remote communications device (RCD) which
interfaces to a refrigeration unit controller via an EIA RS232-C serial interface and tan control the refrigeration
machinery. An iRCD tan be either high or low data rate.
1.3.11 controller: Device that monitors and controls the refrigeration machinery.

Section 2: Performance requirements
2.1 Scope
This ante requirements and contra System
section specifies the perform l of centra monitoring s (CMCS
nece d evices
ssary for them to i nterface and communicate with complying remote com munications (RCDs).
2.2 Requirements
2.2.1 System components
2.2.1.1 Remote condition monitoring System components
A Single remote condition monitoring System consists of a maximum of one master monitoring unit (MMU) and
one multiple data rate central control unit (MDCU). See figure 1 a).
2.2.1.2 Multiple data rate central control unit (MDCU)
An MDCU may include one high data rate central control unit (HDCU) and one low data rate central control unit
(LDCU). lf an HDCU and an LDCU are both present, the HDCU and LDCU are joined together by a central control
unit (CCU) interface, and the three components together form the MDCU.
2.2.1.3 MMUIMDCU interface
The preferred method of connecting the MMU to the MDCU complex is through a Single port as shown in
figure 1 a). However, certain expansion paths may require multiple connections as shown in figure 1 b).
2.2.1.4 High and low data rate remote communications devices (HRCDs and LRCDs)
HRCDs and LRCDs shall be able to coexist on the Same power line network and not interfere with simultaneous
communications with either the HDCU or the LDCU.
2.2.1.5 MDCU components
An MDCU may consist of either a Single HDCU (to communicate with the HRCDs on the network) or a Single
LDCU (to communicate with LRCDs on the network). However, all signalling protocols, data-logging formats,
power levels, insertion rates and other physical requirements shall be identical to that which would be used for
a combined System and therefore must be compatible. Refer to 3.2 and 3.3 for the required protocol and data-
logging formats.
2.2.2 Performance function
2.2.2.1 Standard message
All RCDs shall respond to a minimum list of standardized enquiries (see 2.2.2.4) and commands with a stan-
dardized reply or acknowledgement.
2.2.2.2 Acknowledgement message
The RCD shall send an acknowledgement message for all commands and enquiries that are received and
understood.
2.2,2.3 “Not able” message
If the RCD is not capable of executing a command received or of responding to an enquiry because of the
shail respond with a “Not able” message.
configuration of the RCD and the thermal control machinery, it

HDCU
u
Master monltoring
I
*. c ’
unlt
c
IMMUI
c
m-
u LDCU
c
U
MOCU
CM;S
a) Conflauratfon A
Master monltorlng
. l
MDCU
3@-
------ab
-,
b) Confiquration B
H = high data rate
L
= low data rate
349 = three-Phase power malns
Figure 1
- Remote condition monitoring System components layout

2.2.2.4 Required enquiries
All RCDs shall respond to the following required enquiries.
2.2.2.4.1 Identification number: For an integrally refrigerated or thermal Container this will be the Container
ISO number comprising a 4-letter alphabetical prefix and a 7-digit suffix (includinq the check digit). Where a
demountable marine Clip-on unit (MCOU) is used, the identification number will be the MCOU number in ISO
format.
2.2.2.4.2 Porthole Container number: This response will be in addition to the identification number for MCOU
Systems.
2.2.2.4.3 Potthole number Change: This is recorded in the RCD rnemory in alphanumerical format together with
the time of the Change.
2.2.2.4.4 Return air temperature: In the form of a positive or negative value, expressed in degrees Celsius to
one decimal place, within the range - 30,O “C to + 38,0 “C.
2.2.2.4.5 Supply air temperature: Expressed in the Same format as 2.2.2.4.4.
2.2.2.4.6 RCD manufacturer and type: Consisting of a unique identification number registered and controlled
by ISO, and for which ISO/TC 104 is the registration authority.
2.2.2.5 Optional Standard enquiries
ed s #halt
Other optional enquiries are standardized. RCDs and refrigeration machinery so equi respond to the
PP
following enquiries. RCDs not so equipped shall respond “Not able” (See 2.2.2.3).
ans only or Null mode,
2.2.2.5.1 Operating mode: Full cool, Partial or Lower capacity cool, Modulated coo 3 F
Defrost, Heat, Off.
2.2.2.5.2 Set-Point temperature: Expressed in the Same format as 2.2.2.4.4.
2.2.2.5.3 Alarms: High refrigeration pressure, Temperature out of range, Low compressor oil pressure,
Defrost/Heat/Overheat, Cornpressor overload, Controller failure, Sensor failure - Return air, Sensor
failure - Supply air, Power Off, Amperage draw too high, Amperage draw too low, Defrost (out of time).
(Capacity for future development, e.g. controlled atmosphere.)
2.2.2.5.4 All current alarms: In sequence of occurrence.
2.2.2.5.5 Product temperatures: For example, tank, poultry.
2.2.2.5.6 Data-logger interval: One digit in half-hour intervals up to a maximum of’ 12 h.
2.2.2.5.7 Amperage: 0 to 63,75 A in 0,25 A intervals.
If the destination changes, both the old and the current
2.2.2.5.8 Destination: Three alphanumerical digits.
destination may be declared.
2.2.2.5.9 Port of discharge: Three alphanumerical digits.
2.2.2.5.10 Origin: Three alphanumerical cligits.
2.2n2.5.11 Report results of self-check level 1: One dic$, 0 = Fail, 1 ==. Pass.
2.2.2.5.12 Report results of self-check level 12: In the format of up to 256 ASCII characters, where YE is a Single
Character between two and nine.
2.2.2.5.13 Vessel and voyage designation: (See ISO 9711-2.)

2.2.2.6 Commands
RCDs and refrigeration machinery if so equipped shall respond to the following commands. RCDs not so
equipped shall respond “Not able” (See 2.2.2.3).
2.2.2.6.1 Change Set-Point temperature: Expressed in the Same format as 2.2.2.4.4.
2.2.2.6.2 Initiate self-check level 1.
2.2.2.6.3 Initiate self-check level ~2: In the Same format as 2.2.2.5.12, where y1 is in the range two to nine.
2.2.2.6.4 Change identification number: Expressed in the Same format as 2.2.2.4.1.
2.2.2.6.5 Change data-logger interval: Expressed in the Same format as 2.2.2.5.6.
2.2.2.6.6
Set data-logger time and date: With the date expressed in the format year/month/day.
2.2.2.6.7 Change operating mode: Expressed in the Same format as 2.2.2.5.1.
2.2.2.6.8 Download data-logger record to central monitor.
2.2.2.6.9 Change porthole Container number: Expressed in the Same format as 2.2.2.4.3.
2.2.2.6.10 Change destination: Expressed in the Same format as 2.2.2.5.8.
2.2.2.7 Indecipherable or unserviceable messages
Indecipherable or unserviceable messages shall not Cause the RCD or CMCS to “Crash” or “bang up ”. Also,
failures of an electronie device in any RCD shall not Cause the System to “Crash” or “hang up ”.
2.2.2.8 Verification of Container identification number
The CMCS, if so equipped, shall verify the Container identification number, using the check digit (the seventh
digit of the numerical suffix) and an algorithm selected.
2.2.3 Performance constraints
2.2.3.1 Power interference
RCDs and CMCSs shall not interfere with the proper functioning of power supply requlating or control devices,
k.
such as voltage regulators or protective relaying equipment.
2.2.3.2 Marine device interference
CMCSs and RCDs, individually or as a System, shall not interfere with Standard marine navigation and com-
municatjon devices.
2.2.3.3 System size
All CMCSs shall be suitable to coordinate and report on a System of 1 024 RCDs active at the Same time on
one CMCS.
2.2.3.4 Status update
The MMU/MDCU System shall generate RCD updated Status per 2.2.2.4 at least once per hour per Container for
a System of up to 1 024 Containers active at the Same time on one CMCS.
2.2.3.5 Automatic RCD System list
The population or database of RCDs on the CMCS shall be self-qenerating. No input to the MMU, whether from
an Operator or from another Computer, shall be necessary to determine the RCDs connected to that System.
2.2.3.6 Identification of new RCDs
The MMWMDCU System shall be designed to identify an average of at least one new Container every 10 s, or
6 per minute.
2.2.3.7
Voltage and frequency requirements
RCDs shall be suitable for operating on the voltage Systems specified in ISO 1496-2.
2.2.3.8 Dual voltage requirements
No special handling shall be required for RCDs to operate on the three voltage types of refrigeration machinery.
(See ISO 1496-2:1988, subclause 7.2.)
2.2.3.9 RCD connection
The RCD shall be connected on the line side of the refrigeration machinery clisconnect or circuit breaker, if any,
so that communication is possible when the refrigeration machinery is switched Off. The RCD may have its own
disconnect switch for servicing.
2.2.3.10 Error rates
2.2.3.10.1 All CMCSs and RCDs shall be designed to meet the following error rate criteria.
The RCD/MDCU communication System may have two different types of “undetected and uncorrected” com-
munication errors. An “undetected and uncorrected” communication error is one which is not detected and
corrected within 5 min alter occurrence.
2.2.3.10.2 An error whereby an RCD executes a command which was not commanded by the MMU shall not
G
occur more often than one time in 25 x 10 messages (i.e. any power line disturbance which the receiver in-
terprets as a message), or more often than once in 10 years for each CMCS, whichever is greater.
2.2.3.10.3 An error whereby a CMCS misinterprets a message (i.e. any power line disturbance which the re-
ceiver interprets as a message) shall not occur more often than one time in 25 x IO5 messages.

System compatibility requirements
Section 3:
3.1 Scope
This section specifies the interface requirements for communications protocol, data-logging formats, message
definitions, and physical requirements for low data rate and high data rate (CU and CD).
3.2 Cammunieations protocol
Esch remote condition monitoring System has three interface areas as follows (see figure 2):
- MMU to MDCU interface;
- MDCU to RCD interface;
- RCD to refrigeration machinery controller interface.
Master
monl t orlng MDCU
unit (MMU)
MDCWRCD RCWcontroller
MMWMDCU
Interface interface Interface
(See 3.2.1) (See 3.2.2, 3.2.3, (See 3.2.41
3.5 and 3.6)
Figure 2 - Remote condition monitoring - Communications Mxfaces
3.2.1 MMU to MDCU communications
This subclause, in patt, defines the communications protocol to be used when the MDCU is implemented as a
discrete System component which is separate from the MMU architecture. The requirements given in this
subclause do not preclude the use of bus-based open architecture MDCU applications where the EIA RS232-C
is not appropriate.
The MMU communicates with the MDCU via a full duplex EIA RS232-C serial interface. The baud rate shall be
at least two times the baud rate of the fastest RCD in the System. A typical communications baud rate is
4 800 baud. Esch Character transferred requires 1 Start bit (low logic level), 8 data bits, and 1 stop bit (high logic
level). The minimum time delay required between packets is one Character time. This, therefore, restricts
deadtime between any 2 bytes in a packet to less than one Character delay.
The messages for succeeding interfaces are embedded in the formats of earlier stages (see figure3). These
messages may be intended for action by the MDCU only. These messages are described fully in 3.2.1.1. If the
message contains embedded data intended for an RCD, the format is a s described in 3.2.1.3. Similarly, em-
bedded data intended for the refriqeration machinery is described in 3.2.1.5 and 3.2.4. Note that the field length,
in bytes, is also defined in figure 3.
1 2
1 2 1
Message
Packet
Task No.
SYNC STX Data ( (,.,,(I (See 32.1)
length
\
\
\
\
2 \
Reply Length *) Packet (See 3.2.2 and 3.2.3)
/-
/-
Routlng byte
-/’ (See 3.2.4)
Format ot each analog output or channel
Least slgniflcant
-bit
Most slgnlf lcant
Mask bit3’ --
bit
ue of fleld
[Esch bit = W256) %l
1) Interactlve 1 and 2 commands only.
21 Devlce commands only.
31 Mask bit equals 1 if thei*e Is u Change In the field or 0 if there Is no Change.
Figure 3 - Message format overview
The information transfer format from the MMU to the MDCU is as shown in figure4.
Figure 4 - Information transfer format from the MMU to the MDCU
The inform
ation transfer format returned to the MMU from the MDCU is as shown in figure5.
SYNC Packet
RePlY
Data CRC
STX Task No.
(optional) length
tYPe
--
No. of
1 2
bytes 1 2 1 1-
-- -- ---
Figure 5 - Information transfer format returned to the MMU from the MDCU
ihe fields in figures 4 and 5 are defined as follows.
SYNC An optional synchronization field. lt tan be any nurnber of bytes, the contents of which is
16H. The MDCU Strips all SYNC characters from the Start of a message.
STX
Delimits the Start of a valid message. lt indicates that the next 2 bytes are the packet length.
Packet length A 2 byte unsigned integer which gives the packet length in bytes not including the SYNC, STX
or CRC fields. lt is transmitted high byte followed by low byte.
Task No. A 1 byte number assigned to the job before transmission to the MDCU. lt is not used by the
MDCU and is defined by the application. The MDCU reply will contain the Same value in this
field.
Task numbers shall be assigned sequentially by the MMU from 0 to 254 and then resume at
0. Task number 255 is reserved for the MDCU reset command.
Xmit type
A 1 byte command directing the MDCU as to the type of proces!;ir+ \Nhich is to be performed
on the data. The assignments are discussed in 3.2.1.1.
A 1 byte command response from the MDCU indicating the success or failure Status of the
RePlY tY Pe
corresponding job received by fhe MDCIJ. The assignments are discussed in 3.2.1.2.
Data
Variable length data field in which the contents are dependent on the type of message to be
processed. The contents are defined in 3.2.1.1 and 3.2.1.2 for each appropriate command.
CRC A 16 bit error check field generated by using the CRC-16 polynomial:
p + x15 + x* -l- 1
The optional SYNC characters arc not included in the CRC calculation.
3.2.1.1 MMU to MDCU transmit command types
There are two groups of commands which are sent to the MDCU: those directed to the MDCU for internal pro-
cessing only and those to be transferred over the power line. The former qroup is qiven in table 1, while the
latter group is given in table 2. An explanation of each command follo\tis. x L
3.2.1 .l .l MDCU directed command types
This group of com mands requ ires processing with in the MDCU, i.e. the power line commun i cation s network is
not accessed. The comm ands currently supported by the MDCU are given in table ‘l and exp ained in 3.2.1.1.1.1
to 3.2.1.1.1.3.
Table 1 - MDCU interrogation directed
command types
Command
Value
M DCU reset 20H
M DCU Parameters 22H
MDCU Status 23H
3.2.1.1 .l .l MDCU reset command
Upon request, the MDCU will perform its internal diagnostics and initialize with default Parameters. Any data
associated with this command will be ignored. Since the MDCU is reset, the initial Status condition with default
Parameters will be returned to the MMU as defined in 3.2.1.1.1.2. Task number 255 will be used in the reply.
3.2.1 .l A.2 MDCU Parameters command
The MDCU Parameters command loads the MDCU with inforrnation passed in the data field Portion of the
command. A data field containing more than 15 bytes will Cause the MDCU to ignore the command. The par-
arneters to be loaded are defined below. Note that the Parameters used for the low data rate System only are
prefixed with an L while the Parameters used for the high data rate System only are prefixed with an H.
First byte transmitted:
Parameter0 -
Test Status byte is a read-only location and, therefore, this Parameter is ignored by the MDCU.
Parameterl-2 - MDCU Software version/subversion is a read-only location and, therefore, this Parameter is
ignored by the MDCU.
Parameter3 - Change the MMU handshaking flaq byte between the MDCU and MMU. Esch bit is discussed
L
below.
Bit7 - MDCU external UART CTS Status (MMU communications). This tGl will always be received by the
MMU in the active, or logic one, state since the UART is in the CTS mode (i.e. communicating with the
MMU). This bit is a read-only bit; the MMU cannot set/reset it.
BitG-Q - Although accessible to the MMU, at present not used by the MDCU.
Parameter4-5 - Change available buffer size high (4) and low (5) bytes. DecreasesIexpands power line buffers.
If the new size is below/above the MDCU ’s minimum/rnaximum value, its minimum/maximum value is used.
A value of Zero, or a value received which is equivalent to the previous setting, will retain the previous setting.
If a Change in the buffer size is performed, all jobs within queue will be lost.
LParameter6 - Change the maximum size of the packets (or blocks) to be transferred on the power line. If
received larger than the available buffer size setting (described above), that value will be substituted. A value
of Zero will retain the previous setting (unless that setting is greater than the new available buffer size). lt is
recommended that the packet size not be set greater than its default value (128 or 80H) unless the power line
message timeout settings within the MDCU are changed accordingly.
LParameter7 - Change the number of retransmissions to be attempted for a given job on the power line.
LParameter8 - Change the counter indicating the number of retries which have been performed on the power
line.
LParameter9 - Change the counter indicating the number of successful normal polls whict I required one retry
on the power line.
ch required two re-
LParameterlO - Change the counter indicating the number of successful normal polls whi
tries on the power line.
Parameter1 1
- Change the time delay base value used within an interactive command (3.2.1.1.2.3 and
3.2.1.1.2.8) that is required between the MDCU transmission of data to an RCD and the interactive poll used to
obtain a response from the RCD. Esch count provides a O,l s incremental delay.
Parameterl2-14 - At present undefined. The information will be copied into the Status buffer as received.
Since the first 3 bytes of the Status buffer are read-only locations, any data fieid containing less than 3 bytes
will not Change any Parameters in the MDCU Status buffer. Also, Parameter4-5 is 2 bytes in length and a byte
count which transfers only one of iihese bytes will not update this Parameter. Regardless of whether any par-
ameters were changed, the MDCU reply will return the current Status value to the MMU in a general valid type
reply, as defined in 3.2.1.2.1.
3.2.1 .1.1.3 MDCU Status command
The MDCU Status command simply requests the MDCU to reply with its present Status value. Any data as-
sociated with this command will be ignored. The definition of this Status buffer corresponds to the assignments
discussed in 3.2.1.1.1.2 (MDCU Parameters command), or as defined in 3.2.1.2.1.
3.2.1.1.2 MDCU power line command types
This group of commands requires communication with RCDs over the power line communications network. The
commands currently supported by the MDCU are given in table 2. The format of the power line data field for the
RCD directed commands to be deciphered by the RCD (RCD message) is given in 3.2.1.2, while the format of
the power line data field for the device-related commands to be deciphered by the controller device for an
iRCD, or a device input/output processing for an sRCD (device message), is given in 3.2.4.
Table 2 - MDCU power line directed
command types
Command Value
RCD poll 30H
RCD xmitl 31H
RCD xmit2 32H
RCD interactivel 33H
RCD interactive2 34H
35H
RCD map
RCD interactive pell 36H
Device pell 40H
Device xmitl 41H
Device xmit2 42H
Device interactivel 43H
Device interactive2 44H
Device map 45H
Device interactive poll 46H
--
In all power line communication commands, the first byte of the data field is the routing byte. The routing byte ’s
identification is derived from the original RCD map response (see 3.2.1.1.2.6) and is used by the MDCU to route
the message to the proper data rate modern. Bits 7-6 define routing information for the low data rate RCDs and
high data rate RCDs as described in table 3. The remaining bits (5-O) are dlefined in the appropriate low or high
data rate subclauses, 3.2.2 and 3.2.3 respectively.
Table 3
- Routing byte data rate bit
assignments
Bits 7-6 Definition
-
0 0 Illegal
0 1 ISO LRCD
1 0 ISO HRCD
1 1 Reserved
RCD network address. Two address fields are reserved
The routing byte is always followed by an 11 byte ASCII
for special use in the RCDs. A universal address consisting of all ASCIl Os, or all 30H, is recognized by all RCDs
(i.e. a broadcast address) while a field containing nine ASCII Os followed by two ASClI ls, or nine 30Hs plus two
31Hs, is an address substituted in an RCD containing an invalid personal address.
The command or message type, routing byte and RCD network address are called the power line prefix and
shall comprise ASCII alphanumeric characters. This provides certainty for distinguishing these prefix charac-
ters from control characters.
3.2.1 A.2.1 RCD pell command
The RCD poll command requests the Status buffer from the selected RCD. The data field sent to the MDCU from
the MMU contains the routing byte followed by the 11 byte ASCII RCD network address, i.e.
Data field to MDCU = Routing byte/address
A valid reply from the MDCU contains the routing byte/address and the RCD Status buffer in the data field of
a general valid type reply (see 3.2.1.2.1) i.e.
Data field from MDCU valid I=I Routing byte/address + RCD Status values
The RCD Status buffer contains the information defined below. Note that the Status bytes used for the low data
rate System only are prefixed with an L while the Status bytes used for the high data rate System only are
prefixed with an H.
First byte transmitted:
Status0
- RCD Status is written during initialization of the RCD.
A bit which is set indicates that an error condition occurred during the particular test, as shown in table 4. This
is a read-only location.
Table 4 - RCD Status state bit definitions
Bit RCD state
7 RCD type Status:
sel - Integrated RCD
reset - Stand-alone RCD
6 Datalog initialization incomplete
Reserved
RCD tests had an error:
Internal RAM error
External RAM error
Non-volatile memory error
Program check sum error
Statusl-2
- RCD Software version (1) and Subversion (2) Status is a read-only location.
Status3 -- Handshake byte, used by the host to reset internal RCD buffers ancl also to prevent data tearing
when multiple transfers of a particular buffer are obtained. Esch bit is discussed below.
Bit 7 -
RCD external UART CTS Status (Controller communications for the iRCD and extemal portable data
collection Computer for the sRCD). Set active to a logic one when the UART is in the CIS mode, i.e. currently
capable of transfers. This bit is a read-only bit, the MMU cannot set/reset it.
Bit 6 - RCD device Status buffer Status. Set active indicates that the buffer contains information available
to the MMU. The MMU may reset this Status by transmitting logic Zero in this bit Position, while a logic one
will not Change the buffer ’s state.
Bit 5 - RCD device response buffer Status. Set active indicates that the buffer contains information avail-
able to the MMU. The MMU may reset this Status by transmitting logic Zero in this bit Position, while a logic
one will not Change the buffer ’s state. Note that a buffer in the process of being loaded by the controller
(iRCD) will not abort the transmission.
Bit 4 -
RCD device datalog buffer Status. Set active indicates that the buffer contains information available
to the MMU. The MMU may reset this Status by transmitting logic Zero in this bit Position, while a logic one
will not Change the buffer ’s state. Note that a buffer in the process of being loaded by the controller (iRCD)
will not abort the transmission.
Bit 3 - RCD response buffer Status. Set active indicates that the buffer contains information available to the
MMU.
Bit 2 -
For an sRCD only, RCD external portable data collection Computer buffer Status, if applicable. Set
active to a logic one when either the external serial channel UART receive or the transmit buffer contains
valid information. This information is not exchanged on the power line communications network. This bit tan
be reset by the MMU, but the serial channel communications are not affected.
Bit 1
- At present undefined.
Bit 0 -- RCD data-logger buffer update handshake bit. The RCD sets this bit whenever the RCD has updated
its internal data-logger buffer. The MMU resets the bit Prior to transfer and Checks it after the transfer is
complete, thus providing a means to check possible data tearing of the buffer.
Status4-5 - Available power line buffer size high (4) and low (5) bytes.
LStatus6 -
Indicates the maximum size for any data packet (or block) transmitted by the RCD on the power line
network. This number will never exceed the available buffer size. Its default is set at 128 or 80H.
LStatus7 - Indicates the number of attempts the RCD will perform for a particular job in which it received an
invalid response on the power line from the MDCU. The default is set at 02.
LStatus8 -
Indicates the number of retries required on the power line. Rollover OFFH to OOH will not occur. lt
tan be reset using the RCD Parameters command, as described in 3.2.1.3.2.
Status9 - Indicates the current baud rate the iRCD is communicating with the controller. For the sRCD, this
indicates the current baud rate the device is cornmunicating with an external device, if applicable. The corre-
sponding baud rates are given in table29.
Status10 - Indicates the maximum baud rate the iRCD tan communicate with the controller. For the sRCD, this
indicates the maximum baud rate the device tan communicate with an external device, if applicable. The cor-
responding baud rates are given in table 29.
Status1 1-14 - At present undefined.
3,2.1.1.2.2 RCD xmitl and xmit2 commands
The RCD xmitl and xmit2 command transfers text data to a selected RCD Slave. The xmitl versus xmit2
selection defines the method of transfer on the power Iine and is further described for the appropriate low data
rate or high data rate modern (3.2.2 and 3.2.3 respectively). From the Point of view of the MMU, these process
differentes are invisible, except for the time of response. The data field sent to the MDCU from the MMU con-
tains the routing byte followed by the 11 byte ASCII RCD network address. The information following this ad-
dress is the text data, or message, to be given to the selected RCD, i.e.
Data field to MDCU = Routing byte/address + RCD message
The RCD message field is discussed in 3.2.1.3. Inscribed in it is a subcommand which the RCD evaluates and
processes accordingly. If this subcommand requires a response from the RCD, the RCD buffers it in an RCD
response buffer. An RCD interactive poll command (as described in 3.2.1.1.2.5) is then used to obtain this buf-
fered response. These xmit commands, however, only return a general valid type reply (see 3.2.1.2.1) from the
MDCU to the MMU after the MDCU receives the proper acknowledgement of transfer from the Slave RCD. The
routing byte/address are returned in the data field of this reply, i.e.
Data field from MDCU valid = Routing byte/address
3.2.1 .1.2.3 RCD interactivel and interactive2 commands
The RCD interactivel and interactive2 commands transfer text data to a selected RCD Slave in exactly the Same
way as the RCD xmit commands described in 3.2.1.1.2.2. As with the xmit commands, the interactivel versus
interactive2 selection defines the method of transfer on the power line and is further described for the appro-
priate low data rate or high data rate modern (3.2.2 and 3.2.3 respectively). From the Point of view of the MMU,
these process differentes are invisible, except for the time of response. The interactive commands provide the
RCD with a subcommand inscribed in the text data, which the RCD evaluates and processes accordingly. (The
RCD processes the interactive commands in the Same way as the xmit commands.) If this subcommand re-
quires a response from the RCD, the RCD buffers it in an RCD response buffer. The differente between the RCD
xmit and interactive commands occurs here in the MDCU processing. Instead of returning a valid reply to the
MMU when the MDCU receives a proper acknowledgement from the Slave RCD for the transfer of text data, the
MDCU queues an RCD interactive pell comma
...