01. 简介

文中将探讨功能安全标准ISO 26262以及功能安全标准ISO 21448。文章将解释应用ISO 26262的目的，以及由于汽车行业复杂性的不断提升，该标准如何通过 ISO 21448（SOTIF，预期功能安全）得到补充。为此，需明确ISO 26262的局限性，以及SOTIF应用的必要性。

随着技术的发展和系统复杂性的不断增加，越来越多ISO 26262单独无法覆盖的问题逐渐显现。安全方面的考量不断增多，且随着新型舒适系统和辅助系统的出现而持续变化。因此，由于技术及其复杂性的不断变化，必须改进现有方法，开发新的额外方法以保障最终产品的安全性，并将其与已有的成熟方法结合应用。

本文将阐述这一趋势对现代转向系统的影响，以及在此背景下，如何看待ISO 26262、ISO 21448与失效模式与影响分析（ FMEA ）等传统方法之间的协同作用。如今，汽车制造商已能够让车辆在特定的运行限制和区域内实现自动化行驶。但要解除所有运行限制，实现车辆的“完全自动驾驶”，还需采取哪些措施？目前，相关法规、标准和指南已在逐步完善，但在实践中是否真的可行？

02. 电动助力转向系统

近年来，随着技术的持续发展和自动化程度的不断提高，转向系统发生了巨大变革。此前广泛应用的液压助力转向系统正逐渐被纯电动助力转向系统（EPS）取代。与液压助力转向系统相比，电动助力转向系统（EPS）在多个方面具有优势。

助力转向系统（又称伺服转向系统）具备机械结构，可在转向操作中为驾驶员提供辅助。它能放大驾驶员作用在方向盘上的转向力，从而降低转向所需的作用力。

传统液压伺服转向系统通过液压油缸（伺服机构的一部分）放大转向力。其中，方向盘与控制车轮转向的 转向传动机构 之间存在直接的机械连接。该机械连接在方向盘一侧设有扭簧（通常为扭杆形式），允许方向盘与转向传动机构之间产生微小的相对运动。为产生助力，驾驶员施加的相对运动通过液压阀被检测到，进而使液压油缸内建立压力。因此，助力大小直接取决于驾驶员施加的转向力。

当伺服转向系统失效时，驾驶员仍能在无助力的情况下操控车辆。此时转向操作会明显变得困难，但机械连接可作为备用保障，使驾驶员能够将车辆安全地驶至路边。

电动伺服转向系统的基本功能与液压伺服转向系统类似，但扭簧和液压阀被扭矩传感器取代，液压油缸则由电动机替代。不同的组件布置方式各有优缺点，可根据具体应用场景进行调整。例如，图1中的伺服单元就集成在转向柱上。

图1：带有伺服单元的电动转向系统

这种布置方式在小型汽车中十分常见，因为小型汽车体积和重量较小，不需要很大的转向力。这一点至关重要，因为在这种结构中，转向力需通过转向柱、转向中间轴和转向小齿轮传递，而这些组件会限制最大转向力的输出。此外，该伺服单元位于车辆内部，无需满足严苛的环境技术要求，例如无需具备防水性能。而且，车辆内部的温度范围相对较小——高温往往会对电子控制单元（ECU）中的电子元件造成不良影响。不过，这种布置方式也存在缺点：伺服单元产生的噪音可能会干扰驾驶员，影响其注意力。此外，这种布置方式下的碰撞安全性通常也是一个挑战。

图2所示的伺服单元则直接与转向器或转向小齿轮相连。这种结构使系统能够提供更大的转向输出，因为转向力无需再通过转向柱和转向中间轴传递。因此，其转向助力足以确保从小型轿车到运动型多用途汽车（SUV）等各类车型实现舒适且安全的转向操作。但该布置方式下的伺服单元不再位于车辆内部，因此必须能够承受水、灰尘、温度和振动等环境因素的影响。

图2：带有伺服单元的电动转向系统

传感器会检测作用在转向柱上的扭矩以及方向盘的位置。电子控制单元（ECU，通常安装在转向器或转向柱上）会根据行驶工况，结合电机为转向系统提供助力扭矩。不同行驶工况下的助力大小不同，在开发过程中会根据具体车型进行调整。这样一来，转向系统的响应特性可根据客户需求以及车辆的特定参数（如变刚度悬架系统和可变阻尼减震系统）进行个性化调整，从而实现最佳的操控性和行驶性能。

除技术优势外，电动助力转向系统（EPS）还具有环保优势。在液压转向系统中，液压泵需持续运转，因为它通过皮带传动与内燃机相连。这意味着液压泵的转速与发动机转速同步，无论是否进行转向操作，转向系统中始终有油液循环。由于液压泵需按照发动机怠速转速设计，因此在发动机高转速时会产生不必要的大流量。

而电动助力转向系统（EPS）通过电动机提供助力，仅在需要时才启动转向助力功能，这种工作模式被称为“按需供电”（Power-On-Demand）系统。与传统液压转向系统相比，这可使燃油消耗量降低高达0.8升/100公里。

此外，电动助力转向系统无需使用连接液压泵和转向器的高压液压管路。这一改进简化了车辆的维护和制造流程。而且，电动助力转向系统无需调整即可适配不同类型的发动机。相比之下，传统液压转向系统由于皮带传动的限制，横向布置的四缸发动机与V型八缸发动机的液压转向系统布置方式通常不同。

电动助力转向系统（EPS）的发展还为增加改进功能创造了新可能。其关键优势之一是转向系统具备自适应特性，可与辅助系统协同工作。此外，方向盘扭矩可独立于车辆速度和助力扭矩进行调节。这样一来，便可解决一些设计矛盾，例如停车时因轮胎摩擦大而需要大助力扭矩但方向盘扭矩小，以及高速行驶时需要小助力扭矩但方向盘扭矩大的问题。

电动助力转向系统常见的附加功能包括车道保持辅助、侧风补偿，以及与其他系统协同工作的自动泊车功能。此外，辅助功能还能为驾驶员提供适当的转向建议，帮助其在特别危险的行驶工况下做出正确反应。例如，当车辆发生过度转向，或在μ-Split路面（左右路面摩擦系数不同）上制动时，电子稳定程序（ESP）可向转向系统请求额外的绕车辆垂直轴的扭矩，以辅助驾驶员。

2.1 电动助力转向系统的安全技术需求

在电动助力转向系统的开发过程中，安全技术需求与技术挑战同等重要。系统各项功能本身的安全性必须得到保障，且安全应成为产品的基本组成部分。

要开发功能安全的转向系统，必须考虑整个安全生命周期，包括产品的概念设计、规划、开发、实施、调试以及维护等阶段。例如，ISO 26262中就详细列出了各个阶段的具体工作步骤（详见第4.1节 “ISO 26262的基本结构”）。

安全概念的作用是确保能够妥善应对可能出现的故障。首先，在硬件层面，通过采用符合当前技术水平的机械设计，可从源头避免某些故障的发生。其次，通过合理设计的安全概念，能够快速检测故障，并将系统切换至安全状态。当然，前提是系统存在这样的安全状态。

在大多数电动助力转向系统（EPS）应用中，关闭转向助力即可使系统进入安全状态（Safe State）。这意味着EPS不得再提供任何转向助力。若要退出安全状态，通常需要重启系统，并确保电子控制单元（ECU）成功完成初始化。该安全状态的前提是，根据联合国欧洲经济委员会法规R79（ECE R79）的要求，车辆的机械转向能力得到保障。

