高清可复制 HB 8658-2022 民用飞机机载系统和设备软件设计要求

　　ICS 49.090 V 45

　　HB 8658-2022

　　民用飞机机载系统和设备软件设计要求

　　Design requirements for software of airborne systems and

　　equipments of civil aircraft

　　2022-04-24 发布 2022-10-01 实施

　　中华人民共和国工业和信息化部 发 布

　　前 言

　　本标准按照 GB/T 1.1-2009《标准化工作导则 第 1 部分：标准的结构和编写》给出的规则起草。本标准由中国航空综合技术研究所归口。

　　本标准起草单位：中国航空无线电电子研究所、中国航空综合技术研究所。

　　本标准起草人：李 园、缪万胜、乐 斌、饶俊文、马慧敏、张 英、王博甲、任文明、王炜信、朱晓飞、郭 威、陶瑞超。

　　民用飞机机载系统和设备软件设计要求

　　1 范围

　　本标准规定了民用飞机机载系统和设备软件开发过程中的软件需求分析、软件体系结构设计和软件详细设计等软件设计要求。

　　本标准适用于民用飞机机载系统和设备的软件设计过程。

　　2 规范性引用文件

　　下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件， 仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。

　　GB/T 11457-2006 软件工程术语

　　3 术语和定义

　　GB/T 11457-2006 界定的以及下列术语和定义适用于本文件。

　　3.1

　　派生需求 derivative requirements

　　软件开发过程产生的附加需求，它不可以直接追踪到高级需求。

　　3.2

　　设计模型 design model

　　定义软件设计的模型，如低层次需求、软件架构、算法、组件内部数据结构、数据流和/或控制流。

　　用于生成源代码的模型是设计模型。

　　3.3

　　动态内存 dynamic memory

　　在系统运行中，根据需要进行分配，运行结束后应释放的内存空间。

　　3.4

　　外部接口 external interface

　　CSCI 与其他 CSCI 或硬件之间的数据关系。

　　3.5

　　扇入 fan-in

　　一个模块被其他模块调用。

　　3.6

　　扇出 fan-out

　　一个模块直接调用其他模块。

　　3.7

　　高层需求 high-level requirements

　　分析系统需求、安全性有关的需求及为系统设计结构而开发的需求。

　　3.8

　　内部接口 internal interface

　　CSCI 内部各模块之间的数据关系。

　　3.9

　　低层需求 low-level requirements

　　来自高层需求、派生需求及源代码能直接实现而无需进一步分解的需求。

　　3.10

　　模型 model

　　对系统方面的给定集合的抽象表示，用于系统的分析、验证、仿真、代码生成或这些工作的组合。无论其抽象层次如何，模型应该是明确的。

　　注 1：如果是一个解释上存在歧义的图形，则不认为这是一个模型。

　　注 2：“系统方面的给定集合”可能包含系统的所有方面，也可能只包含一个子集。

　　3.11

　　模型元素 model element

　　用以构建模型的单元。

　　3.12

　　建模技术 modeling technique

　　建模语言和使用此建模语言的特定方式的组合。它是由描述模型信息的抽象级别以及所选的建模工具来驱动。

　　3.13

　　模块 module

　　一个离散的程序单位，在程序中能够逻辑的分开，可独立的描述一个功能，且对于编译、与其他单位结合而言，是可识别的。

　　3.14

　　多版本非相似软件 multiple-version dissimilar software

　　分别开发的能够实现相同功能的两套或多套程序。可通过比较各路的输出结果来检测出某个版本的软件错误。

　　3.15

　　分区 partitioning

　　一种分离或隔离软件部件的方法，以防止发生不必要的软件交互或交叉耦合干扰，并便于隔离故障。分区还允许在同一系统中使用不同的软件级别。

　　3.16

　　冗余 redundancy

　　出于系统安全和可靠性等方面的考虑，人为地对一些关键部件或功能进行重复的配置。

　　3.17

　　重用 reuse

　　在两次或多次不同的软件开发过程中，重复使用相同或相似的软件。

　　3.18

　　安全性监控 safety monitoring

　　一种功能能力，可以在系统中设计用于检测系统异常行为。监控功能可通过硬件、软件或硬件和软件的组合来实现。

　　3.19

　　安全性 safety

　　产品具有的不导致人员伤亡、系统毁坏、重大财产损失或不危及人员健康和环境的能力。

　　3.20

　　共享内存 shared memory

　　在多处理器的计算机系统中，可被不同 CPU 访问的大容量内存。

　　3.21

　　规范模型 specification model

　　描述高层需求的模型，该模型提供了软件组件的功能、性能、接口或安全特定的抽象描述。规范模型不定义软件设计细节，如内部数据结构、内部数据流或内部控制流。

