GB／Z 41912-2022  低压开关设备和控制设备 嵌入式软件开发指南

如要实施与主功能相关的修改，则宜明确相关活动。并在进行任何修改前编制、记录和批准该行动 计划。

注1：修改请求可能来自： 主功能需求规范已变更； 实际使用条件；

事件/事故经验； 一加工材料的变更； 一设备或其操作模式的修改。 注2：根据设备使用信息或说明手册对设备进行的干预（如调整、设置、修理)不视为本条款中的修改。 宜记录请求修改的原因。 宜对修改后的效果进行分析，以确定其对主功能的影响。 宜记录修改对设备主功能的影响及修改的效果。 对设备有影响的所有已接受的修改宜使其硬件和（或)其软件返回到适当的设计阶段（例如，规范 计、集成、安装、调试、验证和系统验证）。后续所有阶段和管理程序宜按照本文件中针对特定阶段规 的程序执行。所有相关文件均宜相应校对， 订和重新发布

对于任何软件开发，都要求在整个开发周期内实行可靠的缺陷管理流程。 缺陷可能是： 编码错误引起的结果； 与原始需求的偏差； 外部事件引发的非预期行为

缺陷管理工作流程因开发项目组的实践而异。图1给出了缺陷生命周期流程示例，包括如下阶段： 新增：这是识别缺陷流程的第一步。通常由测试团队提交缺陷电器标准，有时客户也会报告缺陷。 分析：一旦发现缺陷，开发团队尝试各种方法重现并寻找缺陷的根本原因。通常在此步骤中确 定或修改缺陷的严重性。 拒绝：根据缺陷类型或缺陷的严重程度，可拒绝解决缺陷。 实施：开发人员修复了缺陷，并将其放置在原先缺陷发生处。 验证：缺陷修复后，验证团队将验证缺陷是否已实际修复且系统是否按预期工作。 关闭：一旦缺陷被修复、记录和解决后，其状态将被标记为关闭。 注：可以将缺陷管理工作流程的每个状态分配给特定的项目团队成员，并指定交付期限

5.6系统构建与发布流程

5.6.1二进制代码生成

发布软件时，宜使用唯一的版本号/修订号进行标识。最常用的编号习惯包括主版本号、次版本号 和修订号： 当软件兼容性变更或增加多个新功能时，主要版本号需要递增。通常，当主版本号为0时，该 软件仍处于开发阶段或Beta版本。 当增加少量的附加功能时，次版本号需要递增。 一当缺陷被修复时，修订号需要递增。 每个软件版本都应通过注释的方式进行记录，这些注释详细说明了发布内容：新功能、已修复缺陷 列表以及已知的限制。

6嵌入式软件的手动参数化

有些设备需要通过手动参数化来实现主功能。可通过连接到设备的远程连接（如基于PC的配置 工具)或人机界面[如显示器、指拨开关（DIP开关）、电位计、旋钮、存储卡]，进行参数设定。 基于软件手动参数化要求的目的是确保正确选择与主功能相关的参数，并将其传输到执行主功能 的设备中。这些参数不宜以意外或未经授权的方式影响主功能。 可以采用不同的方法来设置这些参数。甚至基于DIP开关的参数化都可用来设置或更改与主功 能相关的参数。但是专用参数化的软件工具（通常称为配置或参数化工具）正变得越来越普遍。本条款 仅适用于获得授权的人员执行或控制基于软件的手动参数化。如在设备的首次调试时或设备生命周期 内的任一时刻需要设定参数，则本条款适用。

6.2主功能相关参数的影响因素

在基于软件的手动参数化过程中，主功能参数可能会受下列因素影响，如： 负责参数化人员的数据输人错误； 参数化工具中软件自身故障； 参数化工具随附的软件和（或）服务故障； 参数化工具硬件故障； 参数化工具向设备传输参数时出现故障； 设备正确存储参数时发生故障； 参数化过程中受到的系统性干扰，如电磁干扰或断电影响； 受外部影响或其他因素引起的干扰，如电磁干扰或（随机性）断电。 如果没有适当的措施，上述影响可能会在不通知参数化负责人的情况下发生，并导致如下情况： 参数化过程中无法完全或部分更新参数； 参数完全或部分不正确； 通过有线或无线网络传输参数时，将参数传输到错误的设备。 宜平取措施抵消避免或控制由上述影响引起的潜在危险故障