图3展示了电动助力转向系统（EPS）各系统状态之间的关联示例。从图中可以看出，只有在初始化成功后，系统才能进入“EPS激活”状态，且仅在该状态下才能提供转向助力。如图3所示，当自检失败或系统在激活状态下出现故障时，系统会进入安全状态。对于安全关键型故障，必须在故障容忍时间间隔（FTTI）内，通过关闭路径将系统切换至安全状态，以完成故障处理。故障容忍时间间隔（FTTI）是指从关键故障发生到应对措施生效之间的最大可接受时间。该时间必须足够短，以确保故障在此期间不会引发不可接受的风险。因此，故障检测和后续的故障应对措施必须在该时间内完成。

图3：电动转向系统的系统状态

为判断风险是否可接受，需依据ISO 26262进行危害与风险分析。在不考虑安全措施的情况下，先确定所有故障的汽车安全完整性等级（ASIL）。以下为普通电动助力转向系统（EPS）的 ASIL 等级划分示例：

·  转向助力失效→ QM（质量管理级，无特定ASIL需求）

·  转向系统卡滞或卡死→ ASIL D

·  转向助力过大→ ASIL D

·  转向助力不足→ QM

·  非预期提供转向助力→ ASIL D

随后，在安全概念中为这些故障定义安全目标。通过实现保障这些安全目标的功能，可将风险降低至可接受的残余风险水平。

安全目标（Safety Goals）示例如下：

1. 系统必须能够检测可能导致转向系统卡滞或卡死的故障，并依据ASIL D的要求将系统切换至安全状态。

2. 系统必须能够检测可能导致转向助力过大的故障，并依据ASIL D的要求将系统切换至安全状态。

ISO 26262并未对机械组件提出特殊要求，但仍需通过设计避免机械设计中的故障。在机械设计开发过程中，可通过采用失效模式与影响分析（FMEA）等适当方法来确保这一点。例如，方向盘与车轮之间机械连接的失效会导致严重后果，但通过合理的组件尺寸设计可避免此类情况发生。

2.2 线控转向 与功能安全

线控转向（Steer by Wire）系统是一种车辆转向系统，其方向盘与车轮之间不存在机械连接。驾驶员在方向盘上施加的转向动作由传感器检测，并由电子转向控制单元处理为转向指令。该指令通过电气方式传递给执行器，由执行器驱动转向轮完成转向动作。由于缺少机械连接，路面反馈无法直接传递至方向盘，因此需要通过反馈执行器模拟转向力反馈以及路面状况对方向盘的影响。

这种“线控”（by Wire）技术最早在汽车行业的应用是电子油门踏板，它取代了传统的机械油门拉索。

由于线控转向系统通过纯电气方式传递转向角度，人们普遍认为其技术可控性不如机械或液压系统。受电子组件随机失效特性的影响，人们对其信任度相对较低。

传统电动助力转向系统（EPS）在伺服助力失效时，仍能依靠机械连接作为备用保障，确保转向功能的可用性。而为了保证线控转向系统的持续可用性，系统必须能够容忍单个组件的故障，并能切换至冗余组件。系统的可靠性与功能维持能力、危害潜力及安全性直接相关。因此，线控转向系统对可靠性和功能安全的要求与SAE 5级系统（详见第3.1节）相当，需按照相应标准进行开发。在SAE 5级系统中，由于无需驾驶员参与，同样不存在备用保障，因此系统需具备极高的可靠性和安全性。

线控转向系统必须满足最高的自身安全需求，因为在系统失效时驾驶员无法进行干预。因此，线控转向系统的制造商必须证明，系统功能失效不会导致转向功能丧失。所有关键功能必须至少采用双通道设计，以实现系统冗余。

电气或电子系统的基本安全特性包括可靠性、可用性和安全性。在功能安全领域，可靠性指系统在规定时间内实现预期功能的概率。而可用性则指系统在整个生命周期内的任意时刻处于可运行状态的概率。可用性由平均故障前运行时间（MTTF）和平均修复时间（MTTR）计算得出，公式如下：

可用性 = MTTF / (MTTF + MTTR)

该计算基于纯统计数据，未考虑人为因素。当MTTF值较大且MTTR值较小时，系统可用性较高。MTTF值较大意味着设备失效频率低，即失效率低。

图4：各个错误率的示意图

以车辆为例，可靠性可理解为车辆无故障到达目的地的概率；可用性则指车辆当前处于可运行状态、无需维修的概率；而安全性则指车辆不会对人员造成危险。

2.3 故障安全（Fail Safe）与故障运行（Fail Operational）

随着自动化程度的提高，越来越多的电气或电子系统主动参与车辆控制。因此，在故障情况下不能简单地关闭系统，否则可能对人员造成主动危险。这就要求系统在故障情况下仍能维持基本功能的运行。

“故障安全”（Fail Safe）是指当某个组件发生故障时，系统会切换至被动安全状态。对于传统电动助力转向系统（EPS）而言，关闭助力功能即可实现故障安全。这种设计之所以基本可行，是因为即使转向助力失效，驾驶员仍可依靠机械连接安全地操控车辆。但在某些情况下，故障（如转向助力过大）在高速行驶时可能会导致严重后果。此时，安全概念会检测到该故障，并采取“故障安全”措施——关闭转向助力。若系统因瞬时故障引发功能失效，通常在复位和自检周期完成后即可恢复正常运行。

图5展示了这种策略：失效发生时，系统立即切换至安全状态；系统修复完成后，恢复至可运行状态并重新进入运行状态。但若失效并非由瞬时因素等引起，系统频繁出现失效则会导致可靠性和可用性问题。

图5：文件安全系统

“故障运行”（Fail Operational）策略是一种故障处理方式，即在故障情况下系统不会完全关闭。在某些应用场景或系统运行阶段，关闭系统可能会带来安全风险，对人员造成危害。因此，在这些场景或阶段，必须采取容错措施，确保系统在故障情况下仍能进入应急运行状态，维持基本功能。为保障系统功能，故障运行系统需具备冗余设计，通常采用结构冗余、功能冗余、信息冗余和时间冗余等容错措施。

图6展示了故障运行策略：首次故障发生时，系统不会像故障安全系统那样立即切换至被动安全状态，而是进入降额运行状态。以转向系统为例，此时基本转向功能仍可正常实现，车辆仍可操控。但若发生第二次故障，则可能导致系统进入不安全状态。因此，在故障运行模式下，通常需要采取运行限制措施（如降低车速），以应对可能发生的第二次故障。

图6：故障运行系统

故障运行策略已应用于转向系统，这是因为车辆正逐步向更高自动化等级发展（即SAE 3级、4级和5级）。在SAE 4级和5级系统中，驾驶员不再被视为备用保障，因此系统必须具备极高的可靠性和安全性。通过高可靠性的系统架构，即使发生首次故障，系统仍能维持全部或部分功能。这类系统对可靠性、可用性和安全性的要求极高。

根据SAE等级的不同，原始设备制造商（OEM）可能只需提供数秒至数分钟的备用功能。在SAE 3级系统中，若出现故障，系统会通知驾驶员并要求其接管车辆控制权；而在SAE 4级系统中，即使驾驶员未接管，系统也需自行将车辆安全停靠至安全区域。

图7：自动驾驶等级与故障安全到故障运行的过渡

原则上，故障安全控制通道的组件（从传感器到执行器）可复用至故障运行系统。最简单的实现方式是将控制通道加倍，并为每个通道配置独立的传感器、执行器、计算单元、布线，尤其是独立的电源、时钟和复位系统。随后，通过逻辑判断确定某一通道是否存在故障，并将故障通道关闭。该逻辑可集成在各通道中（作为自检功能），也可独立设置。若采用独立逻辑，则形成第三个通道，可实现“三取二”（2-out-of-3）的决策机制。若需进一步提高可用性，可增加更多通道，通过多数表决确定正常工作的通道。

