GB/T英文版翻译智能网联汽车车载操作系统技术要求及试验方法

ChinaAutoRegs|GB/T英文版翻译智能网联汽车车载操作系统技术要求及试验方法

Intelligent and connected vehicle Technical requirements and test method of in-vehicle operating system

前言

本文件按照GB/T 1.1—2020《标准化工作导则第1部分：标准化文件的结构和起草规则》的规定起草。

请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别专利的责任。本文件由中华人民共和国工业和信息化部提出。本文件由全国汽车标准化技术委员会（SAC/TC114）归口。

本文件起草单位：本文件主要起草人：

智能网联汽车车载操作系统技术要求及试验方法

1 范围

本文件规定了车载操作系统单系统的内核、资源抽象、基础库、基础服务、程序运行框架、多系统、可信执行环境、性能指标、信息安全、功能安全等的技术要求和相应的试验方法。

本文件适用于M和N类车辆，其他类型的车辆可参考使用。

2 规范性引用文件

下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，已标注日期的引用文件，仅该日期对应的版本适用于文件；未标注日期的引用文件，其最新版本(包括所有的修改单) 适用于本文件。

GB/T 34590.3 道路车辆功能安全第 3 部分：概念阶段 GB/T 40856 车载信息交互系统信息安全技术要求 GB/T 41388 信息安全技术可信执行环境基本安全规范 GB/T 44373 智能网联汽车术语和定义

GB/T 44464 汽车数据通用要求

GM/T 0005 随机性检测规范

3 术语与定义

下列术语和定义适用于本文件。

3.1

车载操作系统 vehicle-info operating system

运行于车载信息交互系统硬件之上，管理和控制智能网联汽车车载软件、硬件资源的软件集合，为智能网联汽车提供除驾驶自动化功能实现以外的服务。

注：车载操作系统提供的服务包括互联、地图及定位、语音、多媒体、软件升级、账号、驾驶提示、车辆设置、增强的人机交互、显示功能等服务。

3.2

单系统架构 single system architecture

在同一套硬件之上运行单个车载操作系统的架构。

3.3

多系统架构 multi-system architecture

在同一套硬件之上运行多个车载操作系统的架构，多采用硬件隔离、虚拟机管理器、容器三类或者它们的组合方式实现多系统隔离技术方案。

3.4

资源抽象 resource abstraction

运行于车载操作系统内核之上，通过创建软件为车载操作系统应用和基础服务提供硬件资源物理特性和接口内容。

3.5

物模型 thing model

对一个物体的数字化描述，包括元素、组件和物模版三层结构。注1:元素主要包括属性、服务（又称行为或者命令）以及事件。注2:组件是基于物模型元素的一个表示物的抽象层，可表示一个包含有元素中多个同类型或者多个不同类型元素

的集合。

注3:物模板是基于组件以及元素的一个表示物的抽象层，可表示一个包含有组件、元素、以及自定义元素的集合。 [来源：YD/T 4915-2024,3.1，有修改]

3.6

虚拟机管理器 hypervisor

运行于硬件层和多个车载操作系统单系统之间的中间软件层，通过限制或允许访问CPU、中断、内存、外设等资源来定义每个车载操作系统单系统可用的资源。

3.7

容器 container

运行在资源隔离管理框架之上的进程或应用程序。

3.8

安全强相关应用 safety strongly related application

与智能网联汽车功能安全关联性较强的车载操作系统应用负载，如运行仪表、倒车影像、提前输出声音和错误处理等应用。

3.9

安全弱相关应用 safety weak related application

与智能网联汽车功能安全关联性较弱的车载操作系统应用负载，如多媒体应用等。

3.10

OEM 账号 OEM account number

OEM 账号是车厂的用户账号，一般包括车主账号、非车主账号和游客账号。

注：

1）车主账号：每个车辆与一个车主账号唯一对应，用户通过该账号登录车辆的车载系统，车主账号拥有对车辆设置和功能的完全控制权；

2）非车主账号：是一种授权账号，由车主账号进行授权，也可以由车主账号撤销授权，出于安全考虑，车主账号授权的非车主账号数量应有上限，以防止滥用和安全风险；

3）游客账号：当用户未登录车主账号或非车主账号时，应提供游客账号选项。游客账号允许用户访问车载操作系统的基本功能，如车辆控制、设置和地图服务等，以确保即使在未登录状态下，用户也能使用车辆的基础功能。

3.11

系统账号 System account number

提供访问授权、本地资源管理等车载操作系统基础账号服务能力。

3.12

云端应用账号 Cloud application account number

提供第三方账户绑定、多账户管理等车载操作系统的云端应用账号服务能力。

4 缩略语

下列缩略语适用于本文件。

API: 应用程序编程接口 (Application Programming Interface) ASIL: 汽车安全集成等级 (Automotive Safety Integration Level) CA：客户端应用（Client Application） CAN：控制器局域网络(Controller Area Network) DMS：司机监测系统（Driver Monitoring System） ETC：电子不停车收费（Electronic Toll Collection） GNSS：全球导航卫星系统（Global Navigation Satellite System） IC：集成电路（Integrated Circuit） MCU：微控制单元(Microcontroller Unit)

OBD：车载诊断（On-Board Diagnostics） OBU：车载单元（On-Board Unit） OMS：乘客监测系统（Occupancy Monitoring System） OTA: 空中下载 (Over the Air)

PAN: 特权模式不可访问用户态数据（Privileged Access Never） PXN: 特权模式不可执行用户态程序（Privileged Execute Never） TA：可信应用（Trust Application） TEE：可信执行环境(Trusted Execution Environment) V2X：车与外界的互联（Vehicle-to-Everything）

5 车载操作系统技术要求

5.1 通用要求

车载操作系统架构和功能模块参见附录A。

三类车载操作系统（中控操作系统、用于仪表盘的操作系统、用于T-box的操作系统）应支持的功能模块和可选支持的功能模块参见附录B。

车载操作系统可按照6.1的试验方法进行试验，每项试验方法对应的车载操作系统被测功能模块参见附录C。

5.2 车载操作系统内核

车载操作系统内核一般分为微内核和宏内核。

按照 6.2 的试验方法，微内核应满足下述 1）到 7）的条款，宏内核应满足除 6）以外的条款。 1) 进程应完整执行其生命周期，从启动到终止，并在终止后释放所有占用的资源；

2) 对于具有相同优先级的进程组，应确保每个进程都能获得 CPU 时间片；

3) 对于不同优先级的进程组，应确保高优先级进程先于低优先级进程执行；

4) 内核应支持内存的分配、回收、隔离和共享功能；

5) 应满足进程间通信的时效性，确保数据传输的及时性；

6) 用户空间的驱动或应用程序崩溃不应导致微内核崩溃或影响其他进程的正常运行；

7) 内核应支持至少一种芯片的指令集；

8) 可扩展支持 USB 存储设备的基础协议；

9) 操作系统宏内核为硬件抽象（HAL）提供设备驱动程序框架和设备驱动访问控制功能；

10) 操作系统宏内核支持至少一类文件系统（如 EXT3、UFS、FAT32、NFS 网络文件系统等）；

11) 操作系统宏内核支持网络协议栈。

5.3 资源抽象

5.3.1 硬件抽象

按照 6.3.1 的试验方法，硬件抽象应满足下述要求：

1) 支持对芯片的资源抽象；

2) 支持对屏幕、摄像头、扬声器、麦克风等的资源抽象；

3) 支持对外围 IC（如蓝牙、WLAN、GNSS、FM 等）的资源抽象；

4) 支持对外围存储设备（如 U 盘）的资源抽象。

5.3.2 整车服务资源抽象

按照 6.3.2 的试验方法，整车服务资源抽象应对上层应用提供 API 接口，例如提供 API 接口实现对空调、座椅等的显示和调节等服务。

5.4 基础库

按照 6.4 的试验方法，基础库应至少为车载操作系统应用提供进程间通信库、网络传输库、安全通信库、图像库、 C/C++库，宜提供语言引擎库、密码学算法或对硬件加解密的封装接口。

5.5 基础服务

5.5.1 互联服务

按照 6.5.1 的试验方法，运行时环境应满足下述要求：车载操作系统支持的互联服务应具备以下能力：

1) 支持与 T-Box、OBD、Tuner、V2X-OBU、ETC 等多车载终端互联服务；

2) 支持通过无线（如 WLAN、蓝牙）或有线（如 USB）方式与个人移动端、云端的信息交互互通，

实现娱乐智能服务、辅助控制服务等；

3) 支持至少一种网络协议（例如 TCP/IP、HTTPS、MQTT 等），具备与云端互通的能力。

5.5.2 地图及定位服务

按照 6.5.2 的试验方法，地图及定位服务应满足下述要求：

1) 地图及定位服务为包括地图在内的各类应用程序提供位置相关的 API。

2) 地图服务功能可结合 GNSS、各类传感器以及车辆信号数据，实现位置信息求解。

3) 地图及定位服务可实时上传位置数据到云端，同时可接收云端返回的将位置信息与第三方服务或数据挖掘的数据进行融合后的数据，为用户提供所需的与位置相关的增值和个性化的服务。

注：3）的前提条件是地图及定位业务符合相关数据安全和测绘要求。

5.5.3 语音服务

按照 6.5.3 的试验方法，语音服务应满足下述要求：

1) 语音交互服务应提供声学前端、语音唤醒、语音识别、语音合成功能。

2) 语音交互服务可提供语音声纹、语义理解、对话管理、语义生成、语音自学习、语音交互展示等功能。

3) 车载操作系统可提供语音开发框架，将语音服务模块封装为 API 以供应用或者车载小程序使用。

4) 车载操作系统可通过提供语音技能开放平台等方式，支持第三方应用开发者自助式编写离线/ 在线的语音技能，开展有利于开发者的可视化编辑、管理等工作。

5.5.4 多媒体服务

按照 6.5.4 的试验方法，多媒体服务应支持基础的图像、音频、视频的编解码功能以及播放和控制服务，将服务模块封装为 API 以供应用或者车载小程序使用。车载小程序的 API 接口参见附录 D。

5.5.5 软件升级服务

按照 6.5.5 的试验方法，软件升级服务应满足的下述要求：

1) 为新发布功能、安全补丁提供升级通道，确保用户及时接收到软件更新；

2) 可通过网络自动检测到新版本，在用户确认后开始下载和安装过程；

3) 支持在后台管理下载和安装过程；

4) 下载和安装完成后应提示升级完成结果（成功或失败），若升级失败，可提供原因描述。

5.5.6 账号服务

5.5.6.1 系统账号服务

车载操作系统应具备系统帐号。按照6.5.6的试验方法，系统账号提供的服务应满足下述1）～5）的要求，可满足6）的要求。

5) 提供分层的应用授权访问机制，通过服务端鉴权保证服务端访问的安全性和合法性；

6) 支持对本地资源的管理，通过服务端鉴权保证在本地增加、删除以及切换帐户对应本地用户资源并访问该资源的安全性和合法性；

7) 车辆启动后，先通过登陆一种类型的 OEM 账号来登录对应的系统账号（登陆方式包括 OEM 账号密码登陆、扫码登陆、数字钥匙等）；

8) 系统账号与 OEM 账号应具备唯一对应关系，同步生成和注销；

9) 当用户选择退出账号登录，且车辆处于驻车状态下，系统应退出当前的账号；非驻车状态下，用户选择退出登录，系统应提示用户暂时无法退出登录；系统退出登录完成应通过动画等方式进行提示；

10) 当 OEM 账号支持同厂商下多车登陆时，系统账号可支持多车登陆。使用一个 OEM 账号（一个对应的系统账号）在其他车登陆的情况下，系统账号可依据 OEM 账号的设定，支持部分功能受限，例如，不支持下载/删除应用、还原系统设置/车辆设置/车牌号设置/上牌日期设置等。

5.5.6.2 云端应用账号服务

车载操作系统可具备云端应用账号，该账号作为第三方账号，接受 OEM 账号的管理。按照 6.5.6 的试验方法，云端应用账号满足下述要求，有一项符合则判定为符合：

1) 为车机用户提供一个或多个第三方账号绑定服务；

2) 支持用户授权并登录第三方账号后，在车上使用第三方提供的内容服务；

3) 根据与第三方账号约定的绑定要求，同步第三方账号提供的服务和权限；

4) 同一辆车支持与第三方账号保持同步登录和退出；

5) 支持多系统账号管理，提供统一的增加、删除功能；

6) 支持查询系统账号、获取系统帐号授权给应用的 ProxyToken 等应用开发接口；

7) 支持系统和应用/服务对多个系统账号的登录、注册、查询、授权等；

8) 支持单车多个系统帐户的切换，保证多个系统帐户之间的数据隔离和安全，防止多个系统帐户并存情况下的应用错误或者非法调用帐户服务。

5.5.7 驾驶提示服务

按照 6.5.7 的试验方法，驾驶提示服务满足下述要求：

1) 仪表盘操作系统应支持驾驶相关故障告警提示服务，如控制器异常、油箱告警、电量告警、胎压告警等。

2) 座舱操作系统可支持驾驶影像提示服务，如 360°环视、倒车影像、盲区提示、压线提示、透明底盘、轮胎轨迹线提示等。

5.5.8 车辆设置服务

按照 6.5.8 的试验方法，车辆设置服务满足下述要求：

1) 车载操作系统应支持车辆参数设定，如空调策略、电源策略、时间策略、亮度策略和车窗开启策略等；

2) 车载操作系统可支持智能车辆设定，如结合车辆传感器和预设的配置文件，智能设置电源策略、时间策略、亮度策略和车窗开启策略等。

5.5.9 增强的人机交互服务

按照 6.5.9 的试验方法，若车载操作系统支持增强的人机交互服务，则应满足下述要求：

1) 车载操作系统提供 AR 导航、车外视觉辅助驾驶类（如盲区检测、行人提醒，斑马线提醒，前车起步/溜车提醒、前车距离提醒、压线违章提醒、车道偏离提醒等）、车内视觉安全驾驶类

（如疲劳驾驶，FaceID，手势识别、人脸/摄像头遮挡识别、分心识别等）等人机交互和人工智能服务，并且响应性、流畅性、准确性、稳定性、完整性满足一定的要求。

2) 车载操作系统支持成熟的机器学习框架所训练的人工智能模型（如 TensorFlow、PyTorch 等），提供满足多种机器学习框架训练的人工智能模型的高效执行环境，并至少支持一种符合车载应用场景需要的功能，如语音识别、个性化推荐、自然语言处理、计算机视觉识别功能等。

5.5.10 显示功能

按照 6.5.10 的试验方法，若车载操作系统支持显示功能，满足如下要求：

1) 应支持仪表显示；

2) 可支持行车记录仪显示；

3) 可支持 OMS 显示；

4) 可支持 DMS 显示；

5) 可支持多屏幕显示；

6) 可支持抬头显示（HUD）。

5.6 程序运行框架

5.6.1 互联互通框架

按照 6.6.1 的试验方法，互联互通框架应满足下述要求：

1) 互联互通框架支持按照不同的接口类型接入 WLAN、蓝牙等车载设备。接口类型至少包括设备发现，快速接入，服务发现，协议校验，语音控制，在线升级，流量代理。

2) 互联互通框架可分为设备配网层，网络层，适配层、设备抽象层和业务表示层。

3) 设备配网层提供基础的设备组网功能，如 WLAN 快速接入，以及接入后的设备身份识别和认证；

4) 网络层提供设备接入后的连接管理和抽象，应支持至少一种网络协议（如 HTTPS、MQTT 等）的设备；

5) 适配层为智能设备提供 SDK，支持以物模型定义的运动相机，行车记录仪等智能设备的接入；

6) 设备抽象层对接入的智能设备的功能和对上提供的访问控制接口进行抽象，使得应用开发时不需要关心设备种类和型号的差异，通过统一的互联互通接口层进行数据的访问和共享；

7) 业务表示层为上层应用提供业务逻辑数据。

5.6.2 服务融合框架

按照 6.6.2 的试验方法，融合多种基础服务的服务融合框架应提供服务的注册、发现、服务方法的调用、服务数据的订阅和发布、服务安全调用、服务调用并发数、异常调用时返回错误码、调用超时机制等，支持不同类型的服务组合成为新的服务或者应用。

1) 具有应用管理功能，包括应用生命周期管理、应用调度管理、数据和资源管理、应用升级机

制；

2) 具有支持应用开发（如快应用、系统应用、系统三方应用和小程序等）的功能。

5.6.3 多媒体框架

按照 6.6.3 的试验方法，多媒体框架应满足下述要求：

1) 多媒体框架包括音频输入输出与合成、预处理（如回声消除，滤波，去噪），后处理（如均衡、重低音、立体音效）等增强模块，以及基础的多媒体编解码服务；

2) 支持音视频文件播放、音视频文件扫描和呈现、在线音视频播放、音视频录制功能；

3) 支持跨系统的媒体交互功能，如投屏到仪表、手机投屏音视频播放，车内行车记录仪实时视频、小程序多媒体等；

4) 支持系统音频策略配置，如配置音乐播放和语音交互同时发生时的音频策略等，支持多种音视频编解码技术，例如音乐支持 MP3、WMA 格式等，视频支持 AVI、RMVB 格式等。

5) 支持将编解码后的音视频内容可由 App 封装和传输；

6) 支持多媒体功能的定制化需求，如功能裁剪、仅扫描音乐（不扫描视频和图片）、特殊格式的

音视频录制等。

5.6.4 多模态交互框架

按照 6.6.4 的试验方法，若车载操作系统支持多模态交互框架，则应提供至少两种交互框架（如语音、视觉、隔空手势、触摸屏、按键等），应用程序可选择接入一种或者同时接入多种方式来提供交互，例如，抬头显示、虚拟导航、通过手势来接听或者挂断电话等。

5.6.5 场景感知理解框架

按照 6.6.5 的试验方法，场景感知理解框架应根据场景规则或者机器学习模型，提供计算和理解当前场景的功能，应用程序可订阅场景感知理解框架的输出信号来执行动作或者推送服务。典型的场景理解结果比如是否发生了事故、是否在颠簸路面、是否违停禁入区域等。

5.6.6 用户界面框架

按照 6.6.6 的试验方法，用户界面框架应提供窗口、界面元素和动画的编程接口以及界面资源管理（贴图、多语言文本等），可提供接口供三方渲染引擎来绘制界面，支持 2D 或 3D 渲染。

车载操作系统可提供统一的小程序运行环境和小程序用户界面框架，支持开发者开发一份小程序代码可运行在不同车载操作系统中。车载小程序的 API 接口要求参见附录 D。

5.7 多系统

5.7.1 通用要求

按照6.7.1的试验方法，车载操作系统多系统架构应支持5.7.2、5.7.3、5.7.4中至少一种多系统方案。

5.7.2 基于硬件隔离的多系统

按照 6.7.2 的试验方法，基于硬件隔离的多系统将硬件资源通过硬件分区的方式进行划分和管理，应满足下述要求：

1) 为多系统提供了强制隔离。

2) 允许将资源划分为与不同执行环境关联的不同所有权组；

3) 硬件资源（如 SoC 外围设备(Resource)，内存区域(Memory)和引脚等）的所属分区应具备对该资源的访问和管理权限，其他分区不被允许对该资源进行操作；

