如何写好技术安全需求TSR？

在item的开发过程中，制定合适的TSC是开发符合功能安全标准的一个关键前提。这在系统级的标准产品开发的第4部分中有详细的说明。技术安全要求和技术安全概念构成了导出硬件和软件安全要求的基础，然后由工程团队用于开发安全产品。就像任何其他形式的产品开发一样，对需求进行多次修改是非常不可取的。这主要是由于成本的增加，工作产品中出现不一致的可能性及其对整个项目进度的影响。良好的技术安全要求实际上是有效实施功能安全的基础。

目前，ISO 26262标准并没有提供任何直接的指导，以确定某一项目的特定安全目标的技术安全要求的具体方法。本文提供了使用安全分析技术（如FTA或FMEA）提出全面而简明的技术安全要求的指南。

本文的目的是支持那些负责开发技术安全概念的安全工程师。此外，本文认识到，在实践中，项目面临着利益相关者利益缺失、多方开发、上游工作产品缺失或不完整等挑战。本文捕捉到了这些现实世界中的挑战，并提出了解决方案。文章最后引用了几种容错时间间隔的方法(FTTI) ，一个关键参数对技术安全概念的有效性至关重要。

 

写好TSR的重要性

技术安全要求基本上是安全工程师对需要做什么来确保所涉及的项目或部分项目(如单片机或软件对象)在所需的ASIL级别上达到功能安全的理解。特定的设计方法并非强制要求导出TSR。关键是要用清晰、简洁、明确的语言和符号来书写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工作产品中详细描述。一个编写良好的技术安全