GitHub/quartz
1
0
Fork 2
mirror of https://github.com/jackyzha0/quartz.git synced 2025-12-27 14:54:05 -06:00
Code Issues Actions Packages Projects Releases Wiki Activity
12e67907b8
quartz/content/Notes/OCPP/2.0.1解读/架构与拓扑.md
wangzipai f02b101072
[PUBLISHER] Merge #58
2025-04-02 11:38:26 +08:00

444 lines
37 KiB
Markdown
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

---
date created: 2024-03-24 17:48
date updated: 2025-04-02 11:38
tags:
- ocpp
link: "false"
share: "true"
---
# 架构与拓扑
OCPP最初用于在OCPP中充电站管理系统(csms)和充电站之间的后台之间进行双向通信。
该协议已经变得更加先进，每一次新的修订都添加了新的功能和选项。它已经发展成为一种协议，可以在不同的体系结构中用于不同类型的数据充电站。除了最初的“简单”设置CSMS <>充电站之外，本文档还描述了一些拓扑结构，作为使用OCPP的额外解释。
此外，还介绍了配置和监控任何类型充电站的设备管理概念、OCPP信息模型和**三层模型**。本文件部分提供信息，部分提供规范，并不打算限制OCPP的使用。然而，它确实添加了一个解释，说明在创建这个版本的规范时，OCPP的创建者考虑了OCPP的哪种用途。因此，本文档还旨在支持OCPP第2部分中协议规范的读者理解如何使用它。
## 术语和缩写
### 术语
| 术语 | 意义 |
| :------: | :--------------------------------------------------------------------------------------------------------------------: |
| 充电站 | 充电站是电动汽车可以充电的物理系统。充电站中有不定量的充电桩。 |
| 连接器 | 本规范中使用的术语连接器是指充电站上独立操作和管理的电源插座。换句话说，这对应于单个物理连接器。在某些情况下，EVSE可能具有多种物理插座类型和/或系留电缆/连接器安排(即:连接器)，以方便不同的车辆类型(例如四轮电动车及电动踏板车)。 |
| EVSE | EVSE被认为是充电站的一个独立操作和管理的部分，一次可以向一辆电动汽车提供能量 |
| 本地端口智能电表 | 智能电表上的本地端口是数字电表上的一个端口(例如串行端口)，提供对电表读数和使用信息的访问。 |
### 缩写
| 缩写 | 意义 |
| :--: | :-----------------------------------------------------------------------------------------------------------: |
| DSO | Distribution System Operator 配电系统操作员 |
| CSO | Charging Station Operator 充电站运营商 |
| CSMS | Charging Station Management 充电站管理系统 |
| EMS | Energy Management System 能源管理系统（在本文中，它被定义为管理本地负载的设备<br/>(消费和生产)基于当地和/或合同约束和/或合同激励。它有额外的输入，例如来自光伏、电池存储的传感器和控制） |
| EVSE | Electric Vehicle Supply Equipment 电动汽车供应设备（为电动汽车提供充电服务的设备，包括充电桩、充电线等相关配件） |
| LC | Local Controller（在本文档中，它被定义为可以向其充电的设备发送消息站，独立于CSMS。典型的用法是OCPP第2部分的智能充电章节中描述的本地智能充电案例，其中本地控制器可以对其施加充电限制充电站。） |
| LP | Local Proxy 充当消息路由器 |
## 3层模型
本节内容丰富。要理解OCPP规范中的术语，了解该规范的起点是很重要的。OCPP规范使用术语充电站作为电动汽车可以充电的物理系统。充电站可以有一个或多个evse(电动车辆供应设备)。EVSE被认为是充电站的一部分，一次可以向一辆电动汽车提供能量。本规范中使用的术语连接器是指充电站上独立操作和管理的电源插座，换句话说，它对应于单个物理连接器。在某些情况下，EVSE可能有多种物理插座类型和/或系绳电缆/连接器安排，以方便不同类型的车辆(例如四轮电动汽车和电动滑板车)。这种设置被称为==3层模型==，如下图所示。图1所示。OCPP采用的三层模型
![3-tier model.jpg](https://raw.githubusercontent.com/wangzipai/my_ob_pic/main/3-tier%20model.jpg)
本节在逻辑级别上描述用于通信目的的收费基础设施。我们不希望将映射强加到物理硬件上。这是制造商的选择。例如，EVSE可以集成到充电站中，看起来只是该设备的一部分，但它也可以有自己的外壳，并在物理实体充电站之外运行，例如，一个充电广场有20个EVSE和连接器，通过1个调制解调器作为1个充电站与csms通信，OCPP将其视为1个充电站。
## 信息模型
考虑到OCPP的消息越来越复杂，OCPP 2.0.1==基于一个信息模型作为消息==和OCPP固有模式的蓝图。
对于信息模型，我们指的是一个逻辑对象集，它描述了具有所有属性的真实对象。这提供了协议中信息结构的信息表示。此外，它支持使OCPP中的对象**可重用**，并支持消息和自动生成的消息模式的一致定义(第3部分)。
信息模型是一种模型，也称为域模型或核心模型，==OCPP消息和数据类型是基于该模型生成的==。
这些数据类型是从OCPP 1.6规范中提取出来的，并被命名为==核心数据类型==和==限定数据类型==。
下图说明了如何构建信息模型中的DataTypes。在第2部分-规范，数据类型一章中，一些数据类型有Common:前缀。这源于信息模型。这意味着**该数据类型能够在其他数据类型和消息之间共享**。这对设备的OCPP实现没有影响。
![Example datatypes.png](https://raw.githubusercontent.com/wangzipai/my_ob_pic/main/Example%20datatypes.png)
信息模型被划分为多个“功能”，以便更好地概述模型(从而提高可读性):
•事务
•智能充电
•计量
•安全(配置文件/授权)
•通信
•SecondaryActorSchedule
有关每个功能的实际模型的更多详细信息，请参阅附录。
## 设备模型:寻址组件和变量
设备模型指的是OCPP中的一种通用机制，它使充电站的任何模型都能够报告它是如何构建的，因此可以从任何csms进行管理。
使用设备模型(即:“管理设备”)，**在没有预先定义充电站结构的情况下，定义了一些消息和用例来详细配置和监控充电站。**
为了做到这一点，OCPP提供了一种通用机制，允许交换关于充电站的广泛信息。这个版本的设备模型==以3层模型(充电站、EVSE、连接器)为起点==，这意味着使用设备模型创建的任何描述都遵循这3层。本章的其余部分将描述==充电站和csms之间如何交换数据==(以及相关的元数据)。这里没有描述用于管理设备的用例和消息，而是在规范的第2部分中描述。本章只关注数据模型。
### 组件
在OCPP 2.0.1中，充电站被建模为一组“组件”，通常表示物理设备(包括与之连接以进行数据收集与/或控制的任何外部设备)、逻辑功能或逻辑数据实体。
**不同类型的组件主要由`ComponentName`标识**，这是一个标准化组件的名称(参见OCPP part 2c)，或者是一个定制/非标准化组件名称，用于新的、预标准化的设备、供应商特定的扩展等。
充电站(顶层)、EVSE和连接器代表充电站的三个主要“层”，构成了一个隐式的“==基于位置==”的寻址方案，广泛应用于许多OCPP数据结构中。
默认情况下，所有组件都位于充电站层，但是任何组件的单个实例都可以通过将EVSE或EVSE和连接器标识号作为组件寻址引用的一部分与特定EVSE或特定连接器(在特定EVSE上)相关联。
此外，可以有一个组件的多个实例(在功能维度中)，表示多次出现的物理或逻辑组件(例如电源转换器模块、风扇组、常驻固件映像等)。
每个不同的组件实例由一个(可选的)`componentInstance`寻址键唯一标识。当没有提供componentInstance时，则引用组件的默认实例或唯一实例。
==组件本身并不保存数据==:与每个组件实例相关联的所有外部可访问数据都由一组变量表示，**这些变量可以被读取、设置和/或监视更改**。组件与一个或多个变量的关系如下所示。
![](https://raw.githubusercontent.com/wangzipai/my_ob_pic/main/Component%20and%20variables.png)
下表说明了一些常见组件(通过它们的标准化组件名称)，以及它们通常出现在基本家用充电器和典型公共充电站的分层位置级别的示例。
| 基本家用充电器配置示例 | | |
| -------------- | ----------------------- | ----------------- |
| 充电站层 | EVSE 层 | 连接器层 |
| 充电站(自身，作为一个整体) | EVSE(自身，作为一个整体) | 连接器(自身，作为一个整体) |
| RadioLink | ControlMetering | PlugRetentionLock |
| TokenReader | OverCurrentBreaker | |
| 控制器 | RCD | |
| | ChargingStatusIndicator | |
| 公共充电站示例配置 | | |
| -------------- | ----------------------- | ----------------- |
| 充电站层 | EVSE 层 | 连接器层 |
| 充电站(自身，作为一个整体) | EVSE(自身，作为一个整体) | 连接器(自身，作为一个整体) |
| ElectricalFeed | ElectricalFeed | AccessProtection |
| TokenReader | TokenReader | PlugRetentionLock |
| Display | Display | |
| FiscalMetering | FiscalMetering | |
| Clock | ControlMetering | |
| Controller | OverCurrentBreaker | |
| | RCD | |
| | ChargingStatusIndicator | |
### 变量
每个组件都有许多变量，这些变量可以适当地用于保存、设置、读取与/或报告适用于该组件的所有(外部可见)数据，包括配置参数、测量值(例如电流或温度)与/或监控变量值的变化。
尽管许多组件可以有关联变量，这些变量本质上是特定于组件类型的(例如Connector组件的ConnectorType)，但是有一个**最小的标准化变量集**，用于在全局与/或选择性的基础上提供标准化的高级事件通知和状态/状态报告(例如Problem, Active)，并且还用于在清查/发现过程中报告组件的存在状态、可用性等(例如Available, Enabled)。
充电站不需要报告基本变量:Present, Available和Enabled，当它们为只读并设置为true时。当充电站不报告:当前，可用和/或启用时，中央系统将假定它们为只读并设置为true变量可以是任何通用数据类型(布尔值，整数，十进制，日期-时间，字符串)，但也可以将其允许的值限制为特定范围，枚举列表，集合或有序列表。为了支持复杂的组件，任何给定的变量名都可以有多个实例与任何组件相关联(例如，电源转换器模块在多个点报告温度、电流或电压)。每个不同的变量实例由(可选的)variableInstance寻址键字符串值唯一标识。当没有提供variableInstance时，则引用变量的默认或唯一实例。
### 特征因素
每个变量，**除了它的主值(“Actual”)之外，还可以有一组关联的辅助数据**，这些数据被链接到相同的主变量名和variableInstance。
这极大地避免了变量名称空间与令人困惑的辅助变量名称集群(例如FanSpeed, FanSpeedUnits, MinimumFanSpeed, BaseFanSpeed)缺乏一致性和可发现性的混乱。辅助变量数据包括:
• **变量特征元数据(只读)**
◦度量单位(V、W、kW、kWh等)
◦数据类型(Integer、Decimal、String、Date、OptionList等)
◦下限
◦上限
◦枚举变量允许值列表
• **变量属性(读写):**
◦实际值
◦目标值
◦配置下限
◦配置上限
◦可变性(是否可修改，如ReadOnly或ReadWrite)
◦持久性(重启或掉电后是否保留该值)
变量与一个或多个VariableAttributes之间的关系如下图所示。
![](https://raw.githubusercontent.com/wangzipai/my_ob_pic/main/Variable%20attributes%20and%20characteristics.png)
如何使用DeviceModel实现(物理)设备和(虚拟)控制器组件是有区别的。(虚拟)控制器组件必须按照第2部分“引用的组件和变量”中的描述来实现。这些类型的组件/变量只使用`variableAttribute`类型“Actual”。根据这个variableAttribute是否可写，csms可以使用它来设置一个新值。
(物理)设备实现起来有点复杂。例如，存在一个具有风扇转速的风扇，其(物理)限制范围为0 - 1000。但不应允许设置低于200的值，因为风扇会停止工作。它不应该设置在500以上，因为从长远来看，这对风扇来说是不好的。在使用DeviceModel实现该设备时，可以定义如下:
| 组件 | name | Fan | |
| -- | ----------------------- | ---------- | ------------------------------------------------ |
| 变量 | name | FanSpeed | |
| | variableAttribute 1 | type | Actual |
| | | value | 风扇当前的转速值 |
| | | mutability | ReadOnly |
| | variableAttribute 2 | type | Target |
| | | value | csms可以通过该值来调节风扇转速。充电站应尽量使实际值保持在目标值 |
| | | mutability | ReadWrite |
| | variableAttribute 3 | type | MaxSet |
| | | value | 示例中的值'500'。目标值不能高于此值。 |
| | variableAttribute 4 | type | MinSet |
| | | value | 示例中的值'200'。目标值不能低于此值 |
| | variableCharacteristics | maxLimit | 示例中的值“1000”。这可能是风扇的物理最大极限 |
| | | minLimit | 示例中的值“0”。这可能是风扇的物理最小极限。这也可以是-1000，如果风扇也能在另一个方向旋转 |
当尝试设置值为600的目标时，充电站将首先检查允许的最小值和最大值/限制并拒绝设置。如果目标值设置为500，则该数值在范围内，充电站将允许设置并开始调整实际风扇转速。如果实际测量到的风扇转速为502，则超出范围。但是它应该报告给csms，所以物理组件的实际值应该在不检查最小值和最大值/限制的情况下更新。
### 监控
**可选的监控设置可以与变量相关联**，从而允许将对变量(实际)值的更改作为事件通知报告给csms。
其中包括:
​ •监控值
​ •监控类型:上限阈值、下限阈值、增量、周期
​ •上报事件时的严重级别
MonitorType/dataType可能的组合如下表所示。
| | string | decimal | integer | dateTime | boolean | OptionList | SequenceList | MemberList |
| ------ | ------ | ------- | ------- | -------- | ------- | ---------- | ------------ | ---------- |
| 上限阈值 | | X | X | | | | | |
| 下限阈值 | | X | X | | | | | |
| 增量 | X | X | X | X | X | X | X | X |
| 周期 | X | X | X | | X | X | X | X |
| 周期时钟对齐 | X | X | X | | X | X | X | X |
•对于上限阈值和下限阈值，该值表示被变量的实际值所超过的值。
•对于增量，此值表示从监视器设置的时刻起与实际值相比的值变化。
​ ◦当变量的dataType为整数或十进制时，该值表示要达到的差异以触发监视器。
​ ◦当变量的数据类型是dateTime的测量单位将在秒。
​ ◦当变量的dataType为string、boolean、OptionList、SequenceList或MemberList时，该值将被忽略。实际值的每次更改都会触发监视器。
•当增量监视器被触发或充电站重新启动时，充电站将设置一个新的瞬时值。
•对于Periodic和PeriodicClockAligned，该值以秒为单位表示间隔。
变量和一个或多个VariableMonitoring元素之间的关系如下图所示。
![Variables and monitoring.png](https://raw.githubusercontent.com/wangzipai/my_ob_pic/main/Variables%20and%20monitoring.png)
### 标准化的组件和变量列表
为了在不同的充电站和csms之间提供某种程度的互操作性，除了上述定义的组件和变量模型外，OCPP规范的第2部分附录还提供了组件和变量的标准化名称列表。这个列表的想法是确保如果充电站和csms想要交换关于组件的信息，如果它在OCPP规范中列出，它们都使用相同的名称和描述。_对于未在规范中列出的组件或变量名称，充电站制造商和CSMS之间应进行双边预约_。在这些情况下，建议向开放收费联盟提供反馈，以便能够在新版本的OCPP中包含新的/额外的组件和变量。
### 最小设备模型
由于设备模型是一种通用机制，可以应用于任何充电站模型，因此不同实现的复杂性可能会有所不同。
它由许多并非全部必需的用例和消息组成。
本节描述了创建OCPP 2.0.1的工作实现所需实现的设备模型的==最小部分==。设备模型引入了可用于**配置**和**监控**充电站的**组件**和**变量**。其中一些组件和变量包含在规范第2部分的引用组件和变量列表中(按功能块分组)。当实现一个功能块时，属于一个功能块的所有必需的配置变量都应该被实现。对于所有OCPP 2.0.1的实现，也应实现通用部分中要求的配置变量。下表描述了作为设备模型实现的一部分的所有用例需要或可选实现的消息。
| 应用场景/最小设备模型实现的一部分消息 | |
| ------------------- | ----------------------------------------------------------------------------------- |
| **应用场景** | **消息** |
| B05 Set Variables | SetVariables消息必须被实现 |
| B06 Get Variables | GetVariables消息必须被实现 |
| B07 Get Base Report | GetBaseReport消息必须实现并且必须支持所有3个' reportbase '。这些报告的内容取决于充电站的实施情况。实现者可以决定实现中存在哪些组件和变量。 |
| 附加的用例/非最小设备模型实现的一部分的消息 | |
| --------------------------- | ------------------------------------------------------ |
| **应用场景** | **消息** |
| B08 Get Custom Report | GetCustomReport消息是可选的 |
| N02 Get Monitoring Report | GetMonitoringReportRequest消息是可选的。 |
| N03 Set Monitoring Base | SetMonitoringBaseRequest消息是可选的。 |
| N04 Set Variable Monitoring | SetMonitoringBaseRequest消息是可选的。 |
| N05 Set Monitoring Level | SetMonitoringLevelRequest消息是可选的。 |
| N06 Clear/Remove Monitoring | ClearVariableMonitoringRequest消息是可选的。 |
| N07 Alert Event | 建议在充电站中实现NotifyEventRequest，即使没有实现监控，这样它可以用来报告内置的监控事件。 |
| N08 Periodic Event | 同上 |
## 信息模型与设备模型
如上所述，信息模型和设备模型指的是不同的概念。
信息模型(Information Model)指的是==OCPP中的消息和数据类型所基于的信息结构模型==，而设备模型(Device Model)指的是==OCPP中的一种通用机制==，它使充电站的任何模型都能够报告它是如何建立的，这样就可以从任何csms管理充电站，而无需事先定义充电站的结构。
因此，用于设备管理的消息是信息模型的一部分，用于设备建模的对象(“组件”和“变量”)也是信息模型的一部分。
## 将OCPP用于电动汽车充电以外的其他用途
如本文档介绍中所述，OCPP主要用于csms和充电站之间的双向通信。然而，随着设备模型一章中所描述的设备模型的增加，OCPP可以额外用于其他目的。例如，报告变压器或独立电池组中的事件或状态变化也可能对正在推出电动汽车充电基础设施的公司有用。在本例中，可以使用BootNotification将这些设备连接到管理系统。在设备模型中，一个不是充电站的设备，可以通过组件充电站不存在于顶层的事实来识别。目前，OCPP规范没有为非充电站设备提供用例。但是，它们可能会被添加到OCPP的未来版本中。
## 编号
### EVSE编号
为了使CSMS能够处理充电站的所有evse, evse必须始终**以相同的方式编号**。evse编号(evseid)必须如下:
​ •evse必须**按顺序**编号，每个充电站==从1开始==编号(不得跳过编号)。
​ •evseId不能大于充电站的evse总数
​ •对于CSMS发起的操作，evseId ==0保留用于寻址整个充电站==。
​ •对于充电站发起的操作(报告时)，evseId ==0保留给充电站主控制器==。
例如:一个充电站有3个evse:所有的evse必须编号为id: 1,2,3。充电站电动汽车的编号宜采用从左到右，从上到下递增的逻辑方式。
### 连接器编号
为了使csms能够对充电站的所有连接器进行寻址，连接器必须始终以相同的方式编号。连接器编号(connectorId)必须如下所述:
​ •连接器编号(增加)==从每个EVSE上的connectorId 1开始==
​ •每个EVSE的连接器都有一个==唯一==的编号
​ •==EVSE的第一个连接器的ID必须为1==
​ •同一EVSE的其他连接器必须顺序编号(不得跳过数字)
​ •connectorId必须永远不会高于该EVSE上的连接器总数
示例:一个充电站有3个EVSE，每个EVSE有2个连接器，编号如下:
​ •EVSE 1有connectorId 1和2
​ •EVSE 2有connectorId 1和2
​ •EVSE 3有connectorId 1和2
### 事务id
==transactionid现在由充电站生成==，并且对于每个已启动的事务，该充电站必须是唯一的。
在ocpp1.x，这是CSMS做的。
事务ID的格式留给实现。例如，这可能是一个增量数字或UUID。
## OCPP支持的拓扑
本章展示了使用OCPP的一些拓扑结构。正如在介绍中所指出的，OCPP最初用于每个充电站直接与csms通信的设置。重要的是要记住，**OCPP不了解充电站网络的拓扑结构**。下图显示了使用OCPP的设置中可能的组件以及这些组件之间的关系:
![Possible components in a setup using OCPP.png](https://raw.githubusercontent.com/wangzipai/my_ob_pic/main/Possible%20components%20in%20a%20setup%20using%20OCPP.png)
### 直接连接到CSMS的充电站
这是使用OCPP的基本设置。
### 多个充电站通过本地代理连接到CSMS
在某些情况下，希望将一组充电站的所有通信通过单个网络节点路由(即:调制解调器，路由器等)。一个典型的例子是，许多充电站位于地下停车场，很少或根本没有移动网络。为了提供对移动数据的访问，充电站通过局域网连接到中央数据通信单元。这个中心单元连接到移动网络，并充当csms和充电站之间的代理。这样的单元被称为“本地代理”(LP)
![Multiple Charging Stations connected to CSMS via Local Proxy.png](https://raw.githubusercontent.com/wangzipai/my_ob_pic/main/Multiple%20Charging%20Stations%20connected%20to%20CSMS%20via%20Local%20Proxy.png)
### 多个充电站通过本地控制器连接到CSMS
本地代理除了路由OCPP消息之外几乎没有什么作用，而==本地控制器可以独立于csms向其充电站发送消息==。OCPP第2部分的智能充电章节描述了本地智能充电的典型用法，其中本地控制器可以对其充电站施加充电限制。为了让本地控制器被csms寻址，它需要有自己的==充电站标识==。从OCPP的角度来看，本地控制器将只是一个充电站(没有任何EVSEs/连接器)。csms将拥有处理本地控制器的逻辑，以支持本地智能充电等功能。这取决于csms的实现，无论是手动配置组拓扑还是根据IP地址和BootNotifications中的信息从网络中推断出组拓扑。下面的图表说明了这个配置。
![Multiple Charging Stations connected to CSMS via Local Controller.png](https://raw.githubusercontent.com/wangzipai/my_ob_pic/main/Multiple%20Charging%20Stations%20connected%20to%20CSMS%20via%20Local%20Controller.png)
从技术上讲，这种拓扑可以通过多种方式实现。当对websockets使用这种设置时，这意味着当充电站连接到本地控制器时，它应该打开一个具有相同地址的websocket连接到csms。这种方法的优点是本地控制器可以看到所有的消息并对其进行处理，消息不必等待，充电站上的固件更新等都是可能的，而且csms不需要特殊的软件。它可能(在大型安装中)导致csms和LC之间需要大量的websocket连接。有关更多信息，请参阅第4部分中的OCPP实现指南。
### 非OCPP充电站通过OCPP本地连接到csms控制器
该设置有多个非OCPP充电站，这些充电站使用启用OCPP的本地控制器抽象出来。在这种情况下应用OCPP时，应该将LC视为具有多个ev的充电站，或者LC应充当多个OCPP充电站(具有自己的充电站标识)。
![Multiple non-OCPP Charging Stations connected to CSMS via Local Controller.png](https://raw.githubusercontent.com/wangzipai/my_ob_pic/main/Multiple%20non-OCPP%20Charging%20Stations%20connected%20to%20CSMS%20via%20Local%20Controller.png)
### DSO控制信号到csms
在这种设置中，CSMS是唯一向其充电站发送信号的应用程序，但CSMS根据(很可能)电网约束从DSO接收智能充电信号。这意味着接收到非ocpp信号，如OpenADR或OSCP，并基于此信号，csms限制其充电站的充电。想要完全控制充电站的公民社会组织使用这种架构，这样他们就可以控制充电站使用的能量量。这可以通过向充电站发送充电配置文件/充电时间表来完成。
![Smart Charging - DSO control signals to CSMS.png](https://raw.githubusercontent.com/wangzipai/my_ob_pic/main/Smart%20Charging%20-%20DSO%20control%20signals%20to%20CSMS.png)
### CSMS和EMS并行控制
在(半)私有的情况下，充电站不仅连接到csms，而且还连接到能源管理系统，应该支持某种形式的并行控制。OCPP至少应该用于充电站维护，但OCPP 2.0.1还支持报告外部智能充电控制限制。因此，如果能源管理系统决定稍后充电“更好”，则能源管理系统可以对充电站施加外部限制(例如0)，充电站反过来可以通过OCPP向csms报告。能源管理系统可能从智能电表的本地端口输入，以防止连接过载，但也可能有其他原因(例如天气条件)不收费。
![ems csms.png](https://raw.githubusercontent.com/wangzipai/my_ob_pic/main/ems%20csms.png)
## 第一部分附录:OCPP信息模型
### UML表示和消息生成的解释
在下一段中，显示了OCPP信息模型的UML方案。该模型基于公共信息模型(Common Information model, CIM)，并在一定程度上基于CEFACT命名标准(仅是标准的一部分)。模型中的对象被命名为BusinessComponents，并继承CIM IdentifiedObject的属性，比如MRID和Name。在UML图中，从IdentifiedObject继承的属性显示在IdentifiedObject构造型之下。其他属性列在构造型。
OCPP中的消息来自下一段所示的模型，分为三步:
![Process from information Model to Messages schemes.png](https://raw.githubusercontent.com/wangzipai/my_ob_pic/main/Process%20from%20information%20Model%20to%20Messages%20schemes.png)
创建信息模型之后，将基于信息模型创建消息。然而，在这个转换(第一个箭头)中，一些规则被(手动地)应用于建模消息。应用的最重要的规则是，包含对类的引用的消息只有一个<字段>，由名称为`<class><field>`的字段替换。例如，如果消息包含一个Transaction，并且只有一个Id，那么这个Id将被一个transactionId替换。在下一步中，当生成规范第2部分的消息和数据类型部分时，为了可读性，所有核心数据类型(如CounterType)都被它们引用的本例整数中的原始数据类型(枚举除外)所替换。
### OCPP信息模型的可视化表示
#### Transactions
![OCPP Information Model Transactions.png](https://raw.githubusercontent.com/wangzipai/my_ob_pic/main/OCPP%20Information%20Model%20Transactions.png)
#### SmartCharging
![OCPP Information Model SmartCharging.png](https://raw.githubusercontent.com/wangzipai/my_ob_pic/main/OCPP%20Information%20Model%20SmartCharging.png)
#### Metering
![OCPP Information Model Metering.png](https://raw.githubusercontent.com/wangzipai/my_ob_pic/main/OCPP%20Information%20Model%20Metering.png)
#### Device Model
![OCPP Information Model Device Model.png](https://raw.githubusercontent.com/wangzipai/my_ob_pic/main/OCPP%20Information%20Model%20Device%20Model.png)
#### Security-Profiles
![OCPP Information Model Security-Profiles.png](https://raw.githubusercontent.com/wangzipai/my_ob_pic/main/OCPP%20Information%20Model%20Security-Profiles.png)
#### Security-Authorization
![OCPP Information Model Security-Authorization.png](https://raw.githubusercontent.com/wangzipai/my_ob_pic/main/OCPP%20Information%20Model%20Security-Authorization.png)
#### Communication
![OCPP Information Model Communication.png](https://raw.githubusercontent.com/wangzipai/my_ob_pic/main/OCPP%20Information%20Model%20Communication.png)
#### SecondaryActorSchedule
![OCPP Information Model SecondaryActorSchedule.png](https://raw.githubusercontent.com/wangzipai/my_ob_pic/main/OCPP%20Information%20Model%20SecondaryActorSchedule.png)
## 总结
在OCPP协议中，三层模型、信息模型和设备模型相结合，共同构建了一个完整的充电站通信框架。
- [**三层模型**：这个模型将充电站分为充电站、EVSE和连接器三个层次，用于描述和管理充电站的结构和数据](https://www.openchargealliance.org/uploads/files/OCA-OCPP-Whitepaper-Chinese.pdf)[1](https://www.openchargealliance.org/uploads/files/OCA-OCPP-Whitepaper-Chinese.pdf)。
- [**信息模型**：信息模型是基于一个逻辑对象集来生成消息和数据类型，这些对象表示真实的设备和属性。信息模型提供了协议中信息结构的可视化表示，并支持对象的复用和一致性](https://www.openchargealliance.org/uploads/files/OCA-OCPP-Whitepaper-Chinese.pdf)[1](https://www.openchargealliance.org/uploads/files/OCA-OCPP-Whitepaper-Chinese.pdf)。
- [**设备模型**：设备模型提供了一种通用的机制，使任何型号的充电站能够报告其构建方式，以便从任何CSMS进行管理。设备模型使用组件和变量来表示充电站的各个部分，并支持配置、监控和事件通知等功能](https://www.openchargealliance.org/uploads/files/OCA-OCPP-Whitepaper-Chinese.pdf)[1](https://www.openchargealliance.org/uploads/files/OCA-OCPP-Whitepaper-Chinese.pdf)。
[这三个模型相互配合，使得OCPP协议能够支持不同的充电设备和连接器类型，提高充电站的兼容性和灵活性，实现充电站、EVSE和连接器之间的独立操作和管理，提高充电站的可靠性和安全性，并实现充电站与CSMS之间的标准化通信协议](https://www.openchargealliance.org/uploads/files/OCA-OCPP-Whitepaper-Chinese.pdf)[1](https://www.openchargealliance.org/uploads/files/OCA-OCPP-Whitepaper-Chinese.pdf)[。这种结构也大大降低了设备、App 和 SaaS 等各端的开发成本](https://developer.tuya.com/cn/docs/iot/OCPP-Documents?id=Kbxaotl6em9mq)[2](https://developer.tuya.com/cn/docs/iot/OCPP-Documents?id=Kbxaotl6em9mq)。
信息模型中的对象复用和一致性是指：
- 对象复用：信息模型中的一些对象可以在不同的消息和数据类型中重复使用，以减少冗余和提高效率。例如，AmountType对象可以用于表示不同的金额值，如费用、余额、限制等。
- 对象一致性：信息模型中的一些对象可以保持相同的名称、属性和结构，以便在不同的上下文中进行识别和处理。例如，ComponentType对象可以用于表示充电站的各个部分，如充电站、EVSE、连接器等。
## metering图解
![OCPP Information Model Metering.png](https://raw.githubusercontent.com/wangzipai/my_ob_pic/main/OCPP%20Information%20Model%20Metering.png)
这个图用统一建模语言（UML）来表示信息模型中的metering功能块相关的对象、属性、消息和数据类型，以及它们之间的关系。UML是一种标准的图形化语言，用于描述软件系统的结构和行为。UML有多种图，例如类图、时序图、状态图等，用于表示不同的视角和层次。在OCPP 2.0.1中，信息模型主要使用了类图来表示。
类图是一种用于描述系统中的类及其关系的结构图。类图中的每个矩形代表一个类，类名在矩形的顶部，类的属性在矩形的中间，类的操作在矩形的底部。属性和操作可以有可见性标记，例如==`+`表示公开==，==`-`表示私有==，==`#`表示保护==。属性和操作也可以有类型和默认值。类之间可以有不同类型的关系，例如关联、聚合、组合、泛化、依赖等，用不同形状的线和箭头来表示。关系上也可以有角色名、多重性和导航方向等信息。
在这个图中，我们可以看到：
- Metering是一个对象，它代表了一个物理或逻辑的计量设备或功能，它有一个属性meterId，它是一个String类型，并且是公开的（+）。它还有一个操作MeterValues，它是一个消息，并且也是公开的（+）。
- MeterValues是一个消息，它有两个参数：meterValue和transactionId。meterValue是一个MeterValueType类型，并且是公开的（+）。transactionId是一个Integer类型，并且也是公开的（+）。
- MeterValueType是一个数据类型，它是一个复杂类型，并且有两个属性：timestamp和sampledValue。timestamp是一个DateTime类型，并且是公开的（+）。sampledValue是一个SampledValueType类型，并且是公开的（+）。
- SampledValueType是一个数据类型，它是一个复杂类型，并且有四个属性：value、context、format和measurand。value是一个Decimal类型，并且是公开的（+）。context是一个ReadingContextEnumType类型，并且也是公开的（+）。format是一个ValueFormatEnumType类型，并且也是公开的（+）。measurand是一个MeasurandEnumType类型，并且也是公开的（+）。
- ReadingContextEnumType、ValueFormatEnumType和MeasurandEnumType都是数据类型，它们都是枚举类型，并且有多个可能的值。
- Metering和MeterValues之间有一个关联关系，用一条实线连接，并且有一个**空心菱形在Metering一端**。这表示Metering是MeterValues的聚合者，也就是说**Metering包含了MeterValues作为它的一部分**。
- MeterValues和MeterValueType之间有一个依赖关系，用一条虚线连接，并且有一个箭头在MeterValueType一端。这表示MeterValues依赖于MeterValueType作为它的参数。
- MeterValueType和SampledValueType之间也有一个依赖关系，用一条虚线连接，并且有一个箭头在SampledValueType一端。这表示MeterValueType依赖于SampledValueType作为它的属性。
Reference in New Issue View Git Blame Copy Permalink