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.如果分区保护涉及到软件，那么该保护软件的等级要与分区内的软件部件的最高等级相对应。
多版本非相似软件
多版本非相似软件是一项系统设计技术，它涉及到研制两个或多个软件部件，这些软件部件提供同样的功能，从而可避免这些部件间某些同源错误。
多版本非相似软件也称为多版本软件、非相似软件、N版本编程或软件多样性。
必须注意的是，在非相似性引入软件开发之前完成的或进行中的软件生命周期过程仍有潜在的错误源。执行多版本非相似软件的硬件配置可在系统需求中指定。
非相似的程度及相应的保护程度通常是不可测量的。采用了非相似软件后，只有在非相似版本的安全监控功能检测出实际错误，或遇到超过比较器门限的瞬态时，系统功能才会失效。因此，当软件等级的对应的软件验证目标（详见第6章）得到满足后，通常采用非相似软件提供额外的保护。如果系统安全评估过程确定其潜在的系统功能丧失是可接受的，非相似软件的验证方法可在单一版本软件验证方法的基础上进行简化。
多版本非相似软件的验证在12.3.3中讨论。
安全监控
安全监控通过直接监控可能引起特定失效状态的某个功能，进而防止该失效状态发生的一种手段。监控功能可通过硬件、软件、或硬件与软件的组合来实现。
通过使用监控技术，受监控功能的软件等级可以降低至与其相关的系统功能丧失对应的等级。如果要降低软件等级，需确定监控器的三个重要属性：
a.软件等级：安全监控软件的等级要与受监控功能最严重的失效状态相对应。
b.系统故障覆盖：评估监控器的系统故障覆盖情况，确保监控器的设计和实现能使待检测的故障在所有必要条件下会被检测出来。
c.功能和监控器的独立性：监控器和防护机制不会因引起危害的同一失效而同时不起作用。
系统设计对外场可加载软件的考虑
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数Go语言工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年Go语言全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Golang知识点，真正体系化！
由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新
如果你觉得这些内容对你有帮助，可以添加V获取：vip1024b （备注Go）
一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
[外链图片转存中…(img-ZF77DvxJ-1712998481786)]
一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
2667
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
