Structure and function of the

field bus 1 communication protocol

E 531 827 / 00 E
Connecting third-party devices
to the
MCS-5 FIELD BUS 1
Documentation for design engineers

assuring you
certification:
Quality assurance in design/development,
production, installation and service
Guide Page I
FRIEDRICHSHAFEN
E 531 827 / 00 E 04.99
Table of contents
Table of contents I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Abbreviations IV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Preface Contents and target audience of this document 3 . . . . . . . . . . . . . . . . . . .
1 System overview 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1 Structure of the MCS-5 system 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Structure of the communication protocol in layer 1 5 . . . . . . . . . . . . . . . . . . . .
1.2.1 Brief description of the attributes in the communication protocol 5 . . . . . . . .
1.3 Structure of the communication protocol in layer 2 6 . . . . . . . . . . . . . . . . . . . .
1.3.1 Data type definition in layer 2 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.1.1 Data type Measuring point 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4 Device data and project data 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.1 Device data 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.2 Project data 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Description of the field bus 1 protocol 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1 Measuring point transmission 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1 Services and transmission modes 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1.1 Cycle times 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1.2 Cycle times for third-party devices 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1.3 Delta value generation 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1.4 Multiplex variable (MUX) 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.2 PDU measuring point data format 11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.2.1 Assignment of data field byte 6 11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.2.2 Possible assignments of data field byte 2, 3, 4 and 5 11 . . . . . . . . . . . . . . . . . .
2.1.3 Measuring point normalization 12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.3.1 Measuring point normalization for third-party devices 12 . . . . . . . . . . . . . . . . . .
2.1.4 Sensor Defect handling 12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.4.1 Sensor Defect for third-party devices 12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.5 Missing Data handling 13 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.5.1 Missing Data for third-party devices receiving 13 . . . . . . . . . . . . . . . . . . . . .
2.1.5.2 Missing Data for third-party devices transmitting 13 . . . . . . . . . . . . . . . . . . .
Guide
FRIEDRICHSHAFEN
Page II
E 531 827 / 00 E 04.99
Table of contents (cont.)
2.2 Network monitoring NMT 14 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.1 Monitoring of interfaces and devices 14 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.1.1 Node address 14 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.1.2 NMT Alive PDU 14 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.1.3 COB ID for network monitoring 15 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.2 Data format of the NMT Alive PDU 16 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.3 Brief description of the attributes in the NMT Alive PDU data format 16 . . . .
2.2.3.1 Meaning and assignment of the attributes 16 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.4 Field bus 1 redundancy and redundancy switching 17 . . . . . . . . . . . . . . . . . . . .
2.2.4.1 Redundancy 17 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.4.2 Redundancy switching 17 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.4.3 Criteria for switching from the default interface to the
redundant interface 17 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 Service mode: Download 18 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.1 Downloading project data 18 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.2 Data transmission saving 18 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.3 Download criterium: Checking data validity 18 . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.4 Client consistency check of project data 19 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.5 Overview of download protocol services 19 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.6 Data format of the download protocol services 20 . . . . . . . . . . . . . . . . . . . . . . . .
2.3.6.1 Download PU Data Enable Request 20 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.6.2 Download PU Data Request 21 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.6.3 Download PU Data Response 21 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.6.4 Download PU Data 21 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.7 Operating states of the client 22 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.7.1 Bootup mode 22 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.7.2 Download mode 22 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.7.3 Measuring point transmission mode 23 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.7.4 Overview of operating states and operating state transitions in
tabular form 23 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.8 Download sequence control flow chart from the client perspective 24 . . . . . . .
Guide Page III
FRIEDRICHSHAFEN
E 531 827 / 00 E 04.99
Table of contents (cont.)
3 Project data for third-party devices 26 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1 Description of project data structure 26 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.1 Structure of the project data module 27 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.2 Description of the segments in the project data module
and their attributes 28 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.2.1 Segment 1: OS-9 module header (length: 34 bytes) 28 . . . . . . . . . . . . . . . . . . .
3.1.2.2 Segment 2: User data length (length: 4 bytes) 28 . . . . . . . . . . . . . . . . . . . . . . . .
3.1.2.3 Segment 3: User data header part 1 (length: 16 bytes) 29 . . . . . . . . . . . . . . . .
3.1.2.4 Segment 4: User data header part 2 (length: 8 bytes) 30 . . . . . . . . . . . . . . . . .
3.1.2.5 Segment 5: Measuring point attributes (length: n x 16 bytes,
whereby n is max. 128) 30 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.2.6 Segment 6: Normalization tables (length specific) 31 . . . . . . . . . . . . . . . . . . . . .
3.1.2.7 Segment 7: Checksum (length: 2 bytes) 31 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.2.8 Segment 8: Filler bytes 31 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.2.9 Segment 9: OS-9-CRC (length: 4 bytes) 31 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Description of the normalization tables 31 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1 Structure of the normalization tables 32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1.1 Normalization table representing data direction = 0 32 . . . . . . . . . . . . . . . . . . . .
3.2.1.2 Normalization table representing data direction = 1 33 . . . . . . . . . . . . . . . . . . . .
3.2.1.3 Influence of data direction on the X/Y values 33 . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1.4 Normalization method 34 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1.5 Linear interpolation of the values 34 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.2 Structure of the normalization tables 35 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Guide
FRIEDRICHSHAFEN
Page IV
E 531 827 / 00 E 04.99
Abbreviations
Ack field Ack field (used for positive confirmation of receipt from any CAN bus node
regardless of the station concerned)
CAN Controller Area Network (bus standard)
COB CAN Object (CAN telegram transmitted on the CAN bus)
COB ID CAN Object Identifier (part of the CAN telegram which determines object
priority during transmission)
CRC Test sequence for detecting faults during data transmission
(length: 15 bit CRC + 1 bit CRC delimiter)
DLC Data Length Code Field (data length in bytes (Data Field));
(max. adjustable length: 8 bytes)
EOF End Of Frame (each data and data request telegram is terminated by a bit
sequence comprising 7 recessive bits)
FB 1 Field bus 1
I/O device Input/Output device (receiving and transmitting device)
ms Milliseconds
MUX Multiplex value (first byte of the CAN data field required for unambiguous
process data identification)
NMT Network Management (part of the communication protocol, for network
monitoring, performs network services)
PB Process bus
PDU Protocol Data Unit (data field of the CAN telegram)
PLC Programmable Logic Controller
PLC Node Process bus node address of the associated PLC
PU Projektierungsumgebung, project implementation environment
(for the MCS-5 field bus 1)
RTR Remote Transmission Request
Guide Page V
FRIEDRICHSHAFEN
E 531 827 / 00 E 04.99
Abbreviations (cont.)
sec Seconds
SDF Sensor Defect (special bit designation for detecting sensor failure)
SW_ED_1 First information block concerning software edition
SW_ED_2 Second information block concerning software edition
SW_MOD Project data modification status
SW_REV Project data revision status
SW_TYPE Software for a specific type of device
SW_VAR Software variant
Guide
FRIEDRICHSHAFEN
Page VI
E 531 827 / 00 E 04.99
(This page intentionally blank)
System overview
Chapter 1
Page 1 FRIEDRICHSHAFEN
E 531 827 / 00 E 05.99
Preface
Contents and target audience of this document
This manual is divided into three chapters.
Chapters 1 and 2 are intended for all personnel wishing to familiarize themselves with the
structure and function of the MCS-5 field bus 1 protocol.
Chapter 3 is intended for design engineers developing third-party devices. A third-party
device is a device produced by another manufacturer which exchanges process data with
the MCS-5 system in accordance with the field bus 1 protocol.
Special project data must be created for the third-party device to allow it to participate in
communication on field bus 1. MTU plant project engineers have a graphic project imple-
mentation environment at their disposal for this. The plant project engineer also integrates
the third-party device in the MCS-5 plant by agreement with the manufacturer of the third-
party device. Project data for the third-party device are created as a result.
Chapter 3 describes the structure of the project data and the project data module in detail.
Chapter 1
2 Page
System overview
FRIEDRICHSHAFEN
E 531 827 / 00 E 05.99
(This page intentionally blank)
System overview
Chapter 1
Page 3 FRIEDRICHSHAFEN
E 531 827 / 00 E 05.99
Chapter 1
System overview
Chapter 1
4 Page
System overview
FRIEDRICHSHAFEN
E 531 827 / 00 E 05.99
1 System overview
This chapter provides an overview of the structure of the
Entire MCS-5 system
Field bus 1 communication protocol
1.1 Structure of the MCS-5 system
A differentiation is made between
Management level
Field automation level
in the MTU Monitoring and Control System MCS-5 automation system.
A maximum of 31 devices can be connected to field bus 1 in the MCS-5 system (1 PLC +
30 MTU I/O devices or third-party devices). The figure below illustrates the structure of an
MCS-5 system:
Management Computer Unit
Process bus (redundant)
PLC PLC
Field bus 1 Field bus 1
MTU
I/O device
MTU
I/O device
MTU
I/O device
MTU
I/O device
MTU
coupler
MTU Engine
Control
Unit
Management level
Field automation level
Third-party
device
Fig. 1: Structure of an MCS-5 system
System overview
Chapter 1
Page 5 FRIEDRICHSHAFEN
E 531 827 / 00 E 05.99
1.2 Structure of the communication protocol in layer 1
A communication protocol has been especially developed for the MCS-5 system. It corres-
ponds to the ISO/OSI layer model whereby only layers 1, 2 and 7 are used. Parts of the
other layers are included in layer 7.
Standard CAN frames are used exclusively in communication layer 1. The CAN telegram
for layer 1 has the following structure:
DLC
field
RTR
CRC
field
Ack
field
EOF
field
Start
bit
COB ID
Data field
Fig. 2: Structure of the CAN telegram in layer 1
Some parts of this telegram, particularly the data field (field 5) are described in this
manual in more detail.
1.2.1 Brief description of the attributes in the communication protocol
Start bit Start bit (dominant bit, identifies the start of the telegram)
COB ID CAN Object Identifier (11 bits)
RTR Remote Transmission Request (1 bit)
Always set to zero
DLC Data Length Code field
Length (in bytes) of the user data (Data field);
max. adjustable length: 8 bytes
Data field User data
The length of the data field is: 0 to 8 bytes
CRC Test sequence to detect faults during data transmission,
length: 15 bits CRC + 1 bit CRC delimiter
Ack field Ack field
Used for positive confirmation of receipt from any CAN bus node regard-
less of the station concerned
EOF End Of Frame
Each data and data request telegram is terminated by a bit sequence of 7
recessive bits.
Chapter 1
6 Page
System overview
FRIEDRICHSHAFEN
E 531 827 / 00 E 05.99
1.3 Structure of the communication protocol in layer 2
Only the inner blocks of the CAN telegram described are visible in layer 2:
COB ID
RTR
DLC
Data field
The start and end blocks (start bit or Ack field and EOF) are only taken into consideration
in layer 1.
1.3.1 Data type definition in layer 2
Communication objects are divided into various types of data in layer 2. A type of data is
described by:
Assignment to a fixed COB ID value range.
Overall value range: 0 to 2031
Data length definition DLC of 8 bytes
Structural evaluation of the data field
Various services are supported in communication depending on the type of data
transmitted.
1.3.1.1 Data type Measuring point
Measuring point is a possible data type. This data type is used to transmit process data.
Measuring points are transmitted with the WRITE_REQ service. WRITE_REQ is a
cyclic, non-confirmed service.
System overview
Chapter 1
Page 7 FRIEDRICHSHAFEN
E 531 827 / 00 E 05.99
1.4 Device data and project data
The individual devices require several definitions to fulfill their communication tasks.
Definitiions which do not depend on a particular plant are largely implemented in the soft-
ware. Other definitions must be inparted to the devices during initial start-up. A differentia-
tion is made between device data and project data.
1.4.1 Device data
Device data are device settings which are required to allow the device to execute simple
basic functions. When the device data have been set, the device can establish contact
with other devices or service mode can be started.
Device data are e.g. the CAN baud rate and the node address. These data are stored in a
non-volatile memory during initial start-up.
1.4.2 Project data
All other settings required by the FB 1 device to participate in network operations and
communication are referred to as project data.
Device and project data are defined during the project implementation phase of the
MCS-5 plant. The plant project engineer has a graphic project implementation environ-
ment at his disposal for this.
Device data are defined on completion of project implementation. The project implementa-
tion environment automatically generates the project data for the individual devices.
Chapter 1
8 Page
System overview
FRIEDRICHSHAFEN
E 531 827 / 00 E 05.99
(This page intentionally blank)
Protocol description
Chapter 2
Page 9 FRIEDRICHSHAFEN
E 531 827 / 00 E 05.99
Chapter 2
Description of the field bus 1 protocol
Chapter 2
10 Page
Protocol description
FRIEDRICHSHAFEN
E 531 827 / 00 E 05.99
2 Description of the field bus 1 protocol
2.1 Measuring point transmission
2.1.1 Services and transmission modes
Measuring points are transmitted in the field automation level with the WRITE_REQ
service. WRITE_REQ is a non-confirmed service. The receiver need not acknowledge
receipt of the measuring point to the transmitter.
2.1.1.1 Cycle times
The FB 1 device transmits the measuring points cyclically. The cycle times for each indivi-
dual measuring point can be selected as a multiple of the basic cycle (200 ms). The cycle
times are defined for the device by the project data.
2.1.1.2 Cycle times for third-party devices
A cycle time of 400 ms is set for third-party devices for reasons of simplicity. It is not
necessary to set the date for each measuring point to be transmitted in the project data.
2.1.1.3 Delta value generation
The transmitting devices generate a delta value for the measuring points to relieve the
bus: Transmission only takes place within the set cycle when the value of a measuring
point changes.
If a value does not change within 20 sec, the measuring point is transmitted nevertheless.
This superordinate transmission cycle of 20 sec allows Missing Data to be detected in
the receiving devices.
Refer to chap. 2.1.5 Missing Data handling for details.
2.1.1.4 Multiplex variable (MUX)
The first user data byte is used as a multiplex variable (see first byte of data field segment
enlargement in fig. 3).
The multiplex variable and COB ID together identify each measuring point unambiguously
throughout the system.
Protocol description
Chapter 2
Page 11 FRIEDRICHSHAFEN
E 531 827 / 00 E 05.99
2.1.2 PDU measuring point data format
2.1.2.1 Assignment of data field byte 6
The figure below illustrates the communication protocol (see also fig. 2) with two segment
enlargements.
The first segment enlargement shows the structure of the data field for the PDU measu-
ring point data format.
The second segment enlargement shows the bit assignment of the status byte (byte
no. 6).
Start
bit
COB ID
RTR DLC
field
Data field
CRC
field field
Ack
field
EOF
field
Byte
Contents
Bit
Contents
MUX Analog/binary measured value Status
SDF bit
Fig. 3: Bit assignment of the status byte (byte no. 6)
2.1.2.2 Possible assignments of data field byte 2, 3, 4 and 5
The table below shows the possible data formats of the PDU measuring points (byte 2,
byte 3, byte 4 and byte 5):
Possible values Designation
Analog measuring point Normalized measured value
SDF_VALUE
MD VALUE
Binary measuring point TRUE = 1
FALSE = 0
SDF_VALUE
MD VALUE
Sensor Defect SDF_VALUE: 2147483647 (Hex: 0x80000001)
Missing Data MD_VALUE: 2147483647 (Hex: 0x7FFFFFFF)
Tab. 1: PDU measuring point data formats
Chapter 2
12 Page
Protocol description
FRIEDRICHSHAFEN
E 531 827 / 00 E 05.99
2.1.3 Measuring point normalization
All measuring points on FB 1 are transmitted with a normalized base. A base unit is
defined for each physical measured variable. For example, each pressure is transmitted
as a multiple of the base unit 0.01 mbar.
The electrical sensor values are transmitted in physical base units. The normalization
information is provided for the MCS-5 acquisition devices in the project data.
The normalization information is stored in curve tables. The acquisition device performs
normalization as a linear interpolation on the basis of the given points of the curve. Refer
to chap. 3.2.1 Structure of the normalization tables for further information about curve
tables.
2.1.3.1 Measuring point normalization for third-party devices
Third-party devices require information to convert the MCS-5 measuring point into the
measuring point normalized for the third-party device and to convert the measuring point
normalized for the third-party device into the MCS-5 measuring point. Normalization is
also described on the basis of curve tables in this case.
2.1.4 Sensor Defect handling
The MCS-5 acquisition devices perform sensor defect handling. On detecting the sensor
defect,
The measuring point is set to SDF_VALUE (see tab. 1) and
The SDF bit is set in the status byte (see fig. 3)
The SDF bit is evaluated in the PLC to allow the sensor defect to be displayed by the
management computer. The information about the sensor defect is passed on in the PLC.
This takes place during process data processing. All measuring points derived from an
SDF_VALUE measuring point are also set to SDF_VALUE. The SDF bit is not passed
on.
2.1.4.1 Sensor Defect for third-party devices
A third-party device informs the MCS-5 system about a sensor defect by setting the
expected measuring point to SDF_VALUE. The SDF bit in the status byte (data field byte
no. 6) is not set.
Protocol description
Chapter 2
Page 13 FRIEDRICHSHAFEN
E 531 827 / 00 E 05.99
2.1.5 Missing Data handling
As described in chap. 2.1.1.3 under Delta value generation, all measuring points are
transmitted at least every 20 sec. The FB 1 devices detect Missing Data from the mea-
suring points on the basis of delta value generation. A receiving monitoring timeout of 30
sec is applied to each expected measuring point. The measuring point value is set to
MD_Value (byte 2, byte 3, byte 4 and byte 5) when this timeout has expired.
2.1.5.1 Missing Data for third-party devices receiving
The third-party device checks measuring point reception by a 30 sec monitoring timeout.
2.1.5.2 Missing Data for third-party devices transmitting
If a component responsible for acquiring a measuring point fails in the third-party device,
the third-party device transmits this measuring point with MD_VALUE.
The third-party device measuring points in the remaining FB 1 devices are set to
MD_VALUE should the third-party device fail completely.
Chapter 2
14 Page
Protocol description
FRIEDRICHSHAFEN
E 531 827 / 00 E 05.99
2.2 Network monitoring NMT
2.2.1 Monitoring of interfaces and devices
2.2.1.1 Node address
Each FB 1 device has its own network management NMT. NMT monitors network opera-
tion of its own and other devices. The CAN interfaces are monitored starting in its own
device. Any faults which occur are rectified automatically. Each FB 1 device has an unam-
biguous node address on the FB 1 line. The node address is a part of the device data.
The number of FB 1 devices on one line is restricted to 31. The devices are assigned
FB 1 addresses 1 31. The individual FB 1 device does not know the exact network confi-
guration and therefore monitors all 30 other possible devices. The PLC always has node
address 1.
2.2.1.2 NMT Alive PDU
The NMT Alive PDU is a special COB (see fig. 2 Structure of the communication proto-
col), with which each FB 1 device signals its presence in the network. The NMT Alive
PDU is transmitted cyclically every 500 ms. Each FB 1 device can thus check any other
FB 1 device.
The timeout for the NMT Alive PDU is 1.2 sec. When FB 1 is of a redundant design, the
NMT Alive PDUs are transmitted on both interfaces. The FB 1 devices are monitored
separately at both interfaces.
Protocol description
Chapter 2
Page 15 FRIEDRICHSHAFEN
E 531 827 / 00 E 05.99
2.2.1.3 COB ID for network monitoring
As the individual FB 1 devices transmit their NMT Alive PDUs asynchronously, each
device requires an unambiguous COB. This is achieved by assigning a device-specific
COB ID. The COB ID number is determined on the basis of the FB 1 node address.
The COB ID number is calculated in accordance with the formula:
1980 (NMT constant) + <FB 1 node address>
The process bus node address of the associated PLC is also included in the data field of
this COB. This means that a network error is detected if two FB 1 devices with the same
FB 1 node address (but located in different FB 1 lines) are relocated.
Other data field elements of this COB identify the device and the device software used.
These data are provided by the NMT for other applications in the device, they are not
required for network monitoring.
The PLC signals failure of FB 1 devices to the management computer. The PLC, in con-
trast to the other FB 1 devices, knows the precise network configuration.
Chapter 2
16 Page
Protocol description
FRIEDRICHSHAFEN
E 531 827 / 00 E 05.99
2.2.2 Data format of the NMT Alive PDU
The segment from the data field (see fig. 2 Structure of the CAN telegram in layer 1)
shown below illustrates the detailed structure of the data field for the NMT Alive PDU
data format.
The first data byte of the user data is always used as multiplex variable (MUX).
1
SPS NODE
2
SW TYP
3
SW VAR
4
SW ED 1
5
SW ED 2
6
SW REV
7
SW MOD
8
MUX
Byte
Contents
Fig. 4: Structure of the data field for the NMT Alive PDU data format
2.2.3 Brief description of the attributes in the NMT Alive PDU data format
2.2.3.1 Meaning and assignment of the attributes
MUX Multiplex variable. The MUX is set to 0.
SPS node Process bus node address of the associated PLC. The node address is
indicated in the project data.
SW_TYPE Identification of the device with the software (SW).
SW_TYPE is defined by MTU. The definition is indicated in the project
data.
SW version:
SW_VAR: Software variant
SW_ED_1: Software edition, first information block concerning software
edition (full information: SW_ED_1_ED_2 )
SW_ED_2: Software edition, second information block concerning
software edition (full information: SW_ED_1_ED_2 )
SW_REV: Project data revision status
SW_MOD: Project data modification status
The information concerning the software version is provided by the third-party manufactu-
rer. This makes it possible to clearly identify third-party software in other devices.
Refer to the project data for project data identification.
Protocol description
Chapter 2
Page 17 FRIEDRICHSHAFEN
E 531 827 / 00 E 05.99
2.2.4 Field bus 1 redundancy and redundancy switching
2.2.4.1 Redundancy
On redundant versions, all devices are connected both to the default interface and the
redundant interface. The network nodes for the individual devices are monitored separa-
tely at both interfaces. Each device counts the active devices at the interface concerned.
Active devices are devices from which the NMT Alive PDUs are received on time.
The information about whether a redundant interface is provided is imparted to the FB 1
devices as a datum in the project data.
2.2.4.2 Redundancy switching
The interface to which measuring points are transmitted is determined in the network
node monitoring cycle (1.2 sec). This is the interface at which more active devices are
determined at this point in time. It is also referred to as the active interface. Measuring
points are only transmitted at the active interface.
All devices appear as masters when redundancy is switched. They decide independently
about when interface switching is to take place. It takes a little time until all remaining
devices transmit at the same interface should one or several devices fail. This has no
influence on the response of the system in operation.
This redundancy switching applies to transmission only.
A device always receives measuring points at both interfaces regardless of which inter-
face is currently operating as the active interface.
2.2.4.3 Criteria for switching from the default interface to the redundant interface
Two states are possible as a result of network monitoring regarding interface monitoring:
The number of active devices at the default interface is greater or equal to the
number of active devices at the redundant interface.
The default interface is defined as the active interface in this case.
The number of active devices at the default interface is less than the number of
active devices at the redundant interface.
The redundant interface is defined as the active interface in this case.
Chapter 2
18 Page
Protocol description
FRIEDRICHSHAFEN
E 531 827 / 00 E 05.99
2.3 Service mode: Download
2.3.1 Downloading project data
The memory of the PLC stores all project data of the associated FB 1 devices. The data
are non-volatile. Before an FB 1 device can transmit its measuring points actively on the
FB 1, it must check that it has the currently valid project data.
A special download protocol is used for this test and for downloading project data between
PLC (data server) and FB 1 device (client).
The download protocol is only supported at the default interface when FB 1 is of redun-
dant design.
2.3.2 Data transmission saving
Correct transmission of a single CAN telegram is saved in layer 1 in the CAN controller.
A 16-bit checksum of the project data is generated to check that all CAN telegrams have
been received. The checksum is calculated by adding the individual byte values of the
project data. The checksum is transmitted directly after the project data.
2.3.3 Download criterium: Checking data validity
Project data is downloaded by the PLC as required.
Downloading is necessary when project data varies between client and server.
The checksum described in chap. 2.3.2 helps to determine whether the current data in
the client are valid. The client transmits its checksum with the server request. The server
determines validity by comparing this checksum with the checksum of the project data
available in the server.
Protocol description
Chapter 2
Page 19 FRIEDRICHSHAFEN
E 531 827 / 00 E 05.99
2.3.4 Client consistency check of project data
The client checks the consistency of its project data before making the server request. It
compares the calculated checksum with the stored checksum.
The client uses the checksum value 0xFFFF(HEX) on making the request if project data
are inconsistent or the client still has no project data.
2.3.5 Overview of download protocol services
The following services are differentiated in the download protocol:
Download service Brief description Transmitting
device
PU Data Enable Request PLC request to FB 1 devices to start
downloading.
Takes place after the PLC has booted
PLC
PU Data Request Download request of the FB 1 device:
The PLC is requested to check validity of
the data and transmit current data if
necessary.
Takes place after the FB 1 device has
booted or
After receiving the Enable Request
service
FB 1 device
(client)
PU Data Response Download response of the PLC
Data valid:
PLC only transmits the Response
service.
Data invalid:
PLC transmits the Response service
with details of the new data and
subsequently transmits the data.
PLC
PU DATA Transmission of the data PLC
Tab. 2: Download protocol services
Chapter 2
20 Page
Protocol description
FRIEDRICHSHAFEN
E 531 827 / 00 E 05.99
2.3.6 Data format of the download protocol services
The download protocol differentiates between 4 services. The length of the data field is
8 bytes for all services.
Abbreviations used in the telegrams:
Designation Meaning
service_id Indicates the number of the service
node_nr Corresponds to the FB 1 node address of the client
pdu_count Number of COBs following this telegram
checksum Describes the checksum of the data on the server or on the
client
data Project data transmitted from the PLC
Tab. 3: Abbreviations used in the telegrams
2.3.6.1 Download PU Data Enable Request
This service is started by the PLC.
The assignment number of the COB ID is 0.
0xFA 0xFA 0xA5 0xFF 0x0A 0x0A 0xFF 0xA5
1 2 3 4 5 6 7 8 Byte
Contents
Fig. 5: Data format of the Download PU Data Enable Request
Protocol description
Chapter 2
Page 21 FRIEDRICHSHAFEN
E 531 827 / 00 E 05.99
2.3.6.2 Download PU Data Request
This service is started by the FB 1 device, the client.
The assignment number for the COB ID is: 1900 + <Node address of the FB 1 device>.
service_id node_no checksum 0 0 0 mux = 0 Contents
1 2 3 4 5 6 7 8 Byte
Fig. 6: Data format of the Download PU Data Request
Contents of the bytes:
For the multiplex variable: MUX = 0.
For the service ID: service_id = 8.
For the checksum: Client data checksum
2.3.6.3 Download PU Data Response
This service is started by the PLC.
The assignment number for the COB ID is: 1932 + <Node address of the FB 1 device>.
service_id node_no pdu_count checksum 0 mux = 0 Contents
1 2 3 4 5 6 7 8 Byte
Fig. 7: Data format of the Download PU Data Response service
Contents of the bytes:
For the multiplex variable: MUX = 0.
For the service ID: service_id = 9.
For the checksum: Server data checksum
2.3.6.4 Download PU Data
This service is started by the PLC.
The assignment number for the COB ID is: 1932 + <Node address of the FB 1 device>.
data Contents
1 2 3 4 5 6 7 8 Byte
Fig. 8: Data format of the Download PU Data service
Chapter 2
22 Page
Protocol description
FRIEDRICHSHAFEN
E 531 827 / 00 E 05.99
2.3.7 Operating states of the client
2.3.7.1 Bootup mode
The client is in the device initialization phase and is booting up. The device still has no
information about the network state of other FB 1 devices during this phase.
2.3.7.2 Download mode
The client transmits the Download Request service every 5 sec and waits to receive the
Download Response. Actual downloading is initiated on receiving the Download Re-
sponse.
In the Download Response data field, the client receives the information about whether
its project data are valid. Downloading has been completed if this is the case and the
client goes in to measuring point transmission mode.
If the project data are invalid, the data field provides information about the new project
data subsequently transmitted. Only the COB ID is determined by the protocol in the
Download PU Data service used to transmit the project data. The entire data field is
used to increase the flow of data.
The Download PU Data services are transmitted in blocks whereby each block consists
of a fixed number of COBs. The NMT Alive PDUs inform the PLC when a block has been
completely received by the client. This form of block acknowledgement requires the client
to stop cyclic transmission of its NMT Alive PDUs on entering download mode.
When the client has consistent project data and determines PLC failure by NMT timeout, it
goes into measuring point transmission mode.
Protocol description
Chapter 2
Page 23 FRIEDRICHSHAFEN
E 531 827 / 00 E 05.99
2.3.7.3 Measuring point transmission mode
In measuring point transmission mode, the client receives or transmits the measuring
points in accordance with the project data. The client checks all other devices with the
active NMT and transmits its NMT Alive PDUs cyclically.
2.3.7.4 Overview of operating states and operating state transitions in tabular
form
Current state Transition criteria Transition to
Bootup mode Bootup completed Download mode
Download mode 1. After PLC NMT Alive PDU timeout
2. When consistent PU data are available
Measuring point
transmission
mode
Download mode 1. After PLC NMT Alive PDU timeout
2. When consistent PU data are missing
Download mode
Download mode Download completed successfully Measuring point
transmission
mode
Download mode Download completed unsuccessfully Download mode
Measuring point
transmission
mode
Receipt of Download Enable Request Download mode
Tab. 4: Overview of operating states and operating state transitions
Chapter 2
24 Page
Protocol description
FRIEDRICHSHAFEN
E 531 827 / 00 E 05.99
2.3.8 Download sequence control flow chart from the client perspective
Client in
download mode
Start TIMEOUT_1 = 5 sec
Data valid?
Transmission of the nth project
implementation block
All other blocks: 640 PDUs
pdu_count PDUs (all PU data)
received?
received within
TIMEOUT_2 = 4 sec
Transmission of an NMT Alive PDU
(block receipt confirmation)
Start TIMEOUT_2 = 4 sec
Data transmission OK?
Compare checksum with
checksum
Generation of checksum of
transmitted data
Client starts
measured value
No
Yes
Yes
No
Yes
No
Yes
No
No
Yes
Transmission of a Download Request
Download Response within
TIMEOUT_1 = 5 sec
Receipt of a
Evaluation of the Download Response
Attributes of the Download
Response
pdu_count = 0
Checksum = Checksum data
Attributes of the Download
Response received
pdu_count = Number of PDUs
Checksum = Checksum new data
Start TIMEOUT_2 = 4 sec
Block size (BLOCK_PDU_SIZE)
1st block: 639 PDUs
BLOCK_PDU_SIZE PDUs
transmission mode
Fig. 9: Download sequence control flow chart from the client perspective
Thirdparty devices
Chapter 3
Page 25 FRIEDRICHSHAFEN
E 531 827 / 00 E 05.99
Chapter 3
Project data for third-party devices
Chapter 3
26 Page
Thirdparty devices
FRIEDRICHSHAFEN
E 531 827 / 00 E 05.99
3 Project data for third-party devices
The measuring points are defined in accordance with a list by order-specific agreement
between MTU and the manufacturer of the third-party device. The measuring points in this
list are unambiguously identified by the two attributes Data block number and Data word
number. Furthermore, this list includes the direction of data and the normalization infor-
mation in the minimum configuration (see chap. 3.2.1 Structure of the normalization
tables).
The plant project engineer integrates the third-party device in the MCS-5 plant on the
basis of this list. The project data transmitted to the third-party device via the download
mechanism when running are generated as an end product. These data include all infor-
mation required for communication.
Device data required and to be defined are:
FB 1 node address
FB 1 CAN settings:
Values of the two Bit Timing Registers of the CAN controller. The baud
rate results from the values of these two registers.
The device data are passed on to the third-party device manufacturer after definition by
MTU.
3.1 Description of project data structure
Project attributes are described in Motorola notation.
The structure shown in chap. 3.1.1 describes the structure of the binary file generated as
a product of project implementation. OS-9 data module structure is already supported
meaning that the module can be handled internally without modification by the PLC opera-
ting system OS-9. Only the contents of the data module are relevant for the FB 1 client.
Thirdparty devices
Chapter 3
Page 27 FRIEDRICHSHAFEN
E 531 827 / 00 E 05.99
3.1.1 Structure of the project data module
The project data module is divided into 9 segments. Various attributes are defined in these
segments.
The start and end of the module result from the OS-9 data module structure.
Client project data are described in the middle of the module.
OS-9 module header
User data length
User data header
Part 1
User data header
Part 2
Measured value attributes
Normalization tables
Checksum
Filler bytes
OS-9 CRC 4 bytes
2 bytes
specific
n x 16 bytes
8 bytes
16 bytes
34 bytes
4 bytes
C
l
i
e
n
t

