中国汽车基础软件发展问题与挑战

本文节选自AUTOSEMO发布的《中国汽车基础软件发展白皮书1.0》。

“软件是人类历史上最奇特的产物之一，它和其他事物截然不同，以至于拿任何事物来比喻软件，都给人以不够贴切的感觉，软件的自动化运行能力和几乎零成本复制能力给人们带来了前所未有的便利。”

-《大教堂与集市》

1 、技术问题

随着汽车智能化、网联化的不断发展，整车电子电气架构发生了翻天覆地的变化，从过去的分布式架构逐渐过渡到基于域控制器的架构，未来还会向基于中央电脑的架构方向发展。这一变化使得ECU 功能区域集中化，而功能集中化使得车内控制系统趋于形成统一的软件架构标准及通用的硬件平台，各类控制功能逐渐演变为统一平台下的各类应用。

对于汽车基础软件来讲，如何满足整车电子电气架构变化的需求，是值得业界深入探讨的关键问题。一方面，基础软件平台需要统一标准并兼容不同整车厂的应用场景，另一方面，基础软件平台安全性需要重点加以考虑，并给出系统性解决方案。

无论是域控制器架构还是基于中央电脑的架构，整车功能设计都离不开高性能计算单元。高性能计算单元的引入增加了基础软件平台的复杂度，整车功能设计如何把握和驾驭这种复杂度成为首要问题。同时，基于SOA 的整车设计和功能服务化理念也对基础软件平台产生了重要影响，如何满足新的设计和功能，实现未来需求也是亟待解决的问题。

智能网联化对汽车通信技术提出了大带宽和高实时性的要求。通信协议栈是汽车基础软件平台的重要组成部分，基于CAN 总线的信号传输已经无法满足全部需求，而新型总线的各类传输协议标准（如：TSN）还在不断完善，上层应用协议的应用生态还没有构建完成，各整车企业在SOME/IP、DDS、PCIE 的协议应用仍处于论证阶段，这些不确定性都给基础软件平台的发展带来挑战。

面对诸多的技术问题和挑战，各大整车厂和软件服务商对汽车基础软件的发展路径有着不同的声音，也是业内讨论的持续热点。针对目前我国汽车基础软件遇到的发展路径选择和技术实现方案问题，我们给出如下建议：

对于底盘和动力系统，由于功能设计高度实时性，基础软件平台需要搭载实时精简内核的操作系统，同时设计需要充分考虑功能安全。

对于智能驾驶和互联功能的应用，硬件采用高性能计算单元是未来趋势，而基于高性能计算单元的软件开发需要搭载复杂操作系统，例如：Linux、QNX、VxWorks 等。由于上层应用开发需要基础软件平台提供统一接口，多种操作系统的共生需要开发Hypervisor。为了满足这类需求，基础软件平台中的车载操作系统、Hypervisor 和中间件需要进行无缝集成，并且兼容不同应用开发，建议进行统一规划，推荐基于现有商业化软件进行个性化定制，减少重新设计带来的成本浪费，避免软件生态的不畅。

对于娱乐和座舱系统，由于功能开发偏用户体验，而且行业应用百花齐放，很难统一化，建议基础软件平台多参考互联网的技术应用，同时基于不同场景的应用，建立汽车特有的标准体系和基础软件平台。
技术实现方案是汽车基础软件研发的关键因素，决定了相关技术和产品能否成功量产并被市场所接受，针对汽车基础软件技术实现涉及的主要内容，概要综述如下：
1.1 虚拟技术

Hypervisor 是一种运行在基础物理服务器和操作系统之间的中间软件层，可允许多个操作系统和应用共享硬件。Hypervisor 的主要用途是通过限制或允许访问CPU、内存和外设等片上资源来定义每个虚拟机可用的功能。Hypervisor 可以为每个虚拟机分配不同的资源。例如，CPU 上的处理时间可以划分为多个时片，并根据需要分配给不同的虚拟机，一个虚拟机可以访问多个CPU 内核。类似地，存储器和外设可以共享或分配给单个虚拟机。虚拟机无需知道或根本不知道彼此的存在，并且无法访问未提供给它们的资源。因此，Hypervisor 也称为虚拟机监控程序(VMM)。