4) 允许所有者配置对资源的访问权限；

5) 可支持同时并行访问同一硬件资源。

6) 全局电源管理。

7) 支持多操作系统间高效的通信和内存共享

5.7.3 基于虚拟机管理器的多系统

按照6.7.3的试验方法，基于虚拟机管理器（Hypervisor）的多系统将硬件和软件资源通过虚拟机管理器的方式进行划分和管理，应满足下述要求：

1) 硬件系统资源分配和共享（静态或动态）；

2) 外设资源的分配和共享（静态或动态）；

3) 确保车载操作系统单系统之间的独立性，某个车载操作系统单系统无法访问未提供给自身的资源；

4) 支持多操作系统间高效的通信和安全的数据共享；

5) Hypervisor 支持信息安全和功能安全相关方案；

6) 管理各操作系统优先级，根据优先级分配硬件资源，最大化利用硬件资源，并满足对时间敏感需求和系统服务质量的要求；

7) 管理各操作系统生命周期，包括启动，运行，关闭，重启，异常退出等状态；

8) Hypervisor 的存在应保证其低性能损耗，不应对各操作系统性能产生显著影响；

9) 具有不同安全性和安全级别的应用程序可以在相同的硬件上运行，通过虚拟机隔离相互保护；

10) 多容器间具有全局电源管理功能，控制容器的开关；

11) 共享外设的虚拟化，应采用安全隔离方式，不允许两个 VM 同时访问共享外设。

5.7.4 基于容器的多系统

按照 6.7.4 的试验方法，基于容器的多系统将硬件和软件资源通过容器的方式进行划分和管理，应满足下述要求：

1) 多个车载操作系统单系统中的非内核部分运行在基于内核（如 Linux 等）的资源隔离管理框架之上；

2) 容器间支持文件系统隔离和网络隔离；

3) 基于内核（如 Linux 等）的资源隔离管理框架支持多个容器的互相隔离，在某个容器中运行的程序无法访问其他容器内的文件和进程；

4) 资源隔离管理框架需要提供统一管理框架，支持容器的创建、启动、关闭及状态查询等管理能力，能够自动进行资源分配，最大化利用硬件；

5) 支持内核资源隔离，主要包括根文件系统路径、进程、用户、网络和 IPC；

6) 支持 CPU/内存资源的共享调度和配额管理；

7) 支持容器间及容器和 Host 间的通信机制；

8) 支持存储空间隔离，每个容器有独立的根文件系统，容器间互不可见对方文件系统

9) 支持容器间进程隔离，一个容器无法访问其他容器的进程；

10) 支持网络隔离，每个容器具备完全独立的网络协议栈视图，包括网络设备接口，IPv4 和 IPv6 协议栈，IP 路由表，防火墙规则及 sockets 等；

11) 支持容器间故障隔离，一个容器的异常退出或容器内进程的异常终止不影响其他容器的正常运行；

12) 支持外设共享技术，可配置多个容器对于外设的共享或独占能力。

13) 全局电源管理。

14) 管理各操作系统优先级，实现自适应分配，最大化利用硬件资源，并满足对时间敏感需求和系统服务质量的要求；

5.8 可信执行环境

5.8.1 基础要求

5.8.1.1 可信根

按照6.8.1.1的试验方法，依据GB/T 41388 6.2节的要求，可信根为可信执行环境建立及运行提供支撑。可以是硬件、代码和数据。可信根应具备以下安全要求：

1) 应具备机密性、完整性、真实性三个基本安全特性,能够为可信执行环境系统的安全鉴证、安全度量和安全存储提供支持;

2) 应提供访问控制机制,保证未经授权的用户不能访问和篡改可信根的数据和代码。

5.8.1.2 安全启动

按照6.8.1.2的试验方法，安全启动是通过安全机制来验证可信执行环境系统启动过程中每一个阶段软件代码的完整性和真实性,防止非授权或被恶意篡改的代码被执行。安全启动过程构建了一个信任链,整个过程始于一个可信根，其他组件或代码需通过完整性和真实性验证才能被执行。安全启动过程应保证可信执行环境系统的完整性和真实性。

安全启动应满足如下要求:

1) 应保证用于验证完整性和真实性的密码算法本身的鲁棒性；

2) 应保证可信根不可被替换或篡改；

3) 应保证用于代码完整性和真实性验证的密钥不可被非授权替换或篡改,并提供安全的密钥更新、撤销机制；

4) 应保证安全启动信任链按序逐级验证,不可被恶意绕过；

5) 宜提供代码防回滚功能。

5.8.2 可信操作系统

按照6.8.2的试验方法，可信操作系统应具备常规操作系统中的进程管理、内存管理、设备管理、文件管理、日志管理等基本系统功能。

按照6.8.2的试验方法，可信操作系统要求在访问控制、身份鉴别、数据完整性、可信路径等方面满足相应的安全技术要求包括:

1) 应保证可信应用及可信服务仅根据其所分配的权限访问相应的资源,不能越权访问；

2) 应保证系统自身、可信服务与应用启动的正确性与完整性；

3) 应保证系统自身、可信服务与应用数据和代码的真实性和完整性；

4) 应具备可信应用之间、可信应用与可信服务之间的访问控制能力；

5) 对于系统权限的管理，应避免赋予可信服务与应用最高权限，避免单一可信应用与服务出现异常时,影响系统内核及其他可信应用与服务的正常工作；

6) 可信操作系统应具备内存限制，避免应用申请内存超过堆空间大小而引起操作系统崩溃；

7) 可信操作系统应确保驱动崩溃不会影响到整个操作系统。

5.8.3 可信应用与服务管理

5.8.3.1 互信过程

按照6.8.3.1的试验方法，对可信应用及服务的管理，应采用基于设备提供商(或授权服务商)根证书、应用发布证书认证的方式进行，以确保应用数据的机密性、完整性、真实性和行为的不可否认性。

5.8.3.2 可信应用及服务部署

按照6.8.3.2的试验方法，当采用互信通道将 TA 部署到可信执行环境中时,可信执行环境首先要校验 TA 的真实性和完整性,并根据不同 TA 提供商所拥有的权限，对相应 TA 对应的相关资源和通信访问进行严格控制。

5.8.4 可信服务

5.8.4.1 可信时间服务

按照6.8.4.1的试验方法，可信执行环境系统应集成可信时间服务，为可信应用及其他可信服务提供获取可信时间的功能。可信时间分为系统时间与可信应用的持久化时间。系统时间具有任意的非持久性的起点，系统时间可以基于专用的安全硬件实现，也可以基于 TEE 时间实现，不同的可信应用实

例可以拥有不同的系统时间。在整个可信应用实例生命周期中，系统时间不可以重置或回滚，不会因进入低功耗状态而影响系统时间的正常运转：可信应用的持久化时间起点因每个可信应用的不同而不同，但应在重启过程中保持持久化。

5.8.4.2 可信加解密服务

按照6.8.4.2的试验方法，可信执行环境系统应集成可信加解密服务，为可信应用以及其他可信服务提供加解密功能。可信加解密服务应保证仅获得相应授权的可信应用或可信服务才可以访问密钥。

5.8.4.3 可信存储服务

按照6.8.4.3的试验方法，可信执行环境系统应集成可信存储服务，为可信应用及其他可信服务提供可信存储功能。可信存储服务包括但不限于如下功能：

1) 对存储对象的读写操作要求应确保操作的原子性、数据的机密性、数据的完整性；

2) 可信存储应具备访问控制机制，确保只有授权的应用才能访问相应的存储空间；

3) 可信存储宜提供对数据回滚攻击的防御措施。

5.8.4.4 可信身份鉴别服务

按照6.8.4.4的试验方法，可信执行环境系统可集成可信身份鉴别服务，为可信执行环境中的可信应用或其他可信服务提供身份鉴别功能。可信身份鉴别服务通过识别用户的个人身份数字特征信息来识别用户身份的合法性是否有操作相关功能的权利等。可信身份鉴别服务可以采用但不限于下列身份鉴别方式完成用户合法性的判断：口令、指纹、人脸。可信身份鉴别服务宜基于可信存储服务、可信人机交互、可信加解密服务等其他可信服务的协同操作来完成。

5.8.4.5 可信设备鉴证服务

按照6.8.4.5的试验方法，可信执行环境系统可集成可信设备鉴证服务，用于证明设备真实性。可信设备鉴证服务可以对外提供但不限于如下种类的功能：

1) 证明设备标识的真实性及设备来源的真实性；

2) 监测可信执行环境运行的健康状态；

3) 监测富执行环境运行的健康状态。

5.8.4.6 可信人机交互服务

按照6.8.4.6的试验方法，可信执行环境系统可集成可信人机交互服务，提供可信执行环境下的用户人机交互界面显示和输入功能。

按照6.8.4.6的试验方法，在用户和应用程序之间应提供可信通道。具备抵御非法屏幕输入记录、非法屏幕显示内容截取、钓鱼等攻击的防护能力。

5.8.4.7 SE 管理服务

按照6.8.4.7的试验方法，可信执行环境系统可集成 SE 管理服务，用于提供可信应用与 SE 之间的访问通道的功能，以满足更高安全应用场景的需求。

按照6.8.4.7的试验方法，SE 管理服务应具备访问控制机制以确保仅经过授权的可信应用可以访问SE。

5.8.5 跨平台应用中间件

按照6.8.5的试验方法，跨平台应用中间件主要用于解决不同可信执行环境系统之间的应用兼容问题，具体包括四个功能模块，其要求为：

1) 跨平台支持库，应用于弥补不同可信执行环境系统本地支持库的差异；

2) 安全驱动框架，应针对 NFC、摄像头、指纹等安全外设，建立统一驱动框架；

3) 跨平台编程语言，为解决不同可信执行环境系统对 TA 支持的兼容性问题，应建立符合相应安全要求的跨平台编程语言；

4) 跨平台 API，应支持不同平台对跨平台中间件调用的应用编程接口。

5.8.6 可信应用

5.8.6.1 可信应用加载的安全要求

按照6.8.6.1的试验方法，可信执行环境应具备对可信应用验证的能力,以达到保护可信应用内容、验证可信应用的合法性的日的。

5.8.6.2 客户端应用与可信应用通信的安全要求

按照6.8.6.2的试验方法，可信执行环境应具备访问控制能力,确保只有授权的客户端应用才能访问对应的可信应用。

5.8.6.3 可信应用与可信应用通信的安全要求

按照6.8.6.3的试验方法，可信执行环境应具备某种访问控制机制,使得仅被授权的可信应用可以与目标可信应用进行通信可信应用之间的通信，宜保证通信本身的机密性、完整性,除被授权的可信应用外,其他可信应用无法获取通信本身的信息。

5.9 性能指标

5.9.1 冷启动时间

按照6.9.1的试验方法，采用以下方式计算车载操作系统的冷启动时间，值越小性能越好。 1）车载操作系统开机上电到仪表信息或桌面（倒车雷达）呈现时间（典型值：小于5s）；

2）车载操作系统开机上电到操作界面可用时间（典型值：小于15s）；

3）车载操作系统开机上电到操作界面视觉可见时间（典型值：小于 13s）

4）车载操作系统开机上电到开机动画界面视觉可见时间（典型值：小于 2s）

5）车载操作系统开机上电到HUD界面视觉可见时间（典型值：小于 6s）

5.9.2 热启动时间

按照6.9.2的试验方法，采用以下方式计算车载操作系统的热启动时间，值越小性能越好。

1）车载操作系统由STR模式或休眠（standby）模式等切换到仪表信息或倒车影像（倒车雷达）呈现的时间（典型值：小于2s）。

2）车载操作系统由STR模式或休眠（standby）模式等切换到操作界面可用的时间（典型值：小于3 s）；

3）车载操作系统由STR模式或休眠(standby)模式启动到HUD界面稳定显示的时间(典型值:小于3s，进入STR模式的静态电流典型值<5mA）。

5.9.3 优先级调度响应时间

按照 6.9.3 的试验方法，在以下条件下，测量高优先级任务的切换响应时间，应确保实时性，值

越小性能越好：

1）高负载：CPU平均负载率80%以上，例如语音地图、ADAS渲染、娱乐应用等都运行；

5.9.4 存储空间读写性能

按照 6.9.4 的试验方法，在非负载和相同的温度条件下使用 OTG 或本地磁盘对 1GB 大小的文件进行多次读/写测试（测试时用同样的外挂硬盘），计算平均的读/写速度，值越大性能越好（典型值： NTFS 在 Win/Linux 系统使用的写平均速度 55MB/s，读平均时间 102MB/s）。

5.9.5 多系统间通信

按照6.9.5的试验方法，在不开启安全机制且空载条件下，计算车载操作系统多系统架构中不同系统间通信的平均时间、最长时间和最短时间。

注：

1）多系统架构类型包括5.7节基于硬件隔离的多系统、基于虚拟机管理器的多系统和基于容器的多系统。

2）对于两个操作系统A和B组成的多系统，典型测试方案为：输入命令行，多次进行车载操作系统A ping 车载操作系统B，计算平均时间、最长时间和最短时间。

5.9.6 Hypervisor 的资源开销（CPU/GPU）比率

按照 6.9.6的试验方法，在不开启安全机制且空载条件下，计算车载操作系统多系统架构中 Hypervisor的资源开销（CPU/GPU）比率，计算出该比率为0.80到1.00之间，值越大性能越好。

5.9.7 可信执行环境的性能要求

5.9.7.1 CPU 性能

按照6.9.7.1中的试验方法，可信执行环境的性能指标如下： 1）单核情况下TEE下CPU性能较REE下CPU性能损耗百分比，值越小性能越好；

2）多核情况下TEE下CPU性能较REE下CPU性能损耗百分比，值越小性能越好。

5.9.7.2 内存性能

按照6.9.7.2中的试验方法，计算TEE侧的内存性能较REE侧内存性能损耗百分比，值越小性能越好。

5.9.7.3 存储读写性能

按照6.9.7.3中的试验方法，计算TEE的存储读写与REE的存储读写比率，值越小性能越好。

5.9.7.4 加解密性能

按照6.9.7.4中的试验方法，针对不同的加解密方法，可信执行环境的加解密性能指标如下： 1）对于对称算法，TEE侧加解密性能较REE侧性能损耗百分比，值越小性能越好；

2）对于非对称算法，TEE侧生成密钥对的性能较REE侧性能损耗百分比，值越小性能越好，加密、解密的性能较REE性能损耗百分比，值越小性能越好。

3）对于摘要算法，TEE侧性能较REE侧性能损耗百分比，值越小性能越好。

5.9.7.5 通信性能

按照6.9.7.5中的试验方法，TEE的通信性能指标如下： 1）TA与TA通信时间和TA与CA通信时间，值越小性能越好；

2）TEE应具备通道并发能力，支持多CA同时调用多TA完成一个完整可信任务。

5.10 信息安全

5.10.1 通用安全

5.10.1.1 系统安全

按照6.10.1.1的试验方法，车载操作系统的系统安全应满足以下要求： a) 系统用户管理要求

1) 禁止特权用户（如 root 用户）直接登录，应限制登录用户的权限；

2) 应区分不同角色的账号使用的权限，宜实施基于账号的访问控制；

3) 系统内不应存在开发账号和测试账号，应删除非必要的账号；

4) 通过对不成功的鉴别尝试的值（包括尝试次数和时间的阈值）进行预先定义，并明确规定达到该值时采取的措施来实现鉴别失败的处理；

5) 特权用户（如串口 root 身份）身份验证应至少支持口令鉴别、基于令牌的动态口令、生物特征识别(刷脸、声纹或虹膜等)、数字证书鉴别等多种方式中的一种，并在访问安全功能相关的操作之前进行鉴别。

b）系统服务管理要求

1) 操作系统应对关键资源实施强制访问控制（MAC）。应用程序只能获得所需的最低权限。

· 应用级程序需配置为最小访问权限；

· 系统级程序应配置有限的访问权限；

· 接口资源访问（如：WLAN、蓝牙、USB 等接口）的程序应配置最小访问权限；

2) 操作系统应对关键资源实施自主访问控制（DAC）。应对文件和可执行文件的访问进行管理和审计，以保护文件和进程免受未经授权的访问和操作；

3) 操作系统应关闭不必要的系统服务，如非必要的 FTP、Telnet、SSH 等；

4) 操作系统的正式版本中不应存在为开发和调试阶段使用的服务。 c) 系统安全启动要求

1）车载操作系统应支持基于硬件信任根的安全启动，硬件信任根应是可信任的、物理上无法篡改

的；

2）应使用基于信任根的校验机制对根证书的合法性（如公钥的完整性）进行校验；

3）对相关镜像的签名验签应采用国家密码相关机构评估推荐的算法，应遵循密码相关国家标准和

行业标准。

4）车载操作系统应支持基于安全 BootLoader 的安全启动。安全 BootLoader 可支持防漏洞设计，包括但不限于栈保护、数据不可执行。

d) 系统漏洞管理要求

操作系统镜像中，不应存在由权威漏洞平台 6 个月前公布且未经处置的高危及以上的安全漏洞。安全漏洞信息披露平台和机构参考 CVE、CNVD、CNNVD、CNCVE 等。

e) 软件升级安全要求车载操作系统应支持在线更新能力，并验证更新包的真实性和完整性；在执行软件升级后，应告

知车辆用户升级的结果。 f) 系统内核加固

车载操作系统内核宜采用安全加固机制进行保护，如PXN、PAN、KASLR、控制流完整性保护、 RODATA、RO SYSCALL Table、页表完整性保护等安全加固机制；

g) 针对包含只读数据的存储分区，系统应采用一种机制来对数据进行块级或文件级完整性保护；

h) 针对包含读写数据的存储分区，系统应采用对数据进行块级或文件级的完整性保护机制和加密保护机制。

i) 车载操作系统宜对内核进行完整性保护。 j）车载操作系统应限制进程可执行的系统调用范围，限制进程的特权范围，内核应支持强制访问控

制，如 SElinux。

k）应提供常见的入侵检测功能，支持针对特定端口或 IP 的访问控制。 l) 应支持地址空间布局随机化机制(ASLR)。 m）应支持可执行空间保护。 n）应支持堆栈保护:“堆栈粉碎保护”或“堆栈保护器”编译器技术。 o) 应支持编译时缓冲区溢出检查。

5.10.1.2 数据安全

按照6.10.1.2的试验方法，车载操作系统的数据安全应满足以下要求： 1) 当应用调用数据采集服务时，系统应明确告知用户采集的目的和范围；

2) 当应用获取用户敏感个人信息时，汽车数据处理者应依据授权同意范围处理个人信息，若超出授权同意范围，应重新提出授权同意申请；当授权同意期限届满时，若汽车数据处理者仍需要继续进行除删除外的个人信息处理活动，应重新提出个人信息授权同意申请。

3) 应用收集个人信息应限于实现处理目的所必要的最小范围，取得用户的明示同意，特殊情况除外（如紧急呼叫等）。

4) 当系统采集远程控制、远程诊断等功能场景下所发送的指令数据时，系统应确保已获得用户在完全知情的基础上自愿给出的、具体的、清晰明确的授权同意；

5) 如设备或后台需要存储用户数据，则应当告知用户，并获得授权，否则当前用户退出登陆后，系统应默认清空个人数据；如用户授权设备后后台存储用户信息，则需提供直观易用的数据删除选项，以及撤回授权的选项；恢复出厂设置应默认清除用户数据，或提供用户数据是否一并删除的选项。

