目录
01 TSC定义
所处位置
TSC：Technical safety concept技术安全概念
TSR：Technical safety requirement技术安全需求
在系统开发阶段属于安全活动4-6
系统层产品开发示例
TSC目的
目的是从功能安全概念FSC中细化提取出技术安全需求TSR，同时考虑功能概念和架构主要的假设。系统表现，以及与外部环境的交互接口也应该被识别定义。
TSC组成
FSR到TSC是示例：
FSR由TSR和安全机制组成（来自AUTO世代）
TSR
由FSR技术化转来，示例
安全机制
在part4中关于安全机制的类型定义的很清楚和全面。后面会专题写安全机制的文档。
技术安全需求（Technical Safety Requirement, TSR）是为满足功能安全需求（Functional Safety Requirement, FSR）在技术层面派生出的可实施的安全需求。TSR应该明确功能安全需求在各个层级的技术实现，考虑相关项定义和系统架构设计，解决潜在故障的检测、故障避免、安全完整性（即满足ASIL等级）以及产品生产和服务方面的必要安全问题。
具体来说，TSR包括硬件和软件方面的要求，例如硬件的故障检测和容错能力、软件的错误处理和故障恢复机制等。TSR的制定通常基于功能安全需求（FSR），通过组件层别的安全分析（如FTA和FMEA）对功能安全开发最初的安全需求（即安全目标SG）进行细化，得到组件级别的功能安全需求。
02 TSC注意事项
1、OEM传递的安全需求，可能不包含FSC文档，说白了，就是OEM不给tier1 FSC。只给一个safety goal
功能安全概念是功能安全要求的规范，包括相关信息，它们对架构元素的分配，以及实现安全目标所必需的交互。根据ISO26262 Part 4 Clause 6.4.1，技术安全要求需要符合概念阶段开发的功能安全概念。
情况一：一个特定的项目可能会遇到FSC缺失的情况，并且它不在他们的工作职责划分之内。在这种情况下，FSC需要逆向工程或定制，以完成安全案例。
情况二：FSC是可用的，但功能安全要求没有得到适当的引出，并导致某种部分工作产品。这两种场景都是不可取的，并且超出了拥有此工作产品的标准的目的。
供应商应通过DIA确保上游工作产品由双方一致同意的一方按时交付。
FSR和TSR之间是有关联性的，如果FSC不能很好的提供，那么FSR和TSR之间的关系，需要分析时，主动和OEM保持一致，或共同确认。
2、产品开发涉及多部门或公司
这是很常见的一种情况，比如底软采购的autosar的底软包、操作系统开发也是定制的，CAN通信则由EE部门开发，DRE/软件工程师，则整合这些软硬件开发元素。
解决办法：前期DIA签署时，基于公司的属性，明确开发范围，和集成责任。
3、计算资源冲突
用于ECU硬件的微控制器可能没有足够的资源，比如可用的运行时、内存分区功能、空闲RAM或Flash，以实现满足项目的目标ASIL所需的安全控制策略。有时，如果有这样的选择，可以通过仔细选择安全策略来克服运行时或CPU吞吐量等挑战。例如，与基于定时器中断的反馈相比，选择基于ADC的反馈可能会减少CPU负载。应在报价阶段要求评估用于实施适合该项目的安全概念的预期硬件的适用性。
03 TSC案例
本文介绍BMS系统设计与软硬件设计为例，大家可以看到基本的思路即可。
基于系统的层级，将系统分为若干子系统，在最小子系统内进行制定技术安全要求TSR。
基于FSC的功能安全ASIL等级，将需求进行ASIL等级分解。并对不同的分解方案做对比。
采用安全系统+主系统的方案进行架构设计，得到相应的技术安全要求TSR。
系统在进行设计时，这里举例采用FTA的方法将ASIL等级进行分解
依据TSR需求设计的新的架构图
再贴一个EPS的FTA系统层级分析的示例
