智能汽车车用基础软件平台 架构下的关键技术设计

未来随着电子电气性能和可靠性等因素的发展，E/E 架构会逐步演进成中央集中式的结构，实时性要求高的计算将在本地中央计算平台处理，实时性要求较低或需要与外部协同的计算将通过车云一体平台交到云端进行处理。

SOA（是 Service-Oriented Architecture 的简称）作为一个先进的开放式架构，满足车企架构转型的需求，满足车企内外部生态建设的需要，也满足汽车行业生态建设的需求。为此，AUTOSEMO   推出了车端开放的分布式服务框架 ASF，以构建本土化基础软件生态，促进产业链协作和可持续发展。

(1) 针对新 E/E 架构的软件平台标准化架构

当新型 E/E 架构的硬件架构逐步明确后，软件将会逐步标准化，从软件层次划分情况来看，各家整车厂已经逐步转向跨域协同、车云互联、以及软硬件分离等方向。

虽然，国外的组织在标准基础软件开发平台对上层提供统一封装的硬件能力和标准服务组件，但是 没有对跨核跨域功能的汇总，使用者仍需要完成业务整合汇总的工作，对开发者的开发效率会产生一定 影响。ASF     使用标准化基础软件开发平台和操作系统提供的接口，提供更多整车业务层面需要的功能， 并封装成基础系统服务与整车系统服务，例如整车级日志服务、整车级诊断服务等，将各个节点的服务汇总成整车级，为开发者提供基于整车统一视图的服务功能及接口。

(2) 软件定义汽车生态构建

行业生态环境需要各个参与者在统一的标准及规范下进行分工，整车厂、应用供应商、基础软件供应商、操作系统供应商、芯片及硬件供应商各司其职、分工明确，保质保量输出成果.

·  整车厂：设计整车电子电气架构，提出业务功能需求，分解需求给相应供应商处理，并指导供应商做好支撑工作。

·  应用供应商：分解整车厂需求，并对下游基础软件提出相应的需求，对整车厂业务提出建议等。

·  基础软件供应商：根据整车厂和应用需求提供相应的服务功能，将通用功能封装为标准化接口， 提供整套工具链和开发环境，对整车设计、配置以及各节点提供技术支持和建议。

·  操作系统供应商：操作系统符合 POSIX 标准，操作系统的性能需要满足业务需要；对硬件芯片及周边外设的驱动进行适配，对业务所需基础协议栈及功能进行支持。

·  芯片及硬件供应商：根据各层业务需求设计硬件电路，协助整车厂进行芯片选型，对上层所需的驱动模块提供支持。

ASF 可以帮助 OEM 更好的聚焦于策划与开发附加值更高的应用软件，软件服务企业的分工逐渐细化， 促进汽车软件生态的发展。其主要价值体现如下：

·  整车级软件层面：ASF   基于整车软件平台抽离通用化且平台功能可复用性强的基础功能，并集中在一个软件集群中为各功能服务所调用，用于服务在整车平台的能力扩展，并实现整车各系统之间的协同，保证整车软件平台的整体性并进行统一管控。

·  平台级软件层面：ASF  基于国外组织服务框架扩展，向应用层提供更多基于服务开发需要的功能， 接口更加丰富和灵活，，新增了一个运行在 AUTOSAR  CP 和 AP 之上的软件层，对上提供统一视图的操作接口。应用可以调用 ASF 的接口，也可以调用 AUTOSAR 标准的接口，并且可以基于原子服务及系统服务提供的功能进行组合，实现服务的级联，针对不同异构系统分别提供软件包。

总之，随着 ASF 的不断迭代成熟以及 ASF 架构所涉及行业标准的落地和实践，ASF 将促进本土化基础软件生态的可持续与健康发展，助力 “卡脖子” 技术的多点突破。

2.   架构设计

ASF   是位于基础软件平台（即基础操作系统和运行环境）和功能服务层之间的服务软件单元的集群， 主要用于支持功能服务的通用化基础功能的开发和使用。可实现车内各功能服务之间、车云之间共享通信、诊断、计算等资源。