6.3基于软件的手动参数化要求

且带有标识（ 称、版本等）。设备或其相关子系统和参数化工具宜能够防止未经授权的更改，如采用密码等。 当参数化过程可能会导致不安全状态时，宜在设备处于安全状态的情况下离线进行参数化。此外

宜满足以下要求： a）基于软件的手动参数化设计宜被视为设备设计中与主功能相关的设计，并在主功能需求规范 中加以描述，如在系统需求规范中； b)· 设备或子系统宜提供数据检验系统，该系统具备诸如检查数据极值、格式和（或）逻辑输人值等 功能； c）宜维护用于参数化的所有数据的完整性。为此，宜采取以下措施： ：一一控制有效输人范围； 一控制传输之前的数据损坏； 一控制参数传输错误带来的影响； 一控制参数传输不完全带来的影响； 一控制参数化的硬件和软件的故障和失败所带来的影响。 在传输/重传过程中用于编码/解码的软件单元和用于向用户显示主功能相关参数的软件单元至少 使用功能多样性来避免系统性失效。在这种情况下，多样性包含使用完全不同的传输方法来降低发 常规失效的可能性。

5.4参数化工具的验证

至少宜采用下列方法对参数化工具的基本功能进行验证： 验证每一个主功能相关参数是否正确设置（检查有效值）； 验证每一个主功能相关参数的合理性，如检测无效参数组合等； 验证是否提供了防止未经授权修改主功能相关参数的措施。 注：当使用非专用设备(如个人计算机或类似设备)进行参数化时，这一点尤为重要

6.5基于软件手动参数化的文档管理

基于软件的手动参数化宜使用设备供应商提供的专用参数化工具进行，并宜根据使用信息中规 的要求进行记录。该记录信息可由各方创建。记录内容可以保存在不同介质（纸张、电子化、参数化 具中、设备上等）。宜激活并采用对未授权存取提供的保护措施。 宜记录初始参数化以及对参数化的后续修改。记录文档中宜包括： a）‘当文件不在内部存储时，需记录参数化设备的标识； b），初次参数化或更改参数的日期； c）数据设置的日期或版本号； d 执行参数化的授权人员的姓名； e 标识所用数据的来源（例如，预定义的参数集，保留最后一次更改后的前一次设置）； 明确标识主功能相关参数。

嵌人式软件的所有生命周期活动宜着重于避免在其设计生命周期中引人错误，以下要求的主要目 的是生成具有可读性、可理解性、可测试性、可维护性的正确软件。 如果软件同时执行非主功能和主功能，则所有软件都宜视为与主功能相关，除非在设计中可证明功 能之间有足够的独立性。因此，在可行的情况下，宜将基本设备功能等非主功能与主功能分开。

GB/Z41912—2022/IECTR63201:2019

宜选用一套合适的工具，包括配置管理、仿真和带有测试发生器（例如“分线盒”的试验设备。宣考 在整个生命周期中是否有合适的工具以便于设备维护、升级与参数设置。宜在配置管理文件中解释 并记录工具的适用性。 适用性的证明方法如下： 选用恰当的避免和控制故障措施，进行严格的测试来验证其有效性，并记录结果； 一分析并确认这些工具的失效在工具链中可能带来的影响。 注1：避免和控制故障措施的合理性取决于故障的严重程度。评估严重程度的基础是分析。只有在对支持工具和 设备的应用有一定了解的情况下，才能进行该分析。 注2：失效的影响可能因不同的支持工具而异。GB/T20438.4一2017将软件开发生命周期内使用的离线支持工具 分为三类，如在软件生命周期之外使用，需要分析离线支持工具的分类是否合适。 注3：关于支持工具的定义和示例，见GB/T20438.4一2017。 注4：本文件未规定避免或控制离线支持工具故障的任何措施。有关示例见GB/T20438.3一2017中的7.4.4。 注5：可采取适当措施确保制造过程中使用的软件工具（编程和配置工具）不会改变嵌人式软件的完整性。

7.3.1软件生命周期模型

7.3.2审查、测试和验证的独立性

宜根据软件系统需求来开发软件，并在整个设备生命周期内对软件进行管理。 软件需求规范详见7.4.3，

