软硬件全部自己来…这家汽车厂做得到吗？

德国汽车大厂大众(The Volkswagen Group)宣布了一项雄心勃勃的策略，表示将把旗下每辆汽车的电子控制单元(ECU)从现在一辆车约70个的数量减少到只有3个，而且要自己开发几乎所有所需的软件──目前是由多达200家的软件供货商伙伴所开发。

如果大众的新策略进展顺利，将使得其供应链中许多环节变得多余。而据了解，负责该车厂数字技术开发之大众集团管理委员会成员Christian Senger在今年夏天举办的一场活动中，对旗下供货商表示：“我其实只需要你们之中的一半。”

对于这种说法，如今大概没人会感到惊讶。如市场研究机构Strategy Analytics的全球汽车产业部门副总裁Ian Riches接受EE Times访问时表示：“随着现在的车辆越来越朝向软件定义，软件的功能与质量，有效决定了驾驶与使用者体验。在这种情况下，大众的策略非常合理，这让该公司能牢牢掌握对于产品差异化越来越重要的核心技术。”

另一家市场研究机构Semicast Research的首席分析师Colin Barnden也同意以上说法，表示这代表大众想要拿下主导权。

不过也有很多产业观察家认为，该车厂的愿景恐怕要很长一段时间才能实现；如自动驾驶技术开发顾问机构VSI Labs创办人暨首席顾问Phil Magney表示：“我们其实一直在呼吁这一点，但总得有人先走一步；”他指出，大众的决定是首度有汽车大厂跨出大步，表示“我们都面临基础架构的变革。”

“必须有人出来领导整体工作，并为车辆的电子/电气化架构基础性变化设定方向；”Barnden认为，“这需要是『从头到尾』，因此Tier One或Tier Two汽车零组件供货商不能成为领导者。不过我预期Bosch、Continental、Magna，还有Nvidia、Xilinx与ZF等公司将会有很多参与。”

为什么要整合硬件？

实际上，汽车产业供应链上的几乎所有相关业者──包括车厂、芯片与IP供货商──这十年来一直在讨论需要进一步整合ECU的问题；车厂偏好自己设计先进驾驶辅助系统(ADAS)以及自动驾驶车辆的芯片，已经不是秘密。

西门子(Siemens AG)自动驾驶与ADAS部门全球技术经理David Fritz几个月前接受EE Times采访时表示：“我其实已经看到每家车厂内部都有自驾车SoC的设计图，不只有特斯拉(Tesla)； 每一家车厂都想掌控自己的命运。”

说到产业界要将每辆车ECU减少至3个的愿景，Semicast的Barnden预期“车厂会有好几代的技术更迭，而且需要花很多年的时间；”他认为可以将车用电子架构分成以下三大块：

•推进系统──内燃机引擎(ICE)、电动车(EV)、混合动力车辆。
•安全系统──安全气囊、煞车、转向、ADAS。
•车身系统──空调、车门模块、座椅电子零件、手剎车、照明、防盗系统。

Barnden表示，前两种系统必须要达到ASIL-D安全等级，最后一种大概ASIL-B就可以；此外车用资通讯娱乐系统(IVI)则不属于以上任何一个类别，但从ASIL的角度来看，IVI更接近车身而非推进系统或安全系统。

如果ECU整合听起来合乎逻辑，为何到现在还没发生？很多分析师认为这是车厂的惰性。如VSI Labs的Magney观察：“大众宣布的这个想法其实已经被讨论了很长一段时间，就算不是全部也是大多数车厂的共同方向；朝着集中化功能域控制(centralized domain control)移动的速度非常慢；”这都是“没坏就不要修”的心态，他解释：“传统架构运作非常顺利。”

既然是这样，为何需要改变？Magney表示：“我们来到了传统架构所能支持的生命周期管理极限，车用资通讯系统证明了这一点，而且车厂终于妥协了(虽然只有一点点)；现在我们朝着智能功能的实现更进一步，而且这类功能一直在变化与改进，新架构能支持这样的趋势，但旧的架构不能。”

管理与重量都是问题

促使车厂寻求更高整合度的一个主要原因，是他们希望能掌控自己的命运；这也是过去几年来接受EE Times访问的许多产业观察家表达过的一个共同主题。Magney表示：“现在大众声称有超过70个ECU执行不同的功能，基本上都是黑盒子；这些黑盒子成本高昂也不容易扩充，更重要的是，这从软件的角度来看很难管理。”

Semicast同意以上看法；“我们看到的是摆脱一个ECU负责一种功能的作法，转向『功能域控制器』；不然像是现在的S-Class或A8等车款，内部ECU会达到上百个。”他指出，整合很重要，因为“测试所有ECU之间的互操作性”会变成一个大问题。