　　3.22

　　用户可修改软件 user modifiable software

　　在原认证项目中规定的修改限制范围内，未经过认证机构、机身制造商或设备供应商的审查， 而进行修改的软件。

　　4 缩略语

　　下列缩略语适用于本文件。

　　COTS—commercial off-the-shelf，商用现货;

　　CPU—central processing unit，中央处理器;

　　CSC—computer software component，计算机软件部件;

　　CSCI—computer software configuration item，计算机软件配置项;

　　CSU—computer software unit，计算机软件单元;

　　FMECA—failure mode effects and criticality analysis，故障模式、影响及危害性分析;

　　FTA—Fault Tree Analysis，故障树分析。

　　5 要求

　　5.1 软件需求分析

　　5.1.1 软件需求分析的目标

　　软件需求分析的目标是依据软件的策划过程，基于系统要求和系统架构的分析，开发出软件的高层需求。软件高层需求包括功能需求、性能需求、接口需求和安全性相关的需求， 以及在系统安全性评估过程中明确派生的高层需求。

　　5.1.2 软件需求分析输入

　　5.1.2.1 总则

　　用于软件高层需求分析的输入，包括需求标准、分配给软件的系统需求、安全性相关要求、软硬件接口定义和系统架构。

　　5.1.2.2 需求标准

　　高层需求分析应满足以下要求：

　　a) 能够正确地体现软件产品具有的特性;

　　b) 确保软件需求实现;

　　c) 确保软件需求对于设计过程是足够完整的;

　　d) 确保每条需求描述详细、准确且无歧义性;

　　e) 确保分析的软件需求与更高层需求一致，可以满足更高层需求的目标;

　　f) 详细描述需求，以确保可以成为软件设计和测试的依据并具有可验证性;

　　g) 确保每条需求都有明确的出处并且便于跟踪、或被其他文档引用;

　　h) 标识对成本、进度、功能性、风险或性能有强烈影响的关键需求。

　　5.1.2.3 模型标准

　　模型标准定义了每种类型模型的建模技术。每种建模技术的定义应包括下列内容：

　　a) 用来开发模型的方法和技术;

　　b) 要使用的建模语言，对于每种建模语言，针对该模型所代表的软件生命周期数据的类型，对清晰定义该种语言语法和语义的数据进行引用。必要时，对该建模语言的某些功能进行限制使用说明;

　　c) 用于标识并限定模型中包含的需求的方法，以及在需求和其他生命周期数据之间建立可追溯性的途径;

　　d) 用于标识并限定模型中包含的派生需求方法，以及向系统流程(包括系统安全评估流程)提供这些派生需求的方法;

　　e) 用于标识无助于表示软件需求或软件架构，且不是后续软件开发流程或活动输入的每一个模型元素的方法;

　　f) 规范模型或设计模型所表述信息类别的技术适合性的依据。

　　5.1.2.4 分配给软件的系统需求

　　分配给软件的系统需求，用于确定该软件在任何可预见的运行条件下正确地执行其预定功能。一般应包括：

　　a) 功能和操作要求，包括功能描述和用户操作描述等;

　　b) 接口要求，包括内部接口和外部接口;

　　c) 性能要求，包括性能分析、时间和内存空间限制等;

　　d) 维护要求;

　　e) 设计约束，包括设计限制条件和分区要求等;

　　f) 数据安全性、保密性要求， 包括定义使用的各种数据，说明数据的约束;定义被采集数据的特性和要求和范围;

　　g) 认证要求，包括任何适用的认证机构规章和发行文件等;

　　h) 为软件生命周期过程提供帮助所需的附加要求。

　　5.1.2.5 安全相关要求

　　安全相关要求包括安全策略、设计限制条件和设计方法， 如分区、多版本非相似软件、冗余或安全性监控等。当该系统为另一系统组成部分时，另一系统的要求和失效条件也可作为系统安全性要求的一部分分配给软件。

　　安全相关要求一般由系统向下传递，或是系统在初步的安全性评估结果中获得的与软件相关的安全性需求，其中，也有少数是软件开发过程中新识别再由系统采纳下达的。

　　为了避免重复和遗漏，也可将领域经验提炼总结，形成专属领域的通用安全需求，通用安全需求会随着技术进化或新应用的实现而更新。

　　系统安全性要求的输入一般应包括：

　　a) 飞机级功能危害性评估报告;

　　b) 系统级初步的安全性评估报告;

　　c) 系统安全性工作计划等。

　　5.1.2.6 软硬件接口定义

　　软硬件接口定义了系统中软件与硬件之间的数据传递，一般应包括：

　　a) 硬件/软件集成所需的接口需求以及派生需求，如用于硬件和软件之间接口的协议、时序限制条件和解决方案的定义等;

