Connecting third-party devices

to the

MCS-5 FIELD BUS 1

Documentation for design engineers

Structure and function of the

field bus 1 communication protocol

E 531 827 / 00 E

assuring you

certification:
Quality assurance in design/development,
production, installation and service

Guide

Page

Table of contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

IV

Preface

Contents and target audience of this document . . . . . . . . . . . . . . . . . . .

System overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.1

Structure of the MCS-5 system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2

Structure of the communication protocol in layer 1 . . . . . . . . . . . . . . . . . . . .

1.2.1

Brief description of the attributes in the communication protocol . . . . . . . .

1.3

Structure of the communication protocol in layer 2 . . . . . . . . . . . . . . . . . . . .

1.3.1
1.3.1.1

Data type definition in layer 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Data type Measuring point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6
6

1.4

Device data and project data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.4.1

Device data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.4.2

Project data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Description of the field bus 1 protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

2.1

Measuring point transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

2.1.1
2.1.1.1
2.1.1.2
2.1.1.3
2.1.1.4

Services and transmission modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Cycle times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cycle times for third-party devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Delta value generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Multiplex variable (MUX) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10
10
10
10
10

2.1.2
2.1.2.1
2.1.2.2

PDU measuring point data format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Assignment of data field byte 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Possible assignments of data field byte 2, 3, 4 and 5 . . . . . . . . . . . . . . . . . .

11
11
11

2.1.3
2.1.3.1

Measuring point normalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Measuring point normalization for third-party devices . . . . . . . . . . . . . . . . . .

12
12

2.1.4
2.1.4.1

Sensor Defect handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Sensor Defect for third-party devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12
12

2.1.5
2.1.5.1
2.1.5.2

Missing Data handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Missing Data for third-party devices receiving . . . . . . . . . . . . . . . . . . . . .
Missing Data for third-party devices transmitting . . . . . . . . . . . . . . . . . . .

13
13
13

FRIEDRICHSHAFEN

Table of contents

E 531 827 / 00 E

04.99

Page

II

Guide
FRIEDRICHSHAFEN

Table of contents (cont.)

2.2

Network monitoring NMT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

2.2.1
2.2.1.1
2.2.1.2
2.2.1.3

Monitoring of interfaces and devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Node address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NMT Alive PDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
COB ID for network monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14
14
14
15

2.2.2

Data format of the NMT Alive PDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

2.2.3
2.2.3.1

Brief description of the attributes in the NMT Alive PDU data format . . . .
Meaning and assignment of the attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16
16

2.2.4
2.2.4.1
2.2.4.2
2.2.4.3

Field bus 1 redundancy and redundancy switching . . . . . . . . . . . . . . . . . . . .

Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Redundancy switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Criteria for switching from the default interface to the
redundant interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17
17
17
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
2.3.6.1
2.3.6.2
2.3.6.3
2.3.6.4

Data format of the download protocol services . . . . . . . . . . . . . . . . . . . . . . . .

Download PU Data Enable Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Download PU Data Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Download PU Data Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Download PU Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20
20
21
21
21

2.3.7
2.3.7.1
2.3.7.2
2.3.7.3
2.3.7.4

Operating states of the client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Bootup mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Download mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Measuring point transmission mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Overview of operating states and operating state transitions in
tabular form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22
22
22
23

Download sequence control flow chart from the client perspective . . . . . . .

24

2.3.8

04.99

23

E 531 827 / 00 E

Guide

Page

III

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

3.1.2.6
3.1.2.7
3.1.2.8
3.1.2.9

Description of the segments in the project data module

and their attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Segment 1: OS-9 module header (length: 34 bytes) . . . . . . . . . . . . . . . . . . .
Segment 2: User data length (length: 4 bytes) . . . . . . . . . . . . . . . . . . . . . . . .
Segment 3: User data header part 1 (length: 16 bytes) . . . . . . . . . . . . . . . .
Segment 4: User data header part 2 (length: 8 bytes) . . . . . . . . . . . . . . . . .
Segment 5: Measuring point attributes (length: n x 16 bytes,
whereby n is max. 128) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Segment 6: Normalization tables (length specific) . . . . . . . . . . . . . . . . . . . . .
Segment 7: Checksum (length: 2 bytes) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Segment 8: Filler bytes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Segment 9: OS-9-CRC (length: 4 bytes) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30
31
31
31
31

3.2

Description of the normalization tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

3.2.1
3.2.1.1
3.2.1.2
3.2.1.3
3.2.1.4
3.2.1.5

