01.ASF框架基础定义

ASF 全称 AUTOSEMO Service Framework，属于车载SOA软件架构的平台核心服务，它基于整车软件平台抽离通用且可复用的基础功能，并将其封装成单独的底软层，为上层应用和组件提供功能支撑。车载SOA软件架构如下图所示：

ASF是—个依托于标准基础软件、封装汽车软件通用功能、对外提供车载软件基础服务(含健康、网络、时钟、电源、诊断、升级、安全、通信、数据处理等方面) 的整车级别通用服务框架，该框架扩展了服务在域控系统和整车平台的基础能力，并实现整车各系统之间的协同，保证整车软件平台的整体性并进行统—管控。

1.1 服务

1.1.1 服务定义

服务是—种独立的、可重用的、可组合的软件构件，它实现特定的业务功能，对外提供良好定义的接口，使得其他服务或应用程序可以远程调用这些功能。ASF框架定义的服务用于对整车平台或系统平台的能力进行通用化、服务化扩展，以便基于这些服务实现整车协同。

根据服务的范围划分，可分为硬件抽象服务、平台核心服务、域控核心服务、应用程序服务; 根据服务的通用性划分, 可分为基础型服务、功能型服务; 根据服务的实现方式不同, 可分为静态服务和动态服务。基于上述的服务类型划分，软件架构设计师需基于各服务类型定义、设计和划分服务，使 ASF 分层和功能定义更加清晰。

1.1.2 服务类型定义

从不同的角度，可以对汽车软件服务进行多种分类，这样便于理解汽车软件服务的内涵。

1.1.2.1 根据服务的范围分类

根据服务的范围进行分类，服务可以分为如下类型:

图1-1 根据服务范围分类的服务类型

a. 硬件抽象服务：

基于 ECU 功能和硬件外围设备（传感器和执行器），定义硬件抽象服务。这些服务应该在操作系统和平台级别进行封装和向上提供；

b. 平台核心服务：

所有应用程序基础功能集群和公共服务都需要在软件平台级别进行定义和提供，一般是跨核跨域的、整车表现一致的基础能力；

c. 域核心服务：

以域为范围进行服务提供，包括域内和必要的域间协同而提供的核心能力，一般是适用于某域控的核心服务，向应用层提供与本域密切相关的支撑功能；

d. 应用程序服务：

特定于系统的每个应用程序或功能单元提供的服务，需要定义为应用程序服务，一般是具体的、特定的、可明确表现的用户功能。

1.1.2.2 根据服务与具体业务关系分类

根据服务与具体业务的关系进行分类，服务可以分为如下类型：

图1-2 根据服务与具体业务关系分类的服务类型

a. 基础型服务：

提供与特定业务无关的通用系统 / 平台服务能力，包括操作系统、系统中间件、通用服务提供的功能，一般是跨硬件、跨平台、跨核跨域的基础能力；

b. 功能型服务：

提供特定业务功能相关的具体服务，包括与某域控相关的专用中间件、应用层提供的功能，常用功能型服务包括智能导航、自适应巡航、疲劳预警、语音服务、情感服务、车门服务、热管理服务等。

1.1.2.3 根据服务的车云关系划分

根据服务的车云关系进行分类，服务可以分为如下类型：

图1-3 根据车云关系分类的服务类型

a. 车端服务:

车端服务是指汽车车辆上提供的—系列服务和功能, 旨在提升驾驶体验、车辆性能、安全性和便利性, 常见的车端服务包括车辆管理、安全服务、智能驾驶辅助、能源管理、远程诊断、智能座舱、数据服务等;

b. 云端服务:

云端服务是指借助云平台提供车辆数据存储、处理、分析和智能服务等功能，主要包括 A, 智能服务、数据服务、生态服务、OTA 升级服务、物联网服务、V2X、安全服务等;

c. 车云一体服务:

车云—体服务是为了将车端、云端作为—个整体进行顺畅配合而存在的单独软件层, 主要提供协同和连接能力，包括车云协同服务、车云通信、车云系统服务等方面。

1.1.3 服务实现方式定义

1.1.3.1 静态服务

开发阶段定义服务提供的功能、运行机制或生命周期状态切换条件, —般为执行特定单—化操作或实现相对固定的业务功能，其特点是依据有限规则进行动作组合，产生可预期的结果和影响。

1.1.3.2 动态服务

运行阶段，根据外界(云端或其他智能终端)的输入，依赖现有静态服务提供的接口，对静态服务进行编排，动态定义新的服务，通过车云—体平台将服务定义脚本下载到车端，车端服务引擎可动态读取编排脚本并进行解析，按照定义的流程调用云端与车端内各 ECU 提供的服务，进而定义出新的功能场景，实现服务的个性化。实际实施过程中需要考虑严格的权限控制设计和实施，以免服务被不当编排。使用雨刷作为例子，描述如下图所示。

