摘要

在学习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秒尼科技术微信公众号）

根据图一软件开发阶段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秒尼科技术微信公众号）

时间：2024年12月10日下午13:30-17:30
地点：线上（受邀客户注册后发送观看平台）

为应对近年来产业对于嵌入式功能安全（FuSa）方案的广泛需求，普华基础软件、IAR、秒尼科、芯来科技、恩智浦、Parasoft及瑞萨电子共同宣布正式成立FSG（功能安全专家小组）。作为专门研究嵌入式功能安全（FuSa）的共享与协作平台，FSG致力于提供一站式功能安全认证相关的服务，帮助嵌入式功能安全（FuSa）产业提升认证价值，满足IEC 61508、ISO 26262等功能安全认证需求，帮助企业更高效地达成功能安全认证要求。

我们诚邀您于2024年12月10日下午参加FSG中国成立仪式暨功能安全技术分享会！

议程：
13:00-13:30 签到
13:30-13:50 开场演讲——FSG的成立背景与发展蓝图 (Kiyo Uemura, IAR APAC VP & 何积生， IAR高级客户经理)
13:50-14:10 RISC-V信息安全和功能安全方案赋能汽车电子芯片 (范添彬，芯来科技汽车电子产品经理）
14:10-14:30 A Glance of Functional Safety in NXP （Ives Cheng，NXP汽车事业FAE）
14:30-14:50 瑞萨电子基于IEC61508 的功能安全解决方案 （杜灏 ，瑞萨电子嵌入式处理器事业部市场经理）
14:50-15:10 开源安全车控操作系统“小满” （张仕玉，普华基础软件天山事业部总经理）
15:10-15:45 茶歇及交流
15:45-16:05 使用经过认证的工具链加速功能安全产品开发和认证 （段长江，IAR FAE Manager）
16:05-16:25 符合功能安全认证要求的白盒测试解决方案 （王春艳，Parasoft 资深应用工程师）
16:25-16:45 嵌入式功能安全的设计考虑和分享 （范文涛，秒尼科汽车及网络安全产品线总监）
16:45-17:20 圆桌讨论及现场问答
17:20-17:30 活动结束

期待您的参与，与行业专家共话功能安全发展趋势，探讨前沿技术应用，共创未来！

    姓名

    邮箱

    手机

    公司

    职位

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

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

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

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

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

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

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

    随着工业自动化与控制系统（IACS）日益互联并暴露在互联网环境中，它们面临的网络攻击威胁不断增加。恶意行为者出于网络犯罪乃至国家层面的破坏等动机，将工业系统作为攻击目标。

    为了应对不断升级的网络安全风险，国际自动化协会（ISA）和国际电工委员会（IEC）在2018年制定了IEC 62443系列标准，以保障IACS的安全。IEC 62443为所有IACS领域（包括人员、流程和技术）实施网络防御提供了一个全面的框架。

    然而，对于运营商而言，确保完全符合IEC 62443标准是一项艰巨的任务。IACS通常涉及多个站点的异构系统，且集成要求复杂。如果没有自动化工具，维护全面的资产清单并测试所有可能的攻击面是困难的。

    本文深入研究自动化软件测试技术和最佳实践，来简化ISA/IEC 62443合规性。主动降低风险，确保合规性，并加强工业自动化与控制系统的韧性，以抵御不断演变的网络威胁。

    为了帮助您更全面地了解IAR Embedded Workbench产品系列和实用技巧，欢迎您免费参与我们精心准备的系列线上培训课程。

    本次会议主要内容包括：

    点击填写表单，立即回看！

    在前面的文章中，我们介绍了在开发调试过程中如何在IAR Embedded Workbench中进行堆栈静态分析和动态监控，然后设置合理的堆栈大小，避免堆栈溢出。但是即使设置了合理的堆栈大小，在程序运行时最好有对应的失效安全(fail-safe)策略：如果在运行过程中出现堆栈溢出，程序应该要能检测到并执行相应的策略。

    本文主要介绍如何在程序运行时进行堆栈溢出检测及检测到堆栈溢出之后的失效安全策略。

    程序运行时堆栈溢出检测主要通过检查对应的堆栈指针（SP）是否超出指定的堆栈范围来实现，一般可以分为硬件检测和软件检测。

    硬件堆栈溢出检测

    硬件堆栈溢出检测的原理：设置对应的硬件单元，如果在程序运行过程中，SP超出指定的堆栈范围，会触发对应的硬件错误。目前主要有如下两种方式：

    使用堆栈限制寄存器（Stack Limit registers）

    ARMv8-M架构中包含了堆栈限制寄存器（Stack Limit registers），当SP的值小于（ARMv8-M架构中堆栈是向下生长的）对应Stack Limit registers的值时，会触发UsageFault或者HardFault：

    堆栈限制寄存器1

    使用内存保护单元（MPU：Memory Protection Unit）

    为了提高系统的安全性，越来越多的MCU集成了内存保护单元（MPU：Memory Protection Unit），可以通过设置MPU的属性，当SP访问超出指定的堆栈范围时，产生MemManageFault或者HardFault：

    堆栈限制寄存器2

    软件堆栈溢出检测

    软件堆栈溢出检测的原理：在程序开始之前，往堆栈防护区域填充特定的值（比如0xCD）,然后在程序运行时去检查堆栈防护区域中之前填充的值是否被篡改：如果被篡改了，说明堆栈溢出。

    软件堆栈溢出检测

    RTOS任务堆栈溢出检测

    通常情况下，RTOS会提供任务堆栈溢出检测功能，只需要使能对应的宏定义，打开堆栈溢出检测功能。当检测到堆栈溢出时，RTOS会调用相应的堆栈溢出钩子函数（hook）。

    注意：RTOS一般会计算各个任务堆栈的使用情况，所以在新建任务时，RTOS会把任务堆栈所有区域都填充特定的值，然后在运行过程中去检测和计算对应的堆栈使用情况。

    RTOS任务堆栈溢出检测

    在RTOS里面进行任务堆栈溢出检测一般需要如下操作（下面以Azure RTOS为例）：

    /* Determine whether or not stack checking is enabled.

By default, ThreadX stack checking is disabled.

When the following is defined, ThreadX thread stack checking is enabled.

If stack checking is enabled (TX_ENABLE_STACK_CHECKING is defined),

the TX_DISABLE_STACK_FILLING define is negated,

thereby forcing the stack fill which is necessary for the

stack checking logic. */


#define TX_ENABLE_STACK_CHECKING
    void my_stack_error_handler(TX_THREAD *thread_ptr);


/* Register the "my_stack_error_handler" function with ThreadX

so that thread stack errors can be handled by the application. */

status = tx_thread_stack_error_notify(my_stack_error_handler);


    系统堆栈溢出检测

    系统堆栈溢出检查需要开发人员手动添加对应的代码：在程序开始之前，往堆栈防护区域填充特定的值（比如0xCDCDCDCD），然后在程序运行时去检查堆栈防护区域中之前填充的值是否被篡改。

    #define STACK_FILL_PATTERN 0xCDCDCDCD

/* Linker generated symbols */
extern uint32_t CSTACK$$Base;

/* Fill the stack base with dedicated pattern */
*((uint32_t *) &CSTACK$$Base) = STACK_FILL_PATTERN;


/* Check system stack overflow */
/* If the filled pattern is changed, there is stack overflow */
if(STACK_FILL_PATTERN != *((uint32_t *) &CSTACK$$Base))
{

}

    注意：软件堆栈溢出检查由于是通过软件代码进行检测，可能没有那么及时，也有可能在堆栈溢出的地方已经造成了其它的硬件错误（比如从堆栈POP出的PC指向了不可执行的地址）。

    堆栈溢出之后的措施

    前面介绍了程序运行时进行堆栈溢出检测的方法。那么当检测到堆栈溢出之后程序应该怎么处理呢？

    由于堆栈溢出可能会造成程序运行需要的重要数据的破坏，而这种破坏是未知的。所以当发生堆栈溢出时，程序通常是很难继续正常运行的，往往需要通过系统复位来重新回到正常的状态。但是需要注意的是，在系统复位之前，需要确保系统进入安全状态，避免造成更严重的损害。下面是发生堆栈溢出之后一般的处理策略：

    总结

    本文主要介绍了如何在程序运行时进行堆栈溢出检测及检测到堆栈溢出之后的失效安全策略。开发人员可以根据对应系统的具体情况选择合适的方法进行程序运行时堆栈溢出。当检测到堆栈溢出之后，程序需要执行相应的失效安全策略确保系统能够安全地回到正常的运行状态。

    参考文献：

    1. Mastering stack and heap for system reliability：https://www.iar.com/knowledge/learn/programming/mastering-stack-and-heap-for-system-reliability/ 
    2. How much stack memory do I need for my Arm Cortex-M applications?: https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/how-much-stack-memory-do-i-need-for-my-arm-cortex–m-applications
    3. Detecting Stack Overflows (Part 2 of 2): https://weston-embedded.com/support/media-articles/99-detecting-stack-overflows-part-2-of-2
    4. Joseph Yiu, Tim Menasveta. Utilizing Features in an ARM® Cortex®-M Processor to Create Robust Systems
    5. Express logic. Detecting and Avoiding Stack Overflow in IoT Embedded Systems
    6. Understand Azure RTOS ThreadX
    7. How to Prevent and Detect Stack Overflow | Barr Group: https://barrgroup.com/embedded-systems/how-to/prevent-detect-stack-overflow

    我们提供IAR Embedded Workbench for Arm、RISC-V、STM8、Renesas RX、RL78和RH850 经过认证的构建工具链，用于符合IEC 61508、ISO 26262、EN 50128和IEC 62304标准的安全关键型应用。在本文中，我们将介绍认证的含义，以及您如何在自己的项目中利用这种认证。无论您的产品有没有计划进行正式认证，包含的功能安全服务都具有很大的价值。

    嵌入式功能安全标准

    安全认证的正式标准已经发布多年，但在过去的几年中，特别是在嵌入式领域，人们对这些标准的兴趣和实际使用程度正在显著增加。人们对认证和经过认证的终端产品的兴趣日益浓厚，部分原因是法律要求，但对生产企业来说，获得安全认证意味着获得市场竞争力。

    与许多功能安全相关的国际综合标准IEC 61508，经过了多次修订，于2010年发布了第二版。这个标准以及它所衍生的标准，现在广泛应用于对可靠性和安全性有要求的行业，如过程工业、铁路和自动化等，比如ISO 26262用于汽车领域、EN 50128用于铁路应用、IEC 62304用于医疗软件和医疗设备。

    验证和认证

    如果您即将启动一个具备安全关键功能或功能安全要求的项目，您可能已经意识到您所使用的开发工具必须以某种方式经过资格认证，以适用于与安全相关的开发。如何验证开发工具的具体要求取决于您所遵循的标准以及在某种程度上产品故障可能引发的严重程度。这还与工具的性质有关，例如，生成进入产品的代码的编译器比源代码度量工具更难认证，而源代码度量工具比版本控制系统或需求管理系统更难认证。

    不同的标准对安全完整性（即产品的关键程度） 有不同的定义，并且这些标准在工具的分类上也有所不同。以IEC 61508为例，它规定了编译器等工具需要经过认证，尽管并没有明确定义“认证”的具体含义。此外，该标准还要求这些工具必须经过验证，以确保它们符合相关的规范或文档。最糟糕的情况是，这意味着您必须在自己的项目中全面测试这些工具，除非能够提供充分的测试证据。此外，您还需要评估该工具在项目中的依赖程度。

    还需要考虑和评估的另一件事情是工具供应商支持工具的能力，最好能够在安全关键产品的整个生命周期内提供支持。

    将所有这些放在一起可能会给您带来相当大的工作量，而这只是关于一个工具和一个项目的事情……这正是我们的工具链获得认证的背景。

    获得认证和验证！

    我们用于安全关键开发的工具获得认证到底意味着什么呢？它意味着您为证明工具的使用合理性而必须做的工作量大大减少。因为独立的第三方机构TÜV SÜD 已经对我们的开发活动、问题处理程序以及测试和验证活动进行了评估，并认证了我们的工具符合IEC 61508、ISO 26262、EN 50128和 IEC 62304等安全标准的要求。这也意味着，如果您选择C或C++作为编程语言，我们的工具链是一个绝佳的选择。

    延续我们的服务

    那么，如果选择了经过认证的工具，就完事大吉了吗？

    嗯…… 还需要考虑的一个重要的事情是工具链需要的支持级别以及您可以获得的支持级别。这不仅仅限于项目开发的时间，还包括产品的整个生命周期。如果工具旧了并且被新版本取代，工具供应商不一定会在旧版本工具上继续支持您。这种立场与典型的安全相关项目的需求背道而驰，因为在这些安全相关项目中，应尽量避免工具的更新。

    如果之前认证过的工具的更新不仅仅包含错误修复（Bug Fix)，还包含功能更新，那么这个更新是没有实际用途的，因为需要对工具更新进行重新认证或者进行详细的影响分析以及测试。

    通过与开发安全相关的并且具有高可用性要求的软件或服务的客户多年合作，我们了解到，对“冻结”版本的支持至关重要。“冻结”版本指的是只接受错误修复而永远不添加新功能的工具版本。这种版本可以根据需要保持活跃并得到支持。过去，我们为需要特定“冻结”版本和相关支持服务的客户量身定制了特殊协议。现在，通过认证之后，我们有机会以简化的方式为所有使用IAR Embedded Workbench的功能安全版本的客户提供“冻结”版本和相关支持服务。

    持续支持和保护

    我们的安全解决方案包含了以下主要内容：

    IAR Embedded Workbench功能安全版本

    总之，选择经过认证的工具链可以使您轻松地在安全相关项目中使用它。选择包含适当支持服务的工具可以保护您的工具选择和投资。此外，即使您的产品没有直接的安全要求，但如果需要满足各种高完整性或高可用性要求，功能安全支持服务也可能同样非常有用。

    嵌入式软件越来越复杂，代码库规模不断增长，开发者正不断寻求方法来现代化工作流程。回看本次网络研讨会，了解IAR与Parasoft如何帮助提高效率、提升现代化工作流的性能、最大限度地降低测试成本！ 议程包括：

    1.使用IAR解决方案提高现代开发工作流的性能和生产力 
    将重点介绍IAR的解决方案，包括IAR Build Tools，IAR C-STAT/C-RUN，IAR Debug Probes，如何应用在自动化构建和测试中，在显著提升代码质量和可靠性的基础上，提升现代化工作流的性能，释放生产力。 

    2.Parasoft在嵌入式CI/CD流程中的最新实践
    Parasoft的高级代码分析和测试自动化工具在IAR开发环境下构建高度自动化、基于CI的开发工作流程，以及满足ISO26262等安全标准以及代码覆盖率方面的实践，帮助团队提高开发人员的工作效率、最大限度地降低测试成本。

    3.Demo演示 

    4.Q&A环节

    点击填写表单，立即回看！