一种面向城市道路C-V2X网络的边缘计算系统的制作方法

一种面向城市道路c-v2x网络的边缘计算系统
技术领域
1.本发明涉及边缘计算、车联网和车路协同领域，特别涉及一种面向城市道路c-v2x网络的边缘计算系统。


背景技术：

2.全球范围内，城市道路交通正在饱受交通拥堵、事故频发等痼疾的困扰。机动车保有量逐年飞速增长，单纯靠增加道路供给来缓解交通问题已经证明有其局限性。智能交通综合利用现代通信、感知、计算、网络交换、新能源汽车、自动驾驶、大数据等技术，可以作为对解决这一难题的有效补充，依靠高新技术的加持，车辆正在变得越来越“聪明”，道路正在变得越来越“智慧”。
3.边缘计算近年来在学术界和产业界受到了广泛关注，算力和资源靠近客户部署的分布式转型已经成为趋势。边缘计算在节约数据带宽、减少回传容量、降低传输成本、减少时延、提高数据实时分析能力、保护用户数据隐私等方面都有着集中式云计算所不能比拟的优势，因此可以和云计算一起为智能交通提供更强大的计算能力和更优化的分析处理手段。
4.由于应用场景的多样性，对于边缘计算的具体实现架构，目前尚没有统一的方案。主要影响因素包括应用的具体要求(时延、带宽、实时性、数据传输、安全性)、技术条件(边缘配置、与云端和终端设备的距离)和业务特性(需求、经济考虑)等。例如，仅对“边缘”的位置理解，就有终端设备、业务现场、基站附近、聚合点、传输网、核心网、近云端等。通信设备商、it厂商、运营商、车厂、解决方案提供商等均根据自己的行业优势推出了不同的边缘计算系统，这些系统各有特色，但就对交通业务的理解和针对性设计而言，还缺乏一套层次设计清晰、功能划分合理、场景指向性强的智能交通专用边缘计算系统。


技术实现要素：