Barnden也提到重量的问题，“包括将所有功能连接在一起所需的线束重量；就像是航空业，重量等同于燃油消耗；而随着排放测试变得越来越严苛，车厂得想出办法来减少车辆的实体重量，以改善燃油效率。而减少ECU数量(并因此降低线束复杂度)，会是一个好方法。”

他进一步指出，朝向车用以太网络发展的趋势有部份也是为了车辆减重，该技术能用可共享的单一高速网络取代点对点的CAN/FlexRay/LIN总线。在被问到大众的动机时，Barnden则猜测，这是该车厂对于多年前“柴油门”事件的进一步响应，在全球日益高涨的公民环保意识之下，他们必须以真正激进的方法来带头降低排放。

完整的软件堆栈

VSI Labs的Magney指出，福斯准备开发完整的软件堆栈，“我的意思是说完整的车辆软硬技术堆栈…这类似于Tesla自己开发所有软件；”而产业分析师们倾向于赞同大众的做法：“这么做是对的，你不能承担不朝着这种方向发展的后果。”但大众实际上是否能做到还有待观察；Magney表示：“挑战很艰巨，而车厂是否有能力克服？我们且走着瞧。”

Strategy Analytics的Riches也认为大众的策略是远大理想：“在短时间之内，要从一开始几乎不需要为车辆编写软件、或是很少量软件，变成全部自己写，显然是非常高的要求。”

来自美国卡内基美隆大学(Carnegie Mellon University)教授暨Edge Case Research技术长Phil Koopman的评价或许更具针对性。他在一篇LinkedIn的贴文上引述了《Automotive News》的大众报导，然后写道：“大众说要朝向集中化的计算机架构，并且要自行负起开发软件的责任，不依赖来自供货商的软硬件模块；这是为掌握更多价值的大胆举措，并非易事。”

Koopman质疑，由计算机程序设计师Melvin Conway在1967年提出的“Conway定律”是否会带来影响；Conway在那时候提出的是：“设计系统的组织…会受限于产出实际上是复制这些组织通讯架构的设计。”

“Conway定律”意指要让一个软件模块发挥作用，多个作者必须要彼此经常沟通；或者说，“系统会看起来像是生产它们的组织。”简而言之，大众的软件堆栈表现水平，就是跟该公司的软件开发人才一样。

在一方面，汽车产业显然同意，车厂掌控整个车辆(软硬件)的作法是正确的；但并非所有人都有信心能实现这个目标，也没人拥有可尝试的蓝图。Koopman表示：“要成功就要有大幅度的改变，”但实际上要有那些大的改变？

需要改变的包括(车厂内部)组织性议题，还需要有产业层级的改变，科技业者与传统汽车业者对于下一步该怎么走的看法也要改变。Strategy Analytics的Riches指出：“软件与硬件之间完美紧密结合的时代已经过去了；”他认为长期来看，车厂有两种可行做法。

Riches表示，第一种方法是像大众那样，“通通都自己做；第二种方法则是车厂扮演系统整合者的角色，为特定的任务寻求最佳软件供应来源，无论他们认为谁是最佳供货商。”

全部自己来真的可行？

上述的第一种方法能取得绝对的掌控权，在某方面会让事情简单化；不过Riches表示：“像大众要为每个功能与领域开发出绝对一流软件是不可能的，没有人实际上有能力做到这一点。”第二种方法能有更多弹性：“但是管理与整合不同供货商所带来的复杂性不容忽视，当某个地方出错，大家一定会说是别人的问题。”

目前虽有诸如美国联邦机动车辆安全标准(Federal Motor Vehicle Safety Standards，FMVSS)这样的法规，负责规范车用零组件与系统设计的安全性，但像是ADAS或是自动驾驶等较新技术都未被纳入监管。而汽车产业已经习于“自我认证”车辆安全性，希望能掌控整个软硬件架构的想法是可以理解的。

但车厂们是在回顾过往年代，这种他们偏好的封闭作法只会让他们画地自限，因为他们可能会开发只能用在自家硬件上的独特系统。上述《Automotive News》的报导指出，大众自己开发的操作系统会类似于“智能手机与计算机的后台软件”，但事实上今日大多数的手机操作系统是开放性的，手机业者在开发产品时有大量的应用处理器与调制解调器芯片可选择。

除非大众把自己设想为汽车领域的苹果(Apple)，恐怕要实现其远大理想将会遥遥无期。对此Riches提出了一个最关键的问题：“大众能否建立所需的内部敏捷性与灵活性，让管理数十个或是数百个内部团队的复杂度与出错程度，能低于管理相同数量的外部供货商？”