Hypervisor 可以划分为两大类。一类是直接运行在物理硬件之上的。例如一个MCU 中的A核和M 核，A 核运行在Linux 系统和AP 的方案，M 核运行在AUTOSAR OS 和CP 的方案，通过Hypervisor 实现A 核和M 核的划分。另一类是运行在另一个操作系统中。例如在Linux 系统中移植AUTOSAR OS，实现CP 和AP 的融合，同时满足控制器对实时性、安全性、计算能力、处理能力的要求。

1.2 POSIX 操作系统

“软件定义汽车” 主要的技术驱动力就是IT行业技术的引入，以及自动驾驶等汽车行业自身的技术创新。这两类技术都依赖于POSIX OS，目前生态最好的POSIX OS 为Linux，但目前该OS 在实时性及功能安全上很难满足传统体系下汽车行业的要求。而满足实时性与功能安全的POSIX OS由于软件生态较弱，且较封闭，对硬件的支持不好，性能也不如Linux。因此在实时性，功能安全及生态，性能上做好兼顾是POSIX OS 需要解决的关键问题。

1.3 功能安全

当前的功能安全评价体系（ISO26262）比较适合逻辑相对简单且确定，变化频度低的软件架构及模块。而下一代智能网联车的软件平台及应用显然不符合这一特性（例如POSIX OS 中各类复杂的逻辑，机器学习带来的算法不确定性，软件升级带来的频繁变更），因此，在现有体系下整个产品通过功能安全会比较难，即使通过了，由于软件频繁的变革意义也不大。所以，需要探索出符合这种特点模式下的功能安全评价体系。

1.4 异构系统运算支持

随着汽车高级自动驾驶、信息娱乐以及V2X互联化的不断发展，传统的单类单核芯片已不能满足汽车控制器的要求。同一个控制器中具有多个同构或异构处理核必将成为趋势。这些同构或者异构处理核可以在一个芯片上实现，也可以在两个芯片上实现（两个芯片部署到一个ECU 上）。不同的核可以运行不同的操作系统，加载不同平台的基础软件。

例如ADAS 控制器可以有两个芯片，一个运行AUTOSAR OS 和CP 方案，用于实现控制类功能，以保证ADAS 对实时性以及功能安全的要求。而另一个运行Linux 和AP 方案，用于实现数据采集处理等功能，以保证ADAS 对计算能力和处理能力的要求。某芯片厂商用于网关开发的某系列芯片，含有多个A 核和M 核，A 核运行Linux 系统和AP 的方案，M 核运行AUTOSAR OS 和CP的方案。

不同核之间的通信，可以采用各种总线接口实现，例如SPI、UART、USB 和Ethernet 等，除总线接口外，共享内存技术也已被广泛用于核间通信。

1.5 高性能算力支持

智能网联化及自动驾驶技术的发展，带来了更多新需求，例如高整车计算能力、网络通讯带宽以及网络信息安全等。传统的CAN/CANFD/FLEXRAY 总线已经不能满足未来汽车对网络通信带宽的需求，以太网总线已经被广泛应用到汽车中。基于以太网总线的车载高速通信技术需要中间件的支持，而SOME/IP 和DDS 是典型的SOA架构下的中间件。

1.6 软件在线升级支持

随着汽车集成化、电子化进程的推进，汽车软件的复杂度急剧增加，软件故障的修复频率也随之上升。同时，产品功能个性化定制更新的需求也是智能汽车的一个亮点，而这些需求的实现都需要新的电子电气架构支持软件在线升级，比如对操作系统的升级。传统汽车电子产品是各个功能ECU 独自进行软件升级，这将无法满足整车级功能优化和完善，且需要较多的折中与配合。而新的汽车电子架构从分布式ECU 转化为基于云计算的单一计算芯片结构，对硬件及基础软件进行了集中管理，如果能实现类似智能手机系统升级一样，系统基础软件也能根据使用场景进行版本更新升级，使上层应用软件更加灵活和快速的调用底层基础信息，这样在整个汽车生命周期中，硬件平台可以持续支持软件的迭代升级。

1.7 信息安全

