技术领域
[0001] 本发明涉及充电桩管理技术领域,特别是涉及一种充电设备与充电管理平台间的互信认证方法及系统。
相关背景技术
[0002] 充电设备(EVSE)或者充电桩是指以充电为目的提供专用功能,将电能补充给电动汽车或者其他终端设备的装置,在实际生产管理过程中,以充电站为单位作为管理的基本单元,以具备通信能力的设备及其关联组件视作一个充电设备,将其作为资产注册的基本点,以充电接口(枪、充电弓、充电线圈、换电柜等)作为服务可用与否的判断依据。
[0003] 其中,充电设备需要受到充电管理平台的管理,来确认充电设备的状态以及远程控制充电设备的动作等。在充电设备与充电管理平台进行通信时,目前采用的协议,通常是采用普通的通信协议,如单纯的TCP/IP协议、HFS-http协议等,这些协议在进行数据传输时,通信的稳定性和安全性较低,网络流量较大,且存在网络粘包等问题。
[0004] 因此,如何提供一种能够解决上述问题的充电设备与充电管理平台间的互信认证方法及系统是本领域技术人员目前需要解决的问题。
具体实施方式
[0058] 本发明的核心是提供一种充电设备与充电管理平台间的互信认证方法及系统,基于MQTT进行充电设备与充电管理平台间的数据传输,从而尽可能避免网络粘包的问题,且减少网络流量并且提高数据传输的稳定性和安全性。
[0059] 为使本发明实施例的目的、技术方案和优点更加清楚,下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
[0060] 本发明提供了一种充电设备与充电管理平台间的互信认证方法,参见图2和图3所示,图2为本发明提供的充电设备与充电管理平台的通信方式示意图;图3为本发明提供的一种充电设备与充电管理平台间的互信认证方法的过程的流程图。
[0061] 该方法包括:
[0062] 步骤s1:充电设备发送发布主题、业务请求数据以及订阅主题至消息服务器;消息服务器转发该发布主题至充电管理平台,告知充电管理平台当前的业务类型;
[0063] 充电设备是用于为电动车或者其他用电设备提供充电服务的设备,也可以称为充电桩,充电管理平台是用于发送远程控制指令来对充电设备进行各项管理的后端平台。
[0064] 步骤s2:充电管理平台发布订阅主题至消息服务器后,消息服务器将业务请求数据转发至发送了对应订阅主题的充电管理平台内;
[0065] 在本发明中,充电设备和充电管理平台想要向对方发送数据时,需要首先发送一个发布主题至消息服务器,充电设备和充电管理平台想要接收对方发送的数据时,需要首先发送一个订阅主题至消息服务器;后续消息服务器依据发布主题和订阅主题内携带的充电设备的标识,来将数据转发至发送了对应订阅主题的对象内。举例来说,充电设备A发送了发布主题和业务数据,充电管理平台发送了携带有充电设备A的标识的订阅主题,则消息服务器即会将充电设备A发送的业务数据转发至充电管理平台内,若充电管理平台未发送订阅主题,或者发送的是携带有其他充电设备标识的订阅主题,则消息服务器不会将充电设备A发送的业务数据转发至充电管理平台内。
[0066] 当然,订阅主题的目的是为了订阅消息服务器转发的数据,因此,只需要在接收数据之前发送订阅主题至消息服务器即可,本发明不限定充电设备和充电管理平台发送订阅主题的具体时间。
[0067] 步骤s3:充电管理平台依据业务请求数据进行验证,验证通过后,发送发布主题以及业务处理数据至消息服务器,消息服务器将业务处理数据发送至发布了对应订阅主题的充电设备内;
[0068] 充电设备发送业务请求数据至充电管理平台后,充电管理平台需要验证业务请求数据内发送的身份信息、请求信息等是否符合预设的规范,验证通过后,充电管理平台才能生成相应的业务处理数据并发送至充电设备内。
[0069] 步骤s4:充电设备依据业务处理数据进行后续应用处理;其中,上述各个发布主题和订阅主题内均携带有充电设备的标识,消息服务器将发布主题对应的数据转发至与该发布主题携带有相同充电设备标识的订阅主题所对应的对象内。
[0070] 可以理解的是,这种采用发布和订阅的方式进行数据传输的方式是MQTT的典型特征,即本发明中,充电设备与充电管理平台之间依据MQTT进行数据通信,具有节约网络流量、解决网络粘包问题、异步IO通讯框架、通信稳定性和安全性高、具有身份验证功能等特点。本发明采用MQTT来提供充电设备发布信息及充电设备接收充电管理平台发送的远程控制指令等信息的连接通道。即离散的充电设备和充电管理平台之间的遥信遥测遥控信息的通信均采用MQTT协议进行传输。因此,将MQTT协议应用于充电设备与充电管理平台之间,相对于目前采用的基础通信协议来说,能够尽可能避免网络粘包的问题,且减少网络流量并且提高数据传输的稳定性和安全性。
[0071] 需要注意的是,在基于MQTT的通信过程中,充电设备向充电管理平台发送的数据为上行数据,充电管理平台向充电设备发送的数据为下行数据。
[0072] 充电设备和充电管理平台在进行数据传输时,传输的数据有主题和业务数据两类,充电设备和充电管理平台需要首先发送发布主题和业务数据至消息服务器,之后通过订阅主题来订阅消息服务器中的相应数据。
[0073] 主题(Topic)分为:业务主题、遗嘱主题、注册主题、广播主题定义四大部分。
[0074] 其中,业务主题采用三级主题模式,一级为设备编号或设备ID(即前文提到的充电设备的标识),二级为业务传输方向主题,三级为交互业务大类型(用来表明该主题对应的业务数据的类型)。一级主题定义:设备编号或客户端ID,依据数据的类型选择包含设备编号还是客户端ID。二级主题定义:数据是上行还是下行,即数据的传输方向,参见表1所示,表1为业务主题中的二级主题的示意表。三级主题定义:传输数据对应的业务类型,参见表2所示,表2为业务主题中的三级主题的示意表。
[0075] 表1业务主题中的二级主题的示意表
[0076]定义 描述 设备端 平台端
c2s 管理数据上行数据 发布 订阅
s2c 管理数据下行数据 订阅 发布
[0077] 表2业务主题中的三级主题的示意表
[0078]
[0079]
[0080] 举例来看,例如:充电设备123456789的登录鉴权发布主题为:
[0081] 123456789/c2s/业务类型1缩写
[0082] 例如:充电设备123456789的启动充电发布主题为:
[0083] 123456789/c2s/业务类型2缩写
[0084] 例如:充电设备123456789的登录订阅主题为:
[0085] 123456789/s2c/业务类型3缩写
[0086] 例如:充电设备123456789的启动充电订阅主题为:
[0087] 123456789/s2c/业务类型4缩写
[0088] 另外,遗嘱主题定义:设备ID/遗嘱类型描述;遗嘱类型描述表明业务类型为遗嘱。
[0089] 例如:充电设备123456789的遗嘱主题为:
[0090] 123456789/遗嘱类型缩写
[0091] 其中,注册主题定义:
[0092] 充电设备注册时候,因为没有分配设备编号,要使用初始化注册码,作为主题中充电设备的标识。
[0093] 例如:充电设备初始化注册码为12345678注册发布主题为:
[0094] 12345678/c2s/注册主题描述,reg表示的是当前业务类型为注册。
[0095] 充电设备注册订阅主题为:
[0096] 12345678/s2c/注册主题描述
[0097] 广播主题定义:
[0098] 充电设备订阅广播主题,接收充电管理平台发起的广播业务数据。
[0099] 定义:b/s2c/广播主题
[0100] 当然,以上仅为几种具体实施例,具体应用时,主体的内容根据充电设备与充电管理平台之间的数据传输性质进行设定。
[0101] 另外,本发明前述提到的发布主题,指的是发送主题的一方(例如充电设备)之后想要执行的操作为发布,订阅主题指的是发送主题的一方(例如充电管理平台)之后想要执行的操作为订阅。即具体的,对于充电设备来说,其发布主题的二级主题为c2s,订阅主题的二级主题为s2c;对于充电管理平台则相反,其发布主题的二级主题为s2c,订阅主题的二级主题为c2s。但前述提到的发布主题和订阅主题并未限定为业务主题还是注册主题等。
[0102] 在一种优选实施例中,上述业务请求数据包括注册申请数据,注册申请数据包括充电设备厂商编码、初始网络注册码、临时预授权码以及充电设备识别码;所述临时预授权码用于作为密钥加密所述注册申请数据;
[0103] 业务处理数据包括注册激活数据,注册激活数据包括设备编号以及授权码;
[0104] 步骤s3中,充电管理平台依据业务请求数据进行验证的过程包括:
[0105] 依据临时预授权码解密业务请求数据进行身份验证,验证通过后,生成设备编号以及授权码,并使用临时预授权码加密设备编号以及授权码,得到注册激活数据;
[0106] 步骤s4中,后续应用处理包括:依据临时预授权码解密注册激活数据,得到设备编号以及授权码;保存设备编号以及授权码。
[0107] 可以理解的是,充电设备在运行之前,为了使充电管理平台能够对充电设备进行管理,充电设备需要首先在充电管理平台进行注册。注册时,充电设备需要发送携带有自身身份信息的注册申请数据至充电管理平台,充电管理平台对注册申请数据中的身份信息进行验证,验证通过后,生成与充电设备唯一对应的设备编号和授权码,并将其发送至充电设备内保存。当然,充电管理平台内也会保存注册成功后的充电设备的各项信息。充电设备接收到充电管理平台发送的设备编号以及授权码后,需要将其永久保存至自身的存储区域内,保证其任何情况下都不被覆盖和灭失;若设备编号或授权码灭失,则需要人工索要初始网络注册码重新进行注册。另外,上述过程中,充电设备是在上电后主动发起注册申请,这种方式相比人工发起注册申请的方式,自主性和便利性更高。另外,上述注册申请数据中的充电设备识别码指的是能够表征充电设备身份的、与充电设备一一对应的数据,例如可以为充电设备的硬件指纹。并且,为了保证充电设备与充电管理平台之间数据传输的可靠性,尽可能避免受到恶意攻击后的数据泄漏,本实施例采用对注册时的数据进行加密的方式,即通过临时预授权码对注册申请数据和注册激活数据进行加密;这种方式提高了充电设备与充电管理平台在注册过程中数据传输的安全性和可靠性。
[0108] 参见表3和表4所示,表3为充电设备在线注册时的注册申请数据示意表;表4为充电设备在线注册时的注册激活数据示意表。
[0109] 表3充电设备在线注册时的注册申请数据示意表
[0110]序号 参数名称 是否必填
1 充电设备厂商编码 是
2 ESAM序列号 否
3 网络注册码 是
4 临时预授权码 是
5 认证激活标识 是
6 接入单元的硬件指纹 是
7 软件版本号 否
8 软件CRC32校验和 否
9 软件日期版本号 否
10 充电设备接口数量 是
11 网卡MAC地址 否
12 经度 否
13 纬度 否
14 高度 否
[0111] 当然,注册申请数据还可包含其他类型的数据,以上仅为一种具体实施例,本发明不限定注册申请数据的具体内容。
[0112] 另外,若充电设备注册失败的话,充电管理平台可以发送注册失败原因至充电设备,使充电设备能够根据失败原因进行下一步处理,例如再次发起注册等。注册周期推荐为:同一充电设备多次注册间隔时间要大于60S。当然,这里的注册间隔的数值本发明不作限定。
[0113] 另外,充电设备在进行初次激活时(即表3中的认证激活标识为0),则注册申请数据中可以填ESAM序列号来表明充电设备身份;非初次激活时(即表3中的认证激活标识为1),则注册申请数据中可以填原充电设备编号表明充电设备身份。当然,也可采用其他能够表明充电设备身份的标识,本发明对此不作限定。
[0114] 表4充电设备在线注册时的注册激活数据示意表
[0115] 序号 参数名称 是否必填1 成功标识 是
2 失败原因 是
3 设备编号 是
4 授权码 是
[0116] 当然,注册激活数据还可包含其他类型的数据,以上仅为一种具体实施例,本发明不限定注册激活数据的具体内容。
[0117] 进一步的,步骤s4中,充电设备保存设备编号以及授权码之后还包括:
[0118] 充电设备依次发送发布主题、注册确认上行数据以及订阅主题至消息服务器;充电管理平台发送订阅主题至消息服务器,消息服务器转发注册确认上行数据至发送了对应订阅主题的充电管理平台。
[0119] 可以理解的是,为了保证充电设备能够接收到充电管理平台发送的注册激活数据,因此,在充电设备接收到注册激活数据后,需要返回一个注册确认上行数据至充电管理平台,来告知充电管理平台自身已接收到注册激活信息。从而提高充电设备与充电管理平台之间注册数据传输的可靠性以及注册成功的概率,并且也能够告知充电管理平台,充电设备已经成功激活,从而使充电管理平台内可以及时得知充电设备的状态并据此对充电设备进行管理。
[0120] 另外,为了进一步提高注册的可靠性,优选在充电管理平台订阅注册确认上行数据后,发送发布主题和注册确认下行数据至消息服务器;消息服务器转发注册确认下行数据至发布了对应订阅主题的充电设备。
[0121] 即在本实施例中,采用了复确认的方式,使充电设备能够得知充电管理平台是否接收到了自己返回的注册确认上行数据,因为,若充电管理平台未接收到充电设备发送的注册确认上行数据的话,充电管理平台即会认为注册失败,这种情况下,即使充电设备已经接收到注册激活数据,后续也无法正常的与充电管理平台进行通信以及受到充电管理平台的管理。因此,为了避免上述情况,充电设备需要保证充电管理平台接收到自己发送的注册确认上行数据,充电设备发送注册确认上行数据后,若超出预设时间长度,仍未接收到充电管理平台发送的注册确认下行数据的话,在确保自身与充电管理平台未断开连接的情况下,充电设备可以继续重复发送注册确认上行数据,直至接收到充电管理平台发送的注册确认下行数据为止。从而保证了注册的成功率。
[0122] 为了实现上述复确认的机制,发送消息时会在消息中设置Qos级别为1,表明消息接收者如果没有响应或者响应丢失,消息发送者会再次发送以保证消息接收者至少会收到一次。接收者接收到QoS为1的消息后,会立即处理该消息,比如把这个消息发送给订阅该主题的接收端(充电设备或充电管理平台只有在订阅某信息后,才能接收到其订阅的信息),并回复响应。The duplicate(DUP)flag,用来标记PUBLISH被重新分发的情况。仅仅是为了内部使用的目的,并且当QoS为1时,该消息不会被broker或者client处理。接受者都会发送响应消息,而不管DUP flag。
[0123] 参见图4所示,图4为本发明提供的一种充电设备与充电管理平台间的注册流程示意图。参见表5和表6所示,表5为充电设备向充电管理平台发送的注册确认上行数据的示意表;表6为充电管理平台向充电设备发送的注册确认下行数据的示意表。
[0124] 表5充电设备向充电管理平台发送的注册确认上行数据的示意表
[0125]序号 参数名称 是否必填
1 ESAM序列号 否
2 网络注册码 是
3 成功标识 是
4 失败原因 是
[0126] 另外,充电设备在进行初次激活时,则注册确认上行数据中可以填ESAM序列号来表明充电设备身份;非初次激活时,则注册确认上行数据中可以填原充电设备编号表明充电设备身份。当然,也可采用其他能够表明充电设备身份的标识,本发明对此不作限定。
[0127] 表6充电管理平台向充电设备发送的注册确认下行数据的示意表
[0128]序号 参数名称 是否必填
1 ESAM序列号 否
2 网络注册码 是
3 成功标识 是
4 失败原因 是
[0129] 另外,充电设备在进行初次激活时,则注册确认下行数据中可以填ESAM序列号来表明充电设备身份;非初次激活时,则注册确认下行数据中可以填原充电设备编号表明充电设备身份。当然,也可采用其他能够表明充电设备身份的标识,本发明对此不作限定。
[0130] 在优选实施例中,注册完成后,上述业务请求数据还包括登录申请数据,登录申请数据包括设备编号和登录令牌;登录令牌的获得过程为:将授权码作为密钥,对发布时间戳与充电设备识别码之和进行加密,加密后的结果为登录令牌;
[0131] 业务处理数据还包括登录回复数据,登录回复数据包括通过授权码加密后的客户端ID、传输密钥以及初始化向量;
[0132] 后续应用处理还包括:使用授权码解密登录回复数据,得到客户端ID、传输密钥以及初始化向量并保存;依据客户端ID进行业务发布和订阅;依据传输密钥加密业务发布时的发布数据以及解密业务订阅时的订阅数据。
[0133] 参见图5所示,图5为本发明提供的一种充电设备与充电管理平台间的登录流程示意图。
[0134] 可以理解的是,为了减少资源浪费,充电设备并非实时连接充电管理平台,而是仅在有待充电设备接入充电设备时,充电设备再连接充电管理平台,从而降低充电设备和充电管理平台的能耗。为实现上述目的,可令注册完成后,充电设备在每次链接充电管理平台时均进行登录鉴权业务,登录鉴权业务(简称登录业务)的目的是为了充电设备的设备编号、充电设备识别码(例如硬件指纹)以及授权码是否合法,并得到充电管理平台下发的客户端ID以及传输密钥,用于后续的业务发布和订阅操作。假如登录时的验证不通过,则充电管理平台优选返回失败原因,此时充电设备不能上传任何业务数据至充电管理平台,之后充电设备可以根据失败原因和返回结果继续发起登录,直到登录成功为止。登录周期推荐为:同一设备连续多次发起登录的间隔时间要大于30S。当然,本发明不限定登录周期的具体数值。
[0135] 另外,充电设备在发送登录申请数据后,可以开始计时,若超出设定的时间阈值后仍未接收到充电管理平台发送的登录回复数据,则认为此次登录失败,之后可以重复进行登录。当然,具体采用哪种方式判断是否登录失败,本发明不作限定。
[0136] 其中,客户端ID即通信中身份唯一标识的ClientId,在后续充电设备每次发布和订阅信息时,其发布和订阅主题内通常均需要使用该参量。充电设备每次登录时分配给充电设备的客户端ID的值均会改变。并且,充电设备在发起设备注册业务以及设备登录业务时,假如需要输入ClientId的话,由于此时还没有授权的ClientId,充电设备可以自身临时随机生成16位字符当做ClientId发起通信请求,待充电设备登录后获得正式授权ClientId,再使用新的ClientId来发起通信请求来发送和订阅其它业务数据。传输密钥是用于在登陆后,充电设备与充电管理平台进行数据通信时,加密和解密通信数据的密钥,充电设备每次登录时发送给充电设备的传输密钥的值均会改变。初始化向量是用于加密过程中的混合加密的密钥,充电设备每次登录时发送给充电设备的传初始化向量的值均会改变;当然,对于不需要混合加密密钥的加密算法,可以不包含初始化向量。
[0137] 另外,在上述登录过程中,充电设备会利用授权码生成登录令牌(Token),来进行设备登录业务,登录令牌(Token)使用数字签名方式。签名规则为:sign=AES(设备发送时间戳+接入单元的硬件指纹)。这里以AES加密算法为例,也可以采用其他加密算法,本发明对此不作限定。上述过程中,参与加密的密钥和初始化向量均为授权码。
[0138] 参见表7和表8所示,表7为充电设备向充电管理平台发送的登录申请数据的示意表;表8为充电管理平台向充电设备发送的登录回复数据的示意表。
[0139] 表7充电设备向充电管理平台发送的登录申请数据的示意表
[0140]序号 参数名称 是否必填
1 设备编号 是
2 登录令牌 是
3 时间戳 是
4 IP地址 否
5 协议主版本号 是
6 协议次版本号 是
7 协议分支版本号 是
8 接入单元软件日期版本号 否
[0141] 表8充电管理平台向充电设备发送的登录回复数据的示意表
[0142]序号 参数名称 是否必填
1 成功标识 是
2 客户端ID 是
3 数据传输秘钥 是
4 初始化向量 是
[0143] 当然,以上仅为一种优选实施例,本发明不限定登录申请数据和登录回复数据的具体内容。
[0144] 在一种优选实施例中,参见图6所示,图6为本发明提供的一种充电设备与充电管理平台间的时钟对时流程示意图。注册完成后,充电设备发布登录申请数据之前还包括:
[0145] 充电设备发送发布主题、时钟查询请求数据以及订阅主题至消息服务器;
[0146] 充电管理平台发送订阅主题至消息服务器,消息服务器转发时钟查询请求数据至发送了对应订阅主题的充电管理平台;
[0147] 充电管理平台接收时钟查询请求数据后,发送发布主题以及定时数据至消息服务器;消息服务器转发定时数据至发送了对应订阅主题的充电设备;
[0148] 充电设备依据定时数据调整自身时钟。
[0149] 可以理解的是,由于充电设备和充电管理平台分别设置有自身的时钟,并依据自身时钟进行操作,因此,这种情况下,若两者的时钟存在较大的误差,可能会由于时钟不一致导致登录鉴权失败的情况出现。例如,充电设备发起的登录申请数据中含有时间戳,用于表明登录申请数据的发送时间,但是由于充电管理平台可能同时接收到多个充电设备发送的登录申请数据,若某一台充电设备与充电管理平台的时间差异较大,导致充电管理平台认为该台充电设备发送登录申请数据的时间比其他充电设备晚,因此优先处理其他充电设备的登录请求的话,则就有可能导致出现登录超时导致登录失败的情况。因此,为了避免由于时钟差异导致的登录失败的情况,在登录前,充电设备可以首先与充电管理平台进行对时,充电设备的时间和充电管理平台的时间之间的误差不能大于3分钟,否则会造成设备登录鉴权失败。当然,这里的误差阈值也可以为2分钟,或者其他数值,本发明对此不作限定。
[0150] 另外,对于未安装卫星对时装置或有时钟同步需求的充电设备,平台需要提供完善的时钟同步应用,保证与平台时钟一致。上述时钟对时操作,充电设备随时可以发起:充电设备登录前,登录后都可以随时发起。对时周期推荐为:间隔24小时请求一次,不能对时过于频繁,当然,本发明对此不作限定。时钟查询请求数据和定时数据通常不需要加密传输,当然是否加密本发明不作限定。
[0151] 参见表9和表10所示,表9为时钟查询请求数据的示意表;表10为定时数据的示意表。
[0152] 表9时钟查询请求数据的示意表
[0153]序号 参数名称
1 操作流水号
2 控制指令类型
[0154] 表10定时数据的示意表
[0155] 序号 参数名称1 操作流水号
2 当前时间
[0156] 当然,以上仅为一种优选实施例,本发明不限定时钟查询请求数据和定时数据的具体内容。
[0157] 在一种优选实施例中,登录完成后,充电设备向充电管理平台发布数据时,还包括:
[0158] 充电管理平台检测自身已经连接的全部充电设备中,是否有充电设备持有与上述新接入的充电设备相同的客户端ID,若有,充电管理平台将检测到的该充电设备与自身的连接断开。
[0159] 可以理解的是,由于客户端ID是用于表明客户端身份的,因此理论上客户端ID应该是唯一的,但是部分情况下,也可能出现客户端ID重复的情况,这种情况下,为了避免重复的客户端ID均接入充电管理平台导致的混乱,需要令充电管理平台与同一个客户端ID仅建立一个连接,新连接接入时,需要首先将同一客户端ID的旧连接断开,从而保证充电管理平台内依据客户端ID进行的处理的正常进行。
[0160] 在一种优选实施例中,参见图7所示,图7为本发明提供的一种充电设备与充电管理平台间的心跳检测流程示意图。登录完成后,还包括:
[0161] 充电设备周期性(例如每隔50S~60S,本发明对此不作限定)通过消息服务器发送发布主题、心跳包和订阅主题至充电管理平台;
[0162] 充电管理平台向消息服务器发送订阅主题,检测是否每隔一个时间周期即接收到消息服务器转发的充电设备发布的心跳包,若超出时间周期未收到心跳包,则判定充电设备与自身断开连接,若未超出时间周期即收到心跳包,则回复心跳响应至消息服务器,消息服务器转发心跳响应至发布了对应的订阅主题的充电设备;
[0163] 充电设备判断自发布心跳包起、预设时间长度内是否接收到消息服务器转发的心跳响应,若接收到,则自身与充电管理平台保持连接,若未接收到,则自身与充电管理平台断开连接。
[0164] 可以理解的是,充电设备与充电管理平台之间的连接可能由于种种原因断开,为了及时发现连接掉线并及时进行处理,需要充电设备和充电管理平台之间进行心跳检测,从而提高充电设备与充电管理平台之间的连接的可靠性。参见表11所示,表11为心跳包的数据示意表。
[0165] 表11心跳包的数据示意表
[0166]
[0167] 当然,以上仅为一种优选实施例,本发明不限定时钟查询请求数据和定时数据的具体内容。
[0168] 其中,充电设备判断自发布心跳包起、预设时间长度内是否是否接收到消息服务器转发的心跳响应的过程可以为:充电设备自发布心跳包起开始按时钟计数,计数达到超时次数(例如3次),认为心跳超时,可以判定已经和充电管理平台失去连接。后续,充电设备可以自动关闭当前连接,并重新发起连接,在获得连接成功的响应后,向充电管理平台重新发起登录请求。
[0169] 或者,充电设备与充电管理平台断接后,也可由充电管理平台主动发起连接。
[0170] 即在另一优选实施例中,还包括:
[0171] 充电设备发布遗嘱主题以及遗嘱信息至消息服务器;
[0172] 充电管理平台发送订阅主题至消息服务器,接收消息服务器依据该订阅主题内包含的充电设备标识转发的遗嘱信息并保存;
[0173] 充电管理平台判定充电设备与自身断开连接后,还包括:
[0174] 充电管理平台调用充电设备对应的遗嘱信息,将调用的遗嘱信息通过消息服务器发布至自身连接的全部充电设备内,以及将充电设备的标识添加至自身的断开连接列表内,并周期性的发布连接请求至充电设备,直至与充电设备重新建立连接。
[0175] 可以理解的是,发布遗嘱信息是本方法依据MQTT协议的一个应用功能,充电设备发布遗嘱主题和遗嘱信息至消息服务器后,消息服务器会依据充电管理平台发送的订阅主题将遗嘱信息发送至充电管理平台内。当充电管理平台判定充电设备断开后,则调用该遗嘱信息,之后可以选择将该遗嘱信息发送至自身连接的全部充电设备进行显示,告知其他设备及用户该充电设备断接了,无法使用进行充电;这种一对多的设备管理方式,提高了充电管理平台对充电设备的管理集中度,方便了用户及时了解整个充电设备系统的使用情况。另外,充电管理平台还可以将该充电设备添加至自身的断开连接列表内,当然,若充电管理平台未设置断开连接列表,则不执行上述步骤;另外,充电管理平台还可以主动发起与充电设备的重新连接。调用遗嘱信息后,充电管理平台具体执行哪些操作本发明不作限定。
[0176] 通过以上方式,本发明在充电设备与充电管理平台断接后,可以主动进行重连,从而减少了充电设备断接的情况,提高了充电设备与充电管理平台之间的连接可靠性。
[0177] 另外,在其他实施例中,在进行上述心跳检测时,还可以同时发起充电设备的身份认证操作。即充电设备发送发布主题和终端认证请求至消息服务器,充电管理平台发送订阅主题来接收消息服务器转发的终端认证请求后,返回认证随机数。
[0178] 其中,一个数据包由:固定头(Fixed header)、可变头(Variable header)、消息体(payload)三部分构成,包括轻量级的machine-to-machine通信协议、publish/subscribe模式,且支持QoS。适合于低带宽、不可靠连接、嵌入式设备、CPU内存资源紧张的系统。
[0179] 本发明提供了多个层次的安全特性:网络层:有条件可以通过拉专线或者使用VPN来连接设备与MQTT代理,以提高网络传输的安全性。传输层:传输层使用加密是确保安全的一个好手段,可以防止中间人攻击(Man-In-The-Middle Attack)。客户端证书不但可以作为设备的身份凭证,还可以用来验证设备。应用层:MQTT还提供客户端标识(Client Identifier,即ClientId)以及用户名密码,在应用层验证设备。
[0180] 本发明支持两种层次的认证:传输层:传输层不仅使用加密通讯,还可以使用X509证书来认证设备。应用层:MQTT支持客户端ID、用户名密码以及X509证书,在应用层验证设备。
[0181] 其中,充电设备与充电管理平台在进行数据传输时传输的数据主要是在应用层中,应用层中的传输数据的格式结构为应用规约数据单元(Application Protocol Data Unit,APDU),应用规约数据单元包括业务类型标识(CMD)、充电设备编号(SE)、充电设备接口标识(IN)、时间戳(T)、序号(SN)、数据加密方式(E)和应用服务数据单元(Application Service Data Unit,ASDU);
[0182] 应用规约数据单元APDU通过报文数据描述语言(ProtocolBuffers,PB)进行描述,应用规约数据单元APDU的数据类型为两层组合的方式,第一层表示所有传输数据共有的属性(数据部头部内容,基本上就是根据第二层的业务数据提取的一串校验码,第二层代表传输数据中描述具体业务功能的属性(数据部内容)。
[0183] 其中,发布数据时,发布以上两层数据的方式为:将APDU的数据部业务信息序列化为Byte数组赋值给APDU第一层的dataArea(数据域)属性,然后再进行APDU的封装。订阅数据时,需要先反序列化APDU的第一层的信息,获得加密方式等信息;再根据第三级主题类型进行第二层数据域的具体业务信息反序列化得到相应的业务报文。
[0184] 这里的序列化指的是加密;即采用分段式加密的方式,先加密第一层的信息,然后以第一层的第三级主题类型等作为密钥的一部分再加密第二层。反序列化指的是解密,即先解密第一层的信息,得到第一层的第三级主题类型等,之后据此得到第二层的密钥解密第二层数据域的内容,得到上述具体的业务报文。
[0185] 可以理解的是,通过上述数据格式结构进行充电设备与充电管理平台之间的数据传输,能够减小充电设备与充电管理平台之间的数据量,实现小体量传输机制,提高充电设备与充电管理平台之间的数据传输效率。
[0186] 具体应用层数据结构基本要求如表12所示。表12为应用层数据结构(即应用规约数据单元的结构)。参见图8所示,图8为应用服务数据单元封装后的数据结构。
[0187] 表12应用层数据结构
[0188]序号 定义
1 业务类型标识
2 设备编号
3 接口标识
4 设备类型
5 时间戳
6 序列号
7 数据加密方式
8 应用服务数据单元
[0189] 其中,应用服务数据单元内包含的内容即为充电设备和充电管理平台之间需要传输的具体业务内容等。
[0190] 另外,同一充电站内部可以包括多个不同类型的充电设备(例如,群管群控、一桩一枪、一桩多枪等),而且每个充电设备可以包含不同的充电接口,如图1所示,图1为充电管理平台管理充电设备的逻辑示意图。在用户进行启动/停止充电设备时,其扫码或者刷卡是以充电接口为识别点,进行相应的启动/停止控制。充电接口为汽车充电口接触或者实际向电动汽车提供电源的设备。充电设备(EVSE)和充电接口为1:N的关系,充电设备采用统一资产管理码-设备编号。充电接口编号:若充电设备为单接口设备,直接编号为1;多接口充电设备的充电接口编号自1开始,以此顺序编写至N。以编号为0作为各充电接口的共用单元编号。
[0191] 上述时间戳T依据国际约定,表示从1970年1月1日0点0分0秒(UTC/GMT的午夜)开始所经过的毫秒值。当然,也可采用其他时间戳定义,本发明对此不作限定。
[0192] MQTT中的传输层中需要进行加密操作,这里的传输层首先需要采用TLS(Transport Layer Security,安全传输层协议)来在充电设备与充电管理平台间提供保密性和数据完整性。该协议由两层组成:TLS记录协议(TLS Record)和TLS握手协议(TLS Handshake)。在握手的时候便可以创建安全连接,使得黑客无法窃听或者篡改内容了。使用TLS的时候有以下注意点:1.尽可能使用高版本的TLS;2.验证X509证书链防止中间人攻击;3.尽量使用有CA发布的证书;4.TLS会增加连接时开销,对低运算能力的设备而言是额外的负担,不过如果设备是长连接的话就会避免反复连接的开销。
[0193] 另外,充电设备与充电管理平台间的数据传输时,除传输层采用的TLS以外,为了保证数据的安全性,其应用层中的业务数据,也需要进行加密操作。其中,本发明在注册过程中,加密的密钥采用临时预授权码;登录过程中,加密的密钥采用注册时返回的授权码;登录完成后,加密的密钥采用登录时返回的传输密钥。
[0194] 应用层中的加密方式可以采用AES加密方式,具体的加密流程如图9所示,图9为AES加解密流程图。明文P通过密钥K进行AES加密,得到密文C,之后通过网络传输至接收方后,接收方通过密钥K进行AES解密,得到明文P。
[0195] 数据传输加密使用对称加密算法AES 128位加解密,加密模式可以采用AES中的CBC(Cipher Block Chaining,加密块链)模式,填充模式采用PKCS5Padding方式;当然,以上仅为优选实施例,具体采用哪种模式本发明不作限定。
[0196] 为方便理解,以下为数据加密示例:
[0197] 数据密钥:1234567890abcdef
[0198] 初始化向量:1234567890abcdef
[0199] 明文:F0F1F2F3F4F5F6
[0200] 密文:E231A717CFCC3766B04EFED11E596BB4
[0201] 当然,也可采用其他加密方式,具体的,可以设置多种加密类型,并通过代码表示所选择的加密方式,举例来看,参见表13所示,表13为加密规则码示意表。当然,也可采用表13中的加密方式以外的方式进行加密。
[0202] 表13加密规则码示意表
[0203]
[0204]
[0205] 基于以上思想,本发明中涉及的参数设置可以如表14所示,表14为参数设置表格。
[0206] 表14参数设置表格
[0207] 描述 设备端 平台端发布主题 设备ID/二级/三级 设备ID/二级/三级
订阅主题 设备ID/s2c/# 设备ID/c2s/#
服务质量 1 1
[0208] 当然,以上仅为一种具体实施例,本发明不限定具体应用时的参数设置类型。
[0209] 本发明还提供了一种充电设备与充电管理平台间的互信认证系统,包括:
[0210] 充电设备,用于充电设备发送发布主题、业务请求数据以及订阅主题至消息服务器;依据业务处理数据进行后续应用处理;
[0211] 消息服务器,用于接收充电设备发送的发布主题、业务请求数据以及订阅主题;转发充电设备发送的发布主题至充电管理平台,告知充电管理平台当前的业务类型;将业务请求数据转发至发送了对应订阅主题的充电管理平台内;接收充电管理平台发送的订阅主题、发布主题和业务处理数据,将业务处理数据发送至发布了对应订阅主题的充电设备内;其中,上述各个发布主题和订阅主题内均携带有充电设备的标识,消息服务器将发布主题对应的数据转发至与该发布主题携带有相同充电设备标识的订阅主题所对应的对象内;
[0212] 充电管理平台,用于发布订阅主题至消息服务器;依据业务请求数据进行验证,验证通过后,发送发布主题以及业务处理数据至消息服务器。
[0213] 其中,本发明提供的充电设备与充电管理平台间的互信认证系统是用于实现上述提供的充电设备与充电管理平台间的互信认证方法,因此,充电设备与充电管理平台间的互信认证系统与以上充电设备与充电管理平台间的互信认证方法之间一一对应。
[0214] 以上的几种具体实施方式仅是本发明的优选实施方式,以上几种具体实施例可以任意组合,组合后得到的实施例也在本发明的保护范围之内。应当指出,对于本技术领域的普通技术人员来说,相关专业技术人员在不脱离本发明精神和构思前提下推演出的其他改进和变化,均应包含在本发明的保护范围之内。
[0215] 还需要说明的是,在本说明书中,诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。