目前功能安全标准 ISO26262 在汽车自动驾驶辅助系统设计过程中的应用，尤其是概念阶段的设计应用缺乏统一有效的方法。详细阐述了 ISO26262 标准第三部分概念阶段的内容和要求，包括相关项定义、功能安全周期启动、HARA 分析和功能安全概念，介绍了符合 ISO26262 标准进行概念阶段各部分设计的具体方法，以车道保持辅助 ( LKA) 为例阐述详细的设计步骤和分析过程。此方法已应用于某品牌汽车自动驾驶辅助系统的功能安全概念设计，为其他自动化相关驾驶辅助系统开展功能安全概念设计提供了一定的方法指导。
汽车自动化及自动驾驶是汽车行业未来发展的趋势，世界各国对该领域的研究如火如荼，先后开展了很多自动驾驶汽车的相关道路试验，取得了丰硕的成果。目前各国都已经给出了汽车自动化和自动驾驶发展规划，各大车企、汽车相关科研机构和组织对自动驾驶的发展阶段定义基本趋同，包括美国汽车工程师学会 SAE( society of automotive engineers) 、美国国家公路交通安全管理局 NHTSA( national highway traffic safety administration) 、欧洲博世( Bosch) 、中国汽车工程学会以及以长安汽车为代表的一批车企等，主要划分如下阶段: 无自动驾驶( Level 0) 、具有指定功能自动驾驶( Level 1) 、具有复合功能的自动驾驶 ( Level 2) 、具有限制条件的无人驾驶( Level 3) 、完全自动驾驶( Level 4) 。而目前主流的技术水平均处于 Level 1 和 Level 2 的阶段，即辅助自动驾驶阶段，只有像谷歌等极少数公司的技术已经进入 Level 4 阶段。
自动驾驶的实现依靠的是越来越复杂的电子电气系统的集成和控制，基于电子电气系统的功能安全问题渐渐凸显出来，成为汽车自动化过程中首当其冲需要解决的关键问题之一，为此国际标准化组织( ISO) 专门推出了 ISO26262———道路车辆功能安全标准，来为整个生命周期中与功能安全相关的工作流程和管理流程提供指导。
电子电气系统的开发设计越来越多将功能安全作为考虑的因素，所有满足功能安全标准 ISO26262 设计的电子电气系统和子系统，最初的设计依据均来自于顶层分析，即功能安全概念阶段的分析成果，因此合理的概念设计至关重要。
目前应用 ISO26262 标准开发设计实用功能系统的较多，对自动化各个阶段的功能系统尤其是自动驾驶辅助系统的研究应用相对较少，现有研究主要是 ISO26262 标准的整体应用，专门针对功能安全概念的研究文献屈指可数，可见此阶段还未引起研究人员足够的重视。以某汽车品牌在研自动驾驶辅助系统功能之一车道保持系统为例，设计出符合功能安全标准 ISO26262 的电子电气系统安全设计的具体执行方法，阐述了详细的内容和步骤，为开展后续系统设计和软硬件设计提供输出成果，并为其他技术人员开展相关系统的功能安全概念设计提供指导。
ISO26262 是 IEC61508 对电子电气系统在道路车辆方面的功能安全要求的具体应用，适用于道路车辆上特定的由电子、电气和软件组件组成的安全相关系统在安全生命周期内的所有活动。
图 1 表述了基于功能安全的产品生命开发周期，包括概念阶段、产品开发和生产发布之后 3 个阶段。
1) 概念阶段: 包括相关项定义( Part 3-5) 、安全生命周 期 启 动 ( Part 3-6) 、危害分析和风险评估 ( Part 3-7) 、功能安全概念( Part 3-8) 四部分内容。根据产品的功能定义开发相关项定义，并启动产品安全开发生命周期，后以相关项定义为基础进行 HARA 分析，得出产品的功能安全目标和 ASIL 等级，再进行概念分析得出功能安全要求及对应的 ASIL 等级。
2) 产品开发: 基于概念阶段分析得出的功能安全要求，得出具体的技术安全要求，包 括 系 统 层 ( Part 4) 、硬件层( Part 5) 和软件层( Part 6) 的技术安全要求，并指导各个层级的设计开发; 产品设计开发完成后，需要通过功能安全确认( Part 4-9) 和功能安全评估( Part 4-10) 才能允许产品生产发布( Part 4-11) 。其中，安全确认除了对功能安全要求的所有交付物进行确认，还包括支撑概念阶段分析的控制能力的假设、外部措施的使用及其他技术的应用。产品开发过程中应该同步定义产品的生产计划 ( Part 7-5) 和运行计划( Part 7-6) 。
3) 生产发布之后: 基于产品的生产计划和运行计划，执行基于功能安全要求的的生产、运行、服务和报废过程( Part 7-6 和 Part 7-6) 的活动。上述活动中若有修改的情况，则应返回到对应的生命周期阶段进行迭代。
ISO26262 标准共分十章，在产品开发生命周期中，第一、二、八、九、十章适用整个周期，第三、四、五、六、七章则需要遵循设计开发的先后顺序。第三章概念阶段的工作成果是后面所有开发工作的基础，直接决定着接下来产品开发关于功能安全要求的执行质量，因此非常重要。
概念阶段
1. 相关项定义
对相关项进行定义和描述，及其与环境和其它相关项的依赖性和相互影响，包括其功能、边界接口、环境条件、法规要求和危害等，方便设计开发人员能够充分理解相关项，为后续阶段的活动提供支持。
车道保持辅助( lane-keeping assistance，LKA) 是部分自动化阶段的辅助驾驶功能，驾驶员无意识偏离车道时，能够监测并主动纠偏。对其进行相关项定义应包括如下内容:
1）功能理解
图 2 是 LKA 功能的功能架构及边界图，在功能开启后，LKA 通过 CAN 网络搜集各个要素( Element) 提供的相关信息，部分详细如下:
Element 1: 提供开关信息
Element 2: 提供车速信息
Element 3: 提供发动机转速信息
Element 4: 提供方向盘转角信息
Element 5: 提供外界温度信息
Element X: 接收 ECU 指令并执行显示
Element Y: 接收 ECU 指令并执
……: 其他输入和输出信息
所有信息经过 LKA 的 ECU 处理，判断出车辆车轮外边缘距车道线的距离是否满足纠偏要求，并输出相应指令给执行要素( 如 Element X 和 Element Y) ，在需要的时候将车辆纠偏回正常车道内。
相关项定义中的工作模式和条件应该尽量包含系统实际工作时所有的模式及其依据的条件，考虑到开发之初设计的不完全成熟，故允许后续的改进和更新。如表 1 为 LKA 系统具有的工作模式及对应的条件。
表 1
2）边界接口
定义相关项与其他相关项和环境之间的交互作用和相互影响、功能在所涉及的系统和要素间的分配等。如图 2，通过边界线将系统的组件和要素划分成两部分，边界内的要素与系统直接相关、会影响系统功能实现，如 Element 1 系统开关，其开闭触发状态直接决定系统能否开始工作，因此需要划归边界内; 边界外的要素与系统间接相关、会影响系统性能，如提供外界温度信号的 Element 5，其提供的信息作为处理器算法的补偿，准确性仅影响处理器计算偏差的大小，不会影响系统本身功能的使用，因此需要划归边界外; 此外有些要素可能具有不同的功能，在系统工作时参与多种角色，既提供输入信息，又担负 ECU 指令信息显示或执行的任务，或者同时负责其他系统的相关角色，若无法在边界架构图中画出，则需要在相关项定义中明确描述。
接口定义包括机械接口和因边界线划分要素的系统内部要素接口和外部要素接口，此外系统要素间、要素与总线间的通信也应该定义明确。
3）环境条件
本节需要定义系统运行环境，如温度、海拔、湿度、振动、电磁干扰等; 系统运行要求，如工作电压、电流等; 其他的限制条件。若不明确可以不用定义。表 2 列举了 LKA 系统运行的环境条件。
LKA 系统在以上要求的环境条件限制内出现的失效属于功能安全的范畴，超出以上环境条件功能安全不再保证有效。如环境温度大于 NN°C，系统可能无法正常工作; 摄像头被遮挡，系统也无法正常工作; 其他的限制条件如大雨大雪天气也会影响系统的正常工作等。
4）法规要求
应明确列举相关项系统功能符合哪些法律法规、国家标准和国际标准。如 LKA 功能满足的法规包括 ECE R10．05、ISO 7637、GB /T 18655 等，详细可以定义到满足相关法规的具体章节。
5）危害定义
本节需要定义相关项系统已知的失效模式和危害，造成的潜在后果，包括系统要素、软硬件失效对系统造成的危害。如 LKA 系统依靠摄像头提供精确的车道线信息，若摄像头出现故障，需要系统关闭并响应相应提示，系统恢复需要维修或更换摄像头至正常。
2. 启动安全生命周期
安全生命周期启动需要确定本相关项系统是新的开发还是对现有相关项系统进行修改，或是对现有相关项系统的重用。新的相关项开发需要继续进行下一步危害分析和风险评估，对现有相关项进行修改需要评估修改部分对相关项的影响并进行影响分析，对现有相关项系统的重用需要集成和沿用与现有相关项安全相关的文档。讨论的 LKA 系统为新开发的相关项，故对修改相关项和重用相关项内容不做描述。
3. HARA 分析
危害分析和风险评估( hazard analysis and risk assessment，HARA) 。其目的是对功能潜在故障进行识别并对其产生的危害进行分类，确定功能安全目标并制定相应的措施以避免系统功能不合理的风险。
HARA 分析流程如图 3，根据相关项定义，通过潜在危害识别确定整车级危害，然后通过 ASIL 分析确定每一个整车级危害的 ASIL 等级，最后确定相关危害的安全目标，并输出功能安全概念。
图 3
危害分析和风险评估( hazard analysis and risk assessment，HARA) 。其目的是对功能潜在故障进行识别并对其产生的危害进行分类，确定功能安全目标并制定相应的措施以避免系统功能不合理的风险。
HARA 分析流程如图 3，根据相关项定义，通过潜在危害识别确定整车级危害，然后通过 ASIL 分析确定每一个整车级危害的 ASIL 等级，最后确定相关危害的安全目标，并输出功能安全概念。
1）确定整车级危害
目前确定整车级危害使用较多的方法有危害和可操作性分析 HAZOP( hazard and operability analysis) 、头脑风暴、预先危险性分析 PHA ( preliminary haz丰ard analysis) 等，相对来讲，HAZOP 分析系统性、完善性和结构性较好; 头脑风暴和其他 PHA 方法在场景分析的准确性和全面性方面，依赖分析人员具备富的经 验、专业知识等因素，导致分析效果不稳定。因此 LKA 功能的危害分析采用 HAZOP 分析方法。
HAZOP 提供了 12 种失效模式，通过对每种失效模式的分析准确全面的找出潜在危害，包括过度、不足、失效、衰减、间歇性、无规律、震荡、错误、相反、延时、无响应。
表 3 是 LKA 功能的 HAZOP 分析表，对 LKA 功能应该分析上述 12 种失效，确定每种失效导致的整车级危害，并确定需要考虑的多种运行环境，给出可能的控制措施，最后将所有属于危害事件的整车级危害汇总，以进行后续分析。
表 3
汽车安全完整性等级( automobile safety integrity levers，ASIL) 。ASIL 等级是通过暴露度、严重度、可控性三个维度影响因子的分析确定，共分 ASILA、B、 C、D、QM 5 个等级，其中 QM 等级属于质量管理范畴，不在功能安全考虑之内。
(1) 暴露度。对车辆运行工况和驾驶环境的评估。可以通过运行工况占车辆生命运行周期时间比例或者发生频率来确定。暴露度等级定义和分类见表 4。
表 4
(2) 严重度。相关项系统功能在特定的环境条件下发生失效，由潜在危险造成人员伤害的严重程度，包括对本车和其他道路使用车辆的驾驶员、乘员以及路上行人的伤害等。严重度等级定义和分类见表 5。
表 5
(3) 可控性。评估驾驶者或其它道路使用者当危害发生时对危险情况的控制并能避免伤害的概率。严重度等级定义和分类见表 6。对 HAZOP 分析确定的整车级危害继续进行 ASIL分析，分析每一个危害的 E、S、C 等级，并根据表8确定每一个整车级危害的 ASIL 等级。本节以 LKA 功能发生误纠偏和纠偏不足两个整车级危害为例说明 HARA分析过 程和ASIL等级确定，详见表 7。
表 6
表 7
3）确定安全目标
针对驾驶员能感知的整车级危害，从管管人员角度提出为避免危害需要达到的目标，是顶层的功能安全需求。应该为每一个整车级危害确定一个安全目标。可以合并所有整车级危害中类似的安全目标，其 ASIL 等级为相应危害分析中 ASIL 最高的等级。表 9 为通过表 7 的 HARA 分析确定的 LKA 功能的安全目标及对应的 ASIL 等级。
表 9
4. 功能安全概念
功能安全概念源于功能安全目标，包括安全状态、安全需求、安全需求在相关项架构要素的分配，明确一定的安全措施与安全机制。具体包括: 故障检测和失效缓解方法; 过渡到安全状态及故障容忍时间间隔; 容错机制，即一个故障发生时不会直接导致违反安全目标( S) 并保持该功能在安全状态; 故障监测与报警; 从不同功能发送过来的多个请求中选择最适当的控制要求执行的仲裁逻辑; 如图 4 功能安全概念各状态变换的时间间隔定义。
图 4
功能安全概念需要通过以下 3 个方面展开:
1) 安全状态的提出。安全状态是系统或功能不存在任何由于系统导致的不能接受的风险的一种状态，包括功能正常的运行、执行、操作状态、功能故障后的降级反应、功能故障后关闭并报警。本例 LKA 系统在发生故障时，在现有功能本身上述 3 种机制均无法达到有效的安全状态，故无对应的有效安全状态。
2) FSR 的提出。功能安全需求( functional safety requirement，FSR) 。应基于安全目标和安全状态，并考虑初步的架构与边界范围来提出安全需求( 如图 2) ，通过表 10 列举出系统要素及其功能，为每一个要素编号。
为每一个安全目标至少提出一条安全需求。以下述 LKA 系统的安全目标为例:
安全目标: 避免误纠偏( ASIL D) 。
具体的分析过程见表 11。
表 11
安全需求的 ASIL 等级分解和分配依据本节 3) 部分的规则，故障容忍时间间隔需要在后续的设计过程中通过技术安全需求提出。
ISO26262 要求其他相关内容在功能安全概念中明确( 如果具有) ，包括: 可用的驾驶模式; 紧急操作时间; 转换成安全状态的条件; 驾驶员和其他处于危害中的人员的假设行为; 避免危害的外部措施。
3) ASIL 等级要素的分配和分解。基于安全目标提出具体的安全需求，将安全需求分配到具体的系统要素。系统要素包括子系统和零部件，通过分配 ASIL 等级确定其具体的安全需求。多个等级分配给同一要素，需选取最高的 ASIL 等级作为该要素的功能安全等级。
当分配给某一要素的 ASIL 等级过高，导致技术实现难度增加或成本增加等问题，就需要采用 ASIL 分解方法实现“降级”，以满足开发和安全的综合要求。被“降级”分配的要素之间功能相互冗余且具备独立性。分解规则如表 12。
表 12
基于初步架构图和安全需求分解和要素分配，将分配 ASIL 等级的要素重新编号，绘制完善的安全架构图，如图 5。
图 5
基于完善的安全架构图，通过安全需求的分解 和要素的分配，得出安全要素需求汇总表，如表 13。本部分安全需求为功能安全概念阶段的最终输出 物，是后续系统设计、软硬件设计的基础。
1) 根据功能安全标准 ISO26262 第三章概念阶段的内容，设计出标准应用具体方法，给出了设计步骤和分析过程。
2) 应用设计的方法对车道保持辅助( LKA) 进行案例分析，得出符合 ISO26262 标准的分析成果。
3) 所设计的方法为 ISO26262 标准在概念阶段的设计应用提供了借鉴，为其他自动化系统开展功能安全概念设计提供了方法指导。
4) 所设计的方法目前已应用在某车厂多个驾驶辅助系统的设计开发中，如自适应巡航( automatic cruise control，ACC) 、车 道 偏 离 预 警 ( lane depart warning，LDW) 、自动紧急制动( automatic emergency brake，AEB ) 、自 动 泊 车 辅 助 ( automatic parking assist，APA) 等，为相关产品开发提出了功能安全要求，系统全面地找出导致产品失效的原因并针对性的施加措施，能够有效降低产品的非预期失效风险，极大的提高了产品的安全性。如您需要相关支持，可致电18917451722
ISO21448的引入
随着ADAS系统越发复杂，引入了各种复杂的传感系统（如Radar、Lidar）和算法（如machine learning）等。这些传感系统和算法在执行预期功能时（未发生故障），其态势感知能力（situational awareness）在某些情况下能够直接影响安全性。举个例子，Uber自动驾驶汽车2018年3月在美国意外撞击致死一名行人。当时行人正穿过一段未被路灯直接照亮的道路，传感系统（Radar和Lidar，未发生故障）采集了行人的信息，在撞击发生的前6秒被车载软件依次解读为未知物体、车辆和自行车。该事故的最终原因（究竟是传感系统、软件还是其它因素）有待官方调查结果，但仍可见预期功能可能对安全性的极端影响。Safety Of The Intended Functionality （SOTIF）的概念越发受到重视。
SOTIF的关注点是：由功能不足、或者由可合理预见的人员误用所导致的危害和风险。例如，传感系统在暴雨、积雪等天气情况下，本身并未发生故障，但是否仍能执行预期的功能。而功能安全关注于与安全相关的失效，信息安全关注于与安全相关的威胁。
SOTIF在很大程度上基于假设场景来进行分析。ISO/PAS 21448对场景的定义是：“description of the temporal development between several scenes in a sequence of scenes”，即一系列片段（scenes）中几个片段（scenes）之间的时序发展描述。
ISO/PAS 21448将场景（scenarios）划分为如下图所示的4个区间，分别为（1）已知-安全、（2）已知-不安全、（3）未知-不安全和（4）未知-安全。目的是尽可能缩小位于区间（2）和（3）中的场景（scenarios）比例，即将确保场景（scenarios）控制在安全的区间。
一些典型的自动驾驶的假设场景（scenarios）如下：
理论上，SOTIF应该与ISO26262中的流程衔接，比如作为早期HARA的输入、后期确认（Validation）阶段的输入等等。参见下图。将SOTIF与功能安全衔接的潜台词之一，是
SOTIF应该采用与功能安全一致的风险接受准则。