伴随网络技术、计算机、人工智能的发展，汽车的网络互联与智能化成为产业发展必然趋势，汽车成为具有信息交互功能的网联终端，为用户带来更舒适更便利的驾驶体验，同时也面临更大的信息安全方面的挑战。对于控制器可能会遇到的固件安全、入侵威胁、渗透攻击、漏洞扫描等潜在威胁。基础软件需要开发相关模块满足这类需求，例如：安全启动机制、入侵检测和防御系统（IDPS）等。与此同时，行业需要逐步建立智能网联汽车的信息安全体系架构，通过纵深动态防御体系保障汽车电子信息安全。

• 信息安全关键技术

基于汽车基础软件的信息安全应用，重点阐述汽车终端安全、车内网络安全隔离、车内网络安全检测、车内总线认证加密、远程升级安全和安全管理平台。

（1）车载终端安全

在车载终端软件系统中，从信息安全防御的角度，通过灵活的安全组件集成，采用多种安全机制对汽车车载终端的系统、数据、网络及应用进行安全防护，实现车载终端的整体安全。包括：固件安全、操作系统代码安全、安全启动、应用程序访问控制、安全监控，关键数据比如密钥的安全存储、访问控制和篡改防护，通信安全组件（密码模块和安全协议），安全审计等。

（2）网络安全隔离- 车载防火墙

车载防火墙是在汽车网关、域控制器或边界T-Box 系统中集成传统防火墙的功能特性，为车载网络提供安全域隔离和访问控制功能，极大地提高汽车信息系统的安全性，保证网络安全和数据通信安全。车载防火墙按照需求进行防护策略配置，通过黑白名单、端口访问控制、会话控制、攻击防御、流量监控等功能，实现车内不同安全域的隔离、车辆内外网络的安全隔离、边界安全防护。

（3）网络安全检测- 车载入侵检测防护

车载入侵检测防御技术，可以实时监测汽车内部网络或车外到车内的异常通信，发现入侵攻击，并提供必要的异常报文阻断和异常状态上报。可以在汽车网关系统或T-Box 系统上集成入侵检测防御功能，采用特征匹配、协议分析、异常检测等多种技术，实时监测、识别针对车辆的非法入侵和异常通信报文，拦截阻断明显的异常报文，同时支持异常行为上报、日志统计分析展示、安全规则更新等功能，从而实现汽车网络的安全防护。

（4）车内网络安全通信- 通信报文认证加密

传统车内网络通信中，总线通信报文以明文方式传输，攻击者借助简单的采集分析工具对总线通信报文进行抓包提取，通过对原始通信报文的重放或篡改，对车辆ECU 进行攻击，可以造成车辆通信总线故障、ECU 功能异常，甚至影响行车安全等问题。为解决车内通信的安全风险，需要在关键电控单元上实现报文校验安全通信功能，基于AUTOSAR 等软件架构，采取认证、加解密、新鲜度值管理等安全机制，实现车载总线安全通信，防止车内网络关键数据被监听、篡改和重放。

（5）远程升级安全

OTA 远程升级可以方便主机厂对车辆整个生命周期的软件管理。通过软件的快速迭代，快速修复车载软件系统缺陷，提升系统性能。为实现OTA 远程升级的安全防护，需要在车载终端、远程升级服务器上集成升级安全组件，在OTA 升级的过程中，采用身份鉴别、数字签名保证升级包的完整性和端到端的真实性；采用通信加密保证升级包的传输安全。

（6）安全管理平台

安全管理平台为企业提供一个有效的汽车信息安全管理机制。安全管理平台通过部署在车载终端的数据探针进行安全信息收集，基于大数据和威胁情报，实时监控汽车信息安全状况，快速发现和定位攻击。并针对每种攻击形成有效可行的安全策略，提供及时的分析和响应。而且，可以快速准确地将安全补丁及安全策略推送到全网车辆，有效控制网络攻击的传播和爆发。安全管理平台可以实现车载系统信息、车辆管理信息收集展示、数据探针日志分析、安全策略管理、安全报告生成等，实现贯穿汽车全生命周期的信息安全运维管理。其主要应用场景包括：

a) 安全事件应急响应：终端监控、威胁告警事件及时上报，由安全专家提供应急响应服务，阻止安全事件扩散和集中爆发。

b) 潜在威胁关联分析：定期生成日志分析报表，安全管理人员通过关联分析，预判潜在威胁。

c) 攻击检测及时更新：获取最新漏洞信息，及时更新安全威胁，提供第一时间的安全保障。

