通用性设计方案
1.1 通用性设计方案
我单位依据技术要求，设计实现的可靠性、安全性、维修性、测试性、保障性、环境适应性的设计和措施合理可行，满足国家和军队相关标准，满足用户使用要求，下面是详细设计。
1.1.1 “可靠性”设计与措施
1.1.1.1 可靠性工程分析
可靠性符合GJB 450A-2004《装备可靠性工作通用要求》所规定的相关要求，编制系统可靠性维修性保证大纲，对所有软件提出软件可靠性要求，并且软件可靠性要求高于所嵌入硬件的可靠性要求和上一级的可靠性指标要求。
系统参考可靠性框图如下图所示，参照GJB 1621.8A-2006《技术侦察装备通用技术要求第八部分：可靠性指标和验证试验方法》进行系统可靠性指标的预计与分配，系统平均故障间隔时间（MTBF）为300.4H，满足指标要求≥300H。
串联工作可靠性数学模型如式（1）所示：
（1）
并联工作可靠性数学模型如式（2）所示：
（2）
系统中的设备脆弱性分析辅助决策分系统、设备固件解析处理分系统、设备脆弱点样本捕获分系统、设备脆弱点分析定位分系统为并联的工作方式，采用数学模型（2）进行计算。
基础平台与管理分系统、设备脆弱性场景验证分系统为串联工作方式，采用数学模型（1）进行计算。
根据可靠性的参数关系，当任务设备工作方式，系统基本可靠性数学模型见下公式：
+
注：
1）MTBF—系统平均故障间隔时间；
2）MTBFi—第i个模块的平均故障间隔时间；
3）利用数学模型计算后得到MTBF=300.4H，满足指标要求的≥300H。
本系统拟参照GJB 450A-2004《装备可靠性工作通用要求》中的规定采用可靠性分析评价法进行可靠性指标的验证，或按照GJB 899A-2009 《可靠性鉴定和验收试验》规定的方法进行试验验证。
1.1.1.2 可靠性设计分析
1）依照GJB 450A-2004《装备可靠性工作通用要求》的规定制定可靠性工作计划，开展可靠性工作，按照订购方要求提供必要的可靠性信息。必须遵循采用成熟设计的可靠性设计原则，控制新技术所占的比例，应尽量采用简化、冗余和模块化设计。软件的开发必须符合软件工程的要求，对关键软件应具备自检、自启动和自恢复能力，且提供合同要求的验证。对使用中暴露的设计缺陷负责改进；
2）平均故障间隔时间MTBF≥300小时。
1.1.1.3 可靠性设计基本原则
为确保本系统达到规定的可靠性要求，保持和提高系统可靠性水平，满足系统战备完好性和任务成功性要求。可靠性工作的基本原则如下：
1）可靠性与系统的战备完好性、任务成功性、维修性、保障系统及其资源等要求相协调，可靠性要求合理、科学并可实现；
2）可靠性工作以预防为主，把预防、发现和纠正设计、制造、元器件及原材料等方面的缺陷作为可靠性工作的重点；
3）在研制阶段，可靠性工作必须纳入装备的研制工作，统一规划、协调进行、并行开展；
4）采用成熟设计的可靠性设计，控制新技术在系统中所占的比例，分析已有类似产品在使用可靠性方面的缺陷，采取有效的改进措施，提高可靠性；
5）软件的开发符合软件工程要求；
6）加强对研制和生产过程中的可靠性工作的监督与控制，严格进行可靠性评审；
7）重视使用阶段的可靠性工作，尤其是初始使用期间的可靠性评估和使用可靠性改进工作。
1.1.1.4 可靠性设计准则
为了提高系统的可靠性，对产品设计、工艺、软件等方面提出可靠性定性要求，制定以下设计准则，满足系统可靠性要求。
1.1.1.4.1 新技术控制
为保证产品的可靠性以及研制周期的要求，必须最大限度采用成熟技术。若采用新技术，则新技术必须经过充分论证、试验和验证，控制新技术所占的比例。
1.1.1.4.2 简化设计
在满足产品性能要求的前提下，坚持简化设计原则，采用简化、模块化设计。尽可能简化方案、简化结构、简化电路，减少零部件、元器件数量及规格品种。
本项目采用“模块化”设计原则，具备功能模块化、应用插件化、架构微服务化。通过“模块化”设计，整个平台实现了平台层次化、功能服务化、基础设施复用化等简化目标。
1.1.1.4.3 标准化设计
在系统设计时，坚持标准化设计思路，统一软硬件接口，提高系统配置灵活性，增强系统重构、扩展能力。尽量采用标准零部件，标准电路、标准模块，并强调互换性。
本项目采用“通用化”设计原则，其技术体制、系统架构、集成数据、插件式能力均满足标准统一目标。并能够按照不同场景需求标准，采用“系列化”进行部件组合，实现模式化系列平台。
1.1.1.4.4 冗余设计
将冗余设计与其他传统工程设计相结合，从可靠性、安全性指标，元器件的可靠性水平、技术可行性、体积和功耗等方面进行权衡分析后合理采用冗余技术。
本项目从技术层面、硬件层面、数据层面均进行冗余设计：
1）技术层面
平台采用无扰动切换技术、热备技术、故障检测技术、热插拔技术、故障隔离技术等，实现从技术层面的冗余保障。
2）硬件层面
平台采用的硬件设备，关键器件冗余设置（控制卡、电源、风扇等），实现从物理层面的冗余保障。
3）数据层面
平台采用数据备份工具组件，实现数据的多种备份逻辑（完全备份、差异备份、实时备份、定时备份），实现从数据层面的冗余保障。
1.1.1.4.5 软件工程化设计
采用可靠性高的操作系统作平台，自行开发的软件要符合软件规范、有容错性、模块化设计，具有防止误操作的能力，软件具备自检、自启动和自恢复能力。软件开发过程中，对暴露的设计缺陷负责改进，严格按照软件工程化的要求进行控制管理。
本项目首先按照“三化”原则，将系统划分为多个独立模块，使得系统具备合理层次结构，并按照通用性中间层实现模块间的关联。在此前提下，即可运用敏捷性开发方法，实现多模块并行开发，各功能模块独立负责修复。实现软件工程开发过程的高可靠性保障。
1.1.1.5 设备选购可靠性
根据系统性能指标要求，优选可靠性高的设备。按设备性能要求选择元器件和原材料，选用符合可靠性指标要求的元器件。在相应国标、国军标、部标及现行有效的手册中选用元器件与原材料，通过筛选试验，降低上机元器件失效率。
本期项目，主要使用国产的成熟货架产品，包括系统的服务器、交换机、数据存储等硬件。
1.1.1.6 基础支撑环境可靠性保证措施
本项目从设计方案分析可见，影响系统运行的关键硬件部分包括网络、存储、服务器等。可靠性设计准则是从影响可靠性指标的各因素入手，根据已有的、相似产品的工程经验，通过设计使这些因素得到解决或改善。在工程设计中，采取如下可靠性保证措施：
1）基础硬件设备可靠性方面，配置硬件设备，主要包括服务器、交换机、数据存储等硬件，设备均为国产化成熟品牌，在温湿度、电磁兼容性等方面均满足机房运行需求，并且在其他系统内经过成功检验。
2）在数据库服务方面，数据库服务器采用热备方案，保证无单点故障；数据库的库表数据存储在RAID磁盘上，利用磁盘空间的冗余实现数据冗余备份；并根据数据库备份策略，定时自动备份数据库存储的内容。
3）在数据存储方面，在线存储、近线存储等均有文件系统存储管理软件实现统一访问处理形成共用存储资源池，其中单套存储设备出现故障情况下，不影响系统正常业务化运行。
4）关键业务服务方面，如资源支撑、服务支撑、基础数字地球框架等均采用热备方案，保证系统关键节点无单点故障。关键设备（如骨干网络、汇聚层网络、关键业务服务器等）采用热备份，其它关键部件（如电源、电扇、业务网卡等）采用冗余配置。
5）在处理计算资源方面，计算节点构建成计算集群，由批处理作业调度系统统一管理，保证单节点故障不会影响其他节点的正常工作；利用计算资源虚拟化化技术，实现计算资源动态扩展，保证计算节点扩展和故障恢复不会影响其他节点的正常工作。
1.1.1.7 系统软硬件可靠性保证措施
业务系统可靠性是软件系统在意外或错误使用的情况下维持软系统功能特征的基本能力。遵循GJB/Z 102A-2012《军用软件安全性设计指南》、GJB 8114-2013《C/C++语言编程安全子集》等国军标相关标准中软件可靠性要求。主要可靠性保证措施如下：
1）为保证系统可靠性，软件设计和实现上采用组件化等成熟技术，采用异构资源统管、服务支撑框架、基础数字地球框架等技术，继承其他大型用系统设计和实现上的关键技术和成功经验，包括系统总体集成、任务调度与管理、数据管理与可视化等关键技术以及项目实施过程中的进度质量等控制措施的实施经验。软件采用JAVA、Python、Go、JavaScript等熟悉的编程语言进行编码，能够在不同操作系统平台上运行，力求系统技术上的可靠性。
2）设计合理的可靠性测试手段，采取切实可行的可靠性检验途径。在基础支撑环境方面，对双机高可用可靠性测试过程中，关闭其中任意一台服务，系统业务不受影响。在系统业务处理软件，设计多种异常数据、异常接口进行测试，检验系统是否因为数据异常、接口异常等宕机，业务系统是否正常运行。
3）在软件设计中，充分考虑容错处理、异常处理等措施，软件执行过程中具有检错、记录、详细记录日志及错误报告，能够基于错误记录日志及报告进行错误复现，为问题解决提供重要依据。
4）运维统一设计，实现各分系统软件、硬件工作状态显示能力，能够进行故障信息显示，在有故障时及时提醒用户。
5）各分系统软件在运行中要对输入的所有参数执行严格的合理性检查，对数据格式错误、传输规程错误、数据越界等均设置错误识别判断依据，对错误信息进行识别、处理，并设计自动化隔离措施，如对收到的错误接口文件、错误数据后进行识别处理后，将错误数据迁移至错误数据区，从而不影响系统后续自动化处理任务，具备故障自动隔离能力。
6）系统具有较好的容错性和易恢复性。提供所有因误操作而导致的错误提示，对于发生的错误提供相应的解决方法建议。在容错性方面，软件内部错误的信息提示应明确，对异常数据、操作能够处理、提示，避免软件产生异常错误导致退出，在错误发生时确保系统正确行为，并进行内部修复的能力。如在文件系统存储应用中，发现失去了与一个远程组件的连接，系统能努力去恢复此连接。在修复这样的错误之后，软件系统仍可重新执行进程间的操作，直到成功退出或错误再次发生；在处理过程中对边界条件要进行检查和判断，在遇到非致命错误的情况下进行报警并能继续执行易，提升系统易恢复性和健壮性，在遇到意外错误事件时能确保应用系统处于已定义好的状态，在错误发生时系统能继续运行。
7）在系统内对于设备故障、网络故障等可能导致传输中断的故障具有识别能力，在运行状态监视软件能够显示系统软硬件故障信息。软硬件故障解决后，应能恢复系统正常运行。并对导致传输中断等任务，系统自动恢复当前中断的传输任务，具体自动恢复运行能力。
8）系统内各软件均进行优化设计，合理使用和释放计算机系统资源，软件根据具体执行所需合理使用CPU资源、内存资源，充分有效发挥资源性能，软件完成具体执行任务后，及时释放内存、CPU等资源，避免长期占用资源。通过软件使用资源的优化设计，能够确保软件正常、稳定执行。
9）系统进行恢复性设计。关键等级较高的软件考虑易恢复性设计，能够保证软件失效时，关键的数据得到保护，关键的操作得到记录，并在系统恢复时，相关信息能够得到恢复。
1.1.2 “安全性”设计与措施
系统主要涉及到设备与人员安全，系统硬件设备确保在机柜或相应环境中安装正确，软件系统具备身份认证功能，系统将从这方面开展安全性设计。
1.1.2.1 安全性设计分析
依据GJB 900A-2012《装备安全性工作通用要求》的规定和产品特点，对安全性工作进行统筹策划，通过及时、有效、经济的方式将安全性综合到产品设计中去。识别危险并分析每个危险的发生原因、发生可能性及后果，从危险严重性和危险可能性两方面，综合评价危险的风险水平，并在研制过程中有重点、有针对性、持续地采取安全性设计措施，消除或降低危险。
在设计初期考查系统方案，采用初步危险分析（PHA）的方法，确定系统设计中覆盖所有的潜在危险，包括危险的原因及针对危险原因的危险控制等；并进一步分析和确定潜在危险的严重性和可能性；根据危险的严重性等级及其可能性等级，确定每种危险的系统风险指标；根据每个软件的控制类别和系统风险指标确定每个软件的安全性等级，软件安全性等级高的为安全关键软件；对于安全关键软件采用冗余、降级处理、故障处理与恢复、降级运行等安全保证措施。
1.1.2.2 安全性设计准则
1）根据战术技术要求，从结构形式、使用材料和工作环境等方面综合考虑，采取技术安全措施，保证人身、设备和信息的安全；
2）安全性与可靠性、可维修性、保障性、人机工程和经济性等因素综合考虑，当实施的安全措施与其他因素发生矛盾时，一般优先保证安全措施的落实；
3）在装备的设计、制造、使用、维修等过程中，充分考虑所采取的工作原理、使用方式、材料与器件的安全合理性；
4）技术安全措施的保障途径的优先次序，依次为最小风险设计，安全、报警装置与标志，制定专用规程和进行专门培训等；
5）系统的安装平台，在正常情况下，不影响装备的安全，也不因装备的技术性故障使平台发生危险。
1.1.2.3 设备安全性设计
1）设备的安全性设计主要涉及以下几个方面：
（1）电气安全
对裸露于地面和人身容易触及的带电设备，采取可靠的防护措施；设备的带电部分与地面及其他带电部分应保持一定的安全距离；电力系统有避雷器、保护间隙等过程电压保护装置；电气设备安装地点设置安全标志；高压用电设备采取装设高压熔断器和断路器等不同类型保护措施；对低压用电设备应采用相应的低电器保护措施进行保护。
（2）结构安全
机柜等机动性设备选用性能良好、质量稳定的坚固平台，装备经常承受振动、冲击的结构有防护和加固措施，结构选材选用耐老化、抗疲劳、耐腐蚀的材料；室外设备需有抗风加固措施；装备的维修和检查，充分考虑安全性，当维修、调整、校准或其他理由需要接触设备内的部件时，或需要拆除或旁路任何保护装置时，设有可靠的锁定装置或禁止装置以防止有危险的装置运转。
（3）信息安全
系统各个席位及服务器不同于普通办公计算机，建议不要在机器上安装其它应用软件，不要在机器上使用其它来源的非系统自身产生的文档，以免影响系统正常运转，延误训练；内网子系统与互联网进行物理隔绝以防信息泄漏；操作系统中需要安装防病毒软件，具有防止病毒、木马感染、破坏的能力。
（4）电磁安全
系统电磁安全设计符合GJB 900A-2012《装备安全性工作通用要求》的规定和产品特点。各分系统中的设备应进行电磁兼容设计，考虑防电磁干扰、防电磁泄漏、防静电的措施，勘查阵地附近通信站、电力站等辐射源的地理位置，评估与阵地的安全距离，保证设备能在电磁环境中正常工作。
（5）场地安全
机房配备相应的电源、照明、防雷、防火、防电措施。
2）设备安全工作管理主要采取下面措施来保证系统的安全性：
（1）安全性管理
制定安全性工作计划，内容包含工作项目、工作进度、信息管理等；制定安全性评审计划，内容包含评审类型、评审点的设置及评审要求；对安全性进行危险跟踪；采取措施保证试验的安全性控制。
（2）安全性验证与评价
验证系统关键软件及规程是否符合安全性要求；系统试验或使用前对风险进行全面评价并做出书面结论，确定软件和系统设计的所有安全特性及试验、维护和使用中可能产生的危险及其类别。
（3）安全性培训
对于使用和保障人员，按照已批准的安全性规程制订培训计划并进行培训，使用和保障人员能了解安全性措施，并熟练掌握系统的安全操作使用规程及故障排除方法，使用和保障人员需经过考核通过后方能上岗；对于设计人员，根据系统危险性分析和使用危险性分析的结果，制定相应的安全性培训计划，使设计人员掌握必要的安全性设计知识，了解系统危险分析过程及结果，以及应采取的安全性措施，使上岗测试的设计人员熟练掌握系统的安全操作及故障排除方法。
1.1.2.4 软件安全性设计
软件安全性指的是软件运行而不引起系统事故的能力。对所有软件进行安全性分析，确定安全关键软件、及关键指令对整机和系统的影响，评价其风险，并在软件设计及操作上采取相应的安全性措施，使其风险降到最低。对于安全关键软件，应按照GJB 900A-2012《装备安全性工作通用要求》的要求，在软件开发的各个阶段进行有关的软件危险分析。
1）外购与重用软件的分析与测试
（1）分析安全关键软件与外购或重用软件的交互方式；
（2）分析外购或重用软件可能引起安全关键软件失效的故障模式；
（3）分析外购或重用软件没有使用的功能和代码，是否对安全关键功能产生影响；
（4）通过测试和分析的方法，对外购或重用软件的接口和能力进行测试；
（5）组织技术专家，依据分析和测试结果对选择的外购或重用软件进行评审，给出评审结论。
2）软件安全性需求与分析
（2）软件安全性需求分析与系统危险分析结合进行。系统危险分析为软件安全性需求分析提供输入信息，而软件分析的结果，反馈给系统危险分析人员，用于在系统层次进行更全面细致的分析；
（2）从装备安全性要求、系统或设备要求、接口要求、系统危险报告以及系统危险分析中获取软件“必须工作”的功能和“禁止工作”的功能，以及相关的时间性能需求；
（3）从环境要求、系统或设备要求、接口要求中获取软件与硬件、软件与软件、软件与操作者等之间的安全性相关的全部约束；
（4）依据标准、项目规范、软件可靠性安全性设计准则等，归纳软件安全性通用需求；
（5）选择使用软件失效模式及影响分析、软件运行模式分析、数据流分析、控制流分析、基于功能路径的软件潜在分析等方法，对软件需求进行安全性分析，并在《软件需求规格说明》中以独立条款，明确记录分析结果；
（6）标识所有与软件相关的危险和要求软件实现的危险控制；
（7）通过危险跟踪闭环系统，向相关主管人员报告找到的全部问题和新发现的危险。
3）软件设计安全性分析
（1）利用可追溯性矩阵，保证在设计中编入了所有的安全性需求，标识了安全性关键部件、单元和数据；
（2）在软件设计评审时，应对软件设计的可测试性、改善软件可测试性的建议，以及安全性关键部件的独立性给予特别关注；
（3）在安全性关键任务中，应重点考虑中断、时序、事件队列、硬件失效、通讯等问题对安全关键功能的影响；
（4）在《软件设计说明》中以独立条款明确记录软件设计安全性分析结果，记录发现的问题，提交设计评审。
4）软件代码安全性分析
（1）利用可追溯性矩阵，确认在代码中编入了所有安全关键软件需求和设计元素；
（2）验证实现安全性关键需求/设计的所有源代码文件，起始处有一个注释区，指出这些文件是安全性关键的；
（3）依照编码标准，可利用工具对代码进行标准符合性检查；
（4）对代码的逻辑、数据、接口、中断和潜在路径等进行分析，并标识出未使用的代码；
（5）将发现的问题和危险，提交危险跟踪闭环系统。
5）软件安全性测试分析
（1）验证彻底地测试了所有软件安全性需求；
（2）通过测试验证安全关键软件在载荷、应力、硬件失效和操作员错误等多种条件下，都能正常运行；
（3）通过测试验证其他非安全性关键的软件设计元素的失效不会危及安全性关健功能的执行；
（4）利用可追溯性矩阵，验证测试覆盖了所有软件安全性需求；
（5）利用测试覆盖工具，验证测试覆盖了所有软件安全性关键设计元素；
（6）不能通过测试验证的需求，可通过代码审查验证，并报相关管理部门批准；
（7）在《软件测试报告》中以独立章节明确安全性验证分析内容，统计验证的安全性关键需求、软件单元、相关的记录文档，以及与预期要求不一致的全部问题或质疑；
（8）《软件测试报告》应提交评审；
（9）如果发现了新的危险，应协助系统人员进行危险分析，并确定必须采取的措施。
6）运行阶段的软件安全性工作
（1）组织技术专家对软件运行文档进行审查，保证在文档中清晰地标识了所有安全性相关的命令、数据、输入序列等系统安全运行所必需的全部信息，包括错误消息描述和纠正措施；
（2）制定运行阶段的软件安全性工作计划，策划软件维护、培训等活动中软件安全性相关工作的要求、流程、完成形式、人员等，提出产生、实现、追溯和验证安全性关键需求的机制；
（3）任何安全性关健软件需求的更改，必须报相关管理部门批准；
（4）任何软件的维护，必须进行软件更改影响分析，确定回归测试的范围与层次；
（5）在软件交付之前，完成回归测试、验证覆盖分析和相关评审。
7）计算机系统安全设计
（1）安全关键功能的执行必须经操作人员确认或启动；
（2）设立安全性内核的独立计算机程序，用以监视系统并防止系统进入不安全状态；
（3）在系统设计时考虑故障的自动检测，一旦检测出不安全状态，系统应做出正确响应，不得回避；
（4）系统设计能防止越权或意外地存取或修改安全软件；
（5）安全软件在工作过程中，不应造成计算机死锁状态。
8）接口设计
（1）人机交互软件要便于操作员用单一行为处理当前事务，使系统推出潜在不安全状态，并恢复到某一安全状态；
（2）报警设计必须向操作员提供声光报警，声音报警信号必须超过预期的背景噪声，并同时提供表明软件正在操作的实时指示。
1.1.2.5 访问控制设计
系统包括管理员、操作员，管理员主要负责系统运维管理、系统功能配置等，增加、删减用户，并配置用户权限；操作员主要是操作使用系统。
1）系统中的每个用户，应具有唯一的用户识别码，用以标志其身份；
2）系统提供验证用户身份的机制，并对用户识别码、验证数据、验证机制等予以保护；
3）用户进入系统，应先行注册，对不合法的用户予以拒绝并报警；
4）信息设计中应遵循最小特权原则，即只能授予和使用那些为完成该任务或作业必不可少的权限；
5）系统中各特权应尽量分散，使掌握全局信息的人最少。对越权存取信息系统应予拒绝；
6）管理员和操作员，给予所需最低限度的权限，其职责权限应有明确的书面材料；
7）系统对特权指令，监督状况、输入输出指令、系统控制等限定使用，遇到越权和非法访问资源应予以决绝并报警；
8）具有事件审计记录能力，审计日志可保留存储；
9）具有对违规事件进行监视、报警和控制处理的措施；
10）支持对网络安全设备等资源进行管理，对用户违规行为进行监控；
11）关键网络和安全保密设备采取冗余设计；
12）系统根据用户属性及所需资源，规定其访问权限，访问权限过时后应立即注销；
13）对访问数据资源的有关事件和有关操作进行审计，以便获得完整的记录，根据记录进行安全性的分析，并及时采取处理措施；
14）对共享的信息资源，要执行分时和分配控制，防止非正常独占信息资源并控制信息的流向；
15）系统确保资源在安全的前提下能再利用。分配给用户的资源，不含有与系统或系统其它用户以前使用过的相关信息。
1.1.2.6 数据安全性设计
对数据的采集、传输、处理、存储、交换、使用和销毁的过程提出安全要求，以防止军用数据泄露、扩散或破坏，并防止对数据的非授权使用、修改或泄漏，确保数据的保密性、可用性和完整性。
1）根据涉密数据的密级，应采用相应的密码体制、保证数据达到所需的保密强度；
2）对密钥进行有效的管理，包括对密钥的产生、存储、分配、更换、保管、使用和销毁的全过程。密钥的分配可采用人工和自动相结合的方式。密钥的产生和检验工作应由专门的密钥管理部门和授权的人员负责；
3）对软件必须确认其功能的正确性。为了防止软件被非法复制，软件必须有唯一的标识，且能检验这种标识是否存在，以及是否被绕过。为了防止软件被非法修改，软件具有抗分析能力和完整性检验的手段；
4）存有大量密级信息和重要信息的计算机不得处理其他信息，否则把硬盘或盘阵拆下，以防密级信息被窃或被破坏；
5）对核心数据的存储有加密保护措施；
6）存储有密级信息和重要信息的媒体在作业时，具备加密保护措施；
7）对存储的重要数据必须进行完整性检验。要定期检查存储数据媒体的物理损伤情况，尽量减少误操作、软件故障、硬件故障和强电磁干扰等意外事件，以保证数据的完整性；
8）存储有密级信息和重要信息的媒体，必须拷贝，作特殊标志，妥善保管，具有数据自动备份功能，重要数据库热备份；
9）当存储有密级信息和重要信息的媒体报废时，必须进行销毁（如粉碎、消磁）以防信息的泄密和遗失。
1.1.2.7 信息传输设计
1）根据所传输或存储的数据的密级和信息特征，确定对军用数据加密保护的方式（传输数据的用户加密、线路加密、存储数据的局部或全部加密、数据库或库外加密等）；
2）信息在传输具有可靠性的校验纠错机制，保证接收信息的正确性和完整性；
3）信息交换具备鉴别真实性和有效性。收方能证实信息是由确认的发方发来的，内容是真实的，对收到的数据不能修改和抵赖；发方也不能否认发过数据，不能诬陷收方伪造数据；
4）对重要网络采用有防火墙隔离技术和端口保护措施；
5）对网络的拓扑结构、网络配置和网络参数等，未经批准不得变更。
1.1.2.8 接入外网设计
遵守《中国人民解放军计算机网络安全保密规定》的相关要求，内外网物理隔离，数据单向传输。
1.1.2.9 防病毒设计
1）在采集、传输、存储、访问、维护和管理信息的过程中，具有防病毒的保护措施；
2）系统必须具有对病毒进行检测、清除和防治的功能；
3）加强终端管理，及时发现非法程序，并按有关规定及时清除；
4）计算机系统及其所用盘、带应定期检测、登录，一经发现病毒，立即禁止使用，并按有关规定进行病毒清除；
5）用户不得使用未经消毒的信息资源。
1.1.2.10 信息维护设计
1）对所有信息资源，具有增、删、改的保护和相应记录；
2）对密级信息和重要信息进行维护或增、删、改前，必须写出书面申请报告，批准后方可实施；
3）密级信息和重要信息修改时只能在相应的信息副本上进行，并做出详细的记录。
1.1.2.11 人员安全性设计
危险源主要在电气和材料退化两方面，危险的严重性仅为轻微（人员轻度伤害或系统轻度损坏），危险发生的可能等级为极少，危险均在可接受的范围内，因此在设计中主要考虑了低电压低功耗设计，能够保障设备的安全和操作人员的人身安全。
元器件按照环保无害的原则进行，均选用无铅环保的元器件，同时设备的其它制造材料选择符合相关规定，能够保证环境和制造人员的安全。
1.1.3 “维修性”设计与措施
维修性工作按照GJB 368B-2009《装备维修性工作通用要求》规定编写系统维修性工作计划，开展维修性工作，进行系统的维修性设计、研制等工作。
良好的维修性能补充产品的可靠性不足。因此在产品可靠性设计的同时，也必须充分注意到维修性设计。在维修性设计时，应充分考虑系统的使用环境和条件，制定相关的维修策略和维修方式，充分考虑进行维修所必需的故障识别及故障定位方法等事项，力争做到降低设计的复杂性，简化维修工作，减少保障维修费用和工作量，做到预防维修周期尽可能长，从而避免维修中人为差错，降低对维修人员数量和技术水准的要求。
1.1.3.1 维修性工程分析
系统平均现场修复时间（MTTR）为1.99小时，满足MTTR不大于2小时的要求。修复性维修时间主要包括系统故障定位、排除时间等。
本系统采用模块化设计，维修时间的分配考虑可达性、设备故障检测和隔离、维修方式、设备可靠性水平等因素，综合后进行分配。根据分配的结果，利用公式：
计算出系统维修性的预计值为：
故系统维修性指标
=1.99H。
维修性验证独立进行或结合可靠性验证工作进行。
1.1.3.2 维修性设计分析
1）依照GJB 368B-2009《装备维修性工作通用要求》的规定制定维修性工作计划，开展维修性工作，按照订购方要求提供必要的维修性信息。应根据产品特点，制定相应的产品维修性设计准则。软件设计应考虑简化设计、模块化及防差错措施。对使用中暴露的维修性缺陷负责改进；
2）平均故障修复时间MTTR≤2H。
1.1.3.3 维修性设计准则
为保证维修时间尽可能短、维修方便，实现良好的维修性，制定以下准则。
1.1.3.3.1 简化设计
在满足功能要求和使用要求的前提下采用最简单的结构，考虑简化设计、模块化，尽可能减少产品层次和组成单元的数量。
本项目采用“模块化”设计原则，具备功能模块化、应用插件化、架构微服务化。通过“模块化”设计，整个平台实现了平台层次化、功能服务化、基础设施复用化等简化目标。当出现维修需求，可点对点进行维修，避免对其他模块、整体架构产生二次影响。
1.1.3.3.2 可达性设计
1）产品的结构设计和安装，凡需要维修的零部件，都考虑具有良好的可达性；
2）对故障率高而又需要经常维修的部位，提供最佳的可达性；
3）易损件、常拆件和附加设备的拆装要简便，拆装时零部件出进的路线最好是直线或平缓的曲线；
4）产品的检查点、测试点，布置在便于接近的位置上；
5）需要维修和拆装的产品，其周围要有足够的操作空间；
6）维修通道口的设计，使维修操作尽可能简单方便。
1.1.3.3.3 防差错设计
1）电缆、连接器、插头座和调整点采用不同外形、不同插脚或不同定位销进行设计，并以唯一性编号进行标识；
2）对于外形相似、功能不同、安装时容易发生差错的零部件，从构造上采取防差错措施或有明显的防差错标记；
3）控制装置和显示装置要有明显的操作标记；
4）标记经久耐用，不脱落、不退色和不因腐蚀而变质模糊。
1.1.3.3.4 标准化设计
1）设计时优先选用标准化的工具、元器件和零部件，紧固件规格应尽量统一电路组件和部件；
2）将所需的零件、元件、器件、组件和部件的规格品种减少到最低限度。
3）本项目采用“通用化”设计原则，其技术体制、系统架构、集成数据、插件式能力均满足标准统一目标。维修时避免应对纷繁复杂的技术组件和紧耦合的功能平台。
1.1.3.3.5 维修安全性设计
1）在考虑维修可达性的同时，保证维修的安全性，防止对维修人员的伤害；
2）在可能发生危险的部位，有醒目的标记或警告措施；
3）严重危及安全的部分，有自动防护措施；
4）凡与安装、操作、维修安全有关的地方都必须在技术文件资料中提出注意事项；
5）带有危险电压的产品其机壳要有良好的接地措施，其暴露部分要有良好的防护措施。
1.1.3.3.6 易维修性设计
1）标记与编号明显，部件、插件、电缆等具有永久性标记和编号，便于查找和维修；
2）采用快速装卸结构，采用模块化、插件化结构；
3）配备足够的备份件，实现快速替换，脱机修理；
4）限制维修工具，用或少用专用维修工具、附件和支援设备，尽量采用普通工具更换故障件；
5）通过故障检测，指示设备工作状态、故障状态、故障部位。
1.1.3.4 维修性控制措施
系统主要采用以下措施来保证系统的维修性：
1）针对计算设备、网络设备、存储设备等通用采购设备或附件故障，根据故障等级采取断电重启、模块替换、整机返厂检修、设备换新等措施进行维护。
2）针对采购软件、定制软件、定制服务等软件系统，采用软件重启、重新安装、版本升级、重新设计和服务重启等措施进行维护。
3）系统设计统一的运维监控平台，所有重要设备、资源提供统一的监控接口，提供友好的人机交互接口，可设定故障阈值、实现故障分类告警，并提供故障案例知识库便于快速完成常规故障维修处置。
4）系统采用层次化、模块化设计，严格遵循上层调用下层、下层不调用上层的要求，减少各层次间的耦合程度，提高模块可局部替换升级的能力。对于同一软件层，采用模块化设计，模块与模块之间尽量采用数据耦合，减少控制耦合，减少模块间的耦合程度。
5）系统提供完备的操作手册和维修手册，并对系统常见故障问题和处置方法对用户开展专业培训。
6）对使用中暴露的维修性缺陷负责改进。
1.1.4 “测试性”设计与措施
测试性工作按照GJB 2547A-2012《装备测试性通用工作要求》要求，进行系统的测试性设计与研制。提供系统级或设备级自检功能，包括对系统运行状态的监测及故障报警，系统故障的自诊断功能和系统设备的自动检查功能；系统故障检测可达分系统级，分系统检测可达功能模块级、设备级。
系统具备测试性接口，确保接口可用性，输入输出参数个数及命名合理规范，接口实现功能正确完整，接口文档规范。
1.1.4.1 测试性设计分析
系统依据GJB 2547A-2012《装备测试性工作通用要求》的规定和产品特点，选用合适的设计技术方法，开展测试性设计工作，并提供自检功能，包括对系统运行状况的监测及故障报警，系统故障的自诊断功能。
1.1.4.1.1 测试用例设计
在系统研制过程中，优先编写测试用例，对实现的功能进行测试。
本项目对功能、性能的测试用例，严格按照招标指标要求（总体指标6项，功能指标41项，性能指标69项，通用性要求6项），以用户使用角度进行用例设计。
本项目测试目的和范围覆盖工作模式及流程、功能指标、性能指标、专项能力、整体效能。针对每个方向，均提供主要考核指标、测试目标、测试方式及详细测试步骤。实现系统满足“测试性”目标。
1.1.4.1.2 模块可控制性设计
对于每个相对独立的模块，能够单独设计用例，完成功能测试，在测试运行期间模块异常时能够将其隔离而不影响测试。
对于分系统、子系统及功能模块的测试，是按照所属功能、性能指标进行用例设计。
功能测试以分系统为基础单元模块，按照单元测试规则实现模块可控制目标。单元测试具备无依赖和隔离，保障测试过程中如出现异常，不影响测试本身及相关其他模块。
1.1.4.1.3 业务流程的控制性设计
在测试环境满足的情况下能够控制任一单独业务流程，各业务流程具有可控性。
本项目划分的三大业务流程（设备脆弱点检测技术攻研模式流程、对重点目标脆弱点分析协作攻研模式流程及网络威胁前置检测与反制利用模式流程）通过多个分系统相互配合实现业务流程的独立性和可控性。
1.1.4.1.4 可分解性设计
对于复杂的业务流程、场景需合理设定分解点，在测试时能够对其进行分解。
本项目划分的三大业务流程，因其流程需要多分系统相互配合，故其分界点定位于两两交互的分系统之间，具体分解实现通过消息传递接口进行判断控制。
1.1.4.1.5 稳定性设计
测试模块发布合理，后期追加的模块不能为前期所测模块引入新的不必要的测试活动。
本项目按“三化”原则进行模块划分，其功能、数据、接口相互独立，且通过微服务和应用插件式架构设计，实现对现有模块调整及新增模块的无缝集成，通过接口引用具备测试活动的快速启动。
1.1.4.1.6 可测试性编码
代码注释应详细全面，确保所有接口的可用性和易理解性。接口的设计应注重输入输出参数的数量和命名，遵循合理规范的原则，确保接口实现的功能准确无误且完整。在编码过程中，采用模块化方法，力求低耦合、高内聚，以便于维护和复用。
为支持集成测试与系统联调，应设置调测开关及相应的打印函数，并提供清晰的说明文档。在编写单元测试时，需精心挑选测试点，并构造有效的测试代码和测试用例，同时附上明确的注释说明。测试代码应作为一个独立的子模块存在于模块中，便于安装与移除（通过调测开关控制），以简化测试过程。
此外，应充分利用断言来检测软件问题，增强代码的可测试性，从而提高软件质量和开发效率。
1.1.4.1.7 自检功能
提供系统级或者设备级自检功能，包括对系统运行状况的监测及故障报警，系统故障的自诊断功能；系统级故障检测可达分系统级，分系统检测可达设备或可更换模块单元。
本项目基础平台与管理分系统具备对系统运行异常监控告警能力，实现对各分系统的自动诊断和快速告警，当系统出现异常能够第一时间进行修复。
1.1.4.1.8 设备的测试性
项目选用的设备要求具有全生命周期智能运维和深度故障诊断技术，具体如下：
1）完善的自检功能，对设备故障具有指示灯显示功能；
2）设备性能显示，故障时自动灯光或声音告警提示功能；
3）对不具备自测试能力的设备或组件，开展测试性设计，保证系统的测试性需求。
1.1.4.2 软件的易测试性
按照GJB 2547A-2012《装备测试性工作通用要求》、GJB 1909A-2009《装备可靠性维修性保障性要求论证》和系统技术要求，提供各系统级或者设备级自检功能，包括对各系统运行状况的监测及故障报警和定位功能。
1.1.4.2.1 易测试性设计原则
测试性主要表现是设立观察点、控制点、观察装置、驱动装置、隔离装置等。软件开发文档应遵循GJB 438B-2009《军用软件开发文档通用要求》的要求进行编写。软件配置管理应按照相关的国军标和工程规范执行。软件设计时应进行可测试性设计，保证测试结果可准确获取，并保证可测试性设计不会对最终系统的运行造成影响。为保证系统可测试性，在软件设计编目过程中必须遵循以下基本原则：
1）强内聚、弱耦合性
软件设计接口清晰，减少软件对外耦合性。耦合强调模块之间的交互，内聚强调模块内部结合紧密的特性。耦合是用来衡量一个模块与另一个模块关联的紧密程度。紧耦合会使一个系统变得复杂，难以理解，难以调试和维护。因此，设计系统时应当尽量降低模块间的耦合以降低整个系统的复杂性。内聚是用来衡量单一模块中功能和元素之间联系的紧密度，它说明模块或组件中所有元素一同工作来提供有良好边界的行为。
2）可读性和可懂性
在软件开发过程中使用编程规范提升软件的可读性和可懂性，间接提升模块可测试性。针对软件代码编写，定义JAVA/Python/Go等软件编程规范，定义编程风格、变量及函数定义、注释语句等，在详细设计过程定义清晰的编程思路，提高代码可读性，可懂性。采用规范的编程语言、清晰的编程思路、良好的编程风格，各模块能够独立进行测试，从而在单元测试阶段能够依据测试用例进行独立测试。
3）模块化或面向对象的要求
软件编程严格按照模块化或面向对象的要求，降低模块间的耦合度，便于在更动维护后进行测试。应用系统各类软件按照面向对象设计思想进行模块化设计，软件模块组件之间进行松散耦合设计。在这样的结构下，才能在不影响客户使用的情况下替换组件或把新的组件集成到现有的体系结构中来。软件在设计上充分考虑抽象与封装、模块化、责任分离、层次化设计、耦合和内聚、接口与实现的分离等要素，降低模块间的耦合度，从而在后续变更维护后便于测试。
4）可理解性
制定详细的软件需求规格说明、软件设计说明、软件测试用例等文档，使软件易于理解。在系统研制建设各阶段，遵循国军标等要求，制定设计方案、软件需求规格说明、软件设计说明、软件测试大纲及细则等详细文档，文档材料依据前后设计关系有详细的对应，使软件易于理解。
依据软件编程规范，包括统一变量及函数符号名标识符，程序语句结构规范，程序编码中至少有20%以上的注释（不含模块头与函数头的注释部分）。一方面，有利于技术人员在后续系统维护或问题排查过程中及时有效的对软件进行升级；另一方面，优秀的编码风格能够帮助用户快速理解和维护程序。
1.1.4.2.2 易测试性设计措施
可测试性设计时必须要保证不能对系统的任何功能有影响，不能产生附加的活动或者附加的测试，采取合适的设计模式对系统进行设计。主要措施如下：
1）坚持测试驱动设计（测试先行）的方法
优先编写测试代码，先写验收测试，再写单元测试，编写测试代码。设计以这种方式得以进展，在实现阶段捕捉错误并在下一组测试中改正它。
2）尽量做到每个操作对应一个函数，使函数小型化
使用小型函数或重载带缺省参数的函数将使测试中调用这些函数变得便捷。否则，在测试这些函数时将不得不构造额外参数，如果参数很大，那么将很快导致代码膨胀。
3）数据的显示与控制分离
把代码移到GUI视图的外面，然后，各种GUI动作就变成了模型上的简单方法调用。这样，对GUI测试者来说，通过方法调用测试功能比间接地测试功能容易的多，同时它使实现修改程序功能而不影响视图变得更容易。
4）可控制性设计
（1）全局变量的可控制性设计
在外界使用适当的手段能够直接或间接控制该变量，包括获取、修改变量值等；可以将全局类型的变量进行分类并封装到一个个接口中操作。
（2）接口的可控制性设计
各接口在外界使用适当的手段能够直接调用对该接口进行操作，这里所谓的适当的手段主要包括使用测试工具和增加额外代码。对于向外提供的接口的接洽处能够人为的对接，比如构造测试环境模拟接口对接，这里所指的开放接口主要是指相对于整个被测系统，即为被测系统以外提供的接口。接口接洽处人为对接时各接口所要求的条件和所需的参数人为的能够轻易达到和提供。
（3）模块的可控制性设计
对于每个相对独立的模块设计好所需要的驱动和桩都能单独设计用例进行测试对应的功能，在测试运行期间模块异常时能够将其隔离而不影响测试。
（4）业务流程的可控制性设计
在测试环境满足的情况下能够控制任一单独业务流程，各业务流程具有流通性。
（5）场景的可测试性设计
将一场景所涉及到的业务和接口整合到一个统一的接口使其能够单独操作该场景。
5）可分解性设计
（1）业务流程的可分解性设计
对于复杂的业务流程需合理设定分解点，在测试时能够对其进行分解。
（2）场景的可分解性设计
对于复杂的场景需合理设定分解点，在测试时能够对其进行分解。
6）稳定性设计
测试模块发布合理，不能在后期追加的模块为前期所测模块引入新的不必要的测试活动。
7）易理解性设计
（1）设计文档的易理解性
设计参考标准；内容描述主次要分清；依赖关系描述明确。
（2）接口的易理解性
接口功能明确；参数有意义。
（3）业务的易理解性
（4）场景的易理解性
8）可观察性设计
（1）业务执行状态和过程可观察性设计
（2）异常情况可观察性设计
9）测试驱动和桩的设置
为单个测试接口、测试业务、测试场景预留测试驱动和桩的接入点。
10）适合增量式开发的可测试性设计
在增量式开发过程中必须优先考虑测试桩和测试驱动实现的难易程度和真实性。
11）可查询设计
（1）对系统级别的全局变量或者状态设置查询接口。
（2）某一业务或场景调用接口设置接口路径查询。
12）自检测设计
（1）支持软件对功能、接口、流程的自动检测。
（2）能够对检测识别的故障进行报警。
（3）能够对检测识别的故障进行快速隔离，防止问题扩展。
13）自愈合功能
在某一场景中的局部出现故障时设置多路选择或者其他干涉进行跳转执行具有正常逻辑的功能。
14）输出结果
对于任何一项操作都要能产生预期的输出，不管是正确的还是错误的甚至是异常的。测试结果的表现形式可以是数据、现象等，不管是以什么方式表现，都要有依可寻，在设计文档中要有说明。对于测试结果易于判断，具有可分析性、可获得性。在设置的各个控制点或观察点的结果易于查询、修改等。
15）提供统一的操作执行面板
操作面板元素主要由输入和输出元素组成，如所执行的操作和对应的输出，但可能被测系统是一个比较复杂的系统，由多个可以独立的模块组成，涉及到的操作和输出比较多，各操作之间的关联也比较复杂。在设计时统一一个操作面板，该操作面板成为一个可以操作整个被测系统的独立模块，输入（执行的操作）输出均在界面上执行和体现。
特别对于执行某一场景时要跟踪该场景的关键过程和执行后的输出参数，给出一系列可以分析的数据，该场景可以以执行过程分阶段监控，将监控范围内的数据输出以供测试人员分析。
1.1.4.2.3 易测试性编码
1）注释需要详尽，尤其对于接口，要描述清楚功能、实现及参数。
2）使用模块化方法，编码低耦合、高内聚。
3）为集成测试与系统联调准备调测开关及相应打印函数，并且要有详细的说明。
4）为单元测试选择恰当的测试点，并仔细构造测试代码、测试用例，同时给出明确的注释说明。测试代码部分应作为（模块中的）一个子模块，以方便测试代码在模块中的安装与拆卸（通过调测开关）。
5）使用断言来发现软件问题，提高代码可测试性。
6）用断言来检查程序正常运行时不应发生但在调测时有可能发生的非法情况。
7）为测试自动化工具提供所需要的特定“钩子（hook）”。
8）对于每个功能，提供访问、修改状态变量的接口，包括提供查询、修改上层软件、软硬件接口、底层硬件状态的接口及打印。
9）提供查询系统状态的接口，比如内存使用、程序使用进程数等。
10）对于测试因为环境等因素而可能无法测试的功能，提供接口模拟软件实现该功能的过程。
11）对于修改功能，提供修改功能参数单位的接口，以便于进行如软件性能等的测试。
12）出错及异常处理保存记录，记录具有详细的属性，并且格式统一、意义明确。
13）在程序异常时，除了保留日志，还需要提供观察、恢复的外部方法。
14）对全局变量、特殊结构，提供查询的方法。
1.1.4.2.4 易测试性调试与定位
1）对于程序中所涉及到的变量尽可能的在调试过程中可以查询及修改。
2）在整个软件系统执行过程中为每个关键业务或相对独立的业务设定一个调试点，便于系统集成和问题范围的定位。
3）在设定好的调试点处对处理的业务输出数据和全局数据进行可视化输出，便于测试结果的分析。
1.1.4.3 测试性设计工作阶段
根据系统的规模以及测试需求，测试性设计的工作分为方案论证、样机研制和设计定型三个阶段。
1）方案论证阶段
（1）明确测试性定性、定量设计要求；
（2）制定测试性方法。
2）样机研制阶段
（1）按照制定的测试性方法，对测试性进行详细设计；
（2）预计故障检测和故障隔离能力，分析故障的影响，由可靠性设计师负责完成；
（3）进行测试性设计评估，保证测试性设计的有效性，由系统设计师系统完成；
（4）利用专用测试工装，对设备的功能性能进行测试。
3）设计定型阶段
（1）收集分析设备生产和使用中的测试性有关数据，提出测试性改进措施，由可靠性设计师、软件设计师完成；
（2）在设备设计定型、使用过程中收集分析测试性数据，对收集到的数据进行分析处理，并对测试性进行使用评价，由用户、系统设计师完成。
1.1.5 “保障性”设计与措施
保障性工作按照GJB 3872-1999《装备综合保障通用要求》、GJB 1267-1991《军用软件维护》的要求，进行系统的保障性设计与研制，编制并提供使用手册、维护指南等全套用户技术资料；完整规划软件的使用保障活动支持，包括软件包的交付、验收安装和检查，软件的维护和技术支持，软件的更改，维护人员及组织机构等，确保软件的正常使用。
1.1.5.1 保障性设计分析
系统的保障性设计根据以下标准开展保障性设计工作：
1）依据GJB 3872-1999《装备综合保障通用要求》、GJB 1371-1992《装备保障性分析》相关要求，开展保障性设计和分析工作；
2）根据合同要求提供技术资料、保障资源和保障服务；
3）依据GJB 1267-1991《军用软件维护》的要求，完整规划软件的使用保障活动支持，确保软件的正常使用。
保障工作主要包括人员、场地、保障设备、测试工具、维修工具、备品备件、技术资料、训练与培训、维修保养、计算机资源及软件的保障等等，其中操作使用人员、常规维护保养人员、设备安装场地及配套基建、水电气、食宿保障等工作，由用户承担，采用申请或配属的方式，利用装备配套保障资源，时限为装备至外场后的全寿命周期；装备初期培训人员、安装人员、中修及以上维护保养人员、特殊部组件的维保人员、必要的测试工具、维修工具、备品备件、技术资料、软件升级维护、技术支持的保障等，由承研方承担，采用预留、购置、研制等方式，利用装备配套保障资源，时限为装备的全寿命周期。
本项目全寿命剖面由研制阶段、交付阶段和任务剖面组成。研制阶段完成论证、研制与试验、测评等工作；交付阶段完成系统安装部署、交付试验，试验的保障和配套单位为用户单位和承研单位；交付阶段和任务剖面之间包括试验保障、技术保障、基地维护、差异化保障等工作，相关的保障维修和差异化研发建设由用户单位和承研单位共同进行；任务剖面主要有战备和作战使用剖面，战备包括值班、开机、阵地维护等工作，作战使用方式分为设备脆弱点检测技术攻研模式、对重点目标脆弱点分析协作攻研模式、网络威胁前置检测与反制利用模式共三种。
图 3‑121 全寿面任务剖面图
1.1.5.2 保障性方案
本系统根据GJB 3872-1999《装备综合保障通用要求》相关要求，开展保障性设计和分析工作。系统保障方案齐全，包括使用保障方案、维修保障方案及综合保障要素方案（人力和人员、备件和消耗品保障、保障设备、训练和训练保障、技术资料、保障设施、包装、装卸、贮存和运输保障）等，软件满足GJB 1267-1991《军用软件维护》的要求。
本系统和分系统在研制、生产和部署使用各阶段进行保障性分析，依据合同要求提出保障性需求。保障性分析工作由承制方、订购方共同完成，双方的责任在合同中规定，保障性需求应纳入有关文件中。
在系统设计过程中，应同步开展保障性特性设计和保障性资源规划设计分析工作，将综合保障性要求作为性能要求的组成部分。在方案设计时同步考虑其保障性，使有关保障性的要求有效地影响设计。充分进行保障性分析，权衡并确定保障性设计要求和保障资源要求；在保障资源规划和研制过程中，应充分考虑现有保障资源，同时强调其标准化要求。
系统主要采取下面措施来保证系统的保障性：
1）制定相应的软件维修规划，主要包括软件维护计划、软件结构管理、软件维护资源、软件维护环境、软件维护方案以及从研制到战场的保障要求等方面。
2）编写相关的培训教材，加强用户对软件使用技能的培训；当系统发生改变时，及时对现有培训教材进行增补或修正，并进行用户培训，尽可能降低对维修人员的技能要求，减少维修人员数量。
3）对系统使用过程中产生的问题，形成相关问题报告，通过现场维护或远程电话支持的方式进行及时的保障及维护。
4）对构件扩充升级包进行维护和管理，对所有软件构件集成打包，方便用户进行系统维护。
5）软件满足GJB 1267-1991《军用软件维护》的要求，完整规划软件的使用保障活动支持，确保软件的正常使用。
6）技术资料包括装备使用与维修中所需的所有技术资料，技术资料充分反应了装备的技术状态和使用与维修的具体要求，技术资料准确、清晰和易读，同时进行了技术资料得分类，制定了设备的使用与维修技术资料体系。主要技术资料及分类如下表所示。
表 3‑13 设备主要技术资料及分类
序号
类别
名称
备注
1
使用维修
系统技术说明书；
系统操作手册；
基层使用部队
2
使用
系统保障技术手册；
系统保障操作手册；
软件保障部门
3
技术状态
使用维修
系统技术说明书；
系统安装手册；
系统操作手册；
系统维修手册；
系统设计文档；
系统版本说明；
系统拓扑结构资料等；
全套资料按照相关规定进行归档，反应了装备的技术状态和使用与维修的具体要求
1.1.5.3 使用前后保障
拟定装备使用前后的保障方案，其内容包括：
1）装备在储存、维修、训练等状态下，转入使用前准备的工作方式、内容和时限；
2）装备工作状态转换，即由行驶、运输等状态向待命或作业状态的转换，展开和撤收的方式、工作内容和时限；
3）本系统要求尽量防潮、防高温、防震、防盐雾和霉菌，因此，系统装备在非工作状态时应放置在阴凉、干燥、通风的室内，设备使用前及使用后请参照使用维修说明书进行。
1.1.5.4 使用过程保障
系统使用过程中的保障方案，其内容包括：
1）装备使用期间的维护保养按照生产商要求进行；
2）装备使用过程中的测试、技术状态判定和决策，具体见使用维修说明书；
3）应急处置等，具体见使用维修说明书；
4）系统所属各种设备开始使用前应检查随机文件是否齐全，先阅读使用维修说明书，以减少误操作。
1.1.5.5 资源保障
保障资源主要包括通用保障设备、专用保障设备：
1）按照维修机构所需的保障设备提出保障设备配套方案，编制保障设备配套目录；
2）配套所需的检测设备，用于任务系统检测、维修等保障任务，设备的功能、性能、布局及其操作满足任务系统的作战使用及维修要求；
3）配备小型化多功能维修设备、维修工具、备件和支援设备，尽量采用普通工具更换故障件；
4）保障设备采用标准的、易采购的通用设备或综合测试设备，减少专用保障设备的种类和数量；
5）保障设备，易于操作、使用简便，并具有良好的机动性。
1.1.5.6 人员保障
人力和人员保障方案如下：
1）制定人员编制、分工职责、编组原则；
2）制定使用操作及相关技术人员（包括技术把关、决策和技术状况处置人员）的素质和技能要求；
3）制定维修及管理人员的技能和素质要求。
1.1.5.7 技术资料
技术资料方面，按照GJB 4742-1996《军用装备随机文件》、GJB 8000-2013《装备用户技术资料规划与编制要求》、GJB 6387-2008《武器装备研制项目专用规范编写规定》相关规定，编制并提供使用、维护全套用户技术资料。
系统技术资料满足下列要求：
1）技术资料种类、数量、格式和内容等符合系统标准化要求；
2）技术资料的内容确保完整、正确、通俗易懂，满足装备使用和维修要求；
3）技术资料包括但不限于：系统技术说明书、系统安装手册、系统操作手册、系统维修手册、系统拓扑结构资料、系统设计文档等。
1.1.5.8 培训保障
系统研制完成后，按照GJB 5707-2006《装备售后技术服务质量监督要求》设计，并对部队操作人员进行技术培训、现场技术服务。操作人员经过培训，应具有独立操作能力。
1）师资力量
从系统装备的使用维修和管理需求出发，明确完成训练任务对师资力量的需求，包括教员的数量、资历、专业基础知识、技能、装备相关理论知识掌握程度、装备实际使用及操作维修经验等。确定出训练保障所需的师资，并能够满足该系统实际训练对师资力量的要求。
2）训练设备、器材与设施
与系统使用单位沟通协商后，提出训练设备、器材与设施的要求及建议，以满足该系统实际训练所需的训练设备、器材与设施。
3）材料及有关资料
根据系统装备的特点和系统使用单位的要求，负责确定训练教材及有关技术资料，提出教材及有关技术资料配套目录明细的编制建议，相关材料包括：教材、教具、挂图、录像和多媒体课件等。
1.1.5.9 技术服务保障
系统交付用户时和交付用户后，按照用户单位的质量体系文件的要求，组织实施技术服务保障，进行服务保障等交付及交付后活动。保证期后按相关规定和用户要求，组织相关责任单位落实交付后活动，持续完善服务保障机制。
我单位开通了7*24小时装备售后服务热线，专门受理用户反映的装备质量问题，提供全寿命周期内技术培训和咨询等服务；建立了用户质量联络员制度，收集装备质量信息，建立产品档案；设立了专项设备维修经费，储备装备关键器材、自制件，为售后服务提供周转备件。
1.1.6 “环境适应性”设计与措施
系统设备均为室内设备，部署在温控机房内，对市场采购的通用计算机、服务器、交换机、电源、路由器等货架产品，我单位提供通用要求试验报告和产品合格证明。
通过在设计、安装等多方面采取的相应措施，设备的环境适应性设计符合GJB322A-98《军用计算机通用规范》、GJB 367A-2001《军用通信设备通用技术规范》以及相关工程标准的有关要求。
1.1.6.1 基础软硬件环境适应性设计
1）机房环境适应性
机房场地是确保计算机系统正常运行的重要基础设施。机房洁净度、照明、噪音、弱电、消防等都必须符合GB/T 2887-2011《计算机场地通用规范》的要求建设。为确保本系统的稳定运行，对环境的要求如下：
温、湿度：设备机房内温度20℃±2℃；相对湿度20％～65％。其它室内温度23℃±5℃；相对湿度20％～75％。
照明：计算机机房内照明设施照度应为≥300LX，并应有应急照明设施和便于排除故障的高亮度临时手段。终端机房要便于技术人员上机，同时有分区供电开关。
电磁场干扰：机房内频率范围(0.15～10000)MHz时无线电干扰场强＜120dB，磁场干扰场强＜800A/m，满足GJB 151B-2013《军用设备和分系统电磁发射和敏感度要求与测量》和GJB 152A-1997《军用设备和分系统电磁发射和敏感度》有关要求。
接地：接地形式符合GB14050-93《系统接地型式及安全技术要求》的规定，接地电阻≤4Ω，直流逻辑地与交流零线地之间的电压＜1V。
防护：具有防震、防雷、防火、防水、防鼠虫害等设施，具有安全、保密防护措施。
机房供电电源：交流电压：220×(1±10%)V或380×(1±10%)V，频率：50Hz±1Hz，相数：三相五线制或三相四线制/单相三线制。UPS供电，电池供电时间不小于15min。
2）设备接口适应性
系统内配置包括服务器、磁盘阵列、分布式存储设备、工作站、运维管理设备等，设备间连接均采用标准接口，能够基于网络体系进行扩展。购置的硬件设备均采用部件化设计，如服务器、工作站等均包含独立网卡，在网络进行扩展时，可以增加或替换独立网卡部件即可。设备间接口能够适应后续可能的基础环境升级。
1.1.6.2 软件系统环境适应性设计
1）共存性
系统各软件设计采用模块化设计，各模块设计具备强内聚、弱耦合性。模块在设计上，考虑与其他应用模块的共存。模块之间共存首先要解决计算机资源使用冲突问题，模块设计编码过程中依据编程规范，对内存操作等规定使用策略，各模块CPU使用率等进行合理规划，避免由于资源不足导致模块不能共存；另外，在模块依赖库方面，对于系统共性需要的基础计算库、图像处理显示等公共库均独立研发，由系统平台统一提供公共库，不依赖第三方运行时库，从而避免由于模块间用的依赖库版本不一致带来的问题，各模块能够共存。
2）适应性
应用系统软件设计考虑对硬件环境变化有一定适应能力，各模块在技术允许的范围内应对运行环境的变化有适应能力。系统软件设计应采用标准模块化设计，不依赖独立的硬件及软件环境，如软件设计过程中不依赖某款特定CPU或运行支撑库。软件设计确保能在通用硬件设备上运行，避免对硬件和软件环境的依赖性，减少不必要的软件相关性，适应后续运行环境的变化。
3）易安装性
应用系统各软件要易于用户安装。软件产品提供安装包，安装和配置过程简单易行。用户终端不需要部署额外的软件。对部署于服务器、工作站的软件，均有独立安装包，通过远程管理软件可以远程进行软件部署安装、以及服务控制等操作，为用户提供简单方便的部署配置服务。
4）遵循性
应用系统软件开发遵循国家军用标准和适用的国家标准标准、并在此基础上建立公共软件平台标准技术体系，定义标准接口、数据规范、集成规范、开发规范等，设计共性平台技术体系，作为各模块研制的依据。公共软件平台标准技术体系设计合理的分层体系架构，支撑环境层为业务运行提供的统一基础运行环境，为系统软件提供承载平台；系统平台层具有快速集成、灵活扩展的基础软件结构，能够为上层业务软件提供稳定可靠、高效运行的平台支撑。应用软件层是系统运行的主体，主要是智能应用、数据管理、资源服务、运维管理、战场配套等针对航天训练应用需求研制的处理软件。
5）易替换性
应用系统软件模块设计要考虑易于替换，能适应需求、技术发展变化后的模块替换。应用系统软件采用组件化设计，各模块之间有明确的接口划分，降低模块间耦合度。对于系统关键模块，如数据收发服务、数据迁移服务、任务调度服务等业务运行关键模块，采用服务方式独立运行；对信息处理、情报处理等内部数据处理关键模块设计明确的输入输出参数，能够独立运行，提高安全关键模块与其他模块的分离度。由于各模块功能独立，按照标准协议制定接口规范，即使在部分模块技术变更的情况下，只要接口保持一致，模块很容易更新替换。
6）资源特性
应用系统在软件设计时不依赖于特定的计算资源，充分考虑不同应用环境下资源问题，在保证功能正确实现的基础上，尽量减少对计算机资源的需求。应用系统在软件详细设计阶段明确软件编程规范，各软件模块合理使用和释放计算机系统资源，软件根据具体执行所需合理使用CPU资源、内存资源。
1.1.7 “电磁兼容性”设计与措施
电磁兼容性设计试验符合GB 9254-2016《信息技术设备的无线电骚扰限值和测量方法标准》、GJB 1389A-2005《系统电磁兼容性要求》和GB 17625.1-2012《电磁兼容限值谐波电流发射限值（设备每相输入电流≤16A）》、GJB 151B-2013《军用设备和分系统电磁发射和敏感度要求》等相关要求。
1.1.7.1 电磁兼容性分析
由于电子设备可能导致整体电磁干扰现象激增，其中电子设备、仪器等布臵情况、内部辐射、不良接地等都会产生电磁干扰；另外也不排除人为强电磁干扰和雷电的袭击。因此需要从系统上把握电磁兼容性问题。
1.1.7.2 通用电磁兼容设计
系统通过GB 17625.1-2012《电磁兼容限值谐波电流发射限值（设备每相输入电流≤16A）》要求，电磁兼容性设计主要包括以下几方面内容：
1.1.7.2.1 总体电磁环境普查
首先应勘查阵地附近通信站、电力站等辐射源的地理位置，确定与预选阵地的距离，评估出与阵地的安全距离，以便在电磁兼容实施过程中参考。
1.1.7.2.2 防静电设计
按照GJB 3007A-2009《防静电工作区技术要求》执行。注意接地的方式和接地电阻要求。防静电接地应和防雷接地、保护接地等共用一个接地体。雷电期间禁止使用防静电措施。
1.1.7.3 机房电磁兼容设计
对于节点集成部署系统电源、传输设备、处理设备、传输线等试验验证互不干扰，包括不能影响显示监视出现波纹、抖动、模糊，不能对数据传输和处理产生干扰影响而导致数据传输出现显著误码、数值处理出现不一致错误。
为有效防止服务端存储、计算、应用服务设备的相互干扰影响，根据工程经验，各节点分系统采取加强屏蔽、滤波及良好接地等措施。
1）机架为金属结构，尽可能消除大的缝隙；
2）机柜及支撑架接地带良好搭接，保证搭接条的长宽比小于5:1；装配机房内设置信号地线和安全地线，两种地线互相绝缘、分别布设，机柜、机架要与地线可靠连接；
3）服务端机柜的需要通过UPS供电，并提供供电滤波；
4）机房内机柜间采用光缆进行通信，机柜内可采用屏蔽双绞线，屏蔽层两端严格接地；
5）电缆敷设时，避免电源电缆和信号电缆相互接近或处于同一线扎中。
6）涉及的新研设备电磁兼容要求满足GJB 151A-1997《分系统电磁发射和敏感度要求》的要求。
1.1.7.4 试验验证
为了确保电磁兼容指标要求落实到位，保证系统电磁兼容性，需要进行以下相关试验和必要的检查：
1）电磁发射和抗扰度试验，依据GJB 1389A-2005《系统电磁兼容性要求》、GJB 151B-2013《军用设备和分系统电磁发射和敏感度要求》、GB 9254-2016《信息技术设备的无线电骚扰限值和测量方法》等标准和规范中规定的要求和方法进行试验，在设计上都应达到系统内部自兼容和与所载平台互兼容；
采购的通用设备（计算机、服务器、交换机）应满足国家标准（GB9254、GB17625.1）的有关规定；
2）总体电磁兼容性检查。为了验证系统在预期的电磁环境下正常运行，必要时应对阵地、系统、设备列出检查计划，进行必要的阶段性检查。