Car

Skynet

通过自动、用户主动调用接口等方式收集、汇总、存储数据，进而通过可视化界面为用户提供多维度的实时和历史数据、异常报告等，方便用户快速发现和定位问题。

服务

1.EM

执行管理系统（Execution-manager，EM） 是自适应平台基础中的一个功能集群，负责平台初始化以及进程的启动和关闭 。EM 使用 Machine Manifest 和每个应用程序所对应 Manifest 中的信息来控制平台、满足依赖以及执行应用程序，此外 EM 还为状态管理系统（State-Manager, SM）提供支持。具体体现如下：

1. 所有接受EM管理的进程的启动与退出，包括platform service及application service 包括所有进程的启动顺序及每个进程的优先级等
2. 根据SM的状态切换指令，对每个Function group的app组进行管理

2.NM

ZKOS Network Management的作用是让网络中的ECU节点有序的睡眠和唤醒，节省整车电量。

Network Management采用集中式分级网络管理的策略。整个网络中的节点被分为3类：NM Endpoint、NM Router和NM Manager，每个角色能唤醒的网络对象不同。

3.PM

​电源管理系统（Power Management，PM）xx os平台中负责对A核上层应用提供电源事件、电压事件、电压值通知和电源状态、电压状态、电压值查询，并向A核BSP发送电源事件通知的模块。该模块提供了PM client和PM Deamon组件。PM client负责上层应用提供接收PM Daemon的电源、电压、开机原因等事件的程序接口。PM Daemon负责接收M核电源、电压、开机原因等事件，并向上层应用提供电源状态、电压状态、开机原因等。

PM在实现上可以分成以下部分：

• PM Daemon：负责接收M核电源，电压，开机原因等事件通知处理以及向应用程序提供电源状态，电压状态，开机原因等

• PM client：负责上层应用接受PM Daemon的电源，电压，开机原因等事件通知处理以及向上层应用提供电源状态，电压状态，开机原因查询功能

4.PHM

平台健康监测管理系统（Platform Health Management，PHM） 是xx os平台中负责对app运行状态进行监测、对异常app进行恢复的模块 。该模块提供的phm client用于app实现自我状态的report、recovery action client用于向SM（State Management）通知错误状态，并由SM尝试错误恢复。

PHM在实现上可以分成三大部分：

• PHM Daemon组件是PHM的主运行模块，负责接收APP的状态汇报，并进行相关的判断。同时PHM集成WatchDog Client，向WM模块喂狗。当APP状态汇报异常时，PHM会将相关的故障信息通知SM，并由SM进行故障恢复。

• PHM 提供两种client：

1. phm client：APP通过该client与PHM Daemon进行通讯，并report相关的状态。

2. recovery action client: SM需要集成该lib库，并通过该lib库进行故障信息的接收。

5.SM

状态管理系统（State-Manager，SM）是ZeekrOS中的一个功能集群，使用functionGroup_manifest.json 中的信息来定义功能组及其包含的状态。 SM 受到执行管理系统（EM）的管理，接受外部源的状态切换的请求，反馈到EM切换整个平台的运行状态。

SM是受到EM管理的进程，同时受到PHM监控，SM被EM拉起，从配置文件中读取 FG 的定义，将所有FG按配置顺序切换至Startup状态后，等待外部源的请求。

6.persistency

Persistency是为运行在汽车上所有的应用程序和功能集群提供一套将数据储存到非易失性存储（NvM）介质的机制。Persistency将会提供键值对和文件库，被各个Persistency用户集成和调用，提供的功能包括数据缓存、数据淘汰、 数据热更新、数据周期性落盘。Persistency提供了访问这些数据的一系列接口，可用的数据类型分为两类:

• 键值对存储
• 文件存储

7.COM

Communication通讯模块在XX ARK OS 系统中主要负责整车服务化通讯支持，具体体现如下：

