Heinzmann Triton OMD User manual

Copyright 2020 by Heinzmann GmbH & Co. KG. All rights reserved.
This publication may not be reproduced by any means whatsoever or passed on to any third parties.
8929 Manual SF 19 001-e / 03-20
Heinzmann GmbH & Co. KG
Engine & Turbine Management
Am Haselbach 1
D-79677 Schönau
Germany
Phone [phone] - 0
Fax [phone] - 188
E-mail [e-mail]
www.heinzmann.com
V.A.T. No.: DE145551926
HEINZMANN
Engine & Turbine Management
Safety Systems
Triton OMD
Oil Mist Detection System
CAN Protocol

The appropriate manuals must be thoroughly studied before instal-
lation, initial start-up and maintenance.
All instructions pertaining to the system and safety must be followed in
full. Non-observance of the instructions may lead to injury to persons
and/or material damage.
HEINZMANN shall not be held liable for any damage caused through
non-observance of instructions.
Independent tests and inspections are of particular importance for all
applications in which a malfunction could result in injury to persons or
material damage.
All examples and data, as well as all other information in this manual
are there solelyfor the purpose of instruction and they may not be used
for special application without the operator running independent tests
and inspections beforehand.
HEINZMANN does not guarantee, neither expressly nor tacitly, that
the examples, data or other information in this manual is free from er-
ror, complies with industrial standards or fulfils the requirements of any
special application.
To avoid any injury to persons and damage to systems, the follow-
ing monitoring and protective systems must be provided:
−Thermal overload protection
−Overspeed protection independent of the rpm controller
HEINZMANN shall not be held liable for any damage caused through
missing or insufficiently rated overspeed protection.
The following must also be provided for ship propulsion:
−Second power supply for the engine control system
If the governor is used for propulsion, a second power supply has to be
provided to the engine control system if the governor can't keep its po-
sition after power failure.
The following must also be provided for alternator systems:
−Overcurrent protection
−Protection against faulty synchronisation for excessively-large fre-
quency, voltage or phase difference
−Directional contactor
The reasons for overspeeding may be:
−Failure of positioning device, control unit or its auxiliary devices
−Linkage sluggishness and jamming

The following must be observed before an installation:
−Always disconnect the electrical mains supply before any interven-
tions to the system.
−Only use cable screening and mains supply connections that corre-
spond with the European Union EMC Directive
−Check the function of all installed protection and monitoring systems
Please observe the following for electronically controlled injection
(MVC):
−For common rail systems each injector line must be equipped with a
separate mechanical flow-rate limiter
−For unit pump (PLD) and pump-injector unit (PDE) systems, the
fuel enable is first made possible by the solenoid valve’s control
plunger motion. This means that in the event of the control plunger
sticking, the fuel supply to the injection valve is stopped.
As soon as the positioning device receives power, it can actuate the
controller output shaft automatically at any given time. The range of the
controller shaft or control linkage must therefore be secured against un-
authorised access.
HEINZMANN expressly rejects any implied guarantee pertaining to
any marketability or suitability for a special purpose, including in the
event that HEINZMANN was notified of such a special purpose or the
manual contains a reference to such a special purpose.
HEINZMANN shall not be held liable for any indirect and direct dam-
age nor for any incidental and consequential damage that results from
application of any of the examples, data or miscellaneous information
as given in this manual.
HEINZMANN shall not provide any guarantee for the design and
planning of the overall technical system. This is a matter of the operator
its planners and its specialist engineers. They are also responsible for
checking whether the performances of our devices match the intended
purpose. The operator is also responsible for a correct initial start-up of
the overall system.