　　b) 硬件和软件验证活动需要协调的情况。

　　5.1.2.7 系统架构

　　在系统的设计过程中确定系统架构，一般应包括：

　　a) 系统设计说明;

　　b) 系统总体设计要求;

　　c) 系统设计标准。

　　5.1.2.8 其他

　　在软件设计过程中，任何影响软件更改的用户要求或问题报告，均应作为软件需求分析的输入，并对设计进行迭代。

　　5.1.3 软件需求分析的一般要求

　　5.1.3.1 一般要求

　　高层需求包含软件需求以及派生需求。软件需求分析应满足以下要求：

　　a) 对每条分配给软件的系统需求，均需要在高层需求中进行定义、分解或说明， 包括与安全性有关的要求和潜在的失效状态;

　　b) 如果软件在多种状态或方式下运行，并且不同的状态或方式具有不同的需求，则标识和定义每种状态和方式，并描述每种状态或方式下的操作要求。状态和方式的示例包括正常、准备和紧急情况等;

　　c) 确保分析的高层需求符合软件需求标准，与分配给软件的系统需求一致，并且是可追踪和可验证的;

　　d) 标识对成本、进度、功能、性能、质量、风险或环境要求等方面有强烈影响的关键需求;

　　e) 描述高层需求的优先级，以标识其优先顺序;

　　f) 确保每条高层需求的描述详细、准确， 无歧义;如果发现有歧义、不一致或未定义的高层需求，需要迭代需求分析活动，或反馈至软件生命周期过程、分配给系统的软件需求， 直至高层需求完善，或取消有歧义、不一致的地方;

　　g) 如适用，软件的高层需求应采用含误差范围的定量术语陈述;

　　h) 定义派生的高层需求及其存在的原因;

　　i) 派生的高层需求需提交系统生命周期过程，包括系统安全性评估过程;

　　j) 除规定的合理设计约束外，高层需求不描述设计细节或验证细节。

　　5.1.3.2 基于模型方法的分析要求

　　在基于模型的需求分析中，高层需求表现为规范模型。采用基于模型的方法时，应满足以下要求：

　　a) 能详细描述功能、性能、接口或安全特性的抽象表征;

　　b) 从功能、行为和数据等多个视图分析需求， 对于显示系统中有用户界面的配置项，开发用户界面原型;

　　c) 采用软件故障树的方法对安全性需求进行分析;

　　d) 规范模型应足以支持设计模型的实现和验证。如：包含支持设计模型的开发和验证的详细信息的级别;提供软件功能的功能说明等;

　　e) 对规范模型的建模语言及工具使用定义指导原则和复杂度限制，例如：命名习惯、示意图布局、可允许的元素、嵌套级别最大数量、每个示意图的模型元素最大数量、架构层级的最大数量;

　　f) 对规范模型的建模工具及模型元素库的使用做出要求;

　　g) 对不描述软件需求且不作为后续软件开发工作输入的所有模型元素(例如注释块)进行标识;

　　h) 标识为完成或实现任何高层需求而派生的规范模型元素;

　　i) 在分析过程中，若发现系统需求存在缺陷时，有些模型也可以加添到系统需求中。

　　5.1.4 软件需求分析的具体要求

　　5.1.4.1 总则

　　应详细分析需求输入，对分配给软件的需求进行划分，分析划分的软件配置项之间如何交互，以及每个划分的软件配置项的级别，并将其转化为软件的功能、性能、接口、数据和软件安全性等方面的高层需求。

　　5.1.4.2 功能和性能

　　功能和性能需求分析应满足以下要求：

　　a) 确定与功能有关的所有信息，并按某种合适的结构组织功能需求，包括模式、对象、特征、激励和层次等;

　　b) 确定系统的容量要求，包括处理和记录数据的最大容量;

　　c) 确定系统的精度要求，包括数据传输的精度;

　　d) 确定系统的时间特性要求，包括处理时间和响应时间等。

　　5.1.4.3 内部接口

　　内部接口需求分析应包括：

　　a) 接口的优先级;

　　b) 接口的类型;

　　c) 接口需提供、存储、发送、访问和接受的数据元素特征;

　　d) 用于接口的通信方法;

　　e) 接口所需的协议。

　　一般情况下，软件的内部接口也可在设计时描述。

　　5.1.4.4 外部接口

　　外部接口需求分析应包括：

　　a) 与外部设备接口的需求分析，一般包括接口的优先级，接口类型的要求，软件应提供、储存、发送、读取、接受的各数据元素所要求的特征，和使用接口的通信方法;

　　b) 与其他系统的接口;

　　c) 确定人机界面和操作方法等用户接口。