在所有情况下，避免共因失效（Common Cause Failures）都至关重要。例如，若多个通道共用同一电源，一旦电源失效，所有通道都将无法工作，故障运行模式也将无法实现。

03. 自动驾驶的基本工作原理

自动驾驶车辆依赖传感器、执行器、复杂算法、机器学习系统和高性能处理器。车辆通过分布在不同位置的多个传感器，实时构建并更新周围环境的虚拟模型。例如，雷达传感器与摄像头配合可确定周围其他车辆的精确位置；摄像头可识别交通信号灯、交通标志和行人等；激光雷达（LiDAR，Light Detection and Ranging）传感器向周围环境发射光脉冲，通过测量反射时间确定与车辆及其他物体的距离；车辆还可通过全球定位系统（GPS）接收卫星信号，确定自身精确位置。此外，自动驾驶车辆可通过移动通信和无线局域网（WLAN）与其他车辆及数据源进行通信，提前向其他道路使用者预警潜在障碍物。

复杂的软件对所有传感器信息进行处理，规划期望行驶路径，并向车辆执行器发送指令，控制车辆的加速、制动和转向。软件中的固定编码规则、避障算法、预测建模和目标识别功能，可帮助车辆遵守交通规则并避开障碍物。例如，当车辆识别到行人并确定其速度和运动方向后，可通过概率计算预测行人的后续运动，并采取前瞻性动作。

与人类驾驶的车辆相比，自动驾驶车辆具有潜在优势。其中最重要的优势之一是可能提高道路交通安全。每年，由人为失误导致的交通事故造成大量人员伤亡。而自动驾驶车辆的软件不会分心、反应速度更快、始终遵守交通规则且能持续适应路况，因此有望减少交通事故伤亡人数。此外，通过车辆间的通信可实现交通的全局协调，从而缓解交通拥堵。

然而，要充分发挥这些优势，车辆各系统必须为自动驾驶场景做好准备。

3.1 SAE 1-5级系统的要求

“自动驾驶”是一个社会各界广泛讨论的术语，但不同人对其理解存在差异。从技术定义来看，“自主”（autonomous）是人工智能领域的常用术语，指系统能够独立做出决策并拥有决策权。随着时间的推移，该术语的含义已不再局限于“决策”本身，而是扩展到整个系统功能，成为“自动化”（automated）的同义词。因此，“自动驾驶车辆”这一表述掩盖了一些关键问题，例如车辆是否依赖与外部设备的通信来获取和收集数据。

某些自动驾驶系统若具备独立决策能力，则可称为“自主”系统；但若依赖与外部系统的通信或协作，则更适合称为“协同”系统而非“自主”系统。此外，在法律层面，“自主”指自我管理能力。从这一角度来看，“自主”用于描述自动驾驶也存在问题——即使是最先进的自动驾驶系统（ADS）也并非“自我控制”，而是基于算法运行并遵循用户指令。

为统一对不同自动驾驶等级的理解，美国汽车工程师学会（SAE）制定了J3016标准。

SAE J3016标准将自动驾驶等级分为6级：SAE 0级至2级系统由驾驶员监控行驶环境；SAE 3级至5级系统则由系统监控行驶环境。

· SAE 0级： 驾驶员完全负责车辆控制，执行所有关键操作（如加速、制动和转向）。车辆可能配备倒车摄像头、盲点监测等辅助功能，但这些功能不承担关键操作，因此仍属于0级。

· SAE 1级： 驾驶员仍主导车辆控制，但首个自动化系统开始主动介入，在特定场景下部分接管车辆控制（非完整的车辆控制）。例如，自适应巡航控制系统（ACC）激活后仅控制车辆的加速和制动，该功能通常用于高速公路行驶。此时驾驶员可将脚从踏板上移开，但必须始终负责转向操作，并在故障时随时准备接管车辆。

· SAE 2级： 车辆可在一定时间内完全自主执行部分运行。例如，车辆可同时实现车道保持和速度控制，这需要将车道保持辅助系统（LKAS）与自适应巡航控制系统（ACC）结合使用。此外，无需驾驶员操作方向盘的自动泊车功能也属于SAE 2级。在车辆执行上述操作时，驾驶员可短暂将手离开方向盘，但必须持续监控辅助系统，并在故障时能够立即介入。

· SAE 3级： 车辆可在限定时间内自主执行特定驾驶功能，无需驾驶员监控。例如，车辆可结合自适应巡航控制系统（ACC）和车道保持辅助系统（LKAS），在合适的行驶场景下自动超越其他车辆。此时，系统首次完全负责周围环境监测。理论上，驾驶员在系统激活期间可阅读报纸等，但必须在系统发出请求时随时准备接管车辆。系统会通过声光提示提前通知驾驶员接管，因此SAE 3级也被视为“自动驾驶的入门级”。

· SAE 4级： 车辆的自动驾驶系统（ADS）可在其定义的运行设计域（ODD）内自主执行所有驾驶功能。运行设计域（ODD）的参数包括：速度、环境（城市交通、乡村道路、高速公路）、环境条件（天气、时段）、交通状况等。在运行设计域外，仍需人类控制。车辆可识别自身是否超出运行限制，并及时向当前未活跃的驾驶员发出警告。若驾驶员未接管，系统会将车辆切换至安全状态。目前，相关标准尚未明确规定所需的提前警告时间，行业内的讨论范围从30秒到数分钟不等。

· SAE 5级（完全自动驾驶）： 车辆/系统可执行所有驾驶功能，无需驾驶员参与。车辆可自主应对所有行驶场景，此时车内不再有“驾驶员”，仅有“乘客”。根据SAE J3016标准，SAE 5级系统的运行设计域（ODD）不受限制，甚至可实现无乘客的自动驾驶。

3.2 法律要求

2017年6月21日，德国首次实施自动驾驶相关法规，调整了自动化行驶阶段驾驶员的权利和义务。此后，符合特定条件的车辆可在SAE 3级模式下行驶。2021年，德国联邦议院于5月20日通过了一项新法律，并于7月28日生效。该法律允许符合条件的车辆在特定划定路线上以SAE 4级模式行驶。除私人用途外，这一法律还为其他应用场景（如自动驾驶班车、固定路线公交车等）提供了可能。

2021年德国联合政府协议中明确提出，在本届立法任期结束前，为合适基础设施上的完全自动驾驶车辆创造法律条件。2022年2月，德国联邦内阁在自动驾驶领域迈出了重要一步。据德国联邦交通和数字基础设施部（BMVI）宣布，该法规的核心内容是明确德国联邦机动车管理局（KBA）对具备自动驾驶功能车辆的道路准入审批流程，该法规尚需德国联邦参议院批准。

该法规具体针对SAE 4级系统，即车辆可在其划定的运行限制内实现完全自动驾驶。德国政府通过补充法规完善了自动驾驶相关法律，要求对车辆进行全面检测。根据《关于规范具备自动化和自动驾驶功能车辆运行及修改道路交通法规的条例》，制造商必须提交包含所用信息技术的安全概念。

此外，制造商还需描述车辆功能、制定测试场景目录，并列出需永久存储的数据（如车辆识别号、位置数据、系统监控数据、速度数据以及与外部实体交换的数据）。数据安全和信息安全在其中至关重要。