Contents
Triton OMD CAN protocol / Rev.-No. 03
Table of contents
Page
1 Safety instructions and related symbols.............................................................................. 1
1.1 Basic safety measures for servicing and maintenance..................................................... 2
1.2 Before putting an installation into service after naintenance and repair works.............. 2
2 System description................................................................................................................. 3
2.1 Proper and intended use................................................................................................... 3
2.2 Functional description ..................................................................................................... 3
3 HEINZMANN CAN protocol............................................................................................... 5
3.1 Identifier structure ........................................................................................................... 5
3.2 Node types ....................................................................................................................... 5
3.3 Telegram identifier .......................................................................................................... 6
3.4 Node numbers.................................................................................................................. 6
3.5 Baud rate.......................................................................................................................... 6
3.6 Commands....................................................................................................................... 6
3.7 OMD network communication basics ............................................................................. 7
4 OMD evaluator commands overview .................................................................................. 9
4.1 Overview of send telegrams ............................................................................................ 9
4.2 Overview of receipt telegrams....................................................................................... 10
5 Send telegrams specification .............................................................................................. 11
5.1 Direct sensor number counter command ....................................................................... 11
5.2 Network ID distribution command................................................................................ 11
5.3 Network time synchronization command...................................................................... 12
5.4 Network time update command..................................................................................... 12
5.5 Sensor configuration data telegram ............................................................................... 13
5.6 Sensor internal function execution request telegram..................................................... 13
6 Receipt telegram specification............................................................................................ 15
6.1 Direct sensor number counter command response........................................................ 15
6.2 Reverse sensor number counter command response ..................................................... 15
6.3 Sensor configuration CRC invalidity report.................................................................. 16
6.4 Measurement value report telegram .............................................................................. 16
6.5 Error status report telegram ........................................................................................... 17

Contents
Triton OMD CAN protocol / Rev.-No. 03
7 General communication functions overview..................................................................... 19
7.1 Actual sensor number verification................................................................................. 19
7.1.1 Network connection healthy scenario.................................................................... 19
7.1.2 Network connection break scenario....................................................................... 19
7.1.3 Sensor number verification failure scenario .......................................................... 20
7.2 Automatic sensor ID assignment................................................................................... 20
7.3 Network time synchronization....................................................................................... 21
7.4 Individual sensor configuration..................................................................................... 21
7.4.1 Configuration parameter set................................................................................... 22
7.4.2 CRC check sum calculation................................................................................... 22
7.4.3 Configuration data memory layout ........................................................................ 23
7.5 Sensor internal function execution request.................................................................... 23
7.6 Sensor operational data reception.................................................................................. 24
7.6.1 Measurement value report ..................................................................................... 24
7.6.2 Error and status report............................................................................................ 25
8 Lists....................................................................................................................................... 27
8.1 List of figures ................................................................................................................ 27
8.2 List of tables .................................................................................................................. 28
9 Download of manuals.......................................................................................................... 29

Contents
Triton OMD CAN protocol / Rev.-No. 03
Revision Index
Revision
No.
Date of
modification Name Description of modification
01
10.10.2019
ReY
First edition
02
18.10.2019
ReY
Section “7.6.2 Error and status report”: Bit description for
OMD Error Status Report data items was revised accord-
ing to the latest software state.
03
20.03.20
ReY
External range for temperature parameters was changed.
04
05

1Safety instructions and related symbols
Triton OMD CAN protocol / Rev.-No. 03 1
1Safety instructions and related symbols
This publication offers wherever necessary practical safety instructions to indicate inevitable
residual risks when operating the engine. These residual risks imply dangers to
- Personnel
- Product and machine
- The environment
The primary aim of the safety instructions is to prevent personal injury!
The signal words used in this publication are specifically designed to direct your attention to
possible damage extent!
DANGER indicates a hazardous situation which, if not avoided, will result
in death or serious injury..
WARNING indicates a hazardous situation which, if not avoided, could re-
sult in death or serious injury.
CAUTION indicates a hazardous situation which , if not avoided, may result
in minor or moderate injury.
NOTICE indicates a property damage message.
Safety instructions are not only denoted by a signal word but also by hazard
warning triangles. Hazard warning triangles can contain different symbols
to illustrate the danger. However, the symbol used is no substitute for the
actual text of the safety instructions. The text must therefore always be read
in full!
This symbol does not refer to any safety instructions but offers important notes
for better understanding the functions that are being discussed. They should
by all means be observed and practiced.

1Safety instructions and related symbols
2 Triton OMD CAN protocol / Rev.-No. 03
Basic safety measures for normal operation
•The installation may be operated only by authorized persons who have been duly
trained and who are fully acquainted with the operating instructions so that they are
capable of working in accordance with them.
•Before turning the installation on please verify and make sure that
−only authorized persons are present within the working range of the engine;
−nobody will be in danger of suffering injuries by starting the engine.
•Before starting the engine always check the installation for visible damages and
make sure it is not put into operation unless it is in perfect condition. On detecting
any faults please inform your superior immediately!
•Before starting the engine remove any unnecessary material and/or objects from the
working range of the installation/engine.
•Before starting the engine check and make sure that all safety devices are working
properly!
1.1 Basic safety measures for servicing and maintenance
•Before performing any maintenance or repair work make sure the working area of
the engine has been closed to unauthorized persons. Put on a sign warning that
maintenance or repair work is being done.
•Before performing any maintenance or repair work switch off the master switch of
the power supply and secure it by a padlock! The key must be kept by the person
performing the maintenance and repair works.
•Before performing any maintenance and repair work make sure that all parts of en-
gine to be touched have cooled down to ambient temperature and are dead!
•Refasten loose connections!
•Replace at once any damaged lines and/or cables!
•Keep the cabinet always closed. Access should be permitted only to authorized per-
sons having a key or tools.
•Never use a water hose to clean cabinets or other casings of electric equipment!
1.2 Before putting an installation into service after naintenance and
repair works
•Check on all slackened screw connections to have been tightened again!
•Make sure the control linkage has been reattached and all cables have been recon-
nected.
•Make sure all safety devices of the installation are in perfect order and are working
properly!