　　5.1.4.5 数据处理

　　数据处理需求分析应满足以下要求：

　　a) 定义系统使用的各种数据;

　　b) 规定静态数据、动态输入输出数据;

　　c) 说明对数据元素的约束。

　　5.1.4.6 环境

　　环境需求分析应包括：

　　a) 硬件环境;

　　b) 软件环境。

　　5.1.4.7 安全性分析

　　安全性需求分析应根据系统安全相关要求的输入，查找关键安全功能，确定安全性需求。查找关键安全功能的方法主要有基于软件功能的 FTA 和FMECA。软件安全性分析应重点考虑以下内容：

　　a) 安全运行模式、运行状态和安全条件;

　　b) 容错和失效，包括失效状态及其影响、失效状态等级以及验证方法等;

　　c) 危险命令处理;

　　d) 分配给软件的功能研制保证等级;

　　e) 派生的安全性需求。

　　5.1.4.8 配置数据分析

　　某些安全关键系统会被设计为可配置的。此时， 应依据系统需求或配置文件设计规格说明来捕获配置数据的需求，并将配置数据的需求分析为一条或多条高层需求。一般应包括：

　　a) 确定配置数据的使用形式。包括现场可加载、用户可修改等;

　　b) 通过安全性评估，确定配置数据适用的软件级别;

　　c) 配置数据需包含的数据内容。包括激活或不激活的功能、建立时间和内存分区分配、为软件提供的初始值等。

　　5.1.4.9 可追溯性

　　应在分配给软件的系统需求和高层需求之间建立可追溯性，一般应包括：

　　a) 每条分配给软件的系统需求可追溯至一条或多条高层需求;

　　b) 除派生需求外，每条高层需求可追溯至至少一条分配给软件的系统需求。

　　注：若有配置数据需求，也应作为高层需求，追溯至分配给软件的系统需求。

　　基于模型开发的可追溯性与使用传统方法的开发的可追溯性要求相同。重点是划分基于模型的逻辑关系中的层级关系，建立各种模型元素之间的关联关系。也可将模型变为条目列表并进行跟踪管理。

　　5.1.5 软件需求分析输出

　　在软件需求分析的基础上，确定所开发软件的功能、性能、接口、数据、环境要求和约束条件， 并将需求文档化，来描述这些需求。

　　软件需求分析的输出应包括：

　　a) 软件需求规格说明或高层需求;

　　b) 软件高层需求与分配给软件系统需求之间的追踪关系;

　　c) 规范模型(若有);

　　d) 系统功能危害性评估报告。

　　5.2 软件体系结构设计

　　5.2.1 软件体系结构设计目标

　　软件体系结构设计的目标是根据软件的高层需求，定义出待开发软件的全貌，记录软件的重要设计决策，并指导之后的详细设计和实现工作。

　　5.2.2 软件体系结构设计输入

　　软件体系结构设计的输入包括软件高层需求、软件需求规格说明文档和软件设计标准。

　　若高层需求描述为规范模型，应提供以下数据作为输入：

　　a) 规范模型开发的需求依据;

　　b) 模型配置项(描述模型的文件或数据);

　　c) 软件建模技术的标准或规范;

　　d) 模型元素库;

　　e) 建模技术的开发环境和用户手册。

　　5.2.3 软件体系结构设计的一般要求

　　5.2.3.1 一般要求

　　软件体系结构设计应满足以下要求：

　　a) 准确地依据高层需求和派生的高层需求，如果发现有歧义、不一致或者未定义的地方，需要迭代软件设计活动，或反馈至软件生命周期过程、高层需求/派生的高层需求、分配给软件的系统需求，直至设计完善，或取消歧义和不一致的地方;

　　b) 可采用自顶向下或并发等方法进行;

　　c) 确保在现行软/硬件环境条件下是可行的;

　　d) 指明部件的层次特性(各部件间的控制关系和相互作用)和过程特性(部件间的时间关系和顺序关系);

　　e) 完整地描述每个部件的静态特征，一般包括：

　　1) 名称(标识符);

　　2) 作用(简要功能描述);

　　3) 类型(如进程/线程、临时/永久);

　　4) 位置(运行所在的处理机);

　　5) 特权(如对资源的访问特权);

　　6) 资源需求(如存贮页面、CPU、文件、公用区、同时占用的资源数);

　　7) 静态组织(即其下层的组成成份)。

　　f) 完整地描述每个部件的动态特征，一般包括：

　　1) 运行激活条件;

　　2) 初始化处理要求;

　　3) 运行优先级要求;

　　4) 输入信息(源、类型、格式、量化单位、值域、精度和周期);

　　5) 输出信息(目的地、类型、格式、量化单位、值域、精度和周期);

