在开发安全关键型应用时，选择具备成熟历史的硬件平台、完善的应用与诊断软件，以及经过功能安全认证的开发工具链，是确保项目顺利启动并高效完成开发和认证的关键。这一组合不仅显著节省时间与成本，还能帮助开发团队应对多样且复杂的功能安全标准要求，从容应对合规挑战。本文将深入解析，为什么经过功能安全认证的开发工具链，能够为安全关键型嵌入式项目的成功落地带来决定性的优势。

01 安全趋势的演进

近几十年来，需要满足功能安全要求的嵌入式系统越来越多。工业控制、医疗设备和汽车等领域对产品的可靠性要求越来越高，不仅要正常运行，还要在出现故障时保证不出安全问题。在过去，各行业基本都有自己的一套安全标准。现在的趋势是，安全标准正在逐渐统一，允许将一个领域标准中的方法在合理的情况下应用于其他领域。

其中，IEC 61508是一个基础性的通用功能安全标准，为各种可编程电子设备提供了框架。很多行业标准，比如机械领域的IEC 62061和汽车领域的ISO 26262，其实都是在IEC 61508的基础上，针对各自的应用场景做了调整和扩展。

这一功能安全标准的普及，离不开市场需求与法规政策的双重驱动。终端用户与系统集成商对产品可靠性和第三方独立功能安全认证的关注日益增强，使得诸如IEC 61508合规性认证逐步成为项目立项的刚性要求。

02 功能安全设计，从硬件开始

构建功能安全系统，首先需要在硬件层面保障关键器件的可靠性。许多成熟组件已具备明确的失效率与失效模式，通过冗余设计或容错机制可有效降低故障风险。然而，MCU等高复杂度器件则需更深入的设计考量，如抗辐射干扰能力、非易失性存储器的耐久性等。

相对而言，软件故障往往更具隐蔽性。一个栈溢出问题可能会导致系统完全失控。为此，主流芯片厂商通常会提供“安全软件包”（包括安全手册、自检诊断库等）和经过市场验证的芯片，助力开发者快速构建安全关键型系统。

03 开发工具链的重要性

软件项目若涉及功能安全关键功能，使用“合格开发工具链”是基本前提。根据IEC 61508第三部分第7.4.4节的要求，工具链的合规性需根据其在开发流程中的角色与风险等级进行评估。然而，该标准对C编译器等工具链并未提供具体实施细则，因此需投入大量资源进行验证和文档准备，尤其是在SIL 3/4等高安全完整性场景中。

04 工具链认证的理想路径

自行进行工具链认证不仅耗费巨大人力成本，更要求具备编译器设计与测试方面的专业能力。为解决这一挑战，IAR与国际认证机构TÜV SÜD合作，推出经过功能安全认证的工具链解决方案——IAR Embedded Workbench功能安全版，适用于Arm、RISC-V、Renesas RX、RL78、RH850及STM8架构。其认证覆盖内容包括：

IAR Embedded Workbench功能安全版满足10项国际功能安全标准，包括IEC 61508、ISO 26262、IEC 62304、EN 50128/EN 50657、IEC 60730、ISO 13849、IEC 62061、IEC 61511以及ISO 25119，体现了IAR工具的通用性与跨行业适用性。

05 如何落地？

经验丰富的开发团队深知，功能安全项目中最难平衡的往往不是技术难题，而是“合规性”与“效率”之间的拉锯战。过度流程化会导致大量无效工作，而草率应对则无法通过认证。如何在控制成本、缩短上市时间与保障功能安全之间实现最佳权衡，是项目成功的关键。

06 软件之道

根据IEC 61508等标准进行软件开发，往往意味着必须采用V模型、选择合适的编程语言、执行严格的测试与验证。如何在不牺牲安全性的前提下提高开发灵活性？

IAR Embedded Workbench提供经过验证的语言扩展功能，允许开发者安全访问底层硬件资源。此外，其先进的优化功能可缩减目标代码体积。

07 为什么选择IAR功能安全工具链？

选择IAR Embedded Workbench功能安全版，您可获得：

涉及的安全标准：

IAR Embedded Workbench功能安全版（适用于Arm、RISC-V、Renesas RX、RL78、RH850及STM8）已经过TÜV SÜD认证，涵盖以下标准：

下一步？立即行动！

将芯片厂商提供的安全包与IAR Embedded Workbench功能安全版搭配使用，为安全关键型产品开发奠定了坚实基础，不仅加速项目启动，还显著减轻了合规性验证等非开发性工作负担，加速了安全关键型产品的开发和认证。

了解IAR Embedded Workbench 功能安全版更多信息。

网络研讨会——

出海合规第一步：如何满足功能安全合规要求？

随着中国工业设备、控制系统及整线解决方案持续走向全球市场，如何在产品设计阶段就全面考虑目标市场的功能安全要求，已成为企业成功“出海”的核心挑战。

出口欧盟、北美等主要市场，必须严格遵循当地法规与指令的要求。法规所关注的不仅仅是产品本身的技术指标，更聚焦于风险的可控性与系统性的安全保障。尤其针对复杂设备和智能产线，认证机构对系统架构、开发工具及测试验证等各环节的合规性与可追溯性要求日益严格。

