本书以民用航空机载软件适航标准制定者的视角，详细介绍了如何基于目前最新版的DO-178C标准进行安全关键软件的开发与管理，给出了如何获得成功审定的实用指南。主要内容包括：在系统与安全大视野中的软件，DO-178C标准的深入解读和推荐实践，4个标准技术补充（软件工具鉴定、基于模型的开发、面向对象技术和形式化方法）的讲解说明，以及10个相关特别专题（未覆盖代码、外场可加载软件、用户可修改软件和实时操作系统等）的指导建议。

专家荐语： “Rierson女士从自己的经验和大量项目中提炼出一本简明易懂的书……该书的出众之处在于诚挚、务实的建议，以及对各个DO-178C目标的透视。如果项目认真借鉴她的指南，并从起点开始实现，就肯定能比“打勾式项目”花费更小的成本，制造出更安全的软件。” —— Wendy Ljungren 通用电气航空 “……任何从事机载系统开发、验证或审定的人员的必读书……本书对于在RTCA DO-178C及其相关文件的指导下开发软件密集的航空系统的过程，给出了非常清晰又相对简明的解释。本书是一件出色的作品，用非常实际的“要怎样做”和“不要怎样做”提供了必要的基础。” —— Andrew J. Kornecki 安柏瑞德航空大学教授 “本书出自一位博学的管理者和实践者的出色研究和经验……它使用易于理解的术语，精炼而准确地解释了规章中给出的指南……其结果是一本令人难以释卷的著作。” —— George Romanski Verocel公司总裁 随着软件复杂性和关键性的增长，以及项目被迫以更快速度和更低成本开发软件，保证软件密集系统的可靠和安全尤为重要。本书可为你提供有效和高效开发安全关键航空软件所需的信息。这些原则也适用于其他安全关键领域。 本书作者以近30年的安全关键软件经验为背景，总结出了丰富的优秀实践和具体建议。本书是软件和系统管理者、开发者，以及质量保证人员的宝贵参考，能够帮助你更自信地开发、管理或审定安全关键软件。 译者序 安全关键软件（safety-critical software）是指应用于航空、航天、交通、能源、医疗、军事等领域，其运行情况会影响到人身和设施安危的软件系统。该类软件无疑应当被投以格外的关注、施以有效的方法，为追求“万无一失”而极尽所能。 在这一目标下，基于“高质量的过程产生高质量的产品”这一理念，出现了一系列“以过程为中心”的软件工程方法、标准和实践，广为人知的“能力成熟度模型集成（CMMI）”与本书将要介绍的“民用航空机载软件适航标准（DO-178）”均属此列。CMMI影响之大自不待言，而DO-178的成熟和成功同样卓著。实际上可以说在近30年以来，每个有过飞行经历的人都已在不知不觉中，获得过包含DO-178一份贡献的安全保障。 DO-178是民用航空领域用于保证机载软件符合飞行安全要求（即“适航性”）的规范性文件，它由美、欧航空组织建立，已成为在全球航空领域（包括中国）得到广泛认可和使用的事实标准。该系列标准起始于20世纪80年代初，最新版本（DO-178C）于2011年12月发布。DO-178C继承了上一版本（DO-178B）的主体，这本身就是对上一版本自1992年开始将近20年成功运用的最好肯定。新版在概念和结构的清晰性、与系统过程和新技术发展的协调性方面进行了积极有益的改进，将会进一步提升其实践的效能。 DO-178C在作用和思想上与CMMI（以及类似或等同的标准）有一定的相近性，但在另一些方面又存在实质性的不同。CMMI最终评判的是一个组织（企业）的“能力”；DO-178C最终评判的是一个产品（项目）是否合格。CMMI涵盖工程活动和辅助活动、项目管理、过程管理；DO-178C聚焦于工程及其直接相关的管理活动。此外，即使在二者的交集上，DO-178C的特色也十分突出。CMMI是一个“模型”（“框架”），以抽象原则为主（除了明确的“目标”和“实践”），没有强制性的特定做法，更不提供系统化的实施途径。这种方式为实践者针对具体情况创造具体方法保留了灵活性，但是也时常令一些实施者和评价者无所适从。与之不同的是，DO-178C从头到脚都极具实践性、操作性，它所规定的每一件事、每一个要求都更直截了当、更清晰明确，此外还尽可能地针对各种可能用到的新技术和特殊技术，给出专门的使用指导和要求。这种方式体现了一个高安全领域对产品近似“刻板”的限定，而事实也雄辩地证明了它的卓越成效。使用DO-178C无论开展研制还是检查，可能会牺牲一些“发挥”的空间，但是更强的可依据性、易判定性也将避免不少疑问与纠结的可能。对于许多正为难以驾驭CMMI而困扰的实践者，DO-178C恰似一份难得的“消化药”和“实战图”，在过程改进的道路上正好可以与CMMI相辅相成，相得益彰。 作为一个行业标准，DO-178C对于航空软件工作者自然是必修与必从的“法典”，但实际上对于其他领域软件而言，DO-178C同样具有宝贵的指导作用。软件工程难题的根源是软件状态空间超大、需求抽象漂移、人为因素交织等内在特征，而与软件应用的领域并无太大关联。DO-178C所针对和解决的各种问题，其实就是软件工程的基本和普遍问题。因此，对外界而言“深山人未知”的DO-178C，作为一套成熟的工程准则和指南，完全可以在更广阔的空间发挥积极作用，尤其是那些具有高安全性要求的领域，无论天空还是地面，无论民用还是军事，无论是否以通过审定为目的。事实上，他山之石，可以攻玉，有机会深入了解一下不同领域的成功经验和不同背景的专家思维，往往可以获得超出预想的裨益。当然这种学习应当是启发式的而不是拘泥不化的，软件工程这门特殊的学科应当格外崇尚向实践学习、向成功学习，同时也应当格外谨记不会有“一只鞋子适合所有的脚”。 伴随着最新版DO-178C标准的发布，本书给出了对该系列标准的全面深入解读和具体实践指导。作者是直接参与标准文件修订的资深专家，以其对标准的把握，传递了标准的本真的思想、方法，以及制定者的观点甚至争议。同时，作者作为航空软件审定的官方代表和权威专家，以其20多年的研发、审定和授课经历，将其积累的宝贵经验汇聚转化为丰富翔实且细致入微的最佳实践、推荐实践、建议、风险、挑战和陷阱等，并间或呈现鞭辟入里的箴言警句，能令读者在领略教益之余，还不时会萌发“心有戚戚”的称快之感。 国际上，软件过程和质量方面的标准早已在关键应用领域中发挥出重要作用。在国内，相关的概念、模型、标准的重视和推行也已有相当时日。但是，抽象的标准本身难以透射如何在实际工作中实施和见效，以及如何准确审查和评价的法门要义，这也许是过程改进道路上常常遇到的真正难题。从这个意义上讲，相信这本来自实践、用于实践的朴实读物，能为读者跨越从理论到实效的鸿沟，发挥一份真实、快捷的导航和助力作用。 最后需要说明的是，本书涉及专业领域和术语较多，许多术语在不同的群体和语境中有着不同的中文惯用词汇。译者在翻译这些术语时，尽量以传递原意、遵从规范、照顾习惯为兼顾目标，并对所做的一些考虑进行了注解说明。此外，由于译者的知识不足和时间仓促，全书翻译中难免有不当或谬误之处，敬请读者原谅和指正。任何意见、建议和探讨都欢迎致信：qualitysoftware@yeah.net。 前言 我深感重任在肩又忐忑不安地将这本书呈现给您。经过两年的研究和写作，我感到完成的还只是浮光掠影。我希望自己的经验和分享会对您的职业生涯带来帮助。 我很早就热衷于关注安全性及其现实的实现。在高中时代，我为一家本地报纸撰写一个关于安全性小建议的专栏，深入地研究了（作为互联网时代之前的美国乡镇所能做到的极致）：浴盆安全、拖拉机安全、电力安全，以及其他许多方面。在高中最后一年，我参加了州举办的演讲比赛，主题是座椅安全带的安全性。对提高安全性的愿望引领我进入了美国联邦航空局（FAA），这个愿望也是撰写这本书的主要动因。 软件只是整个安全链条中的一环，但却是一个重要环节，并且变得越来越关键。随着软件变得更加普及并且以更加关键的方式得到使用，它的风险和对安全性的作用日益增长。与软件相关的安全性增长的同时，许多公司的业务模型似乎也在变化——以少搏多、进度至上，软件工程师被当成棋盘上的棋子一样东挡西挪。 本书的意图是成为那些在业界奋斗的人们的有益工具。可能您是一位系统工程师或经理、软件经理、软件工程师、质量保证工程师，或者一位努力从他人那里汲取经验的学生。您想要做出色的工作，却被进度和预算的压力拖累。希望这本书，基于我过去20年在航空工业中的经验，可以在您追求质量和卓越的时候助一臂之力。 Leanna Rierson

