传感器和车辆应用之间的API

OEM正在为车辆添加各种传感器，以为驾驶员提供一系列驾驶员辅助和高级别的自动驾驶功能。但OEM和Tier1仍缺乏标准的API，无法链接在车辆计算系统上运行的传感器和应用程序。

没有可互操作的API，OEM就无法使用另一开发商的新传感器来替代。相反，他们必须从头开始重写代码。就目前而言，他们的车辆应用软件无法正确控制新传感器生成的数据流。

Khronos Group与欧洲机器视觉协会（European Machine Vision Association）周一宣布，将成立一个“考察小组”，调查嵌入式摄像头和传感器API标准的要求。作为一个开放的联盟，Khronos以其图形和计算互操作性标准而著称。EMVA在机器视觉技术方面拥有数十年的经验。

Khronos的总裁Neil Trevett解释说，应用软件开发人员需要访问和控制传感器生成的实时流，以便他们可以将推理软件的速度提高一倍，或者更轻松地将自己的图像识别强加到系统中。这项新举措计划解决高级别自动驾驶的车辆所要求的“可移植性性问题，还包括增强的功能性”。

Trevett称该小组为“最早的行业论坛之一，硬件和软件社区可以通过该论坛聚在一起，并实际确定我们是否可以做得更好。”

没有预定的结果

关键词是“探索性”。就像一个政客正在考虑竞选更高职，就会成立一个考察委员会来评估利益相关者一样，这两个小组正在成立考察小组，以评估行业对开放、独立于供应商的免专利费的API标准的需求，以控制嵌入式摄像头和传感器。

Trevett在接受采访时说：“我们没有预定的结果。”该小组可能会得出结论，不需要这种API。若是这样，也无可厚非。Khronos或EMVA甚至其他组织都可以启动标准化工作。考察小组的参与者可能会建议一个开源项目。

Trevett强调：“我们将以零成本向任何有兴趣的人开放这个考察小组。我们希望发现该行业的真正需求。我们将需求和用例放在首位。”

API的位置

Trevett设想的API是“位于应用程序与传感器/摄像头/ISP硬件之间的API。”

Trevett解释说，软件开发人员希望应用程序能够直接控制传感器生成的图像流，用于下游处理。他补充说，他们正在寻找对镜头、曝光或其他任何内容进行可编程控制的级别。

Trevett解释说，他们的目标是“进行越来越复杂的处理以了解环境”。他补充说，由传感器组件（包括摄像头、雷达或激光雷达）生成的图像流将被送到DSP或GPU或由计算API（如OpenCL或Vulkan）控制的另一种硬件加速器。

他解释说，无法通过对许多不同传感器中各种参数的充分控制来实时生成正确的图像集，将使加速器硬件更难进行下游混合。

Trevett说：“如今，每个人都被专有API所束缚。例如，如果我正在参加嵌入式视觉峰会，人们就会追着我问：'为什么Khronos没有摄像头API？’”

越来越多的集成

如今，越来越多的芯片厂商正在努力将更多的智能设备集成到传感器附近。例如，最近Recogni计划将非常高性能的推理引擎插入传感器模块。

鉴于SoC将提升集成曲线，资深汽车行业分析师Egil Juliussen问道：“这种在摄像头模块和计算硬件之间开发API的计划是否会在五年内成为讨论的重点？”

根据Trevett的说法，不一定。他说，这项计划并不是要将传感器和计算系统之间的硬件接口标准化。

对于系统供应商而言，硬件级别的连接（将传感器和摄像头模块连接在一起）只是第一步。对于OEM开发下一代车型或设计工厂车间解决方案的机器视觉专家而言，下一步重要的是编写应用程序，使他们的系统安全准确地运行。