为助力中国企业高效迈出合规第一步，FSG 功能安全工作小组成员单位将联合举办本次线上研讨会，围绕法规趋势、开发工具、芯片支持与测试验证四大维度，深入解析出海过程中的功能安全合规要求与解决方案，帮助企业提升开发效率、缩短认证周期、降低出海成本，加速产品进入国际市场。

内容包括：
• 秒尼科：欧盟新机械法规下的海外出口影响和应对
• 瑞萨电子：基于瑞萨电子MCU/MPU的工业功能安全解决方案
• IAR：合规开发从工具开始——开发工具如何助力客户高效达成功能安全认证
• Parasoft：出海功能安全合规——Parasoft 自动化测试验证体系构建与认证加速方案
• CSA Group：出海功能安全合规——北美工业整机及相关产线合规路径

参会收益：
• 全面了解工业产品出海过程中功能安全合规的关键要求
• 系统掌握从芯片选型、开发工具到测试验证的合规实现路径
• 探索行业领先方案，借助成熟工具与技术资源，缩短产品开发与认证周期
• 与多位领域专家在线交流，解答实际项目中遇到的合规难题

下载会议资料

芯片ISO26262功能安全认证的必要性

车规芯片：为什么要做功能安全

车辆安全的性能对于汽车制造商和消费者来说都是至关重要的。不仅在传统的车辆动态控制和主被动安全领域，更在于智能辅助驾驶和自动驾驶领域。新的功能越来越多地关注系统安全、硬件安全和软件安全。这些功能的开发促使芯片的集成化和算力越来越高，软件、硬件技术日益复杂，来自系统性失效和随机硬件失效的风险也相应逐渐增加。功能安全专攻的方向也是解决系统性失效和随机硬件失效。

汽车芯片和集成电路（IC）逐渐演变为了目前智驾的基础。汽车芯片和集成电路（IC）作为关键器件，受到了大众的重点关注。为了确保车辆的安全可靠，并最终保证商业上的成功，芯片设计企业需要关注其中之一的关键特性，即功能安全（ISO26262）。

ISO 26262：功能安全标准

ISO26262是以IEC61508为基础,为满足道路车辆上电气/电子系统的特定需求而编写。

安全是道路车辆开发的关键问题之一。汽车功能的开发和集成强化了对功能安全的需求,以及对提供证据证明满足功能安全目标的需求。

为了实现功能安全,ISO26262：

a) 提供了一个汽车安全生命周期(开发、生产、运行、服务、报废)的参考,并支持在这些生命周期阶段内对执行的活动进行剪裁;

b) 提供了一种汽车特定的基于风险的分析方法,以确定汽车安全完整性等级(ASIL);

c) 使用 ASIL等级来定义 GB/T34590中适用的要求,以避免不合理的残余风险;

d) 提出了对于功能安全管理、设计、实现、验证、确认和认可措施的要求;

e) 提出了客户与供应商之间关系的要求。

它定义了四个汽车安全完整性等级（ASIL-A，ASIL-B，ASIL-C和ASIL-D）的关键指标和目标。

ISO26262：增加可靠性，识别风险的一些安全分析的方法

大到汽车系统层级，小到IC、IP层级，均可使用以下几类方法降低系统及研发的风险，从而使得汽车系统或者IC更为安全可靠。以下分析方法统称为安全分析，安全分析的目的是确保由于系统性故障或随机硬件故障而导致违背安全目标的风险足够低。

  1. 安全机制：针对的是电气/电子系统的功能安全,通过安全措施(包括安全机制)来实现。
  2. FMEDA：故障模式影响和诊断分析，是汽车功能安全开发活动在硬件设计阶段重要的活动，输出的FMEDA报告也是功能安全相关组件主要的安全性分析交付物之一，主要用于验证系统/子系统或者IC的设计满足ASIL等级要求的安全度量指标。FMEDA可以同时分析SPFM、LFM和PMHF三个指标，度量产品的硬件设计是否符合相应的安全要求。
  3. 产品设计的过程中SPFM 和LFM 可以用来验证硬件构架设计应对随机失效的鲁棒性，PMHF用来评估随机硬件失效率导致违反安全目标的风险已经足够小。
  4. FMEA：失效模式和影响分析是一种“自下而上”的技术分析方法：用来识别、分析和记录基础单元的失效模式、原因和影响。 然后以此为基础制定改进措施。
  5. DFA：相关失效分析，可以分析共因失效和级联失效造成的
  6. FTA：通常以演绎自上而下的方式执行,从非预期的系统行为到确定导致该行为的可能原因。 FTA 包含覆盖了所有可能导致违反某个危害事件的多个故障和事件或情况的组合。

ISO26262：功能安全可降低因为芯片失效引起的不合理风险

在汽车电子产品应用中，芯片故障可以从两个维度来进行分类：一是由于汽车芯片设计漏洞或错误实现所引入的人为系统性故障，二是由于芯片老化和电子迁移等事件导致的随机硬件失效故障。为了解决这两类故障，汽车安全芯片设计企业必须严格遵循ISO26262功能安全标准。

针对系统性失效，通常使用DFMEA方法来识别各种可能的设计失效，并提出相应的设计预防和探测措施，以避免问题芯片的产生。其中，DFMEA的重要作用是通过结构化方法，帮助设计团队识别和解决实际错误或潜在错误源头。

