在上一篇文章《集中式架构-多集中算集中？》中，介绍了集中式电子电气架构的概念和发展趋势。今天来讨论一下集中式架构是不是适用于所有的OEM。

在聊这个主题之前，我们有必要看看怎么才能作出一个集中式的架构……

我们已经说过，所谓的集中式架构不管形式如何，其本质都是把多个域的功能集中到一个控制器中，只不过采用的技术方案或集中度有所不同。

无论怎样设计和开发集中式架构，首先需要完成的肯定是选择方案。

无论选择One Brain，One Board还是One Chip，第一步至少搞清楚以下几件事情：

自己未来的产品路线究竟是怎么样的？

想通过集中式的架构实现哪些目标、承载哪些功能？

有哪些芯片可以选？

自己的组织中有哪些人？具体的能力怎么样？能够做什么？

有哪些供应商可以选，他们现在有什么，能够做什么？

接下来，我们进行逐个的讨论：

1. 产品路线

行业内关于集中式架构的讨论，大体始于某斯拉的Model 3。而且由于某斯拉的成功，似乎所有人都想抄作业。然而，经过长时间的热烈讨论后，完全复制其架构的人却没有。即使现在有很多的自封为集中式的架构出现，但样式却五花八门。这是因为，人家的3和Y的配置和功能基本是完全一样的--都是那么少，唯独智能驾驶和座舱的软件功能一直在迭代。那么多年过去了，除了智能驾驶和座舱，其他的硬件也没有啥变化。这个才是真正的平台化：一次开发，多个项目长期使用。因此，即使其整个架构的开发成本高昂，但平摊到每台车上的成本却非常低。这就是人家的NB之处，通过毕其功于一役的方式，直接打造了一个天花板，让众多的竞争对手难以望其项背。最厉害的人都是这样的，你知道他的套路和招式，却没有能力应对，或者作出了各种努力，然而却是然并卵。

采用集中式架构的一个先决条件是：能够找到自己未来产品规划中的核心部分，而且这个核心部分还是普遍适用于每个车型的。对于大多数的OEM而言，其产品线是极其复杂的。因为大家普遍相信：多生孩子好打仗，而且要大小通吃。当一个架构既要适用于10万元的车，又要使用到30万元以上的车，那对架构的挑战是非常大的。因为当集中度高的时候，就意味着要使用算力较高的芯片，且将很多功能集成到一起，那么这个控制器（或称为计算机）的成本就肯定比较高。当这个控制器使用到成本较低的车型上时，就必然有些功能要被阉割掉，而且由于这个控制器较高的成本，导致低成本车型的基础成本上升，从而可能导致车型的市场竞争力和利润率的下降。

尽管架构设计时都会考虑一定的带宽，但带宽不可能无限大，尤其是对于集中式架构而言，其几个核心控制器的成本是基本固定的。例如，当采用舱驾融合的方式时，你想只卖座舱功能就不再可能了，因为智驾功能和座舱功能已经绑定了。如果非要多出来一个只有座舱的车型，那么就需要单独开发一个座舱控制器，于是，舱驾融合的方案的装车率就会大幅度下降，从而导致单件的实际成本大幅度上升！

说来说去，其实就是一句话，先把产品路线想清楚，再讨论架构的事情。

2. 设计目标

选择集中式的架构，需要投入大量的资源，付出很大的代价。那么，你必然指望通过它实现一些具体的目标。

智能手机的成功，在于其以较低的成本集成了大量的功能，将原来的电话、PDA、导航仪、MP3、影音等设备都集成进来后，总体的成本下降了，而且有无以伦比的方便性。技术的革新一定要能够解决某些现有技术所无法解决的问题，具有一定的性价比。那种为了不同而不同的所谓创新往往都会死的很难看。集中式架构也必然要遵循同样的定律。

要么在实现同样的功能上有成本的优势，要么维护方便，要么更方便更新迭代，要么就是能够实现更多的功能或更好的性能。否则，投入巨量资金和人员开发的东西无法带来实实在在的好处，除了在发布会上自嗨一阵之外就不会有任何用处了。除非你吹的方法真的与众不同，而且还能长期的唬住大量的人，让他们持续觉得你NB。要不然，很快就会被遗忘。因为现在的PPT都是专业的，想靠概念取胜已经很难了。

3. 芯片选择

能做跨域融合的芯片很少，基本上屈指可数。但究竟选择哪个呢？这个不需要特别纠结，当你想清楚你的产品路线和设计目标之后，基本就可以确定了。

如果你决定舱驾融合或者行泊一体，将来的每个车都有类似的配置，那么就去看看究竟哪个芯片的性能和功能能够满足你的要求就可以了。基本上可以按照QCD（Quality，Cost， Delivery Time，即：质量、成本和交付时间）的维度进行选择。