6) 系统应防止非授权访问用户数据；

7) 在多用户系统中，系统应采用用户间隔离机制，防止用户数据的非授权访问；

8) 当车载操作系统提供用户数据采集功能时，系统应提供用户关闭的功能；

9) 系统应对用户数据操作（包括采集，传输，存储，销毁）的日志进行存储；

10) 敏感个人信息应不以明文传输，应采用加密（例如：SM2、AES（长度不低于 128 位）等算法）存储，宜采用基于硬件保护的安全存储；

11) 系统应使用基于硬件的安全存储生物特征信息，或使用纯硬件的生物特征功能实现；

12) 安全重要参数应支持完整性校验，并应防止丢失和误删除，宜采用备份或专用安全空间存储；

13) 操作系统应指定默认日志等级且可配置。

14) 关键数据为车辆内外部通信及相关业务涉及的数据，包括且不仅限于：通信密钥、车辆数字证书私钥、密码、车辆长期 ID、用户认证的生物特征等个人隐私信息、地图数据、导航数据以及其他关键、敏感信息或数据、系统核心配置文件。对关键数据宜采用加密存储、访问控制、加密传输等机制进行保护。

15) 对于关键数据应考虑覆盖其全生命周期的安全，包括数据的生成、采集、存储、访问、传输、分析、使用、销毁等环节的安全防护。

16) 应遵循车企的隐私声明政策，应符合 GB/T XXXXX《智能网联汽车数据通用要求》中 5.1、

5.2、5.3、5.4、5.5、5.6 的规定，不得超范围采集、传输、存储、使用及共享。

5.10.1.3 通信安全

按照6.10.1.3的试验方法，车载操作系统若具备通信安全能力，其设计应满足以下要求：

1) 系统内宜设置网络通信白名单、黑名单等，保证只有受到系统信任的 URL 可以建立通信链接

（如 Http/以太网/蓝牙等）；

2) 应使用 TLSv1.2(长度不低于 2048 的 RSA 算法或长度不低于 256 的 ECC 算法)及以上版本进行通信，当发送敏感个人信息时，应使用 TLSv1.2 及以上版本进行双向认证。

3) 不宜存在 HTTPS 和 HTTP 混合通信的协议设置，应全部使用 HTTPS 进行；

4) 使用到的随机数应符合随机数相关标准(例如:GM/T 0005 等)，保证由已验证、安全的随机数生成器产生；

5) 使用已验证、安全的参数配置（包括设备身份标识、认证机制、安全通信协议、安全服务类型、安全服务描述、安全服务授权信息、安全服务地址、指定哈希算法、指定加密算法、加密密钥、证书类型、证书签发者、证书有效期、证书有效区域、证书权限范围和应用数据签名权限），应只允许车厂信任的认证机构签发的证书；

6) 网络通信时，应支持对数据内容进行完整性校验；数据内容校验失败时，应终止该响应操作；

7) 网络通信时，应支持对通信双方进行身份鉴权；发生身份鉴权失败时，应终止该响应操作；

8) 操作系统应支持基于 PKI 的证书管理机制和安全协议；

9) 对外部网络与车内网络间进行隔离(如 VLAN 或物理隔离)；

10) 通信宜具备关键事件日志记录能力；

11) 网络通信应对异常报文有感知能力，宜具有告警或其它安全响应的能力。

12) 操作系统不得存在隐蔽端口，开启端口应是系统运行和业务应用所必要的，无用的端口应关闭。

13) 车外网络通信应具备访问控制机制（如防火墙），防止非授权访问。

14) 车内具备安全网络域的隔离（如 vlan）。

15) 防火墙功能要求（征求车厂意见，是否为必选，有 vsoc 的情况下，是否还需要有防火墙功能？）

– 实现对报文的安全过滤，拦截非法数据，避免其进入安全区域。

– 防火墙只允许和预定义的网络进行通信。

-防火墙的相关数据（如拦截数据流量、防火墙故障状态和防火墙规则数量等）应使用安全存储机制，并支持上报或转发其它模块处理的功能。

5.10.2 应用安全

按照6.10.2的试验方法，车载操作系统的应用安全应满足以下要求：

1) 应用应支持防被逆向分析，宜采用地址随机化、代码混淆或加壳等措施；

2) 应用软件安装包应采用签名认证机制，在安装时应校验其真实性和完整性，在应用加载宜验其完整性；

3) 应用在访问、操作和使用系统资源及数据时，应校验其访问权限，宜在访问请求中直接附带应用身份和权限信息，并在服务提供方校验其权限是否足够；

4) 应用间应采用隔离机制，系统宜用不同密钥对不同应用的重要数据进行加密；

5) 系统应当控制应用访问系统调用的权限，不应向应用程序暴露所有的系统调用。

5.10.3 审计安全

1) 按照 6.10.3 的试验方法，车载操作系统满足以下安全审计要求：

2) 宜对安全相关的以下事件生成审计日志：系统运行记录、报警记录、操作日志、网络流量记录、应用软件运行日志、配置信息等；

3) 审计日志的内容至少应包括事件发生的日期、时间、主体标识、事件类型描述和结果(成功或失败）、关联的进程等；

4) 审计日志应能本地存储, 访问本地日志需进行权限管控，本地日志宜加密存储；

5) 确保审计信息的真实性和完整性；

6) 审计日志宜能传输到云端，云端日志应加密存储，不应含有个人信息；

7) 敏感信息审计包括禁用 SU、SUDO 命令；禁止敏感 IP；禁止明文的密钥文件等；

8) 文件系统审计包括文件权限读写配置、分区挂载 rwx 属性配置等；

9) 服务审计包括禁用调试服务、调试驱动等；

10) 应用审计包括开启 Canary 栈溢出保护；隐藏符号表（strip）等。

5.10.4 多系统安全

按照6.10.4的试验方法，车载操作系统若为多系统，除满足之上安全要求之外，还应满足以下安全要求：

1) 多系统安全启动的整体流程具备统一的硬件信任根和完整的信任链，确保多系统代码和数据的完整性和真实性；

2) 多系统域隔离安全应确保多操作系统间的空间隔离（如内存、Cache、外设等）、时间隔离

（如硬实时、时间窗配置等）,多系统域隔离安全应参考 6.1.8 故障注入的试验方法，每个子系统应有针对 DMA 攻击的防范措施;

3) 多系统权限模型应确保虚拟机的每项资源都能够通过独立的权限进行管理，系统中无具备最高等级权限的虚拟机；

4) 应具备多系统间通信身份验证和访问控制的能力；

5) 多系统驱动框架对驱动提供有限防护（例如基于内核安全机制检测、前后端驱动隔离等技术）

6) 多系统应采用系统间隔离机制，防止系统数据的非授权访问。

5.11 功能安全

本标准仅定义车载操作系统特有的要求，整车的功能安全要求两种方式： 1）通过整车功能安全等级来推导ASIL等级

2）模块通过SEooC的方式来确认按照6.11的试验方法，车载操作系统供应商应至少在系统层面进行面向功能安全的技术安全概念

活动，以保障系统在故障条件下，对驾驶员传递满足安全状态的关键信息。车载操作系统供应商应进行安全分析活动，并制订对应的安全措施，以说明系统一旦发生失效,该

系统将如何避免或减轻可能对驾驶员的安全产生影响的危害。安全分析至少包括：

a) 系统层面的安全分析，可采用潜在失效模式与影响分析(FMEA)、故障树分析(FTA)或任何适合系统安全分析的其他类似过程。

b) 应至少考虑如下因素可能导致的危害以开展安全分析： 1) 通讯类故障（显示指令信号）

2) 控制器系统故障

3) 显示屏系统故障

4) 应描述对应的安全措施，确保功能安全需求和目标的达成。车载操作系统供应商应进行安全措施制订，以确保安全概念实现。系统可采取如下安全策略：

a) 关键区域（比如：告警灯和档位信息）维持安全状态，其他区域保持正常功能和性能的显示（比如：3D渲染）；

b) 关键区域（比如：告警灯和档位信息）维持安全状态，其他区域显示性能降级（比如： 2D），并只提供必要信息的显示（比如：车速）；

c) 文字类提示（比如：请去4S店维修）。

车载操作系统可参照GB/T 34590.3的危害分析和风险评估的方法确定ASIL等级要求，所使用的底层安全机制应满足相应的ASIL等级要求。

不同类型的车载操作系统应用场景对车载操作系统的功能安全要求及ASIL等级要求参见附录E。

6 车载操作系统试验方法

6.1 通用试验方法

6.1.1 自动化静态代码扫描

a）试验方法： 1）检查厂商提交的文档，并检查代码的实现情况,分析软件成分清单，包括组件数、许可证数、文件数、代码行数、容量等及各项的详情列表； 2）分析开源成分存在的漏洞风险，包括安全漏洞、高风险许可证、兼容风险等;

3）通过静态代码测试工具，根据代码编程标准检查代码子程序和函数是否采用一个入口和一个出口； 4）通过静态代码测试工具，根据代码编程标准检查代码是否存在动态对象或动态变量，否则需要在其产生过程中对其进行在线测试； 5）通过静态代码测试工具，根据代码编程标准检查代码变量是否初始化；

6）通过静态代码测试工具，根据代码编程标准检查代码是否重复使用变量名称；

7）通过静态代码测试工具，根据代码编程标准检查代码是否限制使用指针；

8）通过静态代码测试工具，根据代码编程标准检查代码是否存在隐式类型转换；

9）通过静态代码测试工具，根据代码编程标准检查代码是否存在隐藏数据流或控制流；

10）通过静态代码测试工具，根据代码编程标准检查代码是否存在无条件跳转；

11）通过静态代码测试工具，使用控制流分析方法检查被测代码的控制结构；

12）通过静态代码测试工具，使用数据流分析方法检查被测代码的差错或异常或代码规范情况。注：方法 2）、3）、5）、6）和 7）可能不适用于在基于模型开发中用到的图形模型标记法。

b）预期结果： 1）被测代码满足厂商提供文档所规定的代码编程,标准获取软件成分清单，符合开源合规性；

2）在检测结果中获取漏洞风险清单，不应存在严重等级高的漏洞;

3）子程序和函数采用一个入口和一个出口；

4）无动态对象或动态变量；

5）变量初始化；

6）不能重复使用变量名称；

7）限制使用指针；

8）无隐式类型转换；

9）无隐藏数据流或控制流；

10）没有无条件跳转；

11）无结构化错；

12）无差错或异常情况或代码规范。 c）结果判定：

上述预期结果都满足判定为符合，其他情况判定为不符合。

6.1.2 代码审计人工复核

a）试验方法： 1）检查厂商提交的文档，并检查代码的实现情况；

2）对自动化静态代码扫描报告进行复核；

3）检查代码和设计的一致性；

4）检查代码执行标准的情况；

5）检查代码逻辑表达的正确性；

6）检查代码结构的合理性；

7）检查代码的可读性。

8）检查代码中与用户信息或软件自身安全密切相关的状态信息没有存储在非授权实体都可以访问的地方；检查代码是否存在被绕过的情况；检查代码中使用的密码相关实现技术是否符合相关规定；应确保访问控制和权限管理得到实现。 9）检查代码中的函数调用安全、异常处理安全、指针安全等。

10）检查代码中是否存在释放资源不当的情况，比如内存的分配、释放函数是否成对调用，内存缓冲区边界操作是否发生越界等。

b）预期结果： 1）代码正确实现功能；

2）自动化静态代码扫描报告满足代码编程标准；

3）代码和设计的满足一致性要求；

4）代码执行标准满足代码编程标准；

5）代码逻辑表达满足正确性要求；

6）代码结构满足合理性要求；

7）代码满足可读性要求。

8）关键状态数据不被外部得知或控制，确保输入的数据都经过净化和验证；数据都进行符合规定的加密和保护；确保访问控制和权限管理的安全。

9）代码实现的安全得以满足。

10）代码中的资源管理满足安全性要求。

c）结果判定：

上述预期结果都满足判定为符合，其他情况判定为不符合。

6.1.3 形式化数学验证

a）试验输入

使用形式化验证方法对系统进行验证需要用户提供如下输入： 1）基于高阶逻辑、谓词逻辑、一阶逻辑等数学描述的系统状态机对象规约；

2）基于高阶逻辑、谓词逻辑、一阶逻辑等数学描述的系统安全属性规约，系统安全属性规约应包含系统不变量，或者使用自动化验证工具时包含的前置条件、后置条件等规约描述； 3）支持形式化验证的验证工具、验证框架、代码生成器等；

4）需要验证的系统代码、通过代码生成工具生成的系统代码、或者人工编写的系统代码；

5）详细的验证过程说明文档；

6）需要验证的系统安全属性，一般为自然语言描述的安全需求。

b）试验方法：

1）基于求精方法进行验证，需要验证不同层上的规约之间的精化关系；

2）验证系统实现代码与规约之间的精化关系；

3）验证系统状态机对象规约满足系统安全属性规约的要求；

4）验证系统前置条件成立时，后置条件的正确性，以及系统不变量在系统状态变化过程中的不变性。

c）预期结果： 1）系统状态机规约的不同层次之间满足精化关系，或不满足精化关系；

2）系统状态机对象规约满足或者不满足系统安全属性规约，若不满足，则给出反例；

3）根据规约系统能够或者无法自动合成实现代码；

4）对已提供的系统代码，系统、框架能够或者不能够验证实现代码与规约之间的对等关系。 d）结果判定：

1）系统状态机规约的不同层次之间满足精化关系，或不满足精化关系，验证工具给出推理结果或者验证反例； 2）系统状态机规约满足或者不满足系统安全属性规约，包含前置条件能够或无法推导出后置条件，系统状态机规约满足或不满足系统不变量要求； 3）通过系统规约自动或者手动输出系统代码；

4）已提供的代码与系统状态机形式化规约满足等价关系。如果不满足等价关系，需要给出反例或者提示信息。

6.1.4 二进制代码检测

a）试验方法： 1）使用二进制代码检测工具，识别二进制代码中包含的开源组件版本信息、用户名密码等敏

感信息、加密算法、CVE/CNNVD 漏洞。 b）预期结果：

1）检测结果中不包含与测试模块相关的 CVE 及 CNNVD 发布超过 6 个月的 CVSS 3 评分 7.0 及以上的高危漏洞；

2）检测结果中不包含与测试模块相关的明文用户名及密码信息；

3）检测结果中不包含与测试模块相关的如 MD5、RC4 等弱加密算法。 c）结果判定：

1）上述预期结果都满足判定为符合；

2）其他情况判定为不符合。

6.1.5 模糊测试

a）试验方法：

1）对被测程序编译插桩，生成二进制可执行文件；

2）运行被测程序；

3）创建模糊测试项目，启动模糊测试工具；

4）根据初始测试用例进行变异，并输入到被测程序入口；

5）监控被测程序运行状态；

6）发现漏洞问题项，记录并保存。 b）预期结果：

1）待测程序正常执行，无运行异常中断；

2）内存漏洞（内存泄漏、内存溢出）问题项个数≤2个。

c）结果判定：

1）测试正常结束，未发现漏洞问题项或发现漏洞问题项个数≤2 个，判定结果为符合；

2）测试正常结束，发现漏洞问题项个数>2 个，判定结果为不符合。

6.1.6 漏洞扫描

a）试验方法：

1）测试人员用漏洞扫描工具对车载操作系统所在终端进行漏洞扫描。发现并识别测试模块开放的相关端口、服务、厂商、名称及详细版本信息，判断是否存在已知的高危漏洞。 b）预期结果：

漏洞扫描结果中不包含 CVE 及 CNNVD 发布超过 6 个月的 CVSS 3 评分 7.0 及以上信息安全相关的高危漏洞。

c）结果判定：

1）上述预期结果都满足判定为符合；

2）其他情况判定为不符合。

6.1.7 渗透测试

a）试验方法： 1）渗透测试应提供与生产环境相似的仿真环境，以便进行部分可能影响数据完整性及稳定性的侵入式测试，在生产环境中应避免使用可能导致数据完整性及业务稳定性遭受破环的测试手段。 2）应进行网络安全漏洞扫描测试，对目标主机或网络，搜集目标信息，根据搜集到的信息判断或者进一步测试系统是否存在安全漏洞，设定渗透测试范围，如IP段、域名、整站渗透或者部分模块渗透等，针对找到的安全漏洞制定攻击计划，需考虑安全漏洞原理、可利用工具、目标程序检测机制、攻击是否可以绕过防火墙等； 3）应进行主机漏洞扫描测试，从系统用户的角度检测计算机系统的漏洞，包括应用软件、运行的进程、注册表或用户配置等存在的漏洞，通过渗透测试工具等查找存在的安全漏洞； 4）应进行数据库漏洞扫描测试，通过自动扫描和手动输入发现数据库，经授权扫描、非授权扫描、弱口令、渗透攻击等检测方式发现数据库安全隐患，形成修复建议报告提供给用户； 5）可基于网络安全漏洞研究和挖掘的能力构建安全漏洞库，并使用漏洞库进行定向漏洞扫描，漏洞库应及时更新，在一个月内更新完成。

6）在执行攻击计划后，验证是否可达以下目标：

——未发现CVE及CNNVD发布超过6个月的CVSS 3评分7.0及以上信息安全相关的高危漏洞或漏洞已修复无法成功利用；

——获取用户账号密码；

——截取目标程序传输的数据；

——控制目标主机等。 b）预期结果：

攻击操作无法达到既定目标。 c）结果判定：

上述预期结果都满足判定为符合，其他情况判定为不符合。

6.1.8 故障注入测试

a）试验方法：

1）基于厂商软件安全分析识别出的典型故障，通过破坏标定参数、损坏软件接口、损坏变量的值、引入代码突变或损坏 CPU 寄存器的值等方式注入故障到环境模型中或模拟被测模型中，模拟和捕捉系统在故障下的行为。 2）应进行基于硬件的故障注入，对每个子系统开发的驱动进行 DMA 攻击检测，如能通过直接存储器访问物理地址空间并进行刺探和修改，则说明系统没有针对 DMA 攻击的防范措施。

①需要准备一个具备 DMA 功能的设备，例如一块特制的具有 PCI 接口的网卡，该卡上带有 DMA 控制器，从而尝试获取目标系统的物理访问权限。

②通过恶意的驱动程序、固件漏洞、内核提权来尝试获取对 DMA 控制器的控制权限，使用 DMA 控制器将目标系统的内存映射到自己的设备上，尝试直接读取或写入目标系统的内存数据（如密钥、登录凭证等）。

③通过 DMA 控制器直接修改目标系统的内存内容，以执行如注入恶意代码等的恶意操作。最后在完成攻击后尝试清理并恢复修改过的内存数据，并释放对 DMA 控制器的控制权限，观察系统能否防御 DMA 攻击。 3）应进行基于软件的故障注入，使用软件触发器将故障注入正在运行的软件系统。

①例如将错误的数据加载到寄存器中，或者修改寄存器的状态来引入错误。注入错误后，观察系统的响应，记录系统在故障注入情况下的行为和结果。根据测试结果，分析系统在故障注入情况下的表现。评估系统的容错性、错误处理能力和恢复能力。 4）应进行基于仿真的故障注入。在已知相关项功能及故障类型的前提下，通过故障注入仿真在危害分析和风险评估流程中得到某一故障产生的影响，并据此细化安全目标。

