[0044] 以下结合附图1‑3对本申请作进一步详细说明。
[0045] 本申请实施例公开一种基于边缘计算的电动车物联管控方法。参照图1‑3，基于边缘计算的电动车物联管控方法包括边缘节点处理和后台处理，其中边缘节点处理通过路侧单元RUS实现，路侧单元RUS通过DSRC协议与安装于电动车上的OBU单元通信，OBU单元连接多个安装于电动车的传感模组，以将车体信息发送至路侧单元RUS进行边缘计算；而后，路侧单元RUS通过无线网络将边缘节点处理后的信息发送监管平台(如：云台)进行后台处理。
[0046] 边缘节点处理包括：
[0047] 获取车体信息；以及，
[0048] 判断车体信息是否符合预设的异常条件，如果是，则汇总车体信息、异常判断结果及本节点的识别信息，并统称汇总后的信息为问题信息集，并发送至预设的监管平台进行后台处理。
[0049] 上述车体信息包括电动车的身份信息、位置信息、速度信息、电池信息、刹车信息及车体完整度信息。其中，身份信息包括由生产厂家在在电动车出厂之前写入电动车的OBU单元，用以区分各个电动车的序列号及品牌；位置信息由安装于电动车上的GPRS模块获取、速度信息由安装于车速传感器获取、电池信息由蓄电池电量传感器和电压/电流变送器组合监测电动车的电池获取；刹车信息由一集成板连接联动于刹车的电位器配合速度信息判断获取，如：电位器输出1，速度减小10，表示刹车度5％；车体完整度根据多个安装于车壳内部的压力传感器的受压数值确定，如：1非关键节点传感器受压10，则损坏5％；1关键节点传感器受压10，则表示损坏20％；各个传感器获取相应信息后输出至OBU单元，以保证后续边缘计算顺利执行。
[0050] 基于上述车体信息，异常条件包括：
[0051] 1、电池电量流失速率超出预设阈值、电量指数下跌、电压/电流快速激增超出正常阈值；
[0052] 2、电池信息正常，但速度为0；
[0053] 3、刹车信息以非预设数字关系变化且超出最大允许值；
[0054] 4、车体完整度被破坏超出阈值且多点传感器被触发，或指定关键传感器被触发超出阈值。
[0055] 异常条件为相关工作人员通过云台预设置于路侧单元RUS，保证路侧单元RUS可初步处理部分信息，减小大量非必要数据的上传，以减小后台支撑用服务器的压力。为区分各个RUS单元，其预设置上述节点识别信息，识别信息包括节点的识别序列号和位置信息，位置信息可拓展GPRS模块获取，也可由工作人员根据其节点安装位置人工写入。
[0056] 经各个节点异常条件判断后，如果车体信息不符合异常，则保持设定频率与车体上的OBU单元做数据交互，并在脱离通信距离后释放连接；如果符合异常，则按照上述交由后台处理。
[0057] 后台处理包括：
[0058] 获取问题信息集；以及，
[0059] 判断预设的GIS地图中是否存在对应识别信息的信息节点(根据地图坐标和节点位置确定)，如果有，则存储问题信息集至对应的信息节点；如果没有，则新建信息节点，并用于存储问题信息集。
[0060] 为节省后台成本，设置信息节点清理时间，如：对1年以上的数据清理。
[0061] 后台(监管平台)除按照坐标归档数据外，还需要对数据做分析，因此后台处理还包括：
[0062] 判断车体完整度是否低于预设的阈值，如果是，则判定问题信息集所对应车体出现事故性问题；如果否，则判断问题信息集所对应车体出现非事故性问题；
[0063] 对各个信息节点，于时间周期T1(如：1日历天数)内出现的非事故性和事故性车体的数量分别做统计；
[0064] 依据时间轴，以T1为单位时间，统计事故性车体的数量并生成图表；以及，[0065] 统计各个信息节点发生事故性车体的数量，并根据数量多少生成排名图表。
[0066] 其中，判断车体是否发生事故的阈值根据前述异常条件设定，如果问题信息集中有车体完整度符合异常这一信息，则直接确定为事故性问题车体。
[0067] 相关工作人员，如：交警，其在结合GIS地图后，可通过依据时间轴得到的事故性车体数量的图表，相对清晰的了解监管区域哪些时间更为容易出现事故；还可以通过排名图表，更为直观的了解监管区域的事故多发位置，以合适的分配相关警力对指定区域做管理，减小交通事故和经济损失。
[0068] 为更好的辅助交警等相关人员，后台处理还包括：
[0069] 确定产生问题信息集的节点周边X公里内的标志性建筑(学校、医院等)；其中X为非0数值，如：0.5；
[0070] 对有同一标志性建筑的问题信息统计，并累计事故性车体数量，得到各标志建筑附近发生事故数量的排名；以及，
[0071] 每隔时间周期T4(如：1月)发送各标志建筑附近发生事故数量的排名至用户；该步骤通需用户手机和电动车的身份信息做绑定，以便后台发送相关信息。
[0072] 根据上述内容，本申请不仅可更好的辅助交警了解事故多发区，还可用于对用户做提示，从而效果相对更佳。
[0073] 进一步的，后台处理还包括：
[0074] 获取得到问题信息集时所属边缘节点的天气类型；以及，
[0075] 确定各个品牌所对应的车体信息符合异常条件时的天气类型，并按照天气类型分别统计数量，生成环境干扰后图表。
[0076] 环境干扰后图表一方面可供给至各个电动车品牌，方便其总结其自身产品在各种天气下的问题大小，引导工作改进方向；另一方面，其可供给用户和相关人员做参考，用于注意在各个天气下使用电动车。
[0077] 因此，后台处理还包括：
[0078] 每隔时间周期T3(如：一季度)，根据环境干扰后图表计算各个天气类型各个品牌车体出现事故的几率，生成环境干扰事故几率信息，并发送至用于做边缘计算的边缘节点或电动车用户；
[0079] 对应的边缘节点处理还包括当获取环境干扰事故几率信息，则发送其至电动车用户。
[0080] 环境干扰事故几率信息的计算方法为：
[0081] 某一天气类型某一品牌车体出现的事故的数量/该品牌车体出现事故的总数量。
[0082] 如果环境干扰事故几率信息由后台发送至用户，则直接通过短信的信息发送至用户的手机，为此，用户手机需要和电动车的身份信息做绑定。如果环境干扰事故几率信息由边缘节点发送，则为广播形式，路侧单元RSU交互至与之连接的OBU单元，为此相应车体上可安装连接OBU的小型显示器，以接收提示。
[0083] 为方便厂家更好的对产品做改进，也为电动车用户提供更多的购物参考依据，后台处理还包括：
[0084] 统计时间周期T2(如：一季度)内各个品牌出现非事故性和事故性车体的数量，并生成各品牌对比图表；以及，
[0085] 依据异常判断结果对各品牌对比图表中的非事故性车体进行分类统计，得到各个品牌出现各个异常条件的非事故性车体数量。
[0086] 电动车发生事故，根据责任主要分为两类，一类为用户自身非标准操作导致，如：超速、闯红灯；另一类为各个品牌厂家生产导致的质量责任，为方便相关人员了解事故性车体出现原因，边缘节点处理设置为还包括：
[0087] 判断车体完整度信息、速度信息、电池信息及刹车信息，即判断四个信息符合异常条件出现的顺序，如果车体完整度信息符合异常条件，且顺序在最后，则于问题信息集中增加质量事故标记；
[0088] 此时，后台处理还包括：
[0089] 根据身份信息统计各个品牌有质量事故标记的车体数量，并生成各个品牌质量事故排名表；以及，
[0090] 依据车体完整度信息符合异常条件的顺序，对同一品牌出现质量的车体数量进行统计，并得到各个顺序下所分别对应的车体数量，如A顺序、刹车异常在前，车体完整度异常在后；B顺序、电池异常在前，车体完整度异常在后。
[0091] 根据上述内容，相关人员不仅可了解各个品牌出现质量事故的比例，还可各更为清晰的了解哪一质量问题导致了事故的发生。
[0092] 对于质量事故标记，后台处理还做以下运用：确定有质量事故标记的车体为事故性车体，以跳过后台的事故/非事故判定环节，节省算力。
[0093] 本申请实施例公开基于边缘计算的电动车物联管控系统。参照图1，基于边缘计算的电动车物联管控系统包括车载模组、边缘节点、监管后台及用户终端。
[0094] 其中，车载模组包括OBU单元及多个用于获取车体信息的传感器(如上述实施例所述)，各个传感器分别连接于OBU单元，以保证边缘计算的顺利进行；边缘节点包括多个路侧单元RSU，分别安装于道旁，连接于OBU单元且被配置为用于实现如上述实施例的边缘节点处理；监管后台连接于边缘节点且被配置为用于实现如上述实施例的后台处理；用户终端包括手机、计算机中的任意一种或多种。
[0095] 为提高管理效果，工作人员还可选择对电动车改进，如：当电动车的把手为霍尔手柄，则在霍尔手柄的输出侧并联限速单元，限速单元包括限速电阻及适配的三极管开关电路，三极管开关电路连接于OBU单元；此时，设置有相应权限的相关人员可通过手机等发送限速信息至后台，后台发送信息至边缘节点，再由边缘节点发送至相应的OBU单元，以实现远程限速。
[0096] 综上所述，本申请一方面可辅助交警等相关人员合理分配警力等，减小交通事故发生几率和经济损失，另一方面还可方便各品牌厂家了解自身产品缺陷，引导后续产品改进方向；同时，还可为用户提供购物参考和使用过程中的提示。
[0097] 以上均为本申请的较佳实施例，并非依此限制本申请的保护范围，故：凡依本申请的结构、形状、原理所做的等效变化，均应涵盖于本申请的保护范围之内。