对于随机硬件失效，结合各种安全分析和DFA分析，能够全面覆盖随机故障，并在芯片设计过程中确定需要增加的安全设计措施。

完整的故障避免（fault avoidance）和故障容忍（fault tolerance）措施，不仅仅限于以上的简要说明的内容，实际项目开发要遵循完整的流程去执行和落地。

针对随机硬件失效的各种失效模式，需要有相应的功能安全机制进行应对。包括用于保护内部 SRAM 和传输中数据的纠错码 (ECC)、探测硬件死锁(deadlock)的 watchdog timer、探测寄存器内容故障的Parity、针对复杂逻辑的硬件冗余和锁步、以及探测门级随机硬件失效所需运行的软件自测库等等。由此可见，为了应对随机硬件失效，额外的硬件及软件安全机制的设计均是不可或缺的。

总结

尽管IC已经变的非常可靠和耐用，但依然会发生故障。例如：现在的IC越来越追求小型化，很容易发生相邻管脚由于ESD等原因引起的开路和短路，从而对IC造成损害甚至完全使得IC丧失功能。这些失效可能导致车辆某一个功能失效，甚至可能导致人命丧失。此外，对于大量的汽车研究，危险故障几乎每天都会发生。因此，无论在汽车系统中还是IC产品中功能安全是势不可挡的。

无论主机厂、Tier1 或者Tier2选择主要功能或者是辅助功能IC首选都是选用符合ISO 26262认证的，通过ISO26262认证过的产品产降低了不合规风险，节约了研发和后期维护的成本，使得可靠性增加，深得客户的信赖。

文章转载于FSG成员单位秒尼科技术（MUNIK）

时间：2025-07-23 10:00 至 12:00

地点：电子发烧友网络会议平台

随着中国工业设备、控制系统及整线解决方案持续走向全球市场，如何在产品设计阶段就满足目标市场的功能安全要求，已成为企业成功“出海”的核心挑战。

出口欧盟、北美等主要市场，必须严格遵循当地法规与指令的要求。法规所关注的不仅仅是产品本身的技术指标，更聚焦于风险的可控性与系统性的安全保障。尤其针对复杂设备和智能产线，认证机构对系统架构、开发工具及测试验证等各环节的合规性与可追溯性要求日益严格。

为助力中国企业高效迈出合规第一步，FSG 功能安全工作小组成员单位将联合举办本次线上研讨会，围绕法规趋势、开发工具、芯片支持与测试验证四大维度，深入解析出海过程中的功能安全合规要求与解决方案，帮助企业提升开发效率、缩短认证周期、降低出海成本，加速产品进入国际市场。

内容包括：
• 秒尼科：欧盟新机械法规下的海外出口影响和应对
• 瑞萨电子：基于瑞萨电子MCU/MPU的工业功能安全解决方案
• IAR：合规开发从工具开始——开发工具如何助力客户高效达成功能安全认证
• Parasoft：出海功能安全合规——Parasoft 自动化测试验证体系构建与认证加速方案
• CSA Group：出海功能安全合规——北美工业整机及相关产线合规路径

参会收益：
• 全面了解工业产品出海过程中功能安全合规的关键要求
• 系统掌握从芯片选型、开发工具到测试验证的合规实现路径
• 探索行业领先方案，借助成熟工具与技术资源，缩短产品开发与认证周期
• 与多位领域专家在线交流，解答实际项目中遇到的合规难题

立即点击以下链接报名注册，与行业专家共探功能安全合规之路！

出海合规第一步：如何满足功能安全合规要求？ – 电子发烧友在线研讨会

演讲人

冯丙金•秒尼科实验室总监

秒尼科实验室总监，前外资机构CBTL签证官，首席工程师和授权签字人。

戴其宏•瑞萨电子嵌入式处理器事业部中国市场部专家

负责工业市场推广，十多年的半导体从业经历，拥有丰富的市场经验。为客户嵌入式处理器选型和项目开发提供专业建议。

潘锋•IAR FAE

目前在IAR担任高级工程师，主要负责IAR嵌入式开发解决方案和嵌入式安全解决方案的推广和咨询工作，包括广泛应用于嵌入式领域的IAR Embedded Workbench，IAR Visual State等知名产品。

徐晨英•Parasoft资深方案架构师

Parasoft资深方案架构师，聚焦软件质量保障及合规功能安全领域。在汽车电子、医疗器械、机器人等对功能安全高度敏感的赛道，擅长将AI驱动的自动化测试技术与IEC61508、UL标准等国际合规要求深度融合。

季方舟•CSA市场开发经理

CSA华中区域工业及防爆开发经理。从事认证行业10年，熟悉CE及北美相关准入要求。

立即点击以下链接报名注册，与行业专家共探功能安全合规之路！

出海合规第一步：如何满足功能安全合规要求？ – 电子发烧友在线研讨会

带您解读AI Act REGULATION (EU) 2024/1689

《人工智能法案》为汽车行业设定新的合规标准

欧洲议会和欧洲理事会在2024年6月13日通过了REGULATION (EU) 2024/1689 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL（人工智能法案，AI Act）。