因此，车辆必须符合欧盟第2016/679号条例（《通用数据保护条例》，GDPR）中关于个人数据保护和数据自由流动的要求。原始设备制造商（OEM）还需通过危害分析证明，其技术设备在可能的运行场景下发生故障时的响应方式，以及这些响应对车辆安全性和可控性的影响。此外，车辆所有人还需承担广泛的检测义务：每次出行前需进行发车检查，检查内容包括制动系统、转向系统、照明系统、底盘以及电子控制的车辆系统等；根据法律要求，车辆所有人还需每90天委托“合适的机构/人员” 按照操作手册的规定对车辆进行一次检测。同时，车辆所有人必须能够证明，自动驾驶功能可在任何时候被关闭。

这一发展趋势表明，未来对车辆系统安全性和驾驶功能可靠性的要求将大幅提高。为满足这些要求，相关机构制定了两项关键标准，以确保开发过程和系统的质量：ISO 26262（关注车辆系统功能安全）和ISO 21448（保障已实现功能的可靠性和安全性）。

04. 规范性需求

4.1 ISO 26262的基本结构

ISO 26262是针对道路车辆中电气/电子/可编程电子系统（E/E系统）的国际标准，旨在确保车辆电气/电子组件的功能安全。需要注意的是，ISO 26262不涵盖机械组件可能带来的危害，也不涉及火灾、烟雾、高温、辐射等非功能性危害（除非这些危害由E/E系统失效直接引发）。ISO 26262是在IEC 61508（功能安全基础标准，适用于多个领域）的基础上，针对汽车行业的特定需求制定的。IEC 61508于1998年首次发布，2010年发布的新版本为当前有效版本。

然而，IEC 61508在汽车行业的应用中暴露出不足：一方面，IEC 61508假设操作人员经过专业培训，而汽车行业的用户（如乘用车驾驶员）并非专业操作人员；另一方面，与化工设施等不同，车辆系统不会引发波及大范围区域的灾难性事件，因此需要对风险等级进行更精细的划分。

为解决这些不足，ISO 26262于2011年4月以9部分标准的形式发布，第10部分随后于2011年11月生效。2018年12月，“第二版”（2nd Edition）正式发布，新增了两个部分。随着汽车行业复杂性的不断提升，开发和提供符合安全标准的系统已成为行业重点。ISO 26262的实施为保障系统安全提供了统一的标准框架。

ISO 26262引入了汽车安全完整性等级（ASIL）作为风险评估工具，分为QM（质量管理级）、A、B、C、D五个等级，其中QM对应最低风险，D对应最高风险。风险评估基于三个因素：故障后果的严重程度（Severity，S）、故障导致危害的行驶场景发生频率或持续时间（Exposure，E），以及驾驶员或其他道路使用者对故障的可控性（Controllability，C）。

此外，ISO 26262强调以过程为导向的安全标准，这与汽车行业高度注重过程管理的特点相契合。图8展示了“V模型”（V-Modell），该模型最初为软件开发设计，是一种结构化的开发方法。若要采用当前先进技术，遵循V模型进行开发是推荐做法。V模型明确了开发项目的各个阶段，并规定了每个阶段的核心任务。

图8:ISO 26262中的V模型

V模型的左侧从功能需求规格说明开始，逐步细化为技术需求规格说明和实现基础；V模型的底部为系统实现阶段；右侧则针对左侧各阶段的需求规格说明进行测试验证。

ISO 26262 的各个部分与V模型的各个阶段相对应，具体内容如下：

· 第1部分： 涵盖道路车辆E/E架构中安全相关系统的术语表。通过定义开发安全相关E/E系统时使用的术语，为功能安全的有效实施奠定基础。

· 第2部分： 描述功能安全管理的方法和要求，包括产品生命周期各阶段中与项目相关的管理活动信息，以及证明符合标准的保障措施。

· 第3部分： 阐述开发的早期阶段，定义在开发概念阶段确保功能安全所需的各种流程，包括危害分析和风险评估（将危害按安全完整性等级分类）。

· 第4部分： 涉及系统级产品开发的多个主题，输出包括系统级产品开发的所有文档、技术安全规格说明、技术安全概念、系统架构设计、组件集成与测试，以及安全验证结果。

· 第5部分： 聚焦硬件级产品开发，重点关注硬件规格说明、硬件安全、硬件设计，以及对随机硬件失效的评估（包括随机失效、潜在故障和诊断覆盖率等指标的评估）。

· 第6部分： 定义软件级产品开发过程中的功能安全需求，涵盖软件安全规格说明、软件架构设计、软件组件设计与实现、软件组件验证、软件集成与验证，以及嵌入式软件测试等通用主题。

图9描述了依据ISO 26262的软件开发流程。在汽车行业，实际开发中通常还包含应用阶段，但该模型未列出。ISO 26262的规范性附录中包含对应用阶段的要求，描述了可配置软件的使用规范。

图9:ISO 26262软件开发的V模型

· 第7部分： 包含安全相关系统生产和安装计划的基本方法，以确保生产和安装过程满足功能安全需求，同时规定了在运行、维护、维修和停用过程中需遵守的安全需求。

· 第8部分： 规定了开发安全相关E/E系统时功能安全所需的各种支持过程，包括：分布式开发中的接口管理、安全管理、配置管理、变更管理/验证、文档管理、软件工具的信任等级、软件组件的认证、硬件元件的评估、运行验证（Proven in use）、非ISO 26262适用范围内应用的纳入，以及非按ISO 26262开发的安全相关系统的集成。

· 第9部分： 描述特定的安全导向方法，包括ASIL分解、不同ASIL等级元件在同一系统中共存的标准，以及安全分析的需求。

· 第10部分： 概述ISO 26262的整体内容，旨在帮助理解其他部分，其中详细描述了“上下文外安全元件”（SEooC）的概念。

· 第11部分： 属于ISO 26262的信息性（非规范性）部分，包含支持半导体制造商的详细信息，评估了不同可靠性标准（SN 29500、IEC TR 62380、FIDES）在元件失效率方面的优缺点，还探讨了封装和引脚布局设计，并包含比原版ISO 26262更详细的瞬时错误定义（如由α粒子、β粒子、中子或γ辐射源引起的瞬时错误）。

· 第12部分： ISO 26262最初仅适用于总重量不超过3.5吨的乘用车，第二版将其应用范围扩展至商用车和摩托车。第12部分专门阐述摩托车所需的适配内容，包括摩托车适配的通用主题、安全文化、确认措施、危害分析和风险评估、车辆集成与测试，以及安全验证。

尽管ISO 26262的发布及其后续第二版的修订，为汽车行业提供了首个量身定制的标准，但该标准也面临一些批评。ISO 26262在应对快速变化的E/E环境及其对功能安全的影响方面取得了显著进展，但监管机构认为，修订版仍未充分考虑多项新兴技术。ISO 26262通过消除电气/电子系统失效来确立功能安全标准，但自动驾驶系统的安全性不仅与E/E故障相关，还需考虑驾驶员对功能的误用、传感器和系统的性能限制，以及车辆环境的意外变化等因素。因此，监管机构、安全倡导者，尤其是整个行业，都在积极探索制定新标准以弥补这些空白——该标准即已发布的ISO 21448，下文将对其进行分析。

4.2 ISO 21448（SOTIF）的基本结构

ISO 21448最初计划作为ISO 26262:18的扩展部分发布，但由于其结构复杂，最终未与ISO 26262第二版一同发布，而是作为独立标准推出。SOTIF（预期功能安全）标准旨在降低以下安全风险：

·  预期功能的残余风险

·  已知场景下的非预期行为

·  可能导致非预期行为的未知场景