①选择基于软件的仿真器、模拟器或虚拟机等来创建虚拟环境，根据已知相关项的主要功能及其故障类型，正确识别功能失效模式，以获得关于其影响的整车层级的数据。

②在对系统进行初步分析后，配置故障注入试验，包括设置试验和驾驶场景，以及生成故障列

表。

③创建故障化被测系统，故障注入器模块根据故障列表的信息及通用故障模型模板，创建故障发生器代码。将故障化被测系统与无故障系统的模拟结果进行比较，分析故障影响，进而导出适当的安全目标及安全要求。

b）预期结果：车载操作系统软件在故障注入（基于软件的故障注入、基于硬件的故障注入、基于仿真的故障注入）后安全机制有效，满足对应的软件安全要求且不包含与功能安全相关的、非预期的功能和特性。

1）无法被进行 DMA 攻击，无法获得 DMA 控制的权限，无法读取或写入系统的内存数据。

2）即使被 DMA 攻击也可以被防护，目标系统不被恶意损坏。

3）正在运行的系统在被故障注入后保持正常运行。

4）在模拟运行场景中，车辆保持可控性、系统功能可以正常运行。 c）结果判定：

上述预期结果都满足判定为符合，其他情况判定为不符合。

6.2 车载操作系统内核

在操作系统中运行包含任务调度、内存管理、进程间通信功能的应用程序，确认程序能够正常工

作。

a）试验方法： 1）在操作系统中同时运行多个程序或反复运行同一个程序，在程序关闭后，确认程序所占用

系统资源是否被完全释放；

2）尝试同时创建并执行一定数量的进程并确保这些进程优先级相同，确认是否所有进程都能够获得时间片；

3）尝试同时创建并执行一定数量的进程并确保这些进程优先级各不相同，确认是否优先级高的进程先被执行；

4）进行多次通信测试，记录每次的响应时间，并计算平均值，验证操作系统进程间通信时效性；

5）检查操作系统内核的内存管理策略，尝试进行内存分配、回收、隔离和共享操作；

6）采用文档审查或采用用户空间驱动的开发工具与接口编写测试代码等方式，验证在微内核设计下，驱动或应用程序崩溃时不影响操作系统正常工作；

7）查阅芯片文档，使用支持指令集的汇编语言，编写一个简单的测试代码，确认芯片是否正确执行指令；

8）连接使用不同文件系统格式（如FAT32、NTFS等）格式化的USB存储设备，确认车载系统是否能够正确识别和访问这些不同格式的USB存储设备并能正常进行读取和写入；

9）审查文档及代码，确认内核是否支持设备驱动程序框架和设备驱动访问控制功能；

10）审查文档及代码，检查内核是否支持至少一类文件系统；

11）审查文档及代码，检查内核是否支持网络协议栈。 b）预期结果：

1）操作系统内核设计包含包含任务调度、内存管理、进程间通信管理三项基础功能；

2）进程生命周期完整，执行后释放资源；

3）同时创建且优先级相同的进程都能获得时间片；

4）进程按照优先级高低依次执行；

5）操作系统内核应能够进行内存分配、回收、隔离和共享；

6）进程间通信的时效性符合设计规范要求。

7）驱动崩溃不会影响到微内核及其他进程；

8）应用程序崩溃不会影响到微内核及其他进程；

9）系统能正确执行芯片的指令集；

10）车载系统能够与多媒体网络USB存储设备进行交互和通信；

11）内核支持设备驱动程序框架；

12）内核支持至少一类文件系统（如EXT3、UFS、FAT32、NFS网络文件系统等）；

13）内核支持网络协议栈。 c）结果判定：

1）微内核应达到上述预期结果中的1）到9），都满足则判定为符合，有一项不符合则判定为不符合； 2）宏内核应达到上述预期结果中除7）8）之外的所有结果，都满足则判定为符合，有一项不符合则判定为不符合。

6.3 资源抽象

6.3.1 硬件抽象（HAL）

a）试验方法

1）审查文档，检查资源抽象的设计；

2）检查是否支持对芯片的资源抽象；

3）检查是否支持对屏幕、摄像头、扬声器、麦克风等的资源抽象，尝试使用车载管理系统获取对应资源，尝试使用硬件接口资源抽象获取数据；

4）检查是否支持对外围IC的资源抽象，检查外围IC（如蓝牙、WLAN、GNSS、FM等）的硬件资源抽象和接口，尝试对这些设备进行访问；

5）检查是否支持对外围存储设备（如U盘、SD卡）的资源抽象，尝试对外围存储设备进行访问。

b）预期结果

1）支持对芯片的资源抽象；

2）支持对屏幕、摄像头、扬声器、麦克风等的资源抽象；

3）支持对外围IC（如蓝牙、WLAN、GNSS、FM等）的资源抽象；

4）支持对外围存储设备（如U盘）的资源抽象。 c）结果判定：

1）达到上述预期结果都满足则判定为符合；

2）达不到上述预期结果，或出现其他情况判定为不符合

6.3.2 整车信号和服务资源抽象

a）试验方法

1）检查是否支持对整车服务资源进行抽象，是否提供基于以太网通信协议的统一数据上行/ 下行接口，尝试利用该接口对空调、座椅、档位、灯等功能进行控制，检查接口功能是否正常。

b）预期结果

1）支持对整车服务资源的抽象。 c）结果判定：

1）达到上述预期结果都满足则判定为符合；

2）达不到上述预期结果，或出现其他情况判定为不符合

6.4 基础库

a）试验方法： 1）审查文档，检查基础库的设计；

2）检查基础库是否有进程间通信库、网络传输库、安全通信库和图像库。

3）检查基础库是否支持常见的加密算法，如AES和RSA等；

4）检查上层应用程序能否方便地调用硬件加解密功能，访问和控制加解密模块。 b）预期结果：

1）设计要求完整准确；

2）有符合设计要求和安全需求的相关基础库。 c）结果判定：

1）达到上述预期结果都满足则判定为符合；

2）达不到上述预期结果，或出现其他情况判定为不符合。

6.5 基础服务

6.5.1 互联服务

互联服务的试验方法如下： a）试验方法

1）搭建实车或台架环境；

2）准备试验工具：市场主流 Android/IOS/HarmonyOS 手机（支持Carplay、Hicar、Carlink、 AndroidAuto等手机有线连接、无线连接、WLAN、蓝牙等），USB数据线，CAN设备，ETC设备，T-BOX；

3）测试车载操作系统与终端通讯功能，USB供网、CAN总线通讯、诊断功能、收音机、ETC功能，以及连接响应性能及压力测试，不同终端、不同连接方式连接的响应时间及稳定性存在差异；

4）测试车载操作系统与终端的连接功能，包括有线连接、无线连接、蓝牙音乐、蓝牙电话、数字蓝牙钥匙、远程车辆控制、远程车况查询、数据采集上传、在线应用、有线/无线投屏，以及连接响应性能及压力测试，不同终端、不同连接方式连接的响应时间及稳定性存在差异；

5）测试网络协议（包含TCP/IP、HTTPS、MQTT等）的信息同步功能，主要体现在系统与设备端数据传输与显示的准确性及时效性。

b）预期结果：

1）车载操作系统与终端互联服务功能正常，连接响应性能及压力测试符合设计规范要求；

2）无线（如WLAN、蓝牙）或有线（如USB）方式与个人移动端、云端互通的功能正常，连接响应性能及压力测试符合设计规范要求；

3）网络协议（例如TCP/IP、HTTPS、MQTT等）符合设计规范要求。 c）结果判定：

上述预期结果都满足判定为符合，其他情况判定为不符合。

6.5.2 地图及定位服务

地图及定位服务的试验方法为： a）试验方法：

1）搭建实车环境，可正常收取GPS信号及网络信号；

2）准备测试电脑，测试手机，测试手机下载OEM APP及第三方应用；

3）车载系统安装导航地图软件，安装GPS、陀螺仪信息记录软件。OEM APP及第三方应用绑定车机系统账号；

4）进行行车路试，测试路线包含：普通道路、长隧道、立交、高架下、地下车库、高大建筑密集区、高速连续出口、主辅路等，查看记录软件实时显示的卫星定位、陀螺仪定位数据信息；

5）依据相关设计文档，测试车载操作系统定位服务功能，包括地图在内的各类应用程序获取的位置信息，如导航引导定位，天气应用位置，移动端APP远程车况查询、导航到车、第三方应用发送位置到车等；

6）符合汽车数据通用要求开展测试，引用相关标准。 b）预期结果：

1）卫星及陀螺仪定位数据正常；

2）定位服务功能正常，地图定位及各类应用程序获取的位置信息准确。 c）结果判定：

上述预期结果都满足判定为符合，其他情况判定为不符合。

6.5.3 语音服务

语音服务的试验方法如下： a）试验方法：

1）审查语音服务相关设计文档，确认车载操作系统支持语音服务，如声学前端、语音识别、语音合成、语音声纹、语义理解、对话管理、语义生成、语音自学习、语音交互展示等功能；

2）搭建实车或台架环境，麦克风及扬声器功能正常，车端或台架网络正常；

3）按照语音服务文档规定，通过实车或台架验证在各种工况下（静态、城市、高速工况等）的功能是否正常。

b）预期结果： 1）确认语音服务设计规范包含车载操作系统语音服务功能，包括声学前端、语音识别、语音

合成、语音声纹、语义理解、对话管理、语义生成、语音自学习、语音交互展示等功能。 2）语音服务功能完整，语音唤醒率、识别率、误识别率、响应速度等都符合设计规范要求。

c）结果判定：上述预期结果都满足判定为符合，其他情况判定为不符合。

6.5.4 多媒体服务

多媒体服务的试验方法如下：依据相关设计文档，确认车载操作系统支持的U盘格式，音视频格式、图片/视频分辨率，音频音

质，及多媒体音源。 a）试验方法：

1）搭建实车或台架环境，USB线连接正常，车端或台架网络正常；

2）准备不同格式U盘，选择音源播放来源（蓝牙音乐、U盘音乐、在线音频、U盘视频、在线视频）；

3）准备不同格式的图像、音频文件、视频文件；

4）准备不同分辨率图像、不同音质音频、不同分辨率视频文件；

5）采用步骤1的提供的U盘设备及音源，对步骤2、步骤3的文件按进行播放控制测试，测试车载操作系统对不同格式的图像、音频、视频的兼容能力验证其编解码功能；观察播放质量

（噪音、帧率、音质、流畅度、清晰度、音视频同步等）； 6）播放时系统后台查看播放资源占用数据，包含网络带宽及CPU占用。

b）预期结果： 1）车载操作系统对不同格式的图像、音频、视频的播放控制功能正常；

2）播放质量（噪音、帧率、音质、流畅度、清晰度、音视频同步等）和播放资源占用（网络带宽、CPU占用）两项指标都符合设计规范要求。

c）结果判定：上述预期结果都满足判定为符合，其他情况判定为不符合。

6.5.5 软件升级服务

软件升级服务的试验方法如下： a）实验步骤：

1）审查软件升级服务相关设计文档，确认车载操作系统是否支持软件升级服务，如OTA升级功能；

2）搭建实车或台架环境，车端或台架网络正常；

3）云端配置车辆或台架数据环境；

4）云端上传升级包；

5）云端发布升级任务，推送至车端或台架；

6）通过实车或台架验证设计文档中规定的软件升级功能是否正常，检查是否升级成功。 b）预期结果：

1）确认软件升级服务设计规范包含车载操作系统软件升级服务功能，如OTA升级功能；

2）软件升级后功能完整，软件下载、安装时间等符合设计规范要求。 c）结果判定：

上述预期结果都满足判定为符合，其他情况判定为不符合。

6.5.6 账号服务

账号服务的试验方法如下： a）试验步骤：

1）审查账号服务相关设计文档，确认车载操作系统是否支持账号服务，如账号分类、系统账号基础服务、系统账号与OEM账号、系统账号与第三方账号、多账号管理功能；

2）搭建实车或台架环境，车端或台架网络正常；

3）准备测试手机，并下载OEM APP、第三方应用；

4）不登陆OEM账号使用游客账号，使用OEM APP绑定及解绑OEM车主账号，OEM车主账号授权及解除非车主账号；

5）系统账号绑定及解绑；

6）第三方应用账号登录及退登；

7）OEM账号绑定系统账号，注销OEM账号或系统账号；

8）驻车及非驻车状态下，退出OEM账号；

9）多车登录同一OEM账号，多车登录同一系统账号；

10）使用第三方应用账号绑定及解绑系统账号；

11）第三方应用绑定系统账号，登录与退出系统账号，检查第三方应用账号登录状态；

12）系统账号与第三方账号绑定，同一系统账号多端登录，检查第三方应用账号登录状态；

13）切换系统账号，检查账号下用户数据；

14）通过实车或台架验证设计文档中规定的账号功能是否正常。 b）预期结果：

1）确认账号服务设计规范包含车载操作系统账号服务功能，如账号分类、系统账号基础服务、系统账号与OEM账号、系统账号与第三方账号、多账号管理功能；

2）账号服务功能完整，符合设计规范要求。 c）结果判定：

上述预期结果都满足判定为符合，其他情况判定为不符合。

6.5.7 驾驶提示服务

a）试验方法： 1）审查驾驶提示服务相关设计文档，确认车载操作系统支持驾驶提示服务，如控制器异常、

油箱告警、电量告警、胎压告警、360环视、倒车影像、盲区提示、压线提示、透明底盘、轮胎轨迹线提示等；

2）搭建实车或台架环境，通过实车或台架验证驾驶提示服务文档规定的功能。 b）预期结果：

1）驾驶提示服务设计文档包含了车载操作系统驾驶提示服务功能，包括控制器异常、油箱告警、电量告警、胎压告警、360环视、倒车影像、盲区提示、压线提示、透明底盘、轮胎轨迹线提示等；

2）驾驶提示服务功能完整，响应时机合理准确，画面显示清晰、流畅稳定。 c）结果判定：

上述预期结果都满足为判定符合，其它情况为判定不符合。

6.5.8 车辆设置服务

车辆设置服务的试验方法如下： a）试验方法：

3）审查车辆设置服务相关设计文档，确认车载操作系统应支持车辆设置服务，如空调策略、电源策略、时间策略、亮度策略和车窗开启策略等，可支持智能车辆设置，如结合车辆传感器和预设的配置文件，智能设置电源策略、时间策略、亮度策略和车窗开启策略等；

4）搭建实车或台架环境，通过实车/台架验证车辆设置服务文档规定的功能。 b）预期结果：

3）车辆设置服务设计文档包含了车载操作系统车辆设置服务功能，包括空调策略、电源策略、时间策略、亮度策略和车窗开启策略等，可支持智能车辆设置，如结合车辆传感器和预设的配置文件，智能设置电源策略、时间策略、亮度策略和车窗开启策略等；

4）车辆设置服务功能完整，响应时机合理准确。 c）结果判定：

上述预期结果都满足为判定符合，其它情况为判定不符合。

6.5.9 增强的人机交互服务

增强的人机交互服务的试验方法如下： a）试验方法：

1）审查增强的人机交互服务相关设计文档，确认车载操作系统提供AR导航、车外视觉辅助驾驶类（如盲区检测、行人提醒，斑马线提醒，前车起步/溜车提醒、前车距离提醒、压线违章提醒、车道偏离提醒等）、车内视觉安全驾驶类（如疲劳驾驶，FaceID，手势识别、人脸/摄像头遮挡识别、分心识别等）等人机交互和人工智能服务；

2）搭建实车环境，通过实车验证增强的人机交互服务文档规定的功能。 b）预期结果：

1）增强的人机交互服务设计文档包含了车载操作系统提供AR导航、车外视觉辅助驾驶类（如盲区检测、行人提醒，斑马线提醒，前车起步/溜车提醒、前车距离提醒、压线违章提醒、车道偏离提醒等）、车内视觉安全驾驶类（如疲劳驾驶，FaceID，手势识别、人脸/摄像头遮挡识别、分心识别等）等人机交互和人工智能服务；

2）增强的人机交互服务功能完整，响应时机合理准确，系统流畅稳定。 c）结果判定：

上述预期结果都满足为判定符合，其它情况为判定不符合。

6.5.10 显示功能

a）试验方法： 1）审查车载操作系统支持显示功能相关设计文档，确认车载操作系统应支持仪表显示、OMS显

示，可支持行车记录仪、DMS、多屏幕显示； 2）搭建实车或台架环境，通过实车或台架验证车载操作系统支持显示功能文档规定的功能。

b）预期结果：

3）车载操作系统支持显示功能设计文档包含了应支持仪表显示、OMS显示，可支持行车记录仪、 DMS、多屏幕显示；

4）车载操作系统支持显示功能完整，响应时机合理准确，画面显示清晰、流畅稳定。 c）结果判定：

上述预期结果都满足为判定符合，其它情况为判定不符合

6.6 程序运行框架

6.6.1 互联互通框架

a）试验方法： 1）查阅接口文档，检查是否支持按照不同的接口类型接入WLAN、蓝牙等车载设备。检查接口

类型是否包括设备发现，快速接入，服务发现，协议校验，语音控制，在线升级，流量代理；

2）根据接口文档，编写应用程序调用互联互通框架功能接口，给接口传入给定的参数，使接口执行预期的功能，或使用企业推荐使用的应用程序或方法验证该功能（普适性）。

b）预期结果： 1）支持按照不同的接口类型接入WLAN、蓝牙等车载设备。接口类型包括设备发现，快速接入，

服务发现，协议校验，语音控制，在线升级，流量代理； 2）接口返回值正确，接口调用过程中未发生系统或者程序异常。

c）结果判定：上述预期结果都满足判定为符合，其他情况判定为不符合。

6.6.2 服务融合框架

a）试验方法： 1）查阅接口文档，检查是否能够提供服务的注册、发现、服务方法的调用、服务数据的订阅

和发布、服务安全调用、服务调用并发数、异常调用时返回错误码、调用超时机制等；是否支持不同类型的服务组合成为新的服务或者应用；

2）根据接口文档，编写应用程序调用服务融合框架功能接口，给接口传入给定的参数，使接口执行预期的功能。

b）预期结果： 1）提供服务的注册、发现、服务方法的调用、服务数据的订阅和发布、服务安全调用、服务

调用并发数、异常调用时返回错误码、调用超时机制；支持不同类型的服务组合成为新的服务或者应用；

2）接口返回值正确，接口调用过程中未发生系统或者程序异常。 c）结果判定：

上述预期结果都满足判定为符合，其他情况判定为不符合。

6.6.3 多媒体框架

a）试验方法： 1）查阅接口文档，检查是否包括音频输入输出与合成、预处理（如回声消除，滤波，去噪），

后处理（如均衡、重低音、立体音效）等增强模块，以及基础的多媒体编解码服务； 2）根据接口文档，编写应用程序调用多媒体框架功能接口，给接口传入给定的参数，使接口

执行预期的功能。 b）预期结果：

1）包括音频输入输出与合成、预处理（如回声消除，滤波，去噪），后处理（如均衡、重低音、立体音效）等增强模块，以及基础的多媒体编解码服务；