Structure of the normalization tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Normalization table representing data direction = 0 . . . . . . . . . . . . . . . . . . . .
Normalization table representing data direction = 1 . . . . . . . . . . . . . . . . . . . .
Influence of data direction on the X/Y values . . . . . . . . . . . . . . . . . . . . . . . . .
Normalization method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Linear interpolation of the values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32
32
33
33
34
34

3.2.2

Structure of the normalization tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

35

FRIEDRICHSHAFEN

Table of contents (cont.)

3.1.2.1
3.1.2.2
3.1.2.3
3.1.2.4
3.1.2.5

E 531 827 / 00 E

04.99

28
28
28
29
30

Page

IV

Guide
FRIEDRICHSHAFEN

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

04.99

E 531 827 / 00 E

Guide

Page
FRIEDRICHSHAFEN

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

E 531 827 / 00 E

04.99

Page

VI

Guide
FRIEDRICHSHAFEN

(This page intentionally blank)

04.99

E 531 827 / 00 E

Chapter 1

System overview
FRIEDRICHSHAFEN

Page

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 implementation 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 thirdparty 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.

E 531 827 / 00 E

05.99

Chapter 1
Page

System overview
FRIEDRICHSHAFEN

(This page intentionally blank)

05.99

E 531 827 / 00 E

Chapter 1

System overview
FRIEDRICHSHAFEN

Chapter 1

System overview

E 531 827 / 00 E

05.99

Page

Chapter 1
Page

System overview

FRIEDRICHSHAFEN

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)

Management level
PLC

PLC

Field automation level

MTU Engine
Control
Unit

MTU
coupler

Field bus 1

MTU
I/O device

Fig.

1:

MTU
I/O device

Field bus 1

MTU
I/O device

MTU
I/O device

Third-party
device

Structure of an MCS-5 system

05.99

E 531 827 / 00 E

Chapter 1

System overview

Page

FRIEDRICHSHAFEN

1.2

Structure of the communication protocol in layer 1

A communication protocol has been especially developed for the MCS-5 system. It corresponds 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:

Start
bit

Fig.

2:

COB ID

RTR

DLC
field

Data field

CRC
field

Ack
field

EOF
field

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 regardless of the station concerned

EOF

End Of Frame
Each data and data request telegram is terminated by a bit sequence of 7
recessive bits.

E 531 827 / 00 E

05.99

Chapter 1
Page

System overview

1.3

FRIEDRICHSHAFEN

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.

05.99

E 531 827 / 00 E

Chapter 1

System overview
FRIEDRICHSHAFEN

1.4

Page

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 software. Other definitions must be inparted to the devices during initial start-up. A differentiation 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 environment at his disposal for this.
Device data are defined on completion of project implementation. The project implementation environment automatically generates the project data for the individual devices.

E 531 827 / 00 E

05.99

Chapter 1
Page

System overview
FRIEDRICHSHAFEN

(This page intentionally blank)

05.99

E 531 827 / 00 E

Chapter 2

Protocol description
FRIEDRICHSHAFEN

Chapter 2

Description of the field bus 1 protocol

E 531 827 / 00 E

05.99

Page

Chapter 2
Page

Protocol description

10

FRIEDRICHSHAFEN

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 individual 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.

05.99

E 531 827 / 00 E

Chapter 2

Protocol description

Page

FRIEDRICHSHAFEN

2.1.2

PDU measuring point data format

2.1.2.1

Assignment of data field byte 6

11

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 measuring point data format.
The second segment enlargement shows the bit assignment of the status byte (byte
no. 6).

Start
bit

RTR DLC
field

COB ID

Byte
Contents

MUX

Analog/binary measured value

Bit
Contents

Fig.

3:

2.1.2.2

Data field

CRC
field

Ack EOF
field field

Status

SDF bit

Bit assignment of the status byte (byte no. 6)

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

E 531 827 / 00 E

05.99

Chapter 2
Page

2.1.3

12

Protocol description
FRIEDRICHSHAFEN

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.

05.99

E 531 827 / 00 E

Chapter 2

Protocol description
FRIEDRICHSHAFEN

2.1.5

Page

13

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 measuring 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.

E 531 827 / 00 E

05.99

Chapter 2
Page

Protocol description

14

FRIEDRICHSHAFEN

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 operation 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 unambiguous 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 configuration 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 protocol), 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.

05.99

E 531 827 / 00 E

Chapter 2

Protocol description
FRIEDRICHSHAFEN

2.2.1.3

Page

