美军的系统安全标准及体系概念定义分享

安健之泉

最近翻译学习了2012年发布的美军系统安全标准文件。其中安全概念定义与能源部文件的概念基本一致（缓解措施除外。能源部安全措施分为：预防与缓解二部分）。因为在我国的《企业标准体系要求》GB/T15496-2017里还没有体系概念定义，美军标准有“诱因，系统和体系”的概念定义，所以分享。大家可以结合本行业、单位的安全概念参考学习。

我个人认为从英文Hazard过来的危害一词危害是“危险”+“有害”的缩写词，与危险源的概念有区别。个人认为：危险源=危险之源=是各类危险能量的总称或集合。例如：机械能/电能/化学能/自然灾害释放的能量和人的不安全行为。下面是美军系统安全概念摘抄。

3.2.1可接受风险。指适当的风险接受机构（如《国防部指令5000.02》所定义）愿意接受而无需采取额外缓解措施的风险。

3.2.2采购计划。这是一种有方向、有资金支持的努力，旨在根据经批准的需求，提供新的、改进的或持续的物资、武器或信息系统及服务能力。

3.2.3诱因。引发可能导致事故的危险的一个或多个机制（驱动产生危险的具体过程或关联环节）。

3.2.4现成商用产品（COTS）。指在整个产品生命周期内无需政府进行独特修改或维护即可满足采购机构需求的商业产品。

3.2.5承包商。指与政府签订合同以提供货物或服务的私营企业实体。在本标准中，该词也适用于政府运营的从事国防采购项目开发或执行工作的活动。

3.2.6环境影响。由系统或其使用而全部或部分造成的对环境的不利变化。

3.2.7ESOH。这是一个首字母缩略词，指的是涵盖处理法律、法规、行政命令（EO）、国防部政策、环境合规、与环境影响相关的危害、系统安全（例如平台、系统、系统之系统、武器、爆炸物、软件、弹药、作战系统）、职业安全与健康、危险材料管理以及污染预防等过程和方法的学科组合。

3.2.8事件风险。指在特定硬件/软件配置下，某一危险因素在事件期间所引发的风险。典型的事件包括开发测试/作战测试（DT/OT）、演示、部署、部署后的测试。

3.2.9部署。将系统交付部队或舰队中的单位投入实际使用。

3.2.10固件。指硬件设备与驻留在该硬件设备上的只读软件形式的计算机指令或计算机数据的组合。该软件无法在程序控制下轻易修改。

3.2.11政府提供的设备（GFE）。指由政府持有或直接购置，并随后交付给承包商或以其他方式提供给承包商使用的财产。

3.2.12政府提供的信息（GFI）。指由政府持有或直接获取，随后交付给承包商或以其他方式提供给承包商使用的信息。政府提供的信息可能包括从类似系统中汲取的经验教训或其他通常非政府机构无法获取的数据。

3.2.13现成政府产品（GOTS）。指由政府机构开发、生产或拥有的硬件或软件，在产品整个生命周期内无需进行任何独特修改即可满足采购机构的需求。

3.2.14危害。指可能导致意外事件或一系列事件（即事故）从而造成人员死亡、受伤、职业病、设备或财产损坏或损失以及环境破坏的现实（明患）或潜在（隐患）状况。

3.2.15危险材料（HAZMAT）。任何由于其化学、物理、毒理学或生物学特性，可能对人员、设备或环境造成危害的物品或物质。

3.2.16人因系统集成（HSI）。对系统人力、人员、培训、安全与职业健康、居住性、人员生存能力以及人因工程等方面的要求、概念和资源进行综合全面的分析、设计和评估。

3.2.17初始风险。对已识别危险的潜在风险进行的首次评估。初始风险为该危险确立了一个固定的基准。

3.2.18严格程度（LOR）。指为确保安全关键型或与安全相关的软件功能按要求运行，所必需的软件分析和验证活动的深度和广度的规范。

3.2.19生命周期系统生命的所有阶段，包括设计、研究、开发、测试和评估、生产、部署（库存）、运行和支持以及处置。

3.2.20事故。导致意外死亡、伤害、职业病、设备或财产损坏或损失、或环境破坏的事件或一系列事件。就本标准而言，“事故”一词包括计划事件造成的负面环境影响。

3.2.21缓解措施。为消除危险所采取的行动，或者在无法消除危险的情况下，通过减轻可能发生的事故的严重程度或降低事故发生的可能性来降低相关风险的行动。

3.2.22模式。指指定的系统状态或状况（例如：维护、测试、运行、储存、运输和非军事化）。

3.2.23财产损失。指设备维修或更换、设施维修或更换、环境清理、人身伤害或疾病、环境责任等方面的预计费用总和，还应包括因预计事故而可能产生的任何已知罚款或处罚。

