DO-178C解读 - 软件配置索引（1）

本文件是 NASA 兰利研究中心进行的制导与控制软件 (GCS) 项目的一部分。 尽管制导与控制软件应用程序的一些需求源自 NASA 维京火星任务，但本文档不包含来自实际 NASA 任务的数据。

This document was produced as part of Guidance and Control Software (GCS) Project conducted at NASA Langley Research Center. Although some of the requirements for the Guidance and Control Software application were derived from the NASA Viking Mission to Mars, this document does not contain data from an actual NASA mission.

附录B：制导与控制软件项目软件配置索引Appendix B: Software Configuration Index for the Guidance and Control Software Project

（包括软件生命周期环境配置索引）

(includes the Software Life Cycle Environment Configuration Index)

作者：Laura J. Smith 和 Kelly J. Hayhurst，美国宇航局兰利研究中心

Authors: Laura J. Smith and Kelly J. Hayhurst, NASA Langley Research Center

B.1 引言Introduction

软件配置索引（SCI）充当制导软件（GCS）项目配置控制下项目配置的主列表。 软件生命周期环境配置索引（SECI）标识软件生命周期环境的配置。 本文档包含分别在 DO-178B 第 11.16 和 11.15 节中描述的软件配置索引和软件生命周期环境配置索引。The Software Configuration Index (SCI) functions as a master list for the configuration of items under configuration control for the Guidance and Control Software (GCS) project. The Software Life Cycle Environment Configuration Index (SECI) identifies the configuration of the software life cycle environment. This document contains both the Software Configuration Index and the Software Life Cycle Environment Configuration Index as described in sections 11.16 and 11.15 of DO-178B, respectively.

软件配置索引标识软件产品的配置。 SCI 应确定以下内容：The Software Configuration Index identifies the configuration of the software product. The SCI should identify the following:

• 软件产品the software product;

• 可执行目标码executable object code;

• 每个源码组件each source code component;

• 软件生命周期数据software life cycle data;

• 存档和发布媒介chive and release media;

• 构建可执行目标码的说明instructions for building the executable object code;

• 用于恢复软件以进行重新生成、测试或修改的程序procedures used to recover the software for regeneration, testing, or modification;

• 如果单独打包，请参考软件生命周期环境配置索引reference to the Software Life Cycle Environment Configuration Index if packaged separately; and

• 可执行目标代码的数据完整性检查（如果使用）data integrity checks for the executable object code, if used.

GCS 在线文件的配置管理由 DEC 代码管理系统 (CMS) 辅助（参考 B.1）。 有关此项目期间如何使用 CMS 的更多信息，请参阅软件配置管理计划。 GCS 项目中使用的工具的完整列表可以在本文档的软件生命周期环境部分中找到。Configuration management for on-line files for GCS is aided by the DEC Code Management System (CMS) (ref. B.1). For more information on how CMS is being used during this project, refer to the Software Configuration Management Plan. A complete list of tools used in the GCS project can be found in the Software Life Cycle Environment section of this document.

B.2 软件产品Software Product

就 GCS 项目而言，软件产品是指可执行目标码、每个源码组件以及软件生命周期数据。 以下部分更详细地描述了软件产品的每个组件。For the purpose of the GCS project, the software product refers to executable object code, each source code component, and the software life cycle data. The following sections describe each component of the software product in further detail.

B.2.1 可执行目标码Executable Object Code

在开发的集成阶段完成之前，可执行目标码不会置于配置控制之下。 对于集成阶段期间的所有测试，将从 CMS 获取源代码，并将按照软件验证程序中的定义生成可执行目标码。 所有测试完成后，将使用每个实现的适当构建文件生成可执行目标码（请参阅“构建可执行目标码的说明”部分），并将其放置在指定的 CMS 库中（请参阅表 B.3）。The executable object code will not be placed under configuration control until the integration phase of development is complete. For all of the testing during the integration phase, the source code will be fetched from CMS and the executable object code will be generated as defined in the Software Verification Procedures. Once all testing is complete, the executable object code will be generated using the appropriate build files for each implementation (see section “Instructions for Building Executable Object Code”) and placed in the designated CMS library (see Table B.3).