Trevett解释说，要做到这一点，软件开发人员需要聚焦在传感器上，并使用摄像头生成的一系列帧。“传统的摄像头模块供应商将提供一个非常简单的API，以控制其模块上的所有内容。由于这些模块通常是由硬件供应商设计的，因此它们使用的API非常以硬件为中心。这是你必须戳入和读取寄存器的API级别。”如果像ISP这样接近传感器处理，则模块供应商通常会隐藏它们，并仅使用一个或两个高级功能来渲染图像。

想象一下，系统集成商在丰田汽车中部署了紧密耦合摄像头模块和推理引擎的系统。如果要求该集成商在奔驰车型上部署相同的解决方案怎么办？他们将不得不再次重写所有内容。如果模块供应商将他们的解决方案升级为分辨率更高的传感器（可以更改所有寄存器），该怎么办？他们还是不得不从头开始。

Trevett指出，这个问题涉及代际和平台之间的变化。

总而言之，如果没有一致的互操作性API，OEM将无法部署多个供应商的解决方案。Trevett强调说，这也阻碍了设计良好的系统的开发，该系统可以在连续几代硬件中仍得到保留。

图像传感器的专有性

VSI Labs的创始人兼总裁Phil Magney表示，“视觉传感器的输出可以是原始的，即使原始格式没有标准化，你也可以用它来做自己想做的事。大多数传感器使用专有软件将原始数据转换为JPEG或TIFF格式。许多传感器都以这种格式出售。”

他补充说：“另一方面，Mobileye在传感器上添加了大量IP来创建模块，并在该模块中包含处理IP和支持其特征检测器、分类器甚至控制逻辑所必需的软件。”Magney认为，“Mobileye实际上是一个系统，而不仅仅是传感器。OEM和开发者不喜欢这种方法，因为它是封闭的，你无法获得原始输出应用自己的算法。”

Magney又补充说：“但是，如果你需要ADAS却不具备构建解决方案的技能，则可以选择Mobileye，这样就可以更快地将解决方案推向市场。这就是在过去十年左右的时间里，Mobileye在ADAS市场中获得了如此大的渗透率的原因。”

时代在变。Magney补充说：“OEM、Tier1和开发者都想做自己的事。因此，封闭方法并不理想。该工作组的目标是朝着标准化迈进，以消除一些限制因素。”

深刻的教训

Khronos Group的Trevett坦言，Khronos制定API标准的所有举措并非都像OpenGL、Vulkan或OpenCL一样成功。

在2013-2015年之间，Khronos致力于开发用于手机摄像头控制的“OpenKCAM API标准”。当时的想法是创建“一种开放的、免版税的标准，用于对移动和嵌入式摄像头和传感器进行高级、低级控制。”

Trevett说，该小组希望创建一种标准化的方式来控制手机中的摄像头，但从未发布该规范。这是因为最终苹果和谷歌创建了专有的API，这些API主导了移动市场。由于“对OpenKCAM毫无需求”，Khronos小组放弃了该项目。

Trevett称这是一个经验教训，他说：“我希望我们这次不会遇到准相同的命运”。

乐观的原因之一是机器视觉和汽车的嵌入式空间更加多样化。Trevett指出：“你的系统带有8个摄像头，你的系统将视觉、激光雷达和雷达混合在一起，并且在所有这些多个传感器之间都具有实时要求。这是一个更大的问题空间。”

他补充说：“谷歌的摄像头API不能解决所有这些问题。”

他补充说，这项工作可能成功的另一个原因是，没有任何一个平台供应商可以大笔一挥就决定结果。“有数百个玩家希望集成硬件和软件，并以各种方式使用传感器。因此，没有人会说，好吧，这就是所有人都会使用的东西。”

尽管OpenKCAM规范从未公开发布，但Khronos小组在其网页上指出：“如果OpenKCAM设计的要素满足了Embedded Camera API Exploratory小组制定的议定工作范围的要求，则可能会被重新启用。”

[参考文章]

Looking for APIs that Sit Between Sensors and Vehicle Apps?— Junko Yoshida

---

from A to B