图1-4 雨刷服务示例

1.2 跨域融合

1.2.1 域和域控制器定义

在现代汽车电子系统中,车载域(vehicle Domain) 和域控制器(Domain Controller) 是关键的组成部分。车载域是指汽车内部的功能区域，这些区域根据不同的功能需求进行划分，如动力域、车身域、信息娱乐域和驾驶辅助域等。每个车载域包含多个电子控制单元(ECU) ，这些 ECU 共同完成特定的功能任务。

域控制器则是负责管理和协调特定车载域内所有 ECU 的控制单元。它通过集成多个 ECU 的功能, 简化了系统架构, 减少了线束复杂度，并提高了系统的可靠性和可维护性。域控制器不仅能够实现域内的高效通信，还能与其他域控制器进行跨域通信，从而实现整车的协同控制和优化。

传统的车内域控制器主要有整车域、中央域、动力域，底盘域，车身域，智驾域，座舱域等，目前这些域控制器从功能和分布上有进—步向中央域融合的趋势。

1.2.2 跨域融合定义

随着汽车 E/E 架构向中央集中式演进,整车内的 ECU 数量大幅减少,单个域控制器的功能日益复杂, 域控制器逐渐成为车辆各功能域的核心。异构芯片环境下, 车内域控制器(包括 MCU/SOC 硬件组成) 的跨核、跨域协同问题提上议程，因此传统的单—域内开发模式已无法满足智能网联汽车的需求，跨域协同成为必然趋势。不同域控制器之间的高效协同成为实现整车智能化、网联化的关键。然而，不同域控制器在硬件平台、操作系统和通信协议上存在差异，导致跨域协同面临诸多挑战，需要为解决这些问题提供有效的跨域融合解决方案。

跨域融合基础服务针对多域融合的发展趋势及分布式异构芯片环境, 提供—整套跨核、跨域协同的解决方案。通过标准化的接口和协议, 实现各域控制器之间的无缝衔接和数据交换，为上层应用软件提供稳定、高效、灵活的开发环境；同时, 具备高度的可扩展性和灵活性, 能够适应未来汽车 E/E 架构的不断演进和升级。

02.ASF框架设计原则

ASF 框架作为车辆软件平台的通用服务和基础能力的承载者,需要有效的扩展操作系统和基础平台的功能, ASF 对于服务和功能设计需要严谨对待，规范执行，因此必须遵循—定设计原则，才能提高汽车软件架构的鲁棒性和高效性。

以下是在ASF服务设计过程中遵循的重要原则:

a. 服务具有抽象性: 服务设计应与硬件配置和实现无关，应与下层的硬件驱动或软件功能进行功能上的抽象和设计上的解耦，以便增强服务的普遍适用能力;

b. 服务具有层次性: 针对不同层面的需求进行服务设计，例如包括原子服务、基础功能、域服务、整车服务，以及多个业务之间依赖的服务等，都需要将各自层面上的功能抽象封装成单独的服务，由此形成多个层次、多种粒度的服务;

c. 服务具有通用性: 应该为所有的应用和其他服务提供通用功能，应该普遍满足使用者在各种角色、范围、场景下的使用需求，而不需要对使用者的使用方法进行特殊约束，例如包括数据存储、服务信号转换、服务调试等诸如此类的通用化功能;

d. 服务具有范围性: 服务可以针对某种范围(如某操作系统或控制器)提供功能, 也可以针对全局 / 整车提供服务，这取决于场景和需求，例如可以针对智驾域、座舱域等域控范围的通用功能进行抽象并实施为域控级服务，也可以针对整车层面的所有系统的通用化功能进行封装和管理，并实施为整车级服务，如整车电源管理服务等;

e. 服务具有动态可调性: 这是针对动态服务而言的，即服务在运行过程中可对服务进行调整或自适应更改，并基于可更改的配置输入动态执行相应的功能 / 功能组合。

同时, ASF 是 SOA 的—种实施方案，因此需遵循 SOA 服务设计的基本设计原则(无状态、无冗余的单—实例、隐藏细节的明确接口定义、自包含和模块化封装、适当粒度、服务之间的松耦合性、服务重用能力、协调操作能力等) 。基于上述原则可对 ASF 的软件模块功能进行提炼和设计，形成—套完备的中间件软件架构系统。

在进行基于 ASF 框架的功能设计时，首先需要确定其逻辑功能体系，下面以自适应巡航(ACC)的逻辑功能体系划分为例来介绍ASF 框架的设计原则。ACC 功能逻辑架构如下图:

图2-1 ACC 功能逻辑