ISO 26262规定了应对技术系统失效故障的概念、措施和流程，而SOTIF则针对由已定义功能的局限性引发的故障，制定了相应的处理流程。其核心是如何规范预期功能的规格说明、开发、验证和确认过程。尤其是在自动驾驶领域，高级驾驶辅助系统（ADAS）等新型复杂功能不断涌现，ISO 21448可帮助规避由执行器或传感器的技术限制、环境条件等因素引发的风险。

ISO 26262仍适用于安全气囊等现有系统的开发，通过降低风险可确保安全气囊在行驶过程中不会意外触发或完全失效。然而，即使系统功能完全正常，现代高级驾驶辅助系统（ADAS）仍可能存在安全风险。与ISO 26262相比，SOTIF标准并未采用全新方法，二者的核心区别在于：ISO 21448聚焦于预期功能本身，而ISO 26262则聚焦于随机和系统性错误（即偏离已定义功能的情况）。

图11展示了SOTIF流程的基本结构。与ISO 26262不同，ISO 21448未定义特定的开发或工程流程，但在SOTIF分析完成后，其要求会传递至ISO 26262的概念阶段。即使应用了ISO 26262并确保避免功能失效，道路环境中仍可能存在四种系统状态事件域：

·  已知且安全的系统状态域

·  已知且不安全的系统状态域

·  未知且不安全的系统状态域

·  未知且安全的系统状态域

图10：安全和不安全事件的批量表示

ISO 21448的目标是定义结构化的设计流程，以避免因预期功能缺陷导致的安全隐患，因此重点关注图10中的第 3 象限（未知且不安全的事件）。通过采用相关方法减少未知且不安全事件的数量后，可进一步采取危害控制措施，减少已知且不安全事件的数量，从而提高系统安全性。

SOTIF的目标是增强对系统在未知应用场景下可能行为的认知。ISO 21448未定义独立的开发流程，因此其重点放在概念阶段。

SOTIF概念阶段始于功能和系统规格说明的制定——这是开发车辆自动化功能的起点。该文档的核心内容包括：预期功能的目标描述、该功能与其他车辆功能和系统的依赖关系，以及相关的环境条件。

图11: ISO 26262期间的SOTIF流程

· 第6章： 涉及SOTIF风险的识别，随后需系统识别由所考虑功能的异常行为引发的危害。该标准采用与HARA和HAZOP类似的方法，通过特定动作的引导词来识别风险或潜在危害。与ISO 26262一样，可根据暴露度（E）、严重程度（S）和可控性（C）对识别出的危害进行评估。但二者的关键区别在于，在对危害事件进行分类时，SOTIF还需考虑驾驶员为控制关键驾驶操作而可能出现的反应延迟或无反应情况。

· 第7章： 聚焦危害应用场景的识别与评估，核心是识别可能导致系统非预期行为的系统弱点（这些弱点由特定事件触发）。触发事件可能包括传感器或执行器不匹配等，ISO 21448也将人类视为潜在的触发事件（例如，系统的误用可能引发系统弱点）。因此，人-机交互是ISO 21448的重要组成部分。

· 第8章： 确定降低SOTIF风险的措施，例如改进传感器和执行器系统。

· 第9章： 探讨验证与确认计划的制定。验证旨在证明系统已控制已知且不安全的事件；确认则旨在证明系统对未知且不安全事件具有鲁棒性，同时需确定确认目标。

· 第10章： 规定需对系统及其组件进行验证，目标是证明系统在已知且不安全的场景下表现出预期行为，且相关测试能充分覆盖这些场景。此外，还需进行系统和组件确认，证明其在实际测试场景中不会带来不当风险。验证和确认以当前车辆系统的实证事故数据为基础，确定累计测试里程的合理值，并根据不同测试场景（如高速公路行驶、夜间行驶、雨天行驶等）的代表性和真实性，分配累计测试里程。

最后，需完成SOTIF释放：证明已进行充分的验证和确认，且潜在的残余风险可被接受。释放后，需在系统运行过程中结构化地收集现场数据，并基于这些数据识别、披露和评估任何偏离预期行为的情况。若有必要，需及时对现场车辆进行修正。

05. 分析

5.1 依据ISO 26262的危害分析（HARA）

危害分析与风险评估（HARA）是开发项目中最重要的分析之一。HARA在开发初期进行，输出结果包括所有故障的ASIL（汽车安全完整性等级）评估，以及每个具有ASIL等级的危害事件对应的安全目标。功能开发的很大一部分工作都基于这些带有相应ASIL等级的安全目标。

HARA会分析系统潜在的危害失效和事件，并对其进行评估。每个系统的具体安全目标各不相同，由各功能、故障和评估结果共同决定。HARA完全基于系统的功能行为，无需系统的详细设计方案，因此属于开发的概念阶段。

在HARA中，通过三个维度（严重程度、暴露度、可控性）确定故障的危害性：

1. 严重程度（S） ：若故障在假设场景中发生且无法控制，其影响的严重程度如何。

2. 暴露度（E） ：故障相关场景发生的频率。

3. 可控性（C）： 若故障在假设场景中发生，其可控程度如何。

根据这三个参数，可确定故障的ASIL等级（从A到D，对于危害性极低、仅需遵循常规质量管理流程即可的故障，标记为QM）。其中ASIL A对应最低危害性，ASIL D对应最高危害性。这些等级决定了对开发过程的具体需求。

图12、图13、图14分别展示了用于确定严重程度、暴露度和可控性的各级别描述；图15展示了ISO 26262中用于确定各功能ASIL等级的风险矩阵。

图12：依据ISO 26262的严重程度评估

图13：依据ISO 26262的暴露度评估

图14：依据 ISO 26262的可控性评估

图15：依据ISO 26262的ASIL风险矩阵

ASIL参数应由专家团队确定，以整合广泛的专业知识。任何非最高等级的评估都必须有书面依据支持。

下文的HARA将以示意图形式展示电动转向系统开发中可能面临的潜在风险和危害。此处以伺服转向系统的一项基本核心功能——“转向助力”（Steering Assist）为分析对象。系统的核心功能源自系统描述（Item Definition），该描述在ISO 26262 V模型的概念阶段中被列为首要内容，是后续步骤的基础。由于下文仅为展示HARA方法，仅选取了转向系统的一项基本通用功能，并将其限定为四个运行状态，因此本文章未进行完整的项目定义（Item Definition）。

不过，电动助力转向系统的核心功能列表可参考如下：

1. 转向助力（Steering Assist）： 基础助力功能

2. 主动回正（Active Return）： 辅助方向盘回正至直线行驶位置

3. 主动终端限位反馈（Active End Stop Feedback）： 限制最大转向角度

4. 手部检测（Hands on Detection）： 检测驾驶员是否接触方向盘

5. 侧风补偿（Side Wind Compensation）： 辅助车辆在侧风环境下保持直线行驶

6. 跑偏补偿（Pull Drift Compensation）： 辅助车辆在倾斜路面上保持直线行驶

7. 零位学习（Zero Position Learning）： 在不同轴载下确定直线行驶位置

8. 万向节偏差补偿（Universal Joint Variation Compensation）： 补偿几何非线性偏差

9. 自检（Self-Diagnostic）： 系统自我诊断功能

10. 摩擦补偿（Friction Compensation）： 补偿机械摩擦

11.外部触觉反馈请求（External Haptic Feedback Request）： 通过不同的方向盘振动模式向驾驶员提供反馈

12. 转向特性外部扭矩偏移请求（Steering Characteristic External Torque Offset Request）： 由其他车辆系统（如自动泊车系统）施加方向盘扭矩