为支持软件开发过程，有必要提供以下信息： 主功能规范； b）设备的配置或架构（例如：硬件架构、接线图、与主功能相关的输人和输出）； c）响应时间的要求； d）操作员接口和控制，例如：开关、操纵杆、模式选择器、拨号盘、触控设备、键盘等； e）设备的相关操作模式； 对硬件诊断的要求，包括传感器、终端执行器等的特性； g）机械公差的影响，例如传感器和（或）其传感计数器部件的影响，

7.4.3软件需求规范

7.4.3.1设计需求

软件需求规范宜： 具有结构化、可审查性、可测试性、可理解性、可维护性、可操作性。 根据设备规格和架构为每个子系统设计规范。 足够详细，以便进行适当的软件验证和测试。

可追溯到设备的系统需求规范。这意味着该规范是可以理解的，以便其他人（例如非软件专 家）可以验证该规范是否符合风险评估中定义的软件相关系统需求。 不含模棱两可的术语和不相关的描述。 软件需求规范的输人宜可以直接与预期的输出相关联，反之亦然。文档中宜使用易于理解的半形 方法，例如因果表、逻辑描述、表或图、功能块或时序图。 软件需求规范中宜规定下列内容： a）主功能的逻辑，包括输入和输出以及对检测到故障的正确诊断。可能的方法包括但不限于因 果表、书面说明或功能块。 注1：硬件也可以检测到故障（如输人卡检测到的信号差异）。这种故障检测是软件需求规范的一部分。 b）测试用例规范，包括： 进行测试所需的特定输入值、环境参数、预期试验结果（包括合格/不合格标准）； 故障插人或注人。 注2：对于简单功能，可以通过主功能的规范连带给出测试用例。 c）输人设备（如传感元件和开关）和最终控制元件（如电磁阀、继电器或接触器）的诊断功能。 使设备达到或保持安全状态的功能。 e） 与故障检测、通知和处理相关的功能， 对设备控制流和数据流进行自我监控。故障检测时，宜采取适当的措施以达到或保持安全 状态。 h） 防止未经授权修改设备的功能。 i）与其他设备的接口。 主功能响应时间。 k）信号处理功能的算法模型。 1）编码规则。 注3：软件文档指南在GB/T20438（所有部分）和ISO/IEC/IEEE26512：2018中给出。 宜根据系统需求规范审查软件需求规范中的信息，并在必要时进行修订，以确保充分规定软件

7.4.3.2编程语言规范及相关开发方法

c）易于开发人员及其他需要了解设计的人员理解的说明，包括对应用程序功能的理解和对设备 技术限制的了解。 d）车 软件验证计划，包含对主功能完整性的评价方法、验证策略与工具、对结果的评估以及如何采 取纠正措施。 e）‘系统验证计划的相关部分，宜包括预期的使用测试用例。 f）维护步骤，如修正。

为实现软件需求规范中的要求，宜建立软件架构。软件架构定义了软件的主要组件和子系统，规定 它们如何相互连接，以及如何实现所需的属性。软件架构还需定义软件的总体行为，以及软件组件如何 交互及相互影响。主要软件组件的示例包括操作系统、数据库、输入/输出子系统、通信子系统、应用程 字、缩程和诊断工具等。 软件架构宜遵循模块化的方法，即在有限的软件单元大小内完整定义一个接口和用于子程序和函 数的人口/出口。每个软件单元应有一个清晰易懂的任务 ，并且应限于一个完整的主功能，

7.5.2软件架构规范

宜提供软件架构规范作为软件架构设计的输出，并用以解释主要的软件内容。例如下面列表中 示： 软件架构，定义了为满足软件需求规范而规定的架构； 全局数据； 所用的数据库； 所用的已有软件单元； 诊断功能（内部、外部）； 拥有唯一性标识信息的编程工具； 软件集成测试用例和过程，包括测试环境规范、支持软件、配置描述和对测试失败后采取纠正 措施的过程。 软件架构规范中包含的信息宜根据软件需求规范进行审查

如果以前开发的软件单元要作为设计的 宜分析其在满足主功能软件需求规 而的适用性。还需评估来自先前软件开发环境的限制（例如操作系统和编译器依赖性）

对于软件单元，软件架构规范中宜规定下列信息： 软件单元描述； 软件单元接口（输入和输出及其数据类型），以及（如需要)数据范围 所用软件单元库的标识； 特殊编码规则。

7.6.3软件单元规范

