IEC 61713：软件全寿命周期的可信性

要点提示：IEC 61713 提供了一个全面的软件可信性管理框架，覆盖从概念定义到开发、运行直至退役的全寿命周期。该标准在通用可信性概念（IEC 60300 系列）与软件特定工程实践之间架起了桥梁。

一、标准范围与可信性框架

IEC 61713 针对软件故障可能带来安全、经济或环境后果的系统中实现可信软件的关键挑战。该标准适用于所有类型的软件系统，包括工业控制系统中的嵌入式软件、交通运输和医疗设备中的安全关键应用、企业信息系统以及基础设施管理平台。IEC 61713 并非规定单一方法论，而是提供了一套可信性原则和实践框架，可根据每个项目的具体关键性等级、开发背景和组织能力进行定制。

标准将可信性定义为一个复合属性，涵盖四个关键特质：可用性（随时准备提供正确服务）、可靠性（正确服务的连续性）、安全性（无灾难性后果）和可维护性（接受修改和维修的能力）。针对软件，IEC 61713 进一步扩展了完整性（无不适当的系统变更）和安全性（防止故意故障）。这种整体视角认识到仅关注可靠性无法实现真正的可信性——一个高度可靠但不安全或不保密的系统并不是真正可信的。

注意事项：IEC 61713 指出一个常见的误解——软件可信性可以在开发结束时通过”测试”获得。标准强调可信性必须从最早的概念阶段开始设计，每个寿命周期阶段都要贡献特定的可信性活动并产生可验证的可信性证据。

标准将可信性寿命周期分为六个主要阶段：概念与定义、需求规格说明、设计与开发、集成与测试、安装与运行以及退役。对于每个阶段，IEC 61713 都规定了可信性目标、所需输入、推荐活动和预期输出。这种分阶段方法使项目经理和质量保证团队能够将可信性活动集成到现有开发流程中，无论是使用瀑布式、迭代式还是敏捷方法。

二、可信性技术及其在寿命周期中的应用

IEC 61713 将可信性技术组织为四个基本策略：故障预防、故障容错、故障排除和故障预测。这四种策略贯穿软件寿命周期，在不同阶段有不同的侧重点。

策略	寿命周期重点	关键技术	可度量结果
故障预防	概念到设计	结构化方法、形式化规约、设计评审、编码标准、配置管理	降低单元级故障密度
故障容错	架构到实现	冗余（N版本、恢复块）、异常处理、看门狗、优雅降级	故障时维持服务
故障排除	集成到维护	静态分析、动态测试、形式化验证、代码审查、回归测试	故障检测与修正速率
故障预测	测试到运行	可靠性增长模型（按IEC 61710）、故障密度估计、运行剖面测试	残余故障预测、MTTF/S估计

故障预防在寿命周期早期阶段受到最大重视。标准强调，概念阶段预防一个需求故障的成本通常是在运行阶段修正同一故障的 1/10 到 1/100。关键的预防技术包括需求规格的形式化方法、基于历史故障数据清单的系统设计评审、以及在安全关键嵌入式软件中使用 MISRA C/C++ 等编码标准。配置管理和严格的变更控制被确定为贯穿整个寿命周期的必要预防机制。

最佳实践：对于安全关键软件项目，IEC 61713 建议组合使用独立的故障预防技术。例如，将形式化规约（Z 或 B 方法）与结构化设计评审结合使用，可在编写任何代码前检测到超过 85% 的需求缺陷，而单独使用任一技术仅能达到约 40-50%。

故障容错针对一个现实问题——尽管采取了最佳的预防和排除措施，已部署的软件中仍会残留故障。标准描述了几种架构模式。N版本编程（由不同团队独立实现同一规约）提供针对设计故障的容错，而恢复块技术（带验收测试的备选例程）更适用于算法故障。对于实时控制系统，看门狗定时器和异常处理框架是必须的最低限度的故障容错机制。标准指出，应通过故障注入测试验证故障容错技术，即有意识地引入已知故障以验证容错机制的行为是否符合预期。

三、可信软件工程设计要点