确定核心功能后，需为每个功能分配所有可能的故障。为系统地识别这些故障，本研究采用了DIN EN 61882:2017-02标准中规定的HAZOP方法。该方法可基于核心功能识别潜在故障。标准的表4.2中提供了一些形容词或基本引导词，可用于识别相应的故障（详见附录2 - HAZOP）。通过该表，已为 “转向助力” 核心功能识别出7种潜在故障。

由于故障的严重程度、发生概率和可控性取决于故障发生时的行驶场景，因此需先制定包含所有可能运行状态和行驶场景的场景目录，再进行场景分析（确定车辆的运行模式及其关键阶段）（详见附录3 -场景目录与场景分析）。为控制危害与风险评估的范围，本文章仅考虑三种在该系统中最常见的行驶场景。

这三种运行/关键模式将根据其对电动助力转向系统（EPS）的相关性和发生概率（基于运行状态下的时间占比和发生频率）进行评估，同时还需考虑可预见的系统误用情况。在实际场景分析中，需将这三种运行状态及其对应的关键场景与前文识别出的核心功能故障进行匹配，以确定：某一运行状态及对应的故障是否需在单独评估中考虑、是否已被更高层级的运行状态覆盖，或该组合是否不相关。

最后，在功能危害分析（FHA）中对相关故障进行单独评估，并根据图15中的风险矩阵确定其ASIL等级。同时，为这些与ASIL等级相关的故障分配安全目标——不同故障对应的安全目标可能具有不同的ASIL等级。因此，需根据 “最大ASIL原则”，为每个安全目标分配最高的 ASIL 等级（详见附录 1 - FHA/ HARA & Safety Goals）。

所用分析方法的列项设置均基于当前技术水平，尤其体现了实用性导向。

5.2 系统失效模式与影响分析（System-FMEA）

失效模式与影响分析（FMEA）是一种系统性方法，用于分析错误、错误后果及相关风险。FMEA可应用于多个领域：过程FMEA用于分析生产过程，识别关键生产步骤；设计FMEA用于发现设计中的弱点（如关键尺寸组件）；系统FMEA则用于从定性角度评估系统设计中各组件的失效风险，核心是发现系统中的弱点。此外，系统FMEA还可支持在可靠性、可维护性和安全性方面改进设计，并为后续的故障树分析（FTA）提供有关失效率和失效影响的有用前期信息。

在FMEA中，需从以下三个维度（1-10分制）评估潜在故障及其后果：

1. 发生概率（A，Occurrence）： 错误发生或风险出现的可能性。1分表示几乎不可能发生，10分表示错误或风险定期发生。

2. 严重程度（B，Severity）： 错误发生后产生的影响。1分表示对功能无影响，用户无法察觉；10分表示可能导致人员伤亡、严重违反法规或重大经济损失。

3. 探测概率（E，Detection）： 错误或风险发生后被发现的可能性。1分表示必然能被发现，10分表示无法通过系统性方法发现。

本文附录中的系统FMEA采用了目前仍广泛使用的“传统方法”，如列项所示，该方法使用风险优先数（RPZ，Risk Priority Number）评估风险潜力。风险优先数由发生概率（A）、严重程度（B）和探测概率（E）三者相乘得出，即RPZ = A × B × E。不同参数组合可能得出相同的风险优先数，例如RPZ=120可由3×10×4或4×5×6得出。若严重程度采用非线性评分（如涉及人员伤害时），则第一种情况（严重程度10、探测概率4）比第二种情况（严重程度5、探测概率6）的不可接受性更高。此外，该方法无法确保相似风险获得相同的风险优先数，因此在可能影响人员的场景中，这种方法往往不实用或非最优选择，面临诸多批评。

DIN EN 60812早在2006年就指出了这些缺陷，随后相关领域开展了大量解释和改进工作（例如，德国电气工程师协会标准VDE V 0831101已将改进方法纳入铁路信号技术领域）。在汽车行业，这些改进在汽车工业行动集团（ AIAG ）和德国汽车工业协会（VDA）协调后，通过《FMEA手册》（2019年）才较晚地引入。

这一改进和新方法的核心是，用“任务优先级”（AP）替代传统的风险优先数（RPZ）和风险矩阵方法。任务优先级通过“低、中、高”三级评估，确定是否需要额外的改进措施，同时考虑发生概率（A）、严重程度（B）和探测概率（E）的所有组合。此外，FMEA表格中新增了列项，分析方法中也增加了“考虑范围”步骤。

附录中的系统FMEA（S-FMEA）以“转向助力扭矩过大”（Excessive Provision of Steering Assist Torque）这一潜在故障为例，分析了其可能的故障原因和故障后果。该分析未考虑由设计、制造或装配过程引发的缺陷（这些缺陷将在设计FMEA或过程FMEA中处理）。

FMEA是一份动态文档，需持续更新，因此文档中包含一些需在后续开发过程中填写的列项（例如“已采取措施”列，用于记录FMEA初步结果后采取的额外措施）。本文章中用于示例的系统FMEA为初始版本，因此 K-P 列通常未填写。此外，由于仅考虑了一种故障及其对应的一种故障后果，所有潜在故障原因的严重程度均相同，而发生概率（A）和探测概率（E）则需单独评估，以便确定后续措施和任务优先级。

5.3 依据ISO 21448（SOTIF）的车道保持辅助系统（LKAS）分析

车道保持辅助系统（LKAS）是现代车辆中众多安全辅助系统之一，其核心功能是防止驾驶员和其他道路使用者因非预期车道偏离而面临危险。该系统专为高速公路和快速公路设计，通常在达到特定车速后激活。当车道保持辅助系统激活时，若驾驶员因疲劳或分心等原因面临车道偏离风险，系统会通过视觉、听觉提示及方向盘振动向驾驶员发出警告；若驾驶员未打转向灯就尝试变道，系统也会发出警告。此外，在许多车辆中，系统还会主动干预转向或修正行驶方向。

由于车道保持辅助系统（LKAS）会主动干预转向，已具备初步自动化特征，因此属于SAE 2级系统。不同原始设备制造商（OEM）的车道保持辅助系统在核心原理上相似，但在摄像头安装位置、警告方式及修正强度等方面可能存在差异。通常，车辆的后视镜后方会安装一个智能摄像头，用于识别道路标线。若系统检测到驾驶员可能非预期偏离车道，会相应做出反应：在发出警告后，若驾驶员未响应，大多数系统会主动修正转向，使车辆保持在车道内。

许多车道保持辅助系统（LKAS）提供两级辅助：一级是轻微的方向盘动作，提醒驾驶员保持在车道内；另一级是紧急模式，当系统检测到较大危险时，会进行更强的转向修正。配备电动助力转向系统（EPS）的车辆中，车道保持辅助系统会通过轻微但可感知的方向盘扭转来修正转向，使车辆保持在车道内；而未配备电动助力转向系统的车辆中，系统会通过电子稳定程序（ESP）对单个车轮进行选择性制动，实现转向修正。

车道保持辅助系统（LKAS）最重要的安全特性之一是 “可Override性”（驾驶员可干预性）：在某些情况下，为避免灾难性事件，驾驶员可能需要越过车道线，因此驾驶员必须始终保持双手在方向盘上，不得将车道保持辅助系统误用作自动驾驶系统。为防止这种误用，制造商通过检测方向盘扭矩来判断驾驶员是否手握方向盘（即使是微小的方向盘扭矩也能被检测到）。但在过去，这种监控功能曾被破解（例如，通过在方向盘上夹放物体），这促使制造商开发新的监控系统。

通过依据ISO 26262进行开发，可使车道保持辅助系统（LKAS）几乎达到无故障运行，并将故障或干扰风险降至可接受水平。然而，即使车道保持辅助系统在激活状态下完全正常运行，仍可能引发危害事件。例如，重叠的道路标线可能导致系统误识别标线，进而使系统按照误识别的标线控制或修正车辆行驶方向，而这种修正可能导致不安全的操作。