软件单元规范宜包含下列信息： 每个软件单元的逻辑（如功能）描述； 每个软件单元输入输出接口的完整定义； 输人输出数据的格式和取值范围及其与软件单元的关系； 包括正常和非正常操作的测试用例； 注：尽管测试用例通常包括在其指定范围内对参数进行单独测试，但是这些参数的不同组合可能会导致非预期的 操作。 中断的记录文件。 宜对照输入信息（见7.6.2）审查上述信息

宜按照软件单元规范和编码规则开发软件。编码规则可以是众所周知的行业标准，也可以是制造 商规定内部标准。宜按照软件单元规范和编码规则对代码进行审查。 注1：编码规则旨在限制编程的自由度，以避免程序代码变得难以理解。 注2：编码规则通常定义编程语言的子集或使用强类型编程语言（见GB/T20438.7—2017的C.4.1，C语言在关键 系统中的使用指南（MISRAC)）。 注3：代码审查可以通过手工进行，也可以通过静态代码分析工具自动进行。 宜使用以下编程手段来避免系统性失效： 一变量和配置参数的范围检查和合理性检查； 一时间和（或）逻辑程序时序监控，以检测有缺陷的程序时序； 一限制全局变量的数量或范围。 注4：有关面向对象的体系架构和设计的指南，见GB/T20438.7一2017中的附录G。 编码输出物宜包含： 源代码列表； 代码审查报告。 为了限制网络安全风险，宜采用安全编码规则。根据网络安全需求、嵌人式操作系统和编程语言的 不同，安全编码规则可能会有很大的不同。 例如，在高完整性、中等可用性、操作系统仅限于制造商应用程序和C语言的情况下，宜使用ISO/ ECTS17961：2013和CERT/CCC：2016中规定的以下规则： 从不信任用户输人：清洗传递给复杂子系统的数据，并从格式字符串中排除用户输人； 使用容器类型时检查边界：不要形成或使用越界指针或数组下标，不要对指向非数组对象的指 针进行整数的加减； 安全内存管理：为对象分配足够的内存，且只动态分配空闲内存； 仅在信号处理程序中调用安全函数：仅在信号处理程序中调用异步安全函数，并且不访问信号 处理程序中的共享对象； 其他规则：默认拒绝访问并遵守最小权限原则，

定刷 商规定内部标准。宜按照软件单元规范和编码规则对代码进行审查。 注1：编码规则旨在限制编程的自由度，以避免程序代码变得难以理解。 注2：编码规则通常定义编程语言的子集或使用强类型编程语言（见GB/T20438.72017的C.4.1，C语言在关键 系统中的使用指南（MISRAC)）。 注3：代码审查可以通过手工进行，也可以通过静态代码分析工具自动进行。 宜使用以下编程手段来避免系统性失效 变量和配置参数的范围检查和合理性检查； 一时间和（或）逻辑程序时序监控，以检测有缺陷的程序时序； 一限制全局变量的数量或范围。 注4：有关面向对象的体系架构和设计的指南，见GB/T20438.7一2017中的附录G。 编码输出物宜包含： 源代码列表； 代码审查报告。 为了限制网络安全风险，宜采用安全编码规则。根据网络安全需求、嵌人式操作系统和编程语言的 不同，安全编码规则可能会有很大的不同。 例如，在高完整性、中等可用性、操作系统仅限于制造商应用程序和C语言的情况下，宜使用ISO/ IECTS17961：2013和CERT/CCC：2016中规定的以下规则： 一从不信任用户输人：清洗传递给复杂子系统的数据，并从格式字符串中排除用户输人； 使用容器类型时检查边界：不要形成或使用越界指针或数组下标，不要对指向非数组对象的指 针进行整数的加减； 安全内存管理：为对象分配足够的内存，且只动态分配空闲内存； 仅在信号处理程序中调用安全函数：仅在信号处理程序中调用异步安全函数，并且不访问信号 处理程序中的共享对象； 其他规则：款认拒绝访间并遵守最小权限原则

未经评估的每个软件单元宜根据软件单元规范中定义的测试用例进行测试 如果软件单元未通过测试，则宜采取预定义的纠正措施。 测试结果和纠正措施宜形成文件

软件单元测试宜至少使用动态分析技术并进行测试（GB/T20438.7一2017中的B.6.5)