3.2.24非开发项目(NDI)。系统开发程序中使用的项目（硬件、软件、通信/网络等），但并非作为程序的一部分进行开发。NDI包括但不限于COTS、GOTS、GFE、重复使用项目或“按原样”提供给程序的先前开发的项目。

3.2.25概率。对事故发生的可能性的一种表述。

3.2.26项目经理（PM）。负责并有权实现开发、生产、并维持系统/产品/设备以满足用户的操作需求。项目经理负责向里程碑决策机构提供可靠的成本、进度和绩效报告。

3.2.27重复使用项目。指在某一项目中使用了先前在其他项目或不同应用中开发的项目。

3.2.28风险。事故的严重程度与事故发生的概率的结合。

3.2.29风险等级。将风险定性为高、严重、中或低。

3.2.30安全。不存在可能导致死亡、受伤、职业病、设备或财产损坏或丢失以及环境破坏的情况。

3.2.31安全关键。用于描述其事故严重性后果为灾难性或严重灾难性的条件、事件、操作、过程或项目的术语（例如，关键安全功能、关键安全路径和关键安全组件）。

3.2.32安全关键功能（SCF）。指其无法运行或运行错误将直接导致灾难性或严重事故的功能。

3.2.33安全关键项目（SCI）。通过分析确定可能对具有灾难性或严重事故潜在危害的硬件或软件项目，或者可能用于减轻具有灾难性或严重事故潜在危害的项目。本标准中“安全关键项目”一词的定义独立于公共法108-136和109-364中“关键安全项目”一词的定义。

3.2.34安全相关。用于描述其事故严重程度后果为轻微或可忽略不计的状况、事件、操作、过程或物品的术语。

3.2.35安全重要。用于指被认定为安全关键或安全相关的状况、事件、操作、过程或项目。

3.2.36危害程度。事故潜在后果的严重程度，包括：死亡、受伤、职业病、设备或财产损坏或损失、环境破坏或经济损失。

3.2.37软件。指一组相关的计算机指令和计算机数据，使计算机能够执行计算或控制功能。软件包括计算机程序、规程、规则以及与计算机系统操作相关的任何相关文档。软件包括系统中使用的新开发软件、复杂可编程逻辑器件（固件）、非标准设备接口（NDI）、商用现货（COTS）、政府现货（GOTS）、再利用软件、政府提供的设备（GFE）以及政府开发的软件。

3.2.38软件控制类别。指在系统行为的上下文中，对软件功能的自主程度、指挥和控制权限以及冗余容错能力的分类。

3.2.39软件复用。在开发项目中，将先前开发的软件模块或软件包用于软件应用程序。

3.2.40软件系统安全性。将系统安全原则应用于软件。

3.2.41系统。在规定的环境中为实现指定功能而所需的硬件、软件、材料、设施、人员、数据和服务的组织，且需达到规定的结果。

3.2.42系统之系统（SoS）[ 翻译者认为“系统之系统”定义同样适用于体系定义。]。指一组相互依存的系统，这些系统相互关联或连接，以提供特定的能力。

3.2.43系统安全性。在系统整个生命周期内，运用工程和管理原则、标准及技术，在满足运行效能和适用性、时间及成本限制的条件下，实现可接受的风险水平。

3.2.44系统安全工程。这是一门运用专门知识和技能，将科学和工程原理、标准及技术应用于识别危险，并在无法消除危险时消除危险或降低相关风险的工程学科。

3.2.45系统安全管理。在系统、子系统、设备和基础设施的设计、开发、测试、采购、使用和处置过程中，为识别危险；评估和降低相关风险；以及跟踪、控制、接受和记录所遇到的风险而制定的所有计划和采取的所有行动。

3.2.46系统/子系统规范。针对给定系统的系统级功能和性能要求、接口、适配要求、安全和隐私要求、计算机资源要求、设计约束（包括软件架构、数据标准和编程语言）、软件支持、优先级要求以及开发测试要求。

3.2.47系统工程。项目团队为实现从所陈述的能力向具备实际操作效能和适用性的系统转变而采用的总体过程。系统工程涉及在整个采购生命周期（适应每个阶段）应用系统工程流程，并旨在成为平衡解决能力需求、设计考虑因素和限制条件的整合机制。系统工程还解决技术、预算和进度安排所施加的限制。系统工程流程在物质解决方案分析的早期阶段即开始应用，并在整个生命周期中持续进行。

3.2.48目标风险。项目管理团队计划通过实施与4.3.4节所述设计优先顺序一致的缓解措施而达到的预计风险水平。

3.2.49用户代表。对于装备部署事件，指在联合能力集成与开发系统（JCIDS）流程中正式指定代表单个或多个用户参与能力开发和采购过程的司令部或机构。对于非装备部署事件，用户代表将是负责面临风险的人员、装备和环境的司令部或机构。对于所有事件，用户代表应与风险接受权限处于同等层级。

系统安全过程的八要素。

严重程度类别。