功能安全开发（⼀）功能安全开发流程（本⽂是之前发过的，重新整理调整了内容，以⽅便更多汽车电⼦产品开发可进⾏参考）
ISO26262专门针对汽车⾏业E/E系统安全相关的应⽤提出了规定，从产品开发的需求输⼊开始，标准覆盖了概念开发、系统开发、软硬件开发、⽣产、操作、维修，这样⼀个完整的汽车产品⽣命周期。
功能安全开发要求开发流程是符合V模型的。对于V模型的开发⽅式，左侧是基于需求的活动，右侧是基于测试的活动，最终要求左侧所有的需求都通过右侧对应的测试，以验证其得到了满⾜。⽽对于功能安全开发，其特殊性在于，标准只关注安全相关的活动。也就是左侧是安全需求，右侧是安全相关功能的测试。ISO26262强调的⼀点是追溯性，对于左侧需求相关活动不同层级的开发活动，需要可以在任⼀层追溯到最初的安全需求。当进⾏到右侧的测试时，同样要求每⼀项测试活动，都可逐层追溯到其对应的安全需求。对追溯性的强制要求和关注，既保证了安全需求的实现没有遗漏，同时在各项活动有更改的时候，保证了可准确到所有受其影响的上下层开发活动。
图1 功能安全管理流程
分析功能安全开发流程的要求，其与标准的V模型开发没有冲突。对于已建⽴V模型开发流程的企业，其主要⼯作是在各环节对应嵌⼊安全相关活动的要求，需要关注的是保证活动的可追溯性。⽽对于希望建⽴全新的功能安全开发流程的企业，其可从三个管理⽅向⼊⼿。
汽车安全系统功能安全管理流程可以从配置管理开始，配置管理的⽬的是保证对安全⼯作产物以及开发这些产物的原则、适⽤条件进⾏唯⼀标识，并且在任何时候能可控地对其复现。配置管理另⼀个重要的⽬的是在多次迭代开发之后，能保证当前版本与历史版本的互相追溯。
配置管理的实现不仅仅需要对开发产物的管控，开发活动中的⼈员、权限、开发环境和分⼯合作等，都会对最终产物产⽣影响。因此，良好的配置管理不能单纯寄希望于项⽬参与⼈员和管理⼈员。随着开发活动的深⼊，开发⼯作的细分会迅速增加，仅靠⼈⼒管理⽆法保证全⾯覆盖。从项⽬成⽴开始，我们就需要相应的专业⼯具进⾏配置管理。项⽬⽴项后，项⽬经理负责组建项⽬团队，⽽功能安全经理则负责组建安全开发团队。从团队成⽴那⼀刻开始，配置管理就需要对项⽬团队⼈员构成、不同⾓⾊的权限、⼯作活动的分配、每⼀阶段⼯作产物的评审、归档等⼯作进⾏管理。这个管理需要贯穿整个开发活动，直⾄全部开发活动结束。
需求管理和测试管理都需要在配置管理的管控下进⾏。功能安全开发的最⾼安全需求安全⽬标，所有不同层级的安全需求都最终源于安全⽬标，并继承其所属安全⽬标中最⾼的ASIL等级。对于不同ASIL等级对应的开发和测试活动，在每个层级的要求都不同。⽐如系统设计的安全分析，标准对不同ASIL等级规定了对应所需进⾏的分析⽅法。我们常说对某个产品是ASIL C 等级，这意味着这个产品对应的安全⽬标最⾼要求是ASIL C，它也可能同时存在⼀些低等级要求的安全⽬标，⽐如ASILA、ASIL B。对于这些复杂的安全需求和测试的管理，显然是需要专业⼯具才可实现有效管理和可靠追溯的。
图2功能安全开发流程
进⾏系统开发时，电控系统的安全需求输⼊来源于上层汽车⼦系统导出的FSR。系统开发需要将功能安全需求细化为技术安全需求TSR。基于系统架构设计，需要进⾏安全分析，并提出相应的安全机制，这些安全机制也是TSR的⼀部分。安全分析可以帮助完善系统设计。对于ASILC和D等级的产品设计，需要对系统设计同时进⾏FMEA和FTA分析。如果电控系统是主从结构的，TSR需要同时包括电控系统级的TSR和电控主从系统的TSR。系统阶段所有的TSR最终需要分配给系统中软硬件元素，如果有必要，可以做ASIL等级的分解。此时可以定义初版的软硬件接⼝（HSI）。HSI 中需要定义硬件设备的操作模式和配置参数、对软件分区的⽀持、内存分布、共享资源、定时器、计数器、中断、硬件诊断特征以及需要软件实施的硬件相关诊断等。
图3 主从结构电控系统TSR
对于硬件设计对安全需求的实现，标准规定了三个量化指标进⾏评价：单点故障指标SPFM，潜在故障指标LFM和随机硬件失效指标PMHF。对与ASIL C等级的功能设计，其具体要求是SPFM>97%，LFM>80%，同时PMHF<100Fit。这三个指标的计算可以通过FMEDA的⽅法。这三个指标具体与硬件设计中各元器件的失效率和系统对其失效模式的诊断覆盖率有关。
指标的实现可以考虑选择低失效率的元器件和提⾼诊断覆盖率。
软件设计需要分级进⾏，包括软件架构设计、软件单元设计和代码⽣成。对于ASIL C等级的产品，其软件架构的标记法要求半正式标记法。在实际开发中，需要以模型的⽅式来开发。同时软件架构设计需遵循标准要求的指导原则：软件的层次性，⾼内聚，低耦合；避免使⽤中断等。对于软件单元设计的标记法，同样对应ASIL C要求半正式标记。所以在电控系统的应⽤层开发中，普遍使⽤simulink进⾏模型开发，以达到标准要求。对于软件单元的实施，标准同样列举了⼀些设计原则。但简单的原则性规定对具体的开发活动难以借鉴和遵循，标准推荐了⼀些参考的编码规则，例如C语⾔开发可以借鉴MISRA C。
所有开发活动完成后，需要进⾏的就是对应的测试和验证。对于硬件，从样件测试⼀直到硬件全部的验证测试。⽽对于软件开发，其失效都属于系统性失效。对于系统性失效，可以通过在设计阶段遵循良好的设计原则，在测试阶段进⾏充分的测试来避免。因此标准在软件测试部分，从代码、单元到软件系统集成，都花了很⼤篇幅进⾏了详细规定。软件测试需要覆盖
MIL/SIL/PIL/HIL测试。软硬件分别测试结束后，需要进⾏电控系统集成和相应的测试。最后要进⾏的是整车⼦系统和整车级的系统集成和测试。当最终右侧的测试满⾜了全部左侧的需求时，代表着电控系统开发活动完成了完整的V模型开发。