宜根据软件架构规范中规定的集成测试用例进行测试。软件集成测试的结果宜形成文件。 宜执行以下两个不同的步骤： a）软件集成，仅检查软件模块的交互（通过专用软件集成测试工具）； b）软硬件集成，验证上述相同的模块在目标硬件上的相互影响（允许有效的定时测量和全局行为 检查）。 注：这些测试的目的是表明所有软件单元和软件组件/子系统都可以正确交互以执行其预期功能，并且不执行非预 期功能。这并不意味着测试所有输入组合，也不意味着测试所有输出组合。测试所有等效类或基于结构的测 试就足够了。边界值分析（GB/T20438.7—2017中的C.5.4)或控制流分析（GB/T20438.7—2017中的5.5.9） 可以将测试用例减少到可接受的数量。可分析的程序更容易满足需求。

软件测试的主要目的是确保实现软件需求规范中的详述的功能。 软件测试的主要输出是一个文档，例如带有测试用例和测试结果的测试报告，且允许对测试覆盖率 进行评估。 软件测试也包括故障仿真和相关的故障处理。 当使用已经测试过、包含故障检测和处理措施的软件单元时（例如输入信号的差异或输出的反馈节 点），则不需要对这些故障检测和处理措施进行测试。在这种情况下，只需要对这些软件单元的集成进 行测试。 如果依据指定最终用户用例（如开箱即用体验或软件升级）对集成在设备或系统中的目标硬件进行 测试，则可以将软件测试作为系统验证的一部分进行。 宜采用功能测试作为基本措施。如可行，宜通过仿真来测试代码。 宜定义用于测试嵌人式软件的一般准则或程序，包括： 测试类型； 测试设备的规范，包括工具、支持软件和配置说明； 测试及纠正嵌入式软件过程中的软件版本管理； 缺陷跟踪过程，如错误登记、分级、修复、批准； 测试失败后的纠正措施； 完成相关功能或需求的测试标准； 测试的物理位置，例如可以通过计算机仿真、工作台或设备硬件进行测试

7.10.2测试计划与执行

基于测试用例的测试计划宜包括： 按名称定义角色和职责； 安装测试环境； 功能测试。 软件测试包括以下两种活动类型： 静态分析：对软件的分析。例如通过人工审查，如“4眼”代码审查：检查、走读、控制流分析、数 据流分析。或通过自动代码分析，例如通过MISRA检查。静态分析通常由代码开发人员在 代码实现过程中执行。

基于测试用例的测试计划宜包括： 按名称定义角色和职责； 安装测试环境； 功能测试。 软件测试包括以下两种活动类型： 静态分析：对软件的分析。例如通过人工审查，如“4眼”代码审查：检查、走读、控制流分析、 据流分析。或通过自动代码分析，例如通过MISRA检查。静态分析通常由代码开发人员 代码实现过程中执行。

动态测试：软件在受控且系统化的条件下执行，从而证明其达到预期功能，且无非预期的行为。 尤其包括功能性测试或黑盒测试。 在软件生命周期的早期阶段，采用静态分析进行验证。当代码生成并可运行时，可以进行动态测 试。为了验证软件生命周期活动的输出，上述两种类型的活动要结合使用。有关静态分析和动态测试 的进一步说明，见GB/T20438.3一2017。 嵌人式软件的验证和测试要求包括： 一宜进行静态分析并形成文件。 宜进行动态测试并形成文件。在测试过程中，每个子程序（子程序或函数）宜至少调用一次（入 口）。 动态测试过程中，代码中的所有声明宜至少执行一次。 如果在诊断功能中使用软件来控制随机硬件故障，则动态测试宜解决诊断的正确实施问题，例 如通过故障插人测试。 动态测试宜包括对目标硬件的最终测试，

从系统需求提出至完成软件验证计划，整个软件开发过程宜可追溯。 每个软件开发生命周期阶段的文件都要归档，并提供给相关人员。 测试结果和采取的纠正措施宜形成文件，

建筑施工组织设计7.12配置和变更管理