此法案规定了人工智能（AI）技术的统一监管规则，旨在欧盟内部对AI系统进行有效的风险管理。该法规将AI系统按照风险程度分为不可接受、高风险、有限风险和最低/无风险几类。高风险AI系统，如用于自动驾驶、驾驶辅助系统的AI，需遵循严格的要求，包括强制性的合规性评估和持续监控。

《人工智能法案》特别禁止某些AI行为，尤其是那些被认为具有不可接受风险的行为，例如用于社会评分的AI系统或未经同意抓取个人数据的面部识别技术。同时，对于最低或无风险的AI系统，规定的义务较少，但鼓励开发者遵守自愿行为规范。（《人工智能法案》中的第5条（禁止某些AI行为）和第6条（AI系统分类））。

此外，法规强调对于高风险AI系统，要求进行详细的技术文件编制、信息透明和良好的治理，确保有人工监督，并注重系统的网络安全性。该法案旨在为欧盟内的AI技术发展和应用创造一个更加健康、安全、包括民主、法治和可信的环境，同时保障公民的基本权利。

《人工智能法案》通过的关键时间点

2024年8月：《人工智能法案》正式生效。

2024年2月：欧洲人工智能办公室成立。

2024年1月：推出AI创新包，支持人工智能初创企业和中小企业。

2023年12月：立法机构达成《人工智能法案》政治协议。

2023年6月：欧洲议会确定《人工智能法案》的谈判立场。

2022年12月：欧盟理事会就《人工智能法案》形成了总体立场。

2022年6月：西班牙启动首个AI监管沙盒，推动AI法规进展。

2021年12月：区域委员会对《人工智能法案》发布意见。

2021年6月：欧盟委员会就民事责任问题进行公众咨询，讨论数字时代和人工智能的责任规则。

2020年2月：欧盟委员会发布《人工智能白皮书：欧洲的卓越与信任》。

2019年6月：召开首届欧洲人工智能联盟大会，并发布“值得信赖的人工智能”政策建议。

这些里程碑反映了欧盟在推动人工智能监管和创新方面的战略进程，目的是通过确保合规性、建立信任并促进技术创新，使欧洲在全球AI治理中处于领先地位。

法案的目的与意义

1.保障公民安全与基本权利：《人工智能法案》的首要目标是保护公民免受潜在有害AI技术的影响，特别是在高风险领域，如医疗、金融和公共安全等。高风险AI系统必须满足严格的技术要求、透明度和数据治理标准。（根据《人工智能法案》的第6条和第8条得出）

2.促进AI创新与市场信任：通过为各类AI技术设定清晰的法规框架，法案为创新提供了可预见的合规路径。《人工智能法案》第8条和第9条强调，企业在遵循这些合规要求后，不仅能确保其AI系统的安全性和合规性，还能增强公众对AI技术的信任，从而提升市场接受度。这直接关系到高风险AI系统的合规性和透明度，以及如何通过合规性获得消费者和用户的信任。

3.加强对不当AI应用的监管：法案明确禁止某些不符合伦理或可能侵害隐私的AI应用，如社会评分系统和未经同意的面部识别技术。通过此举，确保AI技术不会滥用个人数据，进而提升公众对AI的信任。（根据《人工智能法案》中的第5条和第52条得出）

法案如何影响您的业务

如果您的公司涉及AI工具的开发，特别是在汽车行业中的主机厂及一级、二级零部件供应商，您需要了解《人工智能法案》对您业务的影响，特别是针对高风险AI应用的严格合规要求。

根据《人工智能法案》的规定，若您的AI系统被归类为高风险系统（例如自动驾驶、驾驶辅助系统等），您将面临以下几项关键合规要求：

1.安全性保障：您必须确保AI系统在各种驾驶场景下的安全性，尤其是在自动驾驶或其他关键安全应用中。系统需要经过严格的相关安全测试（如汽车功能安全ISO 26262和网络安全ISO 21434）和验证，以确保不会对驾驶员或乘客的安全构成威胁。

2.透明度要求：为增强系统的可审计性，您需要证明AI系统的决策过程透明且可追溯。用户和监管机构必须能够理解并验证AI系统如何做出决策，这对于建立市场信任和符合法规至关重要。

3.数据保护和隐私合规：如果您的AI工具处理个人数据，您必须确保符合欧盟的《通用数据保护条例》（GDPR）。这意味着数据的收集、存储、使用以及传输都必须得到用户同意，并且符合隐私保护的规定。

4.合规性评估和审查：高风险AI系统还需要进行定期的合规性评估，并可能面临监管审查。这包括对系统性能、安全性以及合规性的持续监控。您的公司需要准备好应对这些审查，并确保产品始终符合规定要求。

文章转载于FSG成员单位秒尼科技术（MUNIK）

在汽车、工业、医疗等安全关键型应用中，确保功能安全合规性需要严格的工具链验证。开发安全关键型软件的企业必须遵守ISO 26262、IEC 61508、ISO 62304 等国际标准对编译器工具链进行全面的验证。 

尽管部分企业考虑自行验证工具链，但现实情况是，这个过程成本高昂、耗时且资源密集。虽然独立实现合规性是可能的，但实际执行这一过程通常需耗费 6 至 12 个月的专职投入，并动用多名工程师。验证过程本身涉及大量测试、文档以及反复评审，成本高昂且风险巨大。