1.8 测试

随着汽车嵌入式系统复杂度越来越高，如何保证软件可靠性成为了行业共同关注的问题。而基础软件测试是嵌入式系统设计中的重要一环，测试过程直接影响到汽车的生产、售后及召回。从行业测试现状来讲，基础软件测试仍然以

功能测试为主，代码测试覆盖率不高，同时，国内缺乏一些车规级软件测试标准，特别是功能一致性标准。随着“软件定义汽车” 的不断深化，整车厂也逐渐开发软件，关于软件的测试，特别是基础软件测试会越来越标准化。另外，测试流程也需要不断完善，ASPICE 是一个很好的参考对象。汽车基础软件测试主要覆盖如下几个方面：

• 单元测试

（1）静态测试
内容：基于模块代码进行静态测试（符合MISRA 规范），模块单元圈复杂度计算测试
静态测试工具：QAC
测试标准：MISRA 编码规范符合度90% 以上

（2）动态测试
内容：基于函数接口和功能实现进行测试；
动态测试工具：Tessy
测试完成标准：1. 功能覆盖率；2. 结构覆盖率即语句覆盖率

• 集成测试:
测试依据：测试架构设计
测试内容：
（1）接口测试：测试模块内部接口，模块间的接口，软件硬件接口
（2）测试函数之间，模块之间的调用关系，时序和状态转换关系。
（3）故障注入测试：依据故障处理策略，测试软件的故障处理能力
（4）资源测试：测试内存使用量，栈使用量，CPU 使用量和TASK/ 进程执行时间
集测试工具：TESSY、调试器、总线测试设备、示波器等
测试标准：1. 功能覆盖率；2. 结构覆盖率（函数覆盖率，函数调用覆盖率）

• 系统测试:
测试依据：软件功能需求
测试设计方法：
（1）需求分析法
（2）等价类生成和分析
（3）边界值分析
（4）错误猜测
（5）功能依赖分析
（6）使用操作情况分析
测试标准：软件功能覆盖率

• 标准及协议测试

基础软件平台除以上传统嵌入式测试过程外，鉴于其特性和架构，衍生出标准测试及协议测试。

（1）标准测试

标准测试指AUTOSAR 组织为平台测试而专门发布的标准。从开发模型来说，标准测试属于系统级别测试，AUTOSAR 要求使用此部分系统测试用例对被测物进行RS 条目验证，以确定AUTOSAR 软件平台是否满足功能的需求。其每个测试用例都适用于已发布的规范。

Adaptive Platform 的测试主要参考《AUTOSAR_TR_Adaptive Platform System Tests》，其参考ISO-9646 测试体系结构，定义了Adaptive Platform系统测试体系结构（见下图），在最新的R19-11 版本中涵盖12 个模块的测试内容。


图 6 Adaptive Platform系统测试体系结构

Classic Platform 的测试主要参考《ACCEPTANCE TESTS FOR CLASSIC PLATFORM》，根据验收测试中的平台结构（见下图）构建测试方案，参照AUTOSAR_CLASSIC平台对验收测试的要求，定义了14 个模块的测试内容。


图 7 Classic Platform 验收测试中的平台结构

当前在如上测试平台/ 方案的基础上，需要持续的进行测试内容的拓展。也需要利用自动化测试技术提高测试效率，缩短时间，降低成本。

（2）协议测试

协议测试主要是车载以太网部分，OPEN（http://www.opensig.org/）组织已分享了汽车以太网ECU 测试的要求，并基于这些共享需求定义了适用于汽车以太网中所有ECU 的测试规范（TC8）。TC8 规范包括车载以太网ECU从物理层到应用层的各层交互操作性以及常规基础服务功能服务，目的在于提高ECU 使用以太网的通信质量和兼容性。

对于基础软件部分，从OSI（Open System Interconnection）七层模型分析，主要进行3-7层的测试。其中不同层次主要测试协议如下，此部分测试以RFC 为原始需求：
Layer 3: Network Layer, 例如 IP, ICMP 协议的测试；
Layer 4: Transport Layer, 例如 UDP, TCP,DHCP 协议的测试；
Layers 5-6-7: Application oriented layers,例如 SOME/IP, SD 协议的测试。

