智能网联汽车车控操作系统功能安全技术要求
1范围
本文件规定了智能网联汽车车控操作系统功能安全的总体要求。
本标准适用于M和N类车辆的智能网联汽车车控操作系统，其他类型的车辆可参照使用。q70
本文件不包含由信息安全因素间接关联的功能安全技术要求。
2规范性引用文件
下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件，仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。
GB/T34590道路车辆功能安全
ISO/IEC9945信息技术.可移植操作系统接口(POSIX)（Information technology—Portable Operating System Interface（POSIX））
ISO26262道路车辆功能安全（Road vehicles-Functional safety）
3术语和定义
GB/T34590界定的以及下列术语和定义适用于本文件。
兰德酷路泽陆地巡洋舰
车载计算平台on-board computing platform
支撑智能网联汽车驾驶自动化功能等实现的软硬件一体化平台，包括芯片、模组、接口等硬件以及系统软件和功能软件等软件，以适应传统电子控制单元向异构高性能处理器转变的趋势。
注：也被称为车载智能计算基础平台。
车控操作系统vehicle-controlled operating system
运行于车载智能计算基础平台硬件及汽车电子控制单元硬件之上，支撑智能网联汽车驾驶自动化功能实现和安全可靠运行的软件集合。车控操作系统由智能驾驶操作系统和安全车控操作系统组成。
智能驾驶操作系统intelligent driving operating system
车控操作系统（3.2）中支撑智能网联汽车驾驶自动化功能实现的软件集合，包括系统软件和功能软件。
安全实时操作系统safety vehicle-controlled operating system
车控操作系统（3.2）中支撑智能网联汽车安全可靠运行的软件集合，包括系统软件和功能软件。
系统软件system software
功能软件function software
车控操作系统中面向智能驾驶核心共性需求形成的智能驾驶共性服务软件集合，支撑驾驶自动化功能开发，包括数据抽象、功能软件通用框架、智能驾驶通用模型和应用软件接口。
相关项item
实现整车层面功能或部分功能的系统或系统组合。
[GB/T34590.1—2017，定义2.69]
独立于环境的安全要素safety element out of context
不是在特定的相关项定义下开发的安全相关要素。
4缩略语
下列缩略语适用于本文件。
中央处理单元Central Processing Unit
循环冗余码校验Cyclical Redundancy Check
数据分发服务Data Distribution Service
错误检查和纠正Error Checking and Correction
端到端End to End
免于干扰Freedom From Interference
先入先出First In First Out
硬件安全模块Hardware Security Module
惯性测量单元Inertial Measurement Unit
进程间通信Inter-Process Communication
内存管理单元Memory Management Unit
CPU
CRC
DDS
ECC
E2E
FFI
FIFO
HSM
IMU
IPC
MMU
MPU
ODD
OS
POSIX
QM
QoS
RAM
SEooC
V
内存保护单元Memory Protection Unit
运行设计域Operational Design Domain
操作系统Operating System
可移植操作系统接口Portable Operating System Interface
质量管理Quality Management
服务质量Quality of Service
M
随机存取存储器Random Access Memory
独立于环境的安全要素Safety Element out of Context
虚拟机Virtual Machine
5
车控操作系统安全要求
通用要求
5.1.1车控操作系统应满足ISO26262以及GB/T34590的要求，并达到客户定义的安全目标，最高可支持ASIL-D。
车控操作系统的功能安全开发应采用SEooC的方式，应假定整体的适用范围、需求场景和安5.1.2全目标。
5.1.3本标准安全状态只定义软件的安全状态，系统及整车安全状态由用户来定义。
5.1.4
5.1.5
异构分布硬件应支持内存保护和分区，以实现不同安全功能的内存分离。
车控操作系统在全新特定环境下进行集成之前，应确认全部假设在新环境下的有效性。若假设与实际需求不一致，应按照GB/T34590
第八部分第八章进行变更管理。
系统软件安全要求
5.2.1系统软件通用要求
车控操作系统系统软件应符合5.2.2~5.2.6所述的安全要求。
5.2.2操作系统内核
5.2.2.1操作系统内核通用要求
操作系统内核应符合5.2.2.2~5.2.2.5所述的要求。
5.2.2.2安全目标
车控操作系统应提供正确可靠的运行环境，安全等级最高可支持ASIL-D 。
5.2.2.3安全假设
5.2.2.3.1对于使用操作系统进行软件部署的相关项，操作系统应该具有功能安全继承或分解后的最高功能安全等级。
5.2.2.3.2对于具体项目应用，系统集成人员应定义最差调度响应时间，并基于目标环境开展测试，验证所配置的调度策略和线程优先级是否满足最后期限(deadline )需求。
系统集成人员应评审并确认所有的配置(Manifest )是否满足项目安全要求。
系统集成人员应确保上层软件模块安全/正确地使用操作系统内核提供的功能和机制。
使用者需确认车控操作系统内核在系统层级满足所列外部假设条件，并且确保系统的运5.2.2.3.35.2.2.3.45.2.2.3.5行状态在数据手册所规定的范围内。
5.2.2.4
安全要求5.2.2.4.1
操作系统内核应为用户态应用程序的存储访问提供隔离措施，以保证每个存储访问相互隔离。
5.2.2.4.2
操作系统内核应提供措施来约束每个进程在执行过程中不会使用超过其预先分配的资源。5.2.2.4.3操作系统内核的地址空间应被保护，并为应用程序提供访问内核地址空间的安全接口，以支持安全相关的进程间通讯比如管道、FIFO 、共享存储等。
注：管道指进程间单向的数据传输通路。
5.2.2.4.4如果硬件支持特权模式，操作系统内核应将不受信任的用户态软件置于非特权模式下，从而阻止不受信任的用户态软件访问安全相关的硬件。
5.2.2.4.5资源强制访问控制机制，应做到最小特权原则。
5.2.2.4.6在操作系统内核空间出现异常时，如非法系统调用、堆栈溢出、指针异常访问、内存越界、死循环、死锁、超时等，操作系统内核应立即调用内核异常处理程序，并上报对应的故障代码。如果内核异常处理程序为空，操作系统内核应立即调用操作系统关闭处理程序。（内核异常处理程序不建议为空）。
5.2.2.4.7操作系统内核应诊断IPC 消息传递的故障，如IPC 消息发送失败，消息接收失败等。
5.2.2.4.8当一个安全相关线程出现异常时，如超时错误、内存错误、指令错误等，操作系统内核应立即调用该线程的异常处理机制。如果该线程的异常处理机制为空，则内核应立即停止运行该线程。（安全相关线程的异常处理机制不建议为空）。
操作系统内核应尽可能地监控每个用户态进程的资源消耗，如CPU 、内存等5.2.2.4.9。
5.2.2.4.10在多核处理器上，当操作系统内核在一个处理器核心上检测到异常并且需要关闭操作系统时，应同时在所有其他处理器核心上关闭该操作系统。
5.2.2.4.11操作系统内核应提供栈溢出诊断机制，以探测已经发生的栈溢出错误并调用内核异常处理程序。
5.2.2.4.12对于内核服务接口，操作系统内核应向用户态软件模块提供安全的服务接口（如I/O 操作、信号处理等），不正确地调用这些服务接口不应导致内核崩溃。
5.2.2.4.13当出现不正确的内核服务接口调用（例如，传递非法地址、无效参数、非法的上下文等）时，内核服务接口不应执行对应的服务，并且立即返回错误代码。
5.2.2.5
安全状态违背安全目标时，操作系统内核进入的安全状态为：操作系统内核日志、报警、降级、重启或关闭等。
5.2.3虚拟化管理
5.2.3.1
虚拟化管理通用要求系统软件虚拟化管理及板级支持包应符合5.2.3.2~5.2.3.5所述的要求。
5.2.3.2安全目标
虚拟化管理应为跨平台操作系统提供安全的虚拟环境接口，提供满足FFI 要求的隔离机制。安全等级最高支持ASIL-D 。
5.2.3.3安全假设
5.2.3.3.1虚拟化管理应用到的虚拟驱动安全等级最高为ASIL-D 等级。
5.2.3.3.2硬件应提供系统内存管理单元。
芯片的CPU 、中断控制器、I/O 硬件应支持硬件虚拟化的功能。
当虚拟化管理及板级支持包上报故障或进入安全状态时，外部系统应监控虚拟化管理及5.2.3.3.35.2.3.3.4板级支持包上报故障，确保整个系统的安全性。
suv2010knightxv5.2.3.4安全要求
5.2.3.4.1虚拟化管理及板级支持包应具备相关硬件及软件故障的诊断机制、故障上报机制、可能的故障处理机制以及故障恢复机制。
i-vista注：可能的故障处理机制例如对于需要立即处理的安全相关故障，虚拟化管理及板级支持包可以立即操作硬件使系统进入安全状态，不需要先将故障上报到安全监控程序。
5.2.3.4.2诊断测试虚拟化管理及板级支持包在初始化虚拟环境时，应按照但不限于下列方法对硬件进行安全：
a)验证各个硬件模块功能的正确性；
∙∙示例1：回读寄存器验证写入的参数是否成功；
豫h00027示例2：进行通讯回环测试；
b)c)对硬件安全机制进行故障注入测试；
如果安全诊断测试不通过，应根据故障类型停止加载上层软件组件/进程对象/Guest OS，同
时应上报故障给安全域；
虚拟化管理模块在运行时对低安全等级的软件组件（不具备足够ASIL 等级的存量软件模块或
第三方软件模块）进行功能安全监控。如相关寄存器配置是否正确、运行时是否有意外修改寄存器的行为、运行时关键运算结果的合理性校验d)。
注：对于不同厂商提供的硬件IP，安全诊断测试需要根据硬件IP 本身已有的硬件安全机制来设计。例如，硬件IP 内部的所有寄存器都有奇偶校验保护机制，则安全诊断测试需要对奇偶校验保护机制进行故障注入测试；硬件IP 内部的寄存器没有硬件保护机制，则安全诊断测试需要对写入寄存器的数值进行回读校验，并进行周期性的检查。
5.2.3.4.3
根据隔离和使用的需求，虚拟化管理应支持对资源的静态专用与动态共享的能力。5.2.3.4.4
行资源。
5.2.3.4.虚拟化管理在任何情况下（例如意外事件，系统过载等），都应为安全分区提供足够的运5
虚拟化管理应管理所有VM 分区之间的通讯访问权限。安全状5.2.3.5态
当违背安全目标时，虚拟化管理应进入的安全状态为：虚拟化管理日志、报警、重启等。
5.2.4POSIX
5.2.4.1
POSIX 通用要求系统软件POSIX及其他接口应符合5.2.4.2~5.2.4.5所述的要求。
淄博汽车网5.2.4.2安全目标
POSIX 接口或POSIX 接口的子集（例如PSE51）应满足免于干扰（全等级最高支持ASIL-D FFI ）要求。POSIX 接口的实现安。
5.2.4.3安全假设
5.2.4.3.1功能安全应用应充分考量POSIX 接口的实时性要求；
功能安全应用或应用库应使用符合功能安全要求的POSIX 接口，当POSIX 接口上报故5.2.4.3.2障或进入安全状态时，系统需确保安全性。
5.2.4.4安全要求
5.2.4.4.1POSIX接口的设计应符合ISO/IEC9945的要求。
5.2.4.4.2POSIX接口应进行免于干扰FFI的设计，例如：不正确的调用（传递非法地址、无效参数、非法的上下文等）。这些安全的服务接口不应导致内核崩溃或安全隐患。
5.2.4.5安全状态
当违背安全目标时，POSIX接口应进入的安全状态为：POSIX接口不应执行对应的服务，返回错误代码或执行回滚等。
5.2.5系统中间件及服务
5.2.5.1系统中间件及服务通用要求
系统中间件及服务应符合5.2.5.2~5.2.5.5所述的要求。
5.2.5.2安全目标
系统中间件及服务应提供正确的基础系统服务，安全等级最高支持ASIL-D。
5.2.5.3安全假设
5.2.5.3.1对于分布式通信中间件，硬件存储单元中不带有错误检测功能的安全相关通讯都应使用E2E保护。
5.2.5.3.2对于应用调度和生命周期管理，车控操作系统中不同ASIL等级的目标文件不能混合分配给同一个进程。
5.2.5.3.3对于应用调度和生命周期管理，操作系统内核应对进程提供时间隔离和空间隔离。
5.2.5.3.4 5.2.5.3.5需要调度的进程的优先级应根据相关项的安全要求来定义。应在特定线程中进行中断事件处理。
5.2.5.3.6对于安全框架和服务，ASIL-B及以上功能安全等级的安全相关应用组件应使用中间件提供的调度错误(如超时、运行太过频繁、乱序)的检测机制。
5.2.5.3.7安全相关应用组件应使用中间件提供的绑定监控结果的健康监控通道来报告检测到的错误并触发系统响应。
5.2.5.4安全要求
5.2.5.4.1分布式通信中间件中，所有安全相关的以太网通讯都应采用E2E保护。E2E应包含如下信息：数据识别码(Data ID)、校验码(CRC)和计数器(counter)等。
5.2.5.4.2
a)
b)
c)
d)
e)
f)
g)
h)
i)安全框架和服务应符合如下要求：
应能正确初始化安全相关的硬件；
应能检测安全相关组件的潜在故障；
应能验证启动映像文件(image)的完整性（例如版本回退，错误日志记录）；
应能验证应用映像文件(image)的完整性，并提供错误处理和记录；
应能在启动时监测可能禁止或影响安全机制产生作用的硬件潜在故障；
应能在运行时监测硬件错误，并在监测到影响安全目标的硬件错误时切换到安全状态；
应能提供错误响应处理机制；
应能提供监控服务监控应用软件正确执行；
应能提供可以确保完整性的密钥存储机制，例如通过HSM硬件存储或者软件冗余存储和回读来监测数据损坏或丢失；
应提供可以确保完整性的文件访问，例如通过冗余存储和回读来监测数据损坏或丢失j)。
5.2.5.4.3应用更新管理应符合如下要求：
a) b)每次应用更新之前，应该能对应用来源的有效性和软件包的完整性进行检查，若检查失败，应停止升级并提示用户；
每次应用更新完毕后，都应进行应用软件的完整性检查，若检查失败，应进行提示并按升级失败处置；
每次应用更新都应有确定的更新状态（包括更新成功或是更新失败后回滚到更新前的状态）
c)；
发布评论