|
写好TSR的重要性 写的好的TSR能够实现以下的目标： 1. Basis for Safety Concept 技术安全要求及其对相关硬件和软件元素的分配构成该项目的技术安全概念的基础。技术安全要求的薄弱和它们达到预期ASIL水平的能力将削弱安全的实施。 2. Input for Hardware and Software work products 技术安全要求和技术安全概念是系统设计、硬件级产品开发和软件级产品开发的关键输入。在技术安全要求中出现的任何模糊或错误都有可能渗透到下游工作产品中，如硬件安全要求和软件安全要求。良好的产品质量不是巧合，它来自于强大的工程文化需求。召回和服务升级的成本非常高，可能会抹去产品线的利润。 3. Input for Item integration and testing ISO26262标准第4部分第8条讨论了项目集成和测试。集成本身是指硬件-软件、系统和车辆等多个层次的集成。每个级别的测试旨在提供足够的置信度，确保技术安全需求能够抢占可能违反安全目标的意外行为。 4. Cost for product development 技术安全概念和技术安全要求的初步草案可以作为一种聪明的项目管理工具，用于估算工作量，从而估算成本。正如产品开发后期变更的任何其他方面一样，技术安全需求中的范围渐变和返工可能导致成本超支并延迟整个项目进度。 5. Customer Confidence 在实践中，技术安全要求可能完全由Tier1供应商制定，或者在Tier1和OEM之间分工。实际的工作划分和工作产品在一个称为DIA(开发接口协议)的ISO工作产品中详细描述。一个编写良好的技术安全概念(TSC)和技术安全要求可以确保相关各方理解该方法，并致力于可行的实现。这总是有助于维护甚至增强客户对供应商能力的信心。 编写TSR过程中面临的一些困难 1.Missing upstream work product 功能安全概念是功能安全要求的规范，包括相关信息，它们对架构元素的分配，以及实现安全目标所必需的交互。根据ISO26262 Part 4 Clause 6.4.1，技术安全要求需要符合概念阶段开发的功能安全概念。然而，一个特定的项目可能会遇到FSC缺失的情况，并且它不在他们的工作职责划分之内。在这种情况下，FSC需要逆向工程或定制，以完成安全案例。另一种情况是，FSC是可用的，但功能安全要求没有得到适当的引出，并导致某种部分工作产品。这两种场景都是不可取的，并且超出了拥有此工作产品的标准的目的。供应商应通过DIA确保上游工作产品由双方一致同意的一方按时交付。 2.Multiparty development 在今天，由多个组织开发的产品并不少见。对于软件开发来说尤其如此。在OEM开发高级应用软件软件、Tier 1提供大部分基础软件、第三方供应商提供CAN堆栈的产品中，经常可以看到这样的情况。在这些情况下，关键是要在DIA中捕获工作分配和进度，并得到各方的同意。再次强调，在项目早期通过DIA确定多方责任和时间表很重要。 3. Challenges with legacy systems 近年来，OEM公司强烈要求越来越多的控制单元达到ISO26262标准。随着车型年更新，车辆中大多数电控单元通常保持现状或变化极小。然而，新的ECU或工程变更的ECU可能会决定采取措施遵守ISO26262。然而，通常情况下，ECU可能从传感器接收到一些输入，或者可能成为安全概念的一部分，从而获得相应的ASIL要求。这驱动ECU或硬件组件发送信号的变化。然而，OEM可能会因为决定移交遗留组件而立即推迟进行这些更改。在这种情况下，系统的缺陷需要在功能安全评估中得到明确的沟通和双方的同意，并形成文件。此外，由于这些缺陷而可能产生的任何法律责任也应予以记录和商定。 4. Critical computer resources 用于ECU硬件的微控制器可能没有足够的资源，比如可用的运行时、内存分区功能、空闲RAM或Flash，以实现满足项目的目标ASIL所需的安全控制策略。有时，如果有这样的选择，可以通过仔细选择安全策略来克服运行时或CPU吞吐量等挑战。例如，与基于定时器中断的反馈相比，选择基于ADC的反馈可能会减少CPU负载。应在报价阶段要求评估用于实施适合该项目的安全概念的预期硬件的适用性。 5. Stakeholder lack of interest ISO26262的成功实施取决于所有利益相关者的合作和团队合作，包括OEM、Tier1和任何子供应商或第三方。如果OEM的承诺很低，Tier1可能很难开发符合ISO26262的产品。这些挑战从缺少像HARA和FSC这样的安全概念工作产品到无法执行安全验证。正如前面提到的，从项目开始实施的第1点和第2点安全管理依赖于包含DIA的多方，可以帮助缓解这个问题。另一方面，如果ISO26262的实现仅仅是为了供应商的利益，那么供应商可以在内部模拟这些缺失的工作产品和OEM的角色。 编写技术安全概念 为了讨论和应用该方法，我们将以一个相对简单的项目为例，如后门模块，下图所示。后置门模块的主要功能是根据驱动程序的有效请求打开或关闭后置门(启动盖)。打开或关闭请求可以来自硬连接的数字输入开关或CAN消息。根据启动盖的当前位置，请求将被解释为打开或关闭。启动盖的运动是通过H桥控制电机实现的。由于控制模块的潜在故障而可能发生的一种危险是，当一个人正在从汽车行李箱中捡东西时，不小心关闭了门。
从上述危害中，我们可以得出安全目标“防止后大门意外关闭”，并被评为ASIL A。该标准提供了五个分类，其中ASIL A是最不严格和要求，而ASIL D恰恰相反，是最严格的。QM分类不需要ISO26262标准的特殊措施，使用适当的行业特定的质量标准就足够了。ASIL级别是根据在概念阶段的危害分析和风险评估中识别的最高ASIL级别的危害确定的。 Method:故障树分析 故障树分析是一种演绎安全分析方法。对系统进行了系统的自顶向下分析，以找出可能导致顶部事件的故障。这种分析方法是一种有效的工具，可以引出所有可能导致系统中特定的顶层事件(失效)的低层事件(错误或故障及其相互关系)。 cut set（割集）可以导致顶级事件发生的门和事件。最小割集是导致顶层事件的事件的最小组合。故障树的美妙之处在于，它可以帮助安全工程师识别所有可能导致顶层不安全故障的单点故障和双点故障。安全工程师可以根据项目的ASIL和以割集为代表的事件发生的概率，在指定安全要求和安全机制时确定优先级和重点，以加强项目侧重薄弱点。让我们看看如何为后门模块创建一个FTA，并使用它来推导安全目标的技术安全要求——防止门意外关闭。违反安全目标被指定为不希望发生的顶级事件。在这种情况下，这将是——门的意外关闭。 下一步是对系统架构进行头脑风暴，以识别可能导致顶级事件的错误和故障。这些错误将构成下一个较低级别的事件。强烈建议在研讨会的气氛中，与相关的利益相关者(来自不同学科系统、软件和硬件的专家)一起进行这项练习。另一种方法可能是参考利益相关者生成的设计文档，因为根据子系统设计正确建模故障是非常重要的。
在这个例子中，我们可以引出以下低级错误： 1. Incorrect request over CAN 2. Incorrect request from the hardware switch 3. Control software errors and 4. Hardware errors 下一步是引出可能导致这些错误的实际低级错误。在复杂的系统中，在我们达到最低故障级别之前，可能会有多个级别的错误。在最低的故障级别上，故障树将如下所示。下面的图只是指出树可以变得有多大，有多复杂，并且不希望被读取。下面将详细讨论每个切割集。
最低级别列举了所有可能违反安全目标的不同类型的故障。下一步将是分离每个切割集，然后为每个最小切割集定义技术安全要求。
但是，如果任何一个故障仍然是潜在的或未检测到的，并且在稍后的时间点上发生了第二个故障，这将直接违反安全目标。因此，一旦发现双点故障，司机应得到警告，以便在车库采取纠正措施。在故障树中，双点故障表现为割集上由与门连接的两个或多个故障。技术安全概念应力求检测故障树中识别的所有这类双点故障。 技术安全要求应包括故障树中识别的所有单点故障。所需的覆盖程度取决于ASIL级别和项目的度量目标。 使用FTA的技术安全要求的推导可归纳为以下步骤： 1. 将安全目标违反定义为顶级事件 2. 把系统专家带到一个单人房间 3.构造故障树，以识别较低级别的故障和可能导致最高级别事件的故障(违反安全目标) 4. 确定树的最小割集，这些割集会导致错误，从而违反安全目标。每个事件发生的概率可用于指导应包括哪些错误或错误。 5. 定义每个最小切割集的技术安全要求 可以使用FMEA确定技术安全要求的第二种方法。与FTA相比，失效模式效应分析(Failure Mode Effect and Analysis, FMEA)是一种分析故障或故障对系统影响的归纳分析方法 使用一个用于CAN请求的FMEA结构示例来演示该方法
选择发送模块“发送CAN上的关闭请求”功能作为故障模式分析的功能。下一步是列出潜在的故障及其故障原因。严重程度为9级，其安全相关。推荐的操作基本上是技术安全要求，在本例中是： 1. 发送模块应实现CAN堆栈软件至少满足ASIL A的要求。 2.发送模块应实现CAN消息请求门关闭消息的的端到端诊断。 3.后备箱模块在使用CAN信号之前应该对信息进行rolling counter和checksum的诊断。 在识别共因失效时，FMEA是一种很有效的方法。例如：如果电源坏了怎么办?关键是要用任何一种方法来识别所有可能引起危害的单点故障和潜在的双点故障。 无论使用何种方法，技术安全要求都应符合标准规定的下列特征： 1. 明确的和可理解的(对意思有共同的理解) 每个TSR都应该根据这五个特征进行验证。 所有的安全要求都应该具有以下属性：
ISO26262标准还要求在管理安全要求时确保满足以下特性: 1 层次结构(需求被安排在几个连续的层次上，并与相应的设计阶段保持一致) 2 完整性(安全要求完全执行前一级的所有安全要求) 3 外部一致性(安全需求之间不会相互矛盾) 4 可维护性(可以在安全生命周期中修改或扩展需求) 1 2 3 4可以通过软件工具来保证：如(e.g. - DOORS, Polarion etc) 解读FTTI 安全机制确保在诊断出可能违反安全目标的错误时，项目能够过渡到并保持安全状态。这样做的一个重要方面是能够在分配给相关项的容错时间间隔或FTTI内完成此操作。 ECU本身的实际可用时间可能远远小于与安全目标相关的车辆级别FTTI。在制定包括单点故障安全机制在内的技术安全要求时，安全工程师对现有硬件和软件的时序约束和能力进行分析和评估是关键。 需要包含在这个分析中的一些方面包括 为了获得FTTI，推荐使用以下的方法 ·基于时序图的分析 ·专家判断 ·在受控条件下的车辆试验 ·仿真和HiL测试 总结 ISO 26262标准第4部分第6条描述了产品安全生命周期中对技术安全要求的需求。编写良好的技术安全要求是确保达到足够的产品安全水平的先决条件。该标准提到了技术安全要求需要达到的特性和特点。然而，该标准并没有阐明提出技术安全要求的任何方法。本文讨论了如何应用于识别可能导致安全相关故障并导致危险的单点故障和多点故障。识别出的最小切割集可用于推导大量的技术安全要求。 |
|
|