• 提供统一标准化的服务通讯接口，支持SOME/IP、IPC-SHM、TCP协议，并支持协议扩展。
• 支持sub/pub, RPC, C/S模型，内部提供SD服务，TCP目前仅支持C/S模型
• 提供完整的服务通讯库，供服务/框架开发使用
• 提供服务化的COMM接口

功能特性

1. 所有接口均是异步接口，支持域内、跨域服务的异步调用，通讯层可根据实际部署的协议类型，选择将调用请求通过指定传输协议发出。

2. 支持PUB/SUB模型、Client/Server模型和RPC模型，并且提供丰富的配置参数

3. 具备完整的错误及异常处理机制

4. 统一的通信协议和地址规范

• 独立于具体Transport的实现

• 可扩展，可根据业务场景、安全、稳定性等诉求增加控制交互

• 分层设计，上层协议之间对下层透明

1. 灵活、快速的服务发现

功能优势

满足汽车智能化的整体通信需求，屏蔽异构通信系统中的复杂的、繁琐的实现细节和通信协议，它能大幅降低整体服务之间通信的开发成本，并具备可持续的扩展能力。

服务发现:当provider上下线的时候，consumer可以及时收到回调通知。

回调处理:所有接口均是异步接口，所以如connect、close等接口必须等到状态回调，并且状态满足时才能继续后续的工作。

8. Service

ProviderBase向上主要提供的功能是：注册Method接口、推送Topic接口、启动服务接口、停止服务接口。

ConsumerBase向上主要提供的功能是：调用Method接口、订阅Topic接口，接收Provider推送的服务状态消息。

Servicemanager主要提供的功能是：服务状态管理，服务状态监控

• Service Oriented Framework组件包含serviceproxy, serviceskeleton等基本模块，在基本模块基础上使用工具链生成服务框架代码可迅速构建服务开发的代码框架。

功能优势

ZEEKR OS Service Framework旨在构建 ZEEKR OS 的服务化基础，为整个 ZEEA 3.0 架构提供完善的服务开发框架，使得服务开发者可以快速基于 ZEEKR OS Service Framework 构建出服务的框架，填充完整服务实现后，即可编译打包 Release。

9. tsync

Time Syncronization:Tsync Daemon是ZEEKR ARK OS提供时钟同步的一个守护进程，运行该进程时可以实例化gptp协议栈，ntp协议栈和gnss协议栈实现时钟同步服务，同时zkos_tsync提供获取Vehicle time/UTC时间的动态库zkos_tsync_clock_if和接口方法。

10. zbus

ZBUS全称xx-BUS，主要实现S32G芯片A核与M核的核间通信的标准化方案。

目前为用户提供的功能

● 提供S32G芯片A核与M核间基于NXP-IPCF技术的数据通信能力。

SOMEIP

SOMEIP消息结构

SomeIP协议的消息结构主要包括 消息头（Header）和 消息体（Payload）

消息头（Header）：

SomeIP消息头(12字节大小)的结构包含了一些关键字段，具体如下：

• MessageID：消息标识符，由ServiceID和MethodID组成，用于唯一标识消息类型。(4 byte)
• Length：消息的总长度，包括头部和有效载荷的长度。(2 byte)
• Protocol Version：协议版本标识，用于版本管理。(1 byte)
• Interface Version：接口版本，用于服务接口的版本管理。(1 byte)
• ClientID：客户端标识符，指明发起请求的客户端。(2 byte)
• SessionID：会话标识符，用于识别同一会话中的多个消息。(2 byte)
• HeaderID：标识该消息属于哪个服务接口，帮助区分不同服务或版本。(2 byte)

`MessageID`是SomeIP协议中非常重要的字段，主要用于唯一标识一个特定类型的消息。它通常由两部分组成：**ServiceID** 和 **MethodID**。

-   **ServiceID**：标识某个特定的服务。例如，如果一个车载系统提供温度传感器服务，它的ServiceID就用于标识该服务。
-   **MethodID**：标识服务提供的具体方法或功能。例如，如果该服务有“获取温度”或“设置温度”的方法，那么每个方法都会有一个独立的MethodID。