15

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 contrast to the other FB 1 devices, knows the precise network configuration.

E 531 827 / 00 E

05.99

Chapter 2
Page

Protocol description

16

2.2.2

FRIEDRICHSHAFEN

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).

Byte
Contents

Fig.

4:

1
MUX

2
3
SPS NODE SW TYP

4
SW VAR

5
SW ED 1

6
SW ED 2

7
SW REV

8
SW MOD

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 manufacturer. This makes it possible to clearly identify third-party software in other devices.
Refer to the project data for project data identification.

05.99

E 531 827 / 00 E

Chapter 2

Protocol description
FRIEDRICHSHAFEN

2.2.4

Field bus 1 redundancy and redundancy switching

2.2.4.1

Redundancy

Page

17

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 separately 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 interface 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.

E 531 827 / 00 E

05.99

Chapter 2
Page

Protocol description

18

FRIEDRICHSHAFEN

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 redundant 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.

05.99

E 531 827 / 00 E

Chapter 2

Protocol description

Page

FRIEDRICHSHAFEN

2.3.4

19

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

PU Data Enable Request

PLC request to FB 1 devices to start

PLC
downloading.

Takes place after the PLC has booted

PU Data Request

Download request of the FB 1 device:

FB 1 device
The PLC is requested to check validity of (client)
the data and transmit current data if
necessary.

Takes place after the FB 1 device has
booted or

After receiving the Enable Request
service

PU Data Response

Download response of the PLC

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.

PU DATA

Transmission of the data

Tab.

2:

Download protocol services

E 531 827 / 00 E

05.99

Transmitting
device

PLC

Chapter 2
Page

Protocol description

20

2.3.6

FRIEDRICHSHAFEN

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:

2.3.6.1

Abbreviations used in the telegrams

Download PU Data Enable Request

This service is started by the PLC.

The assignment number of the COB ID is 0.

Byte
Contents

Fig.

5:

1
0xA5

2
0xFA

3
0xFA

4
0xA5

5
0xFF

6
0x0A

7
0x0A

8
0xFF

Data format of the Download PU Data Enable Request

05.99

E 531 827 / 00 E

Chapter 2

Protocol description

Page

FRIEDRICHSHAFEN

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>.

Byte
Contents

Fig.

6:

1
mux = 0

2
service_id

3
node_no

5
checksum

6
0

7
0

8
0

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>.

Byte
Contents

Fig.

7:

1
mux = 0

2
service_id

3
node_no

5
pdu_count

7
checksum

8
0

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>.

Byte
Contents

Fig.

8:

5
data

Data format of the Download PU Data service

E 531 827 / 00 E

05.99

21

Chapter 2
Page

Protocol description

22

FRIEDRICHSHAFEN

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 Response.
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.

05.99

E 531 827 / 00 E

Chapter 2

Protocol description
FRIEDRICHSHAFEN

2.3.7.3

Page

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

E 531 827 / 00 E

05.99

23

Chapter 2
Page

Protocol description

24

2.3.8

FRIEDRICHSHAFEN

Download sequence control flow chart from the client perspective

Client in
download mode

Transmission of a Download Request

Start TIMEOUT_1 = 5 sec

No

Receipt of a
Download Response within
TIMEOUT_1 = 5 sec

Yes
Evaluation of the Download Response

Data valid?

Attributes of the Download

Response
pdu_count = 0
Checksum = Checksum data

Yes

No
Attributes of the Download
Response received
pdu_count = Number of PDUs
Checksum = Checksum new data
Start TIMEOUT_2 = 4 sec
Transmission of the nth project
implementation block
Block size (BLOCK_PDU_SIZE)
1st block: 639 PDUs
All other blocks: 640 PDUs

Yes

pdu_count PDUs (all PU data)

received?

No

No

Generation of checksum of
transmitted data

BLOCK_PDU_SIZE PDUs
received within
TIMEOUT_2 = 4 sec

Yes
Transmission of an NMT Alive PDU
(block receipt confirmation)
Start TIMEOUT_2 = 4 sec

No

Data transmission OK?

Compare checksum with
checksum

Yes
Client starts
measured value
transmission mode

Fig.

9:

Download sequence control flow chart from the client perspective

05.99

E 531 827 / 00 E

Chapter 3

Thirdparty devices
FRIEDRICHSHAFEN

Chapter 3

Project data for third-party devices

E 531 827 / 00 E

05.99

Page

25

Chapter 3
Page

Thirdparty devices

26

