2!MODBUS Communication Overview .........................................................................................................................................4!
2.1! General Overview...............................................................................................................................................................................4!
3!EVSE MODBUS Communication Architecture....................................................................................................................... 7!
3.1! MODBUS/TCP Communication Topologies ............................................................................................................................ 7!
4.4! EVSE Current Charging Information Diagnostic Registers ...........................................................................................18!
4.7! Summary of EVSE MODBUS Data Registers ........................................................................................................................23!
MODBUS is an application layer messaging protocol for device communications over different types
of buses or networks. MODBUS communication adopts client and server model. MODBUS Client
initials the MODBUS communication by issuing MODBUS Request and the MODBUS Server processes
the request and sends back the MODBUS Response as shown in Figure 2.1.
MODBUS Client
MODBUS client/server model.
2.1.1 MODBUS Protocol Data Unit (PDU)
MODBUS protocol itself defines a simple protocol data unit ((PPDDUU)) independent of the underlying
communication layers as shown in Figure 2.2.
Function Code
MODBUS PDU format.
Figure - 2.2
Field Description
Function Code Tell MODBUS server what kind of action to perform. For some function
code, sub function code is added to define multiple actions.
Based on the underlying communication bus, additional bus related fields are added to the beginning
(and tailor) of the MODBUS PDU to form MODBUS Application Data Unit. Figure 2-3 shows a MODBUS
Serial ADU format. The MODBUS/TCP ADU format will be addressed in section 2.2.
MODBUS ADU
Address
Function Code
MODBUS RTU ADU format
Figure – 2.3
2.1.3 MODBUS Data Model
MODBUS uses a ‘big-Endian’ representation for addresses and data items. MODBUS data model maps
data into four different kinds of register ranges each of which has distinguishing characteristics as
shown in Table 2.2. Each MODBUS register is a 16 bits field.
Register Type Object Type Type of Access Comments
Coil Single bit Read-Write This data in this type of registers
Discrete Input Single bit Read-Only This type of data can be provided
Input Register 16 bits word Read-Only This type of data can be provided
Holding Register 16 bits word Read-Write This data in this type of registers
MODBUS communication over TCP has already become a de-facto automation standard. Figure 2.4
shows the MODBUS/TCP ADU format.
MODBUS/TCP ADU format.
Figure – 2.4
A dedicated header called the MBAP header (MODBUS Application Protocol header) is used to identify
the MODBUS/TCP Application Data Unit as Figure 2.5.
MODBUS/TCP MBAP Header
The MBAP header is 7 bytes long:
Transaction ID Protocol ID Length Unit ID
MODBUS/TCP ADU
Function Code Data MBAP Header
Figure – 2.5
•Transaction Identifier - It is used for transaction pairing. The MODBUS Client, MODBUS
Gateway, and the MODBUS server will use it to correspond the response to the
corresponding request. The MODBUS server MUST copy in the response the transaction
identifier of the request.
•Protocol Identifier – It is used for intra-system multiplexing. The MODBUS protocol MUST
be identified by the value 0.
•Length
Identifier and data fields.
•Unit Identifier – This field is used for intra-system routing purpose. It is typically used to
communicate to a MODBUS or a MODBUS+ serial line slave through a gateway between
an Ethernet TCP-IP network and a MODBUS serial line. This field is set by the MODBUS
Client in the request and M
server. In this architecture design, the unit ID is ignored by the EVSE.
- The length field is a byte count of the following fields, It includes the Unit
be returned with the same value in the response by the
EVSE adopts MODBUS/TCP communication acting as a MODBUS/TCP server for integrating with the
building management system. In this architecture, a MODBUS Gateway may be needed to connect
BMS from its field bus network to the Ethernet network as shown in Figure 3.1.
The MODBUS Gateway:
• is implemented as a MODBUS/TCP Client
• identifies the EVSE (MODBUS/TCP server) using EVSE IP address
• maintains the Unit ID of EVSE
• is responsible for corresponding the Unit ID to the EVSE IP address.
Inside the BMS, each EVSE may have a unique unite ID to distinguish each other. The MODBUS Client
devices in the BMS recognize each EVSE with its unit ID for MODBUS communication.
The architecture and design of the MODBUS Gateway and MODBUS/TCP clients are out of the scope
of this specification.
MODBUS
Client in
BMS
MODBUS Response
MODBUS
Gateway
MODBUS/TCP Request
MODBUS/TCP Response
EVSE
(MODBUS/TCP
Server)
EVSE and BMS MODBUS communication topology architecture
Figure – 3.1
In any deployment environments, MODBUS/TCP client devices can directly communicate with EVSE if
they have the access privileges as shown in Figure 3.2.
MODBUS/TCP
Client
EVSE MODBUS/TCP communication topology
Figure – 3.2
EVSE allows up to 5 MODBUS/TCP connections concurrently, which means that it allows 5
MODBUS/TCP clients devices to communicate with it at the same time assumed that each
MODBUS/TCP client device only open one connection.
The first client which connects to the MODBUS server will have command priority, meaning all of the
EVSE basic command functionality will be driven from this first client. Any additional client
connections will only have monitoring capabilities.
MODBUS/TCP
Client
MODBUS/TCP
Client
EVSE
MODBUS/TCP
Client
(MODBUS/TCP
Server)
MODBUS/TCP
Client
MODBUS/TCP
Client
EVSE supports 5 MODBUS/TCP communication connections
Figure – 3.3
GE WattStation Connect™ (a.k.a. GE Back end) server commands will take precedence over any
commands issued over the MODBUS protocol. BES will also have the capability to Enable/Disable the
MODBUS feature completely.
MODBUS protocol itself does not provide security feature. But in this architecture design, the EVSE
MODBUS communication application module adopts MODBUS access control based on the
MODBUS/TCP client IP address and access privilege. The authorized MODBUS/TCP clients and their
access privileges are set up through EVSE configuration.
MODBUS/TCP
Client IP Address
IP Address 1 Bit 0---Data Module 1
.
.
Bit 63---Data Module 64
Value of each bit of
0----read the corresponding
data module is not allowed.
1----read the corresponding
data module is allowed.
IP Address 2
IP Address 3
EVSE MODBUS/TCP messaging is just over TCP, not over SSL (Secure Socket Layer).
3.3 MODBUS Function Codes Supported
In this architecture design, all data MODBUS can access are mapped into the Holding registers, see
Chapter 20 for detail.
In the following descriptions, the MBAP header is omitted.
In this architecture design, EVSE supports the following function codes:
3.3.1 Function Code 3 (0x03): Read Holding Registers (Multiple)
Function code 0x03 is used to read the contents of a contiguous block of holding registers in EVSE.
The MODBUS Function code 0x03 Request PDU specifies the starting register address and the number
of registers to be read. In the PDU Registers are addressed starting at zero. Therefore registers
numbered 1-16 are addressed as 0-15.
Access Privilege
Read Write
Bit 0---Data Module 1
.
.
Bit 63---Data Module 64
Value of each bit of
0----read the corresponding data module
is not allowed.
1----read the corresponding data module
is allowed.
In this version, only Control Command
Module is designed for write.
The register data in the response message are packed as two bytes per register, with the binary
contents right justified within each byte.
For each register, the first byte contains the high order bits and the second contains
the low order bits.
• MODBUS FC 3 Response
Field Length (bytes) Value (hex)
Function Code 1 0x03
Byte Count 1 2 × N
Register Value 2 × N
Table – 3.3
Note: N is the number of registers specified in the request.
3.3.2 Function Code 4 (0x04): Read Input registers (multiple)
Function code 4 is used to read the contents of a contiguous block of input registers (read only) in
EVSE. The MODBUS Function code 4 Request PDU specifies the starting register address and the
number of registers to be read. In the PDU Registers are addressed starting at zero. Therefore
registers numbered 1-16 are addressed as 0-15.
• MODBUS FC 4 Request
Field Length (bytes) Value (hex)
Function Code 1 0x04
Starting Address 2 0x0000 to 0xFFFF
Number of Registers 2 0x1 to 0x7D (1 to 125)
Table – 3.4
The register data in the response message are packed as two bytes per register, with the binary
contents right justified within each byte. For each register, the first byte contains the high order bits
and the second contains the low order bits.
3.3.3 Function Code 6 (0x06): Write single register
Table – 3.5
Function code 6 is used to write a single holding register in EVSE. The MODBUS Function code 6
Request PDU specifies the address if the register to be written. In the PDU Registers are addressed
starting at zero. Therefore registers numbered 1 is addressed as 0.
MODBUS FC 6 Request
Field Length (bytes) Value (hex)
Function Code 1 0x06
Register Address 2 0x0000 to 0xFFFF
Register Value 2 0x0000 to 0xFFFF
Table – 3.6
The register data in the response message are packed as two bytes per register, with the binary
contents right justified within each byte. For each register, the first byte contains the high order bits
and the second contains the low order bits.
• M
Field Length (bytes) Value (hex)
Function Code 1 0x06
Register Address 2 0x0000 to 0xFFFF
3.3.4 Function Code 16 (0x10): Write Multiple Holding Registers
Register Value 2 0x0000 to 0xFFFF
Table – 3.7
Function code 16 (0x10) is used to write data into a contiguous block of holding registers in EVSE.
The MODBUS Function code 16 (0x10) Request PDU specifies the starting register address, the number
of registers to be written, the data length, and the data values. In the PDU Registers are addressed
starting at zero. Therefore registers numbered 1-16 are addressed as 0-15.
The Normal MODBUS function code 16 (0x10) Response PDU specifies the starting register address
and the number of registers to be written.
• MODBUS FC 16 Response
Field Length (bytes) Value (hex)
Function Code 1 0x10
Starting Address 2 0x0000 to 0xFFFF
Quantity of Registers 2 0x0000 to 0x7B (1 to 123)
Table – 3.9
3.3.5 Function Code 23 (0x17): Read and Write Holding Registers
Function code 23 (0x17) performs a combination of one read operation and one write operation in a
single MODBUS transaction. The write operation is performed before the read.
The MODBUS Function code 23 (0x17) Request PDU specifies the read starting register address, the
number of registers to be read, the write starting register address, the number of registers to be
written, the write data length, and the write data values. In the PDU Registers are addressed starting
at zero. Therefore registers numbered 1-16 are addressed as 0-15.
• MODBUS FC 23 Request (note N = Quantity of registers to Write)
Field Length (bytes) Value (hex)
Function Code 1 0x17
Read Starting Address 1 0x0000 to 0xFFFF
Number of Registers to Read 2 0x0001 to 0x7D (1 to 125)
Write Starting Address 2 0x0000 to 0xFFFF
Number of Registers to Write 2 0x0001 to 0x79 (1 to 121)
The data address received in the MODBUS
Write request is not an allowable value for
the
The Normal MODBUS function code 23 Response PDU contains the data from the group of registers
that were read. The byte count field specifies the quantity of bytes to follow in the read data field.
• MODBUS FC 23 Response
Field Length (bytes) Value (hex)
Function Code 1 0x17
Read Byte Count 1 2 × N
Read Registers Value N × 2 Value
3.4 MODBUS Exception Codes Supported
In this version architecture design, the MODBUS in EVSE supports the following Exception Codes as
shown in following table.
Exception Code Exception Code Name Description
1 Illegal Function Code
2 Illegal Data Address
(N = Quantity of registers to Read)
Table – 3.11
request is not an allowable action in EVSE.
request is not an allowable address in EVSE.
3 Illegal Data Value
4 Slave Device Failure An unrecoverable error occurred when
In this architecture design, the authorized master device can get the MODBUS Register Data Module
information which includes the ID, address offset, and length of the data module w/ Function Code 3.
3.5.2 Read EVSE MODBUS Register Data
The authorized master device can read any valid MODBUS registers using Function code 3 or 23 as
shown in section 3.3.
3.5.3 Control EVSE
In this architecture design, the authorized master device can issue MODBUS Control command to
control EVSE by writing an appropriate value to the corresponding command register using function
code 16 or 23.
The supported
4.2.
MODBUS Control commands are defined and mapped to MODBUS registers in section
4 EVSE MODBUS Register Map
4.1 EVSE MODBUS Register Data Module Information Registers
EVSE Module Register Data Module
• Version of MODBUS Register Map.
• Number of MODBUS Data Register Modules in this version of MODBUS Register
Map.
• Data Module ID, Address Offset, and length of each module in the MODBUS
Register Map.
The address offset for EVSE Module Register Data Module
is defined as 0
MODBUS Data Model: Input registers (Read only)
The M
Address
(hex)
in this version of MODBUS Register Map.
for EVSE Module Register Data Module InformationRegisters is defined as 0
MODBUS
Register
InformationRegisters are designed to provide the information on
4.4 EVSE Current Charging Information Diagnostic Registers
EEVVSSEE CCuurrrreenntt CChhaarrggiinngg IInnffoorrmmaattiioonn RReeggiisstteerrss provide the user information about the current
charging being performed.
The a
ddeecciimmaall nnoottaattiioonn)) in this version of MODBUS Register Map.
MMOODDBBUUSS DDaattaa MMooddeell: Input registers (Read only)
The M
Address
(hex)
Offset 341 Current
Offset+1 342 Current
MODBUS
Register
(decimal)
for EVSE current Charging Information registers is defined as 00xx00115555 ((334411 iinn
for EVSE last Charging Information registers is defined as 00xx33.
Parameter Data
Charging
Information
Registers
Validity
Charging
Information
Registers
Version
Description Properties
Range
0-1 This field indicates
whether the current
charging Registers
information are valid
or not.
0----Invalid
1----Valid
0x1000 Indicate the version
of EVSE Current
Charging Information
Register
High byte ---- main
version.
Low byte ---- minor
version.
The current version
of EVSE Current
Charging Information
whether EVSE
charging or not.
0----No Current
Charging
1----Current
Charging
The temperature
100C
6current
rating
inside the
WattStation
supplied to EV
Maximum current
allowed to send to EV
R
R
R
WattStationTM EV Charger MODBUS Register Guide
Charging
Voltage
Offset+7 348 Current
Charging
Consumed
Power (high
16 bit)
Offset+8 349 Current
Charging
Consumed
Power(low 16
bit)
Offset+9 350 Current
Charging
Consumed
Energy(high
16 bit)
Offset+A 351 Current
Charging
Consumed
Energy(low 16
bit)
Offset+B 352 Current
Charging
time--seconds(high
16 bit)
Offset+C 353 Current
Charging
time--seconds(low
16 bit)
Offset+D 354 Connected
time--seconds(high
16 bit)
Offset+E 355 Connected
time--seconds(low
16 bit)
Current Charging Information Diagnostic Registers
065535
065535
065535
065535
065535
065535
065535
065535
Table – 4.4
The high 16 bit
values of the current
charging consumed
power.
The low 16 bit values
of the current
charging consumed
power.
The unit of power is
in Watt.
The high 16 bit
values of the current
charging consumed
energy.
The low 16 bit values
of the current
charging consumed
energy.
The unit of energy is
in Watt Hour.
The high 16 bit
values of Number of
seconds EV has been
charging
The low 16 bit values
of Number of
seconds EV has been
charging
The high 16 bit
values of Number of
seconds EV has been
connected
The low 16 bit values
of Number of
seconds EV has been
connected
The address offset for EVSE MODBUS Connection Table Diagnostics registers is defined as 0
(601 in decimal notation) in this version of MODBUS Register Map.
MODBUS Data Model: Input registers (Read only)
The Module ID for EVSE MODBUS Connection Table Diagnostics registers is defined as 0
Address
(hex)
Offset 601 MODBUS
Offset+1 602 MODBUS
MODBUS
Register
(dec)
data.
Parameter Data
Connection Table
Diagnostic
Register Validity
Connection Table
Diagnostic
Register Version
65535
065535
065535
Table – 4.5
Range
Indicate if the
0x1000 High byte ----
R
R
allow the user to view the EVSE MODBUS
Description Properties
R
MODBUS
Connection Table
Diagnostics
register is valid or
not.
0----Invalid
1----Valid
R
main version.
Low byte ---minor version.
The current
version of EVSE
MODBUS
Connection Table
Diagnostics
The instructions do not purport to cover all details or variations in equipment nor to provide for every
possible contingency to be met in connection with installation, operation or maintenance. Should
further information be desired or should particular problems arise which are not covered sufficiently
for the purchaser’s purposes, the matter should be referred to the GE Company.
GE Industrial Solutions
41 Woodford Ave.
Plainville, CT 06062
www.geindustrial.com
WattStationTM is a trademark of General Electric Company.
Information provided is subject to change without notice. Please verify all details with GE. All
Values are design or typical values when measured under laboratory conditions and GE makes
no warranty or guarantee, express or implied, that such performance will be obtained under enduse conditions.
DEH-41581A (4/12)
Loading...
+ hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.