工具链验证的现实情况

编译器工具链的功能安全验证工作不仅仅是确认编译器“是否能运行”，而是涉及严格的测试，以验证其在实际使用条件下的可重复性、正确性和可靠性。

正如 Stack Overflow 上一位专家所指出：“这项工作的一部分是运行验证测试套件，编译数千个测试程序并将实际结果与预期结果比对。另一部分是 ISO 标准一致性测试。虽然这些测试会发现一些问题，但是测试都不是详尽无遗的。此外，还要运行如 GCC 本身附带的 DejaGNU 测试套件。”

然后，即使经过了广泛测试，验证也并不能保证工具链毫无缺陷，而只能识别、记录和证明缺陷。

“功能安全并不意味着你的工具链完美无缺，它只意味着已知的缺陷被清晰地记录在案，而且你有一个识别和记录缺陷的流程。要进行全面验证，您需要修复或记录并证明每一个与预期行为的偏差，从而避免出现已知的、不合理的偏差。”

编译器功能安全验证的关键要素

要使编译器被视为功能安全，企业必须完成三个关键步骤：

1.    广泛测试：

2.    文档：

3.    缓解策略：

如果没有这三个方面的支撑，编译器工具链就无法被正式视为“功能安全”工具，即使已完成初步验证，仍需持续维护、文档记录和每次更新之后的重新认证。

认证不仅仅是测试

许多人误以为只需运行测试套件即可完成编译器工具链验证，但实际上，测试只是整个验证工作的一部分，文档工作同等重要，它确保可追溯性并符合行业标准。包括：

这一文档繁重的过程需要合规专家参与，这给本已复杂的项目增加了相当大的开销。

功能安全认证的真实成本

验证一个编译器是否满足 ISO 26262、IEC 61508、ISO 62304 等标准的成本，取决于所需的安全完整性等级（SIL）。大致成本包括：

这些成本还不包括产品上市延迟带来的隐性成本和商业影响，这可能会进一步增加开发安全关键型应用的公司的财务风险。

因此，对于许多公司来说，问题的关键不再是“能不能验证自己的工具链”，而是“验证自己的工具链值不值得做”。

为什么许多企业选择经过认证的工具链？

考虑到高昂的时间与成本代价，大多数企业倾向选择经过第三方认证的工具链，而非自行进行验证。

例如，IAR 的开发工具已经过 TÜV SÜD 的功能安全认证，符合 ISO 26262、IEC 61508、ISO 62304 等国际标准，可直接投入使用，无需额外验证工作。使用 IAR 经过认证的工具链，企业可以：

借助经过认证的功能安全工具链，企业可以更加专注于创新。

IAR 平台始终包含功能安全

与其他需要额外认证工作的工具链不同，IAR 嵌入式开发平台将功能安全作为内置功能，帮助开发团队：

对于开发安全关键型应用的公司，IAR 提供了经济高效、开箱即用的解决方案，省去了与工具链验证相关的复杂性、时间和成本。

下一步？立即行动！

实现功能安全合规性不一定是高成本和高风险的代名词。借助 IAR 的功能安全工具链，企业可以显著降低工具链验证成本、缩短上市时间，并专注于打造更高质量的安全关键型产品。

如需了解更多，请访问 IAR功能安全解决方案 。

安全是未来汽车发展的关键问题之一。新的功能不仅涉及驾驶辅助领域，还涉及车辆动力学控制以及主动和被动安全系统领域，这些新功能越来越多地触及安全工程领域。未来这些功能的开发和集成将进一步强化拥有安全系统开发流程的必要性，并提供证据来证明所有合理的安全目标都已满足。

随着复杂性、软件内容和机电一体化实施的趋势日益增强，系统性故障和随机硬件故障的风险也在上升。ISO 26262标准提供了指导，通过提供可行的要求和流程，将这些风险降低到可接受的水平。

本文的目的是详细介绍Parasoft C/C++test如何帮助汽车软件开发团队满足特定汽车安全完整性等级（ASIL）的要求。本文首先介绍了ISO 26262标准定义的ASIL概念。然后，描述了Parasoft C/C++test，这是一个统一、完全集成的解决方案，用于自动化软件开发和测试的最佳实践。最后，本文介绍了团队如何使用Parasoft C/C++test完全或部分满足特定ASIL的软件开发流程要求。

摘要

在学习ISO 26262标准的过程中，我们会经常提到“功能安全生命周期“这个概念，对于生命周期这个词，标准的定义是“相关项从概念到报废的全部阶段“。

为了了解生命周期这个概念，我们分别从项目（产品）层面和公司层面这两个角度进行说明。

一. 产品层面的功能安全生命周期

我们以图1中系统层面产品作为示例来进行说明。

（图1）

这张图中，我们可以看到对于产品的开发阶段，我们划分了四个阶段（第一行），分别是产品立项阶段，概念阶段，开发阶段以及工程和生产阶段。对于活动的执行部门（第一列）我们也进行了划分，部门的划分大体可以分为需求，设计，生产这三个大类，因为每个公司对于部门职责的划分都是各不相同，所以这里我们重点关注产品的四个开发阶段。