2System description
Triton OMD CAN protocol / Rev.-No. 03 3
2System description
2.1 Proper and intended use
CAN protocol, discussed in this document, is used for internode communication in OMD
network. The network can consist of one master device (OMD evaluator or superordinate sys-
tem) and up to 16 OMD sensor devices.
2.2 Functional description
Communication in the OMD network is based on the following key functions:
•HEINZMANN CAN protocol is used for internode communication within the network.
•Each device in the network has its unique ID which is used as node number item of
CAN telegram identifiers.
•Automatic ID assignment procedure is used to start communication within the network
after system power up.
•After successful ID assignment, sequence for checking of operational parameters set
consistency of all OMD sensors on bus is foreseen. If required, master device broad-
casts valid parameter set to the OMD sensors.
•Only after successful ID definition and operational parameter set matching, OMD sen-
sors broadcast own operational data.

2System description
4 Triton OMD CAN protocol / Rev.-No. 03

3HEINZMANN CAN protocol
Triton OMD CAN protocol / Rev.-No. 03 5
3HEINZMANN CAN protocol
HEINZMANN CAN protocol is based on the CAN specification 2.0B with 29 bit identifier.
The identifier contains information about sender and receiver and the command code.
Maximum 8 data bytes are therefore available completely for operative data.
3.1 Identifier structure
Bit range
Bit range
Meaning
Value
28…27
p
priority
always 2
26…23
d
type of receiving device
0…15
22…18
m
destination node number
0, 1….31
17
r
reserved
always 0
16…13
s
type of sending device (source)
0…15
12…8
n
source node number
1…31
7…0
c
command
0…255
Tab. 3.1 Identifier structure
Each connection in a HEINZMANN CAN network is therefore a point-to-point connection. A
telegram is sent by a unique source to a unique destination. An exception is transmission of a
command to all units of the same type using node number 0.
3.2 Node types
Sources and destinations are subdivided in node type (device type) and a node number.
OMD sensor and OMD evaluator are internally treated as AC-devices and have device type
item of identifier equal to 5, which is used in telegram identifier.

3HEINZMANN CAN protocol
6 Triton OMD CAN protocol / Rev.-No. 03
3.3 Telegram identifier
Basic structure of the 29-bit form of the identifier is as follows:
•mmmmm - are the five bits for the node number of the receiving device;
•nnnnn - is the node number of the sending device;
•cccccccc - is the command code.
Communication
direction
p
d
m
r
s
n
c
Identifier
AC to AC
2
5
m
0
5
n
c
10 0110 mmmmm 0 0110 nnnnn cccccccc
Tab. 3.2 Identifier template
3.4 Node numbers
For each device type in the HEINZMANN CAN network each node number in the range be-
tween 1 and 31 must be assigned only once.
Node number 0 is not allowed for a single device, since it is used as the number for messages
to all nodes of a certain type.
In OMD system the following node numbers are used:
•Evaluator has node number 31:
•Sensors have node numbers from 1 to 16.
3.5 Baud rate
Baud rate is fixed and is equal to 250 kBaud.
3.6 Commands
The possible command codes of the telegrams and the respective data mapping are described
in the next section of this document.

3HEINZMANN CAN protocol
Triton OMD CAN protocol / Rev.-No. 03 7
3.7 OMD network communication basics
Communication network topology is shown on the picture below:
Fig. 3.1 Communication network topology
Communication between master device (evaluator or superordinate system) and HEINZ-
MANN OMD sensors is organized in the following way:
•Only the first sensor - sensor 1 and the last sensor - sensor N (N – actual number of sen-
sors in the network) in the network are connected to master device directly (via CAN1
and CAN2 respectively). Other sensors establish direct communication to the master
over partner-devices on both sides via CAN1 and CAN2.
•Communication is point-to-point and is handled as a tunneling connection.
•If destination node number data item of the incoming telegram identifier (mmmmm) is
not equal to current receiver node number (ID), then the message is retransmitted to the
next node in the network until it reaches the receiver specified with (mmmmm). Other-
wise, the message is processed and corresponding response is transmitted to the produc-
er or other predefined actions are performed by the receiver device.
Fig. 3.2 Tunneling connection

