Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
IEC 62628：软件可信性方面指南
IEC 62628:2012 提供了在整个软件生命周期中管理可信性方面的全面指导。它涵盖了软件密集型系统的可靠性、可用性、可维护性和完整性（RAMI），弥合了传统硬件可靠性工程与软件质量管理实践之间的差距。
核心目的：建立一个统一的软件可信性框架，与工业自动化、交通运输、能源和医疗系统等行业的系统级可信性计划集成。
一、软件可信性框架
该标准将可信性定义为描述可用性性能及其影响因素的集合术语：可靠性性能、可维护性性能和维护支持性能。对于软件而言，完整性——防止未经授权的访问或修改的属性——被添加为关键属性。
| 可信性属性 | 软件特定定义 | 关键指标 |
|---|---|---|
| 可靠性 | 在规定条件下给定时间内无故障运行的概率 | MTTF、失效强度、可靠性增长 |
| 可用性 | 软件在需要时可运行和可访问的概率 | 可用率、停机时间百分比 |
| 可维护性 | 修改软件以纠正故障或改进性能的难易程度 | 平均修复时间 (MTTR)、变更影响 |
| 完整性 | 防止对软件和数据进行不当修改或破坏 | 安全事件率、数据损坏率 |
二、可信性工程过程
2.1 生命周期集成
标准建议将可信性活动嵌入软件生命周期的每个阶段，从概念到退役。关键活动包括：
- 需求阶段：建立可信性目标，识别关键失效模式
- 设计阶段：应用故障避免、故障容错和故障排除技术
- 实现阶段：编码标准、静态分析、同行评审
- 测试阶段：可靠性增长测试、压力测试、故障注入
- 运维阶段：失效数据收集、根因分析、纠正措施
最佳实践：在需求和设计阶段早期投入可信性活动，与在测试或运维阶段处理故障相比，可节省 5-10 倍的成本。
2.2 故障分类与策略
IEC 62628 将软件故障分为三类：
- 故障避免：通过严格的开发过程、形式化方法和经过验证的工具链防止故障引入
- 故障控制：通过检查、分析和测试来检测和排除故障
- 故障容错：设计软件使其即使在存在故障的情况下也能保持功能
三、可信性评估与改进
3.1 评估方法
标准描述了多种互补的评估方法：
- 软件可靠性增长模型：使用失效数据预测未来可靠性（如 Goel-Okumoto、Musa-Okumoto 模型）
- 运行剖面测试：基于预期使用模式构建测试以估算现场可靠性
- 故障注入：有意引入故障以评估故障容错机制
- 可信性案例：将证据与可信性声明联系起来的结构化论证
3.2 改进技术
| 技术 | 描述 | 可信性影响 |
|---|---|---|
| 复杂度简化 | 减少模块大小、消除死代码 | 降低故障密度 30-50% |
| N 版本编程 | 相同规范的独立实现 | 屏蔽设计故障 |
| 恢复块 | 检测到故障时切换备用例程 | 提高可用性 |
| 结构化文档 | 可追溯的需求到代码映射 | 支撑可维护性 |
工程见解：软件复杂度是可信性风险的最大单一贡献因素。IEC 62628 强烈强调复杂度简化作为主要的故障避免策略——远比任何基于测试的方法更有效。
工程设计要点
- 运行剖面至关重要——如果不了解软件的实际使用方式，可信性测试在统计上毫无意义
- 同时跟踪缺陷密度和失效强度——它们衡量不同的事物；如果缺陷集中在频繁执行的路径中，低缺陷密度并不能保证高可靠性
- 硬件-软件交互很重要——许多系统故障源于软件与硬件的边界，特别是在时序和资源争用方面
- 可信性数据反馈循环——现场失效数据应系统地反馈到设计和测试过程中，以闭合可信性改进循环
- 根据关键性调整严格程度——并非所有软件都需要相同级别的可信性；基于风险的方法使用标准的裁剪指南来优化成本与保证
常见问题
问：IEC 62628 与 IEC 61508（功能安全）有何关系？
答：IEC 61508 侧重于安全相关系统，而 IEC 62628 涵盖所有软件密集型系统的更广泛可信性属性（可靠性、可用性、可维护性、完整性）。这两个标准互为补充——安全是可信性的一个子集。
问：软件可靠性与硬件可靠性有何区别？
答：硬件可靠性通常遵循浴盆曲线，存在磨损故障，而软件可靠性随着故障被检测和排除而随时间提高。软件不会磨损——其故障是从一开始就存在的设计缺陷。
问：敏捷开发是否与 IEC 62628 的可信性要求兼容？
答：是的。该标准与生命周期模型无关。敏捷团队可以在冲刺内实施可信性活动——例如用于故障检测的持续集成、用于可靠性保证的自动化回归测试以及用于过程改进的回顾会议。
四、工具与基础设施支持
IEC 62628 强调自动化工具在整个软件可信性工程中的关键作用。现代软件工程实践中，持续集成/持续交付（CI/CD）流水线应当集成静态代码分析、单元测试覆盖率检查、可靠性增长模型拟合和回归测试自动化等功能。特别推荐采用基于模型的测试（MBT）技术，通过自动生成测试用例覆盖运行剖面中的高概率路径，显著提高测试效率。
软件可信性数据的收集和管理同样至关重要。标准建议建立集中的缺陷数据库和失效报告系统，记录每个失效的发现时间、严重等级、根因分类和修复措施。利用这些数据可以拟合 Goel-Okumoto 或 Musa 可靠性增长模型，预测达到目标可靠性水平所需的额外测试时间。对于关键安全系统，还应当建立独立的可信性验证团队（IV&V），确保评估过程的客观性和完整性。实践证明，早期引入 IV&V 可以在需求阶段发现高达 60% 的潜在缺陷，大幅降低后期修复成本。
