资料介绍
ICS 35.240.99 CCS L 70
34
安徽 省地 方标 准
DB34/T 5429—2026
充换电基础设施综合监管服务平台
接入规范
Specification for comprehensive supervision service platform for charging and
swapping infrastructure
2026-04-30 发布 2026-05-30 实施
安徽省市场监督管理局发 布
前言
本文件按照GB/T 1.1—2020《标准化工作导则第1部分：标准化文件的结构和起草规则》的规定起草。
请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别专利的责任。
本文件由中安能源(安徽)有限公司提出。
本文件由安徽省发展和改革委员会归口。
本文件起草单位：中安能源(安徽)有限公司、国网安徽省电力有限公司、安徽省经济信息中心、合肥蔚电科技有限公司、合肥市电动汽车充电设施投资运营有限公司、安徽星充新能源科技有限公司、芜湖市充换电有限责任公司、合肥特来电汽车充电有限公司、安徽省充换电有限责任公司、安徽奥动新能源科技有限公司、国网安徽电动汽车服务有限公司、国网安徽省电力有限公司马鞍山供电公司。
本文件主要起草人：吴海、吴冠琼、张政、陈晨、王燕、杨娟、范钰、刘凯、潘婉欣、戚运韬、张文、刘辉舟、袁昭、张园、张明懿、翟龙飞、李杰、刘银、刘那、殷源、朱明磊、王维胜、王欧、齐红涛、刘金友、汪安邦、陈伟、王翀、张向宏、刘子婧、张军、张泽群、陈光宇、李林、黄华胜。
I
1 范围
本文件规定了充换电基础设施综合监管服务平台接入基本要求、接入流程、数据传输与安全等要求。本文件适用于安徽省内各充换电基础设施运营商平台的接入。
2 规范性引用文件
下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件，仅该日期对应的版本适用于本文件;不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。
GB/T 9387.1
信息技术开放系统互连基本参考模型第1部分:基本模型
GB/T 19596
电动汽车术语
GB/T 20271
信息安全技术
信息系统通用安全技术要求
GB/T 22239
网络安全等级保护基本要求
GB/T 25070
网络安全等级保护安全设计技术要求
GB/T 29317
电动汽车充换电设施术语
3 术语和定义
GB/T 19596、GB/T 29317界定的以及下列术语和定义适用于本文件。
3. 1
充换电基础设施综合监管服务平台 comprehensive supervision service platform for charging and swapping infrastructure
由政府行业主管单位授权的运营组织或由新能源汽车充换电设施运营商建设的，应用智慧监管、物联网、车联网等技术的新能源汽车充换电基础设施综合监管服务信息系统，在信息化相关技术的支撑下，对新能源汽车充换电基础设施进行监测管理、数据采集，向运营商和新能源汽车用户提供便捷服务，对新能源汽车充换电基础设施领域内相关信息进行收集、整合、分析并加以有效利用，及时对新能源汽车产业领域出现的问题或趋向作出反应，有效实施信息化监管服务。
注：简称监管平台。
3. 2
电动汽车充换电服务 EV charging service
运营商提供给电动汽车使用者的服务，包括通过身份识别认证、站点导航、充换电、支付结算的整个过程。
3. 3
电动汽车充换电服务运营商 EV charging and battery swap service operator
为电动汽车用户提供充换电服务的提供者。
1
注：简称运营商。
3. 4
电动汽车充换电服务平台运营商 EV charging and battery swap service platform operator为电动汽车充换电服务运营商提供电动汽车充换电服务平台服务的专业平台运营商。
注：简称平台运营商。
3. 5
充换电服务平台 Charging and swapping service platform
为充换电设施提供服务网络的运行监控、运营管理、业务服务、信息服务等服务的网络平台。
注：简称运营平台。
4 缩略语
下列缩略语适用于本文件。
HTTP(S)：超文本传输安全协议(Hypertext Transfer Protocol Secure)
JSON：JavaScript对象标记(JavaScript Object Notation)
HMAC：基于哈希的消息认证码(Hash-based Message Authentication Code)
MD5：消息摘要算法(Message Digest Algorithm MD5)
URL：统一资源定位符(Uniform Resource Locator)
5 接入对象
安徽省内开展电动汽车充换电运营服务的平台运营商及其运营平台。
6 接入要求
6. 1 软件界面要求
运营平台的软件界面设计开发应遵循HTML5(HyperText Markup Language 5，超文本5.0)标准。
6. 2 架构要求
运营平台的开发架构应采用B/S(Browser/Server，浏览器/服务器模式)架构，前后端分离，模块化构建方式。
6. 3 业务集成要求
运营平台应通过统一资源文件实现各项业务的集成。
6. 4 运营要求
运营平台应保持(7×24)小时不间断稳定运行。
7 功能要求
接入监管平台的运营平台应具备包括收集、存储、传输充换电服务资源信息、档案信息、状态信息、订单信息等相关数据的功能。
2
8 接入流程
8. 1 申请接入
平台运营商登录监管平台网站，提交接入监管平台相关申请资料。运营商应由其平台运营商代为申请接入监管平台，不需要自己提交申请。
8. 2 开发接口
监管平台技术团队根据平台运营商提交的接入申请，建立沟通联系机制，并通过沟通联系机制向申请接入的平台运营商发布接口协议等相关技术资料，由平台运营商根据接口协议开发数据传输接口。
8. 3 对接联调
平台运营商完成数据接口开发后，应及时告知监管平台技术团队，监管平台技术团队安排相关资源开展数据对接联调。
8.4 数据治理
完成数据对接联调后，平台运营商将其充换电基础设施数据上传至监管平台，监管平台对接收到的数据进行数据合规性治理。
8.5 完成接入
充换电基础设施数据通过监管平台数据治理后，进入监管平台正式环境，正式完成接入。
接入流程如图1所示。
申请接入开发接口对接联调数据治理完成接入
图 1 接入监管平台流程图
9 数据传输与安全
9. 1 数据传输体系
9.1.1 数据传输流程
电动汽车充换电服务信息交换应符合GB/T 9387.1中关于会话连接的要求，一般需要经过平台认证、请求和应答3个步骤。
9.1.2 数据传输接口
所有数据传输接口均应采用HTTP (S)接口，每个接口的URL均采用如下格式定义：
a) http (s)://[域名]/evcs/v[版本号]/[接口名称];
b) 域名：接口提供方平台域名;
c) 版本号：代表接口版本号，不同的版本地址对应相应版本代码。系统升级期间，新旧版本可同时存在，待所有接入方都切换到新接口，旧版本接口即可下线。从而达到平滑升级的目的;
d) 接口名称：所请求/调用接口的名称，接口的命名应符合GB/T 9387.1 相关要求;
3
e) 为保证各接口的功能明确清晰，每个 URL 只允许对应一种功能。
9.1.3 接口调用方式
接口均应使用HTTP (S)/POST方式传输参数，采用JSON的方式，传输过程中应包含消息头和消息主体两部分。数据应采用UTF-8编码(针对Unicode的可变长度字符编码，Unicode Transformation Format)， JSON格式。
9.2 平台认证要求
9.2.1 基本要求
9.2.1.1 平台信息交换应具备平台认证服务，提供平台之间的鉴权认证功能。平台之间在信息交换前，应完成平台认证，获得平台交换能力。
9.2.1.2 省级监管平台、运营商平台应提供严格的系统安全保密机制，保障信息交换接口安全、稳定、可靠地运行，包括信息的存取控制、应用系统操作的安全等。基本要求：
a) 采用身份认证、访问控制、数据加密、数字签名等安全措施;
b) 采用安全可靠并且普遍使用的加密算法;
c) 密钥的存贮和交易信息的加密/解密需要在安全的环境中;
d) 数据安全保密应遵循国家和行业标准;
e) 应能定期或应对突发情况进行密钥更新和启用;
f) 具备对报文进行来源正确性鉴别的机制(HMAC)。
9.2.2 认证方式
9.2.2.1 身份认证宜采取用户名/口令认证、密钥认证或数字证书认证等方式;访问控制可采取 IP(网际互连协议，Internet Protocol)访问控制、时间访问控制等多种结合手段。
9.2.2.2 用户身份认证成功后授予 Token，每次向服务端请求资源时应带着服务端签发的 Token，服务端验证 Token 成功后，才返回请求的数据。Token 的有效期由服务方确定，最长不应超过 7 天，Token丢失或失效后应再次发起认证服务。
9. 3 密钥的管理和使用
9.3.1 基本要求
9.3.1.1 各平台应符合 GB/T 25070、GB/T 20271、GB/T 22239 中关于数据安全传输控制要求。
9.3.1.2 各平台应提供严格的系统安全保密机制，保障信息交换接口安全、稳定、可靠地运行，包括信息的存取控制、应用系统操作的安全等。
9.3.1.3 密码算法用于密钥的产生、分发、HMAC 以及加密等安全功能，相关的算法模块在其生命周期内不应被修改、导出至安全环境外部。
9.3.1.4 指定功能的密钥仅能做指定功能使用，不应被其他任何功能使用。
9.3.2 密钥的分类
交互前应分配标识、对接方密钥、消息密钥、消息密钥初始化向量和签名密钥。并应符合下列要求：
a) 唯一标识(PlatformID):固定 9 位，对接方的组织机构代码九位，作为唯一标识;
b) 密钥(PlatformSecret):可采用 16H、32H、48H 和 64H，由 0～F 字符组成，为申请认证使用;
4
c) 消息密钥(DataSecret):可采用 16H、32H、48H 和 64H，由 0～F 字符组成，用于对所有接口中 Data 信息进行加密;
d) 消息密钥初始化向量(DataSecretIV)：固定 16 位，用户AES 加密过程的混合加密;
e) 签名密钥(SigSecret):可采用 16H、32H、48H 和 64H，由 0～F 字符组成，为签名的加密密钥。
9.3.3 密钥的管理
9.3.3.1 密钥的产生：数据密钥应具备随机产生特性，密钥产生后应检查密钥的有效性，弱密钥和半弱密钥应被剔除。加入信息交换时，必须申请独立的密钥文件，密钥可双方协商产生。
9.3.3.2 密钥的分发：密钥的分发应由安全方式进行，可通过线下分发、联机报文或数字信封的方式加密传输。
9.3.3.3 密钥的存储：密钥宜保存在硬件加密机内。如果出现在硬件加密机外，则密钥应以密文方式出现。密钥注入、密钥管理和密钥档案的保管应由专人负责。使用密钥和销毁密钥要在监督下进行并应有使用、销毁记录。
9.3.3.4 密钥的销毁：当新密钥产生后，生命期结束的旧密钥应从数据库和内存中清除，防止被替换使用;同时所有可能重新构造此密钥的信息也应清除。新密钥成功启用和旧密钥自动销毁的记录将被更新。
9.3.4 密钥的使用
9.3.4.1 数据的加解密处理：消息发送方应对 Data 字段中涉及交易及隐私等数据利用消息密钥(DataSecret)进行加密。
9.3.4.2 消息接收方收到消息之后，根据消息密钥(DataSecret)对消息体中的 Data 数据进行解密，校验参数合法性等后续业务处理。
9.3.4.3 参数签名规范：参数签名采用 HMAC-MD5 算法，采用 MD5 作为散列函数，通过签名密钥(SigSecret)对整个消息主体进行加密，然后采用 MD5 信息摘要的方式形成新的密文，参数签名应大写。
9.3.4.4 参数签名顺序按照消息体顺序拼接后执行，入参拼接顺序为唯一标识标识(PlatformID)、参数内容(Data)、时间戳(TimeStamp)、自增序列(Seq)，出参拼接顺序为返回值(Ret)、返回信息(Msg)、参数内容(Data)。
10 接入数据标准
10.1 完整性
完整性是指接入监管平台的基础设施数据记录和信息是否完整，是否存在缺失的情况。数据的缺失可能会导致统计结果不准确。
10.2 准确性
数据汇总记录的信息和数据是否准确，是否存在异常、错误、虚假或误导性的信息。如果数据不准确，将会影响业务的正确性。
10.3 一致性
5
一致性是指充电站、充电桩、充电枪及订单或不同时间点的数据是否具有相同的含义和标准。不一致的数据会导致业务的混乱和误导。
10. 4 及时性
及时性是指数据产出的时间点是否及时，是否能够满足使用者的需求。过时的数据可能导致业务的滞后和失效。
6