ASF 软件架构在 SOA 平台的层级如图 3.1-5 所示：

图3.1-5 ASF服务架构

ASF    使用标准化基础软件平台和操作系统提供的接口，提供更多整车业务层面需要的功能，并封装成基础系统服务与整车系统服务，例如整车级日志服务、整车级诊断服务等，将各个节点的服务汇总成整车级，为开发者提供整车统一视图的服务功能及服务接口。

ASF    弥补了标准基础软件没有对接口进行业务级汇总和统一的问题，对开发者提供更多面向服务开发所需要的功能服务，使开发者专注于业务设计和开发，为业务创新和软件快速迭代提供支撑。

3.  架构下的关键技术设计

ASF   是一组为功能服务开发、使用和集成而设计的通用化中间件服务集群，服务集群可以被所有的功能服务调用，用于对功能服务在整车平台的能力进行扩展，并实现整车各系统之间的协同，保证整车软件平台的整体性并进行统一管控。

ASF  主要可分为原子服务、SOA  增强型服务、系统级基础服务、整车级基础服务。软件架构设计师需基于各服务类型进行服务定义、设计，使 ASF 分层和功能定义更加清晰。在服务设计过程中遵循以下原则：

·  SOA   增强型服务具有通用性：即可为所有的应用服务提供通用功能，应用服务基于服务自身需求可使用该类服务，如数据存储、服务信号转换、服务调试等诸如此类的通用化功能。

·  系统级基础服务具有一定范围的（如某操作系统或控制器之上）通用性，且具有抽象性：即对基础软件开发平台（如 AUTOSAR Adaptive/Classic、Android 等）提供的通用化功能进行抽象，并提供给应用服务使用，如健康管理服务、网络管理服务、时钟服务、电源管理服务等。

·  整车级系统服务具有全局性：即该类服务的设计更多关注的是整车层面对车内所有系统的通用化功能进行协同和管控，该层服务是对系统基础服务在整车层面的抽象和管控，即通过该层服务可以配置和控制系统基础服务，如整车健康管理服务、整车网络管理服务、整车时钟服务、整车电源管理服务等。

·  动态服务具有动态配置性：即应用服务在运行过程中可对服务进行配置，并基于配置输入执行动态服务的功能。

·  原子服务具有独立性：即其设计应与硬件配置和实现无关，与上层功能服务层和下层的硬件驱动层解耦，完全独立。

·  原子服务具有原子性：即设计的服务不可再拆分，作为服务的最小单位和执行实体，为功能服务提供最基础的执行或采集等功能。

(1) SOA 增强型服务

SOA   增强服务是在国际共同讨论的基础平台进行服务框架扩展，封装通用化的基础功能。应用服务调用此类服务的接口更加方便完善其功能软件逻辑、便于系统集成和敏捷测试。

该类服务为一组服务集群，以 Lib 库的形式集成在应用服务中，并提供满足国际共同讨论的自适应性标准的服务接口，使接口标准完整统一。主要包含模块：服务调试、服务转换、服务权限、服务同步、SOA For Android、日志管理、动态数据收集、诊断管理。

(2) 系统级基础服务

系统级基础服务描述车端各类域控及网关节点，基于通用基础软件提供的底层支持，进行相应的封 装和扩展，实现各类通用化服务功能和框架及在此基础上形成的面向上层应用的各类服务接口（SDK  接口、API 接口、IPC 接口、RPC 接口等）。

系统基础服务包括通用支撑类服务和公共框架类服务。通用支撑类服务包括服务治理（服务发布及发现）及服务容器、服务访问及限流降级、数据订阅及发布、集群管理、消息总线等。公共框架类服务包括升级管理服务、健康管理服务、网络配置服务、资源管理服务、时钟同步服务、安全管理服务、测试服务、电源管理服务、日志服务、诊断服务、数据收集等。

此外，系统基础服务还包括针对具体域控节点功能的框架服务，如针对自动驾驶域控制器，提供自动驾驶融合感知模型和框架服务、规划控制模型和框架服务、决策执行模型及框架服务、定位服务等。针对智能座舱域控制器，提供手势识别服务、语音识别服务、仪表显示服务以及其他应用框架服务。

