一片蓝海——汽车软件的前景 （二）

紧接上文：

一片蓝海——汽车软件的前景 （一）

在整个SOA演进中，软硬件解耦是必然趋势。传统汽车电子电气架构（E/E架构）呈现是分布式的，已经不再适应新电子电气架构的需求（软件定义汽车时代）。
-> 传统电子电气架构中软硬件高度耦合，软件功能的实现是基于甚至是依赖于硬件。在整个车载研发过程中，若需要增加新的功能，需要改变所有与之相关的Software。与此同时，也需要相应改变车内总线布局、功能、系统升级（Software Update）。会致使修改很是繁琐，后期OEM集成验证也会相应的更加复杂困难。特别是需要协同实现功能时，如果其中一个ECU出现问题，可能会导致整个功能全部失效。

->在传统电子电气架构中，不同供应商开发不同的软件架构，互相之间无法实现复用，在新的软件更新框架下（OTA），无法统一对ECU进行Software update；
->在传统电子电气架构中，OEM是整车框架的定义者，但车身具体功能是由ECU独自完成。整个过程软件开发的工作是由供应商完成（Tier1）。OEM在验收ECU具体功能后，对每个供应商提供的ECU进行集成验证。这也是以往OEM，会有一个车身框架，安装所有的ECU在整个车身环境进行上电运行验证其具体功能（主要是在整车环境下，因为对于ECU Supplier而言，没有这样的整车验证的环境，只是做单个ECU功能验证）。也是因为如此，OEM软件开发能力普遍偏弱，这个也不是通过挖许多人，成立软件研究中心一蹴而就；

->随着车辆驾驶者对于出行需求不断提升，以及技术不断更新迭代。车辆也慢慢开始向智能化和网联化发展。以往单一控制器策略（单个ECU），以分布式电子电气架构，实现整车功能控制方法明显已经不能满足时下车载智能产品的开发需求。特别是由于自动驾驶功能概念的引入，对于海量数据的处理、传输、以及成本考量。因此车身电子电气架构转变不可避免——从分布式架构向域控制器架构、中央计算架构转变，而集中化的E/E电子电气架构是实现软件定义汽车的硬件基础。

借助于新的E/E架构，实现软硬件解耦，软件功能开发逐渐通用化、平台化。特别是车载AUTOSAR软件架构出现。以前车载分布式软件架构是一种面向Signal的通信框架，ECU之间通过信号来传递信息，报文作为信息的载体。这个框架已经使用多年，是成熟的车载解决方案。整个车身框架是基于车载CAN总线布局，总线下面下挂每一个域的控制器，通过CAN ID发送广播，实现有效通信。
但是这里有一个弊端，整个软件系统是封闭的、静态的，全部车载功能定义在编译阶段就完成，若OEM要修改或增加具体ECU的功能定义，或者该需求指令需要调用另一个ECU上的功能时，必须把所有涉及到的ECU都进行升级，这样操作就大大延长开发周期、增加开发成本。整个V模型是固定的，这也是德国人在此处玩的很转的原因，本身民族的特性就是在固定模式下细化精化完善。

但随着新的电子电气架构对车载软件提出的新的要求，特别是OTA引入，在自动驾驶领域，随着海量数据的喂养，自动驾驶的算法不断在优化，这就需要很快的频率更新迭代车载软件版本。而原有电子电气架构下的夜店——软硬件高度嵌套，会导致硬件之间难以形成较强的协同性，汽车软件的可复用性和OTA 升级能力整体较弱。
随着汽车电子电气架构趋于域控制器化、集中化，域控制器或中央计算平台以分层式或面向服务的架构部署，整车ECU数量大幅减少（传感器和执行器数量变多），车载控制器底层硬件平台需车规芯片提供更为强大的算力支持，车载控制器软件也不再是基于某一固定硬件开发，而是要具备可移植、可迭代和可拓展等特性。汽车原有以ECU 为单元的研发组织将发生转变，形成通用硬件平台、基础软件平台以及各类应用软件的新型软件架构。这样的架构可以使软件功能实现快速迭代，而、这也是诸多OEM在布局软件研究中心的核心原因所在。抓住车载软件能力，相当于在这个浪潮中拔得头筹。


向如下模式转换


实现软件定义汽车的关键是提供一个稳定的平台，因此智能车载软件架构需向SOA架构转变。以往的车载软件架构是面向信号的架构（Signal-Oriented  Architecture），控制器功能是固定的，软件被提前编写在控制器中（量产进行烧录）。随着智能汽车的发展，车载ECU数量逐年增多，导致ECU之间点对点的通讯变得十分复杂，且不具备灵活性和扩展性，微小的功能改动都会引起整车通讯矩阵以及各ECU软件的变动。比如现阶段应用最广的是基于车身CAN总线的架构，在设计时，就会定义好整车级通信矩阵，当有需求变更时，需要涉及的内容会有关联关系，影响比较大（但是话又说回来，以往车企新车型更新速度也比较慢、比较固定）。同样情况，对比SOA（Service-Oriented  Architecture，面向服务的软件架构）是一种软件架构（准确说是软件设计方法和理念），其特点就是：
-> 对外接口标准化；
-> 软硬件耦合度低；
-> 框架灵活，且易于扩展。