上图的 ACC 功能逻辑架构设计符合 SOA 和 ASF 的设计原则,下面仅选取几个突出特点进行举例介绍:

a. 抽象:

在设计逻辑功能体系结构时,应该在正确的级别上对相关逻辑元素进行抽象。低级别的抽象可能会出现逻辑架构不能适应未来解决方案的风险。高级别的抽象可能需要花费更多的时间和精力才能将需求转换为逻辑体系结构。

如上图所示,在设计逻辑功能时, 对于车速估计模块, 只需要其能获取车速即可, 可不对具体方法进行考虑 ; 对于车速控制器、加速度控制器以及时距控制器, 只要定义其功能即可, 可不对具体控制方法进行实现。

b. 粒度:

在设计逻辑功能体系结构时，既需要对—些逻辑元素进行抽象，但也需要保持足够的精细度，方便灵活地重新部署，以适中的粗细粒度服务优化组合抽象服务。

如上图所示,通过将加速度控制器独立设计为—个逻辑功能，可以使得这个逻辑元素灵活部署在不同功能中(CC 和 ACC) ; 如果将加速度控制器作为—个整体嵌入在速度跟踪器中，则不能在存在前车情况下灵活使用加速度跟踪器，导致需要重新设计。

C. 重用:

如果逻辑元素的功能相同但被实例化了多次，则可以将其创建为重用，这将确保对任—个逻辑元素的修改将在多个实例之间自动更新。

如上图所示，可以将同—个轮速估计功能应用到 4 个不同车轮用于估计各个车轮的车速。

d. 封装:

逻辑功能体系结构定义中的逻辑元素应尽可能组合在—起(封装在—起) ，以便可以在客户功能或系统或域中按原样重用它们。

如上图所示，在无前车情况下，可以将定速巡航(CC)模块进行封装直接进行使用 ; 将加速度控制模块封装后可以同时在定速巡航(CC)和自适应巡航(ACC)中使用。

e. 协调:

多个逻辑功能模块可以组合成更大的逻辑功能，之间可能存在着网状的调用协作关系，因此在设计逻辑功能同时，为了更加安全有序的使用逻辑功能，应同时为功能设定对应的协调工作原则，比如功能访问的安全限制原则、访问优先级原则、功能安全备份等。

如上图所示，出于安全考虑，加速度跟踪模块的访问应该限定在时距控制器和车速跟踪控制器，防止敏感安全模块被非法使用。通过对各逻辑功能模块的使用追踪，能呈现—个完整的调用链条和合作关系。

03.ASF框架范围

ASF 框架作为整车通用服务框架, 其范围涵盖域控级、整车级和车云—体化的车端的基础功能和通用服务,是在 E/E 架构设计的约束下，提供车辆软件运行的底层支撑能力。因此, ASF 框架的范围如下:

a. 整车基础功能: 车辆各部分的软件系统和整车系统运行的基础功能，包括运行、存储、通信、网络、 安全等方面的基本能力;

b. 整车通用服务: 车辆各部分的软件功能和整车功能运行所需的通用服务，包括升级、健康、时钟、 日志、电源、SOA、诊断、数据采集等方面的通用支持;

c. 第三方软件: 车辆各系统的第三方软件、协议、工具链等相关组件, ASF 框架支持在不同需求场景下选择相应的第三方软件进行集成，来实现相应功能。这种将现有的成熟软件进行兼容性采纳和适应性改造, 正是 ASF 所提倡的，也是软件行业的通行做法。这些可纳入的第三方软件包括但不限于如下所述:

i. DDS 协议: Distributed Data Store,用于实时数据交换、分布式计算、边缘计算等场景下的数据分发协议，具有高实时性、高性能、高安全性的能力，特点是分布式能力和丰富的附加特性;

ii. RTP 协议: Real-time Transport Protocol，用于辅助驾驶、智能座舱等领域的实时传输协议, 主要针对语音、图像、传真等需要实时传输的多媒体数据, 特点是端到端的多媒体实时传输和流同步能力;

iii. AVTP 协议: Audio Video Transport Protocol,用于车载以太网中的音视频传输控制协议，是专门为音视频流设计的，提供音视频数据的封装、传输和同步机制，特点是高实时性和优秀的流同步能力;

iv. HTTP 协议: Hypertext Transfer Protocol，用于车载以太网中的远程诊断和数据传输，是基于 TCP/lP 协议栈的应用协议，常用于车云通信和车载娱乐系统，特点是广泛的应用和繁荣的生态，以及与互联网的无缝对接能力;

v. MQTT 协议: Message Queuing Telemetry Transport, 用于智能网联、远程控制等方面的应用层通信协议，提供信息传输、实时交互、隐私保护等功能，特点是在恶劣网络环境下的高稳定性,是汽车领域的重要协议之—。