充电桩状态监测与远程维护技术探析

国网电动汽车服务（福建）有限公司 陈 涵 郑蔚蔚 叶必超

1 充电桩状态监测与远程维护系统的总体设计

设计要求。主要是为满足软件的状态监测及远程维护，对充电桩管理系统的要求在于：可靠性。在满足预定动能前提下要确保自身稳定高效运转，同时又可将充电桩源代码带来的影响降至最低，规避因管理系统产生软件运行故障；多能多样化。针对充电桩软件状态监测系统开发主要是为节约人力资源，所以要求数据能够全面、功能能够多样，不仅可实现充电桩软件运行状态监测，同时又能实现对远程软件的维护；通用性。这一类管理系统需满足各种桩体的需求，并可预留可扩展接口，基于不同的管理对象需求让功能更加具有针对性[1]。

总体方案。针对充电桩软件状态监测与远程维护系统，主要是为改善充电桩本身软件故障频繁出现的状况，解决实际运行效率较低问题（图1）。

图1 功能结构图

2 充电桩状态监测数据采集技术

为全面监测软件实际运行状态，本次研究中选择嵌入式充电桩为基础平台，并考虑到软硬件的架构，这样就可确保监测对象满足实际的要求。

在软件的实际运行过程及远程维护中监测数据是基础，所以对监测对象的选择应尽可能覆盖整个软件的运行过程[2]。如，可考虑到驱动事件监测中的电平事件。通过充电桩硬件架构可知，针对部分外设、主要指继电器组，通过简单的驱动电路和单片机IO 引脚相连，就相当于继电器和IO 引脚能相互直接的影响，继电器的通断控制单片机引脚电平相对应的高低，单片机引脚电平变化直接控制这继电器的通断，这时可直接利用引脚电平来实现主控板与外设间的交互。主控板直接与外设相互连接的单片机引脚设置成为中断源，一旦在检测中发现电平变化，就需直接执行中断处理函数，一般利用外设引起的电平事件可轻松实现对软件运行流程的改变。

在充电桩中有多个继电器搭载，每一个继电器对应一个事件，如是否按下急停按钮、是否已连接充电电缆、是否开启充电进程等。以电缆实际连接为例，相对应的单片机物理管教是端口D 引脚10，在充电前用户就需将充电枪直接插入到充电口中，这样可拦截充电电缆，然后继电器吸合，引脚PD.10电平就会逐渐从低到高，主程序也会直接进入到电缆连接成功的子流程，执行等待充电开启的任务。在充电枪拔下后，断开充电电缆、断开继电器，那么引脚的PD.10电平就会从高逐渐变低，主程序停止原本充电流程，执行充电结束任务，如上传交易记录、消费金额结算等。

图2 嵌入式充电桩硬件结构图

图3 嵌入式充电桩软件结构图

3 充电桩远程维护实现方法

充电桩在状态监测实施后，为落实远程维护技术，要重点考虑到软件故障预警功能的实现及远程查看功能的实现，这样才有利于远程维护技术的有效使用。

3.1 软件故障预警功能实现

3.1.1 软件故障预警方法

针对软件故障预警方法，考虑到本研究选择的监测对象是基于控制流与数据流，且需对软件实际运行状态进行重点关注。因包含了变量数值变化情况、函数调用关系等，所以在实际分析后要考虑到基于控制流模型和抽象解释模型的方式来进行处理[3]。

3.1.2 预警信息查询过程

在程序中如软件运行出现故障，就可选择利用预警代码实现预警信息的自动生成，开发人员按照信息复现故障产生过程，最终就可基于故障的原因实现对代码的维护及优化处理。

预警信息主要是针对发生故障时软件运行状态的描述，如故障类型、发生时间、日志等。预先规定故障代码，实现故障类型的区分。如，0x01代表因电能统计出现错误从而导致的金额问题；0x02代表因无法跳转导致的金额问题。基于软件中对时间信息的存储方式判别，主要是对故障发生的时间基数及二次相对量的记录，由于二次技术已在日志中存储就不需再次记录，直接将三个数据相加就可获取故障产生的具体时间。对于故障日志，也就是故障发生时的日志内容，在本次预警软件中软件故障不会卡死程序，所以可不断更新日志。如没有及时进行保存，新产生的日志就会覆盖过往日志，导致故障发生前无法获取程序运转流程，最终影响故障处理。