B.2.2 源码组件Source Code Components

该项目正在独立开发 GCS 的两个实施方案（称为 Mercury 和 Pluto）。 表 B.1 列出了 Mercury 的源代码组件，表 B.2 列出了 Pluto 的源码组件。 每个实现都有自己的 CMS 库，该库位于 VMS 目录 DISK$HOKIE:[GCS.CMS.SOURCE_CODE.planet] 中，其中planet 指的是 Mercury 或 Pluto。 每个实现的各个源代码组件都位于该库中。Two implementations (referred to as Mercury and Pluto) of the GCS are being developed independently for this project. Table B.1 lists the source code components for Mercury and Table B.2 lists the source code components for Pluto. Each implementation has its own CMS library which is located in the VMS directory DISK$HOKIE:[GCS.CMS.SOURCE_CODE.planet] where planet refers to Mercury or Pluto. The individual source code components are located in this library for each implementation.

Table B.1: Mercury Source Code Components

Library: DISK$HOKIE:[GCS.CMS.SOURCE_CODE.MERCURY]
aeclp.for	arsp.for
asp.for	common.inc
cp.for	crcp.for
excond.inc	gp.for
gsp.for	mercury.for
param.inc	reclp.for
tdlrsp.for	tdsp.for
tsp.for

Table B.2: Pluto Source Code Components

Library: DISK$HOKIE:[GCS.CMS.SOURCE_CODE.PLUTO]
aeclp.for	arsp.for
asp.for	clpsf.for
constants.for	cp.for
crcp.for	external.for
gp.for	gpsf.for
gsp.for	guidance_state.for
pluto.for	reclp.for
run_parameters.for	sensor_output.for
spsf.for	tdlrsp.for
tdsp.for	tsp.for
utility.for

B.2.3 软件生命周期数据Software Life Cycle Data

对于 GCS 项目，配置管理的总体计划是使用兰利已有的一套软件工具和一些纸质表格来识别、控制、基线和归档与 GCS 实施开发相关的所有生命周期数据 。 表 B.3 列出了 DO-178B 指南第 11 节中讨论的 GCS 项目的生命周期数据以及项目所需的其他生命周期数据。 该生命周期数据由规划和支持文档以及软件开发过程中的实际产品（例如设计描述和源代码）组成。 配置管理负责维护整个 GCS 项目中对此生命周期数据所做的所有更改。For the GCS project, the general plan for configuration management is to use a set of software tools, already available at Langley, and some paper forms to identify, control, baseline, and archive all life cycle data associated with the development of the GCS implementations. Table B.3 gives a list of the life cycle data for the GCS project as discussed in Section 11 of the DO-178B guidelines plus additional life cycle data as required by the project. This life cycle data consists of planning and support documents and the actual products from the software development process (e.g., design description and source code). Configuration management is responsible for maintaining all changes made to this life cycle data throughout the GCS project.

Table B.3. Life Cycle Data for the GCS Project

Software Life Cycle Data	Configuration Item	Storage Medium(a)
Plan for Software Aspects of Certification Software Development Plan	Plan for Software Aspects of Certification	CERT_PLAN
Software Verification Plan	Verification Plan Software Requirements Traceability Data	VER_PLAN TRACE_DATA
Software Configuration Management Plan	Configuration Management Plan	CM_PLAN
Software Quality Assurance Plan	Software Quality Assurance Plan	SQA_PLAN
Software Requirements Standards Software Design Standards Software Code Standards	Software Development Standards	DEV_STAND
Software Requirements Data	GCS Specification	SPEC
Design Description	Teamwork Model* Design Overview*	DES_DESCRIP.planet
Source Code	Source Code*	SOURCE_CODE.planet
Executable Object Code	Executable Object Code*	EXEC_OBJ_CODE.planet
Software Verification Cases and Procedures	Verification Cases* Verification Procedures	VER_CASES VER_PROC
Software Verification Results	Verification Results*	VER_RESULTS.planet
Software Life Cycle Environment Configuration Index; Software Configuration Index	Configuration Index	CONFIG_INDEX
Problem Reports	Problem and Action Reports* Support Document Change Reports Formal Modifications to the Specification(b)	paper forms paper forms SPEC_MODS
Software Configuration Management Records	Configuration Management Records*	paper forms
Software Quality Assurance Records	Software Quality Assurance Records*	paper forms
Software Accomplishment Summary	Software Accomplishment Summary	ACCOMP_SUM
Simulator User's Guide	Simulator User's Guide	SIMULATOR.USER_GUID E
Simulator Source Code	Simulator Source Code	SIMULATOR.SOURCE_C ODE

