「软件定义汽车」时代下的SOA架构设计.docVIP

「软件定义汽车」时代下的SOA架构设计 从「软件定义汽车」到SOA 用「软件定义汽车」，这可能是当今业内智能网联汽车的“风口”下，被“炒”的最火的一个概念了。 为什么这么火？ 我个人觉得无外乎有以下几个原因： 首先，在以内燃机为核心的传统汽车被新能源智能汽车颠覆的趋势下，软件在产业价值链和商业模式中的重要性越来越大：以前车厂卖车，商业模式好比是“一锤子买卖”，从机械到硬件到软件，成本和利润全部都“打包”在车价里，一旦车辆被消费者购买以后，整车厂的利润所得就到此为止了。 而现在呢？拥有智能网联功能的汽车被卖到最终客户手里以后，整车厂仍然可以通过OTA的形式对车内软件包括固件进行升级，更新，甚至添加新的应用。这样一来，只要汽车没有报废，消费者就可以通过OTA源源不断地获得更多新的“功能体验”，比如ADAS系统从L2升级到L2.5后获得更加成熟的自动驾驶体验，电源管理系统BMS升级后续航里程获得大幅提升等等。 但是，天下没有免费的午餐！所有新的驾驶体验，功能体验和性能升级都是需要消费者来额外购买订阅的！这种全新的商业模式最早由特斯拉推出，而现如今已经越来越多的被其他整车厂所效仿和采用。 至此，整车厂的盈利模式就由以前的“一锤子买卖”变成了现在的“摇钱树”模式，值此发展下去，传统的4S店都有可能被慢慢取代：以前一些必须送修的故障或者返厂升级的Service工作，现在都可以通过OTA就可以轻松解决了。 或许会有朋友不同意以上的这种说法，但是单单依从进化趋势来讲，我认为：未来的智能网联汽车，本质上，或许真的就只是一台装着4个轮子的高性能计算机。 其次，随着车联网，信息娱乐系统以及ADAS系统的不断发展壮大，车内控制器的复杂程度也将越来越高，其所属的软件代码的行数也将必然会呈现指数级增长。而相对应的软件研发的费用在整车研发费用中的比例也将会大幅增加。 三十年河东，三十年河西，各大车企以及供应商的硬件研发团队或将面临严峻挑战，随之而来的是软件团队的不断发展扩大。所有跟车内软件开发相关职位（嵌入式软件开发，Linux内核开发，功能算法开发等等）的薪资都将水涨船高，人才市场上的竞争不可谓不激烈。在未来高收入程序员的队伍中或将又多出一类新人群 —?汽车软件工程师！ 倘若我们从技术层面来分析：智能汽车内的系统复杂程度的提高是“起因”，而「软件定义汽车」就是自然而然会产生的“结果”。这个因果关系明了了，对我们这些开发人员来说，总的“指导思想”就算树立好了！ 现在新的问题来了：「软件定义汽车」和「SOA」（Service Oriented Architecture）有何必然联系？ 对此，AUTOSAR标准给出的解释是这样的： 为了支持复杂的应用程序，同时在处理分布和计算资源分配方面提供最大的灵活性和可扩展性，AP（Adaptive Platform） 因遵循面向服务的体系结构 （SOA - Service Oriented Architecture）。 SOA基于这样一个概念：系统由一组服务组成，其中一个服务可以依次使用另一个服务，以及根据需要使用一个或多个服务的应用程序。SOA 通常表现出系统间系统的特性，AP 也具有这种特性。例如，一个服务可能驻留在一个应用程序也运行的本地 ECU 上，或者它可以驻留在一个远程 ECU 上，该 ECU 也在运行另一个 AP 实例。两种情况下的应用程序代码是相同的——通信基础设施将处理提供透明通信产生的差异。看待这种架构的另一种方式是分布式计算，通过某种形式的消息传递进行通信。总的来说，所有这些都代表相同的概念。这种基于消息传递、基于通信的架构也可以从快速和高带宽通信（例如以太网）的兴起中受益。 ” 这段话的重点，强调了SOA架构的灵活性和可扩展性，而这个恰恰与「软件定义汽车」的思路不谋而合。但是，通过采用SOA架构，虽然可以更好的支持车控软件的分布式部署与更新迭代，但是这在基于信号的通讯架构（Signal-oriented Communication Architecture）下是不太可能的，至少是十分困难的。 这时候有人可能会有疑问：“特斯拉就没有使用SOA，不照样可以通过OTA进行迭代升级么？” 其实，实现OTA，并不需要SOA。 别说特斯拉用的是基于Linux的操作系统了，就是在跑CP（Classic Platform）的MCU（MicroController Unit）上也可以实现OTA，只是具体方法有所不同。 在SOA架构下，OTA的实现更加方便灵活，最主要的一个优势是可以实现软硬解耦，服务实体可以部署在任意的域控制器上，而且可以在出厂后进行部署策略的调整。 这个优势衍生出了SOA在汽车功能安全方面的另外一个先天优势——冗余。例如，对于安全性要求比较高的功能可以进行冗余部署，比如刹车控制服务，转向控制服务可