【DO-178B阅读笔记】第二章、与软件开发相关的系统层面的内容_多版本非相似

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Golang全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Go语言开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024b （备注go）

正文

理解软件生命周期过程所必需的系统生命周期过程相关内容在本章讨论，包括：

• 系统生命周期过程和软件生命周期过程之间的信息交换（2.1节）
• 失效状态分类、软件等级定义和软件等级的确定（2.2节）
• 系统体系结构的考虑（2.3节）
• 系统层面对用户可修改软件、可选项软件和商用成品软件的考虑（2.4节）
• 针对外场可加载软件的系统设计考虑（2.5节）
• 针对软件验证的系统需求考虑（2.6节）
• 系统验证中的软件考虑（2.7节）

失效状态分类

若要全面地了解失效状态分类的定义，可参考有关的条例和指导性材料，联邦航空局AC25-1309-1A和/或联合航空管理局AMJ25-1309及其修订内容。下面列举的失效状态分类信息来自这些指导材料，包含这些内容是为了更好地使用本文。失效状态的分类为：

a.灾难性的失效状态：导致不能继续安全飞行和着陆的失效状态。

b.危险的/严重的失效状态：降低航空器的性能和机组人员克服不利操纵状态能力的失效状态。这类不利操纵状态可达到以下程度：

（1）大大降低了安全余量或正常工作的能力：

（2）产生身体伤害或高负荷使机组人员不能精确或完整地完成他们的任务；

（3）对机上人员产生不利影响，包括对少数人员严重的或潜在的致命伤害。

c.较重的失效状态：可能降低航空器的性能和机组人员克服不利操纵状态的能力的失效状态。这些不利操纵状态可达到的程度有：显著地降低安全余量或正常工作能力、显著地增加了机组人员的工作量或削弱机组人员工作效率、或造成机上人员不舒服，甚至伤害。

d.较轻的失效状态：不会显著降低航空器安全，且机组人员仍能保持较好的执行能力的失效状态。较轻的失效状态可能是：稍微降低安全余量或正常工作能力、稍微增加机组人员的工作量，如例行飞行计划的更改、或给乘客带来某些不便。

e.无影响的失效状态：不影响航空器的工作能力，或不增加机组工作量的失效状态。

软件等级定义

软件等级基于系统安全评估过程中确定的软件对潜在失效状态的影响而确定。软件分等级意味着：随着失效状态分类的不同，为符合合格审查要求而采取的努力程度也不同。软件等级的定义如下：

A级软件：通过系统安全评估表明，其异常行为会引起或影响系统功能失效，进而导致航空器灾难性失效状态的软件。

B级软件：通过系统安全评估表明，其异常行为会引起或影响系统功能失效，进而导致航空器危险的/严重的失效状态的软件。

C级软件：通过系统安全评估表明，其异常行为会引起或影响系统功能失效，进而导致航空器较重的失效状态的软件。

D级软件：通过系统安全评估表明，其异常行为会引起或影响系统功能失效，进而导致航空器较轻的失效状态的软件。

卫E级软件：通过系统安全评估表明，其异常行为会引起或影响系统功能失效，但不会影响航空器的正常工作能力或飞行员工作量的软件。一旦软件由合格审查机构定为E级，本文提供的提供意见就不再适用。

软件等级确定

首先，系统安全评估过程在不考虑系统设计的情况下，对特定系统中的软件部件确定合适的软件等级。确定软件等级时，必须说明失效的影响，包括功能丧失的影响和功能异常的影响。

注：（1）申请人可能想会考虑在后续的开发过程中会增加预期的功能，以及分配给软件的系统需求也可能会发生改变。这些变化可能会导致失效状态变得更严重，以及软件等级的提升。在这种情况下，按高于最初安全评估确定的等级开发软件也许是可取的：因为功能增加或需求更改之后，按原定等级产生的软件生命周期数据难以支持更高的软件等级（即按原来较低软件等级组织开发而产生的数据，可能无法为更高等级软件的符合性提供证据）。

（2）对于受运行条例强制约束，但又不影响航空器适航性的机载系统和设备，如飞行数据记录仪，软件等级要与该系统和设备预定功能相匹配。某些情况下，可在设备最低性能指标中规定软件等级。

如果软件部件的异常行为影响到多个失效状态，则最严重的失效状态决定了该软件部件的等级。随着系统设计的深入，2.3节中描述的那些系统体系结构会导致软件等级的修正。

一个系统功能可以分配到一个或多个分区的软件部件。并行实现就是用多个软件部件来实现同一系统功能，这样一来，只有当多个部件行为异常时才能产生一个失效状态。对并行实现，至少要有一个软件部件具有系统功能最严重的失效状态对应的软件等级，其它部件的软件等级按该部件功能丧失时的失效状态来确定。在2.3.2节的多版本非相似软件和2.3.3节的安全监控中对这类实现进行了描述。

一个系统功能也可由多个软件部件串行实现，此时任何部件的异常行为都能产生失效状态。在这种实现中，所有软件部件将具有与系统功能最严重的失效状态对应的软件等级。

按某一等级进行软件开发并不意味着指定了该软件的失效率。因此，在系统安全评估过程中，不能象硬件失效率那样使用软件等级或基于软件等级的软件可靠性。

非本指导意见（即本文的2.2.3节）所描述的软件等级确定方法，需通过系统安全评估过程来证明其正确性。

系统体系结构方面的考虑

如果系统安全评估过程表明系统体系结构可阻止软件异常行为造成系统最严重的失效状态，那么要根据软件异常行为能产生影响的、余下失效状态中最严重的失效状态来确定其软件等级。系统安全评估过程考虑体系结构设计方案，以确定它们是否影响软件等级或软件的功能。下面对几种体系结构提供了指导意见，这些体系结构可限制错误的影响、或检测出错误，并提供可接受的系统响应来抑制错误。不要错误地将这些体系结构技术理解为是本文所偏好的、或所要求的解决方案。

分区

分区是对功能上独立的软件部件提供隔离的技术，以抑制和/或隔离故障，并可能减少软件验证过程的工作。如果通过分区提供了保护，那么分区内软件部件的软件等级可由该部件相关的、最严重的失效状态来确定。

对分区的指导意见包括：

.当设计了分区保护时，要考虑系统的下列几个方面，以确定它们是否破坏了分区保护：

（1）硬件资源：处理器、存储器设备、输入/输出设备、中断和定时器；

（2）控制耦合：对外部访问的脆弱性；

（3）数据耦合：共享或重叠的数据，包括堆栈和处理器寄存器数据；

（4）与保护机制相关的硬件设备的失效模式。

b.软件生命周期过程要说明分区的设计考虑，包括分区的部件之间允许的交互程度和范围、是通过硬件还是通过软件和硬件的组合来实现分区保护。

c.如果分区保护涉及到软件，那么该保护软件的等级要与分区内的软件部件的最高等级相对应。

多版本非相似软件

多版本非相似软件是一项系统设计技术，它涉及到研制两个或多个软件部件，这些软件部件提供同样的功能，从而可避免这些部件间某些同源错误。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注Go）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
4b （备注Go）**
[外链图片转存中…(img-S2eLtORo-1713434875064)]

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！