p
r
o
j
e
c
t

d
a
t
a
Fig. 10: Structure of the project data module
Chapter 3
28 Page
Thirdparty devices
FRIEDRICHSHAFEN
E 531 827 / 00 E 05.99
3.1.2 Description of the segments in the project data module and their attributes
3.1.2.1 Segment 1: OS-9 module header (length: 34 bytes)
The OS-9 module header supports the OS-9 data module structure. The module can be
handled internally without modification by the PLC operating system OS-9 in this way.
The OS-9 module header is not described in more detail as it remains invisible for the
client.
3.1.2.2 Segment 2: User data length (length: 4 bytes)
Information about the amount of data (in bytes) of the client project data. Only this part of
the OS-9 module described is transmitted during downloading.
Attributes Meaning of the individual attributes Length
Number of bytes Starting with the user data header (inclusive)
Ending with the checksum (inclusive)
4 bytes
Tab. 5: Attributes of user data length
Thirdparty devices
Chapter 3
Page 29 FRIEDRICHSHAFEN
E 531 827 / 00 E 05.99
3.1.2.3 Segment 3: User data header part 1 (length: 16 bytes)
General information about the project data is included in the first part of the user data
header.
Attributes Meaning of the individual attributes Length
Order Order number 7 bytes
Edition Currently not assigned. The entered value is
zero.
1 byte
SW type SW type is used in the NMT Alive PDU when
running.
1 byte
Domain type Domain data type. This information is not rele-
vant for the third-party device.
1 byte
Domain length Domain length corresponds to user data length
Starting with the user data header (inclusive)
Ending with the checksum (inclusive)
2 bytes
Project data
revision status
Transmitted in the NMT Alive PDU 1 byte
Project data
modification status
Transmitted in the NMT Alive PDU 1 byte
PLC process bus
node address
PLC node address on the process bus 1 byte
FB 1 configuration Differentiates between simple or redundant field
bus 1 design
Value 1: Field bus 1 is of simple design
Value 2: Field bus 1 is of redundant design
1 byte
Tab. 6: Attributes of the user data header part 1
Chapter 3
30 Page
Thirdparty devices
FRIEDRICHSHAFEN
E 531 827 / 00 E 05.99
3.1.2.4 Segment 4: User data header part 2 (length: 8 bytes)
Attributes Meaning of the individual attributes Length
Interface type Interface type defined by MTU 1 byte
Number of
measuring points
(max. 128)
Number of measuring points 2 bytes
Reserved bytes Reserved bytes 5 bytes
Tab. 7: Attributes of the user data header part 2
3.1.2.5 Segment 5: Measuring point attributes (length: n x 16 bytes, whereby n
is max. 128)
Attributes Meaning of the individual attributes Length
COB ID COB ID (transmitted with the measuring point) 2 bytes
MUX Multiplex variable (transmitted with the
measuring point)
1 byte
Offset to normali-
zation table
Offset with reference to the normalization table
for the measuring points.
The offset is calculated from:
Normalization table address minus user data
header address
2 bytes
Data block
number
Logical identifier of a measuring point block 1 byte
Data word number Logical identifier of a measuring point within a
measuring point block
1 byte
Data direction Direction of transmission.
The following values are possible:
Value 0: Data are transmitted from the third-
party device to the MCS-5 field bus 1
Value 1: Data are transmitted from the
MCS-5 field bus 1 to the third-party device
1 byte
Reserved bytes Reserved bytes 8 bytes
Tab. 8: Attributes of the measuring point attributes
Thirdparty devices
Chapter 3
Page 31 FRIEDRICHSHAFEN
E 531 827 / 00 E 05.99
3.1.2.6 Segment 6: Normalization tables (length specific)
The normalization tables are described in chap. 3.2.1 Structure of the normalization
tables.
3.1.2.7 Segment 7: Checksum (length: 2 bytes)
The checksum is a 16-bit cross-checksum to check completeness of data transmission.
The checksum results from the addition of the individual user data byte values.
The checksum is generated by the transmitted data starting with the user data header.
3.1.2.8 Segment 8: Filler bytes
Bytes with a value of 0 which are inserted during data module generation to create an
OS-9-specific module size.
3.1.2.9 Segment 9: OS-9-CRC (length: 4 bytes)
CRC checksum over the entire OS-9 data module.
3.2 Description of the normalization tables
All measuring points are transmitted with a normalized base on FB 1. A unit is defined for
each physical measured variable. Each pressure is, for example, transmitted as a multiple
of the base unit 0.01 mbar.
The third-party device receives the required normalization information for converting the
third-party device normalized measuring point into the MCS-5 measuring point (and vice-
versa) in normalization tables.
Chapter 3
32 Page
Thirdparty devices
FRIEDRICHSHAFEN
E 531 827 / 00 E 05.99
3.2.1 Structure of the normalization tables
The normalization tables represent an X/Y curve by straight lines defined in sections. The
start and end of the individual straight lines are defined by curve points and are defined as
interpolation points in the tables with X/Y value entries. Intermediate values are calcula-
ted by linear interpolation.
A differentiation is made between two data directions in the normalization tables. The two
data directions are:
Data direction = 0 (from the third-party device to the MCS-5 device)
Data direction = 1 (from the MCS-5 device to the third-party device)
In both cases the first and last curve value are: Y
0
= Y
1
or Y
n
= Y
n1
3.2.1.1 Normalization table representing data direction = 0
X axis: Third-party device
normalized measuring point
Y axis: MCS-5 normalized measuring point
Pt. 3 (x
3
/ y
3
)
Pt. 2 (x
2
/ y
2
)
Pt. 1 (x
1
/ y
1
)
Pt. 4 (x
4
= MD_VALUE / y
4
= y
3
)
Pt. 0 (SDF_VALUE + 1 / y
0
= y
1
)
Fig. 11: Representation of the measuring points as a curve data direction = 0
Thirdparty devices
Chapter 3
Page 33 FRIEDRICHSHAFEN
E 531 827 / 00 E 05.99
3.2.1.2 Normalization table representing data direction = 1
Y axis: Third-party device normalized measuring point
X axis: MCS-5 normalized
measuring point
Pt. 3 (x
3
/ y
3
)
Pt. 2 (x
2
/ y
2
)
Pt. 1 (x
1
/ y
1
)
Pt. 4 (x
4
= MD_VALUE / y
4
= y
3
)
Pt. 0 (SDF_VALUE + 1 / y
0
= y
1
)
Fig. 12: Representation of the measuring points as a curve data direction = 1
3.2.1.3 Influence of data direction on the X/Y values
As the X/Y values of the measuring points also depend on the data direction, a further
differentiation is made between the data directions:
From the third-party device to the MCS-5 (data direction = 0)
X value: Physical measuring point of the third-party device
Y value: Physical measuring point in accordance with MCS-5 normalization
From the MCS-5 to the third-party device (data direction = 1)
X value: Physical measuring point in accordance with MCS-5 normalization
Y value: Physical measuring point of the third-party device
Chapter 3
34 Page
Thirdparty devices
FRIEDRICHSHAFEN
E 531 827 / 00 E 05.99
3.2.1.4 Normalization method
Normalization is effected by the linear interpolation method:
Determination of the pair of X values between which the X value lies
Determination of the straight-line equation and calculation of the Y value
3.2.1.5 Linear interpolation of the values
In its simpliest configuration, a curve comprises 4 points whereby the following vertices
are identified by the X/Y values:
First curve value
X
0
= SDF_VALUE + 1 (Hex: 0x80000000)
Y
0
= Y
1
Last curve value
X
n
= MD_VALUE
Y
n
= Y
n1
Interpolation is only effected for X values in the range X
1
X X
n1
.
If the X value is < X
1
, the Y value is set to the value Y
1
.
If the X value is > X
n1
, the Y value is set to the value Y
n1
.
The values are given in the tables as signed 4-byte integer values.
Thirdparty devices
Chapter 3
Page 35 FRIEDRICHSHAFEN
E 531 827 / 00 E 05.99
3.2.2 Structure of the normalization tables
The measuring point attribute Offset to normalization table indicates the X value of the
first curve point.
X
0
table 0
Y
0
table 0
X
1
table 0
Y
1
table 0
Table 2
...
Table n
X
n
table 0
Y
n
table 0
Offset x
Offset y
Offset z
...
...
Fig. 13: Structure of the normalization tables
Chapter 3
36 Page
Thirdparty devices
FRIEDRICHSHAFEN
E 531 827 / 00 E 05.99
(This page intentionally blank)
Das Handbuch ist zur Vermeidung von Strungen oder Schden beim Betrieb zu beachten und daher vom Betreiber dem jeweiligen
Wartungs- und Bedienungspersonal zur Verfgung zu stellen. Auerhalb dieses Verwendungszwecks darf das Handbuch ohne unsere
vorherige Zustimmung nicht benutzt, vervielfltigt oder Dritten sonstwie zugnglich gemacht werden.
nderungen bleiben vorbehalten.
This handbook is provided for use by maintenance and operating personnel in order to avoid malfunctions or damage during operation.
Other than for this purpose, the handbook shall not be reproduced, used or disclosed to others without our prior consent.
Subject to alterations and amendments.
Le manuel devra tre observ en vue dviter des incidents ou des endommagements pendant le service. Aussi recommandons-nous
lexploitant de le mettre la disposition du personnel charg de lentretien et de la conduite. En dehors de cet usage, le manuel ne pourra
tre utilis ni reproduit ou rendu accessible de quelque autre manire des tiers, sans notre consentement pralable.
Nous nous rservons le droit dentreprendre toute modification.
El Manual debe tenerse presente para evitar anomalias o daos durante el servicio, y, por dicho motivo, el usuario debe ponerlo a
disposicin del personal de mantenimiento y de servicio. Fuera de este fin de aplicacin, el Manual no se debe utilizar, copiar ni poner
en manos de terceros, sin nuestro consentimiento previo.
Nos reservamos el derecho de introducir modificaciones.
No sentido de evitar falhas ou danos durante o servicio, o usurio deber cuidar de que o Manual esteja sempre disposio do pessoal
encarregado com a manuteno e operao. Alm desta sua finalidade, o Manual no dever, sob qualquer pretexto, ser reproduzido
parcial ou totalmente ou franqueado a terceiros sem prvia e expressa autorizao de nossa parte.
Reservamo-nos o direito de proceder modificaes.
Il manuale va consultato per evitare anomalie o guasti durante il servizio, per cui va messo a disposizione dall utente al personale addetto
alla manutenzione e alla condotta. Senza nostra approvazione preventiva non ammesso impiegare il manuale per scopi diversi, riprodurlo
o metterlo a disposizione di terzi.
Con riserva di modifiche.
Kytthiriiden ja teknisten vaurioiden vlttmiseksi on noudatettava ksikirjassa annettuja ohjeita, joten kirja on luovutettava huoltoja
kytthenkilkunnan kyttn. Ksikirjaa ei saa ilman sen laatijan lupaa kytt muuhun tarkoitukseen, monistaa tai luovuttaa
ulkopuolisille.
Oikeudet muutoksiin pidtetn.
MTU Motoren- und Turbinen-Union Friedrichshafen GmbH
88040 Friedrichshafen / Germany
Phone (0 75 41) 90 - 0 Telex 7 34 280 50 mt d Telefax (0 75 41) 90 - 61 23
1999