在本次研究中，直接在外部存储器EEPROM 开辟固定的空间，然后按照发生时间、故障类型、故障顺序，基于字节作为单位来进行存储。在发生故障后程序就会立即在指定程序写入预警信息，并针对与服务器端上位机是否建立连接来进行检测。只要判断连接建立就可主动上报预警信息，开发人员就会了解充电桩软件的异常运行问题。当然作为开发人员也可针对存储器指定区域进行自主查看，以此来判断是否有故障的出现，对于软件的运行状态加以把控。

3.2 远程查看功能实现

程序日志主要对软件实际运行过程描述，如果实际问题针对性不强就需考虑到远程维护，所以将日志作为基础，然后结合具体的需求可获取额外的信息。如果可利用上位机模块从本地充电桩采集对应的制定数据，就能实现维护灵活性的提升，对应增加远程查看功能。

3.2.1 变量数值查看

在日志中变量数值的查看可看成为一种事件，主要是了解驱动程序的运行或执行流程如何改变，变量查看主要是基于实际情况，从而实现某些日志没有体现的信息查看，关注的是变量本身的数值变化情况。虽然两者的使用目的不一样，但都是描述变量，实际监测的内容相同，都囊括了内存空间、地址、数值等内容[4]。

通过变量查看功能就可满足程序任意变量数值的获取，也不需考虑存储区域，如全局与静态变量都是在静态区域中存在；同样也不需考虑变量的意义，如代表实际充电的电压、电流等，基于标志位形式来表示充电口的实际状态、启动方式、充电模式等，表示程序执行情况的定时器技术、循环次数等。只要能够获取变量地址就可实现变量数值的获取。

对于服务器端的上位机和本地充电桩间基于变量查看的通信协议见表1。其中0xA5代表上位机模块下发查看变量指令，开/停位为1代表的是开启这一变量查看，为2则代表的暂停查看，为3代表停止查看。在桩接收后就分别执行对应的代码段。0x25代表充电桩上传具体变量数值，不同的变量数据长度要求结合实际情况来做好数据帧个数的计算。

表1 变量查看功能的通信协议

3.2.2 CPU 占用率查询

针对嵌入式系统中系统是否能够长时间稳定运行，需通过CPU 占用率来进行评价，体现的是空间与繁忙程度。在相同时刻只有一个任务会占据CPU，但嵌入式系统可满足多任务切换及抢占式任务的调度，这样就可满足不同时刻CPU 任务分配的实现。一般CPU 处于任务占用或是空闲状态，占用率就是执行任务的时长与总执行时长的比值。因本次研究的硬件平台会有涉及到操作系统，所以CPU任务占用状态就是软件处于充电流程中，CPU 空闲状态就是软件处于空循环之中。因为空循环执行时间获取更加容易，占用率的计算公式就可以调整为：CPU 占用率=（CPU 总执行时长-CPU 空闲时长）/CPU 总执行时长。

在本文的研究分析中，基于小时数来进行统计，当充电桩接受到对CPU 占用率查询指令后，就会将当前重时长不到1h 的时间段内及之后完整4h 的占用率直接上传，这样就会让上位机直接呈现出一段时间之中CPU 具体的任务执行情况。表2为服务器端上位机与本地充电桩间的CPU 占用率查询的通信协议，其中0xA6代表上位机下发的CPU 占用率指令的查询情况，0x26代表的是上传这一段时间内实际的CPU 使用数值。

表2 CPU 占用率查询功能的通信协议

本章节主要是针对软件故障预警以及远程查看的维护方式进行分析。其中软件故障预警主要是基于控制流以及抽象高洁丝模型来进行设计的，这样的方式就可通过预警信息复现故障原因定位与故障过程；远程查看则是基于变量查询与CPU 占用率查询，实现日志查询功能的辅助，最终满足软件运行的全面监测需求[5]。