3HEINZMANN CAN protocol
8 Triton OMD CAN protocol / Rev.-No. 03

4OMD evaluator commands overview
Triton OMD CAN protocol / Rev.-No. 03 9
4OMD evaluator commands overview
4.1 Overview of send telegrams
Command
Telegram
Remark
Reference
95
kSensNumDirectCountCommand
Default
5.1 Direct sensor number coun-
ter command
97
kNetworkIDDistributRequest
Default
5.2 Network ID distribution
command
49
kNetworkTimeSynchCommand
Default
5.3 Network time synchroniza-
tion command
50
kNetworkTimeUpdateCommand
Default
5.4 Network time update com-
mand
51
kSensorConfigDataTel1
Default
5.5 Sensor configuration data
telegram
84
kInternFunctionRequest
Default
5.6 Sensor internal function ex-
ecution request telegram
Tab. 4.1 Overview of send telegrams

4OMD evaluator commands overview
10 Triton OMD CAN protocol / Rev.-No. 03
4.2 Overview of receipt telegrams
Command
Telegram
Remark
Reference
95
kSensNumDirectCountCommand
Default
6.1 Direct sensor number counter
command response
96
kSensNumReverseCountCommand
Default
6.2 Revers sensor number coun-
ter command response
99
kSensorCRCInvalidReport
Default
6.3 Sensor configuration CRC
invalidity report
20
kMesurementValueReport
Default
6.4 Measurement value report
40
kErrorStatusReport
Default
6.5 Error and status report
Tab. 4.2 Overview of receipt telegrams

5Send telegrams specification
Triton OMD CAN protocol / Rev.-No. 03 11
5Send telegrams specification
5.1 Direct sensor number counter command
Command: 95
Data bytes: 2
Destination: common designated message from master to all sensors.
Timeout: 1 s
Activation: automatic, if all the following conditions are fulfilled:
•unit number verification sequence is in process;
•timeout for feedback from network units has expired.
Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7
High byte Low byte High byte Low byte High byte Low byte High byte Low byte
Data item Sensor
Number
Counter
Tx. CAN
Output
Tag
- - - - -
Tab. 5.1 Command 95
Telegram function details are described in section 7.1 Actual sensor number verification.
5.2 Network ID distribution command
Command: 97
Data bytes: 8
Destination: common designated message from master to all sensors.
Timeout: 0,5 s (for transmit attempt condition check)
Activation: automatic, if all the following conditions are fulfilled:
•ID distribution sequence is in process;
•Timeout for transmit attempt has expired;
•RTC Unix second counter has been changed (incremented).
Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7
High byte Low byte High byte Low byte High byte Low byte High byte Low byte
Data item Actual number of
Sensors in the network
Masters OMD parameter
set CRC
Unix Time High Word Unix Time Low Word
Tab. 5.2 Command 97
Telegram function details are described in section 7.2 Automatic sensor ID assignment.

5Send telegrams specification
12 Triton OMD CAN protocol / Rev.-No. 03
5.3 Network time synchronization command
Command: 49
Data bytes: 4
Destination: common designated message from master to all sensors.
Timeout: 600 s (for transmit attempt condition check)
Activation: automatic, if all the following conditions are fulfilled:
•Network ID distribution sequence is finished
•Timeout for transmit attempt has expired
•RTC Unix second counter has been changed (incremented).
Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7
High byte Low byte High byte Low byte High byte Low byte High byte Low byte
Data item Unix Time High Word Unix Time Low Word - - - -
Tab. 5.3 Command 49
Telegram function details are described in section 7.3 Network time synchronization.
5.4 Network time update command
Command: 50
Data bytes: 4
Destination: common designated message from master to all sensors.
Timeout: not periodical telegram
Activation: automatic, if all the following conditions are fulfilled:
•RTC settings have been changed by the user.
Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7
High byte Low byte High byte Low byte High byte Low byte High byte Low byte
Data item Unix Time High Word Unix Time Low Word - - - -
Tab. 5.4 Command 50
Telegram function details are described in section 7.3 Network time synchronization.