　　6) 部件的处理逻辑及其每个异常情况的处理要求;

　　7) 运行中的各种状态及其转换条件;

　　8) 部件间的通信关系;

　　9) 部件间的同步关系;

　　10) 运行终止条件。

　　g) 借助规范化的结构图，其中各种图形符号应使用标准符号、每个部件只能出现一次、一个决策的影响域应是其所在部件控制域的一个子集;

　　h) 按命名规则对配置项、部件、单元、接口数据和变量命名;

　　i) 所有已定义的元素(如 CSCI 、CSC、接口数据和变量等)均应被引用;所有被引用的元素均已

　　定义。

　　5.2.3.2 基于模型方法的要求

　　设计模型可以部分或全部表述软件体系结构和/或低层需求，采用基于模型的方法时，设计模型应满足以下要求：

　　a) 规定内部数据结构、数据流和控制流;

　　b) 对软件架构的描述，该软件架构可定义软件结构，以便实现需求;

　　c) 列出所有的系统需求和安全需求，确认每个预期操作的功能是否有对应的分解，每个非预计后果的保护功能是否也有对应的分解;

　　d) 对设计模型的建模语言及工具使用定义指导原则和复杂度限制，例如：命名习惯、示意图布局、可允许的元素、嵌套级别最大数量、每个示意图的模型元素最大数量、架构层级的最大数量;

　　e) 对设计模型建模工具使用及模型元素库的使用做出要求;

　　f) 标识为完成或实现任何软件体系结构而派生的设计模型元素。

　　5.2.4 软件体系结构设计的具体要求

　　5.2.4.1 总则

　　体系结构设计侧重选择软件质量属性的设计策略，确定设计模式，定义软件部件，设计软件接口(包括软件与外系统之间，软件与用户之间，以及软件部件与部件之间的接口)。使软件系统在架构层面的设计上满足功能性和非功能性的高层需求。

　　5.2.4.2 设计决策

　　设计决策通常包括分配至各个软件部件的需求分配方案，也包括在软件体系结构中使用 COTS 软件。

　　a) 方案应涵盖成本、进度和性能可接受的范围，方案选择应考虑以下因素：

　　1) 开发、维护和支持等成本;

　　2) 软件部件的复杂度;

　　3) 性能、技术约束和风险，如选定的算法/规则，对非法输入或条件的处理;

　　4) 对软件操作、使用条件、运行模式、环境等的健壮性;

　　5) 最终用户的能力和限制。

　　b) 选择 COTS 软件。COTS 软件可以直接使用或修改后使用。如果 COTS 软件的软件生命周期资料存在缺失，需补充相关资料才可使用。

　　c) 为满足安全性和保密性需求所选择的方法。以及为提供灵活性、可用性、可维护性等所选择的方法。如操作系统和开发语言的选择等。

　　d) 如果选择的硬件和操作系统支持分区，考虑最大限度地利用分区，以便于检测和隔离故障，减轻软件组件的验证负担。

　　5.2.4.3 结构分层

　　结构分层应满足下列原则：

　　a) 将部件按控制(调用)关系在逻辑上构成层次结构，软件结构的形态特征应呈树型结构;

　　b) 使高层有较高的扇出，低层有较高的扇入;

　　c) 下层处理的输出数据定义于其上层调用者，并受其控制;

　　d) 下层处理的控制返回至其上层调用者;

　　e) 下一层部件的处理独立于其上一层部件(调用者)。

　　5.2.4.4 部件设计

　　通常意义的部件是对软件有意义的分组，在面向对象中表现为类、包和子系统。每个部件应相对独立。设计时应满足下列要求：

　　a) 赋予每个软件部件唯一的标识符;

　　b) 可采用图标和描述来说明各软件部件间的动态关系，如部件的调用关系、控制流程、数据流图、状态转换图、时序图、活动图等。部件间调用不宜采用直接访问部件内部有关信息的方式;

　　c) 限制部件间传递的参数个数，控制交联关系。部件间的公用信息作为参数显式传递;

　　d) 部件的独立性应以提高其内聚度，降低耦合度来实现;

　　e) 部件/软件单元内的变量要局部化;

　　f) 将可能发生变化的因素或需经常修改的部分尽量放在少数几个部件中;

　　g) 说明软件部件的开发状态/类型，如新开发、重用已有部件或为重用而开发的部件等。针对重用的部件，说明其详细信息，如名称、版本、引用来源等。还该识别产生的派生需求和任何需停用的功能。

　　5.2.4.5 内部接口和数据设计

　　内部接口和数据设计应满足下列要求：

　　a) 详细定义部件间的所有接口数据;

　　b) 在各层次之间接口的存取和使用方式一致;