例如，TCP 协议测试，测试环境和对应需求

在TC8 中描述如下：



图3 TCP协议测试

R F C 7 9 3 - "Transmission Control Protocol" of DARPA, Internet Program, Protocol Specification
RFC 1122 - Requirement for Internet Hosts -- Communication Layers
RFC 2460 - Internet Protocol, Version 6 (IPv6) Specification

• 持续集成、自动化测试、测试驱动开发

基础软件平台实现了传统硬件及软件的松耦合，其为上层应用提供统一的接口，但下层需要适配多种操作系统/ 硬件，实现可移植性。此种架构减少了设计和开发的成本，但对于质量保证过程来说，提出了更高的要求，测试过程面临了快速迭代，多种系统适配的考验。

以Adaptive Platform 为例， 目前使用Jenkins 持续集成和部署平台软件，通过以太网作为传输介质，利用SOA 架构提供的服务来进行自动化测试。基础软件平台的实现，为汽车基础软件平台测试开启了新的历程，为快速迭代和多种适配的大量重复工作提供了解决思路。


图 4 基于SOA架构的自动化测试

2 、应用问题

应用门槛高是目前汽车基础软件解决方案普遍面临的关键问题。主要体现在以下方面：

• 成本高

现有的基础软件产业链几乎被国外垄断，国内使用成本高昂，国产汽车成本有着明显的压力。

• 能力要求高

汽车基础软件开发过程困难，对专业人才的能力水平要求高，具备高能力的专业人才数量不足，导致国内汽车基础软件的开发滞后。

• 项目管理成本高

汽车基础软件在开发过程中，需要投入大量的项目管理人员来对相关进度及质量进行管理，造成项目管理成本高，对于汽车基础软件开发造成一定压力。

• 产业链及研发体系不完整

国内汽车基础软件的上下游产业链缺失，在开发过程中，存在一定阻力。并且缺少一套符合汽车行业上下游的基础软件研发标准体系。

• 技术服务支持不足

国内汽车基础软件产品发展不够完善，服务支持存在一定问题。

• 专业人才储备不足

汽车基础软件在我国起步较晚，对于专业人才的储备不足，同时具有汽车专业背景，了解汽车架构的及软件架构的人才稀缺，导致汽车基础软件的开发滞后，形成恶性循环。

3、标准化问题

汽车基础软件发展至今，标准化问题始终是困扰业界的核心问题。基础软件标准虽然有众多响应者及参与者，但因标准涉及多方核心利益，短时间内难以达成统一。目前国际上有一定影响力的标准分别是OSEK 和AUTOSAR：

OSEK：是指德国的汽车电子类开放系统和对应接口标准（Offene Systeme and deren Schnittstellen fur die Elektronik im Kraftfahrzeug），OSEK 规范主要由四部分组成: 操作系统规范(OSEK OS)、通信规范(OSEK COM)、网络管理规范(OSEK NM) 和OSEK 实现语言(OSERK Implementation Language, OIL)。OSEK 规范为实现其制定的初衷并满足汽车控制领域对系统安全性和节省有限资源的特殊要求，制定了系统而全面的操作系统规范。