5.发明目的：本发明所要解决的技术问题是针对现有技术的不足，提供一种面向城市道路c-v2x(cellular-vehicle to everything，蜂窝车联网)网络的边缘计算系统。
6.为了解决上述技术问题，本发明公开了一种面向城市道路c-v2x网络的边缘计算系统，包括基础设施层、网络层、资源层、平台层、场景层和业务应用层，基础设施层包括车端mec(multi-access edge computing，多接入边缘计算)单元、路侧mec单元和基站mec单元三个层次和一套分布式资源分配和调度策略，各mec单元间通过c-v2x网络和有线网络连接，形成车、路、站一体化部署架构；各mec单元间通过分布式资源分配和调度策略处理边缘计算任务。
7.所述车端mec单元包括部署在车端的专用车载mec终端、车载计算机和车载obu(on board unit，车载单元)，用于处理道路上迫近本车目标的边缘计算任务；
8.所述路侧mec单元包括部署在路侧信号灯杆、监控杆、专用立柱和机箱的便携式计算机，一般为嵌入式架构，可支持ai深度学习等，用于处理从路侧对路口和路段中两个以上
交通目标的边缘计算任务；
9.所述基站mec单元包括部署在蜂窝网基站机房内的通用边缘计算服务器，用于处理基站覆盖范围内态势感知和协同控制相关的大量交通目标的边缘计算任务；
10.所述边缘计算任务在任务类别上包括交通目标检测与识别、交通事件发现与预测、交通场景融合分析与处理、局部交通态势综合感知以及辅助和自动驾驶决策任务。
11.分布式资源分配和调度策略是指对c-v2x网络中的边缘计算资源(包括算力、带宽和存储等)进行分布式配置和管理的策略。总的原则是灵活采用虚拟机、容器、微服务、异构计算、深度学习等技术，综合考虑地理位置、网络时延、消息周期、事件性质、复杂度、传输条件等因素，按具体场景需求进行资源的动态分配和调度。各类mec中均预置同一套通用的分布式资源分配和调度策略，以支持灵活、快速的场景设计开发和部署运行，有效支撑交通目标检测与识别、交通事件发现与预测、智能网联业务场景实现、局部交通态势综合感知、辅助和自动驾驶决策等场景边缘计算任务。
12.通过对三个层次的边缘计算单元进行科学合理、灵活高效的分布式管理，分别实现交通目标检测与识别、交通事件发现与预测、交通场景融合分析与处理、局部交通态势综合感知、辅助和自动驾驶决策五种类别的交通边缘计算任务。
13.在一种实现方式中，专用车载mec终端包括专门用于车辆传感数据分析处理和简单融合计算的轻量级边缘计算设备。其需要提供丰富的外部接口与车载的摄像头、毫米波雷达、激光雷达、超声波雷达、can(controller area network，控制器局域网络)总线、北斗/gps(global positioning system，全球定位系统)定位、车载obu等设备进行对接，其算力支持将对接的车载摄像头、毫米波雷达、激光雷达、超声波雷达、can总线和北斗/gps定位设备感知到的原始数据进行融合处理，完成实时交通目标检测与识别，包括目标的距离、速度、方向、加速度、轮廓、颜色、车牌号等动态、静态特征，并以结构化数据形式向车载obu传输，由obu向外发送。
14.车载计算机包括高度集成的车规级专用电脑，满足严格的温度环境、抗振动冲击能力、可靠性、一致性要求、制造工艺等。该计算机由车厂前装，软硬件相对封闭，主要用于对车辆工作状态进行实时动态监控和故障检测与预警。
15.车载obu包括采用c-v2x技术并具有一定边缘算力的车联网专用车载通信设备。其边缘算力可以与专用车载mec终端配合，协同完成大量复杂的车端计算任务。车载obu能够将车端mec单元的数据通过蜂窝网与基站mec单元进行交互，通过v2x网与其它车端mec单元和路侧mec单元进行交互，实现mec单元间的高效协同。所述蜂窝网指4g/5g蜂窝通信网，即c-v2x网络的uu蜂窝通信模式；所述v2x网指c-v2x网络的pc5直连通信模式。
16.在一种实现方式中，路侧mec单元由于工作环境要求比较严苛，需要进行工业级设计，以确保其工作可靠性和稳定性。路侧mec单元主要通过以太网交换机与rsu(road side unit，路侧单元)、路侧摄像机、毫米波雷达、激光雷达、情报板/诱导屏、北斗/gps、信号机、气象传感器、环境传感器等进行对接，通过光纤或蜂窝网与基站mec进行连接。
17.基站mec单元可根据具体设备和现场情况部署于机架上或单独部署。在运营商已经部署了mec设备的基站，mec单元可选择复用运营商设备，共享算力、存储、网络等资源，以节约成本，提高效益。基站mec可通过光纤或蜂窝网与路侧mec单元连接，通过蜂窝网与车端mec进行连接。
18.在一种实现方式中，所述资源层包括异构资源子层、资源配置子层和资源调度子层，所述异构资源子层包括边缘计算涉及的异构处理器、网络带宽和存储资源的统一表示，所述资源配置子层进行虚拟化配置管理，包括虚拟机方式和容器化方式；所述资源调度子层根据边缘计算任务特性进行资源计算、资源调度、资源隔离、调度优化、作业队列管理、负载均衡、虚拟机迁移和资源卸载；
19.所述平台层根据对各mec单元实时性、安全性和异构计算的需求，部署微服务，所述平台层支撑组件包括服务注册、服务发现、服务网关、业务编排、api(application programming interface，应用程序接口)管理、集成框架、分布式管理和调用链；平台层还提供交通ai(artificial intelligence，人工智能)算法支持、安全认证；
20.所述场景层提供包括交通安全、交通效率、出行服务、自动驾驶在内的智能网联边缘场景的计算支撑，并能够根据需求弹性扩展；
21.所述业务应用层在场景层服务的基础上，与云端业务应用层协同，针对交通管理者、交通运输行业和驾驶员用户提供包括公交优先、全息路口、交通测序、数字孪生、信号优化和自由流收费在内的智能网联和智能交通业务应用。
22.在一种实现方式中，所述分布式资源分配和调度策略包括：
23.步骤1，确定业务应用，明确所涉及的交通参与对象和业务应用的作用范围；
24.步骤2，划分边缘场景，将确定的业务应用划分为不同的边缘场景应用组合；
25.步骤3，分析边缘场景应用详细特征，所述详细特征包括边缘场景应用的应用性质、事件类型、高精地图与定位需求、时延需求、可靠性要求、传输带宽需求、消息周期、数据包大小、数据类型、ai需求、多源融合需求、决策与控制需求、道路特性、目标运动特征、静态特征和环境与气象影响；
26.步骤4，确定边缘计算任务，根据边缘场景应用详细特征，确定实现边缘场景的边缘计算任务；
27.步骤5，确定边缘计算资源详细描述，向平台层提交边缘计算任务请求，平台层根据该请求，通过微服务api接口网关调用对应的微服务和算法模型，并通过微服务向资源层发布所需计算资源的详细描述；
28.步骤6，进行分布式资源调度，资源层根据所需边缘计算资源详细描述，进行算力、带宽和存储的精细调度，将适合的资源分配给适合的边缘计算任务。
29.在一种实现方式中，所述边缘计算任务在任务特性上包括时延敏感型、安全敏感型、带宽敏感型、算力消耗型、存储占用型和异构协作型任务。
30.在一种实现方式中，进行分布式资源调度，通过综合现有资源池状况，针对边缘计算任务在任务特性上的不同，预先制定基于分布式资源调度算法的调度方案及其组合，提供菜单式资源调度方案服务，为上层应用屏蔽琐细的资源调度细节，实现调度的加速和优化；对于车端mec单元，其计算资源优先分配给本车；对于路侧mec单元，其支持的资源调度范围在rsu的信号覆盖范围内，用于包括路侧视频分析、激光雷达点云处理算法和高精地图匹配在内的场景计算，以及支持从路侧向车端提供计算资源，实现车路协同辅助驾驶和自动驾驶支撑；对于基站mec单元，用于长周期(分钟级)、中等时延(20ms-200ms)和弱局域性(跨多个相邻路口)的场景计算。
31.在一种实现方式中，所述分布式资源调度算法包括：
32.步骤6.1，初始化队列，将边缘计算任务按照任务特性划分为6个队列，记时延敏感型任务所在的队列为r1、安全敏感型任务所在的队列为r2、带宽敏感型任务所在的队列为r3、算力消耗型任务所在的队列为r4、存储占用型任务所在的队列为r5和异构协作型任务所在的队列为r6，各个队列初始化时分配固定长度；不同任务特性的边缘计算任务请求并行进入对应的队列；
33.步骤6.2，设定各队列的优先级，对权限高的队列优先分配资源，依次定义各队列优先级为r1》r2》r3＝r4＝r5＝r6，即系统优先处理队列r1中的请求；在接收请求过程中，如果优先级最高的队列达到分配长度，则将其与下—优先级队列合并；如果某一队列在设定时间间隔内为空，则把该队列与优先级最高队列合并；最高优先级队列中请求完全处理后，再处理次一优先级队列；
34.步骤6.3，确定同一个队列中不同请求的调度顺序；
35.步骤6.4，对各个队列中的请求按照调度顺序依次进行资源分配处理。
36.在一种实现方式中，所述步骤6.3包括：
37.步骤6.3.1，定义所述边缘计算系统的qos模型指标，所述模型指标包括计算时间、传输时间、调度时间、带宽开销、算力资源、存储资源、安全要求和权限指标；
38.步骤6.3.2，定义向量s＝{s1,s2,...,si,...,sn}为某队列中的请求服务集合，n为请求个数，1≤i≤n；向量q＝{q1,q2,...,qj,...,qm}为qos模型指标集合，m为qos模型指标总数，1≤j≤m；权重矩阵为p＝(p
ij
)n×m，p
ij
表示队列中第i个请求对第j项qos指标的重要性要求；
39.步骤6.3.3，对权重矩阵进行归一化处理，得到计算矩阵y＝(y
ij
)n×m：
[0040][0041]
其中，maxp
.j
＝max{p
ij
},1≤i≤n，minp
.j
＝min{p
ij
},1≤i≤n；
[0042]
步骤6.3.4，计算第i个请求的信息熵值hi为：
[0043][0044]
步骤6.3.5，计算第i个请求的评价指数wi为：
[0045][0046]
步骤6.3.6，对各队列的请求均按照评价指数wi降序排列，获得不同请求的调度顺序。
[0047]
在一种实现方式中，在步骤6完成分布式资源调度，即边缘计算任务完成后，删除相应的容器及其镜像，及时释放其所占用的资源。
[0048]
有益效果：
[0049]
本发明通过综合车端mec单元、路侧mec单元和基站mec单元三种不同类型和层次的边缘计算设备，利用针对交通应用场景设计的分布式资源分配和调度策略，实现边缘计
算资源在车端、路侧和基站的科学合理配置，提高资源的动态使用效率，降低边缘计算的整体部署成本。通过将边缘计算任务划分为目标检测识别类、事件发现预测类、业务场景实现类、综合态势感知类以及辅助和自动驾驶决策类等不同的类别，有利于有的放矢地确定资源分配和调度策略，实现“因场景定任务”、“因任务定策略”、“因策略定资源”的交通边缘计算部署目标。
[0050]
本发明利用边缘计算、分布式资源分配和调度、虚拟机、容器化、微服务、异构计算、深度学习等技术，能够为城市道路c-v2x网络提供贴近实际交通场景需求的多类型分层次边缘计算架构，可以有效提高边缘计算效率和边缘资源利用率，减小场景分析时延，提高车路协同应用可靠性，同时降低总体部署成本，提高项目资金使用效益。
附图说明
[0051]
下面结合附图和具体实施方式对本发明做更进一步的具体说明，本发明的上述和/或其他方面的优点将会变得更加清楚。
[0052]
图1是本发明的物理系统架构示意图。
[0053]
图2是本发明的总体技术架构示意图。
具体实施方式
[0054]
为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明的实施方式做进一步详细描述。
[0055]
本技术实施例提供了一种面向城市道路c-v2x网络的边缘计算系统，如图2所示，包括基础设施层、网络层、资源层、平台层、场景层和业务应用层，基础设施层包括车端mec单元、路侧mec单元和基站mec单元，如图1所示，各mec单元间通过c-v2x网络和有线(以太网/光纤)网络等紧密连接，形成“车-路-站”一体化部署架构。通过分布式资源分配和调度策略，各mec单元有序地组织资源、运行算法、编排业务、交互通信、存储数据等，实现目标检测识别类、事件发现预测类、业务场景实现类、综合态势感知类以及辅助和自动驾驶决策类等多种类型的边缘计算任务。
[0056]
所述车端mec单元包括部署在车端的专用车载mec终端、车载计算机和车载obu，用于处理道路上迫近本车目标的边缘计算任务；
[0057]
所述路侧mec单元包括部署在路侧信号灯杆、监控杆、专用立柱和机箱的便携式计算机，用于处理从路侧对路口和路段中两个以上交通目标的边缘计算任务；
[0058]
所述基站mec单元包括部署在蜂窝网基站机房内的通用边缘计算服务器，用于处理基站覆盖范围内态势感知和协同控制相关的大量交通目标的的边缘计算任务；
[0059]
所述分布式资源分配和调度策略指对c-v2x网络和有线网络中所有的边缘计算资源进行分布式配置和管理的策略，所述边缘计算资源包括算力、带宽和存储；
[0060]
其中车端mec单元偏重于处理道路上迫近本车目标的识别检测、安全事件预警、紧急决策、自动驾驶等任务，路侧mec单元侧重于完成从路侧对路口、路段中多个交通目标的识别检测、多元感知数据融合、事件预警、盲区和超视距风险提醒、提升安全和效率的辅助驾驶场景实现等任务。基站mec单元侧重于完成对覆盖范围内总体交通态势的把控、多源事件信息的融合处理、智能网联业务实现(如公交优先、全息路口等)、高精地图下发更新、静
态、准静态信息发布等任务。需要注意的是，以上各类型任务在三个层次的mec中可能会存在一定的重叠交叉，但其视角、出发点和作用范围均有所侧重，无法相互替代。
[0061]
本实施例中，所述专用车载mec终端包括专门用于车辆传感数据分析处理和简单融合计算的轻量级边缘计算设备，所述轻量级边缘计算设备具备外部接口，通过所述外部接口与车载摄像头、毫米波雷达、激光雷达、超声波雷达、can总线、北斗/gps定位和车载obu设备进行对接；所述轻量级边缘计算设备的算力支持将对接的车载摄像头、毫米波雷达、激光雷达、超声波雷达、can总线和北斗/gps定位设备感知到的原始数据进行融合处理，完成实时交通目标检测与识别，包括目标的距离、速度、方向、加速度、轮廓、颜色和车牌号特征，并以结构化数据形式向车载obu传输；
[0062]
所述车载计算机包括车规级专用电脑，所述车规级专用电脑由车厂前装，软硬件相对封闭，用于对车辆工作状态进行实时动态监控和故障检测与预警；
[0063]
所述车载obu包括采用c-v2x技术并具有边缘算力的车联网专用车载通信设备，所述车联网专用车载通信设备的边缘算力能够与专用车载mec终端配合，协同完成车端边缘计算任务；如图1所示，所述车载obu能够将车端mec单元的数据通过蜂窝网与基站mec单元进行交互，通过v2x网与其它车端mec单元和路侧mec单元进行交互。
[0064]
本实施例中，如图1所示，所述路侧mec单元通过以太网交换机与rsu、路侧摄像机、毫米波雷达、激光雷达、情报板/诱导屏、北斗/gps、信号机、气象传感器和环境传感器进行对接，通过光纤或蜂窝网与基站mec单元进行连接。
[0065]
如图2所示，本实施例的总体技术架构主要由基础设施层、网络层、资源层、平台层、场景层、业务应用层构成。基础设施层主要由车端mec、路侧mec、基站mec以及其所接入的感知和通信等设备构成，网络层包括c-v2x uu、c-v2x pc5和有线网络(以太网/光纤)三种联网模式，资源层包括异构资源子层、资源配置子层和资源调度子层，异构资源子层主要包括边缘计算可能涉及的各种类型的异构处理器、网络带宽和存储资源的统一表示，资源配置子层进行虚拟化配置管理，包括虚拟机方式和容器化方式。虚拟机方式包括虚拟机软件vmware(virtual machine ware)、开源虚拟机kvm(kernel-based virtual machine)、虚拟箱virtualbox和开源的云计算管理平台项目openstack，容器化方式包括应用容器引擎docker以及容器集群管理/编排工具k8s(kubernetes)、compose、marathon和swarm。相对于云计算而言，边缘计算的轻量化特性主要使用容器技术来支撑微服务的运行环境，但结合虚拟机技术可以为容器提供更加安全的隔离。资源调度子层根据边缘计算的任务特性进行资源计算、资源调度、资源隔离、调度优化、作业队列管理、负载均衡、虚拟机迁移、资源卸载等。平台层主要根据对mec单元实时性、安全性和异构计算的需求，大量部署微服务，其支撑组件包括服务注册、服务发现、服务网关、业务编排、api管理、集成框架、分布式管理、调用链等。平台还需要提供交通ai算法支持、安全认证(包括基于软件的安全认证和基于底层硬件的安全信任根等)等。场景层提供对数十种交通安全、交通效率、出行服务、自动驾驶类智能网联场景的计算支撑，并可以根据需求弹性扩展。业务应用层在场景层服务的基础上，与云端业务应用层协同，针对交通管理者、交通运输行业、驾驶员等用户提供包括公交优先、全息路口、交通测序、数字孪生、信号优化和自由流收费在内的智能网联和智能交通业务应用。
[0066]
本发明的分布式资源分配和调度策略如下：
[0067]
步骤1，确定具体的业务应用
[0068]
根据设计功能确定所需要实现的具体业务应用，如公交优先、全息路口、信号优化等；明确所涉及的交通参与对象，包括部门、人员、车辆、设施、设备、终端等；还应明确业务应用的作用范围，如单点、干线、路口、路段、区域、城市等，对于本发明所述架构，业务应用的作用范围仅限于单个基站的覆盖范围。
[0069]
步骤2，划分支撑的边缘场景应用
[0070]
根据业务应用的定义和内涵，将其详细划分为不同的边缘场景应用组合，这些场景应用一般为现有标准框架所支撑的标准化场景，并可以根据业务实际需求进行剪裁和扩充。
[0071]
步骤3，分析边缘场景应用的详细特征
[0072]
针对所划分的场景应用，进一步分析其详细特征，包括其应用性质(安全、效率、服务、自动驾驶)、事件类型、高精地图与定位需求、时延需求、可靠性要求、传输带宽需求、消息周期、数据包大小、数据类型(是否结构化数据、是否流媒体数据)等、ai需求、多源融合需求、决策与控制需求、道路特性、目标运动特征、静态特征、环境与气象影响等。
[0073]
步骤4，确定场景边缘计算任务的具体需求
[0074]
根据场景应用的特征，确定实现该场景所需要具体边缘计算任务需求。一般包括交通目标检测与识别、交通事件发现与预测、交通场景融合分析与处理、局部交通态势综合感知、辅助和自动驾驶决策等五种类型的场景计算需求；具体到任务特性上，又可划分为时延敏感型、安全敏感型、带宽敏感型、算力消耗型、存储占用型、异构协作型等任务需求。例如交叉路口防碰撞、紧急刹车预警等是典型的时延敏感型任务需求，违法行为取证、高精地图匹配是典型的存储占用型任务需求，视频ai分析是典型的算力消耗性任务需求。
[0075]
步骤5，确定所需边缘计算资源的详细描述
[0076]
任务需求确定后，即可向平台层提交边缘计算任务请求，平台层根据该请求，通过微服务api接口网关调用对应的微服务和算法模型，并通过微服务向资源层发布所需计算资源的详细描述。
[0077]
步骤6，进行分布式资源调度，以微服务方式将适合的边缘计算资源分配给适合的任务
[0078]
资源层根据所需边缘计算资源的详细描述，进行算力、带宽和存储的精细调度，将适合的资源分配给适合的边缘计算任务。这个过程是通过综合现有资源池状况，针对典型的交通边缘计算任务特性，预先制定一系列基于分布式资源调度算法的调度方案及其组合，提供“菜单式”资源调度方案服务，为上层应用屏蔽琐细多变的资源调度细节，实现调度的加速和优化。调度方案集合预先配置于各分布式边缘计算节点上，具有动态性、灵活性、场景指向性、资源相关性等特点，是调度策略的核心。通常情况下，cpu(central processing unit，中央处理器)比较适合于决策控制、规则管理之类的任务，gpu(graphics processing unit，图形处理器)比较适合于ai训练、目标检测等需要大规模并行计算的任务，dsp(digital signal processing，数字信号处理)比较适合于图像和视频处理，fpga(field programmable gate array，现场可编程逻辑门阵列)适合于多源信息融合、视频分割、目标跟踪、事件预测等任务且具有可编程、易升级特性，asic(application specific integrated circuit，专用集成电路)适合于性能强大、成熟稳定的定制性视觉处理和ai算
法任务。如npu(neural-network processing unit，神经网络处理单元)和tpu(tensor processing unit，张量处理单元)均属于用于ai深度学习的asic处理器。对于车端mec，因其处于高速运动状态，加之分配的移动带宽资源有限，原则上其计算资源优先分配给本车。如其附近有支持本架构的智能网联车辆，边缘资源可以支持共享，但需要考虑车辆移动带来的网络快速切换，资源应支持快速分配与卸载。对于路侧mec，其支持的资源调度范围一般在rsu的信号覆盖范围内，一般用于路侧视频分析、激光雷达点云处理算法、高精地图匹配等场景计算，以及支持从路侧向车端提供计算资源，实现车路协同辅助驾驶和自动驾驶支撑，而较少利用车端算力。此外，路侧mec与基站mec间有无线和有线两种联网模式，且位置固定，较易实现算力、带宽和存储资源的共享，可以实现更加灵活的资源调度。如可将短周期、低时延、强局域性的场景计算在路侧mec处完成，而将长周期、中等时延、弱局域性的场景计算在基站mec处完成。又如可将ai场景中的训练和建模过程在基站mec处完成，而将实时性强的推断过程在路侧mec处完成。基站mec通常为x86架构的服务器或虚拟化的边缘云，架构相对单一，资源相对丰富，在本架构中可以起到一定的“资源缓冲区”和“区域现场调度中心”、“安全认证中心”的作用。由于资源虚拟化的特点，以上调度过程对于最终用户是透明的。
[0079]
以交叉路口防碰撞场景为例，该场景涉及到的边缘计算任务一般包括主车运动状态感知、相交道路上机动车、非机动车、行人目标检测与识别、运动参数提取、轨迹预测、碰撞预警、事件上报与存储等。大部分任务对时延和安全性的要求较高。此时主车运动状态感知适宜由车端obu直接采集行车电脑数据并向rsu发送，相交道路上机动车、非机动车、行人目标检测与识别、运动参数提取、轨迹预测和碰撞预警等对算力消耗大，时延要求高，适宜由路侧mec进行路侧视频和毫米波雷达等数据、地图匹配数据以及车端obu上报数据的融合感知，并将结果向路侧车辆广播，主车收到广播后向驾驶员发出预警。当碰撞事件无法避免时，需要将事件原始数据上传至云控平台，该任务属于带宽敏感型和存储占用型任务，但时延要求可以放宽，其计算优先级较低。此外，地图数据的动态更新属于时延不敏感、长周期、突发传输任务，可以由云控平台或基站mec定时向路侧mec下发。
[0080]
城市道路c-v2x网络中边缘计算任务具有强实时性、高并发、多个性化的特征，对边缘计算的等待时间、服务质量、负载均衡、资源利用率等有较高的要求，传统的资源调度算法无法满足需求。
[0081]
本发明采用加权法对资源进行优化调度，结合车路协同不同场景下调度的特点，使用选择模型，将调度问题转化为多属性决策问题，从而实现实时动态调度。
[0082]
针对以上调度策略，设计分布式资源调度算法如下：
[0083]
步骤6.1，初始化队列，将边缘计算任务按照任务特性划分为6个队列，记时延敏感型任务所在的队列为r1、安全敏感型任务所在的队列为r2、带宽敏感型任务所在的队列为r3、算力消耗型任务所在的队列为r4、存储占用型任务所在的队列为r5和异构协作型任务所在的队列为r6，各个队列初始化时分配固定长度(队列中请求的总个数)n，车联网里面的消息请求频率很大一部分是固定的，结合场景需求，根据已知的固定消息请求频率和预估的随机消息请求频率，确定n取值；不同类型的请求并行进入不同的队列。
[0084]
步骤6.2预先设定各队列的优先级，对权限高的队列优先分配资源。根据车路协同任务的资源需求特性，依次定义各类型优先级为r1》r2》r3＝r4＝r5＝r6，即系统优先处理队
列r1中的请求。在接收请求过程中，如果优先级最高的队列达到分配长度，则将其与下—优先级队列合并，即队列r1和r2中的请求共同使用2n长度；如果某一队列在设定时间间隔内为空，则把该队列与优先级最高队列合并，即在规定的时间间隔内暂时取消该优先级，增加最高优先级的请求队列长度；最高优先级队列中请求完全处理后，再处理次一优先级队列。通过这种方式提升高优先级请求的成功率。
[0085]
步骤6.3，确定同一个队列中不同请求的调度顺序；
[0086]
步骤6.3.1，定义所述边缘计算系统的典型qos模型指标，所述模型指标包括计算时间、传输时间、调度时间、带宽开销、算力资源、存储资源、安全要求和权限指标；
[0087]
步骤6.3.2，定义向量s＝{s1,s2,...,si,...,sn}为某队列中的请求服务集合，n为请求个数，1≤i≤n；向量q＝{q1,q2,...,qj,...,qm}为qos模型指标集合，m为qos模型指标总数，1≤j≤m；权重矩阵为p＝(p
ij
)n×m，p
ij
表示队列中第i个请求对第j项qos指标的重要性要求，该权值可以通过专家评价法确定，并可在应用中根据场景实际需求进行调整。
[0088]
步骤6.3.3，对权重矩阵进行归一化处理，得到计算矩阵y＝(y
ij
)n×m：
[0089][0090]
其中，maxp
.j
＝max{p
ij
},1≤i≤n，minp
.j
＝min{p
ij
},1≤i≤n；
[0091]
步骤6.3.4，计算第i个请求的信息熵值hi为：
[0092][0093]
步骤6.3.5，计算第i个请求的评价指数wi为：
[0094][0095]
步骤6.3.6，对各队列的请求均按照评价指数wi降序排列，获得不同请求的调度顺序。
[0096]
步骤6.4，对各个队列中的请求按照调度顺序依次进行资源分配处理。
[0097]
步骤7，任务完成，资源释放。边缘计算任务完成后，删除相应的容器及其镜像，及时释放其所占用的资源。
[0098]
本发明提供了一种基于面向城市道路c-v2x网络的边缘计算系统，具体实现该架构的方法和途径很多，以上所述仅是本发明的实施方式的一种，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。本实施方式中未明确的各组成部分均可用现有技术加以实现。