ocpp websocket结构
在OCPP 1.6 WebSocket通信中,传输的数据具有固定的结构。每个消息都使用JSON格式,并且消息的结构是标准化的,以确保互操作性和一致性。具体来说,OCPP 1.6的消息结构包括以下几个部分:
消息类型编号(Message Type Id):
一个整数,表示消息的类型。OCPP 1.6定义了以下四种消息类型:
- 2:呼叫(Call)消息
- 3:呼叫结果(CallResult)消息
- 4:呼叫错误(CallError)消息
唯一标识符(Unique ID):
一个字符串,用于标识每个消息。呼叫消息和它的响应消息(呼叫结果或呼叫错误)使用相同的唯一标识符。
有效负载(Payload):
一个JSON对象,包含实际的数据。
具体来说,每种消息类型的结构如下:
1. 呼叫(Call)消息
用于客户端向服务器发送请求。结构如下:
[
2, // 消息类型编号,表示这是一个呼叫消息
"unique-id", // 唯一标识符
"Action", // 要执行的动作,如 "BootNotification", "Heartbeat" 等
{ // 有效负载,包含与动作相关的数据
"key": "value"
}
]
2. 呼叫结果(CallResult)消息
用于服务器对呼叫消息进行响应。结构如下:
[
3, // 消息类型编号,表示这是一个呼叫结果消息
"unique-id", // 唯一标识符,必须与呼叫消息的唯一标识符相同
{ // 有效负载,包含响应的数据
"key": "value"
}
]
3. 呼叫错误(CallError)消息
用于服务器对呼叫消息进行错误响应。结构如下:
[
4, // 消息类型编号,表示这是一个呼叫错误消息
"unique-id", // 唯一标识符,必须与呼叫消息的唯一标识符相同
"errorCode", // 错误代码,表示发生的错误类型
"errorDescription", // 错误描述,描述错误的详细信息
{ // 可选的详细错误信息,有效负载
"key": "value"
}
]
OCPP 1.6指令集
由充电桩发起的操作
Authorize
作用
Authorize
指令用于验证用户的身份标签(idTag),确保只有经过授权的用户可以开始或停止充电操作。在充电桩给电动汽车供电之前,必须先完成授权操作。
请求字段(Authorize.req)
- idTag:
string
(必需)- 描述: 用户的身份标签,用于进行授权验证。
- 例子:
"12345678"
响应字段(Authorize.conf)
- idTagInfo:
object
(必需)- 描述: 返回的身份标签信息,包含授权状态和相关信息。
- 结构:
- status:
string
(必需)- 描述: 授权状态
- 可能的值:
"Accepted"
: 身份标签被接受,可以开始充电。"Blocked"
: 身份标签被阻止,不允许充电。"Expired"
: 身份标签已过期,不允许充电。"Invalid"
: 身份标签未知,不允许充电。
- expiryDate:
string
(可选)- 描述: 身份标签的过期日期。
- parentIdTag:
string
(可选)- 描述: 父身份标签,用于关联多个身份标签。
示例
-
请求消息(Authorize.req):
{ "idTag": "12345678" }
-
响应消息(Authorize.conf):
{ "idTagInfo": { "status": "Accepted", "expiryDate": "2024-12-31T23:59:59.000Z", "parentIdTag": "87654321" } }
主要步骤
- 发送请求: 充电桩发送
Authorize.req
消息到中央系统,包含用户的身份标签。 - 处理请求: 中央系统接收请求并验证身份标签。
- 返回响应: 中央系统发送
Authorize.conf
消息回充电桩,指明身份标签的授权状态和相关信息。
注意事项
- 如果身份标签在本地授权列表或授权缓存中不存在,充电桩必须发送
Authorize.req
到中央系统。 - 如果身份标签存在于本地授权列表或授权缓存中,充电桩可以选择是否发送
Authorize.req
到中央系统。 - 充电桩可以实现授权缓存来维护之前成功授权的身份标签记录,以提高授权响应速度。
Boot Notification
作用
Boot Notification
指令用于在充电桩启动或重启后,向中央系统发送其配置信息(例如版本、厂商等)。中央系统通过响应来指示是否接受该充电桩。
请求字段(BootNotification.req)
- chargeBoxSerialNumber:
CiString25Type
(可选)- 描述: 标识充电桩内部充电盒的序列号。此字段已废弃,将在未来版本中移除。
- chargePointModel:
CiString20Type
(必需)- 描述: 标识充电桩的型号。
- chargePointSerialNumber:
CiString25Type
(可选)- 描述: 标识充电桩的序列号。
- chargePointVendor:
CiString20Type
(必需)- 描述: 标识充电桩的厂商。
- firmwareVersion:
CiString50Type
(可选)- 描述: 充电桩的固件版本。
- iccid:
CiString20Type
(可选)- 描述: 调制解调器SIM卡的ICCID。
- imsi:
CiString20Type
(可选)- 描述: 调制解调器SIM卡的IMSI。
- meterSerialNumber:
CiString25Type
(可选)- 描述: 充电桩主要电表的序列号。
- meterType:
CiString25Type
(可选)- 描述: 充电桩主要电表的类型。
响应字段(BootNotification.conf)
- currentTime:
dateTime
(必需)- 描述: 中央系统的当前时间。
- interval:
integer
(必需)- 描述: 当注册状态为Accepted时,该字段包含心跳间隔(以秒为单位)。如果中央系统返回的状态不是Accepted,该字段值表示发送下一个BootNotification请求之前的最小等待时间。
- status:
RegistrationStatus
(必需)- 描述: 标识充电桩是否已在中央系统内注册。可能的值包括:
"Accepted"
: 充电桩已被接受。"Pending"
: 充电桩注册状态待定。"Rejected"
: 充电桩被拒绝。
示例
-
请求消息(BootNotification.req):
{ "chargePointModel": "SingleSocketCharger", "chargePointVendor": "VendorX" }
-
响应消息(BootNotification.conf):
{ "currentTime": "2024-05-23T12:00:00Z", "interval": 300, "status": "Accepted" }
主要步骤
- 发送请求: 充电桩在启动或重启后发送
BootNotification.req
消息到中央系统,包含充电桩的配置信息。 - 处理请求: 中央系统接收请求并验证充电桩的信息。
- 返回响应: 中央系统发送
BootNotification.conf
消息回充电桩,指明充电桩的注册状态和心跳间隔等信息。
注意事项
- 充电桩每次启动或重启后都必须发送
BootNotification.req
请求。 - 在收到中央系统返回的状态为Accepted或Pending之前,充电桩不得发送任何其他请求。
- 如果中央系统返回Rejected状态,充电桩必须等待指定的间隔时间后再发送下一个BootNotification请求。
Data Transfer
作用
Data Transfer
指令用于在充电桩和中央系统之间传输非标准OCPP功能的信息。此指令可以在充电桩需要向中央系统发送自定义信息时使用,反之亦然。
请求字段(DataTransfer.req)
- vendorId:
string
(必需)- 描述: 标识供应商ID,应该唯一标识供应商实现。
- 例子:
"com.example.vendor"
- messageId:
string
(可选)- 描述: 指定特定消息或实现。
- 例子:
"customMessage"
- data:
string
(可选)- 描述: 传输的数据,格式和内容由供应商定义。
- 例子:
"additional information"
响应字段(DataTransfer.conf)
- status:
string
(必需)- 描述: 数据传输的状态。
- 可能的值:
"Accepted"
: 数据传输成功。"Rejected"
: 数据传输失败。"UnknownVendorId"
: 未知的供应商ID。"UnknownMessageId"
: 未知的消息ID。
- data:
string
(可选)- 描述: 由中央系统返回的数据,格式和内容由供应商定义。
示例
-
请求消息(DataTransfer.req):
{ "vendorId": "com.example.vendor", "messageId": "customMessage", "data": "additional information" }
-
响应消息(DataTransfer.conf):
{ "status": "Accepted", "data": "response information" }
主要步骤
- 发送请求: 充电桩或中央系统发送
DataTransfer.req
消息,包含供应商ID和可选的消息ID和数据。 - 处理请求: 接收方(中央系统或充电桩)处理请求并执行相应操作。
- 返回响应: 接收方发送
DataTransfer.conf
消息,指明数据传输的状态和可选的返回数据。
注意事项
vendorId
应唯一标识供应商,实现通常使用反向DNS命名空间。- 如果接收方不支持指定的
vendorId
或messageId
,应返回相应的状态(UnknownVendorId
或UnknownMessageId
)。 data
字段的格式和内容需要由供应商双方协商一致。
Diagnostics Status Notification
作用
Diagnostics Status Notification
指令用于充电桩向中央系统通知诊断上传的状态。充电桩发送此消息来告知中央系统诊断文件的上传状态,包括上传中、上传成功或失败。
请求字段(DiagnosticsStatusNotification.req)
- status:
string
(必需)- 描述: 诊断上传的状态。
- 可能的值:
"Idle"
: 诊断上传未进行。"Uploaded"
: 诊断文件上传成功。"UploadFailed"
: 诊断文件上传失败。"Uploading"
: 诊断文件正在上传。
响应字段(DiagnosticsStatusNotification.conf)
此响应消息没有定义字段,仅用于确认接收到请求。
示例
-
请求消息(DiagnosticsStatusNotification.req):
{ "status": "Uploading" }
-
响应消息(DiagnosticsStatusNotification.conf):
{}
主要步骤
- 发送请求: 充电桩在诊断文件上传过程中,发送
DiagnosticsStatusNotification.req
消息到中央系统,包含当前的上传状态。 - 处理请求: 中央系统接收并处理请求消息。
- 返回响应: 中央系统发送空的
DiagnosticsStatusNotification.conf
消息回充电桩,确认收到状态通知。
注意事项
- 充电桩应在诊断文件上传的不同阶段发送相应的状态通知,包括开始上传、上传成功和上传失败等状态。
- 如果诊断文件上传未进行,则充电桩应发送状态为
Idle
的通知。
Firmware Status Notification
作用
Firmware Status Notification
指令用于充电桩向中央系统通知固件更新的状态。充电桩在下载和安装固件更新的过程中,会发送此消息以更新中央系统有关更新进度的信息。
请求字段(FirmwareStatusNotification.req)
- status:
string
(必需)- 描述: 固件更新的状态。
- 可能的值:
"Downloading"
: 固件正在下载。"Downloaded"
: 固件下载完成。"Installing"
: 固件正在安装。"Installed"
: 固件安装完成。"InstallationFailed"
: 固件安装失败。"Idle"
: 充电桩未在下载或安装固件。
响应字段(FirmwareStatusNotification.conf)
此响应消息没有定义字段,仅用于确认接收到请求。
示例
-
请求消息(FirmwareStatusNotification.req):
{ "status": "Installing" }
-
响应消息(FirmwareStatusNotification.conf):
{}
主要步骤
- 发送请求: 充电桩在固件下载或安装过程中,发送
FirmwareStatusNotification.req
消息到中央系统,包含当前的固件更新状态。 - 处理请求: 中央系统接收并处理请求消息。
- 返回响应: 中央系统发送空的
FirmwareStatusNotification.conf
消息回充电桩,确认收到状态通知。
注意事项
- 充电桩应在固件下载和安装的不同阶段发送相应的状态通知,包括开始下载、下载完成、开始安装、安装完成和安装失败等状态。
- 在固件更新过程中,充电桩应根据固件更新的进度及时发送状态通知,以确保中央系统能实时掌握更新状态。
Heartbeat
作用
Heartbeat
指令用于让中央系统知道充电桩仍然连接。充电桩在可配置的时间间隔后发送心跳信号,以确保中央系统知道充电桩的在线状态。
请求字段(Heartbeat.req)
此请求消息没有定义字段,仅用于发送心跳信号。
响应字段(Heartbeat.conf)
- currentTime:
dateTime
(必需)- 描述: 中央系统的当前时间,用于充电桩同步其内部时钟。
示例
-
请求消息(Heartbeat.req):
{}
-
响应消息(Heartbeat.conf):
{ "currentTime": "2024-05-23T12:00:00Z" }
主要步骤
- 发送请求: 充电桩发送
Heartbeat.req
消息到中央系统,告知其仍然在线。 - 处理请求: 中央系统接收并处理请求消息。
- 返回响应: 中央系统发送
Heartbeat.conf
消息回充电桩,提供当前时间信息。
注意事项
- 充电桩应在配置的时间间隔后发送心跳信号,以确保中央系统知道其在线状态。
- 如果在配置的心跳间隔内已经发送了其他消息,充电桩可以跳过发送心跳信号。
- 建议每天至少发送一次心跳信号以进行时间同步。
Meter Values
作用
Meter Values
指令用于充电桩向中央系统发送电表读数或其他传感器数据。充电桩可以根据配置的时间间隔和指定的测量数据发送此消息,以提供充电会话的进度和状态信息。
请求字段(MeterValues.req)
- connectorId:
integer
(必需)- 描述: 指定从哪个连接器获取的样本。如果connectorId为0,则表示整个充电桩。
- 例子:
1
- transactionId:
integer
(可选)- 描述: 与这些电表读数相关的交易ID。如果没有正在进行的交易或读数来自主电表,则可以省略该字段。
- 例子:
12345
-
meterValue(必选):包含一个或多个测量值的列表,每个测量值包含以下字段:
-
timestamp(必选):测量的时间戳,ISO 8601格式。
-
sampledValue(必选):测量值列表,每个测量值包含以下字段:
- value(必选):实际的测量值。字符串类型。
- context(可选):测量的上下文。取值为Interruption.Begin、Interruption.End、Sample.Clock、Sample.Periodic、Transaction.Begin、Transaction.End、Trigger。
- format(可选):测量值的格式。取值为Raw或SignedData。
- measurand(可选):测量的物理量。取值为Energy.Active.Import.Register、Energy.Active.Export.Register、Energy.Reactive.Import.Register、Energy.Reactive.Export.Register、Power.Active.Import、Power.Active.Export、Power.Reactive.Import、Power.Reactive.Export、Voltage、Current.Import、Current.Export、Frequency、Temperature。
- phase(可选):测量所在的相位。取值为L1、L2、L3、N。
- location(可选):测量的位置。取值为Cable、EV、Inlet、Outlet。
- unit(可选):测量值的单位。取值为Wh、kWh、varh、kvarh、W、kW、var、kvar、A、V、K、Celsius。
-
例子:
[ { "timestamp": "2024-05-23T12:00:00Z", "sampledValue": [ { "value": "20.5", "context": "Sample.Periodic", "format": "Raw", "measurand": "Energy.Active.Import.Register", "unit": "kWh" } ] } ]
-
响应字段(MeterValues.conf)
此响应消息没有定义字段,仅用于确认接收到请求。
示例
-
请求消息(MeterValues.req):
{ "connectorId": 1, "meterValue": [ { "timestamp": "2024-05-23T12:00:00Z", "sampledValue": [ { "value": "20.5", "context": "Sample.Periodic", "format": "Raw", "measurand": "Energy.Active.Import.Register", "unit": "kWh" } ] } ] }
-
响应消息(MeterValues.conf):
{}
主要步骤
- 发送请求: 充电桩根据配置的时间间隔和指定的测量数据发送
MeterValues.req
消息到中央系统。 - 处理请求: 中央系统接收并处理请求消息。
- 返回响应: 中央系统发送空的
MeterValues.conf
消息回充电桩,确认收到电表读数数据。
注意事项
- 充电桩应根据配置的时间间隔定期发送电表读数,以提供充电会话的进度和状态信息。
- 如果测量值是与交易相关的,充电桩应包括transactionId字段。
meterValue
字段包含的每个sampledValue
元素应包括时间戳和相关的测量数据。
Start Transaction
作用
Start Transaction
指令用于充电桩向中央系统通知充电事务的开始。该消息包含开始事务的相关信息,例如连接器ID、用户ID标签、电表起始值等。
请求字段(StartTransaction.req)
- connectorId:
integer
(必需)- 描述: 指定哪个连接器开始了事务。
- 例子:
1
- idTag:
string
(必需)- 描述: 用户的身份标签,用于标识启动事务的用户。
- 例子:
"12345678"
- meterStart:
integer
(必需)- 描述: 事务开始时电表的读数,以瓦特小时(Wh)为单位。
- 例子:
0
- timestamp:
string
(必需)- 描述: 事务开始的时间戳。
- 例子:
"2024-05-23T12:00:00Z"
- reservationId:
integer
(可选)- 描述: 如果事务结束了一个预约,则包含该预约的ID。
- 例子:
12345
响应字段(StartTransaction.conf)
- idTagInfo:
object
(必需)- 描述: 身份标签信息,包含授权状态和相关信息。
- 结构:
- status:
string
(必需)- 描述: 授权状态。
- 可能的值:
"Accepted"
: 身份标签被接受,可以开始事务。"Blocked"
: 身份标签被阻止,不允许开始事务。"Expired"
: 身份标签已过期,不允许开始事务。"Invalid"
: 身份标签未知,不允许开始事务。
- expiryDate:
string
(可选)- 描述: 身份标签的过期日期。
- parentIdTag:
string
(可选)- 描述: 父身份标签,用于关联多个身份标签。
- transactionId:
integer
(必需)- 描述: 中央系统生成的事务ID。
- 例子:
67890
示例
-
请求消息(StartTransaction.req):
{ "connectorId": 1, "idTag": "12345678", "meterStart": 0, "timestamp": "2024-05-23T12:00:00Z" }
-
响应消息(StartTransaction.conf):
{ "idTagInfo": { "status": "Accepted", "expiryDate": "2024-12-31T23:59:59.000Z", "parentIdTag": "87654321" }, "transactionId": 67890 }
主要步骤
- 发送请求: 充电桩发送
StartTransaction.req
消息到中央系统,包含开始事务的相关信息。 - 处理请求: 中央系统接收请求并验证身份标签。
- 返回响应: 中央系统发送
StartTransaction.conf
消息回充电桩,指明事务ID和授权状态。
注意事项
- 中央系统必须验证
StartTransaction.req
中的身份标签,以确保标签有效。 - 如果充电桩实现了授权缓存,则在收到
StartTransaction.conf
后,应更新缓存条目。 - 事务相关的消息应尽快按时间顺序发送,以确保事务信息的准确性。
Status Notification
作用
Status Notification
指令用于充电桩向中央系统通知状态变化或错误。充电桩发送此消息来更新中央系统关于连接器或充电桩主控制器的当前状态。
请求字段(StatusNotification.req)
- connectorId:
integer
(必需)- 描述: 报告状态的连接器的ID。如果状态是针对充电桩主控制器,则ID为'0'。
- 例子:
1
- errorCode:
string
(必需)- 描述: 充电桩报告的错误代码。
- 可能的值:
"ConnectorLockFailure"
"EVCommunicationError"
"GroundFailure"
"HighTemperature"
"InternalError"
"LocalListConflict"
"NoError"
"OtherError"
"OverCurrentFailure"
"OverVoltage"
"PowerMeterFailure"
"PowerSwitchFailure"
"ReaderFailure"
"ResetFailure"
"UnderVoltage"
"WeakSignal"
- 例子:
"NoError"
- info:
string
(可选)- 描述: 与错误相关的额外信息。
- 例子:
"EV disconnected unexpectedly"
- status:
string
(必需)- 描述: 充电桩的当前状态。
- 可能的值:
"Available"
"Preparing"
"Charging"
"SuspendedEV"
"SuspendedEVSE"
"Finishing"
"Reserved"
"Unavailable"
"Faulted"
- 例子:
"Charging"
- timestamp:
string
(可选)- 描述: 报告状态的时间戳。如果没有提供,则假定为消息接收时间。
- 例子:
"2024-05-23T12:00:00Z"
- vendorId:
string
(可选)- 描述: 标识供应商特定实现的ID。
- 例子:
"com.example.vendor"
- vendorErrorCode:
string
(可选)- 描述: 供应商特定的错误代码。
- 例子:
"VendorSpecificError"
响应字段(StatusNotification.conf)
此响应消息没有定义字段,仅用于确认接收到请求。
示例
-
请求消息(StatusNotification.req):
{ "connectorId": 1, "errorCode": "NoError", "status": "Charging", "timestamp": "2024-05-23T12:00:00Z" }
-
响应消息(StatusNotification.conf):
{}
主要步骤
- 发送请求: 充电桩在状态变化或错误发生时发送
StatusNotification.req
消息到中央系统,包含当前的状态和错误信息。 - 处理请求: 中央系统接收并处理请求消息。
- 返回响应: 中央系统发送空的
StatusNotification.conf
消息回充电桩,确认收到状态通知。
注意事项
- 充电桩应在状态变化或检测到错误时及时发送状态通知,以确保中央系统能够实时掌握充电桩的运行状态。
- 充电桩在启动或重启后,应发送初始状态的通知,以更新中央系统关于其当前状态的信息。
Stop Transaction
作用
Stop Transaction
指令用于充电桩向中央系统通知充电事务的结束。该消息包含结束事务的相关信息,例如连接器ID、用户ID标签、电表终止值等。
请求字段(StopTransaction.req)
- idTag:
string
(可选)- 描述: 请求停止充电的用户的身份标签。如果充电桩可以在没有身份标签的情况下终止充电(例如重置的情况),此字段可以省略。
- 例子:
"12345678"
- meterStop:
integer
(必需)- 描述: 事务结束时电表的读数,以瓦特小时(Wh)为单位。
- 例子:
1000
- timestamp:
string
(必需)- 描述: 事务结束的时间戳。
- 例子:
"2024-05-23T12:00:00Z"
- transactionId:
integer
(必需)- 描述: 在
StartTransaction.conf
中接收到的事务ID。 - 例子:
67890
- 描述: 在
- reason:
string
(可选)- 描述: 事务结束的原因。
- 可能的值:
"EmergencyStop"
: 紧急停止"EVDisconnected"
: 电动汽车断开连接"HardReset"
: 硬重置"Local"
: 本地停止"Other"
: 其他"PowerLoss"
: 断电"Reboot"
: 重启"Remote"
: 远程停止"SoftReset"
: 软重置- 例子:
"Local"
- transactionData:
MeterValue[]
(可选)- 描述: 事务使用的详细信息,与计费相关。可以包含任意数量的MeterValue元素,使用与
MeterValues.req
相同的数据结构。
- 描述: 事务使用的详细信息,与计费相关。可以包含任意数量的MeterValue元素,使用与
响应字段(StopTransaction.conf)
- idTagInfo:
object
(可选)- 描述: 身份标签信息,包含授权状态和相关信息。
- 结构:
- status:
string
(必需)- 描述: 授权状态。
- 可能的值:
"Accepted"
: 身份标签被接受,可以开始事务。"Blocked"
: 身份标签被阻止,不允许开始事务。"Expired"
: 身份标签已过期,不允许开始事务。"Invalid"
: 身份标签未知,不允许开始事务。
- expiryDate:
string
(可选)- 描述: 身份标签的过期日期。
- parentIdTag:
string
(可选)- 描述: 父身份标签,用于关联多个身份标签。
示例
-
请求消息(StopTransaction.req):
{ "transactionId": 67890, "meterStop": 1000, "timestamp": "2024-05-23T12:00:00Z", "reason": "Local" }
-
响应消息(StopTransaction.conf):
{ "idTagInfo": { "status": "Accepted", "expiryDate": "2024-12-31T23:59:59.000Z", "parentIdTag": "87654321" } }
主要步骤
- 发送请求: 充电桩发送
StopTransaction.req
消息到中央系统,包含结束事务的相关信息。 - 处理请求: 中央系统接收请求并验证身份标签(如果提供)。
- 返回响应: 中央系统发送
StopTransaction.conf
消息回充电桩,指明身份标签的授权状态(如果提供)和事务结束的确认。
注意事项
- 在正常情况下,充电桩应在事务结束时发送
StopTransaction.req
消息。 - 如果事务结束的原因是由于错误或异常情况(例如断电、重置),充电桩应在
reason
字段中指明具体原因。 - 充电桩应确保事务相关的消息按时间顺序发送,以确保事务信息的准确性。
由中央系统发起的操作
Cancel Reservation
作用
Cancel Reservation
指令用于中央系统通知充电桩取消一个现有的预约。如果充电桩存在与请求中的reservationId
匹配的预约,则会取消该预约并返回状态。
请求字段(CancelReservation.req)
- reservationId:
integer
(必需)- 描述: 要取消的预约的ID。
- 例子:
12345
响应字段(CancelReservation.conf)
- status:
string
(必需)- 描述: 预约取消操作的结果。
- 可能的值:
"Accepted"
: 预约已成功取消。"Rejected"
: 预约取消失败,因为没有与reservationId
匹配的预约。
示例
-
请求消息(CancelReservation.req):
{ "reservationId": 12345 }
-
响应消息(CancelReservation.conf):
{ "status": "Accepted" }
主要步骤
- 发送请求: 中央系统发送
CancelReservation.req
消息到充电桩,包含要取消的预约ID。 - 处理请求: 充电桩接收请求并检查是否存在匹配的预约。
- 返回响应: 充电桩发送
CancelReservation.conf
消息回中央系统,指明预约取消的结果。
注意事项
- 如果预约ID不存在,充电桩应返回
Rejected
状态。 - 预约被成功取消后,充电桩应释放被预约占用的连接器资源。
Change Availability
作用
Change Availability
指令用于中央系统请求充电桩改变其可用性状态。充电桩可以根据请求更改为可用或不可用状态。
请求字段(ChangeAvailability.req)
- connectorId:
integer
(必需)- 描述: 指定要改变可用性状态的连接器ID。如果为
0
,则表示整个充电桩。 - 例子:
1
- 描述: 指定要改变可用性状态的连接器ID。如果为
- type:
string
(必需)- 描述: 请求的可用性变化类型。
- 可能的值:
"Inoperative"
: 充电桩不可用。"Operative"
: 充电桩可用。- 例子:
"Operative"
响应字段(ChangeAvailability.conf)
- status:
string
(必需)- 描述: 指示充电桩是否能够执行可用性变化。
- 可能的值:
"Accepted"
: 请求已被接受并将执行。"Rejected"
: 请求未被接受,不会执行。"Scheduled"
: 请求已被接受并将在当前事务完成后执行。
示例
-
请求消息(ChangeAvailability.req):
{ "connectorId": 1, "type": "Operative" }
-
响应消息(ChangeAvailability.conf):
{ "status": "Accepted" }
主要步骤
- 发送请求: 中央系统发送
ChangeAvailability.req
消息到充电桩,包含要改变的连接器ID和可用性类型。 - 处理请求: 充电桩接收请求并尝试更改其可用性状态。
- 返回响应: 充电桩发送
ChangeAvailability.conf
消息回中央系统,指明可用性变化的结果。
注意事项
- 如果充电桩在当前事务完成之前无法更改状态,应返回
Scheduled
状态。 - 充电桩应在重新启动时保留其不可用状态。
Change Configuration
作用
Change Configuration
指令用于中央系统请求充电桩更改其配置参数。中央系统可以发送一个键值对,其中“键”是要更改的配置设置的名称,“值”包含配置设置的新值。
请求字段(ChangeConfiguration.req)
- key:
CiString50Type
(必需)- 描述: 要更改的配置设置的名称。
- 例子:
"HeartbeatInterval"
- value:
CiString500Type
(必需)- 描述: 配置设置的新值。
- 例子:
"600"
响应字段(ChangeConfiguration.conf)
- status:
string
(必需)- 描述: 表示充电桩是否能够应用配置更改。
- 可能的值:
"Accepted"
: 更改已成功应用。"RebootRequired"
: 更改已成功应用,但需要重启才能生效。"NotSupported"
:key
不对应于充电桩支持的配置设置。"Rejected"
: 充电桩未设置配置,且不符合前述状态的条件。
示例
-
请求消息(ChangeConfiguration.req):
{ "key": "HeartbeatInterval", "value": "600" }
-
响应消息(ChangeConfiguration.conf):
{ "status": "Accepted" }
主要步骤
- 发送请求: 中央系统发送
ChangeConfiguration.req
消息到充电桩,包含要更改的配置键值对。 - 处理请求: 充电桩接收请求并尝试应用配置更改。
- 返回响应: 充电桩发送
ChangeConfiguration.conf
消息回中央系统,指明配置更改的结果。
注意事项
- 如果请求中的
key
不对应于充电桩支持的配置设置,充电桩应返回NotSupported
状态。 - 如果需要重启才能使更改生效,充电桩应返回
RebootRequired
状态。 - 充电桩应在可能的情况下尽量立即应用配置更改,以减少需要重启的次数。
Clear Cache
作用
Clear Cache
指令用于中央系统请求充电桩清除其授权缓存。如果充电桩实现了授权缓存,则会清除缓存并返回状态。
请求字段(ClearCache.req)
此请求消息没有定义字段,仅用于发送清除缓存的请求。
响应字段(ClearCache.conf)
- status:
string
(必需)- 描述: 指示充电桩是否能够清除其授权缓存。
- 可能的值:
"Accepted"
: 缓存已成功清除。"Rejected"
: 缓存清除失败。
示例
-
请求消息(ClearCache.req):
{}
-
响应消息(ClearCache.conf):
{ "status": "Accepted" }
主要步骤
- 发送请求: 中央系统发送
ClearCache.req
消息到充电桩,要求清除其授权缓存。 - 处理请求: 充电桩接收请求并尝试清除其授权缓存。
- 返回响应: 充电桩发送
ClearCache.conf
消息回中央系统,指明缓存清除的结果。
注意事项
- 如果充电桩未实现授权缓存,当收到
ClearCache.req
消息时,应返回Rejected
状态。 - 清除授权缓存后,充电桩应重新请求所有必要的授权信息,以确保正常操作。
Clear Charging Profile
作用
Clear Charging Profile
指令用于中央系统请求充电桩清除其充电配置文件。中央系统可以通过此消息清除一个特定的充电配置文件或一组匹配指定条件的配置文件。
请求字段(ClearChargingProfile.req)
- id:
integer
(可选)- 描述: 要清除的充电配置文件的ID。
- 例子:
12345
- connectorId:
integer
(可选)- 描述: 要清除充电配置文件的连接器ID。ID为0表示清除整个充电桩的配置文件。如果未指定此参数,则清除所有匹配其他条件的充电配置文件。
- 例子:
1
- chargingProfilePurpose:
string
(可选)- 描述: 要清除的充电配置文件的用途。
- 可能的值:
"ChargePointMaxProfile"
: 充电桩的最大充电配置文件。"TxDefaultProfile"
: 默认事务配置文件。"TxProfile"
: 事务配置文件。- 例子:
"TxProfile"
- stackLevel:
integer
(可选)- 描述: 要清除充电配置文件的堆栈级别。
- 例子:
2
响应字段(ClearChargingProfile.conf)
- status:
string
(必需)- 描述: 指示充电桩是否能够执行充电配置文件清除操作。
- 可能的值:
"Accepted"
: 请求已被接受并将执行。"Unknown"
: 充电桩无法找到匹配的充电配置文件。
示例
-
请求消息(ClearChargingProfile.req):
{ "id": 12345, "connectorId": 1, "chargingProfilePurpose": "TxProfile", "stackLevel": 2 }
-
响应消息(ClearChargingProfile.conf):
{ "status": "Accepted" }
主要步骤
- 发送请求: 中央系统发送
ClearChargingProfile.req
消息到充电桩,包含要清除的充电配置文件的相关信息。 - 处理请求: 充电桩接收请求并尝试清除匹配的充电配置文件。
- 返回响应: 充电桩发送
ClearChargingProfile.conf
消息回中央系统,指明清除操作的结果。
注意事项
- 如果请求中的字段都为空,充电桩应清除所有充电配置文件。
- 如果指定了
id
字段,其他字段将被忽略。 - 充电桩应根据提供的条件匹配并清除相应的充电配置文件。
Data Transfer
同充电桩的 Data Transfer 用于传输非OCPP内容
Get Composite Schedule
作用
Get Composite Schedule
指令用于中央系统请求充电桩报告综合充电计划。该计划是充电桩计算所有活动计划和可能存在的本地限制后的结果。
请求字段(GetCompositeSchedule.req)
- connectorId:
integer
(必需)- 描述: 请求充电计划的连接器ID。如果为
0
,充电桩将报告整个充电桩的预计功率或电流消耗。 - 例子:
1
- 描述: 请求充电计划的连接器ID。如果为
- duration:
integer
(必需)- 描述: 请求的计划时长,以秒为单位。
- 例子:
3600
- chargingRateUnit:
string
(可选)- 描述: 可用于指定功率或电流配置文件。
- 可能的值:
"W"
: 瓦特"A"
: 安培- 例子:
"W"
响应字段(GetCompositeSchedule.conf)
- status:
string
(必需)- 描述: 请求的状态。充电桩将指示是否能够处理请求。
- 可能的值:
"Accepted"
: 请求已被接受并将执行。"Rejected"
: 请求未被接受,不会执行。
- connectorId:
integer
(可选)- 描述: 充电计划适用于的连接器ID。
- 例子:
1
- scheduleStart:
string
(可选)- 描述: 计划的开始时间。
- 例子:
"2024-05-23T12:00:00Z"
- chargingSchedule:
object
(可选)- 描述: 计划的充电时间表,表示一段时间内的能耗。
- 结构:
- duration:
integer
(可选)- 描述: 充电计划的时长,以秒为单位。
- 例子:
3600
- startSchedule:
string
(可选)- 描述: 计划的开始时间。
- 例子:
"2024-05-23T12:00:00Z"
- chargingRateUnit:
string
(必需)- 描述: 限制值的计量单位。
- 可能的值:
"W"
: 瓦特"A"
: 安培- 例子:
"W"
- chargingSchedulePeriod:
array
(必需)- 描述: 定义最大功率或电流使用的时间段列表。
- 例子:
[ { "startPeriod": 0, "limit": 32.0 } ]
- minChargingRate:
decimal
(可选)- 描述: 电动汽车支持的最小充电速率。
- 例子:
8.1
示例
-
请求消息(GetCompositeSchedule.req):
{ "connectorId": 1, "duration": 3600, "chargingRateUnit": "W" }
-
响应消息(GetCompositeSchedule.conf):
{ "status": "Accepted", "connectorId": 1, "scheduleStart": "2024-05-23T12:00:00Z", "chargingSchedule": { "duration": 3600, "startSchedule": "2024-05-23T12:00:00Z", "chargingRateUnit": "W", "chargingSchedulePeriod": [ { "startPeriod": 0, "limit": 32.0 } ], "minChargingRate": 8.1 } }
主要步骤
- 发送请求: 中央系统发送
GetCompositeSchedule.req
消息到充电桩,包含请求的连接器ID和计划时长等信息。 - 处理请求: 充电桩接收请求并计算综合充电计划。
- 返回响应: 充电桩发送
GetCompositeSchedule.conf
消息回中央系统,提供计算的充电计划信息。
注意事项
- 如果请求中的
connectorId
为0
,充电桩将报告整个充电桩的预计功率或电流消耗。 - 如果充电桩无法处理请求,应返回
Rejected
状态。 chargingSchedule
中的各字段应根据具体实现和配置情况填写。
Get Configuration
作用
Get Configuration
指令用于中央系统请求充电桩报告其配置参数的值。中央系统可以通过此消息获取充电桩当前的配置设置。
请求字段(GetConfiguration.req)
- key:
CiString50Type
(可选)- 描述: 要获取其配置值的配置键的列表。如果未提供此字段,充电桩将返回所有配置设置。
- 例子:
["HeartbeatInterval", "MeterValueSampleInterval"]
响应字段(GetConfiguration.conf)
- configurationKey:
array
(可选)- 描述: 包含请求的配置键及其对应值的列表。
- 例子:
[ { "key": "HeartbeatInterval", "readonly": false, "value": "300" }, { "key": "MeterValueSampleInterval", "readonly": true, "value": "900" } ]
- unknownKey:
array
(可选)- 描述: 包含充电桩未识别的请求配置键的列表。
- 例子:
["UnknownKey1", "UnknownKey2"]
示例
-
请求消息(GetConfiguration.req):
{ "key": ["HeartbeatInterval", "MeterValueSampleInterval"] }
-
响应消息(GetConfiguration.conf):
{ "configurationKey": [ { "key": "HeartbeatInterval", "readonly": false, "value": "300" }, { "key": "MeterValueSampleInterval", "readonly": true, "value": "900" } ], "unknownKey": ["UnknownKey1", "UnknownKey2"] }
主要步骤
- 发送请求: 中央系统发送
GetConfiguration.req
消息到充电桩,包含要获取配置值的键列表。 - 处理请求: 充电桩接收请求并检索请求的配置值。
- 返回响应: 充电桩发送
GetConfiguration.conf
消息回中央系统,提供配置值和未识别的键(如果有)。
注意事项
- 如果请求中的
key
字段为空或缺失,充电桩应返回所有配置设置。 configurationKey
中的每个元素应包含配置键、其只读状态和当前值。- 对于未识别的配置键,充电桩应在
unknownKey
字段中返回。
Get Diagnostics
作用
Get Diagnostics
指令用于中央系统请求充电桩上传其诊断信息。中央系统通过此消息指定诊断文件应上传的位置,并可选择性地指定所需的诊断信息的开始和结束时间。
请求字段(GetDiagnostics.req)
- location:
anyURI
(必需)- 描述: 指定诊断文件应上传到的位置(目录)。
- 例子:
"https://example.com/diagnostics"
- retries:
integer
(可选)- 描述: 指定充电桩在放弃前应尝试上传诊断文件的次数。如果未提供此字段,则由充电桩决定重试次数。
- 例子:
3
- retryInterval:
integer
(可选)- 描述: 尝试上传诊断文件之间的时间间隔,以秒为单位。
- 例子:
60
- startTime:
string
(可选)- 描述: 包含所请求诊断信息的最早时间的日期和时间。
- 例子:
"2024-05-23T00:00:00Z"
- stopTime:
string
(可选)- 描述: 包含所请求诊断信息的最晚时间的日期和时间。
- 例子:
"2024-05-23T23:59:59Z"
响应字段(GetDiagnostics.conf)
- fileName:
CiString255Type
(可选)- 描述: 包含诊断信息的文件名。如果没有可用的诊断文件,则不包含此字段。
- 例子:
"diagnostics_2024_05_23.log"
示例
-
请求消息(GetDiagnostics.req):
{ "location": "https://example.com/diagnostics", "retries": 3, "retryInterval": 60, "startTime": "2024-05-23T00:00:00Z", "stopTime": "2024-05-23T23:59:59Z" }
-
响应消息(GetDiagnostics.conf):
{ "fileName": "diagnostics_2024_05_23.log" }
主要步骤
- 发送请求: 中央系统发送
GetDiagnostics.req
消息到充电桩,包含文件上传位置和可选的重试参数和时间范围。 - 处理请求: 充电桩接收请求并生成诊断文件。
- 返回响应: 充电桩发送
GetDiagnostics.conf
消息回中央系统,提供诊断文件的名称(如果有)。 - 上传文件: 充电桩将诊断文件上传到指定位置,并通过
DiagnosticsStatusNotification
消息通知上传状态。
注意事项
- 如果未提供重试参数,充电桩将根据其内部逻辑决定重试次数和间隔。
- 如果指定的时间范围内没有可用的诊断信息,充电桩应返回
GetDiagnostics.conf
消息且不包含fileName
字段。
Get Local List Version
作用
Get Local List Version
指令用于中央系统请求充电桩报告本地授权列表的版本号。该版本号用于同步中央系统和充电桩之间的本地授权列表。
请求字段(GetLocalListVersion.req)
此请求消息没有定义字段,仅用于发送获取版本号的请求。
响应字段(GetLocalListVersion.conf)
- listVersion:
integer
(必需)- 描述: 本地授权列表的版本号。0表示列表为空,-1表示充电桩不支持本地授权列表。
- 例子:
123
示例
-
请求消息(GetLocalListVersion.req):
{}
-
响应消息(GetLocalListVersion.conf):
{ "listVersion": 123 }
主要步骤
- 发送请求: 中央系统发送
GetLocalListVersion.req
消息到充电桩,要求获取本地授权列表的版本号。 - 处理请求: 充电桩接收请求并返回当前本地授权列表的版本号。
- 返回响应: 充电桩发送
GetLocalListVersion.conf
消息回中央系统,提供本地授权列表的版本号。
注意事项
- 版本号为0表示本地授权列表为空。
- 版本号为-1表示充电桩不支持本地授权列表。
Remote Start Transaction
作用
Remote Start Transaction
指令用于中央系统请求充电桩远程启动一个充电事务。该指令可以帮助操作员远程启动事务,例如通过移动应用程序或短信控制充电事务。
请求字段(RemoteStartTransaction.req)
- connectorId:
integer
(可选)- 描述: 要启动事务的连接器ID。如果未提供连接器ID,充电桩将自行选择连接器。
- 例子:
1
- idTag:
string
(必需)- 描述: 用于启动事务的身份标签。
- 例子:
"12345678"
- chargingProfile:
object
(可选)- 描述: 充电配置文件,用于指定充电事务的详细充电参数。
- 结构:
- chargingProfileId:
integer
(可选)- 描述: 充电配置文件的唯一标识符。
- stackLevel:
integer
(必需)- 描述: 充电配置文件的堆栈级别。
- chargingProfilePurpose:
string
(必需)- 描述: 充电配置文件的用途。
- 可能的值:
"ChargePointMaxProfile"
: 充电桩的最大充电配置文件。"TxDefaultProfile"
: 默认事务配置文件。"TxProfile"
: 事务配置文件。
- chargingProfileKind:
string
(必需)- 描述: 充电配置文件的种类。
- 可能的值:
"Absolute"
: 绝对值。"Recurring"
: 循环。"Relative"
: 相对值。
- recurrencyKind:
string
(可选)- 描述: 循环类型。
- 可能的值:
"Daily"
: 每日。"Weekly"
: 每周。
- validFrom:
string
(可选)- 描述: 充电配置文件的生效开始时间。
- 例子:
"2024-05-23T12:00:00Z"
- validTo:
string
(可选)- 描述: 充电配置文件的生效结束时间。
- 例子:
"2024-12-31T23:59:59.000Z"
- chargingSchedule:
array
(必需)- 描述: 充电时间表列表。
- 例子:
[ { "duration": 3600, "startSchedule": "2024-05-23T12:00:00Z", "chargingRateUnit": "W", "chargingSchedulePeriod": [ { "startPeriod": 0, "limit": 32.0 } ], "minChargingRate": 8.1 } ]
响应字段(RemoteStartTransaction.conf)
- status:
string
(必需)- 描述: 指示充电桩是否接受启动事务请求。
- 可能的值:
"Accepted"
: 请求已被接受并将执行。"Rejected"
: 请求未被接受,不会执行。
示例
-
请求消息(RemoteStartTransaction.req):
{ "connectorId": 1, "idTag": "12345678", "chargingProfile": { "chargingProfileId": 1, "stackLevel": 0, "chargingProfilePurpose": "TxProfile", "chargingProfileKind": "Absolute", "chargingSchedule": [ { "duration": 3600, "startSchedule": "2024-05-23T12:00:00Z", "chargingRateUnit": "W", "chargingSchedulePeriod": [ { "startPeriod": 0, "limit": 32.0 } ], "minChargingRate": 8.1 } ] } }
-
响应消息(RemoteStartTransaction.conf):
{ "status": "Accepted" }
主要步骤
- 发送请求: 中央系统发送
RemoteStartTransaction.req
消息到充电桩,包含要启动事务的相关信息。 - 处理请求: 充电桩接收请求并尝试启动事务。如果配置了需要授权,充电桩将先验证身份标签。
- 返回响应: 充电桩发送
RemoteStartTransaction.conf
消息回中央系统,指明启动事务的结果。
注意事项
- 如果充电桩配置了需要远程授权,充电桩将先验证身份标签,只有通过授权后才会启动事务。
- 如果请求中未指定连接器ID,充电桩可以自行选择连接器。
- 如果充电桩不支持智能充电且请求中包含充电配置文件,应忽略该配置文件。
Remote Stop Transaction
作用
RemoteStopTransaction
指令用于远程停止正在进行的充电事务。此指令由中央系统发出,以终止充电点上的指定充电事务。
请求字段
transactionId
(必选):需要停止的充电事务ID。整数类型。
响应字段
status
(必选):操作状态。取值为Accepted
或Rejected
。
示例
RemoteStopTransaction.req
{
"transactionId": 12345
}
RemoteStopTransaction.conf
{
"status": "Accepted"
}
主要步骤
- 中央系统发送RemoteStopTransaction.req指令到充电点,指定需要停止的充电事务ID。
- 充电点接收到请求后,验证请求中的参数,并尝试停止指定的充电事务。
- 充电点返回RemoteStopTransaction.conf指令,指示停止操作的结果。
注意事项
- transactionId字段必须为有效的充电事务ID。
- 远程停止充电事务应确保不会对用户造成不便或安全隐患。
- 充电点在接收到停止请求后,应尽快停止指定的充电事务并释放资源。
Reserve Now
指令概述
ReserveNow
指令用于在指定的时间段内预定一个充电点的连接器。此指令由中央系统发出,以确保在指定的时间段内,充电点的某个连接器将被保留给某个特定的用户使用。
指令格式
-
ReserveNow.req
connectorId
(必选):需要保留的连接器的ID。取值为整数。expiryDate
(必选):预订结束的日期和时间,格式为ISO 8601。idTag
(必选):将使用保留连接器的用户的ID标签。parentIdTag
(可选):如果用户使用的是子ID标签,此字段包含父ID标签。
-
ReserveNow.conf
status
(必选):预订状态。取值为Accepted
,Faulted
,Occupied
,Rejected
,Unavailable
。
请求示例
ReserveNow.req
{
"connectorId": 1,
"expiryDate": "2024-05-23T15:00:00Z",
"idTag": "ABC123",
"parentIdTag": "DEF456"
}
ReserveNow.conf
{
"status": "Accepted"
}
响应状态解释
Accepted
:预订成功。Faulted
:充电点故障,无法预订。Occupied
:连接器已被占用。Rejected
:预订请求被拒绝。Unavailable
:连接器不可用。
业务流程
- 中央系统发送
ReserveNow.req
指令到充电点,指定需要保留的连接器、预订的结束时间和使用者的ID标签。 - 充电点接收到请求后,验证请求中的参数,并尝试保留指定的连接器。
- 充电点返回
ReserveNow.conf
指令,指示预订的结果。
注意事项
- 预订的连接器在预订时间段内不应被其他用户使用。
- 预订的有效期由
expiryDate
字段指定,必须为ISO 8601格式的日期时间字符串。 idTag
字段必须为预订用户的有效ID标签。
Reset
指令概述
Reset
指令用于重置充电点。此指令由中央系统发出,以重新启动充电点设备。重置操作可以是硬重置(重启整个系统)或软重置(仅重启软件部分)。
指令格式
-
Reset.req
type
(必选):重置类型。取值为Hard
或Soft
。
-
Reset.conf
status
(必选):重置状态。取值为Accepted
或Rejected
。
请求示例
Reset.req
{
"type": "Hard"
}
Reset.conf
{
"status": "Accepted"
}
响应状态解释
Accepted
:重置请求被接受,充电点将进行重置。Rejected
:重置请求被拒绝,充电点不会进行重置。
业务流程
- 中央系统发送
Reset.req
指令到充电点,指定重置类型(硬重置或软重置)。 - 充电点接收到请求后,验证请求中的参数,并决定是否执行重置操作。
- 充电点返回
Reset.conf
指令,指示重置请求的结果。
注意事项
- 硬重置会导致整个系统重新启动,所有进行中的会话将会中断。
- 软重置只会重启软件部分,不会影响正在进行的充电会话。
- 重置操作应谨慎使用,确保不会对用户造成不便或数据丢失。
Send Local List
作用
SendLocalList
指令用于将本地授权列表发送到充电点。此指令由中央系统发出,以更新充电点上的本地授权列表,使其包含指定的授权ID标签。
请求字段
-
listVersion
(必选):本地列表的版本号。整数类型。 -
localAuthorizationList
(可选):包含授权ID标签的列表,每个ID标签的信息如下:idTag
(必选):授权的ID标签。字符串类型。idTagInfo
(可选):关于ID标签的详细信息,包括状态、过期日期等。
-
updateType
(必选):更新类型。取值为Full
或Differential
。
响应字段
status
(必选):操作状态。取值为Accepted
、Failed
或NotSupported
。
示例
SendLocalList.req
{
"listVersion": 1,
"localAuthorizationList": [
{
"idTag": "ABC123",
"idTagInfo": {
"status": "Accepted",
"expiryDate": "2024-12-31T23:59:59Z",
"parentIdTag": "DEF456"
}
}
],
"updateType": "Full"
}
SendLocalList.conf
{
"status": "Accepted"
}
主要步骤
- 中央系统发送
SendLocalList.req
指令到充电点,包含本地授权列表及其版本号。 - 充电点接收到请求后,验证请求中的参数,并更新本地授权列表。
- 充电点返回
SendLocalList.conf
指令,指示更新操作的结果。
注意事项
listVersion
字段必须为整数,并且应比充电点上当前的列表版本号大。updateType
为Full
时,将替换整个本地授权列表;为Differential
时,仅更新差异部分。- 确保
localAuthorizationList
中的idTag
字段为有效的ID标签。
Set Charging Profile
作用
SetChargingProfile
指令用于设置充电点的充电配置文件。此指令由中央系统发出,以定义充电点在特定时间段内应如何处理充电请求。
请求字段
connectorId
(必选):连接器的ID。整数类型。0表示充电点本身。csChargingProfiles
(必选):充电配置文件,包含以下字段:chargingProfileId
(必选):充电配置文件的ID。整数类型。stackLevel
(必选):配置文件的优先级。整数类型。chargingProfilePurpose
(必选):配置文件的目的。取值为ChargePointMaxProfile
、TxDefaultProfile
或TxProfile
。chargingProfileKind
(必选):配置文件的类型。取值为Absolute
、Recurring
或Relative
。recurrencyKind
(可选):配置文件的循环类型。取值为Daily
或Weekly
。validFrom
(可选):配置文件的有效起始日期和时间,ISO 8601格式。validTo
(可选):配置文件的有效结束日期和时间,ISO 8601格式。chargingSchedule
(必选):充电计划,包含以下字段:duration
(可选):充电计划的持续时间,秒为单位。startSchedule
(可选):充电计划的起始日期和时间,ISO 8601格式。chargingRateUnit
(必选):充电速率的单位。取值为W
(瓦)或A
(安)。chargingSchedulePeriod
(必选):充电计划的时间段,包含以下字段:startPeriod
(必选):时间段的起始时间,秒为单位。limit
(必选):充电功率或电流的限制。numberPhases
(可选):相数。
响应字段
status
(必选):操作状态。取值为Accepted
、Rejected
或NotSupported
。
示例
SetChargingProfile.req
{
"connectorId": 1,
"csChargingProfiles": {
"chargingProfileId": 101,
"stackLevel": 1,
"chargingProfilePurpose": "TxProfile",
"chargingProfileKind": "Relative",
"recurrencyKind": "Daily",
"validFrom": "2024-05-23T00:00:00Z",
"validTo": "2024-12-31T23:59:59Z",
"chargingSchedule": {
"duration": 3600,
"startSchedule": "2024-05-23T00:00:00Z",
"chargingRateUnit": "W",
"chargingSchedulePeriod": [
{
"startPeriod": 0,
"limit": 11000,
"numberPhases": 3
}
]
}
}
}
SetChargingProfile.conf
{
"status": "Accepted"
}
主要步骤
- 中央系统发送
SetChargingProfile.req
指令到充电点,指定需要设置的充电配置文件。 - 充电点接收到请求后,验证请求中的参数,并设置相应的充电配置文件。
- 充电点返回
SetChargingProfile.conf
指令,指示设置操作的结果。
注意事项
connectorId
为0表示设置充电点本身的配置文件,其他值表示设置具体连接器的配置文件。chargingProfilePurpose
和chargingProfileKind
字段必须为有效值。chargingSchedule
中的所有时间字段必须为ISO 8601格式。- 确保
chargingSchedulePeriod
中的limit
值在充电点的能力范围内。
Trigger Message
作用
TriggerMessage
指令用于触发充电点发送特定的消息。此指令由中央系统发出,以请求充电点立即发送指定类型的消息。
请求字段
requestedMessage
(必选):需要触发的消息类型。取值为BootNotification
、Heartbeat
、MeterValues
、StatusNotification
、FirmwareStatusNotification
、DiagnosticsStatusNotification
、Authorize
、StartTransaction
、StopTransaction
、DataTransfer
。connectorId
(可选):需要触发消息的连接器ID。取值为整数。如果省略则表示充电点。
响应字段
status
(必选):操作状态。取值为Accepted
、Rejected
、NotImplemented
。
示例
TriggerMessage.req
{
"requestedMessage": "StatusNotification",
"connectorId": 1
}
TriggerMessage.conf
{
"status": "Accepted"
}
主要步骤
- 中央系统发送
TriggerMessage.req
指令到充电点,指定需要触发的消息类型。 - 充电点接收到请求后,验证请求中的参数,并决定是否触发指定的消息。
- 充电点返回
TriggerMessage.conf
指令,指示触发操作的结果。
注意事项
requestedMessage
字段必须为有效的消息类型。connectorId
字段可选,如果指定则表示触发特定连接器的消息,否则表示触发充电点的消息。
Unlock Connector
作用
UnlockConnector
指令用于解锁充电点的连接器。此指令由中央系统发出,以远程解锁连接器,使其可供使用。
请求字段
connectorId
(必选):需要解锁的连接器ID。取值为整数。
响应字段
status
(必选):操作状态。取值为Unlocked
、UnlockFailed
、NotSupported
。
示例
UnlockConnector.req
{
"connectorId": 1
}
UnlockConnector.conf
{
"status": "Unlocked"
}
主要步骤
- 中央系统发送
UnlockConnector.req
指令到充电点,指定需要解锁的连接器ID。 - 充电点接收到请求后,验证请求中的参数,并尝试解锁连接器。
- 充电点返回
UnlockConnector.conf
指令,指示解锁操作的结果。
注意事项
connectorId
字段必须为有效的连接器ID。- 解锁操作应确保不会对用户造成不便或安全隐患。
Update Firmware
作用
UpdateFirmware
指令用于更新充电点的固件。此指令由中央系统发出,以远程更新充电点的固件版本。
请求字段
location
(必选):固件文件的URL地址。字符串类型。retrieveDate
(必选):开始下载固件的日期和时间,ISO 8601格式。retryInterval
(可选):下载失败后重试的时间间隔,秒为单位。整数类型。retries
(可选):下载失败后的重试次数。整数类型。
响应字段
status
(必选):操作状态。取值为Accepted
或Rejected
。
示例
UpdateFirmware.req
{
"location": "http://example.com/firmware.bin",
"retrieveDate": "2024-05-23T10:00:00Z",
"retryInterval": 600,
"retries": 3
}
UpdateFirmware.conf
{
"status": "Accepted"
}
主要步骤
- 中央系统发送
UpdateFirmware.req
指令到充电点,指定固件文件的URL地址和下载的时间。 - 充电点接收到请求后,验证请求中的参数,并开始下载固件文件。
- 充电点返回
UpdateFirmware.conf
指令,指示固件更新请求的结果。
注意事项
location
字段必须为有效的URL地址,指向固件文件。retrieveDate
字段必须为ISO 8601格式的日期时间字符串。- 下载固件文件过程中应确保网络连接稳定,以避免下载失败。
每个指令有具体的请求和响应格式,例如:
Authorize.req / Authorize.conf
BootNotification.req / BootNotification.conf
StartTransaction.req / StartTransaction.conf
StopTransaction.req / StopTransaction.conf
多次交互指令
OCPP 1.6 中的大多数指令都是单次往返的,即中央系统发送请求到充电点,充电点处理请求并返回响应。然而,某些场景下,OCPP 1.6 可能涉及多次来回的交互。以下是几个示例:
Firmware Update(固件更新):
中央系统发送 UpdateFirmware 请求。
充电点接收请求并开始下载固件文件,期间可能会发送 FirmwareStatusNotification 指令,以通知中央系统固件更新的进度和状态。
Diagnostics(诊断):
中央系统发送 GetDiagnostics 请求。
充电点接收请求并生成诊断文件,然后发送 DiagnosticsStatusNotification 指令,以通知中央系统诊断的状态和结果。
Smart Charging(智能充电):
中央系统可以发送 SetChargingProfile 请求,充电点在接收到请求后需要依据设定的充电配置文件进行充电,这可能会涉及到多个 MeterValues 指令的交互,用于报告充电进度和状态。
这些交互可能并不总是严格的请求-响应模式,而是可能包括事件通知、状态更新等多次往返的消息流。
OCPP-J & OCPP-S
OCPP-J 代表JSON风格的实现(本次使用),有单独的OCPP-J文档
OCPP-S 代表SOAP风格的实现
具备本地授权
疑问
-
配置文件是什么,存在哪里
-
充电桩的启动和停止是由桩发起的?实际的充电流程需要确认一下(如停止需要车主刷卡?)
-
不标准的充电记录
留言
预约部分是不是少了reservationId这个参数。 Sending: [2,”876c6781-b680-4e7e-9267-1821d974bd97″,”ReserveNow”,{“connectorId”:1,”expiryDate”:”2025-01-10T16:01:00.000+08:00″,”idTag”:”ev00001″,”reservationId”:101}]
reservationId 是必要的 , 不过我还没有正式做过OCPP的预约 , 这方面的需求少