　　c) 按标准的表示法使用数据，按标准格式描述接口数据;

　　d) 以某一类型定义的数据在其使用全过程中始终保持类型不变;

　　e) 尽可能不用或少用全局数据;

　　f) 指明变量的定义域(值域)，必要时进行值域检查;

　　g) 在处理开始前，所有的输入均是可用的。

　　5.2.4.6 外部接口设计

　　外部接口设计应满足下列要求：

　　a) 确定软件与其他系统的接口，并说明对系统的要求;

　　b) 说明接口的目的、传输速率、要交换的数据、数据传输量、传输数据格式及其转换要求;

　　c) 在传输数据前，检测通信通道状态;

　　d) 对模拟和数字输入、输出信息作极限检测或合理性检测;

　　e) 设计硬件接口的软件时，对外部输入、输出设备做故障检测，并正确处理故障;

　　f) 在设计硬件接口的软件时，预定信息传输格式和内容，考虑接口元器件的故障模式;

　　g) 人机界面的交互方式应清晰、简明;

　　h) 合理设计警报、告警信息。

　　5.2.4.7 性能

　　对性能的设计应满足下列要求：

　　a) 尽量减少软件处理时间对资源的需求，包括采用适合的优化算法、控制队列长度等;

　　b) 尽量用多个线程并行处理事件，提高资源利用率;

　　c) 分区或模块中使用的任务在启动初始化时配置和创建。禁止动态创建任务;

　　d) 如需要，可定义事件优先级，合理调度资源。

　　5.2.5 软件体系结构设计的输出

　　根据软件高层需求，开发出软件体系结构，并将其文档化。软件体系结构设计的输出可能为：

　　a) 软件设计文档中架构设计部分的文档;

　　b) COTS 软件评价报告(如有);

　　c) 软件体系结构;

　　d) 设计模型(如适用)。

　　5.3 软件详细设计

　　5.3.1 软件详细设计目标

　　软件详细设计的目标是根据高层需求和定义的软件体系结构，开发软件的低层需求(包含派生的低层需求)，对每一个 CSU 进行设计，分析系统所采用算法的逻辑关系，并给出明确、清晰的表达， 为软件实现提供必要的说明。

　　5.3.2 软件详细设计输入

　　软件详细设计的输入应包括：

　　a) 软件的高层需求;

　　b) 软件的体系结构;

　　c) 软件的设计标准。

　　5.3.3 软件详细设计的一般要求

　　5.3.3.1 一般要求

　　软件详细设计应满足 4.2.3 的要求。对于每一个软件单元，详细设计信息描述应满足下列要求：

　　a) 输入/输出数据元素：标识该 CSU 的每一个输入和输出数据元素，并说明其用途，提供这些数据元素的设计信息;

　　b) 局部数据元素：标识该 CSU 内部产生的且不被其他 CSU 使用的每一个数据元素，并说明其用途。要描述每一个数据元素的名称、简要说明、数据类型、数据表示、大小、量纲、限值/值域、精度、分辨率以及任何其他属性，可以通过 CSC 局部数据表来描述这些信息;

　　c) 中断和信号：标识该 CSU 处理的中断和信号，并说明其来源、目的、优先级、期望响应和响应时间、最大值、最小值和发生的概率;

　　d) 算法：标识算法，并描述其目的和细节。算法的描述应包括对输入和内部数据元素的处理以及输出数据元素的生成;

　　e) 错误处理：标识和描述 CSU 的错误诊断和恢复功能，包括对错误的输入数据和影响 CSU 执行的其他条件的处理;

　　f) 数据转换：标识和描述为实现 CSU 的接口需实现的数据转换操作;

　　g) 其他元素的使用。描述 CSU 使用的其他元素，它包括但不限于：

　　1) 其他 CSU(如库函数调用、访问数据库、海量存储设备和实时 I/O 通道的I/O 服务调用);

　　2) 全局内存中的共享数据(如数据库或数据文件、表、公用数据块);

　　3) 输入输出缓冲区，包括消息缓冲区。

　　h) 逻辑流程。根据 a)到 g)项内容描述 CSU 的逻辑流程。应描述启动 CSU 执行的条件、被激活的通信接口功能(如有)、把控制传给其他 CSU 的条件等。如果在 CSCI 的操作期间，执行顺序是动态控制的，则应描述顺序控制的方法以及该方法的逻辑和输入条件，如定时变更、优先级分配、内部存储器的数据移入移出的内部操作、离散输入信号的判读以及 CSCI 的各种操作之间的定时关系;

　　i) 数据结构。描述 CSU 实现的局部数据结构以及 CSU 使用的所有共享数据结构;

　　j) 局部数据文件或数据库。如果数据文件或数据库是 CSU 的局部数据的一部分，则说明其用途，

