Sim0mq Manual
sim0mq-manual
sim0mq-manual
User Manual:
Open the PDF directly: View PDF 
.
Page Count: 41
| Download | |
| Open PDF In Browser | View PDF |
Sim0MQ Message Structure
Author:
Version:
Date:
Alexander Verbraeck, Sibel Eker, TU Delft
1.5
29 April 2017
Table of Changes:
Version Date
Author
1.0
04-03-2017 Verbraeck
1.1
16-03-2017 Eker
1.2
19-4-2017
Eker
1.3
1.4
20-4-2017 Verbraeck
21-04-2017 Eker
1.5
29-04-2017 Verbraeck
TU Delft | Sim0MQ Messages for OTS v1.5
Major changes
Initial version
Message descriptions, update to Figure 1 and addition of
Figure 2.
Changes in the StartFederate and FederateStarted
messages
REQ-ROUTER pattern in chapter 3 added and explained
Changes in the StartFederate and FederateStarted
messages related to the port number of model instances
Units and DisplayUnits adapted to the changes in
DJUNITS version 3.00.01.
Two bytes used for the Money type as 255 is too low,
and cannot store the standard currency id codes.
1
Table of Contents
1
Sim0MQ Basics ..................................................................................................................... 4
1.1 ØMQ Message Bus .................................................................................................................. 4
2
Message Structure ................................................................................................................ 5
2.1 Typed Sim0MQ Messages ....................................................................................................... 5
2.1.1
2.1.2
2.1.3
String types (#9 - #10) ................................................................................................. 7
Array types (#11 - #17) ................................................................................................ 7
Matrix types (#18 - #24) .............................................................................................. 8
2.2 Coding of units......................................................................................................................... 8
2.2.1
2.2.2
2.2.3
2.2.4
2.2.5
2.2.6
2.2.7
2.2.8
2.2.9
Float with unit (#25) .................................................................................................... 9
Double with unit (#26)................................................................................................. 9
Float array with unit (#27) ........................................................................................... 9
Double array with unit (#28) ..................................................................................... 10
Float matrix with unit (#29) ....................................................................................... 10
Double matrix with unit (#30) ................................................................................... 10
Float matrix with unique units per column (#31)...................................................... 11
Double matrix with unique units per column (#32) .................................................. 11
Money units per quantity (unit types #101 - #106) .................................................. 12
2.3 Sim0MQ Simulation Messages .............................................................................................. 13
2.3.1
2.3.2
2.3.3
2.3.4
2.3.5
2.3.6
3
Simulation run id ....................................................................................................... 14
Sender id .................................................................................................................... 14
Receiver id ................................................................................................................. 14
Message type id......................................................................................................... 14
Message status id ...................................................................................................... 14
Example ..................................................................................................................... 14
Sim0MQ Components ......................................................................................................... 16
3.1 Federate Starter .................................................................................................................... 16
3.2 Federation Manager .............................................................................................................. 16
4
Notes and possible extensions............................................................................................. 20
4.1 Notes ..................................................................................................................................... 27
4.2 Possible extensions ............................................................................................................... 27
Appendix A. Unit display type coding .......................................................................................... 28
0. Dimensionless .................................................................................................................... 28
1. Acceleration ....................................................................................................................... 28
2. AngleSolid .......................................................................................................................... 28
3. Angle .................................................................................................................................. 28
4. Direction............................................................................................................................. 28
5. Area .................................................................................................................................... 29
TU Delft | Sim0MQ Messages for OTS v1.5
2
6. Density ............................................................................................................................... 29
7. ElectricalCharge ................................................................................................................. 29
8. ElectricalCurrent ................................................................................................................ 30
9. ElectricalPotential .............................................................................................................. 30
10. ElectricalResistance.......................................................................................................... 30
11. Energy .............................................................................................................................. 30
12. FlowMass ......................................................................................................................... 31
13. FlowVolume ..................................................................................................................... 31
14. Force ................................................................................................................................ 32
15. Frequency......................................................................................................................... 32
16. Length .............................................................................................................................. 32
17. Position ............................................................................................................................ 33
18. LinearDensity ................................................................................................................... 33
19. Mass ................................................................................................................................. 34
20. Power ............................................................................................................................... 34
21. Pressure ........................................................................................................................... 35
22. Speed................................................................................................................................ 35
23. Temperature .................................................................................................................... 35
24. AbsoluteTemperature ...................................................................................................... 36
25. Duration ........................................................................................................................... 36
26. Time ................................................................................................................................. 36
27. Torque .............................................................................................................................. 36
28. Volume ............................................................................................................................. 37
100. Money ............................................................................................................................ 37
101. MoneyPerArea ............................................................................................................... 41
102. MoneyPerEnergy............................................................................................................ 41
103. MoneyPerLength............................................................................................................ 41
104. MoneyPerMass .............................................................................................................. 41
105. MoneyPerDuration ........................................................................................................ 41
106. MoneyPerVolume .......................................................................................................... 41
TU Delft | Sim0MQ Messages for OTS v1.5
3
1 Sim0MQ Basics
1.1 ØMQ Message Bus
Sim0MQ makes use of the ØMQ (or 0MQ or ZMQ) message bus, and contains a layer of simulationspecific components and messages to aid in creating distributed simulation execution.
TU Delft | Sim0MQ Basics v1.5
4
2 Message Structure
Several types of messages can be distinguished: internal messages to ØMQ, such as the heartbeat;
binary messages that have an internal structure that is described by external metadata, and
formatted or typed messages that have an internal structure including structure metadata to be able
to automatically parse the message. Finally, the actual messages could be generated by an external
protocol such as Google's Protocol Buffers (protobuf), which is analogous to the IDL (Interface
Description Language) in Corba and DDS (OMG's Data Distribution Service). We will focus here on the
typed messages that contain internal structure metadata as part of the message, making parsing of
the message easy.
Message structures can be characterized by the following aspects:
•
•
•
•
magic number, aka header frame (or no header frame). The message might have a header
frame at the start, identifying it is a Sim0MQ message to distinguish it from other messages
using the bus. Messages without the magic number might be discarded.
structure metadata. The message might have no structure metadata in the message (e.g.,
the first 4 bytes are a float in network byte order, followed by a 8-byte long in network byte
order), or have structure metadata (e.g., a byte that precedes every field and indicates the
type of field that follows. The advantage of structure metadata is that errors and
incompatibilities between versions can be easily spotted (I expected an integer in field 4, but
I got a String).
external metadata. There might be a file that describes the structure of a message type that
can be used to automatically parse the message. This could work both for messages with or
without structure metadata. External metadata adds names to the types of the structure
metadata (e.g., field 4 is the companyName, and it cannot be null or blank). Required fields
and optional fields can be distinguished in many IDLs (Interface Description Languages).
generative metadata. The file that describes the external metadata might be used for code
generation to create named data structures or classes that contain the same information as
the message type described by the external metadata.
2.1 Typed Sim0MQ Messages
Typed messages have a magic number, and contain structured metadata. Right now, no external
metadata or generative metadata exists. The idea of typed messages is that every field in the
message has a prefix that indicates the field type. Although this can be considered overhead, it
makes it easy to quickly create a data structure from the message without having to know the exact
naming of the fields.
A typed Sim0MQ message looks as follows:
•
•
Frame 0. Magic number = "SMQ##" where ## stands for the version number, e.g., 01. The
magic number is coded as a String, which means that the string type indicator and number of
characters are the prefix for the magic number. Therefore, every Sim0MQ message starts
with: |9|0|0|0|5|S|I|M|, followed by a 2-digit String version number, e.g.:
|9|0|0|0|5|S|I|M|0|1|.
Frame 1-n: Fields, where each field has a 1-byte prefix denoting the type of field. The
standard way of communicating is big-Endian, also known as network byte order. Little
endian can be supported as well, but will lead to additional translations in Java and Python
TU Delft | Message Structure v1.5
5
implementations. When multiple C or C++ components talk to each other, little endian
communication might be a good idea, though. Here, we will focus in big endian
implementations only. Every field is prefixed with a one-byte type code, e.g., 2 for a big
endian 32 bit signed two's complement integer. An int with the value 824 will therefore be
coded as: |2|0|0|3|56| using decimal notation.
The following big endian datatypes have been defined:
code
0
1
2
3
4
5
name
BYTE_8
SHORT_16
INT_32
LONG_64
FLOAT_32
DOUBLE_64
6
7
8
9
10
BOOLEAN_8
CHAR_8
CHAR_16
STRING_8
STRING_16
11
BYTE_8_ARRAY
12
SHORT_16_ARRAY
13
INT_32_ARRAY
14
LONG_64_ARRAY
15
FLOAT_32_ARRAY
16
DOUBLE_64_ARRAY
17
BOOLEAN_8_ARRAY
18
BYTE_8_MATRIX
19
SHORT_16_MATRIX
20
INT_32_MATRIX
21
LONG_64_MATRIX
22
FLOAT_32_MATRIX
23
DOUBLE_64_MATRIX
24
BOOLEAN_8_MATRIX
25
FLOAT_32_UNIT
26
DOUBLE_64_UNIT
TU Delft | Message Structure v1.5
description
Byte, 8 bit signed two's complement integer
Short, 16 bit signed two's complement integer, big endian order
Integer, 32 bit signed two's complement integer, big endian order
Long, 64 bit signed two's complement integer, big endian order
Float, single-precision 32-bit IEEE 754 floating point, big endian order
Float, double-precision 64-bit IEEE 754 floating point, big endian
order
Boolean, sent / received as a byte; 0 = false, 1 = true
Char, 8-bit ASCII character
Char, 16-bit Unicode character, big endian order
String, 32-bit number-preceded byte array of 8-bits characters
String, 32-bit number-preceded char array of 16-bits characters, bigendian order
Byte array, preceded by a 32-bit number indicating the number of
bytes, big-endian order
Short array, preceded by a 32-bit number indicating the number of
shorts, big-endian order
Integer array, preceded by a 32-bit number indicating the number of
integers, big-endian order
Long array, preceded by a 32-bit number indicating the number of
longs, big-endian order
Float array, preceded by a 32-bit number indicating the number of
floats, big-endian order
Double array, preceded by a 32-bit number indicating the number of
doubles, big-endian order
Boolean array, preceded by a 32-bit number indicating the number
of booleans, big-endian order
Byte matrix, preceded by a 32-bit number row count and a 32-bit
number column count, big-endian order
Short matrix, preceded by a 32-bit number row count and a 32-bit
number column count, big-endian order
Integer matrix, preceded by a 32-bit number row count and a 32-bit
number column count, big-endian order
Long matrix, preceded by a 32-bit number row count and a 32-bit
number column count, big-endian order
Float matrix, preceded by a 32-bit number row count and a 32-bit
number column count, big-endian order
Double matrix, preceded by a 32-bit number row count and a 32-bit
number column count, big-endian order
Boolean matrix, preceded by a 32-bit number row count and a 32-bit
number column count, big-endian order
Float stored internally as an SI unit, with unit type and display unit
attached. The total size of the field is 6 bytes. See below.
Double stored internally as an SI unit, with unit type and display unit
attached. The total size of the field is 10 bytes. See below.
6
code
27
name
FLOAT_32_UNIT_ARRAY
28
DOUBLE_64_UNIT_ARRAY
29
FLOAT_32_UNIT_MATRIX
30
DOUBLE_64_UNIT_MATRIX
31
FLOAT_32_UNIT2_MATRIX
32
DOUBLE_64_UNIT2_MATRIX
description
Dense float array, preceded by a 32-bit number indicating the
number of floats, big-endian order, with unit type and display unit
attached to the entire float array. See below.
Dense double array, preceded by a 32-bit number indicating the
number of doubles, big-endian order, with unit type and display unit
attached to the entire float array. See below.
Dense float matrix, preceded by a 32-bit number row count and a
32-bit number column count, big-endian order, with unit type and
display unit attached to the entire float matrix. See below.
Dense double matrix, preceded by a 32-bit number row count and a
32-bit number column count, big-endian order, with unit type and
display unit attached to the entire double matrix. See below.
Dense float matrix, preceded by a 32-bit number row count and a
32-bit number column count, big-endian order, with a unique unit
type and display unit per row of the float matrix. See below.
Dense double matrix, preceded by a 32-bit number row count and a
32-bit number column count, big-endian order, with a unique unit
type and display unit per row of the doublematrix. See below.
As an example, this means that a message coding {"Hello world",24,TRUE} where the number 24 is an
int, is coded as:
|9|0|0|0|5|S|I|M|0|1|9|0|0|0|11|H|e|l|l|o| |w|o|r|l|d|2|0|0|0|24|6|1|
2.1.1 String types (#9 - #10)
The string types are preceded by a 32-bit int indicating the number of characters in the array that
follows. This int is itself not preceded by a byte indicating it is an int. An ASCII string "Hello" is
therefore coded as follows:
|9|0|0|0|5|H|e|l|l|o|
in UTF-8 and as
|10|0|0|0|5|0x00|H|0x00|e|0x00|l|0x00|l|0x00|o|
in UTF-16.
Java uses UTF-16 internally, so Strings could be encoded in different ways, but the Sim0MQ message
header fields from section 2.3 all use UTF-8. Other strings in the message can be encoded using UTF16 or UTF-8, depending on the implementation of the message handler.
2.1.2 Array types (#11 - #17)
The array types are preceded by a 32-bit int indicating the number of values in the array that follows.
This int is itself not preceded by a byte indicating it is an int. An array of 8 shorts with numbers 100
through 107 is therefore coded as follows:
|12|0|0|0|8|0|100|0|101|0|102|0|103|0|104|0|105|0|106|0|107|
TU Delft | Message Structure v1.5
7
2.1.3 Matrix types (#18 - #24)
The matrix types are preceded by a 32-bit int indicating the number of rows, followed by a 32-bit int
indicating the number of columns. These integers are not preceded by a byte indicating it is an int.
The number of values in the matrix that follows is rows * columns. The data is stored row by row,
without a separator between the rows. A matrix with 2 rows and 3 columns of integers 1-2-4 6-7-8 is
therefore coded as follows:
|20|0|0|0|2|0|0|0|3|0|0|0|1|0|0|0|2|0|0|0|4|0|0|0|6|0|0|0|7|0|0|0|8|
2.2 Coding of units
Units are coded with one byte indicating the unit type, and one byte indicating the display type of the
unit. The SI unit or standard unit always has display type 0. Appendix A lists the display types for
each unit type. The unit types as defined currently are:
code
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
100
101
102
103
104
105
106
unit name
Dimensionless
Acceleration
AngleSolid
Angle
Direction
Area
Density
ElectricalCharge
ElectricalCurrent
ElectricalPotential
ElectricalResistance
Energy
FlowMass
FlowVolume
Force
Frequency
Length
Position
LinearDensity
Mass
Power
Pressure
Speed
Temperature
AbsoluteTemperature
Duration
Time
Torque
Volume
Money
MoneyPerArea
MoneyPerEnergy
MoneyPerLength
MoneyPerMass
MoneyPerDuration
MoneyPerVolume
unit description
Unit without a dimension
Acceleration
Solid angle
Angle (relative)
Angle (absolute)
Area
Density based on mass and length
Electrical charge (Coulomb)
Electrical current (Ampere)
Electrical potential (Volt)
Electrical resistance (Ohm)
Energy (Joule)
Mass flow rate
Volume flow rate
Force (Newton)
Frequency (Hz)
Length (relative)
Length (absolute)
Linear density
Mass
Power (Watt)
Pressure (Pascal)
Speed
Temperature (relative)
Temperature (absolute)
Time (relative)
Time (absolute)
Torque (Newton-meter)
Volume
Money (cost in e.g., $, €, ...)
Money/Area (cost/m^2)
Money/Energy (cost/W)
Money/Length (cost/m)
Money/Mass (cost/kg)
Money/Duration (cost/s)
Money/Volume (cost/m^3)
TU Delft | Message Structure v1.5
default (SI) unit
[]
[m/s^2]
[steradian]
[rad]
[rad]
[m^2]
[kg/m^3]
[sA]
[A]
[kgm^2/s^3A]
[kgm^2/s^3A^2]
[kgm^2/s^2]
[kg/s]
[m^3/s]
[kgm/s^2]
[1/s]
[m]
[m]
[1/m]
[kg]
[kgm^2/s^3]
[kg/ms^2]
[m/s]
[K]
[K]
[s]
[s]
[kgm^2/s^2]
[m^3]
[$]
[$/m^2]
[$s^3/kgm^2]
[$/m]
[$/kg]
[$/s]
[$/m^3]
8
Some of the unity types have a relative and an absolute variant. Relative scalars can be added to or
subtracted from relative and absolute scalars; absolute scalars cannot be added, but can be
subtracted, resulting in a relative scalar. As an example, one cannot add two times (3-1-2017, 5
o'clock + 3-1-2017, 3 o'clock = ??), but these values can be subtracted (3-1-2017, 5 o'clock – 3-12017, 3 o'clock = 2 hours). Absolute plus relative yields e.g., 3-1-2017, 17:00 + 2 hours = 3-1-2017,
19:00. Relative values can of course be added/subtracted: 2 hours + 30 minutes = 2.5 hours. See
http://djunits.org for more information.
2.2.1 Float with unit (#25)
The internal storage of the value that is transmitted is always in the SI (or standard) unit, except for
money where the display unit is used. The value is preceded by a one-byte unit type (see the table
above) and a one-byte (or two-byte in case of Money or three-byte in case of the MoneyPerUnit)
display type (see Appendix A). As an example: suppose the unit indicates that the type is a length,
whereas the display type indicates that the internally stored value 60000.0 should be displayed as
60.0 km, this is coded as follows:
|25|16|11|0x47|0x6A|0x60|0x00|
2.2.2 Double with unit (#26)
The internal storage of the value that is transmitted is always in the SI (or standard) unit, except for
money where the display unit is used. The value is preceded by a one-byte unit type (see the table
above) and a one-byte (or two-byte in case of Money or three-byte in case of the MoneyPerUnit)
display type (see Appendix A). As an example: suppose the unit indicates that the type is a length,
whereas the display type indicates that the internally stored value 60000.0 should be displayed as
60.0 km, this is coded as follows:
|26|16|11|0x47|0x6A|0x60|0x00|0x00|0x00|0x00|0x00|
2.2.3 Float array with unit (#27)
After the byte with value 27, the array types have a 32-bit int indicating the number of values in the
array that follows. This int is itself not preceded by a byte indicating it is an int. Then a one-byte unit
type follows (see the table above) and a one-byte (or two-byte in case of Money or three-byte in case
of the MoneyPerUnit) display type (see Appendix A). The internal storage of the values that are
transmitted after that always use the SI (or standard) unit, except for money where the display unit is
used. As an example: when we send an array of two durations, 2.0 minutes and 2.5 minutes, this is
coded as follows:
|27|0|0|0|2|25|7|0x40|0x00|0x00|0x00|0x40|0x20|0x00|0x00|
TU Delft | Message Structure v1.5
9
2.2.4 Double array with unit (#28)
After the byte with value 28, the array types have a 32-bit int indicating the number of values in the
array that follows. This int is itself not preceded by a byte indicating it is an int. Then a one-byte unit
type follows (see the table above) and a one-byte (or two-byte in case of Money or three-byte in case
of the MoneyPerUnit) display type (see Appendix A). The internal storage of the values that are
transmitted after that always use the SI (or standard) unit, except for money where the display unit is
used. As an example: when we send an array of two durations, 21.2 minutes and 21.5 minutes, this is
coded as follows:
|28|0|0|0|2|25|7|0x40|0x35|0x33|0x33|0x3|0x33|0x33|0x33|
|0x40|0x35|0x80|0x00|0x00|0x00|0x00|0x00|
2.2.5 Float matrix with unit (#29)
After the byte with value 29, the matrix types have a 32-bit int indicating the number of rows in the
array that follows, followed by a 32-bit int indicating the number of columns. These integers are not
preceded by a byte indicating it is an int. Then a one-byte unit type follows (see the table above) and
a one-byte (or two-byte in case of Money or three-byte in case of the MoneyPerUnit) display type
(see Appendix A). The internal storage of the values that are transmitted after that always use the SI
(or standard) unit, except for money where the display unit is used. Summarized, the coding is as
follows:
|29| |R|O|W|S| |C|O|L|S| |UT| |DT|
|R|1|C|1| |R|1|C|2| ... |R|1|C|n|
|R|2|C|1| |R|2|C|2| ... |R|2|C|n|
...
|R|m|C|1| |R|m|C|2| ... |R|m|C|n|
In the language sending or receiving a matrix, the rows are denoted by the outer index, and the
columns by the inner index: matrix[row][col].
2.2.6 Double matrix with unit (#30)
After the byte with value 30, the matrix types have a 32-bit int indicating the number of rows in the
array that follows, followed by a 32-bit int indicating the number of columns. These integers are not
preceded by a byte indicating it is an int. Then a one-byte unit type follows (see the table above) and
a one-byte (or two-byte in case of Money or three-byte in case of the MoneyPerUnit) display type
(see Appendix A). The internal storage of the values that are transmitted after that always use the SI
(or standard) unit, except for money where the display unit is used. Summarized, the coding is as
follows:
|30| |R|O|W|S| |C|O|L|S| |UT| |DT|
|R|1|C|1|.|.|.|.| |R|1|C|2|.|.|.|.| ... |R|1|C|n|.|.|.|.|
|R|2|C|1|.|.|.|.| |R|2|C|2|.|.|.|.| ... |R|2|C|n|.|.|.|.|
...
|R|m|C|1|.|.|.|.| |R|m|C|2|.|.|.|.| ... |R|m|C|n|.|.|.|.|
In the language sending or receiving a matrix, the rows are denoted by the outer index, and the
columns by the inner index: matrix[row][col].
TU Delft | Message Structure v1.5
10
2.2.7 Float matrix with unique units per column (#31)
After the byte with value 31, the matrix types have a 32-bit int indicating the number of rows in the
array that follows, followed by a 32-bit int indicating the number of columns. These integers are not
preceded by a byte indicating it is an int. Then a one-byte unit type for column 1 follows (see the
table above) and a one-byte (or two-byte in case of Money or three-byte in case of the
MoneyPerUnit) display type for column 1 (see Appendix A). Then the unit type and display type for
column 2, etc. The internal storage of the values that are transmitted after that always use the SI (or
standard) unit, except for money where the display unit is used. Summarized, the coding is as
follows:
|31| |R|O|W|S| |C|O|L|S|
|UT1|DT1| |UT2|DT2| ... |UTn|DTn|
|R|1|C|1| |R|1|C|2| ... |R|1|C|n|
|R|2|C|1| |R|2|C|2| ... |R|2|C|n|
...
|R|m|C|1| |R|m|C|2| ... |R|m|C|n|
In the language sending or receiving a matrix, the rows are denoted by the outer index, and the
columns by the inner index: matrix[row][col].
This data type is ideal for, for instance, sending a time series of values, where column1 indicates the
time, and column 2 the value. Suppose that we have a time series of 4 values at t = {1, 2, 3, 4} hours
and dimensionless values v = {20.0, 40.0, 50.0, 60.0}, then the coding is as follows:
|31| |0|0|0|4| |0|0|0|2|
|26|8| |0|0|
|0x3F|0x80|0x00|0x00| |0x41|0xA0|0x00|0x00|
|0x40|0x00|0x00|0x00| |0x42|0x20|0x00|0x00|
|0x40|0x00|0x40|0x00| |0x42|0x48|0x00|0x00|
|0x40|0x80|0x00|0x00| |0x42|0x70|0x00|0x00|
2.2.8 Double matrix with unique units per column (#32)
After the byte with value 32, the matrix types have a 32-bit int indicating the number of rows in the
array that follows, followed by a 32-bit int indicating the number of columns. These integers are not
preceded by a byte indicating it is an int. Then a one-byte unit type for column 1 follows (see the
table above) and a one-byte (or two-byte in case of Money or three-byte in case of the
MoneyPerUnit) display type for column 1 (see Appendix A). Then the unit type and display type for
column 2, etc. The internal storage of the values that are transmitted after that always use the SI (or
standard) unit, except for money where the display unit is used. Summarized, the coding is as
follows:
|32| |R|O|W|S| |C|O|L|S|
|UT1|DT1| |UT2|DT2| ... |UTn|DTn|
|R|1|C|1|.|.|.|.| |R|1|C|2|.|.|.|.| ... |R|1|C|n|.|.|.|.|
|R|2|C|1|.|.|.|.| |R|2|C|2|.|.|.|.| ... |R|2|C|n|.|.|.|.|
...
|R|m|C|1|.|.|.|.| |R|m|C|2|.|.|.|.| ... |R|m|C|n|.|.|.|.|
TU Delft | Message Structure v1.5
11
In the language sending or receiving a matrix, the rows are denoted by the outer index, and the
columns by the inner index: matrix[row][col].
This data type is ideal for, for instance, sending a time series of values, where column1 indicates the
time, and column 2 the value. Suppose that we have a time series of 4 values at dimensionless years
{2010, 2011, 2012, 2013} and costs of dollars per acre (#0x348) of {415.7, 423.4, 428.0, 435.1}, then
the coding is as follows:
|32| |0|0|0|4| |0|0|0|2|
|0|0| |101|0x03|0x48|18|
|0x40|0x9F|0x68|0x00|0x00|0x00|0x00|0x00|
|0x40|0x79|0xFB|0x33|0x33|0x33|0x33|0x33|
|0x40|0x9F|0x6C|0x00|0x00|0x00|0x00|0x00|
|0x40|0x7A|0x76|0x66|0x66|0x66|0x66|0x66|
|0x40|0x9F|0x70|0x00|0x00|0x00|0x00|0x00|
|0x40|0x7A|0xC0|0x00|0x00|0x00|0x00|0x00|
|0x40|0x9F|0x74|0x00|0x00|0x00|0x00|0x00|
|0x40|0x7A|0x91|0x99|0x99|0x99|0x99|0x9A|
2.2.9 Money units (#100) and Money units per quantity (unit types #101 - #106)
For MoneyPerUnit quantities such as MoneyPerArea, we need to send three bytes to indicate the
display unit: two for the Money, and one for the other unit. For Money per area, this means we first
send a Money constant followed by an Area constant. As an example, if we want to send the price of
land as € 2500 per hectare, transmitted as a double, this would be coded as:
|26|101|0x03|0xD2|21|0x40|0xA3|0x88|0x00|0x00|0x00|0x00|0x00|
A double array of 200 cost elements in dollars (code 840 = 0x348) would be coded as:
|28|0|0|0|200|100|0x03|0x48|...[200x8 bytes]...|
whereas a double array of 200 elements with dollars per liter would be coded as:
|28|0|0|0|200|106|0x03|0x48|17|...[200x8 bytes]...|
as the Euro has code 978 = 0x3D2.
TU Delft | Message Structure v1.5
12
2.3 Sim0MQ Simulation Messages
In many cases, we want to distinguish between a definition of something, a subsequent change, and
the deletion or termination of something. As an example, a generated entity can report its initial
status, update state changes, and indicate when it leaves the simulation.
Furthermore, it is considered to be useful to know the message type, to avoid mistakes for parsing
the wrong message. Although it adds a bit to the message overhead, the benefits of not parsing and
interpreting a wrong message are clearly outweighing the transmission of a few bytes. In cases
where many short messages of a certain type are sent, untyped messages could be preferred over
typed simulation messages.
Finally, when multiple simulations are running in parallel, it is important to know for which running
simulation the message is intended. In case it gets delivered to the wrong simulation, it can be
discarded and potentially, the mistake can be logged.
The message structure of a typical typed Sim0MQ simulation message looks as follows:
Frame 0. Magic number = |9|0|0|0|5|S|I|M|#|#| where ## stands for the version number, e.g.,
01. The magic number is always coded as a UTF-8 String, so it always starts with a byte equal to 9.
Frame 1. Simulation run id. Simulation run ids can be provided in different types. Examples are two
64-bit longs indicating a UUID, or a String with a UUID number, a String with meaningful
identification, or a short or an int with a simulation run number. In order to check whether the right
information has been received, the id can be translated to a String and compared with an internal
string representation of the required simulation run id. The run id can be coded as UTF-8 or UTF-16.
Frame 2. Sender id. Sender ids can be provided in different types. Examples are two 64-bit longs
indicating a UUID, or a String with a UUID number, a String with meaningful identification, or a short
or an int with a sender id number. The sender id can be used to send back a message to the sender at
some later time. The sender id can be coded as UTF-8 or UTF-16.
Frame 3. Receiver id. Receiver ids can be provided in different types. Examples are two 64-bit longs
indicating a UUID, or a String with a UUID number, a String with meaningful identification, or a short
or an int with a receiver id number. The receiver id can be used to check whether the message is
meant for us, or should be discarded (or an error can be sent if we receive a message not meant for
us). The receiver id can be coded as UTF-8 or UTF-16.
Frame 4. Message type id. Message type ids can be defined per type of simulation, and can be
provided in different types. Examples are a String with a meaningful identification, or a short or an int
with a message type number. For interoperability between different types of simulation, a String id
with dot-notation (e.g., DSOL.1 for a simulator start message from DSOL or OTS.14 for a statistics
message from OpenTrafficSim) would be preferred. The message type id can be coded as UTF-8 or
UTF-16.
Frame 5. Unique message number. The unique message number will be sent as a long (64 bits), and
is meant to confirm with a callback that the message has been received correctly. The number is
unique for the sender, so not globally within the federation.
TU Delft | Message Structure v1.5
13
Frame 6. Message status id. Messages can be about something new (containing a definition that can
be quite long), an update (which is often just an id followed by a single number), and a deletion
(which is often just an id). The message status is is coded as a byte.
Frame 7. Number of fields. The number of fields in the payload is indicated to be able to check the
payload and to avoid reading past the end. The number of fields can be encoded using byte, short, or
int. A 32-bit int is the standard encoding.
Frame 8-n. Payload, where each field has a 1-byte prefix denoting the type of field.
2.3.1 Simulation run id
An example is to standardize on a String with meaningful information for the run id. The string
contains a run prefix, with experiment number and replication number separated by dot-notation.
This could be IDVV.14.2, indicating we run a simulation called 'IDVV', where the message is for
scenario (experiment) 14, replication 2. Clients would know whether they would be part of
experiment 14, replication 2, or not. A simple String comparison would yield whether they received a
message that is meant for the particular simulation.
2.3.2 Sender id
An example is to standardize on a String with meaningful information for the sender id. The string
contains a prefix identifying the type of component, e.g., "MM1" for an MM1 simulation model. A
number after that will indicate a unique number of the instance of the running model or component,
e.g. "MM1.4". When this model sends a message to the model controller, it will use "MM1.4" for this
field as a sender.
2.3.3 Receiver id
An example is to standardize on a String with meaningful information for the receiver id. The string
contains a prefix identifying the type of component, e.g., "MC" for the model controller. A number
after that will indicate a unique number of the instance of the running model or component, e.g.
"MC.1". When this model controller receives a message, it will test for this field as being "MC.1". We
could allow wildcards, where all model controllers would be informed with a message, using "MC.*"
to indicate that any model controller could receive this message, or even more extreme, "*" to
indicate any component could receive this message.
2.3.4 Message type id
Analogous with the simulation run is, the message type id contains a String id with dot-notation. The
first part of the message is the project the message belongs to (e.g., DSOL for the DSOL simulation
package, or OTS for OpenTrafficSim), followed by a message type number that is maintained within
that project (e.g., DSOL.1 for a simulator start message from DSOL or OTS.14 for a statistics message
from OpenTrafficSim).
2.3.5 Message status id
Three different status messages are defined: 1 for new, 2 for change, and 3 for delete. These
messages are coded as a byte.
2.3.6 Example
Suppose we have a simulation called IDVV.14.2 in which a message to change the (double) simulation
speed to the value 0.2 is sent, of which the message type is DSOL.3. The message is sent by "MC.1"
TU Delft | Message Structure v1.5
14
and received by "MM1.4". Suppose the message number is 124. Then the message looks as follows
(note that the double representation of 0.2 is 0x3FC999999999999A):
|9|0|0|0|5|S|I|M|0|1|9|0|0|0|9|I|D|V|V|.|1|4|.|2|
|9|0|0|0|4|M|C|.|1|9|0|0|0|5|M|M|1|.|4|9|0|0|0|6|D|S|O|L|.|3|
|3|0|0|0|0|0|0|0|124|0|2|1|0|1|
|5|0x3F|0xC9|0x99|0x99|0x99|0x99|0x99|0x9A|
TU Delft | Message Structure v1.5
15
3 Sim0MQ Components
Several components have been created to help in easy setting up of simulations that use the
Sim0MQ message bus. Examples are a Federation Manager (aka Model Controller) and a Federate
Starter. A Federate Starter is a lightweight executable to start a federate on a local node as a
(sub)process. The Federate Starter listens to external messages, e.g. from a Federation Manager. The
Federation Manager sends messages to Federate Starters to start model components, loggers, data
collectors, etc. It can start a federation as soon as all required model components are on-line. It
might kill model components that take too long to finish.
3.1 Federate Starter
A Federate Starter is a small program or daemon that listens on a certain port and that can start
federates such as models, loggers, data providers and other federation components on a local
machine. A Federation Manager (e.g., a model controller or a workbench) sends a FederateStart
message to the Federate Starter, which starts the federate and provides it with enough information
so it can report back to the federate starter that the start has succeeded. After that, the Federate
Starter reports back to the Federation Manager that the federate is on-line with a FederateStarted
message. After that, the Federate Starter resumes listening on the port for new messages to start a
federate. See Figure 1 for more details.
Starting a program as a subprocess is sometimes done by forking. The disadvantage of forking is that
the newly started program 'inherits' the state of the federate starter. In this case, we want to start a
program fresh, that is independent of the parent process. In other words, if the parent process (the
Federate Starter) dies, the federates and models that have been started by it should keep working. In
Java 1.7 or higher, this can be achieved by a ProcessBuilder class that takes care of setting the
working directory, setting the environment variables, redirecting the standard i/o (stdin, stdout,
stderr) of the program to be started, and starts the program. It only takes a few lines of coding.
One of the important things to take into account is that all arguments to the program need to be split
as separate arguments, so "java -jar test.jar" should be split into 3 arguments. Another point of
attention is the redirection of input and output. When it is not redirected, it might stay in a buffer
within the program that consumes memory until it is full or until memory runs out. Therefore,
adequate handling of stdout and stderr is needed.
3.2 Federation Manager
The Federation Manager is responsible for the management of the execution of one or more models.
It asks the Federate Starter to start models on its behalf on other servers (or could do so itself if all
models run on the same computer). An extensive set of messages has been devised to communicate
with one or more Federate Starters on multiple computers to start models, and to communicate with
the models to set the parameters and experimental conditions, and to gather the statistics
afterward. Multiple Federation Managers can work in parallel and communicate with their own set
of models. Figure 1 shows the basic communication pattern, and Figure 2 shows a simple
implementation of the connections between the models.
TU Delft | Sim0MQ Components v1.5
16
Model
Federate
Manager
Federate
Starter
FM.1 StartFederate
Initiate the model (with the port number)
Status can be e.g.,
“started”, “running”,
“ended”, “error”
loop
FS.1 RequestStatus
MC.1 Status
FS.2 FederateStarted
loop
FM.2 SimRunControl
MC.2 AckNak
loop
FM.3 SetParameter
optional
MC.2 AckNak
FM.4 SimStart
MC.2 AckNak
loop
Status can be e.g.,
“started”, “running”,
“ended”, “error”
FM.5 RequestStatus
MC.1 Status
loop
FM.6 RequestStatistics
MC.3 Statistics
MC.4 StatisticsError
loop
FM.7 SimReset
optional
MC.2 AckNak
FM.8 KillFederate
FS.3 KillModel
FS.4 FederateKilled
Figure 1. Federate Starter and Model Run control flow
TU Delft | Sim0MQ Components v1.5
17
Port : xxxx
Federate Starter
Server - REP
Federate Starter
Client - REQ
Federate Manager
(EMA WB)
Client - REQ
Model
Port : yyyy
Server - REP
Figure 2: ZeroMQ Simple REQ-REP Messaging Pattern between Federation Manager, Model and Federate Starter
3.3 REQ-ROUTER pattern
In Figure 2, it is shown that both the Federation Manager and the Federate Starter communicate
with the Model. This cannot be done with a REQ-REP framework, as REQ-REP is a 1:1 connection.
Instead, the model can implement a ROUTER socket, which allows multiple connections. The ROUTER
socket is a bit more complicated, however. The following changes have to be implemented in the
model:
•
•
•
Each client should have a unique identity. This is done with the socket.setIdentity(String
identity) method in the Federation Manager and the Federate Starter, right after the socket
has been created, and before binding to a port. In the reference implementation, a unique
UUID is generated for each identity.
The model should use the identity to talk back to the clients, so it will use the right channel.
The model is a bit more complicated in terms of communication, as it explicitly receives the
identity and the envelope separator (the REP receives these fields as well, but strips the
identity and separator from the message so the Model does not have to act on it).
The communication takes place as follows:
Model (ROUTER)
socket(ZMQ.ROUTER)
recv(identity)
recv(delimiter)
recv(message)
[process the data]
sendMore(identity)
sendMore(delimiter)
send(reply_message)
FS/FM Client (REQ)
socket(ZMQ.REQ)
setIdentity(String uniqueId)
<----- sendMessage
-----> recv
TU Delft | Sim0MQ Components v1.5
18
The connections with the REQ-ROUTER pattern are given in Figure 3.
Port : xxxx
Federate Starter
ROUTER
Federate Starter
Client - REQ
Federation Manager
(e.g., EMA WB)
Client - REQ
Port : yyy1
Model
ROUTER
Federation Manager
(e.g., EMA WB)
Client - REQ
Federation Manager
(e.g., EMA WB)
Port : yyy2
Model
ROUTER
Port : yyy3
Client - REQ
Model
ROUTER
Figure 3. ZeroMQ REQ-ROUTER Messaging Pattern between Federation Manager, Model and Federate Starter
TU Delft | Sim0MQ Components v1.5
19
4 Messages
4.1 StartFederate (message type id = FM.1)
NEW
Variable
instanceId
#
8
Type
String(9)
softwareCode
9
String(9)
argsBefore
10
String(9)
modelPath
11
String(9)
argsAfter
12
String(9)
workingDirectory
13
String(9)
redirectStdin
14
String(9)
redirectStdout
15
String(9)
redirectStderr
16
String(9)
TU Delft | Messages v1.5
Comments
Id to identify the callback to know which model instance
has been started, e.g. "IDVV.14". The model instance
will use this as its sender id. The string cannot be empty.
Code for the software to run, will be looked up in a table
on the local computer to determine the path to start the
software on that computer. Example: "java". The string
cannot be empty.
Arguments that the software needs, before the model
file path and name; e.g. "–Xmx2G -jar" in case of a Java
model. This String can be empty (0 characters).
The actual path on the target computer where the
model resides, including the model that needs to be
run. This String cannot be empty.
Arguments that the software or the model needs, after
the model file path and name; e.g. arguments for the
model itself to run like a data file or a data location .
This String can be empty (0 characters), but usually we
would want to send the port number(s) or a location
where the model can find it as well as the name under
which the model was registered. If the port number
needs to be inserted in the args, use %p for the port
number.
Full path on the target computer that will be used as the
working directory. Some files may be temporarily stored
there. If the working directory does not exist yet, it will
be created. The string cannot be empty.
Place to get user input from in case a model asks for it
(it shouldn't, by the way). The string can be empty (0
characters).
Place to send the output to that the model normally
displays on the console. If this is not redirected, the
memory buffer for the stdout might get full, and the
model might stop as a result. On Linux systems, this
often redirected to /dev/null. On Windows systems, this
can e.g., be redirected to a file "out.txt" in the current
working directory. For now, it has to be a path name
(including /dev/null as being acceptable). If no full path
is given, the filename is relative to the working
directory. The string cannot be empty.
Place to send the error messages to that the model
normally displays on the console. If this is not
redirected, the memory buffer for the stderr might get
full, and the model might stop as a result. On Linux
systems, this often redirected to /dev/null. On Windows
systems, this can e.g., be redirected to a file "err.txt" in
the current working directory. For now, it has to be a
path name (including /dev/null as being acceptable). If
no full path is given, the filename is relative to the
working directory. The string cannot be empty.
20
deleteWorkingDirectory
17
Boolean(6)
deleteStdout
18
Boolean(6)
deleteStderr
19
Boolean(6)
Whether to delete the working directory after the run of
the model or not.
Whether to delete the redirected stdout after running
or not (in case it is stored in a different place than the
working directory)
Whether to delete the redirected stderr after running or
not (in case it is stored in a different place than the
working directory)
CHANGE
Not sent
DELETE
Not sent
A number of standard types of software to look up and their respective codes are:
•
•
•
•
•
•
java for the latest Java version
java7, java8, java7+, etc. for a specific version of Java
python for the latest python version
python2, python3, python2+, etc. for a specific version of Python
if necessary, special Strings could be created for 32-bit and 64-bit versions of the software.
Preferably, "x64" is added at the end of the String to denote a 64-bit version
if a specific version is needed of software, either extra entries can be created, or the actual
path on the computer can be specified instead of the type code.
4.1.1 Federate Starter’s instantiation of a model:
When it receives a StartFederate message, the Federate starter creates a process to run the model
with the specifications given in the message, such as the working directory, model file, output and
error files etc. Creating a model instance in this way also requires a port number, to which the model
instance should bind as a ROUTER. This port number is assigned by the Federate Starter. Federate
Starter picks an available port from a range of ports on the machine it is running (which must be
open to outside connection) and gives this to the model as an argument. If the binding is not
successful, the Federate Starter creates generates a new port number.
4.2 RequestStatus (message type id = FS.1)
(The id can be different, because the very same message is sent by the Federation Manager, too.)
This message is sent by the Federate Starter to the Model until a “started” response is received from
the Model. Since the message type id clarifies the function of this message and no information
exchange is necessary, the payload field can be empty (number of fields = 0).
Message status id : NEW
Variable
Type
Comments
4.3 Status (message type id = MC.1)
The Model sends this message as a response to RequestStatus messages sent by the Federate Starter
or the Federation Manager.
TU Delft | Messages v1.5
21
NEW
Variable
uniqueId
Type
Long(3)
status
String(9)
error
String(9)
Comments
The unique message id (Frame 5) of the sender for
which this is the reply.
A string that refers to the model status. Four options:
“started”, “running”, “ended”, “error”.
Optional. If there is an error, the error message is sent
as well. Otherwise this field is an empty string.
4.4 FederateStarted (message type id = FS.2)
Message sent by the Federate Starter to the Federation Manager in response to message FM.1.
NEW
Variable
instanceId
Type
String(9)
status
String(9)
modelPortNumber
short(1)
error
String(9)
Comments
The sender id of the model that was started or had an
error while starting. This is exactly the same as the
instanceId sent by the Federation Manager in the Start
Federate message.
A string that refers to the model status. Four options:
“started”, “running”, “ended”, “error”.
Port number of the model, so the FederateManager can
connect to the model on this port for further simulation
messages.
Optional. If there is an error, the error message is sent
as well. Otherwise this field is an empty string.
4.5 SimRunControl (message type id = FM.2)
Message sent by the Federation Manager to the Model to initiate a simulation.
NEW
Variable
runTime
speed
Type
Any numeric type
(1-5) or Float or
Double with Unit
(25, 26) of type
Duration (25)
Any numeric type
(1-5) or Float or
Double with Unit
(25, 26) of type
Duration (25)
Any numeric type
(1-5) or Float or
Double with Unit
(25, 26) of type
Time (26)
Double(5)
noReplications
Integer(2)
noRandomStreams
streamId.1
Integer(2)
basic type
(1,2,3,9)
warmupTime
offsetTime
TU Delft | Messages v1.5
Comments
Duration of the run of a single replication, including the
warmup time, if present.
Warmup time of the model in time units that the model
uses.
Offset of the time (e.g., a model time of 0 is the year
2016, or 1-1-2015).
Speed as the number of times real-time the model
should run; Double.INFINITY means as fast as possible.
Number of replications for stochastic uncertainties in
the model.
Number of random streams that follow
Identifier of random stream 1
22
seed.1
...
streamId.n
seed.n
Long(3)
Seed for random stream 1
basic type
(1,2,3,9)
Long(3)
Identifier of random stream n
Seed for random stream n
4.6 AckNak (message type id = MC.2)
Message sent by the Model to acknowledge the reception and implementation of a message sent by
the Federation Manager.
This type of message is sent in response to many messages of the FM. That could create confusion if
there were multiple model instances, and one sending an acknowledgement e.g.for SimRunControl,
the other for SetParameter. However, since a different port number will be assigned to each model
and these acknowledgment messages will be sent only after a command, and include the uniqueId of
the request, such a confusion is not expected.
NEW
Variable
uniqueId
Type
Long(3)
status
Boolean(6)
error
String(9)
Comments
The unique message id (Frame 5) of the sender for
which this is the reply.
A boolean that indicates whether the command sent by
the FM has been successfully implemented, e.g.
whether the run control parameters are set successfully.
If ‘status’ is False, an error message that indicates which
parameter could not be set and why. Otherwise, an
empty string.
4.7 SetParameter (message type id = FM.3)
Message sent by the FederateManager to the Model for setting the parameter values. Parameters
are set one by one (but can be a Vector or Matrix).
NEW
Variable
parameterName
parameterValue
Type
String(9)
any type (0-32)
Comments
Name of the parameter as it is in the model.
Value of the parameter assigned for a specific
simulation. The type depends on the parameter. It
1
could, e.g., be long or double.
4.8 SimStart (message type id = FM.4)
Message sent by the Federation Manager to start the simulation.
NEW
Variable
Type
Comments
1
The EMA workbench knows beforehand the type of these parameters, samples accordingly and sends the
sampled values. However, since all integer types are ‘long’ by default and all floats are ‘double’, they will be
sent in that format. Message decoding and encoding handles this type specification.
TU Delft | Messages v1.5
23
4.9 RequestStatus (message type id = FM.5)
Message sent by the Federation Manager to enquire the status of the simulation. The answer to this
message is MC.1 "Status" (discussed above).
Since the message type id clarifies the function of this message and no information exchange is
necessary, the payload field can be empty.
NEW
Variable
Type
Comments
4.10 RequestStatistics (message type id = FM.6)
Message sent by the Federation Manager to collect the output.
NEW
Variable
variableName
Type
String(9)
Comments
The name of the output variable whose value is
requested. That should match with the name in the
model. For a tallied variable, several statistics are
possible, e.g., average, variance, minimum, maximum,
time series, etc. The name should clearly indicate what
the Model Controller expects and what the model
should produce.
4.11 Statistics (message type id = MC.3)
Message sent by the Model to give the model output, if there is output generated for the specified
variable.
NEW
Variable
variableName
variableValue
Type
String(9)
Any type (0-32)
Comments
The name of the output variable whose value is
requested. That should match with the name in the
model.
If variableType is scalar, the data type is e.g., an integer,
float etc. and the value generated in the model.
If variableType is timeseries, the data type is an ‘array’
(type 11-16 or 27/28) or a time series (type 31/32).
4.12 StatisticsError (message type id = MC.4)
Message sent by the Model to indicate that there is an error with the output. MC.3 and MC.4 are
alternative to each other.
NEW
Variable
variableName
error
TU Delft | Messages v1.5
Type
String(9)
String(9)
Comments
The name of the output variable whose value is
requested. That should match with the name in the
model.
Three types of error can occur:
- If the variableName does not exist in the model,
error = “name”
- If the simulation did not generate a value for this
variable, e.g. NaN or division by zerro,
error= “novalue”
24
4.13 SimReset (message type id = FM.7)
CHANGE
Variable
Type
Comments
4.14 KillFederate (message type id = FM.8)
Since the items to be deleted were specified in the StartFederate message, no input is required. The
payload can be an empty string.
NEW
Variable
instanceId
Type
String(9)
Comments
Id to identify the model instance that has to be killed,
e.g. "IDVV.14".
4.15 KillAll (message type id = FM.9)
The message sent by the Federation Manager to the Federate Starter to kill all running model
instances. There is no payload.
NEW
Variable
Type
Comments
4.16 KillModel (message type id = FS.3)
The message is sent by the federate starter to a model instance.
NEW
Variable
Type
Comments
4.17 FederateKilled (message type id = FS.4)
NEW
Variable
instanceId
Type
String(9)
status
Boolean(6)
error
String(9)
Comments
Id to identify the model instance that was killed, e.g.
"IDVV.14".
A boolean that indicates whether the federate has been
successfully terminated.
If ‘status’ is False, an error message that specifies the
problem. Otherwise, an empty string.
4.18 FederatesKilled (message type id = FS.5)
NEW
Variable
status
error
TU Delft | Messages v1.5
Type
Boolean(6)
String(9)
Comments
A boolean that indicates whether all federates has been
successfully terminated.
If ‘status’ is False, an error message that specifies the
problem. Otherwise, an empty string.
25
5 Example: MM1-model with EMA workbench
Magic number is SIM01.
Federation Manager uses id EMA.
Federate Starter id is FS, listens on port 5555.
FM.1, StartFederate: java-jar mm1.jar MM1.1 5556
MM1 listens on port 5556, I/O gets redirected to out.txt, err.txt, and will be deleted.
Model id will be MM1.# where # indicates the instance number.
Each model instance has its own port number.
FM.2 RunControl: run time: 100(double), warmup time 0(double), speed infinite(double), start time
0(double), no of replications 1(integer), 1 seed for the model, name "default", to be set by EMA.
FM.3 parameterr: "iat", double, value, standard value is 1.0.
"servicetime", double, standard value is 0.8.
FM.6 RequestStatistics: "dN", "qN", "uN" are the main statistics. Of each you can ask:
•
•
•
•
•
•
•
•
.average
.stdev
.variance
.sum
.min
.max
.halfwidth(alpha) where alpha is a real number like 0.05 for a 95% confidence interval
.n
TU Delft | Example: MM1-model with EMA workbench v1.5
26
6 Notes and possible extensions
6.1 Notes
6.2 Possible extensions
TU Delft | Notes and possible extensions v1.5
27
Appendix A. Unit display type coding
0. Dimensionless
The Dimensionless unit does not have any display codes, except the default one, indicated with code
number 0.
1. Acceleration
0
METER_PER_SECOND_2 (SI)
1
KM_PER_HOUR_2
2
INCH_PER_SECOND_2
3
FOOT_PER_SECOND_2
4
MILE_PER_HOUR_2
5
MILE_PER_HOUR_PER_SECOND
6
KNOT_PER_SECOND
7
GAL
8
STANDARD_GRAVITY
m/s2
km/h2
in/s2
ft/s2
mi/h2
mi/h/s
kt/s
gal
g
2. AngleSolid
0
STERADIAN (SI)
1
SQUARE_DEGREE
sr
sq.deg
3. Angle
0
RADIAN (SI)
1
ARCMINUTE
2
ARCSECOND
3
CENTESIMAL_ARCMINUTE
4
CENTESIMAL_ARCSECOND
5
DEGREE
6
GRAD
rad
arcmin / '
arcsec / "
centesimal_arcmin
centesimal_arcsec
deg
grad
4. Direction
0
NORTH_RADIAN (BASE)
1
NORTH_DEGREE
2
EAST_RADIAN
3
EAST_DEGREE
rad(N)
deg(N)
rad(E)
deg(E)
TU Delft | Appendix A. Unit display type coding v1.5
28
5. Area
0
SQUARE_METER (SI)
1
SQUARE_ATTOMETER
2
SQUARE_FEMTOMETER
3
SQUARE_PICOMETER
4
SQUARE_NANOMETER
5
SQUARE_MICROMETER
6
SQUARE_MILLIMETER
7
SQUARE_CENTIMETER
8
SQUARE_DECIMETER
9
SQUARE_DEKAMETER
10
SQUARE_HECTOMETER
11
SQUARE_KILOMETER
12
SQUARE_MEGAMETER
13
SQUARE_INCH
14
SQUARE_FOOT
15
SQUARE_YARD
16
SQUARE_MILE
17
SQUARE_NAUTICAL_MILE
18
ACRE
19
ARE
20
CENTIARE
21
HECTARE
m2
am2
fm2
pm2
nm2
μm2
mm2
cm2
dm2
dam2
hm2
km2
Mm2
in2
ft2
yd2
mi2
NM2
acre
a
ca
ha
6. Density
0
KG_PER_METER_3 (SI)
1
GRAM_PER_CENTIMETER_3
kg/m3
g/cm3
7. ElectricalCharge
0
COULOMB
1
PICOCOULOMB
2
NANOCOULOMB
3
MICROCOULOMB
4
MILLICOULOMB
5
ABCOULOMB
6
ATOMIC_UNIT
7
EMU
8
ESU
9
FARADAY
10
FRANKLIN
11
STATCOULOMB
12
MILLIAMPERE_HOUR
13
AMPERE_HOUR
14
KILOAMPERE_HOUR
15
MEGAAMPERE_HOUR
16
MILLIAMPERE_SECOND
C
pC
nC
μC
mC
abC
au
emu
esu
F
Fr
statC
mAh
Ah
kAh
MAh
mAs
TU Delft | Appendix A. Unit display type coding v1.5
29
8. ElectricalCurrent
0
AMPERE (SI)
1
NANOAMPERE
2
MICROAMPERE
3
MILLIAMPERE
4
KILOAMPERE
5
MEGAAMPERE
6
ABAMPERE
7
STATAMPERE
A
nA
μA
mA
kA
MA
abA
statA
9. ElectricalPotential
0
VOLT (SI)
1
NANOVOLT
2
MICROVOLT
3
MILLIVOLT
4
KILOVOLT
5
MEGAVOLT
6
GIGAVOLT
7
ABVOLT
8
STATVOLT
V
nV
μV
mV
kV
MV
GV
abV
statV
10. ElectricalResistance
0
OHM (SI)
1
NANOOHM
2
MICROOHM
3
MILLIOHM
4
KILOOHM
5
MEGAOHM
6
GIGAOHM
7
ABOHM
8
STATOHM
Ω
nΩ
μΩ
mΩ
kΩ
MΩ
GΩ
abΩ
statΩ
11. Energy
0
JOULE (SI)
1
PICOJOULE
2
NANOJOULE
3
MICROJOULE
4
MILLIJOULE
5
KILOJOULE
6
MEGAJOULE
7
GIGAJOULE
8
TERAJOULE
9
PETAJOULE
10
ELECTRONVOLT
11
MICROELECTRONVOLT
12
MILLIELECTRONVOLT
13
KILOELECTRONVOLT
J
pJ
mJ
μJ
mJ
kJ
MJ
GJ
TJ
PJ
eV
μeV
meV
keV
TU Delft | Appendix A. Unit display type coding v1.5
30
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
MEGAELECTRONVOLT
GIGAELECTRONVOLT
TERAELECTRONVOLT
PETAELECTRONVOLT
EXAELECTRONVOLT
WATT_HOUR
FEMTOWATT_HOUR
PICOWATT_HOUR
NANOWATT_HOUR
MICROWATT_HOUR
MILLIWATT_HOUR
KILOWATT_HOUR
MEGAWATT_HOUR
GIGAWATT_HOUR
TERAWATT_HOUR
PETAWATT_HOUR
CALORIE
KILOCALORIE
CALORIE_IT
INCH_POUND_FORCE
FOOT_POUND_FORCE
ERG
BTU_ISO
BTU_IT
STHENE_METER
MeV
GeV
TeV
PeV
EeV
Wh
fWh
pWh
mWh
μWh
mWh
kWh
MWh
GWh
TWh
PWh
cal
kcal
cal(IT)
in lbf
ft lbf
erg
BTU(ISO)
BTU(IT)
sth.m
12. FlowMass
0
KG_PER_SECOND (SI)
1
POUND_PER_SECOND
kg/s
lb/s
13. FlowVolume
0
CUBIC_METER_PER_SECOND (SI)
1
CUBIC_METER_PER_MINUTE
2
CUBIC_METER_PER_HOUR
3
CUBIC_METER_PER_DAY
4
CUBIC_INCH_PER_SECOND
5
CUBIC_INCH_PER_MINUTE
6
CUBIC_FEET_PER_SECOND
7
CUBIC_FEET_PER_MINUTE
8
GALLON_PER_SECOND
9
GALLON_PER_MINUTE
10
GALLON_PER_HOUR
11
GALLON_PER_DAY
12
LITER_PER_SECOND
13
LITER_PER_MINUTE
14
LITER_PER_HOUR
15
LITER_PER_DAY
m3/s
m3/min
m3/h
m3/day
in3/s
in3/min
ft3/s
ft3/min
gal/s
gal/min
gal/h
gal/day
l/s
l/min
l/h
l/day
TU Delft | Appendix A. Unit display type coding v1.5
31
14. Force
0
NEWTON (SI)
1
KILOGRAM_FORCE
2
OUNCE_FORCE
3
POUND_FORCE
4
TON_FORCE
5
DYNE
6
STHENE
N
kgf
ozf
lbf
tnf
dyne
sth
15. Frequency
0
HERTZ (SI)
1
KILOHERTZ
2
MEGAHERTZ
3
GIGAHERTZ
4
TERAHERTZ
5
PER_SECOND
6
PER_ATTOSECOND
7
PER_FEMTOSECOND
8
PER_PICOSECOND
9
PER_NANOSECOND
10
PER_MICROSECOND
11
PER_MILLISECOND
12
PER_MINUTE
13
PER_HOUR
14
PER_DAY
15
PER_WEEK
16
RPM
Hz
kHz
MHz
GHz
THz
1/s
1/as
1/fs
1/ps
1/ns
1/μs
1/ms
1/min
1/hr
1/day
1/wk
rpm
16. Length
0
METER (SI)
1
ATTOMETER
2
FEMTOMETER
3
PICOMETER
4
NANOMETER
5
MICROMETER
6
MILLIMETER
7
CENTIMETER
8
DECIMETER
9
DEKAMETER
10
HECTOMETER
11
KILOMETER
12
MEGAMETER
13
INCH
14
FOOT
15
YARD
16
MILE
17
NAUTICAL_MILE
18
ASTRONOMICAL_UNIT
m
am
fm
pm
nm
μm
mm
cm
dm
dam
hm
km
Mm
in
ft
yd
mi
NM
au
TU Delft | Appendix A. Unit display type coding v1.5
32
19
20
21
PARSEC
LIGHTYEAR
ANGSTROM
pc
ly
Å
17. Position
0
METER (BASE)
1
ATTOMETER
2
FEMTOMETER
3
PICOMETER
4
NANOMETER
5
MICROMETER
6
MILLIMETER
7
CENTIMETER
8
DECIMETER
9
DEKAMETER
10
HECTOMETER
11
KILOMETER
12
MEGAMETER
13
INCH
14
FOOT
15
YARD
16
MILE
17
NAUTICAL_MILE
18
ASTRONOMICAL_UNIT
19
PARSEC
20
LIGHT_YEAR
21
ANGSTROM
m
am
fm
pm
nm
μm
mm
cm
dm
dam
hm
km
Mm
in
ft
yd
mi
NM
au
pc
ly
Å
18. LinearDensity
0
PER_METER (SI)
1
PER_ATTOMETER
2
PER_FEMTOMETER
3
PER_PICOMETER
4
PER_NANOMETER
5
PER_MICROMETER
6
PER_MILLIMETER
7
PER_CENTIMETER
8
PER_DECIMETER
9
PER_DEKAMETER
10
PER_HECTOMETER
11
PER_KILOMETER
12
PER_MEGAMETER
13
PER_INCH
14
PER_FOOT
15
PER_YARD
16
PER_MILE
17
PER_NAUTICAL_MILE
18
PER_ASTRONOMICAL_UNIT
1/m
1/am
1/fm
1/pm
1/nm
1/μm
1/mm
1/cm
1/dm
1/dam
1/hm
1/km
1/Mm
1/in
1/ft
1/yd
1/mi
1/NM
1/au
TU Delft | Appendix A. Unit display type coding v1.5
33
19
20
21
PER_PARSEC
PER_LIGHT_YEAR
PER_ANGSTROM
1/pc
1/ly
1/Å
19. Mass
0
KILOGRAM (SI)
1
FEMTOGRAM
2
PICOGRAM
3
NANOGRAM
4
MICROGRAM
5
MILLIGRAM
6
GRAM
7
MEGAGRAM
8
GIGAGRAM
9
TERAGRAM
10
PETAGRAM
11
MICROELECTRONVOLT
12
MILLIELECTRONVOLT
13
KILOELECTRONVOLT
14
MEGAELECTRONVOLT
15
GIGAELECTRONVOLT
16
TERAELECTRONVOLT
17
PETAELECTRONVOLT
18
EXAELECTRONVOLT
19
OUNCE
20
POUND
21
DALTON
22
TON_LONG
23
TON_SHORT
24
TONNE
kg
fg
pg
mg
μg
mg
kg
Mg
Gg
Tg
Pg
μeV
meV
keV
MeV
GeV
TeV
PeV
EeV
oz
lb
Da
ton (long)
ton (short)
tonne
20. Power
0
WATT (SI)
1
FEMTOWATT
2
PICOWATT
3
NANOWATT
4
MICROWATT
5
MILLIWATT
6
KILOWATT
7
MEGAWATT
8
GIGAWATT
9
TERAWATT
10
PETAWATT
11
ERG_PER_SECOND
12
FOOT_POUND_FORCE_PER_SECOND
13
FOOT_POUND_FORCE_PER_MINUTE
14
FOOT_POUND_FORCE_PER_HOUR
15
HORSEPOWER_METRIC
W
fW
pW
mW
μW
mW
kW
MW
GW
TW
PW
erg/s
ft.lbf/s
ft.lbf/min
ft.lbf/h
hp / PS
TU Delft | Appendix A. Unit display type coding v1.5
34
16
STHENE_METER_PER_SECOND
sth/s
21. Pressure
0
PASCAL (SI)
1
HECTOPASCAL
2
KILOPASCAL
3
ATMOSPHERE_STANDARD
4
ATMOSPHERE_TECHNICAL
5
MILLIBAR
6
BAR
7
BARYE
8
MILLIMETER_MERCURY
9
CENTIMETER_MERCURY
10
INCH_MERCURY
11
FOOT_MERCURY
12
KGF_PER_SQUARE_MM
13
PIEZE
14
POUND_PER_SQUARE_INCH
15
POUND_PER_SQUARE_FOOT
16
TORR
Pa
hPa
kPa
atm
at
mbar
bar
Ba
mmHg
cmHg
inHg
ftHg
kgf/mm2
pz
lb/in2
lb/ft2
torr
22. Speed
0
METER_PER_SECOND (SI)
1
METER_PER_HOUR
2
KM_PER_SECOND
3
KM_PER_HOUR
4
INCH_PER_SECOND
5
INCH_PER_MINUTE
6
INCH_PER_HOUR
7
FOOT_PER_SECOND
8
FOOT_PER_MINUTE
9
FOOT_PER_HOUR
10
MILE_PER_SECOND
11
MILE_PER_MINUTE
12
MILE_PER_HOUR
13
KNOT
m/s
m/h
km/s
km/h
in/s
in/min
in/h
ft/s
ft/min
ft/h
mi/s
mi/min
mi/h
kt
23. Temperature
0
KELVIN (SI)
1
DEGREE_CELSIUS
2
DEGREE_FAHRENHEIT
3
DEGREE_RANKINE
4
DEGREE_REAUMUR
K
O
C
O
F
O
R
O
Ré
TU Delft | Appendix A. Unit display type coding v1.5
35
24. AbsoluteTemperature
0
KELVIN (SI)
1
DEGREE_CELSIUS
2
DEGREE_FAHRENHEIT
3
DEGREE_RANKINE
4
DEGREE_REAUMUR
K
O
C
O
F
O
R
O
Ré
25. Duration
0
SECOND (SI)
1
ATTOSECOND
2
FEMTOSECOND
3
PICOSECOND
4
NANOSECOND
5
MICROSECOND
6
MILLISECOND
7
MINUTE
8
HOUR
9
DAY
10
WEEK
s
as
fs
ps
ns
μs
ms
min
hr
day
wk
26. Time
0
BASE_SECOND
1
BASE_MICROSECOND
2
BASE_MILLISECOND
3
BASE_MINUTE
4
BASE_HOUR
5
BASE_DAY
6
BASE_WEEK
7
EPOCH_SECOND (since 1-1-70)
8
EPOCH_MICROSECOND (since 1-1-70)
9
EPOCH_MILLISECOND (since 1-1-70)
10
EPOCH_MINUTE (since 1-1-70)
11
EPOCH_HOUR (since 1-1-70)
12
EPOCH_DAY (since 1-1-70)
13
EPOCH_WEEK (since 1-1-70)
14
YEAR1_SECOND (since 1-1-0001)
15
J2000_SECOND (since 1-1-2000, 12:00)
s
μs
ms
min
hr
day
wk
s (POSIX)
μs (POSIX)
ms (POSIX)
min (POSIX)
hr (POSIX)
day (POSIX)
wk (POSIX)
s(1-1-0001)
s(1-1-2000)
27. Torque
0
NEWTON_METER (SI)
1
POUND_FOOT
2
POUND_INCH
3
METER_KILOGRAM_FORCE
Nm
lb.ft
lb.in
m.kgf
TU Delft | Appendix A. Unit display type coding v1.5
36
28. Volume
0
CUBIC_METER (SI)
1
CUBIC_ATTOMETER
2
CUBIC_FEMTOMETER
3
CUBIC_PICOMETER
4
CUBIC_NANOMETER
5
CUBIC_MICROMETER
6
CUBIC_MILLIMETER
7
CUBIC_CENTIMETER
8
CUBIC_DECIMETER
9
CUBIC_DEKAMETER
10
CUBIC_HECTOMETER
11
CUBIC_KILOMETER
12
CUBIC_MEGAMETER
13
CUBIC_INCH
14
CUBIC_FOOT
15
CUBIC_YARD
16
CUBIC_MILE
17
LITER
18
GALLON_IMP
19
GALLON_US_FLUID
20
OUNCE_IMP_FLUID
21
OUNCE_US_FLUID
22
PINT_IMP
23
PINT_US_FLUID
24
QUART_IMP
25
QUART_US_FLUID
26
CUBIC_PARSEC
27
CUBIC_LIGHT_YEAR
m3
am3
fm3
pm3
nm3
μm3
mm3
cm3
dm3
dam3
hm3
km3
Mm3
in3
ft3
yd3
mi3
l
gal (imp)
gal (US)
oz (imp)
oz (US)
pt (imp)
pt (US)
qt (imp)
qt (US)
pc3
ly3
100. Money
Money is in essence dimensionless. The following currencies are supported, according to ISO 4217 2:
CODE
784
971
008
051
532
973
032
036
533
944
977
052
050
975
2
ABBREV.
AED
AFN
ALL
AMD
ANG
AOA
ARS
AUD
AWG
AZN
BAM
BBD
BDT
BGN
NAME
United Arab Emirates dirham
Afghan afghani
Albanian lek
Armenian dram
Netherlands Antillean guilder
Angolan kwanza
Argentine peso
Australian dollar
Aruban florin
Azerbaijani manat
Bosnia and Herzegovina convertible mark
Barbados dollar
Bangladeshi taka
Bulgarian lev
https://en.wikipedia.org/wiki/ISO_4217
TU Delft | Appendix A. Unit display type coding v1.5
37
CODE
048
108
060
096
068
984
986
044
064
072
933
974
084
124
976
947
756
948
990
152
156
170
970
188
931
192
132
203
262
208
214
012
818
232
230
978
242
238
826
981
936
292
270
324
320
328
344
340
191
ABBREV.
BHD
BIF
BMD
BND
BOB
BOV
BRL
BSD
BTN
BWP
BYN
BYR
BZD
CAD
CDF
CHE
CHF
CHW
CLF
CLP
CNY
COP
COU
CRC
CUC
CUP
CVE
CZK
DJF
DKK
DOP
DZD
EGP
ERN
ETB
EUR
FJD
FKP
GBP
GEL
GHS
GIP
GMD
GNF
GTQ
GYD
HKD
HNL
HRK
NAME
Bahraini dinar
Burundian franc
Bermudian dollar
Brunei dollar
Boliviano
Bolivian Mvdol (funds code)
Brazilian real
Bahamian dollar
Bhutanese ngultrum
Botswana pula
New Belarusian ruble
Belarusian ruble
Belize dollar
Canadian dollar
Congolese franc
WIR Euro (complementary currency)
Swiss franc
WIR Franc (complementary currency)
Unidad de Fomento (funds code)
Chilean peso
Chinese yuan
Colombian peso
Unidad de Valor Real (UVR) (funds code)
Costa Rican colon
Cuban convertible peso
Cuban peso
Cape Verde escudo
Czech koruna
Djiboutian franc
Danish krone
Dominican peso
Algerian dinar
Egyptian pound
Eritrean nakfa
Ethiopian birr
Euro
Fiji dollar
Falkland Islands pound
Pound sterling
Georgian lari
Ghanaian cedi
Gibraltar pound
Gambian dalasi
Guinean franc
Guatemalan quetzal
Guyanese dollar
Hong Kong dollar
Honduran lempira
Croatian kuna
TU Delft | Appendix A. Unit display type coding v1.5
38
CODE
332
348
360
376
356
368
364
352
388
400
392
404
417
116
174
408
410
414
136
398
418
422
144
430
426
434
504
498
969
807
104
496
446
478
480
462
454
484
979
458
943
516
566
558
578
524
554
512
590
ABBREV.
HTG
HUF
IDR
ILS
INR
IQD
IRR
ISK
JMD
JOD
JPY
KES
KGS
KHR
KMF
KPW
KRW
KWD
KYD
KZT
LAK
LBP
LKR
LRD
LSL
LYD
MAD
MDL
MGA
MKD
MMK
MNT
MOP
MRO
MUR
MVR
MWK
MXN
MXV
MYR
MZN
NAD
NGN
NIO
NOK
NPR
NZD
OMR
PAB
NAME
Haitian gourde
Hungarian forint
Indonesian rupiah
Israeli new shekel
Indian rupee
Iraqi dinar
Iranian rial
Icelandic króna
Jamaican dollar
Jordanian dinar
Japanese yen
Kenyan shilling
Kyrgyzstani som
Cambodian riel
Comoro franc
North Korean won
South Korean won
Kuwaiti dinar
Cayman Islands dollar
Kazakhstani tenge
Lao kip
Lebanese pound
Sri Lankan rupee
Liberian dollar
Lesotho loti
Libyan dinar
Moroccan dirham
Moldovan leu
Malagasy ariary
Macedonian denar
Myanmar kyat
Mongolian tögrög
Macanese pataca
Mauritanian ouguiya
Mauritian rupee
Maldivian rufiyaa
Malawian kwacha
Mexican peso
Mexican Unidad de Inversion (UDI) (funds code)
Malaysian ringgit
Mozambican metical
Namibian dollar
Nigerian naira
Nicaraguan córdoba
Norwegian krone
Nepalese rupee
New Zealand dollar
Omani rial
Panamanian balboa
TU Delft | Appendix A. Unit display type coding v1.5
39
CODE
604
598
608
586
985
600
634
946
941
643
646
682
090
690
938
752
702
654
694
706
968
728
678
222
760
748
764
972
934
788
776
949
780
901
834
980
800
840
997
940
858
860
937
704
548
882
950
961
959
ABBREV.
PEN
PGK
PHP
PKR
PLN
PYG
QAR
RON
RSD
RUB
RWF
SAR
SBD
SCR
SDG
SEK
SGD
SHP
SLL
SOS
SRD
SSP
STD
SVC
SYP
SZL
THB
TJS
TMT
TND
TOP
TRY
TTD
TWD
TZS
UAH
UGX
USD
USN
UYI
UYU
UZS
VEF
VND
VUV
WST
XAF
XAG
XAU
NAME
Peruvian Sol
Papua New Guinean kina
Philippine peso
Pakistani rupee
Polish zloty
Paraguayan guaraní
Qatari riyal
Romanian leu
Serbian dinar
Russian ruble
Rwandan franc
Saudi riyal
Solomon Islands dollar
Seychelles rupee
Sudanese pound
Swedish krona/kronor
Singapore dollar
Saint Helena pound
Sierra Leonean leone
Somali shilling
Surinamese dollar
South Sudanese pound
São Tomé and Príncipe dobra
Salvadoran colón
Syrian pound
Swazi lilangeni
Thai baht
Tajikistani somoni
Turkmenistani manat
Tunisian dinar
Tongan pa?anga
Turkish lira
Trinidad and Tobago dollar
New Taiwan dollar
Tanzanian shilling
Ukrainian hryvnia
Ugandan shilling
United States dollar
United States dollar (next day) (funds code)
Uruguay Peso en Unidades Indexadas (URUIURUI) (funds code)
Uruguayan peso
Uzbekistan som
Venezuelan bolívar
Vietnamese dong
Vanuatu vatu
Samoan tala
CFA franc BEAC
Silver (one troy ounce)
Gold (one troy ounce)
TU Delft | Appendix A. Unit display type coding v1.5
40
CODE
955
956
957
958
951
960
952
964
953
962
994
963
965
999
886
710
967
932
1000
ABBREV.
XBA
XBB
XBC
XBD
XCD
XDR
XOF
XPD
XPF
XPT
XSU
XTS
XUA
XXX
YER
ZAR
ZMW
ZWL
XBT
NAME
European Composite Unit (EURCO) (bond market unit)
European Monetary Unit (E.M.U.-6) (bond market unit)
European Unit of Account 9 (E.U.A.-9) (bond market unit)
European Unit of Account 17 (E.U.A.-17) (bond market unit)
East Caribbean dollar
Special drawing rights
CFA franc BCEAO
Palladium (one troy ounce)
CFP franc (franc Pacifique)
Platinum (one troy ounce)
SUCRE
Code reserved for testing purposes
ADB Unit of Account
No currency
Yemeni rial
South African rand
Zambian kwacha
Zimbabwean dollar A/10
Bitcoin
101. MoneyPerArea
For MoneyPerArea (code 101), it is suggested to send three bytes: two for the Money, followed by an
Area constant. As an example, if we want to send the price of land as € 2500 per hectare,
transmitted as a double (code 26), this would be coded as (€ has code 978 = #03D2):
|26|101|0x03|0xD2|21|0x40|0xA3|0x88|0x00|0x00|0x00|0x00|0x00|
102. MoneyPerEnergy
For MoneyPerEnergy, it is suggested to send three bytes: two for the Money, followed by an Energy
display constant.
103. MoneyPerLength
For MoneyPerLength, it is suggested to send three bytes: two for the Money, followed by a Length
display constant.
104. MoneyPerMass
For MoneyPerMass, it is suggested to send three bytes: two for the Money, followed by a Mass
display constant.
105. MoneyPerDuration
For MoneyPerDuration, it is suggested to send three bytes: two for the Money, followed by a
Duration display constant.
106. MoneyPerVolume
For MoneyPerVolume, it is suggested to send three bytes: two for the Money, followed by a Volume
display constant.
TU Delft | Appendix A. Unit display type coding v1.5
41
Source Exif Data:
File Type : PDF File Type Extension : pdf MIME Type : application/pdf PDF Version : 1.5 Linearized : Yes Author : Alexander Verbraeck Company : TU Delft Create Date : 2017:04:29 22:44:10+02:00 Modify Date : 2017:04:29 22:44:21+02:00 Source Modified : D:20170429204401 Tagged PDF : Yes XMP Toolkit : Adobe XMP Core 5.2-c001 63.139439, 2010/09/27-13:37:26 Metadata Date : 2017:04:29 22:44:21+02:00 Creator Tool : Acrobat PDFMaker 10.1 for Word Document ID : uuid:00f461e7-7a2b-4d8c-8d5f-b353a2ca1851 Instance ID : uuid:b0a664de-3f44-4bed-94da-299f32e22996 Subject : 23 Format : application/pdf Creator : Alexander Verbraeck Producer : Adobe PDF Library 10.0 Page Layout : OneColumn Page Count : 41EXIF Metadata provided by EXIF.tools