(a) 所有 CMS 库均位于 DISK$HOKIE:[GCS.CMS.xxx] 中，其中 xxx 是在存储介质下指定的。All CMS libraries are located in DISK$HOKIE:[GCS.CMS.xxx] where xxx is specified under storage medium.

(b) GCS 规范的正式修改 2.2-1 至 2.2-26 未记录在支持文档变更报告 (SDCR) 中。 对 GCS 规范的所有剩余修改都将记录在 SDCR 表格中。Formal modifications 2.2-1 through 2.2-26 of the GCS Specification were not recorded in Support Documentation Change Reports (SDCR). All remaining modifications to the GCS Specification will be recorded on an SDCR form.

* 这些配置项将特定于实现，标签应酌情引用实现。These configuration items will be implementation specific, the labels should refer to the implementation as appropriate.

B.2.4 存档和发布媒介chive and Release Media

GCS 项目使用 CMS 进行配置管理的项目在运行 VMS 操作系统的 DEC VAX 集群上保持在线。 下面介绍本系统的备份，以保证数据的完整性：The items under configuration management using CMS for the GCS project are kept on-line on a DEC VAX cluster, running the VMS operating system. The following describes the backups of this system to ensure the integrity of the data:

• 系统上所有项目的完整备份将每周执行一次；a full backup of all items located on the system will be performed once a week;

• 每个完整备份磁盘会制作一个副本，并存储在物理上独立的档案中，以尽量减少发生灾难时丢失的风险；a duplicate copy will be made of each full backup tape and stored in a physically separate archive to minimize the risk of loss in the event of a disaster;

• 不得对任何备份磁盘进行未经授权的更改；no unauthorized changes can be made to any of the backup tapes;

• 将验证所有磁盘是否存在再生错误（通过使用备份/验证命令）；all tapes will be verified for regeneration errors (by using the backup/verify command);

• 增量备份每天运行一次，周期为四个星期，以减少丢失任何信息的可能性。incremental backups are run on a daily basis for a four week cycle to lessen the probability of losing any information.

执行完整备份后，将制作磁盘的副本。 复制时会验证复制磁盘，以确保生成准确的副本。 GCS项目的组件将在集成测试完成后授权向认证机构发布。 所有数据将被存档以供将来参考。After a full backup has been performed, a duplicate copy of the tape will be made. The duplicate tapes are verified when copied to ensure that accurate copies have been produced. The components of the GCS project will be authorized for release to the certification authority after the integration testing has been completed. All data will be archived for future references.

由于问题报告和支持文档变更报告不是以电子方式保存的，因此配置管理器会将它们存档在活页夹中。 只有经过 SQA 代表批准并签署的 PR 和 SDCR 才会被存档。 每个实施都会有单独的活页夹，标有“星球问题报告”和“变更报告”。 SDCR 按配置项组织。 有关活页夹的更多详细信息，请参阅软件配置管理计划中的“配置状态统计”部分。Since Problem Reports and Support Documentation Change Reports are not kept electronically, they will be archived in a binder by the configuration manager. Only PRs and SDCRs that have been approved and signed by the SQA representative will be archived. There will be separate binders labeled "Problem Reports for Planet", for each implementation, and “Change Reports”. The SDCRs are organized by configuration item. See the section on "Configuration Status Accounting" in the Software Configuration Management Plan for more details on the binders.

