|
经过概念阶段，最终得到了FSR。FSR是item级的功能安全要求，进行系统阶段的开发，需要将FSR细化为system级的TSR，然后进行系统设计。系统阶段的安全活动可以组成一个小的V模型的。系统阶段在V模型的左侧主要是细化TSR和进行产品的系统设计，左侧的开发活动通过右侧的集成和测试、安全确认和功能安全评估进行对应的验证。最终完成系统阶段的所有开发和验证，可以进行生产发布。 图1 系统阶段功能安全活动 系统开发位于概念开发和软硬件开发之间，系统的TSR承接的是概念阶段的FSR，是FSR在技术层级的具体实现。分析得到的所有TSR最终需要分配到系统架构中的具体软硬件元素上 图2 系统开发TSR 进行TSR分析时，需要基于FSR和系统初始架构。对于初始架构，需要在概念开发的基础上进一步细化。首先要细化系统的外部接口（通信接口）、环境约束和系统配置要求等。然后系统内部各子系统的设计需要细化。子系统内各功能模块需要明确，并且互相之间的关系需明确。下图是部分细化的初始架构，在实际开发中需在此基础上根据具体设计要求，增加更多细节，以便于理解功能模块间的相互关系和进行相应的功能安全分析。 图3 细化初始架构 对于每一个SG，其针对的是防止功能失效的危害。对于一个完整的功能，其实现可分为三部分：传感器、控制器和执行器。在分析TSR时，需要考虑安全机制和安全措施，用以检测功能失效。安全措施需要有效避免单点和潜伏故障。这个设计方法之一可以分别考虑功能中各部分的预期功能和对应的安全措施。 图4 安全措施的考虑 对于SG001，以Sensor部分，即CMU为例。对于其功能要求的FSR001，可以导出如下TSR，并分配到CMU上的元素上。 图5 FSR001导出的TSR 在概念开发阶段，对SG进行安全分析后还会得到故障诊断要求相关的FSR。这些FSR可以导出safety measure相对应的TSR。这里假设概念阶段的FSR为FSR10，导出对应的TSR（仅限硬件架构要求）如下。 图6 FSR10导出的TSR 在系统阶段，同样要进行安全分析，以验证系统设计中对单点故障、潜伏故障的诊断是否全面，SM是否有效。对于ASIL C等级的BMS，FMEA和FTA分析都是标准要求的。 经过分析后得到的所有TSR最终要分配到系统架构中的软硬件元素上。接下来需要定义初版的HSI(Hardwar-SoftwareInterface)。HSI 中应包括由软件控制的硬件设备和支持软件运行需要的硬件资源。通常来说，单片机相关的硬件资源是需要定义的重点，包括单片机的各工作模式定义、硬件内部共享和专用资源（内存、定时器、中断和I/O等）、硬件通讯机制和时间约束等。另外一个重点是定义硬件诊断特征和需要软件实现的硬件诊断功能。 系统阶段右侧验证的活动，需要在更下一层的软硬件工作都完成后才可以进行。相关项的集成和测试是分阶段进行的，按可进行的顺序，依次是软硬件集成、系统层级的集成和整车层级的集成。 图7 相关项的集成和测试 在验证阶段的所有活动，包括设计验证、安全分析、硬件集成和测试、软件集成和测试、相关项的集成和测试，其目的是为每项特定活动的结果是符合相应规定要求提供证据。而整车层级的所有针对相关项的集成和测试，最终目的是为预期使用的恰当性提供证据，并确认安全措施针对所开发的车辆的充分性。所有安全活动有效的证据需要通过安全确认来实现，安全确认首先提供了符合安全目标和功能安全概念适合相关项的功能安全的证据。最终安全确认要提供的是在整车层面的安全目标正确、完整且完全得到实现的证据。 前述所有活动都完成后，可以组织进行功能安全评估。功能安全评估可以由负责功能安全的组织进行，比如整车厂或者负责功能安全的供应商，还可以是整车厂委任的第三方或专业认证机构进行。最终评估结果会以功能安全评估报告的形式给出。 （本文及BMS功能安全开发系列文章中，所有例子和相关参数均为个人交流使用，所有均为假设，无任何项目相关或验证。仅供参考学习） |
|
|