1-立项阶段：这个阶段我们的主要活动就是根据客户初期的需求或者市场调研结果判断是否立项，项目的相关管理人员也会在这个阶段明确；

2-概念阶段：立项成功后，概念阶段我们就要开始制定项目计划和安全计划，对项目所有的活动进行统一规划，对于功能安全而言，这个阶段我们有两个重要的活动进行执行，分别是影响分析（对于部分复用项目安全活动的识别）和SEooC（判断项目是否是定制开发），这两个活动都会影响到安全计划中对于安全活动的范围判定以及安全需求的制定。

就拿影响分析而言，影响分析是分析新项目在旧项目的基础上需要做哪些方面的修改，如果进行修改，会对旧项目的哪些WP（工作成果）造成什么样的影响，这些修改工作什么时候开始进行，由谁来执行等信息都会在安全计划中更新。比如旧项目是ASILB等级，而新项目是ASILD等级，因为客户对产品的随机硬件失效率提出了更高的要求，并且新旧产品在功能层面的需求相同，所以考虑在原有架构基础上新增一些安全机制尝试实现新的要求，通过影响分析活动判断下来部分IP的详细设计specification是可以直接复用;而诸如需求Spec，架构设计,FMEDA等活动需要在原有文档基础上进行修改;像FTA，高ASIL等级对应的测试验证活动等，由于旧项目ASIL较低，所以当时是没有执行，现在ASILD项目中，我们就要新增这些活动，并输出相对应的文档。

而对于SEooC而言，它就直接决定了我们的安全要求的制定，要么是客户定制提出产品需求，要么是SEooC假设获得需求，这些都会体现在安全计划的内容中。

3-开发阶段：对于图1中的示例，产品涉及硬件和软件的开发，对于硬件和软件而言，各自开发过程基本相同，从获得HSR/SSR（硬件安全需求/软件安全需求）→架构设计→详细设计→集成设计，以及每个环节的验证活动，包括我们重点关注的FMEA,FTA,DFA,FMEDA这些安全分析活动也都是在这个阶段来执行的。此阶段的活动就是为了在技术层面将产品需求实现。

4-工程和生产阶段：当上阶段的开发工作结束后，我们就要将设计转化为实体的商品，此时我们便要联系生产和封装厂进行生产活动，这里就要包括对生产工艺的要求，生产的计划安排以及生产过程的其他管理活动。生产结束后客户在使用过程中遇到的一些调试，安装等问题要求，产品出现质量问题的售后服务以及产品在达到使用寿命后所要采取的必要保费措施，都会记录在这个阶段。以上内容就是一个系统层面产品生命周期中会出现的活动。

二. 组织层面的安全生命周期

公司层面的安全生命周期相较于产品层面就没有那么复杂，对于公司而言生命周期其实就是公司可能会涉及的标准范围，也就是标准part2-5.4.6（独立于项目的安全生命周期裁剪）的要求。下图2是ISO 26262经常会看到的一副标准章节图。

这里面将标准所有的章节及对应的安全活动进行了展现， 可以简单地理解上图就是功能安全在公司层面最完整的生命周期，不同的公司的安全生命周期只会比此范围小，不会超越此图的范围，不同公司将此图中不涉及的章节或者安全活动裁剪以后的结果就是该公司组织层面的生命周期，已下表中的内容为例给大家进行说明。

表格前两列列举了标准从part2-part9的主要内容（这里暂时只考虑与实际项目实施强相关的几个部分），后4列我们是划分了四种类型的公司，标记了它们对应ISO 26262标准生命周期常见的几种情况。

1-对于OEM厂商而言，它们属于汽车E/E开发需求的发起者，而且是产业链的最终集成者，所以OEM是会涉及标准的所有章节，因此他们的生命周期就是完整的ISO 26262范围。

2-对于系统集成商而言，他们的产品一般会先集成到Tire1&Tire2的产品中，然会才会应用到整车上进行使用，他们一般不会直接承担整车的某项功能，所以标准part3的活动对于他们而言是不涉及的，因此在他们的生命周期中是要裁剪掉的，而对于系统的设计工作（part4），软件硬件的设计工作(part5&6)，支持部分（part8中的安全需求管理，DIA,配置管理，变更管理等），安全分析（part9）这些都有可能会涉及，因此在他们生命周期中这些都是要保留下来的。另外对于部分系统开发公司，可能会存在没有产品的实际生产能力，所以part7对于系统层面有被裁剪掉的可能性。

3-对于一个纯硬件公司，首先part2,part8的管理和支持内容肯定是要保留，并且因为它们是专业的硬件设计公司，所以part5的设计内容以及part9的安全分析内容也是要保留，因为是纯硬件公司，所以软件部分的part6则需要裁剪掉，part3因为是相关项层面的活动，所以也不会涉及。而硬件公司，可能会去开发通用组件而假设客户的需求，所谓的客户其实就是系统层面的集成商，因此就可能会通过SEooC假设到系统层面的需求，也就相当于part4-6的内容，因此硬件公司关于part4是可能会设计到的。Part7就和系统层面的理由一致，可能会涉及到，也可能会被裁剪掉。

