Medibus Drager
Medibus Drager
Medibus Drager
Protocol Definition
Instructions for Use
Revision Level 4.03
Contents
MEDIBUS Commands................................................7
Structure of Commands......................................... 7
Command Codes...................................................8
MEDIBUS Responses...............................................10
Structure of Responses........................................10
Responding to Control Commands and
unknown Commands............................................11
Responding to corrupt Commands....................... 11
Responding to Data Request Commands............. 11
Current Measured Data and
Alarm Limit Response..................................... 12
Alarm Status Responses................................. 12
Time & Date Update Response....................... 13
Device Setting Responses.............................. 14
Text Message Response................................. 14
Device Identification Response........................15
MEDIBUS Realtime-Extension
Realtime-Data Records............................................ 21
Structure of Realtime-Data Records......................21
Sync Byte....................................................... 21
Sync-Commands............................................ 22
2
For Your Safety and that of Your
Patients
1)
Insofar as reference is made to laws, regulations or standards, these
are based on the legal system of the Federal Republic of Germany.
3
Intended Use
4
MEDIBUS
Introduction
Initializing Communication
(refer to MEDIBUS-life-cyle-diagram)
– To initialize communication or to restart communica-
tion after a time-out, a device must send the "Initialize
Communications Command" ICC. Refer to section
"Control commands" for the format of commands.
– A device considers communication initialized after
having received either a response to a transmitted
ICC or an ICC from the other device. Refer to section
"Responding to commands" for the format of
responses.
– Commands embedded in a response to an ICC are
disregarded.
Terminating Communication
– To stop the communication the "STOP" command
has to be sent.
– The command echo has to be checked to make sure
the "Stop Communication" command has been
received correctly. Further commands from the linked
device may be ignored until the communication has
been reinitialized.
Time-Out
– Any pause in the data flow exceeding 3 seconds
leads to a time-out, terminating the communication
link. To resume communication after a time-out, the
device must re-initialize communication by transmitting
an ICC command (cf. section "Initializing communica-
tion"). Whenever a device receives an ICC command,
it must send a response to it (cf. section
"Responses").
– After receiving a command the device has to send a
complete response within 10 seconds.
– If there is no need for sending commands or
responses the "NOP"–command has to be sent in
2-second-intervals to keep the communication alive.
5
MEDIBUS
Introduction
Allowable Characters
– Printable ASCII characters.
– Control characters defined in this Instructions for Use.
Software Handshaking
– Some control characters can be sent at any time to
control the flow of data. They do not require
responses.
6
MEDIBUS
Commands
Structure of Commands
– A command is a string of ASCII characters
transmitted by one device to request data from the
other device or to control its function.
– A command may be embedded in the response to
another command, but a new command must not
be transmitted until the response to the previous
command has been received.
– If, however, the response to a command has not been
received in full within 10 seconds since the
transmission of the last command byte, the command
may be repeated or a new command may be
transmitted.
0 1 2 4 5 Byte
7
MEDIBUS
Commands
Command Codes
Control Commands
Control commands are used to initialize, control and stop
communication.
Command Code
No Operation (NOP) 30H
Initialize Communication (ICC) 51H
Stop Communication (STOP) 55H
Command Code
Request current measured Data (Codepage 1) 24H
Request current low Alarm Limits (Codepage 1) 25H
Request current high Alarm Limits (Codepage 1) 26H
Request current Alarms (Codepage 1) 27H
Request current Date and Time 28H
Request current Device Setting 29H
Request current Text Messages 2AH
Request current measured Data (Codepage 2) 2BH
Request current low Alarm Limits (Codepage 2) 2CH
Request current high Alarm Limits (Codepage 2) 2DH
Request current Alarms (Codepage 2) 2EH
Request Device Identification 52H
Miscellaneous Commands
Command Code
Time changed 49H
Configure Data Response Command 4AH
8
MEDIBUS
Commands
0 +1 +3 +5 +2n-2 +2n
n <= 125
DATA TYPE:
One byte identifying the data type to configure.
This may be:
24H for current Data, low Alarm Limits and high
Alarm Limits (codepage 1)
27H for current Alarms (codepage 1)
29H for current Device Settings
2AH for current Textmessages
2BH for current Data, low Alarm Limits and high
Alarm Limits (codepage 2)
2EH for current Alarms (codepage 2)
DATA CODE:
Two byte ASCII HEX data code. See appendices for
code numbers.
The configuration stays valid until receipt of a new
"Configure Data Response" command. After re-initializia-
tion of communication (ICC) and if the "Configure Data
Response" is send without data codes, the configuration
is set to its default state, where internal programmed
configuration is used.
An example is given in Appendix.
9
MEDIBUS
Responses
Structure of Responses
Upon receipt of a command, a device must respond to it
within 10 seconds. A command may be embedded within
the response. The following format has to be used:
– – –
10
MEDIBUS
Responses
0 1 2 4 5 Byte
11
MEDIBUS
Responses
DATA CODE Two byte ASCII HEX number identifying the parameter or
alarm limit.
DATA Four byte ASCII field containing the current value of the
parameter or alarm limit.
See appendix for data formats. Surplus character positions
and leading zeros must be replaced by an ASCII "Space"
(20H).
ALARM Priority One byte field specifying the alarm priority (number in the
range of 1 to 31), 31 being the highest priority. The
priority is encoded by adding 30H. The priorities,
therefore, lie in the range from ASCII "1" (31H) to ASCII
character "O" (4FH).
Alarm priorities see Appendix.
ALARM CODE Two byte ASCII HEX number identifying the alarm.
ALARM PHRASE Twelve byte ASCII character string describing the alarm.
12
MEDIBUS
Responses
TIME DATE
(HH:MM:SS) (DD-MMM-YY)
0 +8 +17
NOTE:
The month representing letters (MMM) has to be sent in
German language.
MONTH REPRESENTIVE
January JAN
February FEB
March MAR
April APR
May MAI
June JUN
July JUL
August AUG
September SEP
October OKT
November NOV
December DEZ
* The PM 8040 substitudes leading zeros in the hours, day and year
field with ASCII spaces (20H), e.g. ' 8:06:05 4-MAR 2'.
13
MEDIBUS
Responses
15
MEDIBUS Realtime-Extension
Introduction
Time-Out
Realtime bytes (Sync-Byte, Sync-commands, Realtime
values) do not affect the 3 sec time-out described in the
"Time-out" chapter of the "slow" MEDIBUS-Protocol.
Data-Bit 0 to 6
Realtime Data Flag not set
16
MEDIBUS Realtime-Extension
Introduction
Sync Byte
A Sync Byte is always the first byte in a realtime-data-
record (see page 21).
A Sync Byte is transmitted in the following format:
sync byte
1101XXXX
Sync-Command Bytes
Sync-Commands are used for information which have to
be transmitted without delay (see section Sync-
Commands).
The form of a sync-command-byte and its argument is as
follows:
sync-command byte
1100XXXX
Realtime-Value-Bytes
A realtime value is transmitted at a resolution of 12 bits.
For transmission the value is diveded into two data bytes:
1. byte 2. byte
10DDDDDD 10DDDDDD
17
MEDIBUS Realtime-Extension
Commands
Command Codes
Command Code
Request Realtime Configuration 53H
Configure Realtime Transmission 54H
Realtime Configuration changed 56H
18
MEDIBUS Realtime-Extension
Commands
19
MEDIBUS Realtime-Extension
Responses
NOTE:
In MIN and MAX the first character may be a minus.
MIN and MAX may contain a decimal point at any
position except at the first or last character position.
Leading zeros must be replaced by spaces.
20
MEDIBUS Realtime-Extension
Realtime-Data Records
Sync 1st Sync-Comm. 1st Sync-Comm. 1st value 2nd value nth Value
Byte Code Argum. ... Code Argum. lower higher lower higher lower higher
1 1 n n Bits Bits Bits Bits Bits Bits
Sync Byte
The sync byte status bits, if set, hold the following
information:
Example (binary):
11010101 10110000 10100011 10001011 10111100
Sync Byte value of 1st curve value of 3rd curve
8F0H F0BH
2nd value
missing
21
MEDIBUS Realtime-Extension
Realtime-Data Records
Sync-Commands
Sync-Commands are used for information which have to
be sent very fast (e.g. enable/disable datastreams) or
which belong to the realtime data directly following the
Sync-Commands.
A Sync-Command is not responded to!
Sync-Commands are embedded within a realtime-data
record (see chapter 5). Up to 16 Sync-Commands may
optionally follow the Sync Byte.
22
MEDIBUS Realtime-Extension
Realtime-Data Records
(*):
The bits 0 to 3 within the argument are related to the datastreams in the
same order as the Sync-Byte's status-bits to the datastream 1 to 4 (see
5.1). A set bit (1) enables, a resetted bit (0) disables the attached
datastream.
(**):
"Transmitted Datastreams" commands must be sent only if the order of
transmitted datastreams has changed. The datastreams will be sent in a
fixed order, until a new "Transmitted Datastream" command announces
a new order.
23
Appendix
MEDIBUS-Life-Cycle
Communications Start-up
After starting the device it must send an ICC-command.
This command may be repeated each 3 seconds if no
character was received or each 10 seconds if characters
have been received but no complete response within this
time.
On receipt of an ICC-response a "Request Device-Identi-
fication"-command may be sent if required.
After having received and processed a correct Device-
Identification the device is now in an active protocol
state. It is ready to answer Data Request Commands or
to send any command on its own.
Communications Time-Out
If no character is received within 3 seconds the commu-
nication is assumed to be broken. In case of a 3 seconds
time-out, communication must be re-initialized by sending
an ICC-command.
If communication is in an idle state (no command or
response pending) the NOP-command may be sent by
any device every 2 seconds to keep communication alive
and to avoid a 3 seconds time-out.
Terminating Communication
To terminate communication regular the STOP-command
must be sent. After receipt of the STOP-response the
device may completely stop the communication.
The STOP-command must be sent to avoid an error-state
and error-communication on the linked device.
24
Appendix
Start of Device
send
ICC-Command
3 or 10 sec Timeout
or Checksum-Error
ICC-Command received
waiting for ICC- send ICC-
Response Response
ICC-Response received
send Request-
Device-ID-
Command
10 sec Timeout
or Checksum-Error
Command received
waiting for send
Device-ID- Command-
Response Response
correct Device-ID
received
3 sec Timeout
Request-Device-
ID-response
processing
MEDIBUS-
Protocol active
waiting for
STOP-
Response
Communication
STOP-Response received Reset
Stop of Device
25
Appendix
MEDIBUS Realtime-Extension
– Life-Cycle
Re-configuration of data-transmission
Re-configuration by receiver:
After realtime-data transmission has been configured and
enabled once, using the "Configure Realtime-
Transmission" command a new configuration may be
sent at any time. The realtime data source will change the
configuration after receipt of the configuration command.
To keep the moment of change under control the realtime
data receiver is recommended to disable all or only the
changed datastreams by using the "Enable/Disable
Datastream" commands before sending the new
configuration and to enable the datastreams after receipt
of the response to its configuration command.
26
Appendix
MEDIBUS active
(ICC and Device-ID
processed)
start Realtime-MEDIBUS
send Request-Realtime-
Configuration Command
Request-Realtime-Configuration
Response
send Configure-Real-
time-Transmission
Command
Configure-Realtime-
Transmission Response
enable Datastreams
Realtime-Configuration-changed
Realtime Data Record Command received
send Realtime-
disable Datastreams process Realtime Data Configuration-changed
Command Response
disable Datastreams
27
Appendix
Example:
28
Appendix
MEDIBUS example 1
PC responds:
SOH ICC-Echo CHECKSUM CR
29
Appendix
MEDIBUS example 2
Data update command and response
01H 24H 45H 42H 20H 39H 38H 20H 45H 31H 20H 37H 30H 20H 37H 41H 0DH
0 1 2 4 8 10 14 16 17
MEDIBUS example 3
Configure Data response command
If the receiving device of example 2 is only interested in
O2Sat, it has to send the configure Data Response
Command.
ESC Command Code Datatype Data Code CHECKSUM CR
'E' 'B' '1' '0'
1BH 4AH 24H 45H 42H 31H 30H 0DH
30
Appendix
MEDIBUS example 4
Request current date and time.
After Start-up a PC requests current date and time from
Dräger Device:
After a while the user changes the time and date setting
on the Dräger Device, which therefore sends the "Time
changed" command:
The PC echos
31
Appendix
MEDIBUS example 5
Realtime-Extension
After general start-up procedure a PC requests a Dräger
Device for its Realtime Configuration:
SOH Echo
01H 53H
Checksum CR
'3' 'B'
33H 45H 0DH
32
Appendix
Sync Byte =
D3H = 1101 0011bin indicates realtime values 0 and 1
are following because bits 0 (LSB) and 1 are set.
Airway Pressure =
91H 81H = 1001 0001bin 1000 0001bin
=> Regarding the format of Realtime-Value-Bytes
(see page 17)
the twelve bit realtime value is 0000 0101 0001bin =
81dec
=> the according Airway Pressure value v(xbin) in mbar
is (regard page 20):
v(xbin) = –10 mbar + 81 * (100 mbar – (–10 mbar)) /
880 = 0.125 mbar
CO2 =
8DH 83H = 1000 1101bin 1000 0011bin
=> twelve bit binary value 0000 1100 1101bin = 205dec
=> CO2 value v(xbin) in mmHg:
v(xbin) = –20 mmHg + 205 * (100 mmHg –
(–20 mmHg))/1120 = 1.96 mmHg
33
Appendix
Sync Byte D2H = 1101 0010 bin has only bit 1 set,
indicating only the second configured trace CO2
is following the Sync Byte. The first trace Airway
Pressure is missing.
Do all Dräger medical devices send the ICC command on their own?
Yes. As long as an ICC response and an ICC command are not
received, Dräger medical devices send the ICC command
approx. every 3 seconds.
Does my PC have to respond to the ICC command from the Dräger medical device?
Yes. Every command must be responded to.
34
Appendix
Why isn’t the data configuration command processed; in other words: Why
does my PC still receive all data when subsequent data request commands
are given?
The data configuration command is often sent too early. All
Dräger medical devices send a device identification request after
the ICC sequence. Your PC needs to respond to this request
first (see above) and then allow the Dräger medical device
approx. 200ms to process this response. Only after this will the
Dräger medical device be ready to process the data
configuration command. All previous data configuration
commands shall be ignored by the Dräger medical device.
35
Appendix
How long does it take the response to come from the Dräger medical
device?
This depends on the Dräger medical device, the command, the
length of the response and the Baud rate. For this reason, this
question cannot be answered completely. Usually, far less than
500ms pass between the completed reception of a command
and the transfer of the first character of the response.
36
Appendix
Is all information and are all configurations sent to the Dräger medical
device before the re-initialization lost during a communication re-initialization
(ICC), e.g. after a 3-second or a 10-second time-out, and does everything
have to be re-sent for this reason?
Yes. All information in the Dräger medical device sent previously
will be deleted with every communication (re-)initialization.
37
Appendix
Will the ESC for commands / the SOH for responses be calculated into
the check sum?
Yes. See the MEDIBUS examples in this instruction for use.
Logbook of Changes
38
Appendix
39
Dräger Medical AG & Co. KGaA
Germany
H Moislinger Allee 53 – 55
D-23542 Lübeck
T (4 51) 8 82 - 0
X 26 80 70
FAX (4 51) 8 82-20 80
! http://www.draeger.com
90 28 258 - GA 6494.380 en
Dräger Medical AG & Co. KGaA
7th edition - September 2003
Subject to alteration