原来自动驾驶离不开OpenStack

最令人期待的5G用例可能就是自动驾驶汽车，紧随其后的会是交通革新。这预计将带来新的服务，如污染监测、跟踪和预测诊断，拥堵检测和在城市提供更顺畅的移动性以及更可靠的信息娱乐。

云架构将使所有这一切成为可能，但让汽车真正智能化还存在一定的技术障碍。

这些障碍包括：

——车载单元（OBU）和云或数据中心同步数据传输的低延迟要求。

——更快地处理生成的原始数据，以便为车辆中的物理OBU生成有洞察的指令。

——用于保持由车内多个传感器生成的数据的原始缓存的中间层，以得到即时洞察，从而产生快速响应。

西班牙卡塔赫纳和穆尔西亚大学的研究人员通过使用OpenStack和ETSI Open Source Mano（OSM）虚拟化车辆OBU，测试了一种称为“surrogates”的解决方案，以消除这些障碍。概念验证的焦点是用多接入边缘计算（MEC）层，充当云和车辆OBU之间的中间层。

该解决方案以虚拟网络功能（VNF）的形式虚拟化物理OBU的功能——VNF托管在网络的中间层或边缘（路边单元、蜂窝基站、WiFi接入点等）。数据预处理任务，如对原始数据的分析、模式识别和聚合由这些VNF执行，而这些VNF又由基于边缘的NFV管理，并进一步推向云以进行大量全球大数据分析。然后，处理过的洞察由从部署在车内的OBU从vOBU或数据分析模块访问。

计算资源或功能从物理OBU中取出，并以较高的资源消耗功率推送到边缘层。这意味着这些VNF可由部署在车内的多个物理OBU同时访问。这样可以将从数据中心到OBU的传输延迟和响应信息传输时间减少50％。此外，它还可以减少消耗并释放网络中数十辆车辆和多种其他类型设备所需的无线网络带宽。

所提出的解决方案需要两个NFV云：一个作为中心云，另一个作为边缘基础设施。PoC使用OpenStack和ETSI Open Source Mano（OSM）构建，以收集和处理来自车辆OBU的数据。 OpenStack（版本Pike）充当虚拟基础设施管理器（VIM），用于管理两个基础设施上的虚拟化资源。 OSM（版本4）在中心云中用作VNF的编排器。具有MEC功能的Edge基础设施域由使用OpenStack管理的vOBU VNF组成。 VNF与MANO、OBU管理器和数据分析模块进行通信，以实现各自的功能。

OBU管理器本身是在边缘虚拟化域中部署的VNF，充当物理OBU到其相同域中的虚拟对应部件的中间组件。它与OSM通信以获取与vOBU相关的请求，例如分配、扩展和共享状态报告。一旦有来自现有OBU的新请求和有新车辆加入具有访问限制的网络，就会发生vOBU的扩展和分配。

监控模块部署在边缘域的物理OBU和OpenStack环境中，该边缘域在与vOBU通信时充当OBU的中间件。Grafana用作监控解决方案。数据分析模块响应VNF在边缘域的数据分析请求。VNF与数据分析模块进行通信，以获取分析洞察（新的洞察请求或过去请求的洞察缓存）。

PoC在5GINFIRE项目测试平台设置下进行了测试，并进行了三次试验来评估目标：

——在vOBU中获得不同的缓存成功率时，评估平台运行

——研究请求丢失的比率

——分析系统可扩展性和新车注册以及获取vOBU实例的持续时间

研究人员总结说，通过使用Grafana和Android应用程序实施监控服务得到验证，证明了该提案可以良好运行。

这个解决方案展示了中层边缘域中的卸载设备功能如何不仅有益于车辆服务，还有利于工业物联网、智能城市运营等其他用例。使用OpenStack和OSM as MANO等领先的开放基础设施项目表明，这些解决方案可以使用开源项目，并具有控制开发基础设施成本的额外好处。与OpenStack一起使用，OSM带来了各种好处，因为它提供了许多强大的解决方案，可以支持更大规模的5G用例。

原文链接：

http://superuser.openstack.org/articles/edge-for-autonomous-cars-openstack-and-etsi-open-source-mano/

获取更多开源云技术资讯&大咖交流&免费活动，欢迎添加开源云中文社区小助手，备注开源云！

（长按识别二维码添加）