2）接口返回值正确，接口调用过程中未发生系统或者程序异常。 c）结果判定：

上述预期结果都满足判定为符合，其他情况判定为不符合。

6.6.4 多模态交互框架

a）试验方法： 1）若车载操作系统支持多模态交互框架，查阅接口文档，检查是否支持至少两种交互框架

（如语音、视觉、手势、触摸屏，按键等），应用程序是否可选择接入一种或者同时接入多种方式来提供交互（如抬头显示、虚拟导航、通过手势来接听或者挂断电话等）；

2）根据接口文档，编写应用程序调用多模态交互框架功能接口，给接口传入给定的参数，使接口执行预期的功能。

b）预期结果： 1）提供至少两种交互框架（如语音、视觉、隔空手势、触摸屏，按键等），应用程序可选择

接入一种或者同时接入多种方式来提供交互（如AR-HUD、语音指令响应、通过隔空手势来接听或者挂断电话等）；

2）接口返回值正确，接口调用过程中未发生系统或者程序异常。 c）结果判定：

上述预期结果都满足判定为符合，其他情况判定为不符合。

6.6.5 场景感知理解框架

a）试验方法： 1）查阅接口文档，检查是否支持根据场景规则或者机器学习模型提供计算和理解当前场景的

功能，是否可订阅场景感知理解框架的输出信号来执行动作或者推送服务； 2）根据接口文档，编写应用程序调用场景感知理解框架功能接口，给接口传入给定的参数，

使接口执行预期的功能。 b）预期结果：

1）支持根据场景规则或者机器学习模型提供计算和理解当前场景的功能，可订阅场景感知理解框架的输出信号来执行动作或者推送服务；

2）接口返回值正确，接口调用过程中未发生系统或者程序异常。 c）结果判定：

上述预期结果都满足判定为符合，其他情况判定为不符合。

6.6.6 用户界面框架

a）试验方法： 1）查阅接口文档，检查是否支持供窗口、界面元素和动画的编程接口及界面资源管理（贴图、

多语言文本等），是否提供接口供三方渲染引擎绘制界面，是否支持2D或3D渲染； 2）根据接口文档，编写应用程序调用用户界面框架功能接口，给接口传入给定的参数，使接

口执行预期的功能。 b）预期结果：

1）支持供窗口、界面元素和动画的编程接口及界面资源管理（贴图、多语言文本等），支持提供接口供三方渲染引擎绘制界面，支持2D或3D渲染；

2）接口返回值正确，接口调用过程中未发生系统或者程序异常。

c）结果判定：上述预期结果都满足判定为符合，其他情况判定为不符合。

6.7 多系统

6.7.1 通用要求

a）试验方法： 1）检查车载操作系统所支持的多系统方案。

b）预期结果 1）在基于硬件隔离的多系统、基于虚拟机管理器的多系统、基于容器的多系统这三种多系统方案中，车载操作系统应支持其中至少一种。

c）结果判定： 1）达到上述预期结果都满足则判定为符合；

2）达不到上述预期结果，或出现其他情况判定为不符合。

6.7.2 基于硬件隔离的多系统

基于硬件隔离的多系统试验方法如下： a）试验方法：

1）审查硬件规格文档，确认是否提供了硬件强制隔离功能；

2）尝试将资源划分为与不同执行环境关联的不同所有权组，确认系统支持该操作且能够成功完成划分；

3）尝试在硬件资源（如SoC外围设备，内存区域和引脚等）所在分区，操作此硬件资源；尝试在其他分区对此硬件资源进行操作；

4）尝试由所有者进行与资源访问权限相关的操作，确认所有者拥有所属资源的访问权限，确认所有者能够查看资源的访问权限，能够修改访问权限。

5）尝试设置安全强相关应用和安全弱相关应用，确认应用可划分为安全强相关应用和安全弱相关应用确认；

6）尝试分配硬件归属于安全强相关应用或安全弱相关应用，确认系统支持该操作；

7）设定安全强相关应用（主要用于运行仪表，倒车影像，提前输出声音和错误处理等应用）和安全弱相关应用（主要用于应用负载，如多媒体应用等），启动多系统，确认不同应用启动的顺序，确认安全强相关应用支持快速启动；

8）设定安全弱相关应用，确认应用是否支持运行安全弱相关应用负载，如多媒体应用等；

9）运行多个（至少两个）安全弱相关应用，并同时并行访问同一硬件资源，确认操作是否能够成功。

b）预期结果： 1）硬件为多系统提供了强制隔离；

2）资源可以被划分到不同的权限组中，且权限组可以和执行环境关联；

3）硬件资源所属分区具备对该资源的访问和管理权限，其他分区不被允许对该资源进行操作。

4）系统提供权限配置功能，并允许所有者对资源的访问权限配置；

5）支持预先分配硬件归属于安全强相关应用或安全弱相关应用；

6）安全强相关应用支持快速启动；

7）安全弱相关应用支持运行安全弱相关应用负载，如多媒体应用等；

8）可支持同时并行访问同一硬件资源。 c）结果判定：

1）达到上述预期结果都满足则判定为符合；

2）达不到上述预期结果，或出现其他情况判定为不符合。

6.7.3 基于虚拟机管理器的多系统

基于虚拟机管理器的多系统试验方法如下： a）试验方法：

1）审查设计文档，确认虚拟机管理器具备管理硬件和外设资源的能力；

2）创建多个系统（至少两个），通过操作系统提供的命令或工具查看系统中的硬件资源的分配情况是否与设计文档一致，以验证是否已经将硬件资源分配给多个系统；更改虚拟机配置或重新编译，查看硬件资源能否被成功分配；通过执行并发使用测试、性能测试以及进行资源监控，检查被多个系统共享的硬件资源，是否可被多个系统成功共享；

3）创建多个系统（至少两个），通过操作系统提供的命令或工具查看系统中的外设资源的分配情况是否与设计文档一致，以验证是否已经将外设资源分配给这些系统；检查外设资源是否是通过虚拟机管理而非直接访问；通过执行并发使用测试、性能测试以及进行资源监控，检查被多个系统共享的外设资源，是否可被多个系统成功共享;

4）车载操作系统单系统尝试访问虚拟机管理器为其他操作系统的分配的资源；

5）在低安全级别虚拟机中编写测试程序通过DMA方式映射并访问高安全级别虚拟机所使用的物理地址，确认映射和访问不能够成功。

6）在低安全级别虚拟机中编写测试程序，对GPU等复杂有状态驱动进行故障注入（如reset 等），确保高安全级别虚拟机不会收到任何影响。

7）为两个系统设置共享数据，编写测试程序，尝试两个系统访问共享数据，确认共享数据能够正常访问；尝试第三方访问共享数据，确认共享数据不能够被第三方访问；

8）为不同操作系统分配不同的优先级，确认虚拟机管理器能够优先处理高优先级系统发出的请求；

9）编写测试程序，尝试对操作系统执行启动、运行、关闭、重启、异常退出等操作，确认虚拟机管理器能够管理各操作系统的生命周期；

10）创建多个系统并使用此多系统完成多项操作，确认在操作过程中各软件运行流畅无卡顿，确认Hypervisor低性能损耗。

11）根据文档并使用此多系统，确认多系统提供全局电源管理。

12）为两个系统设置共享外设，编写测试程序，尝试让两个系统访问共享外设，确保在任何时刻只有一个虚拟机能够成功访问该外设；尝试让两个系统访问共享外设，确认共享外设不能够同时访问。

b）预期结果： 1）虚拟机管理器具备硬件资源和外设资源分配和共享能力（静态或动态）；

2）运行在相同硬件上的操作系统之间实现隔离，并且不能访问未提供给自身的资源；

3）多操作系统之间能正常通信；

4）多系统间能够安全的共享数据，多系统在任何时刻只有一个虚拟机能够成功访问共享外设；

5）虚拟机管理器能够管理各操作系统优先级，实现自适应分配最大化利用硬件资源，并满足对时间敏感需求和系统服务质量的要求；

6）虚拟机管理器能管理各操作系统生命周期，包括启动、运行、关闭、重启、异常退出等状态；

7）Hypervisor的存在应保证其低性能损耗，不应对各操作系统性能产生显著影响；

8）多系统具备全局的电源管理，比如睡眠、唤醒等功能。

c）结果判定： 1）达到上述预期结果都满足则判定为符合；

2）达不到上述预期结果，或出现其他情况判定为不符合。

6.7.4 基于容器的多系统

基于容器的多系统试验方法如下： a）试验方法：

1）审查文档，确认多个车载操作系统单系统中的非内核部分是否运行在基于内核（如Linux等）的资源隔离管理框架之上；

2）审查不同容器之间是否能相互访问对方的文件系统；

3）检查某容器中的测试程序是否可以访问其他容器的进程，以及此容器是否能访问其他容器中的进程；

4）创建多个容器，检查每个容器的网络协议栈（包括网络设备接口，IPv4和IPv6协议栈，IP 路由表，防火墙规则及sockets等）是否是独立的；

5）根据文档，测试资源隔离管理框架是否具备容器创建、启动、关闭及状态查询等管理能力；

6）编写测试程序，观察系统能否系统能够将不同的应用程序或进程的根文件系统路径进行隔离，用户在系统中具有不同的权限和访问控制，不同的网络连接无法直接通信，系统能够将不同的进程间通信进行隔离；

7）尝试查看CPU和内存资源的配额情况，确认系统提供相关操作，尝试修改CPU和内存资源的配额情况，确认修改操作能够成功；

8）编写程序，尝试在容器间及容器和Host间进行通信，确认基于容器的多系统支持容器间及容器和Host间的通信机制；

9）创建多个容器，检查不同的容器或应用程序的存储空间的状态，它们在文件系统层面上是否是相互隔离的；

10）编写测试程序，尝试在一个容器中制造异常（异常退出或进程异常），确认此容器的异常不会影响其他容器正常运行；

11）编写程序，尝试不同容器分配共享外设，确认容器能够使用共享的外设，尝试为容器分配独占外设，确认容器能够访问该独占外设，且其他容器不能访问该独占的外设。

b）预期结果： 1）多个车载操作系统单系统中的非内核部分运行在基于内核（如Linux等）的资源隔离管理框

架之上； 2）容器间支持文件系统隔离，不同容器之间不能彼此访问对方的文件系统；

3）测试容器中运行的程序无法访问其他容器内的进程，此容器本身也无法访问其他容器中的进程；

4）容器间支持网络隔离，每个容器具备完全独立的网络协议栈；

5）支持内核资源隔离，不同内核资源不能互相访问；

6）资源隔离管理框架具备容器创建、启动、关闭及状态查询等管理能力；

7）资源隔离管理框架具备CPU/内存资源的共享调度和配额管理能力；

8）基于容器的多系统支持容器间及容器和Host间的通信机制；

9）基于容器的多系统支持每个容器有独立的根文件系统；

10）一个容器的异常不会影响其他容器正常运行；

11）资源隔离管理框架支持外设共享技术，可配置多个容器对于外设的共享或独占能力。 c）结果判定：

1）达到上述预期结果都满足则判定为符合；

2）达不到上述预期结果，或出现其他情况判定为不符合。

6.8 可信执行环境

6.8.1 基础要求

6.8.1.1 可信根

根据GB_T 41388-2022《信息安全技术可信执行环境基本安全规范按照》中13.1.2的规定,可信外设的测试评价方法如下。

a）试验方法： 1）审查可信执行环境的可信根设计；

2）检查可信执行环境系统的安全鉴证、安全度量和安全存储过程,验证可信根是否提供了机密性、完整性、真实性等安全特性； 3）尝试使用未经授权的用户访问和篡改可信根的数据和代码,验证访问控制机制是否有效。

b）预期结果： 1）可信根具备机密性、完整性、真实性三个基本安全特性，为可信执行环境系统的安全鉴证安全度量和安全存储提供支持； 2）可信根具备访问控制机制，保证未经授权的用户不能访问和篡改可信根的数据和代码。

c）结果判定：上述预期结果都满足判定为符合，其他情况判定为不符合。

6.8.1.2 安全启动

根据GB_T 41388-2022《信息安全技术可信执行环境基本安全规范按照》中13.1.3的规定,可信外设的测试评价方法如下。

a）试验方法： 1）审查可信执行环境系统的安全启动过程；

2）检查安全启动过程用于完整性和真实性验证的加解密算法不存在已公开脆弱性；

3）尝试替换或篡改可信根,验证安全启动是否正常执行；

4）检查用于完整性和真实性验证密钥的更新和撤销机制，尝试非授权替换或篡改相应密钥，验证安全启动是否正常执行；

5）尝试绕过安全启动信任链的逐级验证过程。

6）尝试进行代码防回滚操作，观察系统是否存在未进行身份验证和授权的非法用户能访问和管理旧版本代码。

b）预期结果： 1）安全启动过程保证可信执行环境系统的完整性和真实性，防止非授权或被恶意篡改的代码被执行；

2）安全启动过程保证用于完整性和真实性验证的密码算法本身的鲁棒性；

3）安全启动过程保证可信根不可被替换或篡改；

4）安全启动过程保证用于进行代码完整性和真实性验证的密钥不可被非授权替换或篡改，并提供安全的密钥更新、撤销功能；

5）安全启动信任链按序逐级验证，不可被恶意绕过。

6）系统不可进行代码回滚操作，用户不可管理旧版本代码。 c）结果判定：

上述预期结果都满足判定为符合，其他情况判定为不符合。

6.8.2 可信操作系统

6.8.2.1 业务功能

根据GB_T 41388-2022《信息安全技术可信执行环境基本安全规范按照》中13.3的规定,业务功能试验方法如下：

a）试验方法：

1）审查厂商提交的文档,检查可信操作系统的设计；

2）检查可信操作系统的进程管理功能，尝试创建与销毁进程，验证进程权限是否能被正确设置和限制，检查进程资源是否按策略分配，测试进程间通信机制的安全性； 3）检查可信操作系统的内存管理功能，尝试分配与回收内存，验证内存隔离机制，验证内存加解密的有效性； 4）检查可信操作系统的设备管理功能，检查设备驱动程序是否存在安全漏洞，验证设备访问权限控制是否有效，测试设备I/O操作是否按预期进行； 5）检查可信操作系统的文件管理功能；检查文件权限设置是否得到严格执行，验证文件内容是否会在未经授权的情况下被篡改； 6）检查可信操作系统的日志管理功能，检查是否重要的系统操作都能被记录，验证日志记录是否可能被篡改； 7）检查可信操作系统的访问控制策略,尝试使用可信应用及可信服务分别访问策略所允许和不允许访问的资源,验证策略是否有效； 8）检查可信应用之间、可信应用与可信服务之间的访问控制策略,尝试使用可信应用及可信服务分别访问策略所允许和不允许访问的可信应用和可信服务,验证策略是否有效。

b）预期结果： 1）可信操作系统具备常规操作系统中的进程管理、内存管理、设备管理、文件管理等基本系统功能； 2）可信操作系统保证可信应用及可信服务仅根据其所分配的权限访问相应的资源,不能越权访问；

3）可信应用之间、可信应用与可信服务之间具备访问控制能力。 c）结果判定：

上述预期结果都满足判定为符合，其他情况判定为不符合。

6.8.2.2 安全功能

根据GB_T 41388-2022《信息安全技术可信执行环境基本安全规范按照》中13.3的规定,安全功能试验方法如下：

a）试验方法： 1）检查可信操作系统自身、可信服务与应用启动过程,尝试篡改启动代码和绕过完整性校验过程； 2）检查可信操作系统自身、可信服务与应用数据和代码的真实性和完整性保护机制，尝试篡改相应数据和代码； 3）检查可信操作系统内部可信服务与可信应用的权限设置,验证是否赋予可信服务与可信应用最高权限；

4）尝试在可信应用中不断申请内存，验证可信操作系统是否有内存限制；

5）尝试制造驱动崩溃，验证可信操作系统是否会因驱动崩溃而产生内核崩溃。 b）预期结果：

1）可信操作系统保证系统自身、可信服务与应用启动的正确性与完整性；

2）可信操作系统保证系统自身、可信服务与应用数据和代码的真实性和完整性；

3）可信操作系统的系统权限管理不会赋予可信服务与应用最高权限，单一可信应用与服务出现崩溃或安全问题时不会影响系统内核及其他可信应用与服务的正常工作； 4）可信操作系统应具备内存限制，避免应用申请内存超过堆空间大小而引起操作系统崩溃；

5）可信操作系统应确保驱动崩溃不会影响到整个操作系统。 c）结果判定：

上述预期结果都满足判定为符合，其他情况判定为不符合。

6.8.3 可信应用与服务管理

6.8.3.1 互信过程

根据GB_T 41388-2022《信息安全技术可信执行环境基本安全规范按照》中13.4.1的规定,互信过程试验方法如下：

a）试验方法： 1）审查可信应用与服务的管理机制；

2）执行可信应用与服务的管理操作，检查操作过程中设备提供商(或授权服务商)、可信应用提供商、可信应用运营商的互信是否基于设备根证书、应用发布证书进行认证。

b）预期结果： 1）可信应用及服务的管理,采用基于设备根证书、应用发布证书认证的方式进行，以确保应用数据的机密性、完整性、真实性和行为的不可否认性。

c）结果判定：上述预期结果都满足判定为符合，其他情况判定为不符合。

6.8.3.2 可信应用及服务部署

根据GB_T 41388-2022《信息安全技术可信执行环境基本安全规范按照》中13.4.2的规定,可信应用及服务部署试验方法如下：

a）试验方法： 1）审查可信应用及服务部署过程；

2）尝试篡改设备提供商(或授权服务商)根证书、应用发布证书，执行可信应用与服务的安装操作，验证安装是否失败； 3）检查可信应用及服务部署过程的访问控制策略，尝试根据TA提供商所拥有的权限访问策略所允许和不允许的 TA 对应的相关资源和通信,验证策略是否有效。

b）预期结果：

1）当采用互信通道将 TA 部署到可信执行环境中时,可信执行环境系统首先校验 TA 的真实性和完整性，并根据不同 TA 提供商所拥有的权限，对相应 TA 对应的相关资源和通信访问进行严格控制。

c）结果判定：上述预期结果都满足判定为符合，其他情况判定为不符合。

6.8.4 可信服务

6.8.4.1 业务功能

业务功能试验方法如下：

6.8.4.1.1 可信时间服务

根据GB_T 41388-2022《信息安全技术可信执行环境基本安全规范按照》中13.5.1的规定,可信时间服务测试评价方法如下。

a）试验方法： 1）审查可信时间服务的设计；

2）在可信应用实例生命周期中,在系统正常运行状态和低功耗状态下,多次获取系统时间并进行比较;尝试重置或回滚系统时间,验证操作是否成功； 3）在可信应用实例中,获取持久化时间,使系统重启,在相同可信应用实例中再次获取持久化时间。

b）预期结果： 1）可信执行环境系统可集成可信时间服务，为可信应用及其他可信服务提供获取可信时间的功能； 2）在整个可信应用实例生命周期中,系统时间不可以重置或回滚，且不会因进入低功耗状态而影响系统时间的正常运转；

3）可信应用的持久化时间在重启过程中保持持久化。 c）结果判定：

上述预期结果都满足判定为符合，其他情况判定为不符合。

6.8.4.1.2 可信存储服务