IEC 61713 的一个关键工程概念是可信性案例——一个有说服力的、有效的论据和记录的证据体系，证明系统在给定环境中对于给定应用是可信的。可信性案例类似于 IEC 61508 和 DO-178C 等标准要求的安全案例，但涵盖所有可信性属性，而不仅仅是安全性。标准建议在寿命周期中逐步开发可信性案例，从概念阶段的可信性策略开始，在后续阶段通过证据收集逐步完善。

标准基于软件的关键性等级提供了选择可信性技术的详细指南。定义了四个关键性等级，从 1 级（故障后果为轻微的经济或不便）到 4 级（灾难性的安全或环境后果）。每个等级要求逐步更严格的可信性活动和证据。这种基于风险的方法使组织能够按比例分配可信性工程资源，既避免关键功能工程不足，也避免非关键功能过度工程。

关键性等级	故障后果	最低可信性要求
1 级	轻微不便，无安全影响	编码标准、单元测试、基本配置管理
2 级	中度经济损失，可能轻微伤害	1级 + 设计评审、集成测试、故障预测
3 级	重大经济损失，可能严重伤害	2级 + 形式化规约、独立验证确认、故障容错
4 级	灾难性，人员伤亡，严重环境破坏	3级 + 形式化验证、多样性冗余、独立安全案例

重要提醒：IEC 61713 警示”可信性平台效应”——在某一临界点之后，增加测试投入在故障检测方面收益递减。标准建议在系统测试期间使用故障预测（可靠性增长模型）客观估计残留故障密度。当故障检测率接近平台时，应将工作从故障排除转向故障容错和运行监控。

对于实际实施 IEC 61713 的工程师，标准强调了运行剖面的重要性——对系统在预期环境中使用方式的定量刻画。运行剖面将驱动可靠性测试的测试用例选择、为关键功能分配容错机制提供依据、并为可信性指标的解读提供背景。没有代表性的运行剖面，可靠性增长模型可能产生不反映现场经验的乐观预测。标准建议在整个寿命周期中随着早期部署和 Beta 测试阶段获取更多使用数据而更新运行剖面。

与现有软件工程标准的集成是 IEC 61713 的另一个优势。标准提供了到 ISO/IEC 12207（软件寿命周期过程）、IEC 61508（功能安全）、ISO 26262（汽车安全）和 IEC 62304（医疗器械软件）的映射指南。对于在多个标准下运行的项目，IEC 61713 可作为总体可信性框架，而领域特定标准则处理专业的安全和法规要求。这种协调方法减少了重复工作，确保整个系统寿命周期中一致的可信性管理。

常见问题解答

问题1：IEC 61713 是否适用于敏捷软件开发项目？

适用。IEC 61713 与方法论无关，可适用于敏捷方法。关键是将标准定义的可信性活动映射到敏捷仪式和工件中。例如，故障预防活动与冲刺规划和完成定义一致；故障排除映射到持续集成测试和冲刺评审；可信性案例可作为活文档在每个冲刺更新。标准明确认可迭代开发可与严格的可信性管理兼容。

问题2：IEC 61713 与 IEC 61508（功能安全）有何关系？

IEC 61713 和 IEC 61508 是互补的。IEC 61508 专门关注功能安全（因故障行为导致的危险不可接受风险的消除），而 IEC 61713 涵盖更广泛的可信性属性，包括可靠性、可用性和可维护性。实践中，在安全功能方面符合 IEC 61508 的项目将已满足 IEC 61713 对这些功能的许多要求。IEC 61713 填补了非安全相关的可信性方面的空白，并提供了统一的框架。

问题3：应跟踪哪些指标来证明软件可信性？

IEC 61713 推荐一套平衡的指标：故障密度（开发期间每千行代码的故障数）、缺陷检测有效性（发布前发现的缺陷百分比）、平均恢复服务时间（可维护性）、运行故障强度（可靠性）和需求稳定性（过程质量）。单一的指标是不够的——标准强调必须通过随时间跟踪的多项互补度量来评估可信性。

问题4：在需要符合 IEC 61713 的系统中能否使用开源软件组件？

可以，但需要额外的鉴定活动。IEC 61713 要求所有软件组件（不论来源）都须经过与其关键性相称的可信性评估。对于开源组件，这通常意味着：对照标准要求验证组件的开发过程、进行独立漏洞评估、建立针对开源社区中新发现故障的监控过程。标准提供了评估”未知来源软件”（SOUP）的具体指南。