01 背景
在2024年SAE COMVEC（Commercial Vehicle Engineering Congress）大陆集团商用车与特种车辆负责人Georg Fässler提出了几个观点：
- “Data processing and seamless connectivity will play a central role in future commercial vehicles, necessitating software to handle the influx of data to and from the cloud. (Continental)”
数据处理和无缝连接技术将在未来商用车的发展中占据核心地位，需要软件来管理车辆与云端之间频繁的数据交换；
- “The digitalization of commercial vehicles and the whole logistics chain is a necessary response and one of the most important developments in the CV industry in my view,”
为了应对商用车行业当前面临的挑战，包括司机短缺、燃料成本上升、运输需求增加、降低排放等，实现商用车和全物流链的数字化是应对这些问题的必要手段；
- “Just as passenger cars, commercial vehicles will increasingly rely on software-enabled functions, with software being decoupled from hardware for rapid development and over-the-air (OTA) updates – particularly with the emergence of modern driver-assistance systems and the eventual transition to automated and fully autonomous driving,”
和乘用车一样，商用车也将依赖越来越多的软件实现各种功能，软件将与硬件逐渐解耦，以加快研发速度并实现OTA更新，尤其是在现代驾驶辅助系统出现后，向自动驾驶和完全自动驾驶转型的过程中。
SDV软件定义汽车的概念已经深入人心， 逐渐获得全行业的认同，但是在讨论软件定义汽车时更多是从乘用车的角度思考，如何满足新生代消费群体个性化的用车需求，如何实现千人前面，如何构造智能、舒适、便捷的第三生活空间，如何缩短开发周期，快速的将车型推向市场，我在这里主要想和大家一起探讨下如何通过软件定义商用车，如何实现SDT（Software-defined Trucks）,商用车作为生产工具，其需要满足的客户需求是不同的，从商用车的全生命周期管理角度来看，SDT的主要目的还是要实现TCO（Total Cost Ownership）的降低，包括降低能源成本、管理成本、道路通行费、购车成本、维护成本以及金融保险等。
02 如何实现软件定义卡车SDT
2.1 集中式的架构
集中式的电子电气架构是实现软件定义卡车的基础，商用车相对于乘用车有一个最明显的特点就是车型变种多，单车销量少，零部件供应商通常会通过标准化的产品适配不同OEM的车型，甚至通信协议都不用更改，这也就是SAE J1939标准在商用车行业使用的初衷，另外，在车辆开发过程中，经历过协调多个供应商进行一个功能变更的历程，就会有深切的感悟，太难了，供应商开口就是增加费用，开发周期要延长，特别是对于新势力OEM来说，新产品在未来市场的销量存在不确定性，相对于传统头部OEM没有成熟的供应链体系，在与供应商合作过程话语权低，作为新势力OEM如何在面临上述挑战时逐步构建自身的优势，开发集中式的电子电气架构是必要的途径。
在集中式架构中，传感器/执行器/嵌入式ECU可沿用现有供应商的成熟产品，在满足功能、性能目标的前提下降低开发成本，但是在域控制器及以上产品中，卡车OEM需要逐步构建自主开发能力，从而能够将核心软件部署在上面，构建自己的差异化竞争力。上述所说的核心软件，及能够带来TCO优化的软件，例如我在《燃料电池重卡整车能量管理》中提到的等效氢耗最小的能量管理策略（ECMS）、基于智能驾驶超视距能力的预测性自适应巡航控制策略（PACC）、基于效率的电机转矩分配优化、低压系统能量管理策略等。
2.2 自主可控的软件开发能力
实现软件定义卡车（SDT）需要在集中式的电子电气架构基础上，采用面向服务的软件开发方式，逐步构建自主可控的软件开发能力。而构建整车全域的软件开发能力是一个漫长且不太可能实现的事情，需要有坚定的战略定力及雄厚的资金储备，所以作为卡车OEM应该从动力域、车身域入手逐步扩展到底盘域、智驾域。
自主可控的软件开发能力需要以软硬解耦为前提，应用软件的开发应降低对硬件和底层软件的依赖，如果应用软件开发过程中处处受限于黑盒的底层将会束手束脚，因此需要有AUTOSAR的基础软件，AUTOSAR的核心思想在于“统一标准、分散实现、集中配置”，“统一标准”是为了给各厂商提供一个开放的、通用的平台，“分散实现”要求软件系统高度的层次化和模块化，同时还要降低应用软件与硬件平台之间的耦合，不同的模块可以有不同的组织及人员去完成，“集中配置”及所有模块的配置信息以统一的格式集中整合并管理起来，从而配置成一个完整的系统。
2.3 开放标准的车辆接口（Vehicle API）
商用车应用的主要下游行业场景由于行业特性和运输要求，对于车辆的需求差异较大，例如：
- 快递快运行业由于对时效要求高，夜间行驶较多、成本控制严格，因而在防疲劳等驾驶安全以及能耗管理等需求较高；
- 整车运输由于长距离、高价值特性，在货物、安全和成本管理等方面的需求较高；
- 危化行业收政策监管影响大，对运输安全要求极为严格，因此对车队定位管理及安全管理要求极高；
- 电商行业干线物流运输以低时效要求的仓间入库货品挑拨为主，对自有车辆的成本管理、驾驶安全管理等需求较高；
- 冷链运输由于需要向货主提供全程温度监控报告，对车辆定位和货物温度监控等功能需求较高；
为了满足上述不同场景对数字化的需求，目前行业内普遍采用后装车联网终端的方式，例如G7易流，通过在不同品牌车辆上加装IoT智能终端设备，获取车辆的部分数据同时结合云端算法，向货运经营者提供覆盖车辆位置与轨迹、司机驾驶安全管理、货物温度管理、货物流向管理等丰富场景、软硬一体的车队数字化管理服务。但是这种方式首先需要在车辆上另外加装冗余的车联网终端，因为在目前的卡车上不管是国六的燃油车还是新能源卡车（满足GB/T32960）都装有车载终端，增加车辆的改制及硬件成本，同时加装的设备能够获取的车辆数据也是有限的，因此需要构建一个标准化的开放的车辆接口，而COVESA VSS(Vehicle Signal Spefication）就是一个这样的规范，其提供了一种将车端的数据安全、有效、无歧义的开放给第三方运营服务商，从而促进开放协作。
例如国外主流OEM Ford，Volvo以与Verizon Connect、Spireon等TSP玩家合作，实现互利共赢，用户可一键激活定制化平台，无需二次安装硬件，OEM可从开放数据而获取的收益中分成。
如何实现Vehicle API，我理解可通过S2S(Signal To Service)的方式将车端的信号抽象为原子服务，一方面OEM自主的App可通过组合原子服务实现车辆功能，如根据车辆的不同运营场景、不同的运营区域优化动力系统的参数，根据高精精度服务、速度控制服务实现基于经济性的全局速度规划等，另一方面，可借鉴COVESA VSS等行业标准将车辆服务进行再一次的抽象，提供标准化的接口，从而使第三方APP以面向服务的方式开发。
03 结语
在软件定义汽车的时代，不管乘用车还是商用车相同的是车辆的功能将越来越多的由软件实现，车辆技术的创新将更多的由软件实现，但是同时又存在不同，软件在乘用车上的创新更多的是满足用户安全、舒适、便捷、个性化等需求，而软件在商用车上的创新主要是降低车辆的TCO。 同时相对于乘用车，商用车更需要开放标准的车辆接口，促进上下游的协作，相对于乘用车的开发者平台，促进商用车行业统一的开放平台更具有其现实意义。
作者：窦明佳
来源：汽车电子与软件
推荐阅读：
更多汽车电子干货请关注汽车电子与软件专栏。欢迎添加极术小姐姐微信（id:aijishu20)加入技术交流群，请备注研究方向。