根据GB_T 41388-2022《信息安全技术可信执行环境基本安全规范按照》中13.5.3的规定,可信存储服务测试评价方法如下。

a）试验方法： 1）审查可信存储服务的设计；

2）使用可信应用调用可信存储功能多次存储数据，验证存储过程是否保证操作的原子性。 b）预期结果：

1）可信执行环境系统集成可信存储服务功能，为可信应用及其他可信服务提供可信存储功能；

2）可信存储服务对存储对象的读写操作保证操作的原子性、数据的完整性。 c）结果判定：

上述预期结果都满足判定为符合，其他情况判定为不符合。

6.8.4.1.3 可信身份鉴别服务

根据GB_T 41388-2022《信息安全技术可信执行环境基本安全规范按照》中13.5.4的规定,可信存储服务测试评价方法如下。

a）试验方法：

1）审查可信身份鉴别服务的设计；

2）使用可信应用调用可信身份鉴别功能,尝试在可信执行环境之外篡改鉴别数据或结果。 b）预期结果：

1）可信执行环境系统集成可信身份鉴别服务功能,为可信执行环境系统中的可信应用或其他可信服务提供身份鉴别功能； 2）可信身份鉴别服务基于可信存储服务、可信人机交互、可信加解密服务等其他可信服务的协同操作来完成。

c）结果判定：上述预期结果都满足判定为符合，其他情况判定为不符合。

6.8.4.1.4 可信设备鉴证服务

根据GB_T 41388-2022《信息安全技术可信执行环境基本安全规范按照》中13.5.5的规定,可信存储服务测试评价方法如下。

a）试验方法： 1）审查可信设备鉴证服务的设计；

2）尝试伪造设备标识和设备来源,使用可信应用调用可信设备鉴证功能,验证调用结果是否能够证明设备标识的真实性及设备来源的真实性； 3）改变富执行环境的健康状态,使用可信应用调用可信设备鉴证功能,验证调用结果是否能够体现健康状态。

b）预期结果： 1）可信执行环境系统集成可信设备鉴证服务功能,用于证明设备的真实性；

2）可信设备鉴证服务能够证明设备标识的真实性及设备来源的真实性；

3）可信设备鉴证服务能够监测富执行环境运行的健康状态。 c）结果判定：

上述预期结果都满足判定为符合，其他情况判定为不符合。

6.8.4.1.5 可信人机交互服务

根据GB_T 41388-2022《信息安全技术可信执行环境基本安全规范按照》中13.5.6的规定,可信存储服务测试评价方法如下。

a）试验方法： 1）审查可信人机交互服务的设计。

b）预期结果： 1）可信执行环境系统集成可信人机交互服务功能，提供可信执行环境下的用户人机交互界面显示和输入功能。

c）结果判定：上述预期结果都满足判定为符合，其他情况判定为不符合。

6.8.4.1.6 SE 管理服务

根据GB_T 41388-2022《信息安全技术可信执行环境基本安全规范按照》中13.5.7的规定,可信存储服务测试评价方法如下。

a）试验方法：

1）审查SE 管理服务的设计。 b）预期结果：

1）可信执行环境系统集成 SE 管理服务功能,用于提供可信应用与 SE 之间的访问通道的功能。 c）结果判定：

上述预期结果都满足判定为符合，其他情况判定为不符合。

6.8.4.2 安全功能

安全功能试验方法如下：

6.8.4.2.1 可信加解密服务

根据GB_T 41388-2022《信息安全技术可信执行环境基本安全规范按照》中13.5.2的规定,可信存储服务测试评价方法如下。

a）试验方法： 1）审查可信加解密服务的设计；

2）使用可信应用以及其他可信服务调用加解密功能；

3）尝试使用未授权可信应用以及其他可信服务访问密钥。 b）预期结果：

1）可信执行环境系统集成可信加解密服务,为可信应用以及其他可信服务提供加解密功能；

2）可信加解密服务保证仅获得相应授权的可信应用或可信服务才可以访问密钥。 c）结果判定：

上述预期结果都满足判定为符合，其他情况判定为不符合。

6.8.4.2.2 可信存储服务

a）试验方法： 1）尝试使用可信应用获取或篡改其他可信应用或可信服务的数据；

2）检查可信存储的访问控制策略，根据策略使用可信应用访问策略所允许和不允许的存储空间，验证策略是否有效；

3）尝试对可信存储的数据执行回滚攻击。 b）预期结果：

1）可信存储服务对存储对象的读写操作保证数据的机密性；

2）可信存储具备访问控制机制，确保只有授权的应用才能访问相应的存储空间；

3）可信存储具备对数据回滚攻击的防御措施。 c）结果判定：

上述预期结果都满足判定为符合，其他情况判定为不符合。

6.8.4.2.3 可信人机交互服务

a）试验方法： 1）使用可信应用调用可信人机交互服务,尝试在可信执行环境之外执行窃取屏幕输入记录截取屏幕显示内容等攻击。

b）预期结果： 1）可信人机交互服务在用户和应用程序之间提供可信通道,具备抵御非法屏幕输入记录、非法屏幕显示内容截取、钓鱼等攻击的防护能力。

c）结果判定：上述预期结果都满足判定为符合，其他情况判定为不符合。

6.8.4.2.4 SE 管理服务

a）试验方法：

1）检查 SE 管理服务的访问控制策略,尝试使用授权和未授权的可信应用访问 SE，验证策略是否有效。

b）预期结果：

1）SE 管理服务具备访问控制机制以确保仅经过授权的可信应用可以访问 SE。 c）结果判定：

上述预期结果都满足判定为符合，其他情况判定为不符合。

6.8.5 跨平台应用中间件

根据GB_T 41388-2022《信息安全技术可信执行环境基本安全规范按照》中13.6的规定跨平台应用中间件试验方法如下：

a）试验方法：

1）审查厂商提交的文档,检查跨平台应用中间件的设计；

2）尝试在不同可信执行环境系统上安装和使用同一可信应用,调用相同接口和驱动,验证可信应用运行是否正常。

b）预期结果：

1）可信执行环境系统集成跨平台应用中间件,解决应用兼容性问题；

2）跨平台应用中间件能够提供跨平台支持库、安全外设的统一驱动框架、跨平台编程语言和跨平台API等功能。

c）结果判定：上述预期结果都满足判定为符合，其他情况判定为不符合。

6.8.6 可信应用

6.8.6.1 业务功能

业务功能试验方法如下：

6.8.6.1.1 可信应用加载

a）试验方法： 1）审查厂商提交的文档,检查可信应用加载过程；

2）尝试篡改可信应用安装文件,执行可信应用安装操作,验证可信执行环境是否能够验证可信应用合法性。

b）预期结果： 1）可信执行环境系统具备对可信应用验证的能力。

c）结果判定：上述预期结果都满足判定为符合，其他情况判定为不符合。

6.8.6.1.2 客户端应用与可信应用通信

a）试验方法： 1）审查厂商提交的文档,检查客户端应用与可信应用通信过程；

2）检查可信执行环境的访问控制策略,根据策略使用已授权和未授权的客户端应用访问可信应用,验证策略是否有效。 3）审查评估对象的对外接口，确认是否存在向REE输出密钥等敏感数据的相关接口。

b）预期结果： 1）可信执行环境具备访问控制能力,确保只有授权的客户端应用才能访问对应的可信应用。

2）确认不存在向REE输出敏感数据的接口。 c）结果判定：

上述预期结果都满足判定为符合，其他情况判定为不符合。

6.8.6.1.3 可信应用与可信应用通信

根据GB_T 41388-2022《信息安全技术可信执行环境基本安全规范按照》中13.7.3的规定，可信应用与可信应用通信评价方法如下。

a）试验方法： 1）审查厂商提交的文档,检查可信应用与可信应用通信过程；

2）检查可信执行环境的访问控制策略,根据策略使用已授权的可信应用访问未授权的可信应用, 验证策略是否有效。 3）检查可信执行环境的通信安全，使用已授权的可信应用访问另一个已授权的可信应用,验证是否有通信内容泄露的可能。

b）预期结果： 1）可信执行环境具备访问控制能力,确保只有授权的客户端应用才能访问对应的可信应用。

2）可信执行环境的通信符合安全性要求，保持机密性、完整性。 c）结果判定：上述预期结果都满足判定为符合，其他情况判定为不符合。

6.8.6.2 安全功能

安全功能试验方法如下： a）试验方法：

1）审查厂商提交的文档,检查可信应用与可信应用通信过程；

2）检查可信执行环境的访问控制策略,根据策略使用已授权和未授权的可信应用访问可信应用, 验证策略是否有效； 3）在可信应用与可信应用通信过程中,尝试使用未授权可信应用获取或篡改通信数据。

b）预期结果： 1）可信执行环境具备访问控制机制,使得仅被授权的可信应用可以与目标可信应用进行通信；

2）可信应用之间的通信,保证通信本身的机密性、完整性,除被授权的可信应用外,其他可信应用无法获取通信本身的信息。

c）结果判定：上述预期结果都满足判定为符合，其他情况判定为不符合。

6.9 性能试验

6.9.1 冷启动时间

冷启动时间性能测试应按照下列流程及要求依次进行： 1）搭建测试环境；

2）将设备格式化并刷入待测系统；

3）打开设备电源，记录时刻t1；

4）待仪表信息或倒车影像（倒车雷达）呈现，记录时刻t2；

5）待操作界面可用，记录时刻t3；

6）得出2个启动时间值：

——上电到仪表信息或倒车影像（倒车雷达）呈现时间：t2-t1；

——上电到操作界面可用时间：t3-t1； 7）关闭设备电源；

8）设置循环次数，循环执行步骤3）～7）；

9）根据6）的计算方式得出多组启动时间数据可进行相应的性能结果统计(包括，最大，最小，平均值等)，得到2个冷启动标志性动作的性能结果。

6.9.2 热启动时间

热启动时间性能测试应按照下列流程及要求依次进行： 1）搭建测试环境；

2）将设备格式化并刷入待测系统；

3）系统启动后进入STR模式或休眠（standby）模式；

4）唤醒系统，记录时刻t1；

5）待仪表信息或倒车影像（倒车雷达）呈现，记录时刻t2；

6）待操作界面可用，记录时刻t3；

7）得出2个启动时间值：

——切换到仪表信息或倒车影像（倒车雷达）呈现时间：t2-t1；

——切换到到操作界面可用时间：t3-t1； 8）设置系统进入STR模式或休眠（standby）模式；

9）设置循环次数，循环执行步骤4）～8）；

10）根据7）的计算方式得出多组启动时间数据可进行相应的性能结果统计(包括，最大，最小，平均值等)，得到2个热启动标志性动作的性能结果。

6.9.3 优先级调度响应时间

优先级调度响应时间测试应按照下列流程及要求依次进行： 1）搭建测试环境；

2）将设备格式化并刷入待测系统；

3）运行测试程序使CPU处于高负载，禁用系统中的其他中断；

4）创建n个不同优先级的周期性实时任务并运行，且每个任务都会设置一个timer，用于周期性的唤醒该任务；

5）设置任务进入睡眠状态，记录时刻t1，睡眠时间为t2；

6）任务被唤醒后记录当前系统时间t3；

7）得出任务系统调度延迟：t3-t2-t1；

8）循环执行步骤5）~7），进行多次测试；

9）在操作结束后，得出高负载时，n个任务的多组调度延迟数据，计算后可得每个优先级任务调度延迟(包括最大延迟、最小延迟、平均延迟)； 10）运行测试程序使CPU处于低负载，禁用系统中的其他中断；

11）重复执行步骤 4)～8)；

12）在操作结束后，得出低负载时，n个任务的多组调度延迟数据，计算后可得每个优先级任务调度延迟(包括最大延迟、最小延迟、平均延迟)；

13）搭建高温测试环境；

14）运行测试程序，禁用系统中的其他中断

15）重复执行步骤 4)～8）；

16）在操作结束后，得出高温时，n个任务的多组调度延迟数据，计算后可得每个优先级任务调度延迟(包括最大延迟、最小延迟、平均延迟)。

6.9.4 存储空间读写性能

存储空间读写性能测试应该安装下列流程及要求依次进行： 1）搭建测试环境；

2）将设备格式化并刷入待测系统；

3）启动测试程序并设定读/写次数和读/写参数；

4）开始读/写文件，记录时刻 t1；

5）完成 1GB 大小数据读/写后停止，记录时刻 t2；

6）得出读/写 1GB 大小数据耗时:t2-t1;

7）循环执行步骤 3）~6）；

8）在操作结束后得出多组参数下 1GB 数据读/写耗时后计算平均读/写速度。

6.9.5 Hypervisor 的资源开销（CPU/GPU）比率

1) 配置一台安装 Hypervisor 的系统 A，一台不搭载虚拟机的系统 B，（A、B 为同一系统）分别用于运行评分软件。

2) 在所有系统中禁用所有安全机制（如防火墙、SELinux 等），以减少干扰。 3) 在搭载 Hypervisor 的系统 A 中运行评分软件，得到：

CPU 评分：A1 GPU 评分：A2

4) 在另一台系统 B，进行相同的测试，得到： CPU 评分：B1

GPU 评分：B2

5) 计算 CPU 和 GPU 的性能比率： CPU 比率 = A1 / B1

GPU 比率 = A2 / B2

6) 计算 Hypervisor 带来的资源损耗： CPU 损耗 = 1 – (A1 / B1)

GPU 损耗 = 1 – (A2 / B2)

7) 循环执行步骤（4）-（7）

8) 多次操作取平均值得出 Hypervisor 的资源开销（CPU/GPU）比率。

6.9.6 多系统间通信

多系统间通信性能测试应该安装下列流程及要求依次进行： 1）搭建测试环境；

2）将设备格式化并刷入待测系统；

3）启动测试程序，关闭安全机制并设定循环次数；

4）发起通信，记录当前系统时间 t1；

5）收到响应消息后记录当前系统时间 t2；

6）循环执行步骤 4）~5)；

7）得出多系统间通信时间：t2-t1；

8）在操作结束得出多组数据后计算多系统间通信时间（包括平均时间，最长时间，最短时间）。

6.9.7 可信执行环境性能

6.9.7.1 CPU 性能

a）试验方法

1）在绑定单核的情况下，分别在 TEE 侧和 REE 侧利用 CPU 求解一定范围内的所有质数，记录处理时间；

2）在绑定多核的情况下，分别在 TEE 侧和 REE 侧利用 CPU 求解一定范围内的所有质数，记录处理时间。

b）预期结果

1）单核情况下，TEE 所用时间不超过 REE 的 1.10 倍；

2）多核情况下，TEE 所用时间不超过 REE 的 1.10 倍； c）结果判定

上述预期结果都满足判定为符合，其他情况判定为不符合。

6.9.7.2 内存性能

a）试验方法

1）分别在 TEE 侧和 REE 侧进行内存复制操作，记录耗费时间。 b）预期结果

1）TEE 侧进行内存复制操作所耗费时间和 REE 侧的差距不超过 1%。 c）结果判定

上述预期结果都满足判定为符合，其他情况判定为不符合。

6.9.7.3 存储读写性能

a）试验方法

1）在 REE 侧对数据分别进行存储与读写操作，记录耗费时间；

2）在 TEE 侧使用反向调用的方式，对 REE 侧数据分别进行存储与读写操作，记录耗费时间； b）预期结果

1）TEE 侧存储读数据性能较 REE 侧损耗在 5%以内，写数据性能较 REE 损耗在 5%以内。 c）结果判定

上述预期结果都满足判定为符合，其他情况判定为不符合。

6.9.7.4 加解密性能

a）试验方法

1）在定频定核的情况下，分别在 TEE 与 REE 下进行 AES256 算法加解密操作，并记录消耗时

间；

2）在定频定核的情况下，分别在 TEE 与 REE 下利用 RSA2048 算法生成密钥对并进行加解密

操作，记录耗费时间；

3）在定频定核的情况下，分别在 TEE 与 REE 下计算 SHA512 哈希值，并记录耗费时间。 b）预期结果

1）REE 下 AES256 算法加解密所耗费时间不超过 TEE 所耗费时间 1.15 倍；

2）TEE 下 RSA2048 算法生成密钥对所用时间不超过 REE 下生成时间的 1.6 倍，加密所用时间不超过 REE 的 1.2 倍，解密所用时间不超过 REE 的 1.2 倍；

3）在 TEE 下摘要算法(SHA512) 加解密所耗费时间不超过 TEE 所耗费时间的 1.15 倍。 c）结果判定

上述预期结果都满足判定为符合，其他情况判定为不符合。

6.9.7.5 通信性能

a）试验方法

1）编写服务端 TA，分别测试客户端 TA 与客户端 CA 访问服务端的时间；

2）测试在 REE 到 TEE 多条通道完全阻塞的情况下，再启动一条新的通道，确认新的通道是否能正常传输数据。

b）预期结果

1）TA 与 TA 通信时间应小于 50μs，TA 与 CA 通信时间应小于 230μs；

2）在 REE 到 TEE 多条通道阻塞的情况下，新启动的通道仍然可以正常传输数据。 c）结果判定

上述预期结果都满足判定为符合，其他情况判定为不符合。

6.10 信息安全试验

6.10.1 通用安全

6.10.1.1 系统安全

a) 系统用户管理要求试验方法：

1）尝试root用户直接登录系统；

2）尝试为不同角色的账号设置使用权限；

3）查看系统中所有账号，尝试以开发账号和测试账号登录系统；

4）编写测试程序，修改各种不成功鉴别尝试值（包括尝试次数和时间的阈值）的预设值，根据修改的值的类型，进行相应的不成功登录，确认当达到预设值时，系统是否能够鉴别失败并进行处理；

5）审查身份验证功能的相关设计文档，确认特权用户（串口root身份）身份验证应支持口令鉴别、基于令牌的动态口令、生物特征识别(刷脸、声纹或虹膜等)、数字证书鉴别等多种方式；

6）尝试以特权用户（串口root身份）身份进行登录，确认是否在访问安全功能相关的操作之前完成身份验证的鉴别工作。

预期结果：预期结果：

1）root用户不能直接登录；

2）确认能够为不同角色的账号设置使用权限；

3）确认系统中没有非必要账号，确认系统中不存在开发账号和测试账号，确认开发账号和测试账号不能登录系统；

4）确认当达到所设置的不成功的鉴别尝试值时，系统能够采取正确的措施来进行鉴别失败处理；

5）确认系统的特权用户（串口root身份）身份验证功能支持口令鉴别、基于令牌的动态口令、生物特征识别(刷脸、声纹或虹膜等)、数字证书鉴别等多种方式；

6）确认身份验证的鉴别工作在访问安全功能相关的操作之前完成；结果判定：上述预期结果都满足判定为符合，其他情况判定为不符合。

b）系统服务管理要求：试验方法：

1）审查系统服务相关设计文档，确认操作系统对关键资源实施强制访问控制（MAC）；

2）在系统中安装应用级程序、系统级程序、接口资源访问程序，查看应用程序的权限，确认应用程序只能获得最低权限；

3）审查系统服务相关设计文档，确认系统对关键资源实施自主访问控制（DAC）；

4）尝试在系统中对文件和可执行文件的访问进行管理和审计；

5）启动操作系统，查看系统中的服务；预期结果：