ISO 26262未规定排除此类危险的具体方法；ISO 21448虽然也无法完全排除由环境引发的危害或风险，但通过其独特的方法，为识别和安全控制大部分此类风险提供了有效途径。

在概念阶段，需从自动化功能的描述出发，通过系统化方法推导潜在危害和风险。对于车道保持辅助系统（LKAS）这类SAE 2级系统，责任始终由驾驶员承担：驾驶员必须持续感知环境信息，并能对潜在危险场景立即做出反应。车道保持辅助系统通过警告功能，为驾驶员提供额外的环境感知信息，帮助驾驶员更好地调整横向和纵向驾驶行为。

这种人机交互已暴露出由预期功能失效（如警告功能失效）引发的潜在危害：传感器、执行器、控制算法，以及驾驶员的不当行为，都可能产生风险和危害。在车道保持辅助系统这一具体案例中，两种关键危害为：系统执行不安全的驾驶操作，或驾驶员未修正这种不安全操作。

在自动化功能设计中，功能和系统描述是依据ISO 21448进行分析的起点，同时该文档也是动态更新的，需在开发过程中不断调整。文档中需描述功能的正常运行模式和预期行为，明确功能的局限性，尤其要说明系统在发现局限性时的行为，以及相应的警告提示和要求驾驶员接管的机制。该描述在ISO 26262中被称为“项目定义”（Item Definition），但ISO 26262对警告提示和接管要求的关注程度远低于ISO 21448（SOTIF）。

ISO 21448提及了多种危害分析方法，可用于系统性识别与预期功能安全相关的危害。总体而言，在系统层面，可采用多种方法识别和分析未知的不安全事件。

随着新技术及其复杂性的不断提升，传统的系统安全保障方法已不足以应对挑战。其中，“系统理论事故模型与过程”（STAMP，Systems-Theoretic Accident Model and Processes）是最有趣且最重要的新方法之一，由Nancy Leveson在其2012年出版的《Engineering a Safer World》一书中提出。该危害分析方法采用半形式化方式，对安全相关系统进行结构化分析。STAMP的优势在于将系统、驾驶员和行驶环境视为一个社会技术系统进行整体考量。“系统理论过程分析”（STPA，Systems-Theoretic Process Analysis）是基于STAMP的一种危害分析方法。这些新方法已在多个行业得到应用，其核心目标是保障预期功能的安全。

STPA是一种自上而下的分析方法，通过逐步细化分析，加深对系统的理解。与失效模式与影响分析（FMEA，归纳法）或故障树分析（FTA，演绎法）等传统方法相比，STPA能识别系统中更多的潜在危害。“基于STAMP的因果分析”（CAST，Causal Analysis Based on STAMP）是另一种源于STAMP的方法，通过事故分析深入理解防护功能的失效原因。该方法也可应用于验证阶段：当系统出现不可预见的行为时，CAST可解释测试偏差，进而识别合适的SOTIF措施。

在包含车道保持辅助系统（LKAS）的系统安全控制结构中，驾驶员被视为系统的有机组成部分。因此，在STPA分析中，会尽早考虑驾驶员对车道保持辅助系统的潜在或可预见误用。此外，环境也被纳入控制结构，例如需考虑交通工具、交通标志及总体环境条件等因素。

图16：驾驶员与第二阶段车辆自动化之间的效果图

通过已知的驾驶员安全控制结构，可确定不安全的控制行为。为确定这些行为，需采用类似HAZOP的引导词方法，定义控制行为的故障场景。通过评估各种组合，识别可能导致危害状态的故障场景，进而推导出针对预期功能安全的SOTIF需求。

通过驾驶员、系统与环境构成的整体结构，可识别并处理可能导致系统潜在不安全行为的不安全控制行为或缺失的系统功能。

在后续的实施阶段，需控制这些功能失效，最终确保将SOTIF风险降至可接受的残余风险水平。通常需组合采用多种措施以实现最佳效果，包括系统改进措施、限制预期功能、将驾驶任务责任归还给驾驶员，以及控制可预见的误用行为。

最后，需通过验证和确认证明预期功能的实现具有足够的安全性。验证的目标还包括证明系统能够应对已知和未知事件。

回到车道保持辅助系统（LKAS）的示例，在确认阶段需分析系统及其应用场景：通过刻意改变参数，观察系统是否始终表现出预期行为。为触发潜在的未知不安全事件，ISO 21448要求使用非设计预期的应用和环境场景，通过系统行为推导与实际应用场景的关联和协同效应，从而发现可能在设计预期应用场景中也会出现的潜在未知不安全事件。

这也是验证与确认的核心区别：验证仅证明系统满足已定义的要求，而通过验证与确认的结合，可证明已知和未知的不安全事件发生频率均足够低。

06. 方法学结果的讨论与比较

电动助力转向系统的开发过程复杂，需要在众多安全和危害分析方面具备丰富经验——因为转向系统是车辆中具有高危害潜力的核心组件。为避免安全关键型失效并最小化失效风险，开发过程中需进行全面的危害分析与风险评估（HARA）和失效模式与影响分析（FMEA）。例如，在实际应用中，一份完整的HARA可能包含数百至数千行内容。

本文章仅针对一项核心功能进行了HARA和系统FMEA分析，并阐述了基于转向的辅助系统（LKAS）的SOTIF分析方法。为控制文章篇幅，HARA仅聚焦“转向助力”（Steering Assist）功能，系统FMEA仅分析“转向助力扭矩过大”（Excessive Provision of Steering Assist Torque）这一故障，SOTIF分析仅阐述车道保持辅助系统（LKAS）的理论框架，以帮助读者理解基本方法。

在针对“转向助力”功能的HARA中，通过依据DIN EN 61882标准的引导词，在HAZOP分析中识别出7种潜在故障。在初始分析中，曾识别出更多故障，但其中部分已被现有故障覆盖，因此无需进一步考虑。

在每个步骤中，将分析内容精简至必要范围，是控制工作量在可行范围内的关键。

随后，制定了包含转向系统四种核心运行状态的场景目录，并根据相关性和发生概率对这些状态进行排序。在场景分析中，将这些场景与前文识别出的故障进行匹配，判断某一故障是否与特定运行状态相关、是否需在功能危害分析（FHA）中进一步考虑。例如，分析显示“一般城市交通”场景已覆盖所有其他“城市交通”子场景，这表明并非所有识别出的场景都与后续分析相关。

在后续的单独分析中，仅对相关的“故障运行场景”组合进行评估。分析结果显示：10种组合被评为ASIL D级，4种为ASIL C级，3种为ASIL B级，1种为ASIL QM级；另有4种组合因可控性良好（评为C0级）而排除在进一步分析之外（无ASIL等级）。

未出现ASIL A级故障，这与转向系统在车辆运行中的重要性密切相关：不存在仅在中等发生概率的行驶场景中才具有危害性的故障——故障要么始终具有危害性，要么仅在极罕见的行驶场景中具有危害性。对于始终具有危害性的故障，即使可控性良好（C1级），也至少会被评为ASIL B级；对于仅在极罕见场景中具有危害性的故障，其可控性通常足够好，因此会被评为ASIL QM级。

根据评估出的故障，可推导出相应的安全目标。尽管本分析仅聚焦一项功能，但已明确：即使是单一功能，也需通过多个不同的安全目标来保障其安全性。