MessageID = (ServiceID << 16) | MethodID
这种格式是将`ServiceID`和`MethodID`拼接成一个32位的整数。`ServiceID`通常占16位，而`MethodID`占16位。这样，`MessageID`就能够唯一地标识一个服务方法。

举个例子，如果：

-   ServiceID = 1001（表示温度传感器服务）
-   MethodID = 1（表示获取温度）

那么，`MessageID` = 1001 << 16 | 1 = 0xF401。

消息体（Payload）：

有效载荷（Payload）包含实际的数据内容，比如服务的请求内容或响应结果。有效载荷的大小取决于具体的应用和服务要求。

someip 和dds 中间件区别

• SomeIP：主要用于车载系统中，特别是在汽车领域。它是基于服务的中间件，支持服务发现和服务调用，旨在为车辆内的各种模块提供高效、灵活的通信。SomeIP支持基于IP协议的通信，主要用于实现车辆内部不同电子控制单元（ECU）之间的通信。

• DDS：是一种用于实时分布式系统的数据共享中间件，强调数据分发。DDS设计用于跨多个设备的通信，支持数据发布/订阅模式，并具有良好的实时性和可扩展性，广泛应用于航空航天、军事、工业自动化等领域

服务发现

• SomeIP：具有服务发现机制，节点可以动态发现其他节点提供的服务，并进行通信。。
• DDS：也有服务发现机制，但它的设计更侧重于实时分布式系统中的数据共享，服务发现与数据流密切相关，系统会自动发现网络中的数据源。

数据传输

• SomeIP：一般通过UDP或TCP协议进行数据传输。
• DDS：使用一种更加灵活的协议，通过数据流进行高效的数据传输。DDS支持多种传输协议（如UDP、TCP、Shared Memory等

总结

• SomeIP适合车载通信领域，注重服务调用和高效的IP协议通信。
• DDS则更注重实时数据分发，适用于多设备、多节点的分布式系统，特别是在要求高可靠性和实时性的场景中表现更好

IPCF

IPCF（Inter-Process Communication Framework）是一种 进程间通信（IPC）框架，主要用于 嵌入式系统 和 汽车电子领域（如 AUTOSAR Adaptive Platform）。它提供了一种高效、可靠的跨进程通信机制，适用于 多核/多ECU 系统。

1. IPCF 的核心功能

功能	说明
进程间通信（IPC）	提供跨进程的消息传递机制
零拷贝（Zero-Copy）	减少内存拷贝，提高性能
共享内存（Shared Memory）	高效数据交换，适用于大容量数据传输
事件通知（Event Notification）	支持异步事件触发
多核支持	适用于 AMP（非对称多核）和 SMP（对称多核）
安全隔离	支持进程间访问控制（如 TEE 环境）

---

2. IPCF 的通信模型

IPCF 通常支持以下通信模式：

(1) 消息传递（Message Passing）

• 同步调用（RPC 风格） ：类似 SOME/IP，适用于请求-响应模式。
• 异步消息队列：生产者-消费者模型，适用于事件驱动架构。

(2) 共享内存（Shared Memory）

• 零拷贝传输：适用于 高吞吐数据（如摄像头、雷达数据）。
• 内存池管理：避免频繁分配/释放内存。

(3) 信号量/事件通知

• Semaphore/Mutex：进程间同步。
• Event Trigger：异步通知（如中断触发）

3. IPCF vs. 其他 IPC 机制

特性	IPCF	DDS	SOME/IP	POSIX IPC
通信模型	消息/共享内存	Pub/Sub	Client-Server	消息队列/共享内存
适用场景	多核/ECU 通信	分布式系统	车载 SOA	通用 Linux IPC
性能	高（零拷贝）	中（序列化开销）	中（TCP/UDP）	中（系统调用开销）
标准化	AUTOSAR AP	OMG DDS	AUTOSAR	POSIX
典型应用	域控制器通信	自动驾驶	车身控制	通用嵌入式系统