1）确认操作系统对关键资源实施强制访问控制（MAC）；

2）应用级程序需配置为最小访问权限；系统级程序应配置有限的访问权限；接口资源访问（如： WLAN、蓝牙、USB等接口）的程序应该配置最小访问权限；

3）确认操作系统对关键资源实施自主访问控制（DAC）；

4）系统提供对文件和可执行文件的访问的管理和审计功能，能够确保文件和进程免受未经授权的访问和操作；

5）不必要的系统服务应处于关闭状态，如非必要的FTP、Telnet、SSH等；

6）系统中不存在为开发和调试阶段使用的服务。结果判定：上述预期结果都满足判定为符合，其他情况判定为不符合。

c) 系统安全启动要求试验方法：

1) 检查操作系统所使用的芯片是否支持安全启动功能，并且其OTP功能被启用；

2) 检查芯片安全启动程序相关文档或源代码，如bootloader，确认是否有根证书验证过程

3) 检查安全启动过程的相关文档或源代码，确认所使用算法是国家密码管理机构推荐的，并符合国家相关标准规定；

4) 检查操作系统Bootloader相关安全设计文档，确认Bootloader是否具备防篡改机制；预期结果：

1) 确认操作系统所使用的芯片支持安全启动功能，且OTP功能处于启用状态；

2) 确认芯片安全启动程序包括对根证书的验证过程；

3) 确认安全启动过程所使用的算法是国家密码管理机构推荐的，并符合国家相关标准规定；

4) 确认操作系统Bootloader相关安全设计文档，确认Bootloader是否具备防篡改机制；结果判定：

上述预期结果都满足判定为符合，其他情况判定为不符合。

d) 系统漏洞管理要求试验方法：

1) 通过自动化代码扫描结合人工代码审核的方式对操作系统源代码进行审阅；

2) 通过二进制代码扫描的方式对操作系统镜像文件进行检查；上述两种试验方法可结合实际情况选择其中一种。

预期结果：

1) 识别源代码或镜像文件中是否包含权威漏洞平台6个月前公布且未经处置的高危及以上的安全漏洞；

结果判定：

1) 如包含权威漏洞平台6个月前公布且未经处置的高危及以上的安全漏洞，需进一步提交针对该漏洞的具体处置措施，包括代码及设计文档，否则视为不符合；

2) 如不包含权威漏洞平台6个月前公布且未经处置的高危及以上的安全漏洞，视为符合。

e) 软件升级安全要求试验方法：

1）审查操作系统软件升级方面的设计文档；

2）在服务器放置经过篡改的升级包，并通知操作系统下载升级包；

3）在服务器放置未经数字签名的升级包，并通知操作系统下载升级包；预期结果： 1）审查操作系统软件升级过程中是否有对升级包真实性、完整性的验证功能；

2）车载操作系统在进行更新时能够验证升级包的完整性，并发现异常终止升级；

3）车载操作系统在进行更新时能够验证升级包的真实性，并发现异常终止升级；结果判定：

上述预期结果都满足判定为符合，其他情况判定为不符合。

f）系统内核加固试验方法：

1）查看相关文档，确认车载操作系统内核的安全加固机制，确认内核是否采用了如安PXN、PAN、 KASLR、控制流完整性保护、RODATA、RO SYSCALL Table、页表完整性保护等全加固机制；

2）查看车载操作系统对内核的保护机制，确认系统是否对内核进行了完整性保护；尝试破坏内核的完整性，确认内核的保护机制是否能够识别出错误；

3）查看车载操作系统对可执行的系统调用的范围进行了限制，是否限制了进程的特权范围，内核是否支持强制访问控制，如SElinux；

4）审阅相关文档，确认系统是否支持地址空间布局随机化机制(ASLR)；预期结果：

1）车载操作系统内核使用了安全加固机制；

2）审阅相关文档，确认是否存在内核完整性保护机制，并确认系统启动或运行时对内核进行完整性验证；

3）审阅相关文档，确认内核是否提供了进程间隔离机制，并编写测试脚本，对跨进程内存地址进行读写访问，已确认进程间隔离机制有效；

4）系统内核提供了地址随机化功能；结果判定：

上述预期结果都满足判定为符合，其他情况判定为不符合。

g）系统访问控制试验方法：

1）查看系统读写权限，并尝试对只读区域写入数据，对包含只读数据的存储分区的保护机制，确认车载操作系统是否采用了一种机制来对数据进行块级或文件级完整性保护；尝试破坏数据的完整性，确认车载操作系统是否能够识别出错误；

2）查看系统对包含读写数据的存储分区的保护机制，确认车载操作系统是否采用一种机制来对数据进行块级或文件级完整性保护；尝试破坏数据的完整性，确认车载操作系统是否能够识别出错误；

3）查看系统确认是否提供了常见的入侵检测功能，是否支持针对特定端口或IP的访问控制；利用

6.1.8中的试验方法，对系统进行渗透入侵，确认系统是否能够成功检测到此次入侵；尝试对特定端口或IP进行访问控制操作，确认系统是否提供该操作，并且操作是否能够成功；

预期结果： 1）只读存储区域使用了只读保护机制，或操作系统启动或运行时可对只读数据进行完整性检查；

2）系统是否对权限为读/写的存储区域有保护机制，如加密存储或完整性验证；

3）审阅相关文档，确认系统是否提供访问控制和入侵检测服务，并在车载操作系统启动运行后对系统进行端口扫描及渗透测试，以确认访问控制和入侵检测服务有效；

结果判定：上述预期结果都满足判定为符合，其他情况判定为不符合。 h）编译器要求

试验方法： 1）审阅相关文档，并检查编译器，确认编译器是否支持堆栈保护；

2) 审阅相关文档，并检查编译器，确认编译器是否支持编译时缓冲区溢出检查。预期结果：

1）编译器支持堆栈保护；

2）编译器支持缓冲区溢出检查；结果判定：

上述预期结果都满足判定为符合，其他情况判定为不符合。

6.10.1.2 数据安全

a) 试验方法

1) 在系统中运行能够进行数据采集服务的应用，启动应用并尝试进行数据采集，确认系统是否能够明确告知用户采集的目的和范围；

2) 在系统中运行能够获取多项用户敏感个人信息的应用。尝试在已获取授权同意的情况下采集对应个人信息；尝试在未获取授权同意的情况下采集对应个人信息；尝试在授权同意期满之后再次采集对应个人信息。确认上述采集行为是否符合要求；

3) 审查数据安全设计相关文档，查看应用收集个人信息是否限于实现处理目的所必要的最小范围，且需要取得用户的明示同意；

4) 在系统中运行能够采集远程控制、远程诊断等功能场景下所发送的指令数据的应用程序，尝试采集远程控制、远程诊断等功能场景下所发送的指令数据，确认是否向用户提出了具体的、清晰明确的授权同意，确认该授权同意是否由用户在完全知情的基础上自愿给出；确认采集动作是否在获得授权同意之后进行；

5) 在系统中运行能够让设备或后台存储用户数据的应用，确认在存储数据之前，是否会告知用户并获取授权；用户选择拒绝授权，并退出登录，确认用户个人数据是否被清空；再次运行测试应用并且用户选择授权，确认系统是否为用户提供直观易用的数据删除选项，以及撤回授权的选项；尝试将系统恢复出厂设置，确认用户数据是否被清除，或提供用户数据是否一并删除数据的选项。

6) 在系统中运行能够访问用户数据的应用程序，尝试在非授权的情况下访问用户数据，确认系统是否允许访问；

7) 查看系统的用户间隔离机制，在系统中创建多个用户，尝试用户在非授权的情况下访问其他用户的数据，确认是否能够访问其他用户的数据；

8) 尝试关闭用户数据采集功能，确认系统是否提供了用户关闭功能；

9) 尝试进行各种用户数据操作，包括采集、传输、存储、销毁等操作，确认系统是否对相关操作保存了日志；

10)尝试存储敏感个人信息，确认敏感个人信息是否以明文方式存储；

11)查看系统对于生物特征信息的存储方式；

12)查看参数完整性校验功能，确认系统是否对安全重要参数进行了完整性校验，是否采取了相应的措施来避免重要参数的丢失和误删除，是否对安全重要参数采用了备份或安全空间存储；

13)查看系统中的各类日志，确认系统是否为各类日志设置了默认等级，并尝试对日志等级进行修改；

14)查看为车辆内外部通信及相关业务的关键数据的保护机制，关键数据包括且不仅限于：通信密钥、车辆数字证书私钥、密码、车辆长期Id、用户认证的生物特征等个人隐私信息、

地图数据、导航数据以及其他关键、敏感信息或数据、系统核心配置文件，确认系统是否对关键数据采用了加密存储、访问控制、加密传输等机制予以保护；

15)查看对关键数据整个生命周期的安全防护机制，确认系统是否对关键数据的全生命周期，包括数据的生成、采集、存储、访问、传输、分析、使用、销毁等环节，提供了安全防护机制。

16)查看系统在进行数据采集时，是否遵循最小采集原则；尝试进行数据采集，确认是否告知用户采集的目的；是否在征得用户同意之后才能够完成数据采集；

18)查看系统是否是否采取了相应的安全机制，以保护存储数据的保密性和完整性；查看系统是否采用了数据脱敏、数据加密技术；查看系统是否使用了安全存储，采用物理安全芯片或可信执行环境、分区隔离等技术；

19)确认系统是否采用了数据使用的授权机制，确认在数据使用时是否提供了权限的验证机制，是否采取了相应措施以验证数据的完整性和真实性；

20)尝试执行数据共享操作，确定在共享时是否询问了个人信息主体的同意，确定是否完成了共享数据的备份；

21)尝试执行数据销毁操作，确认数据是否被彻底销毁，销毁后是否有数据遗留，是否能够恢复数据。

b) 预期结果

1) 系统明确告知用户采集的目的和范围；

2) 应用能够采集已获授权的用户敏感个人信息，不能采集未或授权的信息；若授权同意期满，需要重启提出个人信息授权同意申请；

3) 应用收集个人信息应限于实现处理目的所必要的最小范围，取得用户的明示同意，特殊情况除外（如紧急呼叫等）；

4) 系统应在采集远程控制、远程诊断等功能场景下所发送的指令数据之前，需要获取用户的授权同意，未获授权则不能采集相关数据。该授权同意必须是具体的、清晰明确的，并且必须是在用户完全知情且自愿的基础上获得。

5) 如设备或后台需要存储用户数据，则应当告知用户，并获得授权；没有获得用户授权，当前用户退出登陆后，系统应默认清空个人数据；获得了用户授权，系统应提供直观易用的数据删除选项，以及撤回授权的选项；恢复出厂设置应默认清除用户数据，或提供用户数据是否一并删除的选项。

6) 系统应拒绝在非授权情况下访问用户数据；

7) 系统应采用用户间隔机制，在非授权情况下，用户不能访问其他用户的数据；

8) 当车载操作系统提供用户数据采集功能时，系统应提供用户关闭的功能；

9) 系统应提供日志功能对用户数据操作（包括采集，传输，存储，销毁）进行存储；

10)系统应应采用用加密（例如：SM2、AES（长度不低于128位）等算法）存储敏感个人信息，宜采用基于硬件保护的安全存储；

11)系统应使用基于硬件的安全存储生物特征信息，或使用纯硬件的生物特征功能实现；

12)系统支持安全重要参数的完整性校验，系统提供安全重要参数的防丢失和误删除功能，宜采用备份或专用安全空间存储；当安全重要参数出现完整性缺失时，系统能够发现错误；

13)操作系统应该指定默认日志等级，且具有对日志等级进行配置的功能；

14)系统对关键数据宜采用加密存储、访问控制、加密传输等机制进行保护。

15)系统对关键数据的全生命周期提供了安全防护机制，包括数据的生成、采集、存储、访问、传输、分析、使用、销毁等环节；

16)在采集数据时应遵循最小采集原则；系统在采集数据之前应该明确告知用户采集的目的；应该在用户同意采集后才能够采集数据，如果用户不同意，则不能采集数据；

17)系统中包括保护传输数据的保密性、完整性和真实性的功能；

18)系统中包括保护存储数据的保密性和完整性的功能，宜采用数据脱敏、数据加密；宜使用安全存储，采用物理安全芯片或可信执行环境、分区隔离等；

19)系统在使用数据之前需要获得授权，否则无法使用，并且会对数据的完整性和真实性进行验证；

20)数据共享时应该取的个人信息主体的同意，在共享时应该对共享数据进行备份；

21)销毁数据时，数据应该被彻底销毁，没有遗留数据，不能被恢复； c) 结果判定：

1) 达到上述预期结果都满足则判定为符合；

2) 达不到上述预期结果，或出现其他情况判定为不符合。

6.10.1.3 通信安全

a）试验方法

1）尝试在系统中设置网络通信白名单，确认系统是否提供网络通信白名单功能；

2）在系统中设置网络通信白名单，尝试与受到系统信任的URL建立通信链接（如Http/以太网

/蓝牙等），与未信任URL建立通信链接，确认是否只有受到系统信任的URL才能建立通信链接；

3）查看通信加密功能，确认是否使用TLSv1.2(长度不低于2048的RSA算法或长度不低于256的 ECC算法)及以上版本进行通信；

4）尝试发送敏感个人信息，确认是否使用TLSv1.2及以上版本进行双向认证；

5）查看通信协议设置，确认系统中是否存在HTTPS和HTTP混合通信；确认系统中是否全部使用HTTPS进行通信；

6）查看随机数生成器的具体设计，确认系统中是否采用了已验证、安全的随机数生成器；

7）尝试生成随机数，确认随机数是否符合随机数相关标准(例如:GM/T 0005等)

8）查看参数配置的具体设计（包括设备身份标识、认证机制、安全通信协议、安全服务类型、安全服务描述、安全服务授权信息、安全服务地址、指定哈希算法、指定加密算法、加密密钥、证书类型、证书签发者、证书有效期、证书有效区域、证书权限范围和应用数据签名权限），确认参数配置是否是已验证且安全的，确认使用的证书是否全部都由车厂信任的认证机构签发；

9）审查通信流程，确认网络通信时，系统是否会对数据的完整性进行校验；

10）编写测试程序，尝试在网络通信时发送校验值不正确的数据，确认是否能够成功校验出错误，并且终止响应该操作；

11）审查通信流程，确认在网络通信时，系统会对通信双方进行身份验证；

12）尝试篡改网络通信某一方（或双方）的身份，并进行网络通信，确认身份鉴权是否能够识别发现错误，并终止相应操作；

13）确认系统是否支持基于PKI的证书管理机制和安全协议；

14）审查网络隔离机制，确认是否对外部网络与车内网络间进行隔离(如VLAN或物理隔离)；

15）尝试进行网络通信并完成各种操作，确认系统是否利用日志对关键事件进行记录；（会上：会后整合至技术要求）

16）尝试在网络通信中发送异常报文，确认系统是否能够感知异常报文；

17）对操作系统进行端口扫描，确认是否存在隐蔽端口；查看所有开启端口，确认这些端口是否是系统运行和业务应用所必要的；确认所有无用的端口是否已经被关闭；

18）确认车外网络通信是否具有访问控制机制（如防火墙）；

19）尝试分别以授权访问和非授权访问两种方式，利用车外网络进行通信，确认访问控制机制是否能够识别出非授权访问，是否能够阻止该非授权访问；

20）审查车内网络隔离机制，确认车内是否具备安全网络域的隔离（vlan）；

21）利用6.1.6和6.1.8中的试验方法，.对防火墙进行模糊测试与渗透测试，确认防火墙是否能够拦截非法报文，确认防火墙是否能够拦截与未定义网络之间的通信；

22）检查防火墙的工作机制，确认在保存防火墙的相关数据时，是否采用了安全存储机制。防火墙相关数据包括拦截数据流量、防火墙故障状态和防火墙规则数量等。

23）检查防火墙的工作机制，确认防火墙是否支持将数据上报或转发其它模块处理的功能。 b）预期结果：

1）系统宜提供网络通信白名单功能，且只有受到系统信任的URL可以建立通信链接；

2）加密通信应使用TLSv1.2(长度不低于2048的RSA算法或长度不低于256的ECC算法)及以上版本进行通信，并且在发送敏感个人信息时，应使用TLSv1.2及以上版本进行双向认证；

3）系统全部使用HTTPS协议进行通信；

4）系统采用已验证、安全的随机数生成器，且生成的随机数符合随机数相关标准(例如:GM/T

0005等)；

5）系统使用已验证、安全的参数配置，且只使用车厂信任的认证机构签发的证书；

6）系统在网络通信时会对数据内容进行完整性校验；若数据完整性校验失败，系统会终止响应操作；

7）系统在网络通信时会对双方进行身份鉴权，若鉴权失败，会终止响应操作；

8）操作系统应支持基于PKI的证书管理机制和安全协议；

9）操作系统应对外部网络与车内网络间进行隔离(如VLAN或物理隔离)；

10）系统宜提供关键事件的日志功能；

11）系统应该对异常报文有感知能力，建议具有告警或其他安全响应的能力；

12）系统中不存在隐蔽端口，所有开启的端口都应该是系统运行和业务应用所必要的，无用的端口都应该处于关闭状态；

13）系统对车外网络通信提供访问控制机制（如防火墙），能够防止非授权访问；

14）系统应该具备安全网络域的隔离（如vlan）；

15）防火墙能够对报文进行安全过滤，能够拦截非法数据，避免其进入安全区域；

16）防火墙只允许和预定义的网络进行通信，能够拦截与未定义的网络之间的通信；

17）系统使用安全存储机制来保存防火墙的相关数据，并且具有上报或转发其它模块处理的功能；

c）结果判定： 1）除（1）（10）之外的所有预期结果都满足则判定为符合；

2）达不到除（1）（10）之外的上述预期结果，或出现其他情况判定为不符合。

6.10.2 应用安全

a）试验方法

1）确认是否对应用采取了防逆向措施，宜采用地址随机化、代码混淆或加壳等措施；

2）对车载操作系统的应用进行逆向工程，确认应用是否能够被逆向分析；

3）确认是否会利用签名认证机制，对应用软件安装包进行真实性和完整性验证，

4）确认系统加载应用时，是否会验证其完整性；

5）尝试向系统中安装签名有误的应用，确认签名验证机制是否能够成功检测出错误；

6）尝试利用应用访问、操作和使用系统资源及数据，确认系统在执行相关操作时，是否会校验应用的访问权限；

7）查看应用在访问、操作和使用系统资源及数据时的请求，确认访问请求中是否直接附带了应用身份和权限信息；确认服务提供方是否会对权限进行校验

8）确认应用间是否采用隔离机制；

9）确认系统在对不同应用的重要数据进行加密时，是否采用了不同的密钥；

10）确认系统是否控制了应用访问系统调用的权限，是否向应用程序暴露了所有的系统调用； b）预期结果

1）系统的应用应采取防逆向分析机制，并且该机制能够有效防止应用被逆向分析；

2）应用软件安装包应采用签名认证机制，系统在安装和加载时，利用该机制校验应用的真实性和完整性；

3）在应用加载时，宜对完整性进行检验；

4）应用在访问、操作和使用系统资源及数据时，应校验其访问权限，宜在访问请求中直接附带应用身份和权限信息，并在服务提供方校验其权限是否足够；

5）应用间应采用隔离机制；