这里不得不提醒的一点是，供应链的安全。安全分成两个维度，一个是芯片供应商是否能够长期稳定的供货，不会因为什么所谓的不可抗力而断货。另一个是Tier1供应商是否能够提供长期的升级与维护服务。因为每个架构的生命周期至少都有5年以上，如果过几个月就因为种种原因而停货了，那损失就太大了。这要考虑的点就很多了，比如：国际局势、供应商的实例和产线分布、供应商的产品路线图、行业发展趋势等，这个很难考虑那么全，但是又不得不考虑。风险总是存在的，有时候只能看运气了。

当你把很多东西都集中在一个控制器或者一个芯片的时候，你就完全被它控制了。

4. 评估自己和供应商的能力

除了看说明书对芯片进行选择以外，还要考虑到很多其他因素，其中最重要的是总体能力。总体能力包括OEM自身的能力和供应商的能力的总和。因为OEM作为具有钞能力的金主爸爸，只要舍得花钱，就可以获得很多供应商的帮助。所以，即使自身能力有所欠缺，也可以通过整合供应商资源来实现总体能力的提升。这个就如同漂亮国组建的北约一样，只要实现目标所需要的能力可以获得，那么就可以完成任务了。

只不过，当OEM自身能力强的时候，被人忽悠的可能性就会小很多，因此付出的代价也会小。但如果OEM愿意使用他的钞能力，那么也可以在实现业务目标的同时积累很多的Knowhow，并将其转换为自身的能力。

做一个集中式架构并不是很多人想象的那么简单-将几个控制器的代码合并到一个控制器中就可以了。首先，这几个原来的分布式控制器肯定是由多个供应商分别负责的，有能力将多个供应商的Knowhow整合到一起的人至少要对原来的每个控制器都很了解，从而能设计出一个合适的软件架构。其次，原来控制器中的很多核心算法都是各自设计者的看家本领，没人愿意轻易贡献出来的，不是你想买就能买的。对于被集中的那些供应商而言，卖了吃饭的家伙后就只能等着饿死了。于是，整合者最大的考验就是要解决怎么整合的问题。解决的方法只有两个，要么OEM和负责整合的供应商有足够的能力，要么就只能花大价钱买知识了。

假设上面的问题都解决了，开发的工作才能真正开始。怎么样把原来通过总线通信传递的信息变成控制器内部的信息、将原来控制器的I/O(输入输出)与控制逻辑解耦并剥离、充分利用新芯片的各种资源等，是解决探险途中各种各样未知问题的首要任务。很多人看了一些武侠电影或小说就觉得自己是武林高手了，开发过程中才能检验自己的幻想是不是变成了现实。在软件开发中，1+1不等于2。很多时候会等于4甚至是10。当代码量变为2倍的时候，复杂性可能或上升一个数量级。这是软件思维与机械思维的最大不同点。

总之，永远不要高估自己的能力。汽车电子产品与软件开发的复杂是超乎想象的。

5. 引申一下，且谈一下组织架构的改变

想象一下，以前的分布式架构有三个控制器，分别归属三个部门负责。当变为一个集中式控制器后，究竟由谁来负责呢？不论怎么分，都必然有人的工作职责和技能要求改变了，有人可能无事可做了，供应链的结构也变了。这些都会涉及到众多的利益。俗话说，断人财路如同杀人父母。这种大的变革，如果没有管理层的强力支持，是无论如何也推行不下去的。因此，新势力在新架构的实施方面有天然的优势。

根据康威定律：“设计系统的架构受制于产生这些设计的组织的沟通结构。” 通俗的来讲：产品必然是其（人员）组织沟通结构的缩影。反过来讲，要想开发某一种形式的架构，组织形态需要最先按照这种架构形式进行改变。

如果不能改变组织架构，将组织架构进行集中，那么集中式架构也很难搞成。

复盘一下再：

1. 集中式架构也是有很多代价的，这些代价包括但不限于产品配置阶梯变少，开发和维护成本上升，测试复杂度增加，供应链安全性降低，迭代升级的成本增加，导致组织重构等。

2. 过度的集中会带来大量的问题

3. 不能为了集中而集中

4. 集中式并不一定是汽车架构的唯一发展方向

5. 架构是为产品服务的，产品是要拿出来卖钱的

6. 不是所有的车企都适合搞高度集中的架构

7. 不要人云己云，抄作业。

最后，再次以莎士比亚在《亨利四世》中的名言结尾  “Uneasy lies the head that wears a crown.” 欲戴其冠必承其重！