系统基础服务支持灵活组合、配置及部署，在不同的域控节点上部署不同的服务模块，如升级服务、健康管理服务、网络管理服务、系统资源查询服务、时钟服务、安全服务、调试服务、软件包管理服务、电源管理服务、通信服务、日志服务、通用支撑类服务、数据收集服务。

(3) 整车级系统基础服务

整车级系统基础服务是将各控制器节点的能力，通过跨域、跨核组合成整车级别的业务功能，以对应用层提供整车级统一的调用。整车级系统基础服务包含整车电源管理服务、整车健康管理服务、整车时钟服务、整车诊断 Master、整车版本管理服务、整车数据采集服务、整车日志管理服务。

(4) 动态服务

动态服务工作流通常由车云一体的云端平台（ 比如：开发者平台）提供工具链支持，对接技术生态及运营，从而在运行态具备灵活更新的能力。动态服务开发流程以逻辑组合建模为主，因此工具链需要支持可视化 UML 建模，输出模型脚本，并与车端建立同步机制。

动态服务开发面对的角色，不再局限于传统的 OEM/ 供应商角色，而是拓展面向第三方开发者，甚至是车主。

(5) 原子服务

原子服务是执行单一操作功能的服务，具有硬件功能上的不可拆分性。例如获取一个数值或者执行 一个I/O 操作。通过将域控制器的硬件功能，拆分为最小功能的原子服务，并统一定义原子服务的访问接口， 从而实现软硬件的完全隔离。软硬件隔离后，车载硬件不再绑定特定的功能，应用软件得以自由使用车 载硬件，实现更加灵活多样化的功能。例如方向盘在正常行驶过程中，用于控制车辆的转向，当车辆处 于非驾驶模式时，又可以成为中控大屏游戏应用的控制手柄。

① 原子服务定义方法

原子服务分为功能原子服务和硬件原子服务，这里先以硬件原子服务为例说明原子服务的定义原则。

② 原子服务的属性

原子服务需要为上层提供完备的设备访问能力，而又隐藏硬件实现的细节，从而实现硬件逻辑和应用程序逻辑的分离。原子服务，应当具有以下的属性：

·  硬件控制

·  更改硬件工作参数

·  获取 / 通知硬件故障状态

·  故障自恢复

·  采集 / 发送硬件数据

通过调用原子服务，应用层可以实现硬件的控制功能、更改硬件的工作参数、获取硬件故障状态、收发硬件数据等功能，而无需关心硬件的初始化、反初始化、故障重启恢复等细节的具体实现。例如，提供原子服务的 ECU，应当具备在硬件发生故障时，自我恢复硬件故障或者进入预定义的保护状态的能力， 并且通过服务接口通知服务使用者，服务使用者仅负责收到故障状态的通知，而不需要参与如何解决硬 件故障的过程。

③ 原子服务的颗粒度

原子服务的颗粒度大小，直接影响到原子服务的灵活性和服务使用的便捷性。如果原子服务的颗粒 度过于细小，则原子服务的使用会变得更加灵活，但同时应用层也不得不执行更多细小功能的组合，服 务使用的便捷性上便会受到限制。反之，如果原子服务的颗粒度过于巨大，虽然应用层使用会更加便捷， 但是应用层可以组合的服务场景将会相应的减少，限制了应用功能的多样性。原子服务的不可拆分性， 不是物理意义上的不可拆分，而应该是功能意义上的不可拆分。

3.2  基础软件验证平台

3.2.1  验证平台概要

汽车电子的高速发展决定了基础软件所面临的要求将会更加严格，其要求会覆盖软件的安全性、稳定性、可扩展性等方方面面。为了提高软件质量，降低软件应用风险，构建高安全、高可靠性、高效率实施的基础软件验证平台则是必不可少的一环。

当前，汽车电子厂商大多采用 V 模式进行新产品开发，相应的，基础软件验证也可以参照 V 模型流程， 持续进行不同层面的验证，如图 3.2-1 所示。