6）系统宜用不同密钥对不同应用的重要数据进行加密

7）系统应当控制应用访问系统调用的权限，不会向应用程序暴露所有的系统调用。

c）结果判定

1）除（3）（6）之外的预期结果都满足则判定为符合；

2）达不到除（3）（6）之外的上述预期结果，或出现其他情况判定为不符合。

6.10.3 审计安全

a）试验方法

1）运行系统，进行包括触发报警、连接网络、运行应用等在内的任意操作，确认系统是否会对以下事件生成审计日志：系统运行记录、报警记录、操作日志、网络流量记录、应用软件运行日志、配置信息等；

2）查看审计日志的内容，确认其中是否包括事件发生的日期、时间、主体标识、事件类型描述和结果(成功或失败）、关联的进程等；

3）检查日志的本地存储机制，确认审计日志是否在本地保存，尝试将审计日志保存至本地，确认是否能够成功保存；

4）检查日志的权限管控机制，确认系统是否对访问本地日志进行权限管控；在无权限的情况下对本地日志进行访问，再在有权限的情况下对本地日志进行访问，确认对本地日志的权限管控是否有效；

5）检查日志的存储机制，确认系统是否对于本地日志采用了加密存储；

6）确认是否为审计信息提供数字签名和时间戳功能，确认数字签名和时间戳功能是否真实有效；

7）确认审计日志是否能够传输到云端；若能够传输到云端，确认云端日志在云端是否被加密存储，确认云端日志中是否含有个人信息；

8）审计日志若能传输到云端，尝试将审计日志保存至云端，并查看云端日志，确认日志的加密情况，确认日志中是否包含个人信息；

9）确认系统是否进行敏感信息审计，是否禁用SU、SUDO命令，是否禁止敏感IP，是否禁止明文的密钥文件；尝试使用SU、SUDO命令，使用敏感IP，使用明文的密钥文件，确认行为是否被禁止；

10）确认系统是否文件系统审计功能，是否进行文件权限读写配置，是否进行分区挂载rwx属性配置；尝试进行文件权限读写配置，尝试进行分区挂载rwx属性配置，确认相关操作是否支持；（会上：根据实际情况修改试验方法）

11）确认服务审计中是否包括禁用调试服务、调试驱动等；

12）确认权限审计是否包括用户UID、GID重复性检查等；

13）确认应用审计是否包括开启Canary栈溢出保护，隐藏符号表（strip）等 b）预期结果

1）系统宜对生成审计日志：系统运行记录、报警记录、操作日志、网络流量记录、应用软件运行日志、配置信息等安全相关事件生成审计日志；

2）审计日志的内容至少应包括事件发生的日期、时间、主体标识、事件类型描述和结果(成功或失败）、关联的进程等信息；

3）审计日志应该能够进行本地存储，

4）系统对访问本地日志进行了权限管控，且管控有效；

5）宜对本地日志进行加密存储；

6）系统利用数字签名和时间戳机制，确保审计信息的真实性和完整性；

7）审计日志宜能传输到云端，云端日志应加密存储，不应含有个人信息；

8）系统对敏感信息进行审计，包括禁用SU、SUDO命令；禁止敏感IP；禁止明文的密钥文件等

9）文件系统审计包括文件权限读写配置、分区挂载rwx属性配置等；

10）服务审计包括禁用调试服务、调试驱动等；

11）权限审计包括用户UID、GID重复性检查等；

12）应用审计包括开启Canary栈溢出保护；隐藏符号表（strip）等。 c）结果判定

1）除（1）（5）（7）之外的达到上述预期结果都满足则判定为符合；

2）达不到除（1）（5）（7）之外的上述预期结果，或出现其他情况判定为不符合。

6.10.4 多系统安全

a）试验方法

1）检查多系统安全启动的整体流程，确认流程是否具备统一的硬件信任根和完整的信任链；尝试篡改或指定错误的硬件根和信任链，确认是否能够识别错误；

2）检查多系统域隔离安全机制，确认是否能够确保多操作系统间的空间隔离（如内存、 Cache、外设等）、时间隔离（如硬实时、时间窗配置等）

3）检查多系统权限模型，确认虚拟机的每项资源是否能够通过独立的权限进行管理，确认系统中是否不村子具备最高等级权限的虚拟机，尝试对虚拟机中的资源进行权限管理，确认与设计文档内容相符；

4）检查多系统间通信机制，确认是否具备多系统间通信身份验证和访问控制的能力；

5）尝试以合法身份进行通信，再以不合法的身份进行通信，确认是否只能在通过身份验证的情况下进行多系统间通信；

6）尝试拥有访问权限的前提下发起访问，再以没有访问权限的前提下发起访问，确认事发后只有拥有访问权限才能完成访问；

7）检查多系统驱动框架对驱动的防护机制，确认多系统驱动框架对驱动提供有限防护（例如基于内核安全机制检测、前后端驱动隔离等技术）

8）检查多系统间隔离机制，确认隔离机制能够防止系统数据的非授权访问；

9）尝试在授权的情况下，访问多系统的系统数据，确认是否能够正常访问；尝试在非授权的情况下，访问访问多系统的系统数据，确认是否无法访问。

b）预期结果

1）多系统安全启动的整体流程具备统一的硬件信任根和完整的信任链，确保多系统代码和数据的完整性和真实性

2）多系统域隔离安全应确保多操作系统间的空间隔离（如内存、Cache、外设等）、时间隔离（如硬实时、时间窗配置等）；

3）多系统权限模型应确保虚拟机的每项资源都能够通过独立的权限进行管理，系统中无具备最高等级权限的虚拟机；

4）应具备多系统间通信身份验证和访问控制的能力；

5）多系统驱动框架对驱动提供有限防护（例如基于内核安全机制检测、前后端驱动隔离等技术）；

6）多系统应采用系统间隔离机制，防止系统数据的非授权访问。 c）结果判定：

1）达到上述预期结果都满足则判定为符合；

2）达不到上述预期结果，或出现其他情况判定为不符合。

6.11 功能安全试验

在进行车载操作系统的验证活动中，应对验证计划和结果进行检查，以证明满足面向功能安全的安全概念。验证应基于仿真测试或其它适当的方法。应通过向智能座舱系统相关的电子电气组件施加相应的输入，来模拟组件内部典型故障的影响，以检查系统组件发生失效的情况。

附录 A

（资料性附录）车载操作系统架构

A.1单系统架构如图1所示，单个车载操作系统的单系统架构由车载操作系统内核、资源抽象、基础库、基础服务、

运行时环境、程序运行框架和车载操作系统安全七个功能模块组成。单个车载操作系统对底层车载智能座舱平台异构硬件（简称底层硬件）和上层应用程序提供统一的接口。

图 A.1 车载操作系统单系统架构

A.2 多系统架构 A.2.1 多系统架构分类

多系统架构是同一套硬件之上运行多个车载操作系统单系统的架构。从车载操作系统的功能、性能和安全的隔离需求角度，分为硬件隔离、虚拟机管理器、容器三类多系统基础架构，以及两类或三类基础架构的混合架构。

A.2.2 硬件隔离架构

如图2所示，硬件隔离架构将硬件资源通过硬件分区的方式进行划分和管理。

图 A.2 硬件隔离架构

A.2.3 虚拟机管理器架构

如图3所示，虚拟机管理器（Hypervisor）架构将硬件和软件资源通过虚拟机管理器的方式进行划分和管理，包括Type-1祼机型和Type-2宿主型两种类型。

a) Type-1祼机型：虚拟机管理器运行在硬件之上，多个车载操作系统单系统运行在虚拟机管理器之上。

b) Type-2宿主型：宿主操作系统运行在硬件之上，虚拟机管理器运行在宿主车载操作系统之上，多个车载操作系统单系统以应用程序进程形式运行在虚拟机管理器之上。

图 A.3 基于虚拟机管理器的多系统架构

A.2.4 容器架构

如图 4 所示，容器架构将硬件和软件资源通过容器的方式进行划分和管理。

图 A.4 容器架构

A.2.5 混合架构

混合架构可采用三类基础架构中的两类或三类组合而成。图5（1）是硬件隔离+虚拟机管理器Type-1的混合架构。

此外，如图5（2）所示，有些虚拟机管理器在Type2的基础上，将虚拟机管理器实现在一个宿主操作系统之上，但该操作系统既可以支持硬件虚拟化及其它单系统运行在其虚拟机管理器之上，又可以运行自身操作系统的功能和应用，并实现与其它单系统间的隔离。

（1）硬件隔离+虚拟机管理器Type-1混合架构（2）虚拟机管理器Type-2+ Application混合架构图 A.5 多系统混合架构

附录 B

（规范性附录）各类车载操作系统技术要求对应表

表 B.1 各类车载操作系统技术要求对应表

技术要求章节号中控操作系统用于仪表盘的操作系统用于 T- box 的操作系统

1.内核 5.2 M M M

2.资源抽象 5.3 M O O

3.基础库进程间通信库 5.4 M M M

网络传输库MOM

安全通信库MMM

图像库MMO

4.基础服务互联服务 5.7.1 O – M

地图及定位服务5.7.2O-O

语音服务5.7.3O-O

多媒体服务5.7.4OO(报警音)O

软件升级服务5.7.5O-O

账号服务5.7.6O-O

驾驶提示服务5.7.7OOO

增强的人机交互服务5.7.8OOO

显示功能5.7.9OOO

5.运行时环境 5.5 O O O

6.协议栈 5.6 O O O

7.程序运行框架 5.8 O O O

8.多系统 5.9 O O –

9．可信执行环境 5.10 O O O

10.通用安全系统安全 5.12.1.1 M M M

数据安全5.12.1.2MMM

通信安全5.12.1.3MOM

11.应用安全 5.12.2 M O M

12.审计安全 5.12.3 M O M

13.多系统安全 5.12.4 M O O

14.功能安全 5.13 O O（建议 ASIL-B 及 –

以上）

“M”：必选技术要求；“O”：可选技术要求; “-” ：不涉及

附录 C

（资料性附录）试验方法简述及车载操作系统不同对象试验方法对应表

C.1 试验方法简述

C.1.1 业务功能

模拟真实用户实际的工作流程，检查系统是否满足用户所需求的业务功能的过程。

C.1.2 隐私策略

测试人员通过检测工具或方法验证系统开发商的隐私策略与公开一致，保证用户的个人信息不被违规或超范围收集使用。

C.1.3 安全功能

对功能安全和信息安全目标的一致性检查。

C.1.4 自动化静态代码扫描

利用代码扫描工具，定义编程语言的规则，对程序代码进行自动化分析，找到代码中潜在的漏洞。

C.1.5 代码审计人工复核

人工进行的发现程序错误、安全漏洞和违反程序规范为目标的源代码分析，能够找到静态代码扫描等普通安全测试所无法发现的安全漏洞，通常在自动化静态代码扫描的结果基础上，也会进行人工代码审计，以判断扫描结果是否存在误报。

C.1.6 形式化数学验证

形式化方法采用严格的数学方法，基于数学逻辑和推理验证的技术来描述、开发并验证软件。形式化方法一般可分为定理证明和模型检测两种方法。其中，定理证明通过对系统问题进行逻辑抽象，以数学定理或逻辑公式的方式表达系统应有的功能和安全属性，采用数学推理的方式进行验证。模型检测方法则需要对系统进行建模，并进行自动推理。系统软件的形式化验证由于其系统复杂性一般多采用定理证明的方式来实现。

通过形式化方法对系统软件的开发过程一般为：首先使用规约语言描述系统要满足的规约和系统特性；其次，使用验证工具验证系统实现代码的行为满足规约的要求。

C.1.8 二进制代码检测

使用二进制代码检测工具对操作系统固件进行检测分析，识别其中包含的开源组件版本信息、用户名密码等敏感信息、加密算法、CVE/CNNVD漏洞。

C.1.9 软件成分分析（供应链安全）

一种对二进制软件的组成部分进行识别、分析和追踪的技术。专门用于分析开发人员使用的各种源码、模块、框架和库，以识别和清点开源软件的组件及其构成和依赖关系，并识别已知的安全漏洞或者潜在的许可证授权问题，把这些风险排查在应用系统投产之前，也适用于应用系统运行中的诊断分析。

C.1.10 模糊测试

一种动态测试技术，利用自动、半自动的方法，发送大量随机数据到被测试系统，通过监控系统运行过程中的异常（断言失败、死循环、系统错误、逻辑错误、优先级倒换、重启等），来发现被测目标中可能存在质量问题的测试技术。按照是否获得目标反馈，一般分为黑盒模糊测试和灰盒模糊测试；按照测试场景，一般分为源代码模糊测试、协议模糊测试、API模糊测试等。

C.1.11 渗透测试

模拟黑客采用的漏洞挖掘技术和攻击方法，对系统的网络、主机、应用和数据等单元是否存在安全问题进行检测的过程。渗透测试主要用于发现系统的脆弱性，评估信息系统是否安全，从攻击者角度发现、分析系统漏洞，利用漏洞实现主动攻击。

C.1.12 漏洞扫描

基于漏洞数据库，通过扫描等手段对指定的远程或者本地计算机系统的安全脆弱性进行检测，发现可利用漏洞的一种安全检测（渗透攻击）行为。

C.1.13 压力测试

也称为强度测试、负载测试。压力测试是模拟实际应用的软硬件环境及用户使用过程的系统负荷，长时间或超大负荷地运行测试软件，来测试被测系统的性能可靠性、稳定性等。

C.1.14 故障注入测试

一种可靠性验证技术，代码层面的故障注入指向源码中注入故障代码，引入故障并观察系统存在故障时的行为。引入的代码通常不能影响正常功能逻辑，易读易写且能引入编译器检测。

C.2 车载操作系统不同对象试验方法对应表

从试验目的角度，车载操作系统的试验方法分为一致性检查、功能安全、信息安全、性能四个大类，不同对象对应的试验方法见表C.1。

表C.1 车载操作系统不同对象试验方法对应表

试验方法试验对象

目标

分类

黑盒

白盒

操作系统内核

资源抽象层

基础库

运行时环境

协议栈基础服务程序运行框架多系统可信执行环境

文件系统

互联服务

地图及定位服务

语音服务

多媒体服务

自动升级服务

账号服务

驾驶提示服务增

强的人机交互服务

互联互通框架

服务融合框架

多媒体框架

多模态交互框架场景感知理解框架

用户界面框架

基于硬件隔离基于虚拟机管理器

基于容器

基础要求

可信虚拟化系统

可信操作系统可

信应用与服务管理

可信服务跨平台应用中间件

可信应用

一致性检查业务功能 ● ● M M M M M M M M M M M M M M M M M M M M M M M – M M M M M M

隐私策略●●——MMM–M—————M–

安全功能——————–MMMMMMMM-M

信息安全

静态自动化静态代码扫描 ● ● M M M M M M M M M M M M M M M M M M M M – M M M M M M M M M

代码审计人工复核●OOOOOOMMMMMMMMOOOOOO-OOOOOOOOO

形式化数学验证●——OOOOOOOO——-OOOOOOOOO

逆向工程●—–OOOOOOOOOOOOOOO———-

二进制代码检测●MMMMMMMMMMMMMMMMMMMM-OOMMMMMMM

软件成分分析（供应链安

全） ● M M M M M – – – – – – – – – – – – – – – – – – – – – – – – –

动态模糊测试 ● ● M M M M M M M M M M M M M M M M M M M M – O O M M M – M M M

渗透测试●—–MMMMMMMMMMMMMMM—MMMMMMM

漏洞扫描●MMMMMMMMMMMMMMMMMMMM—MMMMMMM

压力测试MMMMM————————-

功能安全

静态自动化静态代码扫描 ● ● M M M M M M M M M M M M M M M M M M M M – M M O O O O O O O

代码审计人工复核●OOOOOOMMMMMMMMOOOOOO-OOOOOOOOO

形式化数学验证●———————OOOOOOOOO

动态模糊测试●●MMMMMMMMMMMMMMMMMMMM-OOOOO-OOO

故障注入测试●MMMMMMMMMMMMMMMMMMMM-OOOOOOOOO

注：“M”：必选试验方法；“O”：可选试验方法; “-”：不涉及

附录 D

（资料性附录）车载小程序 API 接口要求

1) 支持车载小程序引擎，提供统一的小程序运行环境和小程序用户界面框架，支持开发者开发一份小程序代码可运行在不同车载操作系统中；

2) 车载小程序引擎引用物模型基于整车服务/信号接口的 SDK；

3) 车载小程序平台将 SDK 中的接口封装并提供给运行在平台中的小程序使用，并提供安全接入的认证平台；

4) 运行在小程序平台的小程序通过平台认证后可以使用小程序平台调用到车载操作系统中的整车服务。

车载操作系统功能安全典型应用场景和安全要求

车载操作系统应用场景可分为高实时性要求场景、道路安全相关显示场景和车载娱乐场景。典型的车载操作系统的应用场景如表1所示。

不同类型的车载操作系统应用场景对车载操作系统的功能安全要求及ASIL等级要求建议如表E.1所

示。

车载操作系统的应用场景分类及典型的应用场景

类型 1

（高实时性要求场景)

仪表告警制动系统故障指示灯，ESC/ESP（电子稳定控制系统）故障/关闭指示

灯，TC 循迹防滑系统故障/关闭指示灯，中央告警灯，动力电池热失控报警信息，后轮转向故障报警等

驾驶提示错误显示档位信息（D/R/P/N），转向指示，四驱显示&报警，可脱手高

速公路辅助（SHWA）指示灯，EPB（电子驻车制动系统）开启指示灯， ABS（防锁死刹车系统）开启指示灯，SRS 安全气囊指示灯等

道路安全相

关告警

通过多功能摄像头 MFK 视觉识别进行道路安全告警

类型 2 (道路安全相关显示场景) 窄路提示

AVP 摄像头显示

倒车显示

通过地图数据进行道路安全提示（QM）

类型 3 (车载娱乐场景) 音乐服务

网络服务

车载网络游戏

车载网上购物

参考文献

[1] GB/T 34590.9 道路车辆功能安全第 9 部分：以汽车安全完整性等级为导向和以安全为导向的分析

[2] GB/T 40856 车载信息交互系统信息安全技术要求

下单前可任取样页验证译文质量。
免费提供正规普通增值税数电发票。
请联系手机/微信: 13306496964/Email: standardtrans@foxmail.com 获取完整译文。
本英文译本为纯人工专业精翻版本，保证语法术语准确率和专业度！
专业源于专注|ChinaAutoRegs 始终专注于汽车标准翻译领域！
「中国汽车标准译文库」已收录上千个现行汽车国家标准和行业标准的英文版译本，涵盖传统燃油车、新能源汽车和摩托车标准化体系！独家打造千万级汽车专业术语库和记忆库。
The English Translation of this document is readily available, and delivered immediately upon payment.
Sample pages may be requested to your preference before placing order.
Please contact standardtrans@foxmail.com for the complete PDF version in English.
Our well-established database has included almost all Chinese automotive standards in effect, providing one-stop, up-to-date, efficient and professional solution.

中国汽车标准译文库

ChinaAutoRegs|专业源于专注

GB/T英文版翻译智能网联汽车车载操作系统技术要求及试验方法

发表回复取消回复

发表回复 取消回复

发表回复取消回复