软件的任何修改或变更都宜进行影响性分析，以确定所有受影响的软件部分，并进行必要的重新设 计、重新审查和重新测试活动，以确认其仍符合相关软件需求规范 宜规定并记录配置管理和变更管理过程文件，且至少宜包括下列项目： 配置管理要素，至少包含：软件需求、概要和详细的软件设计、软件单元源代码、验证测试的计 划、过程和结果； 每个软件单元或配置要素的唯一识别标识规则； 一从申请到实施的所有变更过程。 对于配置的每个要素，需可识别已发生的所有变更及相关要素的版本。 注1：目的是能够跟踪每个要素的开发过程（即已经做了哪些修改，为什么修改，何时修改）。 软件配置管理宜允许获得精确且唯一的软件版本标识。配置管理宜关联所有必要的要素（及其版 本），以证明主功能的完整性。 在进行最终软件版本评估测试之前，软件配置中的所有要素都宜包含在配置管理过程中。 注2：此处的目的是确保在软件执行评估程序时，所有要素都处于精确管理的状态。任何后续的变更都可能需要 对软件进行修订，以便分析人员可以识别该软件。 宜建立软件及其相关数据的归档程序（存储备份和归档的方法）。 注3：这些备份和存档可用于在软件的生命周期内维护和修改软件。

7.13与设备及系统相关的验证

验证宜包括： 验证在目标硬件上执行时软件指定的功能行为和性能标准（例如时序性能），包括用户用例； 验证软件措施是否有效降低风险评估中确定的风险； 验证软件开发过程中为避免系统性软件故障而采取的措施和方法。 第一步，检查是否有嵌入式软件相关的规范和设计文档。宜对规范及文档进行审查，确保其完整

，检查是否存在错误的解释、遗漏或不一致之处。 注：对于小型程序，通过使用如软件文档（控制流程图、软件单元或块的源代码、I/O和变量分配列表、交叉引用列 表）的方式对控制流、过程等进行审查或走读来对程序进行分析就足够了。 通常，可以将软件视为“黑盒”或“灰盒”，并分别通过黑盒或灰盒测试进行验证。 测试内容包括： 功能行为和性能的黑盒测试（例如时序性能）； 一基于极值分析的附加扩展测试用例； 一I/O测试，以确保正常使用输人和输出信号； 模拟预先分析确定的故障及预期响应的测试用例，以评估基于软件的故障控制措施的充分性； 一从内部和外部客户的角度进行最终用户环境测试，以验证该解决方案是否按预期为最终用户 工作。这可以是设备或整个系统验证的一部分。 后续测试宜包括： 工业网络环境和控制系统测试； 大量的网络流量测试； 鲁棒性行为测试； 测试重复性测试的性能，例如配置写人和电源循环； 从用户角度测试固件升级性能 已验证的单个软件功能不需要再次验证。但是，如果为一个特定项自组合了多个这样的功能块饮用水标准，宜 证主功能的最终完整性。同时宜进行影响性分析，以确定哪些软件功能需要重新验证。 宜检查软件相关用户手册，确认已经采取充分的措施和行动来避免软件系统故障。 宜审查软件实施、配置和变更管理措施，以确保其正确执行。 如果嵌人式软件后续进行了修改，则宜在适当的范围内对其进行重新验证

性，检查是否存在错误的解释、遗漏或不一致之处。 注：对于小型程序，通过使用如软件文档（控制流程图、软件单元或块的源代码、I/O和变量分配列表、交叉引用列 表）的方式对控制流、过程等进行审查或走读来对程序进行分析就足够了。 通常，可以将软件视为“黑盒”或“灰盒”，并分别通过黑盒或灰盒测试进行验证。 测试内容包括： 功能行为和性能的黑盒测试（例如时序性能）； 一基于极值分析的附加扩展测试用例； 一1/O测试，以确保正常使用输人和输出信号； 模拟预先分析确定的故障及预期响应的测试用例，以评估基于软件的故障控制措施的充分性； 从内部和外部客户的角度进行最终用户环境测试，以验证该解决方案是否按预期为最终用户 工作。这可以是设备或整个系统验证的一部分。 后续测试宜包括： 工业网络环境和控制系统测试； 大量的网络流量测试； 鲁棒性行为测试； 测试重复性测试的性能，例如配置写入和电源循环； 从用户角度测试固件升级性能 已验证的单个软件功能不需要再次验证。但是，如果为一个特定项自组合了多个这样的功能块，宜 验证主功能的最终完整性。同时宜进行影响性分析，以确定哪些软件功能需要重新验证。 宜检查软件相关用户手册，确认已经采取充分的措施和行动来避免软件系统故障。 宜审查软件实施、配置和变更管理措施，以确保其正确执行。 如果嵌人式软件后续进行了修改，则宜在适当的范围内对其进行重新验证，