FRIEDRICHSHAFEN

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 information 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 information 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 operating system OS-9. Only the contents of the data module are relevant for the FB 1 client.

05.99

E 531 827 / 00 E

Chapter 3

Thirdparty devices
FRIEDRICHSHAFEN

3.1.1

Page

27

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

Client project data are described in the middle of the module.

OS-9 module header

34 bytes

User data length

4 bytes

User data header

Part 1

16 bytes

User data header

Part 2

8 bytes

Measured value attributes

n x 16 bytes

Normalization tables

specific

Checksum

2 bytes

Filler bytes
OS-9 CRC

Fig.

10:

4 bytes

Structure of the project data module

E 531 827 / 00 E

05.99

Chapter 3
Page

Thirdparty devices

28

FRIEDRICHSHAFEN

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

Number of bytes

Starting with the user data header (inclusive) 4 bytes

Ending with the checksum (inclusive)

Tab.

5:

Length

Attributes of user data length

05.99

E 531 827 / 00 E

Chapter 3

Thirdparty devices

Page

FRIEDRICHSHAFEN

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 relevant for the third-party device.

1 byte

Domain length

Domain length corresponds to user data length 2 bytes

Starting with the user data header (inclusive)

Ending with the checksum (inclusive)

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 1 byte

bus 1 design

Value 1: Field bus 1 is of simple design

Value 2: Field bus 1 is of redundant design

Tab.

6:

Attributes of the user data header part 1

E 531 827 / 00 E

05.99

29

Chapter 3
Page

Thirdparty devices

30

3.1.2.4

FRIEDRICHSHAFEN

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:

3.1.2.5

Attributes of the user data header part 2

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 normalization 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.
1 byte
The following values are possible:

Value 0: Data are transmitted from the thirdparty 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

Reserved bytes

Reserved bytes

Tab.

8:

8 bytes

Attributes of the measuring point attributes

05.99

E 531 827 / 00 E

Chapter 3

Thirdparty devices
FRIEDRICHSHAFEN

3.1.2.6

Page

31

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 viceversa) in normalization tables.

E 531 827 / 00 E

05.99

Chapter 3
Page

Thirdparty devices

32

3.2.1

FRIEDRICHSHAFEN

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 calculated 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: Y0 = Y1 or Yn = Yn1
3.2.1.1

Normalization table representing data direction = 0

Y axis: MCS-5 normalized measuring point

Pt. 3 (x3 / y3)

Pt. 4 (x4 = MD_VALUE / y4 = y3)

Pt. 1 (x1 / y1)

Pt. 2 (x2 / y2)

Pt. 0 (SDF_VALUE + 1 / y0 = y1)

X axis: Third-party device

normalized measuring point

Fig.

11:

Representation of the measuring points as a curve data direction = 0

05.99

E 531 827 / 00 E

Chapter 3

Thirdparty devices

Page

FRIEDRICHSHAFEN

3.2.1.2

33

Normalization table representing data direction = 1

Y axis: Third-party device normalized measuring point

Pt. 3 (x3 / y3)

Pt. 4 (x4 = MD_VALUE / y4 = y3)

Pt. 1 (x1 / y1)

Pt. 2 (x2 / y2)

Pt. 0 (SDF_VALUE + 1 / y0 = y1)

X axis: MCS-5 normalized

measuring point

Fig.

12:

3.2.1.3

Representation of the measuring points as a curve data direction = 1

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

E 531 827 / 00 E

05.99

Chapter 3
Page

3.2.1.4

Thirdparty devices

34

FRIEDRICHSHAFEN

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

X0 = SDF_VALUE + 1 (Hex: 0x80000000)

Y0 = Y1

Last curve value

Xn = MD_VALUE
Yn = Yn1

Interpolation is only effected for X values in the range X1 X Xn1.

If the X value is < X1, the Y value is set to the value Y1.
If the X value is > Xn1, the Y value is set to the value Yn1.
The values are given in the tables as signed 4-byte integer values.

05.99

E 531 827 / 00 E

Chapter 3

Thirdparty devices

Page

FRIEDRICHSHAFEN

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.

X0 table 0

Offset x

Y0 table 0
X1 table 0
Y1 table 0
...
...
Xn table 0
Yn table 0

Table 2

Offset y

...

Table n

Fig.

13:

Structure of the normalization tables

E 531 827 / 00 E

05.99

Offset z

35

Chapter 3
Page

36

Thirdparty devices
FRIEDRICHSHAFEN

(This page intentionally blank)

05.99

E 531 827 / 00 E

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.

 1999
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