当谈论架构的时候，我们在谈什么

在谈论自动驾驶的时候，“架构”这个词越来越多的被提及，但这个词对于大多数人来说这个词还是过于抽象。对于ADAS系统而言，架构的定义是什么？它包含了哪些内容？如何成为一个合格的架构师？今天就来讨论一下。

以下所有的讨论，都局限于汽车自动驾驶设计这个范围内，超出部分不论。

架构是什么？

提到架构，就要提到系统。在我看来，系统是为了实现功能而设计的所有硬件和软件的集合。而架构就是用来解释这些硬件和软件是如何分工，如何组合，以及划分完成后各个软件和硬件模块之前接口定义的抽象。

如果把系统比作一幢房子，那架构就是图纸，规定了这个房子要有几个房间，每个房间做什么用，为了让这些房间实现功能，它们分别应该有什么样的大小，朝向，水电煤气管道，以及相互之间的位置关系。事实上，架构这个词就是来源于英文的Architect，也就是建筑师的意思。

一张图纸，可以表示房子的“架构”，那对于自动驾驶系统，该如何来表示它的架构呢？一些工具软件可以给我们更清晰的概念，比如PREEvision中，把架构分成了逻辑层，硬件层，通讯层这些不同的层级，简单的理解就是：

逻辑层定义了要实现功能的软件模块和软件模块之间的交互关系；

硬件层把这些软件模块映射到不同的ECU或传感器当中，和硬件“绑定”起来；

通讯层把硬件模块之间的信号和硬件接口归纳起来，形成引脚定义和通讯矩阵。

这个分层概念极其精辟，精辟到不需要一句多余的话来解释。

以AEB为例，

逻辑层是这样的：

硬件层是这样的：

通讯层是这样的：

看上去很清晰吧，但按照这个程序做出来的“架构”只能说是有了，而不能算是好的。要做出一个出色的架构，需要考虑的问题非常之多。借用一张别处的图片：

如何做一个好的架构师

首先，要通过沟通明确系统需求，架构不是一个架空的东西，所有的输入，都来源于和需求方反复的沟通和确认，不但要能够理解别人要什么，还要引导对方去完善这个系统，增加细节或者删除不合理的内容。在汽车行业，这往往意味着架构师本身对于整车各个子系统都有涉猎且有深刻的理解，这时候的工作内容，甚至有一些产品经理的色彩。

其次，要有非常强的抽象能力，能够把这个系统功能用逻辑模块的方式表达出来，每一个逻辑模块，都必须是在软件上可以实现的，这就要求对于软件和软件工具也有一定的理解。架构可以不是写软件写的最好的那个，但一定要会用，否则这个表达方式将很难被软件工程师接受。软件工程师会负责每一个子模块的开发，架构必须要明确这个子模块的需求，这个时候的工作量简直爆炸，然而并没有人可以帮助你。

再次：需要有用战略眼光评估方案的能力，不同的架构，在可读性，成本，开发周期，可拓展性等等方面都有不同，所有的概念都必须存在于架构的脑中，不可忽略任何一点，优秀的架构可以使各个方面都得到平衡和优化，这个时候架构依然需要孤军奋战，因为项目和其他部门可能会提出各种各样的意见，但解决方案还是得架构自己提出和完善。

最后：协调能力，架构毕竟是一个相对高级或者抽象的设计，在开发过程中，很多细节问题会不断暴露，这时架构又要成为一个类似项目经理的角色，去协调各个工程师和部门，跟踪问题清单，还要和工程师一起制定解决方案。当然，越优秀的架构，在前期考虑会越全面，以减少过程中的变更，但对于一个很大而且很新的系统，这种问题不可避免。

此外，架构师有时可能会规定技术标准，包括编码标准，工具或平台。软件架构师也可以参与硬件环境架构的设计，或者可以完全专注于代码的设计方法。

在写这篇文章之前，我查阅了软件架构师的解释，深深的感受到两个冲击：

第一：架构师这个抬头已经被滥用了

第二：由于“架构师”这个概念是从软件行业舶来的，所以过于强调了写代码的能力，而稍微忽略了其他方面的能力

其实从上文就可以看出，架构师是一个综合能力要求非常高的岗位，任何一个成为架构师的工程师，都有理由为自己感到骄傲。这是团队中为数不多的“知其然，也知其所以然”的角色。

看看“果壳机动”的其他文章