查资料获知，SOA 架构中每一个服务都具有唯一且独立互不影响的身份标识（Identifier），其定义了清晰的功能范围，并通过中间件实现自身任务的发布、对其他服务的订阅以及与其他服务的通讯工作。通过上述独立互补影响特点可知，SOA架构可解决传统架构中因个别功能增减/变更而导致整个通讯矩阵与路由矩阵都要变更的问题（该架构的易扩展性）。
另外，SOA架构中每个Service Interface的特性是“标准可访问”，服务个体的设计、部署不再依赖于具体特定的硬件平台（低耦合性的特点）、操作系统和编程语言，同样的组件/功能可以通过标准化接口在不同的车型上实现复用，实现组件的“软硬分离”，达到跨平台复用的效果。

在时下汽车智能化时代，车载软件的更新迭代频率越发短暂，因此独立于硬件的软件升级是持续为客户提供价值的关键（可参考头部车企特斯拉的OTA更新频率）。由于SOA 架构具有“松耦合”的特性，服务组件和硬件均可以标准化地接入和访问，若要新增某一功能只需增加相应的服务组件并使其调用不同的硬件功能即可。这样可以促使每家的开发人员抽出更多精力和资金专注于上层应用的开发，而无需再对底层算法甚至各个ECU 中的软件进行重新编译，这也解决了相同的应用在不同车型及硬件环境下重复开发的痛点，使得汽车软件架构十分灵活并易扩展。（有好处也有坏处，会容易导致技术壁垒形成，造就技术寡头）。
在这样的环境下（软硬件解耦以及汽车软件架构向SOA 转型），车载软件产业链被重新建设，越来越多的玩家加入这样的行列：

1、越来越多的OEM构建自己的软件能力，在这个过程中，增强了软件自研能力、系统架构能力以及SOA架构能力。大部分车企通过合资或者独资成立自己的软件研究院，已经完成了软件自研能力补充或升级，构建了平台型架构体系，以往传统车企的开发模式逐步向面向软件定义汽车的开发模型过渡。
整个过程也划分不同阶段，现主流电动车OEM已经在迅速布局：

建立软件自研能力：OEM开始自研车载软件，将自身需求和设计、代码编写、软件架构等能力打通；

伴随自研能力加强，OEM会逐步建立系统建构能力，实现“硬件通用平台化”与持续可升级；

最终模式是OEM建立自身SOA架构，通过标准的服务接口、耦合度低的服务机制，结合高算力高性能计算平台，打造汽车“软件驱动”基础能力。


2、凭借这个东风，许多国内外软件供应商一跃成为Tier1供应商，在整个产业体系中话语权也在不断加重。随着新的车载软件架构不断更新迭代，其开发难度不断增加，于此同时传统的汽车Supplier研发能力难以满足需求。在这样的背景下，OEM主动绕过传统一级供应商，直接与原有的二级供应商（芯片、软件算法等厂商）合作。在软件定义汽车时代，软件重要性不言而喻，整车厂为了掌握主导权并降低高昂的开发成本，会选择直接与较强的独立算法研发能力的软件供应商合作。
注：OEM将底层基础软件（系统软件层）作为发展核心，车载SOA架构对汽车生态开启新的构建，个人猜想汽车行业极有可能复制PC和智能手机的软件分工模式。OEM自建或与供应商合作搭建操作系统和SOA平台，引入大量的算法供应商、生态合作伙伴等形成开发者生态圈，未来车企能够向用户提供全生命周期的软件服务。
汽车软件产业在汽车智能化的进程中被重塑，从大的方面对于软件供应商有了更好的机会，一跃成为话语权高的Tier1。我国汽车行业也可以站在一个起跑线上（其实我们已经部分领先），可以有更好的一个行业环境。从小的方面，对于我等从事汽车行业的工程师，也是一个非常不错的发展机会。政策导向和海量资金涌入，以往不敢设想的技术点，有了更多的突破机会。


因自己一直从事车载诊断行业，新的电子电气架构也给自己带来了很多的思考。以往分布式电子电气架构中诊断需求规范是每一个ECU都有自属的需求规范，单独基于这个芯片开打诊断Software即可。做集成测试时，也方便掌控。但是伴随域控制器、车载以太网以及新颖的通信策略，对于诊断功能的定义、诊断功能界定策略都带来了新的Topic：
1、以往控制器架构更多是单个ECU控制一个功能（BCM、ICM等），现在更多是以域控制器+Sensor和执行器，每个部件诊断判定策略、存储策略、信号触发方式发生改变；
2、更多的车规级操作系统引入，对于Sensor和执行器判定后，怎么与中央处理器数据交互？出现故障时，以怎样的触发方式告知存储方？
3、当一个故障由多个引发点（Error event），每一个点都来自不同的输入源，怎么快速界定？通过定义Snapshot快照信息是否可以完成此功能?是否也可以UDS原有的框架基础上，新定义一个自属服务，完成自己需要的功能？
以上种种，都是茶余饭后自己对行业的思索，仅供参考！