4-对于芯片生产，封装厂，因为不涉及功能安全的设计环节，所以part3—part6都不涉及，会被裁剪掉，与其相关的就是part2的管理部分，part7的生产部份，part8的支持部分。

以上内容就是生命周期在产品层面和组织层面的内容。

（转自Munik秒尼科技术微信公众号）

汽车行业正迅速转变为一个复杂的智能移动生态系统，引入了新的软件复杂性和潜在的漏洞。在道路车辆中越来越多地使用软件和数据共享功能是汽车行业增长的显著驱动因素。然而，报告显示，如果未能实施适当的缓解措施，新的攻击向量能够造成大规模的破坏，可能会使整个行业陷入困境。对车辆的网络攻击可能会危及驾驶员、乘客和其他道路使用者的安全、隐私和性能。

解决这一需求的关键举措之一是制定ISO/SAE 21434标准，即道路车辆网络安全工程国际标准。ISO/SAE 21434的主要目的是确保车辆制造商从道路车辆的设计之初到报废的整个生命周期中都纳入网络安全措施。

ISO/SAE 21434的合规性要求涉及实施一个网络安全管理系统，覆盖产品开发生命周期的所有阶段。这些要求还包括道路车辆软件系统需要经过严格的测试、风险评估、监控和审查等。

本白皮书将讨论实施ISO/SAE 21434的常见挑战和解决方案，以及自动化测试解决方案如何支持和简化合规流程。

根据图一软件开发阶段V模型，软件单元设计和实现之后，需要对相应的软件设计进行测试验证即V模式右边内容。具体包括：软件单元验证、软件集成和验证、嵌入式软件验证。本文着重阐述功能安全软件开发阶段中这三个阶段的测试验证活动。

图一：软件开发阶段V模型

1、软件测试验证方法

1.1 软件测试验证对象

软件单元验证、软件集成和验证、嵌入式软件验证分别对应的不同的测试对象，具体如下图所示：

图二：软件测试验证对象

1.2 软件测试验证方法

ISO 26262-6:2018 从第9章节到第11章节分别对软件单元验证、软件集成和验证、嵌入式软件验证这三部分进行了详述，其中对根据ASIL等级推荐了不同的验证方法，如下图所示：

图三、软件单元验证方法

图四、软件集成验证方法

图五、嵌入式软件的测试方法

从图三、图四、图五可以看到软件单元设计的验证以走查、检查、审查、分析、测试等为主要验证方法；软件集成验证以静态分析、资源评估（主要包括消耗的CPU资源、RAM、ROM等）、测试等为主要验证方法；嵌入式软件的测试方法主要用测试来进行验证。虽然属于软件开发中的不同子阶段，但是很多测试方法是共同的，比如故障注入测试、接口测试、基于需求的测试。这里可以从测试类型的角度，将测试归纳为静态分析测试和动态分析测试。

1.2.1 静态分析：

静态分析是指不用执行程序的测试，对程序文件进行跟踪，即可以在运行程序之前的早期阶段检测分析。它主要采用代码走查、技术评审、代码审查等方式对软件单元或者软件产品进行测试。验证方法有走查、结对编程、检查、控制流分析、数据流分析、静态代码分析，主要集中在软件单元验证和软件集成验证活动中。其中静态代码分析最为主要，其主要目的是检查代码编写是否符合特定的编程规则。对于大部分车辆控制器代码而言，静态代码分析，即C代码静态分析(如果基于模型开发，则是自动生成的代码)，主要是保证代码满足MISRA C(Motor Industry Software Reliability Association, 汽车工业软件可靠性协会)相关的要求。

静态代码分析一般可以直接采用自动化检测软件，例如SIMULINK, Model Advisor; Vector, VectorCAST; Perforce, Helix QAC等，通过配置代码检测规则，然后导入源文件进行自动化分析，如果不满足相关要求，则需要对代码进行修改直至满足为止。最终输出静态代码分析报告给予功能安全软件设计验证提供依据。

1.2.2 动态分析：

动态分析是指测试程序的动态形式，对运行着的程序进行跟踪，通过观察程序运行的实际结果来发现错误和缺陷。它包括的验证方法有：基于需求的验证、接口测试、背靠背测试、故障注入测试等，主要集中在软件集成验证和嵌入式软件验证活动中。动态分析在测试环节具体现如下图：

图六、动态分析测试

在给出的验证方法中，测试占据很大部分，如何进行测试，更需要关注具体的测试用例，它规定测试的测试方法、测试环境、测试设备和工具、测试步骤、判断准则、预期结果等等。

2 软件测试用例导出方法

动态分析测试基本上都需要用到测试用例，如何导出测试用例，用尽可能少的测试用例，覆盖尽可能多的测试场景，这个是对功能安全测试工程师一个很高的要求。ISO 26262-6:2018中分别给出了软件单元、集成测试、嵌入式软件测试用例导出方法，这里归类如下图所示：

图七、测试用例导出方法

其中：

等价类的生成和分析，可以基于划分输入输出来识别等价类，为每个等价类选择一个有代表性的测试值；边界值分析主要用于接口测试，接近边界的值、与边界交叉的值及超出范围的值；错误推测法可基于经验学习中收集的数据和专家判断的数据做为依据进行测试；软件操作用例分析可以包括现场软件更新或者嵌入式软件在不同操作模式下的安全相关行为分析,例如,启动、诊断、降级、断电(进入睡眠状态)、通电(唤醒)、校准、不同ECU 之间的模式下的安全行为分析。

