企业网站建设的基本原则有哪些?,dede阿里百秀网站源码,交互网站图,做UI设计的网站一、规范的编制的背景原因
编制该规范的原因
确保系统安全性和可靠性 随着汽车电子系统日益复杂#xff0c;功能不断增加#xff0c;对安全性和可靠性的要求也越来越高。该规范为AUTOSAR平台在安全执行、配置、更新、信息交换、数据处理等多方面制定了明确要求#xff0c;…
一、规范的编制的背景原因
编制该规范的原因
确保系统安全性和可靠性 随着汽车电子系统日益复杂功能不断增加对安全性和可靠性的要求也越来越高。该规范为AUTOSAR平台在安全执行、配置、更新、信息交换、数据处理等多方面制定了明确要求例如规定了AUTOSAR应提供机制来监测控制流和管理多应用的执行顺序[RS_SAF_00001]以确保系统免受干扰避免因控制流混乱或执行顺序错误导致系统故障或安全问题。在车辆运行中多个ECU及软件组件相互关联安全的信息交换至关重要。规范中要求提供机制支持安全的信息交换[RS_SAF_00004]可防止因信息传输错误或接收异常引发的车辆功能异常如避免因错误的车速信息传输导致自动驾驶系统做出错误决策。 统一标准与互操作性 AUTOSAR平台涉及众多供应商和不同的应用场景编制该规范能统一安全要求标准确保不同供应商开发的组件和系统在集成时能够正确交互和协同工作。例如在执行管理方面明确了执行管理应设置进程执行可执行文件[RS_EM_00002]并对进程相关属性如优先级、调度策略和访问权限进行分配使不同供应商开发的应用在同一平台上运行时能遵循统一的进程管理规则实现资源的合理分配和隔离保障系统的稳定性和安全性。对于通信管理规范规定了通信管理应使用E2E协议保护事件和方法的传输[RS_CM_00223]、[RS_CM_00400]并提供相关信息给应用保证了不同组件间通信的安全性和可靠性无论使用何种通信总线都能满足统一的安全通信标准促进组件间的互操作性。
缺乏规范的后果
安全漏洞与风险增加 若无该规范在数据存储方面可能缺乏安全机制容易导致数据损坏或丢失。例如应用在存储和检索数据时若没有规范要求的安全存储机制如[RS_SAF_10039]中防止数据意外更改、[RS_SAF_10040]中支持数据恢复机制可能因内存故障、干扰等因素使数据出错导致车辆关键系统如发动机控制、刹车系统获取错误数据进而引发严重安全事故。在软件更新时若没有安全更新机制如[RS_SAF_10038]要求在安全状态下更新软件可能在车辆行驶过程中进行不恰当的更新导致系统不稳定或功能失效危及行车安全。 系统集成困难与混乱 不同供应商的组件可能因缺乏统一安全标准而无法有效集成。比如执行管理中若没有统一的进程创建和资源分配规则一个供应商的应用可能过度占用资源影响其他应用运行甚至导致系统崩溃或者因进程隔离不当使不同安全级别的应用相互干扰破坏系统整体安全性。通信方面若没有规范对通信协议和故障检测机制的统一要求组件间通信可能出现错误无法及时发现和处理导致信息传输错误、延迟或丢失使车辆各系统间协同工作失效如仪表盘无法正确显示车辆状态信息驾驶员辅助系统无法及时获取传感器数据等。
二、规范的主要内容
2.1 顶层安全
顶层安全要求涵盖了安全执行、配置、更新或升级、信息交换、数据损坏检测、安全存储以及故障恢复等多个方面旨在确保AUTOSAR平台在各关键环节具备相应的安全保障机制以应对复杂的汽车电子系统运行环境。
安全执行
要求[RS_SAF_00001]规定AUTOSAR应提供支持机制用于监控控制流并管理具有不同安全关键性的多个应用程序的执行顺序。示例在车辆的自动驾驶系统中同时运行着感知模块、决策模块和控制模块等多个应用程序。感知模块负责收集环境信息如摄像头图像、雷达数据等决策模块根据感知数据做出驾驶决策如加速、减速、转向等控制模块执行决策并控制车辆的实际运行。如果没有有效的控制流监控和执行顺序管理感知模块可能出现数据处理延迟或错误导致决策模块基于错误信息做出错误决策进而控制模块执行错误操作危及车辆安全。例如感知模块在某一时刻因故障未能及时更新图像数据若没有规范要求的机制决策模块可能使用过期数据做出错误的驾驶决策如判断前方无障碍物而加速行驶而实际上前方有障碍物这将引发严重的安全事故。
安全配置
要求[RS_SAF_00002]要求AUTOSAR提供机制以支持在车辆整个驾驶周期内进行正确配置。示例车辆的电子控制系统包含众多配置参数如发动机控制单元的燃油喷射量、点火时间等参数以及安全气囊系统的触发阈值等。在车辆行驶过程中如果这些配置参数因某种原因如电磁干扰、软件故障等发生错误更改可能导致发动机性能下降、油耗增加甚至熄火或者安全气囊在不应触发的时候触发对驾驶员和乘客造成伤害。例如发动机控制单元的燃油喷射量配置在行驶中被错误修改可能使发动机混合气过浓或过稀影响发动机正常运行导致车辆动力不足或抖动影响驾驶安全。
安全更新或升级
要求[RS_SAF_00003]规定AUTOSAR应提供机制以支持对具有不同关键性的多个平台和非平台应用程序进行正确的更新和升级。示例汽车的车载娱乐系统和发动机控制软件都可能需要更新。如果在车辆行驶过程中发动机控制软件进行更新且没有遵循安全更新机制可能导致发动机突然停止工作或出现异常运行状态如更新过程中数据传输错误使发动机控制逻辑混乱引发发动机抖动、失速等问题严重影响车辆行驶安全。而车载娱乐系统若更新出错可能导致死机、卡顿影响用户体验但相比发动机控制软件更新出错对安全的直接影响相对较小。
安全信息交换
要求[RS_SAF_00004]要求AUTOSAR提供机制支持安全关键应用程序之间安全地交换传输和接收信息。示例在车辆的防抱死制动系统ABS和电子稳定控制系统ESP之间需要交换车辆轮速、加速度等信息。如果信息交换过程中出现错误例如传输的数据被篡改或丢失ABS可能接收到错误的轮速信息导致制动压力调节不当使车轮抱死或制动距离延长ESP可能因错误的加速度信息无法正确判断车辆行驶状态从而无法有效干预车辆稳定性在车辆转弯或紧急制动时容易引发侧滑、甩尾等危险情况。
数据损坏检测
要求[RS_SAF_00005]规定AUTOSAR应提供机制用于在数据处理、与其他系统或系统元素通信时检测故障。示例车辆的传感器如温度传感器、压力传感器等将数据传输给发动机控制系统。如果传感器数据在传输过程中因线路干扰或硬件故障出现数据损坏如数据位翻转而系统没有检测机制发动机控制系统可能根据错误的传感器数据如错误的进气温度数据调整燃油喷射量导致发动机燃烧不充分、动力下降、排放增加长期运行还可能损坏发动机部件影响车辆性能和可靠性。
安全存储
要求[RS_SAF_00006]要求AUTOSAR提供机制以支持应用程序的安全存储。示例车辆的导航系统存储地图数据和用户设置信息。如果存储机制不安全在车辆受到电磁干扰或存储设备出现故障时地图数据可能损坏或丢失导致导航系统无法正常工作驾驶员在陌生道路上失去导航指引增加迷路风险用户设置信息丢失可能使驾驶员偏好的导航显示模式、语音提示等设置恢复默认影响使用便利性在驾驶过程中分散驾驶员注意力间接影响行车安全。
故障恢复
要求[RS_SAF_00007]规定AUTOSAR应监控、检测并提供对可检测故障做出反应的手段。示例车辆的电池管理系统负责监控电池状态若电池电压、电流等参数出现异常如电池过热导致电压波动故障恢复机制应能检测到这种异常。如果没有有效的故障恢复机制电池可能过度充电或过度放电损坏电池寿命甚至引发电池起火、爆炸等严重安全事故。而有了相应机制系统可以采取措施如调整充电电流、启动冷却系统等恢复电池正常状态保障车辆电气系统安全稳定运行。
2.2 功能安全
功能安全要求涵盖软件组件初始化、验证、关机与终止、状态转换、资源管理、通信、防止数据丢失与篡改、安全更新、错误检测与恢复、时间相关检测、通信故障检测与配置等多个方面旨在确保AUTOSAR平台在软件和系统功能的各个关键环节具备相应的安全保障机制以应对复杂的汽车电子系统运行环境。
软件组件安全初始化
要求[RS_SAF_10001]规定AUTOSAR应提供机制支持软件组件的安全初始化。示例在汽车的发动机控制系统中包含多个软件组件如燃油喷射控制组件、点火控制组件等。在车辆启动时这些软件组件需要进行初始化以确保它们能正确运行。如果没有安全的初始化机制可能会导致初始化参数错误。例如燃油喷射控制组件初始化时错误地设置了喷油嘴的初始喷油量可能使发动机启动困难、燃烧不充分甚至无法启动影响车辆正常使用还可能因混合气过浓或过稀损坏发动机部件。
软件组件安全验证
要求[RS_SAF_10002]要求AUTOSAR提供机制对平台基本软件模块、功能集群、软件组件、应用程序、服务及其各自的配置数据进行安全验证。示例对于汽车的自动驾驶系统其中包含各种软件组件和配置数据。在系统运行前需要对这些组件和数据进行验证。如果没有有效的验证机制例如在更新自动驾驶系统的某个软件组件后其配置数据可能被错误修改但未被检测到。当车辆行驶在自动驾驶模式下该组件可能因错误的配置数据而无法正确处理传感器信息导致自动驾驶系统做出错误决策如错误判断前方障碍物距离引发碰撞事故。
安全关机与终止
要求[RS_SAF_10005]规定AUTOSAR应提供机制支持应用程序、软件组件、基本软件模块和服务的安全关机和终止。示例当车辆发生严重故障如发动机过热、电气系统短路等需要紧急关机时如果关机过程不安全可能导致数据丢失或系统状态异常。例如车辆的电子控制单元ECU在关机时如果没有按照正确顺序终止相关应用程序和服务可能使正在写入的数据丢失下次启动时系统无法正常加载之前的运行状态影响车辆的诊断和修复甚至可能导致系统无法重新启动车辆无法正常使用。
安全状态转换
要求[RS_SAF_10006]要求AUTOSAR提供机制支持基本软件模块、软件组件、应用程序或服务生命周期中的安全状态转换。示例在汽车的自动变速器控制系统中软件组件在不同的驾驶模式如停车、行驶、倒车等下需要进行状态转换。如果状态转换机制不安全当从行驶模式切换到倒车模式时若没有正确处理状态转换过程可能导致变速器换挡错误车辆突然失去动力或产生异常冲击影响驾驶舒适性严重时可能损坏变速器部件危及行车安全。
安全资源管理
要求[RS_SAF_10008]规定AUTOSAR应提供机制支持对自适应平台功能集群、应用程序和服务以及经典平台基本软件模块和软件组件进行安全资源管理。示例在车辆的多媒体娱乐系统和安全相关系统如安全气囊系统共用同一硬件资源如CPU、内存等的情况下如果没有安全的资源管理机制多媒体娱乐系统可能过度占用资源导致安全气囊系统在需要时无法及时响应。例如当车辆发生碰撞时由于资源被娱乐系统占用安全气囊系统可能无法及时触发无法为驾驶员和乘客提供有效的保护增加人员受伤风险。
安全通信接口
要求[RS_SAF_10014]要求AUTOSAR提供接口支持基本软件模块、软件组件、应用程序或服务进行安全通信。示例在车辆的车联网系统中车载设备与云端服务器之间需要进行通信传输车辆状态信息如车速、位置等和接收导航、远程控制等指令。如果通信接口不安全数据在传输过程中可能被窃取或篡改。例如黑客可能篡改车辆发送给云端的位置信息使车辆被错误定位或者篡改云端发送给车辆的导航指令导致车辆驶向错误路线引发交通混乱危及车辆和道路安全。
防止配置丢失
要求[RS_SAF_10027]规定AUTOSAR应提供机制防止有效配置丢失。示例汽车的座椅记忆功能、后视镜调节功能等都依赖于配置数据。如果车辆在行驶过程中因电气系统干扰或软件故障导致配置数据丢失座椅和后视镜可能恢复到默认位置影响驾驶员的视线和操作舒适性分散驾驶员注意力增加驾驶风险。例如驾驶员在调整好座椅和后视镜位置后因配置丢失突然座椅位置改变可能导致驾驶员无法正常操作踏板和方向盘影响驾驶安全。
安全程序执行
要求[RS_SAF_10030]规定AUTOSAR应提供机制支持安全程序执行。示例在车辆的制动控制系统中程序负责根据驾驶员的制动操作和车辆状态如车速、车轮转速等计算并控制制动压力。如果程序执行过程中出现错误例如因内存故障导致程序指令错误执行可能使制动压力计算错误制动距离变长或制动不均匀在紧急制动情况下无法有效减速引发追尾等碰撞事故严重威胁车辆和人员安全。
程序执行时间检测
要求[RS_SAF_10031]要求AUTOSAR提供机制检测程序执行时间违规。示例在车辆的发动机控制系统中一些控制程序需要在规定时间内完成执行如氧传感器信号处理程序用于实时调整空燃比。如果该程序执行时间过长超过规定时间限制可能导致发动机无法及时根据氧传感器反馈调整空燃比使发动机燃烧效率降低、排放增加长期运行还可能损坏发动机催化转化器等部件影响车辆性能和环保指标。
防止数据意外更改
要求[RS_SAF_10037]规定AUTOSAR应提供机制防止数据意外更改。示例在车辆的电子钱包系统用于支付停车费、过路费等中如果没有防止数据意外更改的机制可能因软件漏洞或外部干扰使账户余额数据被错误修改。例如账户余额可能被无故增加或减少导致支付系统混乱影响车辆正常的费用支付甚至可能引发财务纠纷同时也可能使车辆相关服务如自动缴费通行无法正常使用。
安全软件更新
要求[RS_SAF_10038]规定AUTOSAR应提供机制确保安全相关软件仅在不会导致危险情况的状态下进行更新/升级。示例在车辆的高级驾驶辅助系统ADAS更新过程中如果没有遵循安全更新机制在车辆行驶过程中进行更新可能导致系统功能异常。例如更新使前方碰撞预警功能失效驾驶员在驾驶过程中无法及时收到碰撞预警增加了发生碰撞事故的风险或者更新导致自适应巡航控制系统出错车辆速度控制不稳定影响行车安全。
数据损坏检测与恢复
要求[RS_SAF_10039]规定AUTOSAR应提供机制检测数据意外更改[RS_SAF_10040]要求支持数据恢复机制。示例车辆的行车记录仪存储大量行驶数据如果存储数据因存储设备故障或电磁干扰出现损坏若没有检测和恢复机制重要的事故相关数据可能丢失无法为事故调查提供准确信息。例如在发生交通事故后行车记录仪的数据损坏无法恢复无法确定事故发生时的车速、车辆状态等关键信息给事故责任认定带来困难同时也可能影响保险理赔等后续处理。
通信故障检测与配置
要求[RS_SAF_10041]规定AUTOSAR应允许集成商选择和配置检测通信故障的安全机制[RS_SAF_10042]要求提供机制检测时间同步违规。示例在车辆的分布式控制系统中不同ECU之间通过通信网络协同工作。如果通信出现故障如网络延迟、数据包丢失等且没有有效的检测和配置机制例如车辆的转向控制系统和车轮速度传感器之间通信故障转向控制系统无法及时获取准确的车轮速度信息可能导致转向助力系统失效或转向控制不准确使车辆在行驶过程中转向困难增加偏离车道、碰撞路边障碍物等风险。同时若时间同步出现问题如不同传感器数据的时间戳不一致可能使车辆控制系统无法正确融合数据做出错误决策影响车辆行驶稳定性和安全性。
2.3 技术安全要求
技术安全要求涵盖了健康监测、自适应平台各功能集群平台健康管理、执行管理、状态管理、操作系统接口、持久性、通信管理、更新和配置管理以及经典平台相关模块看门狗管理器、操作系统、E2E保护等方面旨在确保AUTOSAR平台在各个技术层面具备相应的安全保障机制以应对复杂的汽车电子系统运行环境。
健康监测
存活监督[RS_HM_09125] 要求健康监测应检查受监督实体中达到给定检查点的频率是否符合指定限制。示例在车辆的电池管理系统中有一个定期检查电池电压的任务该任务被设定为每10秒检查一次电压即检查点。如果健康监测机制发现该任务在一段时间内如1分钟执行次数远远少于预期的6次1分钟内应执行6次则可能表明电池管理系统出现故障如任务被阻塞或陷入死循环。这可能导致电池过充或过放无法及时被监测到进而影响电池寿命严重时可能引发电池起火、爆炸等安全问题。 逻辑监督[RS_HM_09222] 要求健康监测应检查受监督实体在运行时检查点的顺序是否与指定顺序相同包括分支选择、并发执行等逻辑正确性。示例在车辆的发动机控制系统中启动过程涉及多个步骤的逻辑顺序如先进行系统自检然后启动油泵接着启动点火系统等。如果健康监测检测到在一次启动过程中油泵在自检完成前就启动了违反了指定顺序可能是控制程序出现错误或受到干扰。这可能导致发动机启动失败或者在启动过程中因油压不足而损坏发动机部件影响车辆正常使用甚至在行驶中突然熄火危及行车安全。 期限监督[RS_HM_09235] 要求健康监测应检查两个检查点之间的经过时间是否在指定的最小和最大限制内包括检测第二个检查点是否从未到达。示例在车辆的自适应巡航控制系统中有一个任务负责定期更新与前车的距离信息检查点规定每500毫秒更新一次。如果健康监测发现两次更新之间的时间超过了1秒最大限制可能是传感器数据传输延迟或处理任务阻塞。这可能使车辆无法及时准确地保持与前车的安全距离在高速行驶时容易引发追尾事故威胁车辆和乘客的生命安全。
自适应平台功能集群
平台健康管理PHM 状态管理监督失败处理[RS_PHM_00115] 要求如果状态管理监督失败平台健康管理应触发看门狗重置。示例在车辆的自动驾驶系统中状态管理负责监控系统各个组件的状态如传感器状态、决策模块状态等。若状态管理监督发现传感器数据持续异常表明监督失败但无法自行恢复平台健康管理应触发看门狗重置。如果没有触发重置自动驾驶系统可能继续基于错误的传感器数据做出决策导致车辆行驶轨迹偏离如在车道保持功能中车辆可能偏离车道引发碰撞事故。 执行管理监督失败处理[RS_PHM_00116] 要求如果执行管理监督失败平台健康管理应触发看门狗重置。示例在车辆的动力系统控制中执行管理负责调度和执行各种控制任务如发动机喷油控制、变速器换挡控制等。若执行管理监督发现某个控制任务长时间未完成监督失败可能是执行管理模块出现故障或资源死锁。此时平台健康管理触发看门狗重置若不重置动力系统控制混乱发动机可能出现异常转速、变速器换挡异常影响车辆动力输出和行驶安全。 其他组件故障通知[RS_PHM_00117] 要求平台健康管理应在除执行管理和状态管理之外的自适应平台功能集群、自适应应用或服务发生故障时通知状态管理。示例在车辆的信息娱乐系统中某个音频播放服务出现故障属于自适应应用平台健康管理检测到故障后通知状态管理。状态管理可以根据此通知采取相应措施如尝试重启该服务或调整系统资源分配避免故障扩散影响整个信息娱乐系统的稳定性若不通知可能导致信息娱乐系统其他功能如导航显示、蓝牙连接等也受到影响分散驾驶员注意力间接影响行车安全。 检查点处理限制[RS_PHM_00118] 要求PHM应仅处理来自相应进程报告的检查点。示例在车辆的安全监控系统中不同传感器进程如车门传感器、车内监控传感器等向PHM报告检查点。如果PHM错误地处理了来自非对应进程如娱乐系统进程的虚假检查点可能导致系统误判安全状态如错误地认为车门未关闭实际上已关闭触发不必要的警报干扰驾驶员注意力影响正常驾驶。 异常检查点处理[RS_PHM_00119] 要求如果检查点是由非相应进程报告的则应引发安全事件。示例在车辆的网络通信系统中假设存在恶意软件试图模拟正常进程向PHM发送虚假检查点意图干扰系统安全机制。由于该检查点来自非相应进程PHM应引发安全事件如通知安全防护系统进行进一步检查和处理防止恶意软件通过伪造检查点信息获取系统权限或破坏系统正常运行保障车辆网络安全和整体系统安全。 执行管理EM 进程创建[RS_EM_00002] 要求执行管理应为每个建模进程的执行设置一个进程并根据执行清单分配进程特定属性如优先级、调度策略和访问权限。示例在车辆的多任务处理系统中同时运行着安全关键任务如制动控制任务和非安全关键任务如座椅加热控制任务。执行管理根据执行清单为制动控制任务创建高优先级进程确保其能及时响应制动操作而座椅加热控制任务为低优先级进程。如果没有正确设置进程属性例如制动控制任务被错误分配低优先级在紧急制动时可能因资源竞争无法及时执行导致制动延迟增加制动距离引发碰撞事故。 资源预算配置[RS_EM_00005] 要求执行管理应支持为进程和进程组配置操作系统资源预算。示例在车辆的多媒体系统中视频播放进程和音频播放进程属于同一进程组执行管理根据系统资源情况为该进程组配置一定的CPU时间和内存资源预算。如果在播放高清视频时视频播放进程占用过多资源超过预算执行管理可以限制其资源使用确保音频播放不受影响维持多媒体系统整体的稳定性避免因资源过度占用导致系统卡顿或崩溃影响用户体验间接影响驾驶安全如驾驶员因操作多媒体系统分心时系统不稳定可能加重分心程度。 线程绑定[RS_EM_00008] 要求执行管理应支持将给定进程的所有线程绑定到指定的处理器核心集。示例在车辆的雷达信号处理系统中为了减少线程迁移带来的开销和提高处理效率执行管理将雷达数据采集线程和处理线程绑定到特定的处理器核心。如果没有进行绑定线程可能在不同核心间频繁迁移导致数据处理延迟无法及时准确地获取雷达信息影响自动驾驶系统对周围环境的感知和判断在车辆行驶过程中可能无法及时检测到障碍物增加碰撞风险。 子进程创建控制[RS_EM_00009] 要求执行管理应控制其启动的每个进程创建子进程的权利除非另有配置。示例在车辆的软件更新系统中主更新进程负责下载和安装更新包执行管理限制主更新进程直接创建其他无关子进程防止恶意软件利用更新进程的权限创建恶意子进程如窃取车辆系统信息或破坏系统文件。如果没有这种控制恶意子进程可能在车辆系统中肆意运行危及车辆数据安全和系统稳定性影响车辆正常使用。 安全完整性级别实施[RS_EM_00151] 要求执行管理应至少按照平台上支持的任何进程的最高安全完整性级别实施。示例在车辆的混合关键度系统中同时运行着ASIL D级别的自动驾驶控制进程和QM级别的诊断日志记录进程。执行管理按照ASIL D级别的安全标准实施确保在管理这些进程时能满足自动驾驶控制进程对安全性的严格要求如严格的资源分配、错误检测和恢复机制等。如果执行管理没有达到相应安全级别可能导致自动驾驶控制进程出现错误无法及时处理影响车辆自动驾驶功能的安全性引发严重事故。 状态管理SM 安全完整性级别实施[RS_SM_00600] 要求状态管理应至少按照其管理的任何进程的最高安全完整性级别实施。示例在车辆的动力系统状态管理中涉及发动机启动、运行、停止等不同状态的管理其中发动机控制进程可能具有较高的安全关键度如ASIL C级状态管理需要按照该高安全级别实施。如果状态管理在处理发动机状态转换时出现错误如因自身安全级别不足导致状态转换逻辑错误可能使发动机在运行中突然停止或进入错误状态导致车辆失去动力影响行车安全特别是在高速行驶或复杂路况下后果更为严重。 协调恢复行动[RS_SM_00601] 要求状态管理应协调恢复行动。示例在车辆的电子控制系统中某个传感器出现故障导致相关数据异常平台健康管理检测到故障并通知状态管理。状态管理负责协调恢复行动如尝试重新初始化传感器、切换到备用传感器如果有或调整系统运行模式以适应传感器故障。如果没有有效的协调恢复机制系统可能持续使用错误的传感器数据导致控制策略错误影响车辆性能和安全性如发动机控制可能因错误的进气温度传感器数据而调整不当使发动机工作异常。
操作系统接口
系统内存预算[RS_OSI_00201] 要求操作系统应提供机制为每个进程或进程组配置内存预算。示例在车辆的多应用系统中导航应用和音乐播放应用同时运行操作系统为导航应用分配了一定的内存预算为音乐播放应用分配了另一部分内存预算。如果导航应用因地图数据更新等原因试图占用超过其预算的内存操作系统可以限制其内存使用防止导航应用因内存不足崩溃同时确保音乐播放应用不受影响维持系统整体稳定性。若没有内存预算机制导航应用可能过度占用内存导致音乐播放卡顿或系统因内存耗尽而死机影响驾驶员对车辆功能的正常使用在驾驶过程中可能因操作分心而引发安全问题。 CPU时间预算[RS_OSI_00202] 要求操作系统应提供机制为每个进程或进程组配置CPU时间预算。示例在车辆的自动驾驶系统中感知模块和决策模块是两个重要进程。操作系统为感知模块分配了较高的CPU时间预算以确保其能及时处理传感器数据。如果决策模块出现异常占用过多CPU时间超过其预算操作系统可以干预保证感知模块有足够的CPU时间运行维持对周围环境的准确感知。否则感知模块可能因CPU时间不足无法及时更新数据导致自动驾驶系统决策失误如无法及时检测到前方障碍物引发碰撞事故。 进程绑定到CPU核心[RS_OSI_00203] 要求操作系统应提供机制将进程或进程组绑定到CPU核心可选。示例在车辆的安全关键控制系统中如防抱死制动系统ABS和电子稳定控制系统ESP的相关进程操作系统可以将它们绑定到特定的CPU核心。这样可以减少进程在不同核心间切换的开销提高系统响应速度和稳定性。如果没有绑定在紧急制动或车辆处于不稳定状态时这些关键进程可能因核心切换延迟而无法及时执行控制操作影响制动效果和车辆稳定性增加事故风险。 多进程隔离[RS_OSI_00206] 要求操作系统应提供机制使多个进程相互隔离运行。示例在车辆的系统中安全关键的发动机控制进程和非安全关键的车载娱乐进程同时运行。操作系统确保发动机控制进程的内存空间和娱乐进程的内存空间相互隔离防止娱乐进程因软件漏洞如缓冲区溢出意外修改发动机控制进程的内存数据导致发动机控制出错影响车辆动力输出和运行安全。同时也避免发动机控制进程的高优先级任务抢占娱乐进程资源时导致娱乐进程崩溃影响用户体验间接影响驾驶安全如驾驶员因娱乐系统故障分心。
持久性
数据损坏检测[RS_PER_00008] 要求持久性应能够检测持久内存中的数据损坏。示例在车辆的车辆配置数据存储中存储着车辆的各种设置如轮胎压力监测系统的校准数据、驾驶模式偏好等。如果存储这些数据的持久内存因电磁干扰或硬件老化出现数据损坏持久性机制应能检测到。若无法检测车辆可能使用错误的校准数据导致轮胎压力监测不准确驾驶员无法及时发现轮胎异常增加爆胎风险或者驾驶模式无法正确切换影响驾驶体验和车辆性能。 数据恢复[RS_PER_00009] 要求持久性应能够恢复已损坏的数据。示例在车辆的行车记录仪数据存储中若因存储设备故障部分数据损坏持久性的恢复机制可以尝试恢复数据。如果没有恢复机制重要的行车记录如事故发生瞬间的数据可能丢失无法为事故调查提供准确信息影响责任认定和保险理赔等后续处理。而有了恢复机制即使数据损坏也有机会还原数据保障车辆相关数据的完整性和可用性。
通信管理
事件传输保护[RS_CM_00223] 要求通信管理应使用E2E协议保护事件的传输且E2E保护应在事件API之后执行。示例在车辆的安全气囊系统中碰撞传感器检测到碰撞事件后通过通信管理向安全气囊控制单元发送触发信号事件。通信管理使用E2E协议确保信号在传输过程中不被篡改或丢失。如果没有E2E保护黑客可能篡改信号使安全气囊在不应触发的时候触发如在正常行驶中误触发对驾驶员和乘客造成伤害或者信号丢失导致安全气囊在碰撞时无法及时触发无法提供有效保护危及人员生命安全。 事件E2E信息提供[RS_CM_00224] 要求通信管理应将接收到事件的E2E信息提供给应用。示例在车辆的车门状态监测系统中车门状态传感器将车门开关状态作为事件发送给车辆控制系统。通信管理在接收到事件后将E2E信息如数据完整性校验结果、传输状态等提供给控制系统。如果控制系统接收到车门状态事件但没有E2E信息当车门状态数据出现错误如因干扰导致数据错误显示车门未关闭实际已关闭时控制系统无法判断数据的准确性可能触发错误警报如提示车门未关闭干扰驾驶员注意力影响驾驶安全。 方法传输保护[RS_CM_00400] 要求通信管理应使用E2E协议保护方法的传输对应用透明。示例在车辆的远程诊断系统中车辆向远程服务器发送诊断数据并接收服务器返回的诊断方法如更新诊断程序、调整参数等。通信管理使用E2E协议确保数据和方法在传输过程中的安全。如果没有保护在数据传输过程中可能被窃取或篡改导致车辆敏感信息泄露如车辆行驶数据、系统配置等或者接收到错误的诊断方法使车辆系统出现错误调整影响车辆性能和安全性。 方法E2E信息提供[RS_CM_00401] 要求通信管理应将接收到方法调用的E2E信息提供给应用。示例在车辆的自动泊车系统中当车辆与停车场管理系统进行通信接收泊车引导方法调用时通信管理将E2E信息提供给自动泊车系统。如果自动泊车系统没有收到E2E信息在接收泊车引导指令过程中无法判断指令是否完整和正确。若指令被篡改如引导路径被恶意修改自动泊车系统可能按照错误指令操作导致车辆碰撞障碍物损坏车辆甚至危及人员安全。 服务响应延迟检测[RS_CM_00403] 要求通信管理应提供接口通过监督预定义的响应期限在客户端检测E2E保护服务响应的延迟。示例在车辆的车载信息娱乐系统中当用户通过触摸屏操作请求播放音乐时信息娱乐系统向音频播放服务发送请求通信管理开始监督预定义的响应期限如500毫秒。如果由于音频播放服务故障或系统资源紧张等原因导致响应延迟超过期限通信管理检测到延迟并通知信息娱乐系统。信息娱乐系统可以向用户显示提示如“播放音乐响应延迟请稍候”避免用户因长时间无响应而重复操作导致系统进一步混乱。若没有这种检测机制用户可能因不知系统状态而频繁点击触摸屏分散驾驶注意力增加发生交通事故的风险。同时在车辆的远程控制系统中例如远程解锁车门的操作如果服务响应延迟检测不到位车主可能在等待解锁反馈无果的情况下采取其他不当操作如强行拉车门损坏车辆门锁或影响车辆安全系统的正常逻辑甚至可能引发车辆报警系统误判造成不必要的麻烦和安全隐患。 方法响应E2E信息提供[RS_CM_00404] 要求通信管理应将方法响应的E2E信息提供给应用。示例在车辆的自适应巡航控制系统中当车辆与前车距离过近时自适应巡航控制系统向发动机控制单元和制动控制单元发送减速方法请求并接收它们的响应。通信管理将响应的E2E信息如数据有效性、是否完整等提供给自适应巡航控制系统。如果没有这些E2E信息当发动机控制单元或制动控制单元的响应数据出现错误如因通信干扰导致减速指令执行结果数据错误自适应巡航控制系统无法判断数据的准确性可能做出错误决策如错误地认为车辆没有正常减速而继续发出更强的减速指令导致车辆急刹车影响车内乘客舒适性在高速行驶时还可能引发后车追尾事故。
更新和配置管理UCM
更新失败恢复[RS_UCM_00008] 要求UCM应在激活失败时支持恢复机制确保系统在更新失败后恢复到更新前的状态。示例在车辆的车载软件系统更新过程中如地图导航软件更新。如果更新过程中出现错误如下载数据损坏、更新程序出错等UCM的恢复机制应使系统回滚到更新前的版本保证导航软件仍能正常使用。若没有恢复机制导航软件可能无法启动或出现错误功能驾驶员在陌生道路上可能因失去准确导航而迷路增加驾驶时间和风险尤其是在不熟悉路况或高速公路上行驶时可能因寻找正确路线而分散注意力引发交通事故。 软件包一致性检查[RS_UCM_00012] 要求UCM应检查传输的软件包的一致性。示例在车辆的电子控制单元ECU软件更新时更新包从服务器下载到车辆。UCM检查软件包的一致性包括文件完整性、版本兼容性等。如果下载的软件包在传输过程中被损坏如部分数据丢失或与车辆当前系统不兼容如硬件版本不支持新软件功能UCM检测到不一致并阻止更新安装。否则安装损坏或不兼容的软件包可能导致ECU功能异常如发动机控制单元安装错误软件包后发动机可能出现抖动、动力下降或无法启动等问题严重影响车辆性能和可靠性甚至使车辆在行驶中抛锚危及行车安全。 意外中断恢复[RS_UCM_00027] 要求UCM应能够在意外中断后安全恢复。示例在车辆进行系统更新时突然车辆电源中断如电池电量耗尽或车辆意外熄火。当电源恢复后UCM应能够识别更新过程中的中断情况并采取相应措施如继续未完成的更新步骤或回滚到更新前的稳定状态。若UCM无法处理这种意外中断系统可能处于不一致状态部分更新的文件和未更新的文件混合导致系统功能混乱如车辆的安全系统可能因配置文件混乱而失效在后续行驶中无法正常发挥保护作用增加车辆发生事故的风险。 更新软件验证[RS_UCM_00030] 要求UCM应在激活过程中验证更新的软件确保软件能成功执行后才宣布激活成功。示例在车辆的高级驾驶辅助系统ADAS软件更新后UCM要求在实际运行环境中对更新后的软件进行验证例如进行一系列模拟驾驶场景测试检查传感器数据处理、决策算法等功能是否正常。如果没有验证机制或验证不充分更新后的ADAS软件可能存在隐藏错误在车辆行驶过程中无法正确识别障碍物或做出错误的驾驶辅助决策如错误地提示驾驶员变道或制动影响驾驶员对车辆的正常控制增加碰撞事故的可能性。
经典平台相关模块
看门狗管理器WDGM 安全完整性级别继承[RS_SAF_31101] 要求看门狗管理器应至少继承平台上运行的任何软件组件的最高安全完整性级别。示例在车辆的经典平台中同时运行着安全关键的制动系统软件组件如ASIL C级和非安全关键的灯光控制系统软件组件如QM级。看门狗管理器继承制动系统软件组件的安全完整性级别ASIL C级对制动系统软件进行严格监控。如果看门狗管理器没有达到相应安全级别在制动系统软件出现故障如陷入死循环时可能无法及时检测到并采取正确措施如触发系统复位导致制动失效严重危及车辆和乘客安全。 存活监测[RS_SAF_31102] 要求看门狗管理器应监测安全相关软件组件、应用程序和模块的存活状态。示例在车辆的发动机管理系统中发动机控制软件是安全相关的看门狗管理器定期监测其存活状态。如果发动机控制软件因内存错误或程序崩溃而停止运行看门狗管理器检测到该软件不再“存活”可以触发相应的恢复机制如重启发动机控制软件或进入安全模式。若没有存活监测发动机可能停止工作车辆失去动力在行驶过程中会导致危险情况如在高速公路上突然熄火可能引发后方车辆追尾事故。 控制流监测[RS_SAF_31103] 要求看门狗管理器应监测安全相关软件组件、应用程序和模块的控制流。示例在车辆的自动变速器控制软件中控制流规定了根据车速、油门踏板位置等条件进行换挡的逻辑顺序。如果软件因干扰或错误修改而偏离正常控制流如在低速时错误地执行高档位换挡逻辑看门狗管理器检测到控制流违规可采取措施如报警并尝试纠正控制流或触发系统复位。否则自动变速器可能出现换挡异常导致车辆动力传输不稳定影响驾驶舒适性严重时可能损坏变速器部件危及行车安全。 期限监测[RS_SAF_31104] 要求看门狗管理器应监测安全相关软件组件、应用程序和模块的检查点之间的持续时间是否在配置的最小和最大时间限制内。示例在车辆的安全气囊系统中有一个任务负责定期检查传感器状态检查点规定每10毫秒检查一次。如果看门狗管理器发现两次检查之间的时间超过了20毫秒最大限制可能是任务执行延迟或系统出现故障。这可能导致安全气囊系统无法及时响应碰撞事件在关键时刻无法及时弹出安全气囊无法有效保护驾驶员和乘客安全增加人员伤亡风险。 操作系统OS 内存保护[RS_SAF_31201] 要求操作系统应防止应用程序对其分配内存区域之外进行写访问。示例在车辆的电子控制系统中安全关键的发动机控制应用程序和非安全关键的诊断应用程序同时运行。操作系统确保发动机控制应用程序的内存区域受到保护防止诊断应用程序因软件漏洞如缓冲区溢出意外写入发动机控制应用程序的内存修改其关键数据如燃油喷射量设置、点火时间参数等。若没有内存保护发动机控制可能出错导致发动机工作异常如燃烧不充分、动力下降或熄火影响车辆正常行驶在行驶中可能引发安全问题。 时间保护[RS_SAF_31202] 要求操作系统应防止任何应用程序的定时故障传播。示例在车辆的多媒体系统中视频播放应用程序出现定时故障如因解码算法效率问题导致播放卡顿超过了预定义的播放时间预算。操作系统应防止该定时故障影响其他应用程序如车辆的仪表盘显示应用程序确保仪表盘能正常显示车速、转速等关键信息。如果定时故障传播仪表盘显示可能出现延迟或错误驾驶员无法及时准确获取车辆状态信息影响驾驶决策增加事故风险。 E2E保护 通信错误检测[RS_SAF_31301] 要求通信服务、E2E转换器和E2E库应提供机制检测软件组件之间信息交换中的错误考虑ISO标准中列出的所有故障并将E2E检查结果发布给应用程序。示例在车辆的分布式控制系统中不同ECU之间通过通信网络交换信息如发动机ECU与变速器ECU之间传输发动机转速和扭矩信息。E2E保护机制检测传输过程中的错误如数据重复、丢失、延迟、篡改等如因电磁干扰导致发动机转速数据传输错误。如果检测到错误E2E检查结果通知给相关应用程序发动机控制程序和变速器控制程序应用程序可以根据错误类型采取相应措施如请求重传数据、调整控制策略或进入安全模式。若没有这种检测机制变速器可能根据错误的发动机转速信息进行换挡操作导致换挡冲击、动力传输不平稳影响车辆驾驶舒适性和性能长期可能损坏变速器部件危及行车安全。 通信故障检测机制配置[RS_SAF_31302] 要求允许集成商配置检测通信故障的安全机制。示例在车辆的车联网系统中根据不同的通信场景和需求集成商可以配置不同的通信故障检测机制。例如对于车辆与云端服务器之间的重要数据传输如车辆位置信息、诊断数据上传等集成商可以配置更严格的检测机制如增加数据校验位、采用更复杂的加密算法等以确保数据的准确性和安全性。而对于车内一些非关键信息如娱乐系统与手机的蓝牙连接数据可以配置相对简单的检测机制。这样可以根据实际情况灵活调整通信故障检测策略在保证系统安全的前提下优化系统资源利用和性能提高系统整体可靠性和适应性。如果不能配置可能导致资源浪费在非关键通信中使用过度严格的检测机制或安全漏洞在关键通信中检测不足影响车辆系统的正常运行和安全性。
三、规范版本迭代更新历史
需求追踪
文档中的需求追踪部分提供了需求之间的映射关系明确了各需求的满足来源便于确认需求的实现情况确保系统开发符合规范要求保障系统安全性和功能性的完整性。例如[RS_Main_00010]“安全机制”这一要求由[RS_SAF_00001]、[RS_SAF_00002]等多个安全相关要求满足表明这些具体安全要求共同实现了整体安全机制的构建确保系统在执行、配置、更新等多方面具备相应安全保障以应对复杂的汽车电子系统运行环境避免因需求遗漏或错误关联导致系统安全漏洞或功能缺失。
变更历史
R22 - 11版本 新增要求包括[RS_SAF_00007]恢复失败、[RS_SAF_10039]检测数据意外更改、[RS_SAF_10040]恢复损坏数据、[RS_SAF_10041]检测通信故障机制配置、[RS_SAF_10042]检测时间同步违规等。这些新增要求进一步完善了系统在故障恢复、数据完整性和通信可靠性方面的规范如在数据处理中[RS_SAF_10039]和[RS_SAF_10040]的加入使系统能更好地应对数据损坏情况确保数据准确性和可用性避免因数据问题导致系统功能异常或安全事故。更改要求[RS_SAF_10001]软件组件安全初始化等多个要求被更改优化了相关功能的安全规范如对软件组件初始化机制进行调整使其更符合系统安全需求增强系统启动阶段的安全性防止因初始化不当引发后续运行问题。删除要求删除了[RS_SAF_21101] - [RS_SAF_21704]等一系列要求简化了规范内容去除可能冗余或不适用的部分使规范更加聚焦于核心安全需求避免因过多复杂或不必要的要求导致系统开发和维护困难。 R23 - 11版本 新增要求无新增要求表明该版本主要在已有需求基础上进行优化和调整。更改要求[RS_SAF_00005]数据损坏检测等多个要求被更改持续改进相关功能的安全规范如对数据损坏检测的范围或方式进行优化提高检测准确性和有效性确保系统能及时发现数据处理和通信中的故障隐患保障系统数据安全和稳定运行。删除要求删除了[RS_SAF_21401] - [RS_SAF_21403]等要求进一步精简规范提高规范的简洁性和可操作性避免因过多陈旧或不合理要求影响系统安全规范的实施和维护。 R24 - 11版本 新增要求无新增要求说明该版本主要侧重于已有需求的稳定和完善。更改要求无更改要求显示该版本在需求规范方面保持相对稳定为系统开发和安全保障提供了可靠的依据确保相关方在该版本下能依据稳定的规范进行工作减少因需求变动带来的不确定性和风险。删除要求无删除要求维持了规范内容的完整性和连续性保证了系统安全要求在该版本中的连贯性有助于系统的持续开发和安全维护使系统能持续稳定地满足安全规范要求避免因需求删除导致系统功能缺失或安全漏洞。
