为什么需要有一套自己的框架

注意 本文中出现的观点仅代表个人而非任何与作者现实中产生交集的人或组织。

上层算法决定理论极值，下层框架限定实际边界

引子

对于智能汽车来说，从梦开始的地方（也就是DARPA Urban Challenge）算起，算法和硬件一直是整个行业的明星。形成这个环境的原因也非常得简单，算法可以有无数的gym去进行简单的量化，而硬件层面的每一点进步都是可以被直接感知的。 而证明这两点最简单的例子就是红绿灯及限速标志识别的准确度及激光雷达的线数。

可是在最近（2022）一段时间以来，业内越来越多的注意力开始放在另外的两个方面，也就是算法工程化以及框架平台的构造上。这是因为所有人都发现了一件事情，智能汽车或者自动驾驶不是由算法+硬件组成的，而是在一个完整的框架上由不同的算法和硬件传感器构建而来的。

为什么需要框架

很久很久以前（~2000）机器人（包含那时还没有出现的智能汽车）是没有一个真正意义上的框架平台的。在那个时候，一切恰恰如之前那些只会用电烙铁的电子工程师或者只会用YOLO的统计学炼丹师所预计的那样，是直接的算法与硬件的组合体。很多时候一个硬件的信息会直接交给上层应用层来进行处理。当然，一般情况下这个听起来没有什么问题，鼠标键盘直接插在电脑上不是也直接能用得很好吗。

是的，假如只有少数几个传感器的话那么简单的ad-hoc驱动直连算法方案是没有太大问题的。但是在先进的机器人里和智能汽车里，整套系统是极其复杂的。整套感知链接或者是算法链接上往往由很多个不同种类的节点所组成，这些节点之间如果还需要像原来一样手工做点对点通信，那么最终的结果是一个巨大畸形且根本无法维护的怪胎。这也是为什么好像每个人都见过非常厉害的自动驾驶算法，却少有或者是几乎没有一家公司能真正把它落地的原因。对于车辆软件这种工业性极强的软件来说，没有人会接受一个从demo逐步演进软件方案。

为什么需要一个特制的框架

当然，现在已经有诸多框架软件在汽车行业内被使用了，除了被学界广泛使用的ROS的变体之外也有德国汽车工业提出的AutoSar和日本汽车工业提出的JasPar框架。不过从目前来看，AutoSar大有一统江湖的趋势。 这些恩恩怨怨暂且放下不谈，但是当下为什么车企们都会选择在已有的框架下面自己进行开发而不使用现有的公共框架呢。这就牵涉到框架软件侧非常关键的一个问题，那就是通用性和最优性的取舍。当然，虽说是取舍，但却并不一定完全要舍，这其实是最考验软件开发者能力的一点。简单来说就是有一个公司或者一款车型需要A特性，有另一个公司或者另一个平台需要B特性，假如同时A特性与B特性它们需求完全相对的侧重点的话，那么软件设计者和开发者的能力就会得到最大程度的检验。

就目前（2022）来看，还没有任何一个公司和供应商可以说出，我的系统在任何需求的场景下都能做到最优这一句话。这是非常正常的，哪怕是平台软件应用的到航天飞机和核动力航母上的公司在不正经聊天的时候也会说出，我们的系统没法在某某情况下做到最优。当然，全（预期）场景最优是每一个平台的终极挑战，每个人都会去追求。不过有一点非常的关键，在当前这个关键的节点，已经没有人能够继续等待一个完美的平台框架了。与一般的软件不同，车辆软件其实天生与硬件是强绑定的。假如平台软件不能提供一个优秀的解决方案，那么企业只有两个选择，一个是使用成本更高的硬件去强行拉起性能不足的软件，二就是把通用平台软件降格为只适用于某一个特定场景的专属软件。这也是为什么当前每一家车企都在开发属于自己的特制框架的重要原因。

框架的未来

总得来说，框架软件现在成为事实上的壁垒，无论上层算法多么先进，底层硬件怎么高级，最终还是依赖框架软件来让他们发挥出性能。而这一点，恰恰正是之前几乎所有人都忽视了的。

“Hail the Omnissiah! He is the God in the Machine, the Source of All Knowledge.”

---

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.