第一部分?引　　言 第1章　引言和概览 2 1.1　安全关键软件的定义 2 1.2　安全性问题的重要性 2 1.3　本书目的和重要提示 4 1.4　本书概览 6 第二部分?安全关键软件开发的语境 第2章?系统语境中的软件 8 2.1　系统开发概览 8 2.2　系统需求 10 2.2.1　系统需求的重要性 10 2.2.2　系统需求的类型 10 2.2.3　良好的需求的特性 10 2.2.4　系统需求考虑 11 2.2.5　需求假设 14 2.2.6　分配到软/硬件项 14 2.3　系统需求确认与验证 15 2.3.1　需求确认 15 2.3.2　实现验证 15 2.3.3　确认与验证建议 15 2.4　系统工程师最佳实践 17 2.5　软件与系统的关系 19 第3章?系统安全性评估语境中的软件 20 3.1　航空器与系统安全性评估过程概览 20 3.1.1　安全性工作计划 21 3.1.2　功能危险评估 21 3.1.3　系统功能危险评估 22 3.1.4　初步航空器安全性评估 22 3.1.5　初步系统安全性评估 22 3.1.6　共因分析 23 3.1.7　航空器安全性评估和系统安全性评估 24 3.2　开发保证 24 3.2.1　开发保证等级 25 3.3　软件如何置于安全性过程 26 3.3.1　软件的独特性 26 3.3.2　软件开发保证 26 3.3.3　其他观点 28 3.3.4　在系统安全性过程关注软件的建议 28 第三部分?使用DO-178C开发安全关键软件 第4章?DO-178C及支持文件概览 32 4.1　DO-178历史 32 4.2　DO-178C和DO-278A核心文件 34 4.2.1　DO-278A与DO-178C的不同 39 4.2.2　DO-178C附件A的目标表概览 39 4.3　DO-330：软件工具鉴定考虑 43 4.4　DO-178C技术补充 43 4.4.1　DO-331：基于模型的开发补充 43 4.4.2　DO-332：面向对象技术补充 44 4.4.3　DO-333：形式化方法补充 44 4.5　DO-248C：支持材料 44 第5章?软件策划 46 5.1　引言 46 5.2　一般策划建议 46 5.3　5个软件计划 49 5.3.1　软件合格审定计划 49 5.3.2　软件开发计划 50 5.3.3　软件验证计划 52 5.3.4　软件配置管理计划 54 5.3.5　软件质量保证计划 56 5.4　3个开发标准 57 5.4.1　软件需求标准 58 5.4.2　软件设计标准 58 5.4.3　软件编码标准 59 5.5　工具鉴定计划 60 5.6　其他计划 60 5.6.1　项目管理计划 60 5.6.2　需求管理计划 60 5.6.3　测试计划 60 第6章?软件需求 61 6.1　引言 61 6.2　定义需求 61 6.3　良好的需求的重要性 62 6.3.1　原因1：需求是软件开发的基础 62 6.3.2　原因2：好的需求节省时间和金钱 63 6.3.3　原因3：好的需求对安全性至关重要 64 6.3.4　原因4：好的需求对满足客户需要是必需的 64 6.3.5　原因5：好的需求对测试很重要 64 6.4　软件需求工程师 65 6.5　软件需求开发概览 66 6.6　收集和分析软件需求的输入 67 6.6.1　需求收集活动 67 6.6.2　需求分析活动 68 6.7　编写软件需求 69 6.7.1　任务1：确定方法 69 6.7.2　任务2：确定软件需求文档格式 70 6.7.3　任务3：将软件功能划分为子系统和/或特征 70 6.7.4　任务4：确定需求优先级 71 6.7.5　避免滑下的斜坡 71 6.7.6　任务5：编档需求 72 6.7.7　任务6：提供系统需求的反馈 77 6.8　验证（评审）需求 77 6.8.1　同行评审推荐实践 78 6.9　管理需求 81 6.9.1　需求管理基础 81 6.9.2　需求管理工具 81 6.10?需求原型 83 6.11?可追踪性 83 6.11.1　可追踪性的重要性和好处 84 6.11.2　双向可追踪性 84 6.11.3　DO-178C和可追踪性 85 6.11.4　可追踪性挑战 86 第7章?软件设计 88 7.1　软件设计概览 88 7.1.1　软件体系结构 88 7.1.2　软件低层需求 89 7.1.3　设计打包 90 7.2　设计方法 90 7.2.1　基于结构的设计（传统） 90 7.2.2　面向对象的设计 91 7.3　良好设计的特性 92 7.4　设计验证 95 第8章?软件实现：编码与集成 97 8.1　引言 97 8.2　编码 97 8.2.1　DO-178C编码指南概览 97 8.2.2　安全关键软件中使用的语言 98 8.2.3　选择一种语言和编译器 100 8.2.4　编程的一般建议 102 8.2.5　代码相关的特别话题 109 8.3　验证源代码 110 8.4　开发集成 111 8.4.1　构建过程 111 8.4.2　加载过程 112 8.5　验证开发集成 112 第9章?软件验证 113 9.1　引言 113 9.2　验证的重要性 113 9.3　独立性与验证 114 9.4　评审 115 9.4.1　软件计划评审 115 9.4.2　软件需求、设计和代码评审 115 9.4.3　测试资料评审 115 9.4.4　其他资料项评审 116 9.5　分析 116 9.5.1　最坏情况执行时间分析 117 9.5.2　内存余量分析 117 9.5.3　链接和内存映像分析 118 9.5.4　加载分析 118 9.5.5　中断分析 118 9.5.6　数学分析 119 9.5.7　错误和警告分析 119 9.5.8　分区分析 119 9.6　软件测试 119 9.6.1　软件测试的目的 120 9.6.2　DO-178C软件测试指南概览 121 9.6.3　测试策略综述 123 9.6.4　测试策划 126 9.6.5　测试开发 128 9.6.6　测试执行 130 9.6.7　测试报告 132 9.6.8　测试可追踪性 132 9.6.9　回归测试 132 9.6.10?易测试性 133 9.6.11?验证过程中的自动化 133 9.7　验证的验证 134 9.7.1　测试规程评审 135 9.7.2　测试结果的评审 135 9.7.3　需求覆盖分析 136 9.7.4　结构覆盖分析 136 9.8　问题报告 142 9.9　验证过程建议 145 第10章?软件配置管理 148 10.1　引言 148 10.1.1　什么是软件配置管理 148 10.1.2　为什么需要软件配置管理 148 10.1.3　谁负责实现软件配置管理 149 10.1.4　软件配置管理涉及什么 150 10.2　软件配置管理活动 150 10.2.1　配置标识 150 10.2.2　基线 151 10.2.3　可追踪性 151 10.2.4　问题报告 151 10.2.5　变更控制和评审 154 10.2.6　配置状态记录 155 10.2.7　发布 156 10.2.8　归档和提取 156 10.2.9　资料控制类别 157 10.2.10?加载控制 158 10.2.11?软件生命周期环境控制 159 10.3　特别的软件配置管理技能 159 10.4　软件配置管理资料 160 10.4.1　软件配置管理计划 160 10.4.2　问题报告 160 10.4.3　软件生命周期环境配置索引 160 10.4.4　软件配置索引 160 10.4.5　软件配置管理记录 161 10.5　软件配置管理陷阱 161 10.6　变更影响分析 163 第11章?软件质量保证 166 11.1　引言：软件质量和软件质量保证 166 11.1.1　定义软件质量 166 11.1.2　高质量软件的特性 166 11.1.3　软件质量保证 167 11.1.4　常见质量过程和产品问题的例子 168 11.2　有效和无效的软件质量保证的特征 169 11.2.1　有效的软件质量保证 169 11.2.2　无效的软件质量保证 170 11.3　软件质量保证活动 170 第12章?合格审定联络 174 12.1　什么是合格审定联络 174 12.2　与合格审定机构的沟通 174 12.2.1　与合格审定机构协调的最佳实践 175 12.3　软件完成总结 177 12.4　介入阶段审核 178 12.4.1　介入阶段审核概览 178 12.4.2　软件作业辅助概览 179 12.4.3　使用软件作业辅助 181 12.4.4　对审核者的一般建议 181 12.4.5　对被审核者的一般建议 186 12.4.6　介入阶段审核细节 188 12.5　合格审定飞行试验之前的软件成熟度 195 第四部分?工具鉴定和DO-178C补充 第13章?DO-330和软件工具鉴定 198 13.1　引言 198 13.2　确定工具鉴定需要和等级（DO-178C的12.2节） 199 13.3　鉴定一个工具（DO-330概览） 202 13.3.1　DO-330的需要 202 13.3.2　DO-330工具鉴定过程 203 13.4　工具鉴定特别话题 210 13.4.1　FAA规定8110.49 210 13.4.2　工具确定性 211 13.4.3　额外的工具鉴定考虑 211 13.4.4　工具鉴定陷阱 212 13.4.5　DO-330和DO-178C补充 214 13.4.6　DO-330用于其他领域 214 第14章?DO-331和基于模型的开发与验证 215 14.1　引言 215 14.2　基于模型开发的潜在好处 216 14.3　基于模型开发的潜在风险 218 14.4　DO-331概览 221 14.5　合格审定机构对DO-331的认识 225 第15章?DO-332和面向对象技术及相关技术 226 15.1　面向对象技术介绍 226 15.2　OOT在航空中的使用 226 15.3　航空手册中的OOT 227 15.4　FAA资助的OOT和结构覆盖研究 227 15.5　DO-332概览 228 15.5.1　策划 228 15.5.2　开发 228 15.5.3　验证 228 15.5.4　脆弱性 229 15.5.5　类型安全 229 15.5.6　相关技术 230 15.5.7　常见问题 230 15.6　OOT建议 230 15.7　结论 230 第16章?DO-333和形式化方法 231 16.1　形式化方法介绍 231 16.2　什么是形式化方法 232 16.3　形式化方法的潜在好处 233 16.4　形式化方法的挑战 234 16.5　DO-333概览 235 16.5.1　DO-333的目的 235 16.5.2　DO-333与DO-178C的比较 236 16.6　其他资源 238 第五部分?特?别?专?题 第17章?未覆盖代码（无关代码、死代码和非激活代码） 240 17.1　引言 240 17.2　无关代码和死代码 240 17.2.1　避免无关代码和死代码的晚发现 241 17.2.2　评价无关代码或死代码 242 17.3　非激活代码 243 17.3.1　策划 245 17.3.2　开发 245 17.3.3　验证 246 第18章?外场可加载软件 247 18.1　引言 247 18.2　什么是外场可加载软件 247 18.3　外场可加载软件的好处 247 18.4　外场可加载软件的挑战 248 18.5　开发和加载外场可加载软件 248 18.5.1　开发支持外场加载的系统 248 18.5.2　开发外场可加载软件 249 18.5.3　加载外场可加载软件 249 18.5.4　修改外场可加载软件 250 18.6　总结 250 第19章?用户可修改软件 251 19.1　引言 251 19.2　什么是用户可修改软件 251 19.3　UMS例子 252 19.4　为UMS设计系统 252 19.5　修改和维护UMS 254 第20章?实时操作系统 256 20.1　引言 256 20.2　什么是RTOS 256 20.3　为什么使用RTOS 257 20.4　RTOS内核及其支持软件 258 20.4.1　RTOS内核 258 20.4.2　应用编程接口 258 20.4.3　主板支持包 259 20.4.4　设备驱动 260 20.4.5　支持库 260 20.5　安全关键系统中使用的RTOS的特性 260 20.5.1　确定性 260 20.5.2　可靠的性能 260 20.5.3　硬件兼容 261 20.5.4　环境兼容 261 20.5.5　容错 261 20.5.6　健康监控 261 20.5.7　可审定 262 20.5.8　可维护 262 20.5.9　可复用 262 20.6　安全关键系统中使用的RTOS的功能 262 20.6.1　多任务 262 20.6.2　有保证和确定性的可调度性 263 20.6.3　确定性的任务间通信 264 20.6.4　可靠的内存管理 265 20.6.5　中断处理 265 20.6.6　钩子函数 265 20.6.7　健壮性检查 266 20.6.8　文件系统 266 20.6.9　健壮分区 266 20.7　需考虑的RTOS问题 266 20.7.1　要考虑的技术问题 267 20.7.2　要考虑的合格审定问题 269 20.8　RTOS相关的其他话题 271 20.8.1　ARINC 653概览 271 20.8.2　工具支持 273 20.8.3　开源RTOS 274 20.8.4　多核处理器、虚拟化和虚拟机管理器 274 20.8.5　保密性 275 20.8.6　RTOS选择问题 275 第21章?软件分区 276 21.1　引言 276 21.1.1　分区：保护的一个子集 276 21.1.2　DO-178C和分区 277 21.1.3　健壮分区 277 21.2　共享内存（空间分区） 279 21.3　共享中央处理器（时间分区） 279 21.4　共享输入/输出 280 21.5　一些与分区相关的挑战 281 21.5.1　直接内存访问 281 21.5.2　高速缓存 281 21.5.3　中断 282 21.5.4　分区间通信 282 21.6　分区的建议 282 第22章?配置数据 287 22.1　引言 287 22.2　术语和例子 287 22.3　DO-178C关于参数数据项的指南总结 289 22.4　建议 289 第23章?航空数据 293 23.1　引言 293 23.2　DO-200A：航空数据处理标准 293 23.3　FAA咨询通告AC 20-153A 296 23.4　用于处理航空数据的工具 297 23.5　与航空数据相关的其他工业文件 298 23.5.1　DO-201A：航空信息标准 298 23.5.2　DO-236B：航空系统性能最低标准：区域导航要求的导航性能 298 23.5.3　DO-272C：机场地图信息的用户需求 298 23.5.4　DO-276A：地形和障碍数据的用户需求 298 23.5.5　DO-291B：地形、障碍和机场地图数据互换标准 298 23.5.6　ARINC 424：导航系统数据库标准 299 23.5.7　ARINC 816-1：机场地图数据库的嵌入式互换格式 299 第24章?软件复用 300 24.1　引言 300 24.2　设计可复用构件 301 24.3　复用先前开发的软件 304 24.3.1　为在民用航空产品中使用而评价PDS 305 24.3.2　复用未使用DO-178［］开发的PDS 308 24.3.3　COTS软件的额外考虑 310 24.4　产品服役历史 311 24.4.1　产品服役历史的定义 311 24.4.2　使用产品服役历史寻求置信度的困难 311 24.4.3　使用产品服役历史声明置信度时考虑的因素 312 第25章?逆向工程 313 25.1　引言 313 25.2　什么是逆向工程 313 25.3　逆向工程的例子 314 25.4　逆向工程要考虑的问题 314 25.5　逆向工程的建议 315 第26章?外包和离岸外包软件生命周期活动 321 26.1　引言 321 26.2　外包的原因 322 26.3　外包的挑战和风险 322 26.4　克服挑战和风险的建议 325 26.5　总结 331 附录A?活动转换准则举例 332 附录B?实时操作系统关注点 338 附录C?为安全关键系统选择实时操作系统时考虑的问题 341 附录D?软件服役历史问题 344 缩略语 348 参考文献 353 推荐读物 365