ISO 10368:2006
(Main)Freight thermal containers — Remote condition monitoring
Freight thermal containers — Remote condition monitoring
ISO 10368:2006 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 complying remote communication devices of differing manufacture and configuration used by other carriers and terminals. The data-logging formats and message protocols outlined in ISO 10368:2006 apply to all currently available data rate transmission techniques. These formats and protocols also apply to all future techniques designed to be an ISO International Standard compatible system.
Conteneurs à caractéristiques thermiques — Système de pilotage à distance des groupes frigorifiques
General Information
Relations
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 10368
Second edition
2006-02-15
Freight thermal containers — Remote
condition monitoring
Conteneurs à caractéristiques thermiques — Système de pilotage à
distance des groupes frigorifiques
Reference number
©
ISO 2006
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.
© ISO 2006
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2006 – All rights reserved
Contents Page
Foreword. iv
Introduction . v
1 Scope. 1
2 Normative references. 1
3 Terms and definitions. 1
4 Performance requirements . 3
4.1 General. 3
4.2 Requirements. 3
4.2.1 System components. 3
4.2.2 Performance function. 4
4.2.3 Performance constraints . 8
5 System compatibility requirements . 9
5.1 General. 9
5.2 Communications protocol . 9
5.2.1 General. 9
5.2.2 MMU to MDCU communications . 9
5.2.3 MDCU to LRCD communications . 33
5.2.4 MDCU to HRCD communications. 42
5.3 MMU/Device communications. 50
5.3.1 Headers. 50
5.3.2 Other MMU/Device messages. 50
5.4 Low data rate physical requirements — LDCU to LRCD . 51
5.4.1 Frequency. 51
5.4.2 Modulation method. 51
5.4.3 Baud rate. 51
5.4.4 Transmission mode. 51
5.4.5 Injection mode. 51
5.4.6 Receiver sensitivity. 51
5.4.7 Non-transmission Impedance . 51
5.4.8 Bit synchronization. 51
5.4.9 Carrier setup time. 51
5.4.10 Out-of-band filtering for HDR compatibility . 51
5.5 High data rate physical requirements — HDCU to HRCD. 52
5.5.1 Modulation method — Broad band. 52
5.5.2 Transmission mode. 52
5.5.3 Injection mode. 53
5.5.4 Output/input impedance. 53
5.5.5 Power density function . 53
5.5.6 Synchronization method. 53
5.5.7 Demodulation method. 53
5.5.8 Receiver sensitivity. 53
5.5.9 Data link protocol. 54
5.5.10 Out-of-band filtering requirements for “LDR” compatibility. 61
Bibliography . 64
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 normally carried out through ISO
technical committees. Each 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, governmental 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.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO 10368 was prepared by Technical Committee ISO/TC 104, Freight containers, Subcommittee SC 2,
Specific purpose containers.
This second edition cancels and replaces the first edition (ISO 10368:1992), which has been technically
revised.
iv © ISO 2006 – All rights reserved
Introduction
In revising this International Standard, material relating to the RCD/Controller interface has been deleted as it
is not relevant to the powerline interface, and the section on data logging formats has been deleted as it is not
used in the industry. Where necessary, other smaller additions, deletions and corrections have been applied.
The International Organization for Standardization (ISO) draws attention to the fact that it is claimed that
compliance with this document may involve the use of a patent concerning the low and high data rate systems
given in 5.4 and 5.5 respectively. ISO takes no position concerning the evidence, validity and scope of this
patent right.
The holder of this patent right has assured ISO that he/she is willing to negotiate licences under reasonable
and non-discriminatory terms and conditions with applicants throughout the world. In this respect, the
statement of the holder of this patent right is registered with ISO. (The declarations have not yet been
received by ISO.) For the low data rate system, information may be obtained from:
Thermo King Corporation,
314 W 90th Street
Minneapolis, Minnesota 55420
USA
For the high data rate system, information may be obtained from:
Adaptive Networks Incorporated
1505 Commonwealth Ave.
Suite 30
Brighton, Massachusetts 02135
USA
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights other than those identified above. ISO shall not be held responsible for identifying any or all such patent
rights.
INTERNATIONAL STANDARD ISO 10368:2006(E)
Freight thermal containers — Remote condition monitoring
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
complying 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 International Standard-compatible system.
The performance requirements for the monitoring, communication and control system are given in Clause 4.
The system compatibility requirements are given in Clause 5. All sections of this International Standard apply
to all implementations, except where specified.
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
ISO 1496-2:1996, Series 1 freight containers — Specification and testing — Part 2: Thermal containers
ISO 9711-2, Freight containers — Information related to containers on board vessels — Part 2: Telex data
transmission
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
remote communications device
RCD
device which is physically a part of the refrigeration machinery and which communicates with any complying
CMCS using the refrigeration machinery power distribution system as the data transmission medium
NOTE 1 See Figures 1 and 2.
NOTE 2 There are two distinct types of RCD:
⎯ an sRCD (see 3.9); and
⎯ an iRCD (see 3.10).
3.2
central monitoring and control system
CMCS
system consisting of hardware and software which monitors and controls one or more RCDs
NOTE A typical system consists of at least:
a) operator interface devices;
b) an MMU; and
c) power line data link equipment, such as an MDCU.
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
NOTE It is the interface between the human operator and the network.
3.4
multiple data rate central control unit
MDCU
device which forms the link between the MMU and the three-phase power line bus which contains the
individual RCDs
NOTE An MDCU consists of two components as follows:
⎯ a central control unit capable of receiving and transmitting at the data rates which meet the requirements of this
International Standard; and
⎯ a central control interface.
3.5
high data rate remote communications device
HRCD
RCD which transmits data at a high data rate, e.g. 19,200 baud
3.6
low data rate remote communications device
LRCD
RCD which communicates data at a low data rate, e.g. 1 200 baud
3.7
high data rate central control unit
HDCU
device which links the MMU and the power line network, communicating with the HRCDs
3.8
low data rate central control unit
LDCU
device which links the MMU and the power line network, communicating with the LRCDs
3.9
stand-alone remote communications device
sRCD
slave remote communications device RCD which, with limited capabilities, merely monitors a container
refrigeration unit
NOTE An sRCD can be either high or low data rate.
2 © ISO 2006 – All rights reserved
3.10
integrated remote communications device
iRCD
slave remote RCD which interfaces to a refrigeration unit controller via an EIA R5232-C serial interface and
can control the refrigeration machinery
NOTE An iRCD can be either high or low data rate.
3.11
controller
microprocessor device that monitors and controls the refrigeration machinery
4 Performance requirements
4.1 General
This clause specifies the performance requirements of central monitoring and control systems (CMCSs)
necessary for them to interface and communicate with complying remote communications devices (RCDs).
4.2 Requirements
4.2.1 System components
4.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, Configuration A.)
4.2.1.2 MDCU
An MDCU may include one high data rate central control unit (HDCU) and one low data rate central control
unit (LDCU). If an HDCU and an LDCU are both present, the single remote condition monitoring system
consists of a maximum of one MMU and one MDCU. (See Figure 1, Configuration A. The HDCU and LDCU
are joined together by a central control unit (CCU) interface, and the three components together form the
MDCU.
4.2.1.3 MMU/MDCU interface
The preferred method of connecting the MMU to the MDCU complex is through a single port as shown in
Figure 1, Configuration A. However, certain expansion paths may require multiple connections as shown in
Figure 1, Configuration B.
4.2.1.4 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.
4.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 shall be compatible. Refer to 5.2 and 5.3 for the required protocol and
data-logging formats.
4.2.2 Performance function
4.2.2.1 Standard message
All RCDs shall respond to a minimum list of standardized enquiries (see 4.2.2.4) and commands with a
standardized reply or acknowledgement.
4.2.2.2 Acknowledgement message
The RCD shall send an acknowledgement message for all commands and enquiries that are received and
understood.
4.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
configuration of the RCD and the thermal control machinery, it shall respond with a “Not able” message.
4.2.2.4 Required enquiries
4.2.2.4.1 General
All RCDs shall respond to the following required enquiries given in 4.2.2.4.2 to 4.2.2.4.7.
4.2.2.4.2 Identification number
For an integrally refrigerated or thermal container, this shall be the container ISO number comprising a 4-letter
alphabetical prefix and a 7-digit suffix (including the check digit). Where a demountable marine clip-on unit is
used, the identification number shall be the MDCU number in ISO format.
4.2.2.4.3 Porthole container number
This response shall be in addition to the identification number for MDCU systems.
4.2.2.4.4 Porthole number change
This shall be recorded in the RCD memory in alphanumerical format, together with the time of the change.
4.2.2.4.5 Return air temperature
This shall be recorded in the form of a positive or negative value, expressed in degrees Celsius to one
decimal place, within the range −30,0 °C to +38,0 °C.
4.2.2.4.6 Supply air temperature
This shall be expressed in the same format as 4.2.2.4.5.
4.2.2.4.7 RCD manufacturer and type
This shall consist of a unique identification number registered and controlled by ISO, and for which
ISO/TC 104 is the registration authority.
4 © ISO 2006 – All rights reserved
a) Configuration A
b) Configuration B
Components
MMU master monitoring unit MDCU multiple data rate central control unit
∅3 three-phase power mains HRCD high data rate remote communications device
CCU central control unit LRCD low data rate remote communications device
LDCU low data rate central control unit
HCDU high data rate central control unit
RCD remote communications device
Figure 1 — Remote condition monitoring system components layout
4.2.2.5 Optional standard enquiries
4.2.2.5.1 General
Other optional enquiries shall be standardized. RCDs and refrigeration machinery so equipped shall respond
to the enquiries given in 4.2.2.5.2 to 4.2.2.5.14. RCDs not so equipped shall respond “Not able” (see 4.2.2.3).
4.2.2.5.2 Operating mode
These include Full cool, Partial or Lower capacity cool, Modulated cool, Fans only or Null mode, Defrost, Heat,
Off.
4.2.2.5.3 Set-point temperature
This shall be expressed in the same format as 4.2.2.4.5.
4.2.2.5.4 Alarms
These include High refrigeration pressure, Temperature out of range, Low compressor oil pressure,
Defrost/Heat/Overheat, Compressor 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). (There is
capacity for future development, e.g. controlled atmosphere.)
4.2.2.5.5 All current alarms
These shall be in sequence of occurrence.
4.2.2.5.6 Product temperatures
These include, for example, tank, poultry.
4.2.2.5.7 Data-logger interval
This shall be one digit in half-hour intervals up to a maximum of 12 h.
4.2.2.5.8 Amperage
This shall be 0 to 63,75 A in 0,25 A intervals.
4.2.2.5.9 Destination
This may be up to five alphanumerical digits. If the destination changes, both the old and the current
destination may be declared.
4.2.2.5.10 Port of discharge
This may be up to five alphanumerical digits.
4.2.2.5.11 Origin
This may be up to five alphanumerical digits.
4.2.2.5.12 Report results of self-check level 1
These shall be one digit: 0 = Fail, 1 = Pass.
6 © ISO 2006 – All rights reserved
4.2.2.5.13 Report results of self-check level n
This shall be in the format of up to 256 ASCII characters, where n is a single character between two and nine.
4.2.2.5.14 Vessel and voyage designation
(See ISO 9711-2.)
4.2.2.6 Commands
4.2.2.6.1 General
RCDs and refrigeration machinery if so equipped shall respond to the commands given in 4.2.2.6.2 to
4.2.2.6.9. RCDs not so equipped shall respond “Not able” (see 4.2.2.3).
4.2.2.6.2 Change set-point temperature
This shall be expressed in the same format as 4.2.2.4.5.
4.2.2.6.3 Initiate self-check level 1
The self-check level 1 shall be initiated.
4.2.2.6.4 Initiate self-check level n
This shall be expressed in the same format as 4.2.2.5.13, where n is in the range two to nine.
4.2.2.6.5 Change identification number
This shall be expressed in the same format as 4.2.2.4.2.
4.2.2.6.6 Change data-logger interval
This shall be expressed in the same format as 4.2.2.5.7.
4.2.2.6.7 Set data-logger time and date
This shall have the date expressed in the format year/month/day.
4.2.2.6.8 Change operating mode
This shall be expressed in the same format as 4.2.2.5.2.
4.2.2.6.9 Change porthole container number
This shall be expressed in the same format as 4.2.2.4.4.
4.2.2.7 Indecipherable or unserviceable messages
Indecipherable or unserviceable messages shall not cause the RCD or CMCS to “crash” or “hang up”. Also,
failures of an electronic device in any RCD shall not cause the system to “crash” or “hang up”.
4.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.
4.2.3 Performance constraints
4.2.3.1 Power interference
RCDs and CMCSs shall not interfere with the proper functioning of power supply regulating or controlling
devices, such as voltage regulators or protective relaying equipment.
4.2.3.2 Marine device Interference
CMCSs and RCDs, individually or as a system, shall not interfere with standard marine navigation and
communication devices.
4.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.
4.2.3.4 Status update
The MMU/MDCU system shall generate RCD updated status in accordance with 4.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.
4.2.3.5 Automatic RCD system list
The population or database of RCDs on the CMCS shall be self-generating. No input to the MMU, whether
from an operator or from another computer, shall be necessary to determine the RCDs connected to that
system.
4.2.3.6 Identification of new RCDs
The MMU/MDCU system shall be designed to identify an average of at least one new container every 10 s, or
6 per minute.
4.2.3.7 Voltage and frequency requirements
RCDs shall be suitable for operating on the voltage systems specified in ISO 1496-2.
4.2.3.8 RCD connection
The RCD shall be connected on the line side of the refrigeration machinery disconnect 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.
4.2.3.9 Error rates
4.2.3.9.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”
communication errors. An “undetected and uncorrected” communication error is one which is not detected and
corrected within 5 min after occurrence.
8 © ISO 2006 – All rights reserved
4.2.3.9.2 An error whereby an RCD executes a command which was not commanded by the MMU shall
not occur more often than one time in 25 × 10 messages (i.e. any power line disturbance which the receiver
interprets as a message), or more often than once in 10 years for each CMCS, whichever is greater.
4.2.3.9.3 An error whereby a CMCS misinterprets a message (i.e. any power line disturbance which the
receiver interprets as a message) shall not occur more often than one time in 25 × 10 messages.
5 System compatibility requirements
5.1 General
This clause 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) systems.
5.2 Communications protocol
5.2.1 General
Each 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.
Figure 2 — Remote condition monitoring — Communications interfaces
5.2.2 MMU to MDCU communications
5.2.2.1 General
This subclause, in part, 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
R5232-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 twice the baud rate of the fastest RCD in the system. A typical communications baud rate is
4 800 baud. Each 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 Figure 3). These
messages may be intended for action by the MDCU only. These messages are described fully in 5.2.2.2. If the
message contains embedded data intended for an RCD, the format is as described in 5.2.2.4. Similarly,
embedded data intended for the refrigeration machinery is described in 4.2.5.2.1 and 4.2.2.6.1. Note that the
field length, in bytes, is also defined in Figure 3.
Key
1 interactive 1 and 2 commands only
2 device commands only
a
Mask bit equals 1 if there is a 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 MCDU is as shown in Figure 4.
SYNC Packet
STX Task No. Xmit type Data CRC
(optional) length
No. of
1 2 1 1 2
bytes
Figure 4 — Information transfer format from the MMU to the MDCU
The information transfer format returned to the MMU from the MDCU is as shown in Figure 5.
SYNC Packet
STX Task No. Xmit type Data CRC
(optional) length
No. of
1 2 1 1 2
bytes
Figure 5 — Information transfer format returned to the MMU from the MDCU
10 © ISO 2006 – All rights reserved
The fields in Figures 4 and 5 are defined as follows:
⎯ SYNC — An optional synchronization field. It may be any number of bytes, the contents of which are 16H.
The MDCU strips all SYNC characters from the start.
⎯ STX — Delimits the start of a valid message. It 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. It is transmitted high byte followed by low byte.
⎯ Task No. — A 1-byte number assigned to the job before transmission to the MDCU. It is not used by the
MDCU and is defined by the application. The MDCU reply contains 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 processing which is to be
performed on the data. The assignments are discussed in 5.2.2.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 5.2.2.2 and 5.2.2.3 for each appropriate command.
⎯ CRC-A 16 bit error check field generated by using the CRC-16 polynomial:
16 15 2
X + x + x + 1
The optional SYNC characters are not included in the CRC calculation.
5.2.2.2 MMU to MDCU transmit command types
5.2.2.2.1 General
There are two groups of commands which are sent to the MDCU: those directed to the MDCU for internal
processing only and those to be transferred over the power line. The former group is given in Table 1, while
the latter group is given in Table 2. An explanation of each command follows.
5.2.2.2.2 MDCU directed command types
5.2.2.2.2.1 General
This group of commands requires processing within the MDCU, i.e. the power line communications network is
not accessed. The commands currently supported by the MDCU are given in Table 1 and explained in
5.2.2.2.2.2 to 5.2.2.2.2.4.
Table 1 — MDCU interrogation directed command types
Command Value
DCU reset 20H
MDCU parameters 22H
MDCU status 23H
5.2.2.2.2.2 MDCU reset command
Upon request, the MDCU shall perform its internal diagnostics and initialize with default parameters. Any data
associated with this command shall be ignored. Since the MDCU is reset, the initial status condition with
default parameters shall be returned to the MMU as defined in 5.2.2.2.2.3. Task number 255 will be used in
the reply.
5.2.2.2.2.3 MDCU parameters command
The MDCU parameters command loads the MDCU with information 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
parameters 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:
⎯ Parameter 0 — Test status byte is a read-only location and, therefore, this parameter is ignored by the
MDCU.
⎯ Parameter 1-2 — MDCU software version/subversion is a read-only location and, therefore, this
parameter is ignored by the MDCU.
⎯ Parameter 3 — The MMU handshaking flag byte between the MDCU and MMU is changed. Each bit is
discussed below.
⎯ Bit 7 — This is MDCU external UART CTS status (MMU communications). This bit is always received by
the MMU in the active, or logic on, 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.
⎯ Bit 6-0 — Although accessible to the MMU, at present it is not used by the MDCU.
⎯ Parameter 4-5 — Change is available for buffer size high (4) and low (5) bytes. It decreases/expands
power line buffers. If the new size is below/above the MDCU’s minimum/maximum value, its
minimum/maximum value is used. A value of zero, or a value received which is equivalent to the previous
setting, retains the previous setting. If a change in the buffer size is performed, all jobs within queue are
lost.
⎯ Lparameter 6 — The maximum size of the packets (or blocks) to be transferred on the power line is
changed. If received larger than the available buffer size setting (described above), that value will be
substituted. A value of zero retains the previous setting (unless that setting is greater than the new
available buffer size). It 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.
⎯ Lparameter 7 — The number of retransmissions to be attempted for a given job on the power line is
changed.
⎯ Lparameter 8 — The counter indicating the number of retries which have been performed on the power
line is changed.
⎯ Lparameter 9 — The counter indicating the number of successful normal polls which required one retry
on the power line is changed.
⎯ Lparameter l0 — The counter indicating the number of successful normal polls which required two retries
on the power line is changed.
⎯ Parameter 11 — The time delay base value used within an interactive command (5.2.2.2.3.4 and
5.2.2.2.3.9) that is required between the MDCU transmission of data to an RCD and the interactive poll
used to obtain a response from the RCD is changed. Each count provides a 0,1 s incremental delay.
12 © ISO 2006 – All rights reserved
⎯ Parameter 12-14 — This is presently 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 field containing less
than 3 bytes will not change any parameters in the MDCU status buffer. Also, Parameter 4-5 is 2 bytes in
length and a byte count which transfers only one of these bytes will not update this parameter.
Regardless of whether any parameters were changed, the MDCU reply will return the current status value
to the MMU in a general valid type reply, as defined in 5.2.2.3.2.
5.2.2.2.2.4 MDCU status command
The MDCU status command simply requests the MDCU to reply with its present status value. Any data
associated with this command is ignored. The definition of this status buffer corresponds to the assignments
discussed in 5.2.2.2.2.3 (MDCU parameters command), or as defined in 5.2.2.3.2.
5.2.2.2.3 MDCU power line command types
5.2.2.2.3.1 General
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 is given
in 5 2.2.3.
Table 2 — MDCU power line directed command types
Command Value
RCD poll 30H
RCD xmit1 31H
RCD xmit2 32H
RCD interactive1 33H
RCD interactive2 34H
RCD map 35H
RCD interactive poll 36H
Device poll 40H
Device xmit1 41H
Device xmit2 42H
Device interactive1 43H
Device interactive2 44H
Device map 45H
Device interactive poll 46H
Extended device poll 47H
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 5.2.2.2.3.7) and is used by the MDCU
to route the message to the proper data rate modem. 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-0) are defined in the
appropriate low or high data rate subclauses, 5.2.3 and 5.2.4 respectively.
Table 3 — Routing byte data rate bit assignments
Bits 7-6 Definition
00 Illegal
01 ISO LRCD
10 ISO HRCD
11 Reserved
The routing byte is always followed by an 11-byte ASCII RCD network address. Two address fields are
reserved for special use in the RCDs. A universal address consisting of all ASCII Os, or all 30H, is recognized
by all RCDs (i.e. a broadcast address) while a field containing nine ASCII Os followed by two ASCII??s, or
nine 3OHs plus two 3lHs, 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 characters
from control characters.
5.2.2.2.3.2 RCD poll 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 5.2.2.3.2), i.e.
Data field from MDCU valid = 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 initialisation 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
RGD type status:
7 Set - Integrated RCD
Reset - Stand-alone RCD
6 Datalog initialization incomplete
5 Reserved
4 RCD tests had an error:
3 Internal RAM error
2 External RAM error
1 Non-volatile memory error
0 Program check sum error
14 © ISO 2006 – All rights reserved
⎯ Status 1-2 — RCD software version (1) and subversion (2) status is a read-only location.
⎯ Status 3 — This is the handshake byte, used by the host to reset internal RCD buffers and also to prevent
data tearing when multiple transfers of a particular buffer are obtained. Each bit is discussed below.
⎯ Bit 7 — This is the RCD external UART CTS status (controller communications for the iRCD and external
portable data collection computer for the sRCD). Set active indicates a logic one when the UART is in the
CTS mode, i.e. currently capable of transfers. This bit is a read-only bit, the MMU cannot set/reset it.
⎯ Bit 6 — This is the 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 — This is the RCD device response 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 4 — This is the 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 — This is the RCD response buffer status. Set active indicates that the buffer contains information
available to the MMU.
⎯ Bit 2 — For an sRCD only, this is the 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 can be reset by the MMU, but the serial channel communications are not affected.
⎯ Bit 1 — This is at present undefined.
⎯ Bit 0 — This is the 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.
⎯ Status 4-5 — This is the available power line buffer size high (4) and low (5) bytes.
⎯ Lstatus 6 — This 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.
⎯ Lstatus 7 — This 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.
⎯ Lstatus 8 — This indicates the number of retries required on the power line. Rollover OFFH to OOH will
not occur. It can be reset using the RCD parameters command, as described in 5.2.2.4.3.
⎯ Status 9 — This indicates the current baud rate the iRCD is communicating with the controller. For the
sRCD, this indicates the current baud rate the device is communicating with an external device, if
applicable. The corresponding baud rates are given in Table 5.
⎯ Status 10 — This indicates the maximum baud rate the iRCD can communicate with the controller. For
the sRCD, this indicates the maximum baud rate the device can communicate with an external device, if
applicable. The corresponding baud rates are given in Table 5.
Table 5 — Baud rate definitions
RT New baud rate
00 Default rate
01 75 baud
02 110 baud
03 300 baud
04 600 baud
05 1 200 baud
06 2 400 baud
07 4 800 baud
08 9 600 baud
09 19,2 kilobaud
10 38,4 kilobaud
11 67,2 kilobaud
12 100 kilobaud
Status 11-12 — Controller Software Version:
Data type: unsigned integer
Data format: stored as a 2 byte value in BCD (binary coded decimal) format
Example: rev 5117 = 01010001 00010111
Status 3 — Manufacturer Code: Assigned by ISO, Carrier Transicold — type “1”, type “0” reserved [restricted
to numeric (non alpha) characters]:
Data type: unsigned byte
Data format: stored as an unsigned one byte value
Example: 1 = 00000001
Status 14 — Manufacturer Type Indicator: Assigned by manufacturer (restricted to numeric (non alpha)
characters):
Data type: unsigned byte
Data format: stored as an unsigned one-byte value
Example: 82 = 01010010
Reserved values: The following values shall be reserved for ISO use:
0000H
FF00H
00FFH
FFFFh
5.2.2.2.3.3 RCD xmit1 and xmit2 commands
The RCD xmit1 and xmit2 command transfers text data to a selected RCD slave. The xmit1 versus xmit 2
selection defines the method of transfer on the power line and is further described for the appropriate low data
rate or high data rate modem (5.2.3 and 5.2.4 respectively
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...