AUTOSAR ：AUTOSAR(Automotive Open System Architecture）， 即汽车开放系统架构。它是由汽车制造商、零部件供应商以及研究、服务机构共同参与的一种汽车电子系统的合作开发框架，并建立了一个开放的汽车控制器（ECU）标准软件架构。兼容并使用AUTOSAR 标准的国外公司主要有Vector、EB、ETAS、Mentor，国内公司主要有东软睿驰和经纬恒润、普华基础软件。

• 东软睿驰汽车基础软件平台产品 - NeuSAR



图 东软睿驰 汽车基础软件平台产品-NeuSAR

汽车基础软件平台产品NeuSAR 是基于AUTOSAR 由东软睿驰全新自主研发，支持QNX,Linux 等操作系统，产品包含：NeuSAR aCore，NeuSAR cCore, 工具链和Bootloader 等。广泛应用于新一代电子电气架构下的自动驾驶，智能驾舱，底盘动力，车身控制等域控制系统，为整车企业实现产品快速迭代开发，降低研发成本，提升用户体验。同时，借助于高效的本地化支持，可以与整车企业及合作伙伴共同解决新架构下的软件技术开发问题，实现通过软件创新，推动汽车产业发展。

• 经纬恒润INTERWORK



图 11 经纬恒润 基础软件产品介绍

经纬恒润是国内最早致力于为行业提供AUTOSAR 解决方案的软件服务提供商，目前已拥有成熟完善的基础软件系列产品，其中围绕AUTOSAR 体系可以提供INTEWORK-CP、INTEWORK-AP 以及配套的工具链，通过提供全项目周期的集成和培训服务，为客户和生态伙伴提供基础软件解决方案。

• 普华基础软件

普华灵智汽车电子基础软件平台及技术架构是国内较早面向新能源汽车和智能互联汽车的电控系统一体化解决方案， 为用户提供基于AUTOSAR 和OSEK 标准的操作系统、通信协议、诊断协议、网络管理、标定、底层驱动、Bootloader 等基础软件模块与集成开发环境，提供技术先进的控制器软硬件解决方案。普华的汽车电子产品和服务已经广泛应用于国内外整车和零部件企业的研发和量产。

4、对策与建议

综合考虑国内外经济贸易形势和技术发展现状，中国汽车基础软件发展应坚持以下原则。一是继承原则。继承和参考世界汽车产业已有成果，如AUTOSAR Classic 部分。二是创新原则。面向我国汽车产业新发展的新机遇，实现开放创新的应用需求，我国汽车基础软件需要全面提高核心技术水平，助力整车企业加快实现创新领域的技术发展。三是兼容原则。中国汽车基础软件要有国际化思维，面向未来，保持与主流国际汽车软件标准的兼容性要求，为后续国际市场开拓保留充分可能。这将有利于我国整车企业应用和国外的技术软件相兼容，也有利于我国汽车产业走向国际。

结合上述原则，针对我国汽车基础软件的具体举措，建议如下：

1、整合优势资源，推动汽车基础软件标准化体系建设
基础软件发展至今，已经有大量其他已有标准供参考和借鉴，同时在当前中美关系的大背景下，国家对于核心基础产业的发展决心也是空前坚定，中国目前也成为了世界上最大的汽车消费市场，在新能源、智能汽车领域的战略布局具有前瞻性。

OSEK 和AUTOSAR 不兼容， 甚至不同的AUTOSAR 供应商之间的AUTOSAR 工具和不同AUTOSAR 版本间也存在不兼容的问题。由于我国汽车基础软件行业标准规范没有建立，企业在跨平台、跨系统集成应用时就需要解决很多复杂的标准问题，这些对于汽车基础软件的大规模普及是非常不利的。

建议成立由国内主要相关企业和厂商共同参与的联盟，尽快统一行业标准，从国家层面上构建统一、规范的标准体系。只有标准得到统一，汽车基础软件的互联互通和信息融合才能够真正得以实现。

2、强化汽车基础软件人才培养，加大应用普及推广力度

汽车基础软件涉及计算机、通信、控制、机械等多个学科，是典型的学科交叉创新领域，亟需大量的领域交叉融合的专业技术人才。从未来发展考虑，建议相关领域知识内容纳入到相关专业的大学教学课程体系，加强国内对于汽车基础软件的重视程度，对基础人才进行重点培养，夯实国内汽车基础软件的发展基础。

汽车基础软件涉及汽车制造和信息技术的融合创新。目前，我国汽车制造领域和信息技术领域的融合不够深入，不同专业人员缺乏统一的思考维度，建议相关行业组织开展不同领域人员的统一培训，促进不同领域专业人员交流，夯实国内汽车基础软件发展的产业人才基础。

3、加大政府支持力度，加强创新平台建设，

促进汽车基础软件生态圈建立构建“产、学、研、用” 一体化运作，依托相关企业和重点高校，成立重点实验室和专业技术创新中心，整合多方资源，集中攻克相关“卡脖子”技术。鼓励高校和科研院所成果转化，鼓励企业牵头开展重大项目攻关。

构建生态圈，把汽车基础软件纳入国家重点研发计划及工业强基等重大项目指南，支持相关技术研究、发展和产业化运作。加强扶持力度，为拥有国产自主知识产权的相关基础软件产品提供政策补贴，降低企业应用风险，可通过后期SOP量产税收进行调节补收，进而降低企业在最开始应用的成本。