　　并用记录、字段等描述其结构，还要说明其访问机制(如顺序的、随机的);

　　k) 局限性：描述限制 CSU 性能的任何局限性或独特功能;

　　l) 定义和分析派生的低层需求及其存在的原因，以确保不会影响较高级别的需求;

　　m) 软件设计活动可能将故障模式引入到软件中，也可能防止某些故障模式。在软件设计中使用划分或者其他架构方法可能会改变软件的某些组件的软件级别分配。在这种情况下，将其他数据作为派生的低层需求定义并提供给系统流程(包括系统安全评估流程);

　　n) 定义其他派生的低层需求并向系统流程提供(包括系统安全评估流程)。

　　5.3.3.2 基于模型方法的要求

　　采用基于模型的方法时，用于描述软件体系结构和/或低层需求的设计模型，除了应满足 4.2.3.2的要求外，还应满足下列要求：

　　a) 对软件如何满足规定的高层需求(包括算法、数据结构、以及如何将软件需求分配到处理器和任务)的详细描述;

　　b) 输入/输出描述，例如：数据词典，包括贯穿软件架构的内部和外部词典;

　　c) 设计模型的数据流和控制流;

　　d) 资源限制、用于管理每项资源及其限制的策略、测量的方法，如计时和内存;

　　e) 调度步骤及处理器/任务间通讯机制，包括时间排序、抢先调度和及中断;

　　f) 设计方法及实现这些方法的细节，如软件加载、用户可修改软件或多版本非相似软件;

　　g) 划分方法及防止违背划分的途径;

　　h) 对软件组件的描述，这些组件是新组件还是此前开发的，如果是此前开发的，可参照取得这些组件的基线;

　　i) 分析由软件设计流程导致的派生的低层需求;

　　j) 标识为完成或实现任何软件低层需求而派生的设计模型元素;

　　k) 如果设计模型描述了低层需求和/或架构，则标识没有描述系统需求或软件架构并且并非后续软件开发流程或活动的输入的所有模型，如注释块;

　　l) 某些设计决策可追溯至与安全有关的系统需求的理论依据。

　　5.3.4 软件详细设计的具体要求

　　5.3.4.1 完整性

　　软件详细设计的完整性应满足下列要求：

　　a) 每条高层需求，都应定义、分解或说明为软件低层需求;

　　b) 有充分的资料(如逻辑结构图、算法、存贮分配图等)保证设计的完整性;

　　c) 算法和公式等要充分、准确和完善;

　　d) 标识出程序的每一个输入、输出或数据库成份;其描述应达到可编码的程度;

　　e) 说明程序的操作步骤和处理步骤;

　　f) 考虑到所有可能的情况和条件;

　　g) 指明在出现异常情况和不正当输入的情况下的行为。

　　5.3.4.2 一致性

　　软件详细设计的一致性应满足下列要求：

　　a) 不能包含内在的矛盾;

　　b) 计算中的输入、输出和数据库数据的计量单位、计算精度和逻辑表达式一致;

　　c) 对失效状态的响应与安全性相关的需求保持一致。

　　5.3.4.3 正确性

　　软件详细设计的正确性应满足下列要求：

　　a) 逻辑准确;

　　b) 与模型、算法和数值定义一致;

　　c) 正确实现上层所确定的输入、输出和数据库所含的数据格式、内容和数据率。

　　5.3.4.4 可行性

　　软件详细设计的可行性应满足下列要求：

　　a) 所设计的模型、算法和数值定义对于应用领域是可接受的;

　　b) 设计能在规定的开发成本、进度和其他限制条件下实现;

　　c) 在可用的资源条件下，所设计的功能是能实现的。

　　5.3.4.5 健壮性

　　软件详细设计的健壮性应满足下列要求：

　　a) 设计覆盖高层需求中所要求的容错和故障处理的需求，减轻故障造成的后果;

　　b) 判定所有错误情况，并告警和记录。涉及并发进程的错误检测应做到： 在等待某一进程结束之前，检测该进程是否已启动或已超时。不必等待已终止进程的结束。

　　5.3.4.6 安全性

　　软件详细设计过程会引入一些可能的失效模式，同时，也可能阻止另一些失效模式。在软件设计中采用分区或其他体系架构方法，可能会改变某些软件部件的软件等级。这种情况下， 应定义额外的派生需求，并进行系统安全性评估。

　　当安全性需求提出诸如看门狗定时器、合理性检查和交叉通道比较等要求时， 应对控制流和数据流进行监控。

　　5.3.4.7 测试性

　　软件详细设计的测试性应满足下列要求：

　　a) 设计中对每一个函数的描述都使用准确的术语和符号;可验证它与需求定义是否一致;