如下图给出了测试用例的设计示例可供参考：通过变化f_in_cell_voltage的输入数值，观察b_out_charging_enable输出数值的结果：

图八、测试用例示例

3 软件安全测试的完整性

为了评估验证的完整性并提供证据证明已有测试用例已充分实现相应测试目标，必须对测试完整性进行评估，这里就得提到结构覆盖率这个概念。结构覆盖率用于度量我们设计的测试用例在多大程度上可以覆盖我们的代码，测试人员可以创建代码覆盖缺失的测试用例，以增加覆盖率。在ISO 26262-6:2018中对软件单元，集成软件的测试覆盖率提出了相应要求，具体包括:

图九、结构覆盖率在软件验证过程中的要求

可以看出，软件单元层面结构覆盖率多基于语句、分支等最基本的代码组合部分测试，而集成后的软件架构层面的结构覆盖率多基于函数，其层级更高。二者逐步递进，可以有效的评估软件安全测试的完整性和充分性。

其中：

函数覆盖率和调用覆盖率很好理解，分别用来统计代码中所有函数是否被测试用例执行的比例和执行测试用例时每个函数是否被调用的比例。下面重点介绍一下：语句覆盖率、分支覆盖率以及MC/DC(修改/判定条件覆盖率)，因为这三个覆盖率最容易被混淆。

3.1 语句覆盖率

语句覆盖率用于统计每个代码语句被测试用例执行的比例，主要从未执行的语句，死代码、未执行的分支三个范围综合考虑的。

示例：

源代码：为一个简单的计算两个数值之和的函数

方案1：

如果A=3,B=9

代码执行如下图所示：黄色标记的是根据输入值后执行的语句，已执行语句=5，语句总是=7，所以语句的覆盖率：5/7=71%。

方案1：

如果A=-3,B=-9

代码执行如下图所示：黄色标记的是根据输入值后执行的语句，已执行语句=6，语句总是=7，所以语句的覆盖率：6/7=85%。

但是总体的来说，所有的未覆盖的语句都被第二种方案所覆盖，如果覆盖到所有测试边界就可以认为覆盖率为100%。

3.2 分支覆盖率

分支覆盖率用于统计每个判定分支被测试用例执行的比例，确保来自每个分支的每个条件至少执行一次。具体指在if，case，for，forever，while等语句中各个分支的执行情况。

这里还是依语句覆盖率示例代码为例，计算两个数值之和的函数对应的控制流程图如下

从流程图可以看出图中给出两个执行路径1-2-3-4和1-2-5-6。所以我们在设计测试用例时需要考虑把两条路径都要覆盖到。

测试用例：

这里的分支覆盖率一定不可以约分。1/2怎么来的呢？1代表当前覆盖了一条语句，2代表这个程序一共有两个分支。

3.3 MC/DC(修改/判定条件覆盖率)

MC/DC(修改/判定条件覆盖率) 用于判断类代码覆盖检测，相对比较难理解。它是对分支测试的进一步补充，要求在一个程序中每一种所有可能的输入和输出至少出现一次，并且要求判定中的每一个条件必须能够独立影响判定输出，简单可以理解在其他条件不变的前提下，仅改变条件中一个值，而使判定结果改变。

示例：

用例：

对于条件A，用例1和用例2，A取值相反，B和C相同，判定结果分别为1和0；

对于条件B，用例1和用例3，B取值相反，A和C相同，判定结果分别为1和0

对于条件C，用例3和用例4，C取值相反，A和B相同，判定结果分别为0和1。

理论上，对于三个输入判定条件(A, B, C)，一共存在8种测试Case，为实现MC/DC全覆盖，然而仅仅用了4个案例就实现了MC/DC全覆盖，使用最少的测试用例达到最高的覆盖率，不仅节省了成本还节省了时间。

总之，结构覆盖率不需要一味追求100%，高结构覆盖率并不完全说明代码已经进行高质量充分测试，它只说明哪些代码没有被测试用例有效执行。结构覆盖率测试可以帮我们反推前期测试用例设计是否充分，是否存在盲点，哪些地方需要进行补充，增加测试完整性。结构覆盖率测试并不能解决软件事先没有考虑到的情形及功能不足。

4 软件测试的环境

在进行测试验证时我们还需要考虑测试环境和目标环境之间的差异，以便在后续测试阶段的目标环境中定义额外的测试。不同阶段的测试对应着不同的测试环境，如下图所示：

图十、软件测试环境要求

其中：模型在环测试主要验证基于模型开发的软件单元和产品；电子控制单元网络测试环境主要用于测试功能安全对于网络安全的影响；硬件在环测试主要应用于接口测试验证软件设计是否符合软硬件接口规范。

关于功能安全软件开发阶段-软件测试验证的分享就到这里了，无论是最初的设计还是后期的验证环节，我们需要时刻规范开发过程中的每一个子阶段，才能避免因软件设计而造成的系统性失效。

（转自Munik秒尼科技术微信公众号）