|
上一篇文章主要介绍了电子电气架构、车载操作系统、基础软件平台等之间的关系，以及软件定义汽车的基本概念，本篇将继续深入，重点阐述三个问题：
一、智能电动汽车软件范畴按照新能源汽车的特点以及中央计算电子电气架构的发展趋势，可以按照以下三个类别，对智能汽车软件进行分类：动力与底盘控制器、车身控制器、中央计算单元。 智能电动汽车软件分类.jpg
动力与底盘控制器底盘类的功能，包括电子转向（EPS）、电子驻车（EPB）、车身稳定（ESP）、集成动态制动（IDB）等等，都是牢牢的掌握在了一线Tier手里，这部分软件都是和机械零部件绑定在一起的，在其整个生命周期内不会发生功能的改变（可能会重新标定新的参数），实现的是车辆运行最基本的、有最高功能安全等级要求的、微秒级时延的功能。所以即使是在集中式的电子电气架构下，未来很长一段时间，这部分功能都会以独立ECU的方式存在，遵守Classic AutoSAR标准进行开发。在“动力与底盘”控制器中，整车厂唯一可以做并且非常有必要的是，提供一个底盘域的适配层，为中央计算单元提供标准的线控服务，这样以来，中央计算单元就不用单独和各个底盘ECU通信（不同车型可能使用了不同Tier1的产品），可以做到中央计算单元和车型平台解耦。动力类包含了新能源三大核心技术，整车控制器（VCU）、电机控制器（MCU）和电池管理系统（BMS），其中VCU通过采集油门踏板、挡位、刹车踏板等信号来判断驾驶员的驾驶意图；通过监测车辆状态（车速、温度等）信息，向动力系统、动力电池系统发送车辆的运行状态控制指令。BMS负责估测动力电池组的荷电状态 SOC，即电池剩余电量，保证SOC维持在合理的范围内，同时监测电池充放电过程中的温度、电流、电压等，保持整组电池运行的可靠性和高效性。MCU系统根据数学模型，采集位置、电流信号，对IGBT进行通断控制，形成交变磁场，从而控制电机按目标进行运转。这三大部件对整车性能有着重要影响。越来越多的主机厂选择自己进行开发，也就有了往集成化方向发展的基础，可以逐步将功能迁移到“底盘与动力”控制器当中去。
车身控制器传统也叫BCM，车身控制相关的功能包括，车门、车窗、天窗、雨刮、照明、空调、空气净化、无钥匙进入等等，整车厂对这部分具有很高的决定权，现存的绝大部分ECU上的功能都可以搬到车身控制器上去，按照开关、传感器、执行器的维度对原有ECU的功能进行分解，主机厂可以自己开发，也可以要求Tier1按照规范提供软件模块，由主机厂进行集成。
中央计算单元中央计算单元的集成的三个重要模块分别是自动驾驶、智能座舱、通信单元。为什么把这三块放在一起，下一章会详细介绍，本节重点介绍其内容。自动驾驶，软件上具体的要做的事情，上一篇有过介绍，其核心是算法和数据的积累，稍微有点实力的主机厂都不会放弃自主研发，因为一旦掉队，短时间追不上来，也将彻底沦为硬件的代工厂，这是一个需要长期高投入的领域，在这个领域当中，主机厂、算法商、Tier1等各自的分工，也都还在探索当中。传感器与芯片算力，是发展中的主要制约因素。智能座舱，各个主机厂都在做，其技术和生态是消费电子在车场景的延展，一般会选择一家互联网公司合作，其核心还是围绕了人机交互展开，探索人与设备之间的关系，目前最主要的两大交互方式就是触屏+语音，对整车硬件的智能化的水平有很高的要求，但是车载硬件算力的滞后特性，导致功能体验不如消费电子。通信单元，也叫TBOX，是车与外界联系的枢纽，目前主要实现的功能，如远程车控、远程诊断、整车OTA、国地标数据采集等等，与车的联系非常紧密，主机厂一般都会自己开发上面的应用软件。其发展和通信标准的强相关，比如4G到5G的切换，未来技术上影响较大的因素是V2X，其发展会改变目前的软硬件架构。
二、软件+硬件皆可升级的基础软件OTA的能力，各家主机厂目前都已经具备了，相比于传统的汽车，软件OTA在一定周期上给汽车注入了新的活力，但依然会碰到算力的天花板。汽车的机械零部件，出厂之后，其功能整个生命周期都不会发生变化，但是中央计算单元，其发展始终跟随最新的ICT技术，在车的生命周期当中，算法、芯片、通信标准等会不断的更迭换代，车的生命周期都在5年以上，但相关的ICT技术，基本2年就会有一个大变样。用户不可能像换手机去一样去换汽车，既然不能换车，为什么不能让用户可以升级中央计算单元呢？升级中央计算单元硬件，特斯拉已经在这么做了！为什么传统主机厂以前在这方面不作为呢？
以上几个原因，导致了软硬件无法形成平台化，原本羸弱的资源，全部耗散在了无限的车型适配工作当中，根本没有资源提前去研发下一代平台，如此产生恶性循环。写这段的时候，我还是有点激动，曾经加班加点，就是为了把同样的工作适配到十多款车型，毕竟也是为此耗散过青春！Tier1的朋友们倒是很开心，反正只要给钱，主机厂愿意改，他们就愿意接！
不仅要在用户看得到的功能上下功夫，还要在软件的工程能力上下功夫，重视架构设计，否则一旦历史的包袱积累到一定程度，连重构的勇气都会丧失！作为中国高科技公司的代表，连任正非都喊出了华为要加大投入，提高软件能力的口号！
如何能够做到中央计算单元的软硬皆可升级，才是真正考验软硬件架构能力的课题，特斯拉已经开了个好头，就看接下来追上去的是谁。
动力与底盘控制器、车身控制器，其核心软硬件设计目标，是要为中央计算单元提供良好的服务接口，让中央计算单元既能够灵活调用，同时也保持松耦合关系，终极目标是实现软硬件皆可升级。
三、面向服务的架构设计在传统的离散架构下，车内的ECU通过总线相互通信，但是它们之间的信号收发关系和路由信息都是静态的，是在编译阶段写死的。各个ECU会周期性的发出各种信号，如果需要在另外一个子网当中使用，还需要网关进行转发，出于负载的考虑，网关通常不会把所有信号都转发，如果预先定义功能中，不包含某个信号，而后续又要使用，除了修改业务所在单元之外，还需要对网关的配置进行修改。如果车辆上市后，想在某个控制器上新增功能，可以通过OTA更新该控制器的软件，但是这个功能需要的其他控制器的信号怎么解决呢？当然，也可以把所依赖的控制器都OTA一遍，但这个工作量与同时OTA的控制器的数量是指数关系，新架构上升级一个控制器，一个月就能解决的事情，在老的架构上可能需要一年。面向服务的架构（Service-Oriented Architecture，SOA），是一种架构设计思想，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。SOA在互联网IT中有很多应用案例，和微服务的架构有相似的地方，具体可以参考SOA和微服务架构的区别。简单来说，SOA就是要求各个控制器，把自己的能力，以服务的方式提供出来，以此来构建一个与车型、芯片、操作系统无关的灵活可变的平台系统。
下面举个例子来说明，在中央计算电子电气架构下，以以太网为通信方式，把各个控制器提供的功能按服务的维度进行拆解（以下只是示意，主要为了讲清楚原理，服务的分类、拆解、分层，是一个架构设计的细活儿，是一个系统性的工作）。 面向服务的架构设计举例.png
上面这张图，软件上的分层看起好像和传统软件的架构也没太大区别，其实这里面最关键还是服务间的连接关系，其核心是需要SOA框架软件的实现一套服务管理的框架，类似与IT领域所说的 UDDI（Universal DescriptionDiscovery and Integration，统一描述、发现和集成），提供服务发布、查找和定位的方法。在这个框架下，服务节点可以动态加入，并且按照统一标准实现的所有服务都是对等的，服务之间可以动态的建立订阅/发布的关系，且相互之间以一种中立的服务描述语言为契约，是一种松耦合的关系。
服务可以分为三类，原子服务、组合服务、流程服务，原子服务提供的是最基本的功能，比如获取传感器的数据、升降车窗指令；组合服务是利用多个原子服务，实现了部分判断逻辑，比如升降车窗并不是任何条件下都能执行，还需其他条件去综合判断；流程服务，是根据业务功能定义的服务，比如产品上定义一个抽烟模式，需要同时打开车窗、天窗，并播放车主收藏的音乐，这就需要调用多个组合服务去实现。
原子服务，一般和硬件功能有关，硬件功能决定了原子服务的范围；组合服务，可以认为和某种策略和控制逻辑相关，比如实现一种新的驾驶模式；流程服务，可以认为是和特定场景下的产品功能。在SOA的软件框架下，“软件定义汽车”就变成了，在一个完备的原子服务集合当中，通过定义新的组合服务与流程服务，去实现新的产品功能。而在硬件可升级的前提下，又可以通过硬件升级，去拓展原子服务的功能范围。比如，换了带V2X的中央计算单元，就可以新增V2X相关的原子服务，然后定义一个新的流程服务，如，基于V2X的紧急刹车。
当然新的架构，也一定会带来新的挑战:
结语本篇主要对智能汽车软件的范围、软硬件升级、SOA的内涵进行了介绍，下一篇将重点介绍，SOA实现的基础；对常见的技术概念，车载以太网、SOME/IP、DDS、Adaptive AutoSAR、ROS2 等，梳理各自所处的技术层次与要解决的问题，阐述其与SOA的关系。链接： https://www.jianshu.com/p/799741994ce6（简书）
免责声明：本网站的部分内容，来源于其他网站的转载，转载目的在于传递和分享更多信息，并不代表本平台赞同其观点和对其真实性负责，版权归原作者所有，如有侵权请联系我们删除。 |
