作者：Aimee
来源：焉知自动驾驶
随着驾驶员辅助系统的日益复杂，主机厂要发布销售和使用的技术产品，始终必须首先提供足够安全的证明。在这种总体安全考虑中，正确和安全的产品功能部分称为功能安全。评估产品是否安全的参考是容许的风险极限，如果与产品相关的风险低于风险极限，则可以认为它是足够安全的。然而，随着开发的深入，系统由于“功能不足”产生异常行为的这一原因正变得越来越突出。在这种情况下，系统设计的局限性成为一种挑战，因此有必要使用统计模型来处理该局限性的相关未知数。验证具有功能不足的系统方法是对系统错误行为的可接受度进行概率统计，其剩余概率按照一定形式指定发布安全目标。
汽车标准ISO 26262就是在为驾驶员辅助系统设计新的预测系统的情况下设计的功能安全评估准则。本文将以介绍该准则原理为前提对驾驶辅助中的几个典型的功能进行安全分析及解读。
ISO26262架构
ISO 26262定义了道路车辆安全关键组件和系统开发过程的要求，其标准中描述的过程面向产品开发的通用V模型（如下图）。在产品生命周期的开始阶段（即在系统的设计阶段），应确定功能可能引起的危害，并应量化由此产生的风险。根据此风险定义，定义安全目标，并由此定义安全有效的开发方法，确保满足整个产品生命周期监控的要求。因此，由ISO 26262定义的方法可确保在开发过程开始时就整合安全要求，从而根据产品安全标准定义适当的方法。特别是，即使在详细指定产品属性之前，也必须定义安全概念的质量要求。为了实现广泛的应用，甚至适用于差异较大的系统，ISO 26262还抽象地解决了功能安全性问题。因此，它不可避免地会提供有关应用所需的方法和较少的程序信息，例如，可控性估计的转换和风险评估的测试。
ISO 26262要求在设计阶段，识别与E / E系统相关的风险并评估潜在风险。这是在危害分析和风险评估（H＆R）的基础上完成的，该方法的应用在ISO 26262的第3部分（上图中的3-7）中得到规范规定。在H＆R范围内，在不考虑原因的情况下在整车级别上分析潜在危害，并对检测到的风险进行分类。为了防止在H＆R范围内定义危害，ISO 26262要求制定安全目标规范（上图中的3-5），这些为开发安全概念提供了框架。安全目标是在车辆级别上考虑到影响环境的因素和情况，随后作为危害中涉及的功能在车辆系统中作为功能安全要求得出（图1中的3-8）。这种推导仍然是“没有解决方案”，因此独立于具体实现。一个或多个功能的实现仅在具体的系统级别完成，并由技术安全要求解决（上图中的4–6）。与功能安全要求相反，技术安全要求描述了系统的实现，并且在下一个派生步骤中，相应地详细给出了硬件和软件安全要求，以实现硬件和软件设计。
智能驾驶系统安全需求概览
安全要求的层次结构如下图所示。在考虑系统的功能安全性时，需要定义故障类型的不同限制（ISO 26262词汇表中包括了对故障，错误和故障含义的详细区分）。限制之一是对电气/电子（E / E）和可编程系统的限制，例如，机械故障将不被视为引起风险的原因。也可能由于E / E组件或软件故障，还会使得发生的系统性故障也被认为是与传感器系统相关的故障。即使所有组件和软件功能都符合规范，也会发生其他类型的故障。在此，系统不会以适合情况的方式做出反应，因为系统规格未涵盖操作车辆时可能发生的所有可能情况。由于对情况的不完全了解或基于不可行的预测或模型假设，这可能导致系统在驾驶情况下做出不正确反应。根据当前的知识状态，由于可能的驾驶情况很多，依赖周边传感器的系统是不能明确确定出来，也不能对其进行测试，并确保可以在规范范围内进行正确的干预。系统规范的一个更抽象的表述可以解决这样一个问题，即在技术实施时必须基于有关车辆周围环境的最新可用信息来定义具体的系统反应。
同时，该标准仅考虑驾驶员辅助系统的功能故障（在偏离明确规范的情况下）。假设可以清楚地区分符合规格，正确的功能状态和不符合规格，故障或失效的状态。这些故障可以被清楚地识别出来，并且可以通过具有很高的检测率，关闭措施和降级机制的故障检测方法将其减少到最少。ISO 26262中描述的基于客观风险评估的方法来定义安全要求的过程可以应用于两种故障类型。从驾驶员和参与此情况的其他人的角度来看，危险是否由系统的功能故障或不足引起，这无关紧要。即使在两种故障类型的技术原因都不相同的情况下，驾驶员在车辆中感觉到的效果也可能相似（例如，没有任何可察觉原因的车辆减速）。
参照ISO 26262准则，其是基于以下三个风险参数完成的：
–暴露度：驾驶情况多久发生一次，驾驶员或其他道路使用者是否会构成危险？
–可控度：在这种驾驶情况下，驾驶员或其他道路使用者如何良好地控制危险，从而可以避免损坏？
–严重性：发生损坏时，严重性是什么？
上图3在风险图中显示了三个风险参数之间的关系。该图有助于说明如何进行风险评估。产品风险由损坏的严重程度（X轴）和频率（Y轴）组成。参考上述风险参数，使用相同名称的参数评估损坏的严重性。
风险评估的结果是潜在风险，可以通过QM，ASIL A，ASIL B，ASIL C和ASIL D类中的ASIL（“汽车安全完整性等级”）进行评估。此处，ASIL A对应最低的风险等级而ASIL D对应最高的风险等级。根据表1评估各个风险参数，可以具体定义ASIL分类。这里，每个风险参数分为三到四个类别。每个类别对应不同的含义。
基于ASIL，对预防和控制系统性和随机性故障的措施进行了规范性的定义，以将潜在风险降低到剩余风险，且该风险低于可承受的风险程度。与ASIL A相比，在ASIL D中应采用更多的方法和措施来确保安全。而如果仅通过QM（质量管理）对危害进行分类，则使用经过认证的质量管理体系就足够了，进一步的应用不需要将ISO 26262纳入开发过程。
AEB安全需求评估
安全目标针对的是能够直接或间接访问系统相关执行器，并因此有可能造成危险的所有系统目标（如下a至e），安全要求的层次结构要求更详细地说明从车辆级别到硬件和软件级别的安全要求。该安全要求流程可确保实现给定的安全目标，从而防止发现的危险。下面以“自动紧急制动（AEB）”功能为例更详细地介绍此安全要求流程。如果前车辆即将发生碰撞，AEB应该执行自动紧急制动。根据干预程度，该功能旨在最大程度地减少损坏或防止损坏。
1、AEB安全目标规范
AEB功能可激活的执行器是“制动单元”。根据执行器功能“制动”，可以将以下故障定义为潜在危险：
（a）意外自动刹车
（b）驾驶员制动期间产生额外制动助力
（c）发出有制动要求，执行器没有制动助力
（d）尽管有制动要求，但制动助力过低
（e）静止期间的意外夹持力
首先，驾驶员辅助功能定义的潜在风险是独立于“制动功能”的。根据H＆R中的严重性（S），暴露（E）和可控制性（C）的风险参数进行的。在这里，如上危害类型（a）和（b）被分类为ASIL C，评估时不考虑定义相关的安全措施（例如，通过驾驶员或制动干预的限制）。
确定系统功能的ASIL等级可以被用作产品进一步开发的标准，以降低风险。在此，为防止危害“后端碰撞”而规定了安全目标。这些处于最高抽象级别的安全要求，是开发安全概念的起点。另外，必须为每个安全目标指定“安全状态”。对于上表中的示例，下表中描述了安全目标和安全状态。
2、 安全需求规范
1） 基本规则
安全需求规范的基本规则是根据车辆和系统体系结构中各个级别的安全目标来指定安全要求的。在整车级别，以功能安全要求的形式可能会损害安全目标的功能安全。这是在所有涉及的系统中完成的，并且是发送给各个系统供应商的需求规范的一部分。功能安全概念描述了假设和解决方案，这些假设和解决方案是根据安全目标得出功能安全要求的。
具有功能安全要求的要求规范是由负责车辆系统的一方创建的，通常是OEM。系统提供者有责任以不影响系统功能安全性的方式规定和实施安全概念。技术安全概念包含从功能安全要求中得出技术安全要求的文档。它包含系统级别的具体解决方案，用于防止违反功能安全要求，并隐含地用于防止违反上级安全目标。
2）AEB安全需求
下图给出了车辆和系统级AEB功能的安全要求示例。制动执行器功能的组成部分是“驾驶员辅助系统（DAS）”和“电子稳定控制（ESC）系统”。此外，必须以不违反安全目标的方式，完成安全目标，即“避免意外制动，导致危险”。对于DAS而言，这意味着必须防止可能导致危险的不合理的AEB请求。通过在持续时间以及强度方面限制AEB功能，可以通过缩短制动时间或减弱制动速度来降低潜在的风险，从而对损坏的程度以及可控性产生积极影响。当ISO 26262中描述的H＆R涉及以具体方式定义在风险降低时，存在其局限性。通常，对于风险参数的粗略分类和相关的主观估计，因此难以根据潜在风险对具有不同制动曲线的制动干预进行评估。在这种情况下，客观的方法（例如基于运动方程式的仿真或使用耐久测试数据和事故统计数据）可以进一步帮助更准确地定义不同制动曲线的ASIL分类。
假设AEB干预受到限制，系统可以将潜在风险降低到ASIL A。在这种情况下，此ASIL分类以及功能安全要求是“避免在AEB激活条件范围内发生意外的制动要求”被传输到系统FAS端。通常，AEB要求受系统ESC的限制，而系统ESC的功能安全等级ASIL C则来自于相应安全目标的原始分类。
3）分解方法
除了继承安全要求（将ASIL分配给至少一个导出的安全要求）之外，ISO 26262还提供了分解的可能性。在此，可以降低导出的系统安全要求的ASIL等级。只有在“分解前”的安全要求（即初始安全要求）通过至少两个足够独立的元素或子系统来实现，才能通过分解来降低ASIL安全等级。因此，每个派生的安全要求都必须能够“独自”满足初始安全要求。在此，考虑到初始安全要求，当无法确认相关故障的原因时，则不能武断的假定元素或子系统视为会单独发生故障的状态元件。
在下图中，ASIL功能安全分析拆解出了所有涉及的系统。在这里，系统ESC会收到初始安全目标的ASIL等级。DAS中ASIL的降低不是通过分解到冗余系统来完成，而是通过重新评估可能具有有限制动功能的潜在风险来完成。根据ISO 26262在独立的电子控制单元中实施了用于确保指定限制的安全机制，因此绝对可以将ASIL降低到DAS实际可接受的潜在风险。如果假设在ESC系统中无需实施ASIL C要求，则可以想到即使在DAS中也要遵守指定的限制，从而将ASIL C分类分配给两个系统。参照下图，ISO 26262提供了用于减少ASIL分类的不同选项。但是，此处的初始ASIL应始终放在上面方括号中。然后，可以将ASIL C分解为ASIL A（C）和ASIL B（C）。为了满足AEB功能的安全要求，将在下图中进行更改。
3．安全需求的满足过程
通过H＆R分析可以系统地汇总了产品所带来的风险，并从安全目标中得出了安全要求之后，ISO26262要求产品开发必须确保这些要求得到切实执行。根据基本的V模型，完整的需求树必须首先指定产品属性。该规范在所有详细级别上都为V模型的正确分支，产品属性的验证和确认奠定了基础。
在ISO 26262中，使用相应的模型定义了四个大致的层次结构级别：
1）通过安全目标规定的抽象系统级别（要求（f））
2）由功能安全要求组成的无解决方案的产品说明（要求（c）和（d））
3）在实施级别上可能与更多模块相关的需求，但尚未涉及最小的体系结构要素：技术安全要求（要求（b），（e）和（g））
4）与最小结构元素有关的实施要求：硬件/软件安全要求（此示例中的要求（a）仅在硬件级别上）
3.1 需求水平的可追溯性
如果假定安全性目标已经过验证，则根据ISO 26262，只有在可以证明解决方案满足安全性目标的情况下，产品才是安全的。因此，仅精确描述实现哪些算法或使用哪种硬件是不够的。为了进行验证，解决方案必须与抽象指定的属性（尤其是安全目标）需要有明确的链接。对于复杂的系统，创建此类完整的文档非常具有挑战性。
在基于毫米波雷达的AEB系统时，以下内容可能会得出以下要求：
（a）镜头加热器电热丝的内部电阻必须为若干欧姆。
（b）RADAR传感器必须使用固定波束天线检测反射点。
（c）AEB不得在无事故风险的情况下制动。
（d）驾驶员必须能够随时接管或超越驾驶辅助系统行为。
（e）必须用卡尔曼滤波器进行物体跟踪。
（f）车辆不得因未经授权的制动干预而引起任何事故。
（g）激活刹车灯开关（BLS）时，自动紧急制动控制被中断，并且参照驾驶员要求减速。
AEB功能安全的示例中给出的所有要求都是有效的产品要求，而以非常不同的抽象级别进行表示。如上，要求（f）符合一般安全目标，要求（c）和（d）是行为的抽象描述，目前尚无法预期具体的硬件和软件解决方案。要求（b）和（e）描述了硬件组件和软件算法，而没有预期实现细节。此示例中的要求（a）是最具体的要求，直接涉及硬件实现。这里出现的核心问题是，根据要求（a）的内部电阻的符合性是否与安全相关，还是“仅”出于质量方面的动机。为了回答这些问题，需要一个对需求进行排序的层次需求树，以从最抽象的需求到具体的解决方案定义进行追踪。对于每个级别，解决方案空间都受到进一步限制，该树也可以理解为嵌套解空间的表示方法。
ISO26262不仅着眼于安全性要求也更专注于需求树的完全一致性。在实践中，经常会发生层次结构级别被无意混合的情况。例如，开发人员在DAS的行为描述级别指定了一种具体的算法。这导致了系统设计的早期，无需设置不必要的限制，这对于后期系统建立可追溯的原理比较难。为了获得更好的系统概述，将属于一个解决方案空间的所有需求编译到一个系统或子系统描述中很有用。
此处显示的示例需求树显然是不完整的，因为无法借助这种简单的“规范”来开发任何系统。该示例说明了复杂的驾驶员辅助系统需要建立完整，明确，可追溯的需求树。而在创建需求树时，结构化的系统体系结构是掌握安全系统设计的重要元素。安全目标在进行H&R分析时要求系统设计过程具有完整的可追溯性。由于记录良好的需求树不仅可以跟踪安全目标的遵守情况，而且还可以总体上提高产品质量，因此即使没有安全目标也要实现，可追溯性是汽车行业的标准要求。
除了ISO 26262中要求的层次结构级别外，通常由系统开发人员来决定其在到达其体系结构的最小结构元素有哪些，其过程中需要提供多少个派生步骤。小步骤使跟踪单个步骤变得更加容易，但是让元素的数量和链接结构的复杂性变化更大。在此处显示的示例中，从安全目标得出的需求树与从AEB功能的性能需求得出的树是分开的。通常，ISO 26262隐含地假定系统级别的故障基本上总是由故障（即与实施要求的偏差）引起的。在这种情况下，安全架构和功能架构之间的区别非常明显，因为安全要求基本上仅限于监视指定的实现方案以及对此监视的响应。典型的“安全体系结构”可以保护系统的功能部分免受实施故障的影响。
3.2 功能安全验证
基于需求测试过程，有效验证的先决条件是抽象的对系统规范进行完整描述。验证旨在证明模型中指定的输入/输出关系是由产品的相应元素实现的。正确派生的功能安全模型（例如，在实现级别的需求定义）等同于抽象系统规范。因此，实际上仅在产品的系统级别上验证模型就足够了。但是，在实践中，如果模型更复杂，则不可能进行完整的验证。规范越抽象，必须检查的输入/输出关系就越多。由于规范仅在实施时才算是真正的被确定，因此在这里只能实际达到一定程度的完整性。
验证基本上证明，在规范和实现的相同抽象级别上的两个等效模型实际上彼此对应。
但是，在H＆R分析中是有意识地以抽象和通用的方式制定安全目标，以至于即使是设计错误（即以错误的方式得出的模型）也可能导致违反这些顶层要求（见下左图）。
“安全验证”专门致力于确保从抽象需求派生的有效性的任务。此外，实际安全目标的完整性和正确性需要得到验证。这包括检查驾驶员是否可以使系统进入“安全状态”。所需的方法集中在产品级别的系统测试上，并且特别着重于测试系统对“故障”的鲁棒性要求，即错误地不符合规范的实现元素。
基于ISO 262262进行功能安全分析的限制
在前面的示例中，可以通过一个比较简单的解决方案，借助刹车灯开关，实现功能安全目标 - 即“驾驶员必须能够随时超越AEB控制”。即便使用完整的推导模型也很难推导出“即便在没有事故风险的情况下系统不会主动不刹车”这一安全目标。在这种情况下，安全目标与定义系统实际功能的系统要求相同，且很难与核心的“安全架构”分开，这将可能导致较为复杂、难以解释或无法预测的系统设计。因此，必须确保功能路径的可追溯性。
常规系统缺乏对其元素状态或环境“负载”的了解。在上一章中讨论的验证是基于对派生模型的完整理解，它假定应该满足构成设计基础的硬件要求。在制造后和发布产品之前，可以大致检查硬件属性。当无法精确知道环境负荷时，很难在更长的时间内对属性进行建模。已知负载后特定组件的故障会导致基本可预测的系统性故障。发生故障时，可以说明原因和故障过程。但是，对于精确的预测，必须知道组件的确切属性（可能在原子级别）以及整个生命周期内的确切负载方案。
由于无法了解所有已交付产品的最新技术信息，因此单个故障似乎是偶然的。为了安全地设计组件，在开发过程中会引用统计模型。与我们的示例中的统计资料建模相似，可以对特定情况下行人的个人行为进行统计建模。这就产生了一种算法，即通常在许多类似情况下都是正确的（“真阳性”），并且以一定的概率错误地估计了这种情况（“假阳性”）。导致与抽象规范不相符的不良行为的错误估计在下文中称为错误行为。这种故障行为的概率称为“残留故障概率”。通常可以使用驾驶员辅助系统中的模型参数来调整此残余故障概率（如下图）。
图10可以使用参数设置分类器的检测精度。当故障分类减少时，即“假阳性”概率，则检测精度也在降低，即“真阳性”概率。另一方面，增加的检测精度总是伴随着增加的故障分类概率。参考线之间的间隙对应于选择性，并由此对应于分类器的性能。最大选择性代表了检测精度和故障分类概率之间的折衷
必须定义残余故障概率，以将这样的系统设计为系统规范的一部分。这也是设计硬件组件的标准。通过定量（故障树分析，FTA）或定性（故障模式和影响分析，FMEA）的粗略估计，可以得出在整个系统级别上对故障频率建模的常规方法。与基于完整派生模型的设计发布相反，在设计审查中确认不存在相关故障的情况下，发布系统时已知统计模型的误报率。系统测试用于确认发生概率，并与目标残余故障概率保持一致。
对于功能不足的系统，必须证明遵守上限以应对系统固有的残留风险。在最简单的情况下，应在系统级别执行统计“黑匣子测试”。通过使用统计代表性样本上的试验，可以在不了解实施细节的情况下测量错误行为的可能性。对于驾驶员辅助系统，这意味着在代表功能的驾驶条件下进行大量测试。
总结
本文简要概述了汽车标准ISO26262，其中包含对功能安全性的要求，以避免或控制系统性故障和随机硬件故障。在此背景下，针对驾驶辅助安全系统AEB进行了危害分析和风险评估，并介绍了防止该功能产生相关危害的其他步骤。在本文的最后部分讨论了功能不足导致的危害，这些危害超出了ISO 26262的范围。很难预测这是否可以通过增强ISO 26262或其他措施来实现。根据目前的估计，在各个公司中对ISO 26262本身的应用仍存在不同的应用，这是因为该标准允许对其进行单独的解释。
本文转自： 焉知自动驾驶 ，转载此文目的在于传递更多信息，版权归原作者所有。如不支持转载，请联系小编demi@eetrend.com删除。