完整的HARA分析将识别出更多安全目标。在定义安全目标时，应尽可能保持通用性，以便单个安全目标能覆盖尽可能多的故障。从“无转向助力功能可用”这一故障因可控性良好而被排除在进一步分析之外的结论中，可推导出安全状态 ——“EPS应关闭（无转向助力功能激活）”。

该安全状态在所有关键故障发生时都会被触发，以避免潜在的进一步或更严重危害。综上可见，由于转向系统若开发不当会对人员造成危险，因此其功能/系统开发需满足较高的ASIL等级需求。同样可合理推断，电动助力转向系统（EPS）的其他功能也将获得类似的ASIL等级评估结果。

从故障F02（转向助力扭矩过大）中，推导出安全目标——“应防止转向助力扭矩过高（过大）”。随后，选取该安全目标进行系统FMEA的详细分析。

在系统FMEA（S-FMEA）中，故障后果被确定为“车辆横向稳定性丧失”（Loss of Lateral Vehicle Stability），这对人员而言是潜在危害事件，因此严重程度被评为10分。

导致助力扭矩降低的故障原因较易识别（例如摩擦、或任何中断力传递的机械缺陷）；而导致“额外增加”或“放大”某一参数的故障原因（如助力扭矩过大）则不那么明显——转向助力扭矩过大仅可能由机械系统或电气/电子（E/E）系统引发。

从机械系统角度看，仅有三种可能的故障原因：

1. 油缸尺寸过大：在设定压力下，过大的油缸会产生过大的力，进而导致转向扭矩过高。作为预防措施，在设计初期需通过计算机辅助设计（CAD）和计算，确保油缸尺寸满足应用需求，并通过适当测试验证设计合理性。该故障原因的发生概率和探测概率均被评为3分——因为油缸尺寸设计（面积=力/压力）和测试（记录压力-力曲线）均为成熟且可靠的技术。

2. 其他机械原因（略）

3. 其他机械原因（略）

从电气/电子（E/E）系统角度看，软件计算错误是一个重要的潜在故障原因——若对输入信号的计算出现错误，可能导致转向助力扭矩过高。这类故障原因在行业中确实频繁出现。尽管已采用多种方法（如编程规范、复用成熟软件模块）预防软件错误，但经验表明这些方法无法覆盖所有错误来源，因此该故障原因的发生概率被评为6分。通过充分的软件测试，可大幅提高此类错误的探测概率，因此探测概率被评为2分。

总体而言，针对“转向助力扭矩过大”故障的系统FMEA（S-FMEA）篇幅相对较短，提及的故障原因也较少，这是因为此类故障的机械系统原因本身十分有限，电气/电子（E/E）系统原因相较于其他潜在故障也更少。因此，该故障非常适合用于在文章中演示系统FMEA的构建流程，同时避免过度增加文章篇幅。

在后续工作中，需将识别出的故障原因分配给各个子系统（如传感器、机械系统或控制单元），并在设计FMEA中进一步深入分析，以识别更多故障原因。

总体来看，所有潜在故障原因的风险优先数（RPZ）均显示中等风险，因此需考虑采取进一步措施。传统措施包括额外测试或设计变更，而针对机电一体化系统，还可采用控制单元的在线故障检测与处理等措施——这些措施在传统系统FMEA中通常不会被考虑。

此外，对比不同评估方法（如单独评估严重程度、使用RPZ、或计算发生概率与严重程度的乘积）也具有重要意义：与RPZ显示所有故障原因均需采取措施不同，通过 “发生概率×严重程度” 的计算，大部分故障原因被归为 “最小可接受风险”，无需采取额外措施；而单独评估严重程度时，仅关注故障后果而非故障原因，因此所有故障原因会被同等对待。

这些评估方法本质上都是为故障原因排序的尝试，在不同应用场景中，可能更适合采用某一种方法。其中，单独评估严重程度具有特殊地位——它被用于将安全相关故障原因标记为“关键特性”。

综上可见，“转向助力扭矩过大”这一初始故障属于安全关键型故障。已完成的系统FMEA明确表明，无论是基于严重程度还是风险优先数（RPZ），每种故障原因都需通过特定措施进行控制。

对辅助系统（LKAS）的SOTIF分析仅停留在理论框架层面，未提供具体结果，因此本节将讨论STPA（系统理论过程分析）的实施方法。STPA分析的起点是控制结构——该结构从纯功能角度描述系统，展示子系统间精确的控制流和信息流。无论上层系统是人类还是基于电气/电子（E/E）的计算机系统，二者都会分配、执行并确定相应动作。

车道保持辅助系统（LKAS）在激活后需执行其核心功能，而人类则需持续监控系统。因此，人类的“子系统”可理解为驾驶员用于控制车辆横向行驶的双手，同时需在分析中考虑驾驶员对方向盘的潜在误用。车道保持辅助系统本身的一个潜在子系统是摄像头——它负责采集并传递环境信息。

STPA分析流程大致分为两个步骤：

1. 识别潜在危险控制行为（Unsafe Control Actions）： 通过优化系统设计，可排除已识别的危险控制行为。例如，系统 “过早触发安全动作”就是一种危险控制行为——它不代表功能失效，而是功能异常。若车道保持辅助系统过早介入转向，可能导致车辆进入未知且不安全的事件域（如车辆晃动）。为避免此类情况，除了正确设计系统外，还需考虑因果因素。

2. 识别可能导致危险控制行为的原因和场景： 基于这些原因和场景，可制定额外的安全措施以降低风险。

成功实施SOTIF分析和STPA分析后，可判断车道保持辅助系统（LKAS）及其子系统是否存在故障流程、算法缺陷或子系统间交互问题。通过减少这些因素的影响，最终可最大限度地减少潜在的未知不安全事件。

07. 总结、结论与展望

本文的核心目标是阐述电动助力转向系统（EPS）的结构，以及如何开展相应的危害分析和安全分析。

文章重点探讨了ISO 26262和ISO 21448（SOTIF）两项标准，为读者提供功能安全分析方法的理论知识；此外，还解释了潜在的未来转向系统（如线控转向）和车辆自动化技术。

分析结果表明，从功能安全角度来看，电动助力转向系统的评估标准严格且具有批判性。这一结果并不意外——转向系统是车辆的核心组件，故障可能引发危害事件。随着转向系统的不断发展和众多辅助系统的集成，其复杂性日益提升，因此需要采用新的、适配的分析方法，以消除潜在故障源。

危害分析与风险评估（HARA）和失效模式与影响分析（FMEA）能有效评估特定故障或系统的风险水平，但仅依靠这两种方法，无法完全覆盖车道保持辅助系统（LKAS）等功能带来的潜在危害。通过SOTIF方法的分析可知，需采用结构化的分析思路，并在分析过程中及时将认知融入系统设计，才能实现全面覆盖。

文章还聚焦自动驾驶技术及其在德国的法律基础，结果表明：机构和监管部门正积极推动自动驾驶技术发展，但行业难以完全跟上这一快速发展步伐。ISO 21448（SOTIF）作为描述预期功能安全方法的新标准，目前仅能全面覆盖至SAE 2级自动化系统，未来需进一步补充完善，以满足自动化技术快速发展带来的安全保障需求。

在这一过程中，必须始终将人员安全置于首位——通过认真、有意识地开展功能安全相关工作，可进一步保障人员安全。自动驾驶技术的未来发展将带来更多挑战和创新，关键在于对这些发展保持批判性审视，始终将人员及其安全放在首位。

只有这样，才能确保是人类适应系统，而非系统支配人类。

附件1：–FHA/ HARA & Safety Goals

附件2：- HAZOP

附件3：-情况目录和情况分析

附件4：-- System - FMEA