　　b) 定量地说明使用条件、限制和处理结果等内容。

　　5.3.4.8 复杂性

　　软件详细设计的复杂性应满足下列要求：

　　a) 谨慎使用中断嵌套，使用时进行状态保护;

　　b) 谨慎使用循环控制语句，避免出现死循环，中断服务程序避免出现超时;

　　c) 尽量避免使用 C 语言中的无条件分支。但有时无条件分支也会被用于执行某些关键处理，如致命的错误处理;

　　d) 模块的圈复杂度一般不大于 10;

　　e) 每个模块传递的参数个数一般不超过 6 个;

　　f) 模块的扇入和扇出一般不大于 7;

　　g) 如果超出以上要求，可以用分析报告的方式进行说明，不存在安全隐患。

　　5.3.4.9 模块化

　　软件详细设计的模块化应满足下列要求：

　　a) 采用模块化的结构。使部件由一些较小的、以层次结构相互联系的软件单元组成;

　　b) 设计使用特殊的规则来限制软件单元的规模(复杂度、代码行数);

　　c) 每个软件单元只有一个入口和一个出口;

　　d) 以数据流、控制流的形式表示的软件模块接口保证模块间的一致性。

　　5.3.4.10 内存管理

　　5.3.4.10.1 动态内存管理

　　使用动态内存管理应防止出现以下问题：

　　a) 内存泄漏：为对象分配了内存空间，但却从未使用，从而造成内存泄漏;

　　b) 内存不足：由于逻辑上可用的连续空闲内存不足，分配请求可能失败;

　　c) 释放不足：分配请求可能由于未引用内存(如：对象或结构)的回收不足而失败，这也可能是由于丢失引用造成的;

　　d) 堆内存耗尽：同时申请的堆内存需求可能超过可用内存;

　　e) 过早释放：当对象仍需使用的时候，内存空间已被释放。

　　5.3.4.10.2 共享内存管理

　　使用共享内存管理应注意以下问题：

　　a) 建立共享内存互斥访问机制;

　　b) 对共享内存边界进行校验，防止共享内存的大小超过限制;

　　c) 禁止低安全性等级操作高安全性等级的共享内存。

　　5.3.4.11 异常管理

　　应定义抛出异常的情况、捕获异常的情况以及异常处理。如越界检测、除 0 检测，前/后置条件检测。将异常视为需求的一部分，并检查可替换性。

　　5.3.4.12 数据处理规则

　　数据处理规则应满足下列要求：

　　a) 先定义(赋值)后使用。如初始化数据、计算数据、从上层输入的数据在其使用前赋予定义;

　　b) 数据的量化单位一致;

　　c) 避免使用全局数据。

　　5.3.4.13 控制规则

　　控制规则应满足下列要求：

　　a) 软件错误的密度随软件复杂性的增加而增大。为了减少每个软件单元的复杂性， 使选择和迭代的嵌套层数最少;

　　注：选择是比顺序更复杂的结构;迭代是比选择更复杂的结构;如果有两条路径，则总的复杂性是每条路径复杂性之和;对于一条给定路径，其复杂性随该路径每一部分的复杂性的增长而急速增大，路径复杂性等于该路径各部分复杂性的乘积。

　　b) 对关键功能的控制有反馈机制，反馈功能正常或异常结果;

　　c) 禁止递归。

　　5.3.4.14 命名规则

　　命名规则应满足下列要求：

　　a) 函数和数据的名称是有意义的和描述性的，并且通常应包含描述动作;

　　b) 术语的定义连贯一致，避免在同一设计文档中使用同义词以不同名称描述同一活动，而导致重

　　复的设计;

　　c) 类型的名称反映该类型数据的性质。输入和输出参数的名称依据相关软件的高层需求;

　　d) 设计文件中使用的缩写来自缩略语列表。

　　5.3.4.15 可追溯性

　　在低层需求和高层需求之间应建立可追溯性;

　　a) 每条高层需求可追溯至一条或多条低层需求;

　　b) 除派生需求外，每条低层需求可追溯至至少一条高层需求。

　　基于模型开发的可追溯性与使用传统方法的开发的可追溯性要求相同。可将模型变为条目列表， 进行跟踪管理。如： 需求中的用例和设计中组件的实现关系。也可基于模型生成各类文档， 将文档关联到模型上。

　　5.3.5 软件详细设计输出

　　根据软件高层需求和软件体系结构，开发软件低层需求，并将其文档化。软件详细设计的输出可能为：

　　a) 软件低层需求或软件设计说明文档(包含软件体系结构和低层需求);

　　b) 软件低层需求与软件高层需求之间的追踪关系;

　　c) 设计模型(如适用)。