B.2.5 构建可执行目标码的说明Instructions for Building the Executable Object Code

每个实现的程序员负责包含有关如何将所有源代码元素链接在一起才能运行文件的指令的文件。 Mercury 构建文件是mercury_compile.txt。 Pluto 构建文件是 list_of_routines.txt。 每个构建文件都存储在各自的 CMS 库 DISK$HOKIE:[GCS.CMS.SOURCE_CODE.planet] 中。 附录 B 中给出了每个构建文件的副本。The programmer for each implementation is responsible for the file that contains instructions for how all of the source code elements must be linked together in order to run the files. The Mercury build file is mercury_compile.txt. The Pluto build file is list_of_routines.txt. Each build file is stored in their respective CMS libraries, DISK$HOKIE:[GCS.CMS.SOURCE_CODE.planet]. A copy of each build file is given is Appendix B.

B.2.6 用于恢复软件以进行重新生成、测试或修改的过程Procedures Used to Recover the Software for Regeneration, Testing, or Modification

当配置管理器请求配置项时，它会被放置在 VMS 目录中。 然而，并非所有项目的生命周期数据都是在 VAX 系统上开发或修改的。 例如，大多数规划和支持文档是在 Macintosh 上使用 Microsoft Word 开发的，而实施设计是使用在 SUN 工作站上运行的名为 Teamwork 的工具开发的。 需要一些特殊说明来确保所有项目数据都可以重新生成和修改。 以下小节描述了将文件传输到 VMS 目录或从 VMS 目录传输为其本机格式的过程。When a configuration item is requested from the Configuration Manager, it is placed in a VMS directory. However, not all of the project’s life cycle data is developed or modified on the VAX system. For example, most of the planning and support documentation is developed using Microsoft Word on a Macintosh, and the implementations’ designs are developed using a tool called Teamwork that runs on a SUN workstation. Some special instructions are needed to ensure that all project data can be regenerated and modified. The following subsections describe the procedures for transferring files to/from a VMS directory to their native format.

B.2.6.1 文本文档说明Instructions for Text Documents

大多数规划文档都是使用Microsoft Word 开发的，并且可以使用FTP 工具将这些文档传输到VAX 进行配置管理。 该文档必须传输到名为 AIR19 的 VAX 系统上的相应目录（所有项目成员都将在该系统上拥有有效帐户）。 使用 FTP 传输 Microsoft Word 文档时，必须选择“Image”和“MacBinary”选项，以确保文档可以重新生成为 Word 文档。Most of the planning documents are developed using Microsoft Word and these documents can be transferred to the VAX for configuration management using the FTP tool. The document must be transferred to the appropriate directory on the VAX system called AIR19 (all project members will have a valid account on this system). When transferring a Microsoft Word document using FTP, the options Image and MacBinary must be selected to ensure that the document can be regenerated as a Word document.

B.2.6.2 团队合作模型说明Instructions for Teamwork Models

如上所述，Teamwork 工具（在 SUN 工作站上运行）用于开发和修改每个实现的设计描述。 准备用于配置管理的 Teamwork 模型涉及从 Teamwork 数据库中提取模型并将结果文件正确传输到 AIR19。 团队合作模型可以是完整的，也可以是增量的。 一个完整的模型包含它自己的所有对象； 也就是说，它是独立的，因此称为“完整”。 增量模型仅记录对存储在其他模型中的对象所做的修改； 它不是独立的。 GCS 项目配置管理下的所有 Teamwork 模型都将是完整模型。 归档增量模型时，增量模型以及所有引用的模型必须作为一个单元进行归档，以保留重建增量模型的能力。As stated above, the Teamwork tool (running on a SUN workstation) is used to develop and modify the design description for each implementation. Preparing a Teamwork model for configuration management involves extracting the model from the Teamwork database and properly transferring the resulting file to AIR19. Teamwork models are either complete or incremental. A complete model contains all of its own objects; that is, it is self-contained, hence the term complete. An incremental model records only modifications made to objects stored in some other model; it is not self-contained. All Teamwork models under configuration management for the GCS project will be complete models. When archiving an incremental model, the incremental model as well as all referenced models must be archived as a unit in order to preserve the ability to reconstruct the incremental model.