图3.2-1 V模式研发流程

充分的测试验证需实现需求阶段至系统阶段的全覆盖。

例如：

在需求分析阶段，要考虑系统验证的计划，包括确保每一个需求点都是可验证的，并设计相应的初步系统验证用例；

在概要设计阶段，要考虑部件验证计划，设计相应用例，验证高级模块的功能以及模块之间的接口关系；

在详细设计阶段，要考虑单元验证计划，编制单元验证用例。

进行基础软件验证时需按照顺序开展代码静态验证、单元验证、部件验证（包括软软集成、软硬集 成）、系统验证等测试执行工作。其验证类型可分为白盒测试、黑盒测试两类。白盒测试包含代码静态验证、单元验证，重点侧重于代码逻辑、接口实现等内容。黑盒测试包含部件验证、系统验证，重点侧重于硬件功能实现、人机交互实现及通信功能实现等内容。例如，后文提及的时间特性分析验证平台属于单元验证的内容，通信相关技术验证平台属于部件验证内容。

图3.2-2 基础软件验证过程

总体而言，每部分的软件验证包括五个基本过程：测试需求分析、测试策划、设计与实现、测试执行、测试总结 , 其流程如图 3.2-2 所示。

同时，为了提高效率，节约人力和成本，可用适宜的自动化测试工具以及相应的管理措施与管理工具， 以保障需求得到充分的验证。

此外，基础软件验证平台还应该通过静态分析、仿真、在环测试等手段验证设计和实现的有效性。其中，仿真验证平台因为有利于前期验证及特殊测试用例注入，可以节省测试环境成本及缩短开发周期。而且由于基于分布式开发需求，验证平台目前正往云端迁移。

3.2.2  验证平台典型案例

1.  通信相关验证技术

随着汽车智能网联化、新型电子电气架构的发展，作为车辆神经系统的汽车通信技术也面临着越来越多的新需求。基础软件所具备软硬件分离、软件接口的互换及重复使用特性等特点可以更好地实现车载网络现阶段发展中所遇到的总线类型多元化、协议应用多元化等需求。为保证基础软件在车载通信上的应用， 其验证相关技术是必不可少的环节。结合基础软件 COM、CANNm、CANTp 等基础模块单元，通信相关验证平台需包括通信验证、网络管理验证、诊断服务验证、时间同步验证等方面。

(1) 网络通信测试验证

网络通信是实现汽车各控制器进行信息交互的桥梁，无论是传统的分布式电子电气架构，还是域控 制器架构，或是基于中央大脑的电子电气架构，其在汽车主干网中常用的总线通信类型大致包含CAN  总线、LIN 总线、以太网三类。此外，智能网联化的发展也对车辆的网络通信提出了大带宽、高时效，功能及信息安全防护等要求。上述三类网络通信方式的组合及其在基础软件验证平台的应用，基本能够满足汽车 在不同架构类型及不同功能场景下的通信需求。与之相对应的基础测试验证则成为了检验基础软件是否 满足通信需求的重要一环。

① 需求分析

基础软件虽然具备软硬件的解耦、接口的可复用性、平台的可移植性等优势，但是其可灵活配置的特性也决定了其面向整车系统时配置参数具有差异化或在基础软件代码开发移植阶段存在不满足整车通信需求的情况。例如某一车型平台或某一架构下各个控制器的基础软件在开发阶段的通信参数设置、信号交互、总线通信故障处理逻辑等与期望不一致的情况。这些差异化的内容往往会导致汽车总线无法通信、功能无法正常执行等问题，因此网络通信测试的验证务必在单个控制器开发完成后进行，以保证装车后的通信质量。

② 验证方法

CAN/LIN 网络通信的验证主要针对通信配置参数、总线容错处理及恢复逻辑、报文交互等内容进行验证，因此测试设计方法主要为需求分析方法、边界值分析、等价类法。为实现网络通信验证，需视不同的需求搭建测试环境。网络通信验证的测试环境可分为基于示波器的测试、基于总线分析仪的测试、基于总线干扰仪的测试三类。