Teamwork 的“模型流程索引”显示的第二列指示模型是完整的还是增量的。 在准备用于配置管理的团队合作模型时，如有必要，请首先完成模型。The second column of the Teamwork's "Model Processes Index" display indicates if a model is complete or incremental. When preparing a Teamwork model for configuration management, first complete the model if necessary.

模型完成后，将调用“dump_tsa”实用程序将 Teamwork 模型从 Teamwork 数据库提取到转储文件中。 转储文件只是特定格式的操作系统文件。 创建模型的转储文件后，应将“转储”文件传输到 AIR19。 FTP 实用程序提供了一种传输转储文件的便捷方法。 请注意，必须使用 FTP 的二进制模式才能保持文件完整性。Once the model is completed, the "dump_tsa" utility is invoked to extract the Teamwork model from the Teamwork database into a dump file. A dump file is merely an operating system file in a specific format. Once a dump file for the model has been created, the "dump" file should be transferred to AIR19. The FTP utility provides a convenient means for transferring the dump file. Note, the binary mode of FTP must be used in order to preserve the file integrity.

从配置管理请求 Teamwork 模型进行测试或修改后，可以使用 FTP 实用程序将 Teamwork 模型从 AIR19 传输到加载了 Teamwork 的计算机。 应调用 ftp 的二进制模式。 一旦包含 Teamwork 模型的文件驻留在计算机上，应使用“load_tsa”实用程序将转储文件加载到 Teamwork 中。After requesting the Teamwork model from configuration management for testing or modification, the FTP utility can be used to transfer the Teamwork model from AIR19 to the machine which has Teamwork loaded. The binary mode of ftp should be invoked. Once the file containing the Teamwork model resides on the machine, the "load_tsa" utility should be used to load the dump file into Teamwork.

B.2.6.3 源代码和测试用例说明Instructions for Source Code and Test Cases

源代码和测试用例是在 VAX 或 SUN 上创建的，具体取决于参与者工作站。 对于在 SUN 上创建源代码或测试用例的情况，文件通过 FTP 实用程序传输到 AIR19（开发工作站）进行编译、链接、执行等。在将文件存储在 内容管理系统。The source code and test cases are created either on a VAX or on a SUN, depending on the participants workstation. For those cases where source code or test cases are created on the SUN, the files are transferred to AIR19 (the development workstation) via the FTP utility for compilation, linking, executing, etc. No special conversion instructions are necessary before storing the files in CMS.

B.2.6.4 配置项的原生格式Native Format of Configuration Items

表 B.4 显示配置项及其在 CMS 库中存储的格式（如果适用）。 部分配置项仅以纸质形式保存； 这些将被存档并可供将来参考。Table B.4 shows the configuration items along with the format in which they are stored in the CMS libraries, if applicable. Some of the configuration items are only kept in paper form; these will be archived and available for future references.

Table B.4: Native Format of Configuration Items

Configuration Items	Format
Plan for Software Aspects of Certification	Microsoft Word
Verification Plan	Microsoft Word
Software Requirements Traceability Data	Microsoft Word
Configuration Management Plan	Microsoft Word
Software Quality Assurance Plan	Microsoft Word
Software Development Standards	Microsoft Word
GCS Specification	Microsoft Word
Teamwork Model	Teamwork
Design Overview	Microsoft Word
Source Code	FORTRAN
Executable Object Code	VMS Executable Image
Verification Cases	models: Mathematica test cases: ASCII
Verification Procedures	Microsoft Word
Verification Results	Microsoft Word
Configuration Index	Microsoft Word
Problem and Action Reports	paper
Support Document Change Forms	paper
Formal Modifications to the Specification	Microsoft Word
Configuration Management Records	paper
Software Quality Assurance Records	paper
Software Accomplishment Summary	Microsoft Word
Simulator User's Guide	Microsoft Word
Simulator Source Code	FORTRAN