2.1 NAV-1 概述与摘要信息

通用开放士兵系统参考架构（ GOSSRA ）在本文档中描述，代表了 GOSSRA 联盟为后续标准化提出的建议。

标准化本身不在本项目范围内。然而，联盟计划向北约 “ 陆地能力组步兵系统 ” （ LCG DSS ）下属的 “C4I 与系统架构 ” 工作组提出该架构，该工作组在项目期间通过 GOSSRA 演示和讨论持续关注该工作。

该架构由一组文档组成，包含七个卷：/1/ 、 /2/ 、/3/ 、/4/ 、/5/ 、 /6/ 和/7/ ，包含根据北约架构框架 v3.1 的不同架构视图，并增加了安全视图（见图 2-1 ). 它配有一个由一组计算机文件表示的形式架构，使用 SparxSystems 企业架构师（ 13 版 ） / 8/ 编译。

图 2-1 – GOSSRA 文档结构

针对士兵系统的开发基于以下假设：

• 这是一个参考架构 。它包含了共同的最佳实践，并不描绘任何一个国家的解决方案。当各国定义、指定或开发其特定的步兵系统时，可能会选择以此架构为参考。
• 作为参考架构，它 并不打算决定采购或采购决策 。相反，它旨在作为解决方案开发的模板。
• 各国有责任 利用该参考创建目标架构（解决方案）， 以体现其实现，包括针对特定角色的具体设备。
• 参考架构 标准化了创新预期缓慢的特定方面 ，但 保留创新快速且需要竞争的选项 。
• 国家在创建包含士兵系统的系统架构 时，也负责使用该参考。
• 这种架构不仅模拟 了一个小队，也展示了单一士兵 。我们认识到士兵们不独立行动，是联网的，并且共享装备（尤其是车辆平台）。小队还包括执行不同角色的士兵，例如指挥官、机枪手、狙击手、侦察兵、医护兵或其他任务特定角色，因此需要不同的装备。
• 该架构关注 士兵所穿戴、携带和使用的 电气和电子设备，以及 软件和数据通信 。
• 该架构包含 互操作性、互换性和共性 等概念。
• 该参考架构并非严格盲目遵循北约架构框架中的流程和观点，而是利用其底层概念高效开发被 认为对 目的和社区有用的 视图 。

2.1.1 识别

这套文档代表了 “GOSSRA 标准化架构 ” ，即 GOSSRA 项目的交付物 D8.5 。

该架构由 GOSSRA 联盟于 2019 年 5 月 6 日至 2020 年 4 月 30 日期间开发。由德国莱茵金属电子有限公司领导的 GOSSRA 联盟涵盖来自 7 个国家的 9 个参与者： GMV （西班牙）、 iTTi （波兰）、 Tekever -ASDS （葡萄牙）、 Larimart （意大利）、 Leonardo （意大利）、 SAAB （瑞典）、 Indra （西班牙）和 TNO （荷兰），并获得了为期 23 个月（ 2018 年 7 月 1 日至 2020 年 4 月 30 日）约 150 万欧元的欧盟资助。

这些公司包括主要的欧洲士兵系统公司，这些公司已经大量开发并交付了士兵系统。此外，参与者是较小的公司，他们提供了子系统或组件，并为项目贡献了具体且宝贵的专业知识。最后，一个研究机构提供了关于最新发展和技术的知识。

以下是 GOSSRA 项目团队成员：

• Rheinmetall Electronics GmbH (DEU, prime contractor)
  • Dr. Norbert Härle (Contract Manager)
  • Erik Wimmer (Deputy Contract Manager)
  • Daniel Riggers (Technical Coordinator)
  • Dr. Deepak Das (Technical Expert)
• GMV Aerospace and Defence (ESP)
  • Jose Luis Delgado (Project Manager and Technical Expert)
  • Ricardo Sáenz Amandi (Technical Expert)
  • Vicente Javier de Ayala Parets (Technical Expert)
  • Iñigo Barredo (Technical Expert)
  • Gustavo Alberto García García (Technical Expert)
• ITTI Sp. z o.o. (POL),
  • Piotr Gmitrowicz (Project Manager and Technical Expert)
  • Łukasz Szklarski (Technical Expert)
  • Patryk Maik (Technical Expert)
  • Mateusz Oles (Technical Expert)
• Tekever ASDS Lda. (PRT),
  • António Monteiro (Project Manager)
  • Duarte Belo (Technical Expert)
  • Aleksandra Nadziejko (Technical Expert)
  • Filipe Rodrigues (former Project Manager & Technical Expert)
  • André Oliveira (former Project Manager & Technical Expert)
• Larimart SpA (ITA),
  • Marco Stella (Technical Expert),
  • Fabrizio Parmeggiani (Project Manager and Technical Expert)
  • Luigi Esposito (Technical Expert)
• Leonardo SpA (ITA)
  • Francesco Fedi, LDO (Principal Editor)
  • Rosa Ana Lopez Mazuelas (Technical Expert)
  • Fabio Casalino (Technical Expert)
  • Francesco Cazzato (Project Manager)
  • Antonio DiRocco (Technical Expert)
  • Mazzulli Vanessa (Technical Expert)
  • Zamburru Lorenzo (Technical Expert)
• SAAB AB (SWE)
  • Dennies Olesen (Technicas l Expert)
  • Pär-Åke Anderkrans (Project Manager and Technical Expert)
• Indra (ESP)
  • Pablo Martínez Mena (Project Manager)
  • Ángel Pérez Martín-Nieto (Technical Expert)
• TNO (NLD)
  • Marcel van der Lee (Technical Expert)
  • Angela Kwaijtaal (Project Manager)
  • RonaldRonald in 't Velt (Technical Expert)
  • ; Eelco Cramer (Technical Expert)

除了联盟外， GOSSRA 项目还设立了一个利益相关者咨询委员会，成员包括以下欧洲政府的代表：

• NLD
  • Luc de Beer (Mindef, DMO, DP&V, Ressort Projecten, Soldier System Procurement)
  • Major Koen van Veen (Defence Centre of Expertise for Soldier and Equipment)
  • Jasper Groenewegen (DNV GL)
• DEU
  • Dr. Karl-Heinz Rippert (Federal Office of Bundeswehr Equipment, Information Technology and In-Service Support, Soldier System Procurement)
• ITA
  • Magg. Ing. Mattia Bevilacqua (Ministero della Difesa, IV Reparto “Coordinamento dei programmi di armamento”, Direzione di Programma “Forza NEC”)
  • Ten. Col. Vincenzo Bello (Ministero della Difesa, IV Reparto “Coordinamento dei programmi di armamento”, Direzione di Programma “Forza NEC”)
  • Col. Mauro Fanzani (Ministero della Difesa, IV Reparto “Coordinamento dei programmi di armamento”, Direzione di Programma “Forza NEC”)
• ESP
  • Col. Antonio Varo Gutiérrez (ET MDE)
  • Col. (ET) Moisés Serrano Martínez (ET MDE)
• PRT
  • Lt. Col. Luís Paz Lopes (Portugese Army)
  • LTCol Simão Sousa (Portugese Arm

特别感谢他们的反馈和贡献。

2.1.2 范围

2.1.2.1 架构 范围

通用开放士兵系统参考架构（ GOSSRA ）的目的是作为欧盟 / 北约层面的通用参考架构，用于在国家层面推导目标架构。

本参考架构全面关注：

• 软件
• 电子设备
• 语音与数据通信
• 传感器
• 效应器
• 人机界面设备
• C4I

该士兵系统参考架构已准备好公开标准化，且不意味着任何受保护的知识产权。该架构将在未来至少十年内应用，将考虑能力、运营和技术的趋势和潜力。

该架构代表 “ 最佳实践 ” 、 “ 未来趋势与发展 ” ，并建议标准接口。该系统应作为推导 “ 目标架构 ” 的参考，目标架构是针对特定士兵系统的架构。

通过引用该参考架构，即 “ 目标架构 ” ，则可：

• 更易于开发，
• 包含所有主要方面，
• 使用特定的通用标准，实现互操作性。

2.1.2.2 架构框架

本参考架构应跟进其他项目、研究或工作组已完成的工作，并符合北约架构框架（ NAF ） v3 ，该框架是 EDA 架构库的必需，并被许多欧洲和北约国家采用（ NAF v3.1/9/ 、 /10/ 和/11/ ）。

2.1.2.3 视图与子视图

采用了北约架构框架 NAF v3.1 及其指导方针的概念。 NAF v3.1 中选定的视图如下

• 全局视图 ，
• 能力视图，
• 运营 视图 ，
• 面向服务的视图 ，
• 系统视图，
• 技术视图,

NAF v3.1 视图由 安全视图 扩展，安全视图涵盖士兵系统的所有安全方面，并关联多个 NAF v3.1 视图。

2.1.2.4 参考架构与目标架构

参考架构的范围是提供一套一致的架构最佳实践、高层解决方案、指南、建议和标准，形成一个资产基础，以从中衍生独立的目标项目。参考架构通常在共同的总体架构下开发。

图 2-2 – 从整体架构到目标架构的路径

作为一种参考架构， GOSSRA 旨在为最广泛的用户提供一个方便使用的模板，如开发系统组件的软硬件工程师、需要采购和维护系统的利益相关者、通信专家等。

为了实现这一雄心勃勃的目标， GOSSRA 模板依赖基于视图和域的二维结构。 GOSSRA 所遵循的北约架构框架标准化了系统必须考虑的视图，以全面代表系统。随后， NAF 视图根据五个领域描述，不仅涵盖 DSS 本身 ，还包括与对等及更高级别系统的交互。

图 2-3 – GOSSRA 视图和域

源自 GOSSRA 的目标架构，即实际的 DSS 项目及其相关能力、服务和基础设施，更易于开发、采购和维护。此外，通过遵循相同的原则和标准，所有衍生的目标架构都易于互操作，并能共享多个方面，包括项目治理和管理。

该方法论确保每个目标架构可以独立开发，例如符合国家的具体需求和特性，同时仍能享受符合 GOSSRA 规范的能力。

此外，派生目标架构不必实现模板涵盖的所有细节。但每当需要开发相关方面时， GOSSTRA 可以提供理性且合理的解决方案。

2.1.3 上下文背景

2.1.3.1 士兵系统领域的技术挑战

随着民用领域微型化、强大电子和计算能力的成功，以及军事领域对网络系统和子系统、信息交流的广泛需求，士兵系统正越来越多地实现 x 。

此外，士兵系统在所有相关数据的掌握下可以更高效地使用。这些数据不仅由士兵本人或他们携带的系统产生，还将越来越多地来自其他来源（高层单位、车辆、其他士兵、无人值守传感器等）。因此，通过共同通信网络，士兵系统与这些来源之间的数据交换至关重要。

2.1.3.2 开发、采购与互操作性中的挑战

将采购的士兵系统架构由许多欧洲国家的士兵系统公司单独开发。

如今，大多数欧洲 / 北约国家都有自己对士兵现代化计划的方案。许多国家仍处于原型阶段或现代士兵系统的概念开发。结果是各国特定的系统，除例外，这些系统都是专有的，完全缺乏电气、电子和 IT 方面的互操作性。然而，在欧盟 / 北约联盟背景下，甚至与非军事伙伴合作，都需要高度的互操作性。

2.1.3.3 通用架构及其优势

多年来，开放架构或通用架构开始被视为使复杂系统可管理和实现的关键。同时，此类参考架构使士兵系统的经济性通过以下方式实现

• 通过对所有系统进行完全联网，提升运营效率，
• 通过标准化和互操作性减少集成工作，
• 通过升级易于集成的子系统实现创新，
• 通过使子系统可互换来增强竞争，
• 通过采用子系统和集成方法，采用高技术准备水平（ TRL ）来降低技术风险，
• 通过减少不同子系统的种类，减少后勤和维护工作，以及
• 增加供应商数量，并采用统一的技术方法。

2.1.3.4 对联邦任务网络（ FMN ）和 TES （战术边缘联盟） 计划的 潜在影响

联邦任务网络（ FMN ）是北约中的一种框架，旨在为联盟环境中的信息共享提供一种有效且高效的手段。该能力 旨在通过改进信息共享，支持未来作战中的指挥控制和决策。它提供了应对未来北约行动中任何任务环境新兴需求的敏捷性、灵活性和可扩展性。

联邦任务网络基于包括成本效益和最大程度重复利用现有标准和能力的原则。联邦任务网络建立在阿富汗任务网络（ AMN ）实施和北约网络赋能能力计划/13/ 的经验教训基础上。

FMN 的主要功能战略目标是提供：

• 全军范围内无缝的人际沟通，
• 这是任务网络中战场的单一视图。

FMN 的范围主要针对任务区域的多国网络，涵盖更高层级（部署、固定）层级，如多国指挥所。然而，最近 FMN 内部成立了一个新的工作组，专注于战术层面。

该战术边缘联盟（ TES ）受 FMN 能力规划工作组委托，负责制定联邦任务网络中 与作战信息交换相关的规范 ，涵盖从旅指挥到营、连和排级的指挥与控制（ C2 ）层级，在战术和机动边缘。

建议 TES 工作组考虑并分析该参考架构。

在制定作战信息交换规范时， NCV （能力视图）和 NOV （作战视图）对于描述小型战术单位信息需求的通用性资料具有重要意义。此外， NSOV （面向服务视角）提供了一套类似于北约 C3 分类法的服务，但目标是最低战术层面。

关于拟议的标准和协议， TES 应考虑 NSV （系统视图）和 NTV （技术视图）中的建议，特别是两个国际互操作性标准（ STANAG 4677 《步兵系统标准与协议》（指挥、控制、通信与计算机互操作性（ C4 ））和 VMF （可变消息格式））应纳入 FMN 。对 TES 来说，最相关的是联盟和联合领域，而个人、 STU 和跨平台领域可能与 FMN 相关性较低。

2.1.4 目标与目的

2.1.4.1 目标

总体目标是拥有一个广泛可用且标准化的参考架构，以便广泛用于士兵系统的定义、设计和开发，从而在推进士兵系统方面迈出更大一步，减少工作量和成本。

2.1.4.2 目的

通用开放士兵系统参考架构（ GOSSRA ）的目的是代表一个全面的士兵系统架构，使其能够

• 促进国家步兵项目在系统层面和组成部分层面的互操作性和互换性，
• 使士兵能够为每次任务配备易于互换的装备，
• 考虑以减少布线工作量的数据分发概念，
• 福斯特协调了士兵系统开放电力架构的 “ 即人 ” 概念，
• 允许模块化方案支持不同士兵的装备配置，
• 包含操作、系统和技术架构视图，
• 应朝向标准化方向发展，
• 并由制定标准的路线图支持，
• 所需的整合工作量大幅降低，
• 增加零部件生产数量，
• 降低生命周期成本，
• 指导组件开发者，
• 充分利用商业现成产品（ COTS ）。

2.1.4.3 士兵系统采购的决策支持需求

该架构的目的还包括为士兵系统采购提供决策支持。采购士兵系统的决定需要回答以下几个问题：

• 必须支持哪些能力？
• 哪些运营问题重要？
• 系统及其子系统期望提供哪些服务？
• 如何构建这个系统？
• 需要考虑哪些子系统，以及如何与之对接？
• 子系统需要提供哪些接口？
• 需要考虑哪些组件和设备？
• 目前有哪些技术可用，未来又有哪些技术？
• 哪些标准是相关的？

2.1.5 工具与文件格式

该架构被编译为 Microsoft Word 文档，并以 PDF 便携格式文件形式分发。这些图形使用 Microsoft Visio 、 Microsoft PowerPoint 和 SPARX SYSTEM 的 EA 开发 。

文档附有一组由 SPARXSYSTEM 的 EA 工具生成的文件，这些文件表示参考架构作为形式架构。

2.2 发现

本章总结了在第 2 卷至第 6 卷中 “ 能力、运营、面向服务、系统、技术和安全视角中发展出的架构核心方面，并提出了以下愿景。

• 各国都参考了这种参考架构。
• 士兵系统提供商生产符合参考架构的士兵系统。
• 士兵系统供应商生产符合该参考架构的设备。
• 士兵系统成本更低，更适合采购的用途。
• 每位士兵都将配备一套高度现代化的士兵系统，受益于最新技术发展，并针对其特定角色进行了优化。
• 通用架构允许采购机构和用户为士兵系统、子系统或设备选择最合适的供应商，促进开放竞争和定价。

2.2.1 能力视图（ NCV ，第 2 卷）

能力视图描述了下车士兵和小型战术单位（ STUs ）的能力，这些单位可能包括考虑联合和联合作战的相关移动平台。 STU 代表一群个体士兵，根据具体国家需求和特点，组织为军事队、军队、连或其他组织。

士兵随后被分为：

• 个人或基础士兵（例如基础步兵系统），
• 特种士兵（例如配备额外专业装备），
• STU 领导者 。

能力愿景（ NCV-1 ）描述了以下能力目标，分为八个能力类别（见 图 2-4 ）：

2.2.1.1 指挥、控制、通信、计算、情报（ C4I ）

DSS 应为步兵士兵提供支持，解答核心问题（ “ 我的任务是什么 ” 、 “ 我在哪里 ” 、 “ 我的战友在哪里 ” 、 “ 敌人在哪里 ” 、 “ 我的环境是什么 ” ），具体如下：

多感官方法、自动化功能、增强的基于无线电的作战识别（RBCI）、快速且丰富的信息共享、战术与个人选择以及半球感知。

2.2.1.2 情报、监视、目标获取、侦察（ ISTAR ）

DSS 应提供 ISTAR 能力，主要用于提升士兵的态势感知、目标获取与指定以及决策能力，具体如下：

信息融合、STU作为传感器、数据采集与分析、CROP（共同相关作战态势）、战术增强现实（TAR）、电子战韧性网络、信息安全与访问控制、非人类智能合作以及智能电源管理与系统。

2.2.1.3 有效参与

DSS 应提升士兵在白天、夜间及全天候条件下与目标交战的协调与支持，包括

转角射击、自动射击控制、身体佩戴传感器集成、战术增强现实（TAR）、电子战（EW）以及轻武器传感器网络。

2.2.1.4 机动性

DSS 应使士兵能够在各种地形和环境条件下，无论是骑乘还是下车都能不受阻碍地移动，在特殊配置情况下，还能通过在困难和 “ 禁行 ” 地形中增强机动性

体积、重量和功率（SWaP）（减少运输需求，结合功能、外骨骼、士兵冷却）、自动驾驶车辆及其应用（货运载具、UGV、新型燃料/发动机）、数字化（模块化）。

2.2.1.5 防护与生存能力

DSS 应帮助士兵忍受战场或作战区域的身心压力，通过自适应伪装、隐蔽传感器以及防护敌方火力、弹片、刺击武器和战斗噪音，包括

防范非致命高功率武器、电子战、CBRNE、零排放（热成像、电磁发射、通信、视觉）、带生物识别传感器的服装、温度管理/气候控制以及综合防护。

2.2.1.6 可持续性与物流

DSS 应使士兵能够根据任务需求配置装备 ; 无论是提前还是任务期间。可持续性体现的是士兵能够更长时间地操作 DSS ，通过以下方式

集成物流、可持续电力、连接器的通用性与互换性、潜在替代电源、增强模块化、自动化原位软件更新与设备升级、生产与制造模式、增材制造以及空中补给。

2.2.1.7 教育与培训

DSS 应使士兵能够 通过多种训练方法（电子学习、虚拟现实（VR）、游戏软件重复使用、C4I系统作为训练背带、训练设施作为复合体等多种操作设备来训练该系统

任务期间， “ 硬件环路 ” ，人工智能（ AI ）支持），使得

多个培训领域（个人技能发展、 “C4I” 培训、平台培训、安全与医疗培训、用户级维护、集体训练 / 战术训练、联合 / 联合训练）。

2.2.1.8 多国互操作性

该能力目标重点是解决战术、技术和后勤互操作性方面的具体空白。

图 2-4 – 能力愿景的分类

能力分类法（ NCV-2 ） 基于之前介绍的能力目标，定义了整个架构中使用的能力的词汇。

能力之间的依赖关系在 NCV-4 能力依赖中进行了展示。

最后，在 NCV-6 能力到活动映射 中，能力目标按子能力划分，如分类法（ NCV-2 ）所述，与作战活动相关 。 NCV-6 表明了各项能力如何参与多项作战活动。

2.2.2 作战视图（ NOV ，第 3 卷）

高 级别作战概念描述（ NOV-1 ），见 图 2-5 ， 是根据配备 DSS 的 soldie r 作战的典型场景和情境定义的。

图 2-5 – 高层次作战概念描述

总体而言，下步兵系统（ DSS ）的广泛需求涵盖多个军事分支的作战，包括除常规步兵外的装甲兵、工程兵团、山地步兵、海军陆战队、伞兵、特种作战部队等。

军事行动的基本概念在此观点中定义，并更详细地描述了新的群体 化概念。此外，分析了作战需求，重点关注互操作性和提升士兵系统效能的方法。

最后，将敏捷指挥与控制概念与传统 C2 概念进行比较。

运营节点连接描述（ NOV-2 ） 展示了运营领域在支持运营活动中的信息交换需求。 该部门细分为：

• 士兵节点内部连接（ 士兵个人领域 ），
• 小型战术单元（ STU ）节点内部连接（ 小型战术单元域 ），以及
• 小型战术单位（ STU ）节点外部连接（ 平台内域、联合域、联盟域 ）。

操作需求（ NOV-3 ）确定 了上述列表中每个领域信息空间中所需的信息。

其中一个具有挑战性的目标是设计一个能够高效提供准确完整态势感知的 DSS ，并在最大程度上减轻士兵的负担。信息过载是一个已知且重要的压力因素，尤其对战斗中的士兵来说。因此，额外设备增加的重量 / 体积 / 功耗增加与机动性之间的权衡需要谨慎权衡。

组织关系图（ NOV-4 ）， 见 图 2-6 ，识别了运营领域的关键参与者，并展示了它们之间的组织关系。该图表是通过从不同欧洲国家的组织中提取并协调而成。能力视图中提到的三种 通用角色相关配置 有更详细的描述

其他联合作战分支，如装甲兵、炮兵、工程兵团、陆军航空兵、信号兵团、近距空中支援、核生化防御军团、后勤军事单位、宪兵、军事运输服务、地理信息服务、医疗服务、非政府组织以及地方 / 国际当局，均被识别并描述其关系。

运营活动模型（ NOV-5 ） 定义了 C4I 活动、通用任务以及不同类型操作的具体任务：

• 战斗 / 交战，
• 维和行动
• 维和行动
• 维和执行
• 和平建设，以及
• 人道主义行动。
• 机械化步兵高强度攻击（ 24 小时）
• 与特种部队的军事撤离行动（ 72 小时），以及
• 与正规步兵的围堵与搜索行动（ 36 小时）。

特别指出 了 NOV-6 的作战活动序列和时间描述， 包含三种具体情景

为参与士兵制定了典型的活动安排及其在不同时长（ 24 、 36 和 72 小时）中使用士兵系统组件的作战。

还识别出非功能性需求 。这些要求虽然不严格操作且非 NAF v3 指南要求，但在设计 DSS 时是重要的限制。

2.2.3 面向服务的观点（ NSOV ，第 4 卷）

在 NSOV 中，服务被理解为一种明确定义的提供工作单元的方式，通过该单位，提供者向消费者提供有用的结果，无论服务的构建或实施如何。

面向 服务 视图服务的识别和定义主要考虑了两种服务类型：

• 作战服务： 由个别士兵或特种部队向高级部队或其他单位提供的服务
• 功能服务： 士兵系统为士兵 /STU 提供的服务

企业服务 是未来考虑的，仅简要提及，未作详细定义。

NSOV-1 服务分类 法定义了这些服务类型的服务（见 图 2-7 ）。

运营服务 根据能力视图中已定义的能力目标定义。从这些作战服务中，技术系统会派出功能服务，以支持士兵执行作战服务。

士兵系统在 NSV 系统视图中定义，使其恰好提供这些功能性服务。

NSOV-2 服务定义 对分类法中定义的每个服务提供了详细描述。因此，阅读分类学时查阅描述是很有用的。

最后， NSOV-3 作战活动服务映射 将作战服务映射为 NOV 作战视图中定义的活动。

图2-7 – DSS 服务

2.2.4 系统视图（ NSV ，第 5 卷）

北约系统视图描述了为所需功能提供支持的系统和子系统。它将系统资源关联到 NCV 能力视图、 NOV 操作视图和 NSOV 面向服务视图。识别并使用了以下不同的领域：

• 士兵个人领域 ，作为独立单位满足下步士兵的需求。
• 小型战术单位领域 ，满足以步兵为节点的小队或小队的需求。
• 跨平台域 ，作为节点满足士兵的需求，该节点与另一个平台（例如载具）交互。该领域还包括 NGVA 车辆中的骑兵士兵。
• 联合领域 作为节点，满足步兵的需求，与不同部队单位互动。
• 联盟领域 作为节点满足步兵需求，与盟军单位互动。

人们认为最重要的是不要单纯关注某个士兵，而是他如何在环境中与所有人，尤其是群体中行动，这实际上是士兵的常规应用。标准化文档根据上述领域结构化，使读者能够直接找到自己感兴趣的领域。

首先，系统视图介绍系统域以及士兵系统设备和配置（见 图 2-8 示例）。

图 2-8 – 不同角色所需设备示例

然后，上述领域进行了详细说明。主要部分包含每个域的分层参考架构。参考架构层从上层开始是：

• 士兵应用 ，定义了设计士兵应用的关键架构概念，
• 可以轻易演化，
• 每个组件高度聚焦于特定能力，
• 其组件松耦合，以最大限度减少组件变化对其他组件的影响。
• C4I 应用 ，定义了 C4I 应用家族的参考架构。具体来说，针对以下 C4I 功能领域的应用架构进行了研究：
• 战场管理服务，
• 态势感知，
• 系统管理，以及
• 人类 RAS （机器人与自主系统）交互。
• 数据交换服务 ，定义了涵盖所有战术、控制和管理数据流的应用组件之间数据交换的协议集。为满足各领域不同的数据交换需求，已选择了不同的协议套件。数据交换服务在应用组件松耦合中起着关键作用。
• 语音与数据通信 ，定义了支持数据交换服务的协议层集合，即向下连接至无线信道的网络，以传输数据和语音。具体来说， “ 波形 ” 概念被采用为设计解决方案，利用软件定义无线电能力提供标准化协议套件，提升联合多国行动中的通信灵活性和互操作性
• 电子元件 ，定义了 DSS 的物理架构，即其组件之间的信号和功率分配。布线和电力管理的关键问题也得到了解决，以提升国家设备间的互操作性并减少 SWaP 。

此外，还提供了易于阅读的指导，涵盖架构的强制性和可选要求。它们对于确保所选标准的合规使用尤为重要。为了提供更好的概述，标准在协议栈图中表示，如 图 2-9 和 图 2-10 所示。

系统视图明确定义了最重要的内部、外部接口和概念为必备，例如实现设备的互操作性或互换性（见 图 2-9 和 图 2-10 ）。在个人领域，五大类接口被描述为强制标准。

系统 总线 决定采用 USB 3.1 第二代有线连接。由于这是 Solider Systems 的新技术， USB 2.0 被定义为备用技术。无线连接时，选择 4.2 版本的蓝牙，或用于极短距离连接的 NFC 。

为了通用连接设备，定义了 连接器和信号 。在该架构编写时，尚未能找到标准化的 USB 3.1 第二代连接器，但不同厂商宣布了可能的解决方案，如推荐的 Micro 38999 。因此， USB 3.1 第二代所需的信号被定义为允许连接器的互换针脚。关于 USB 2.0 连接， STANAG 4695 是一个很好的参考，也被军事领域其他领域考虑使用。

为了在士兵系统（个人域）中的设备或实体之间交换信息， MQTT 被定义为 信息交换机制（ IEM ）。 MQTT 在计算资源和带宽的利用率上尤其出色。随着在民用领域（例如工业 4.0 ）的普及，广泛存在可互换的参考实现，具有高 TRL 的特性，降低了 DSS 市场的风险（例如对提供外设的公司）。

此外，对于个人领域中更复杂的信息交换任务，选择数据分发服务（ DDS ）作为可选协议。 DDS 提供高效的信息交换和更新，例如对于拥有大量设备或实体的 BMS 域。

为了确保数据互操作性，除了信息交换机制外，还需要描述存储信息的数据 结构 。这些数据结构定义在使用 XSD 和 XML 进行数据交换的数据模型中。

士兵系统设备推荐的数据模型基于英国陆地数据模型，该模型是 GVA （英国国防飞机 23-09 ）和 NGVA （北约标准 4754 ）的基础。由于英国陆地数据模型缺少 C4I 数据， C4I 取自 STANAG 4677 的数据模型（ JDSSDM ），因此满足士兵系统领域的大部分需求。

在多媒体目的下，建议支持和使用最常见的标准，如 H.264/H265 、 MP3 、 G.711 、 JPEG 、 PNG 和 TIFF 。

为了提高士兵系统的可扩展性，定义了一个 基于 APP 的人机界面概念 。这一概念结合 图 2-9 和 图 2-10 中的图层，使不同士兵系统之间的应用能够移植，并适应新的设备或能力。

关于外部接口，即小型战术单位、联合和联盟领域，建议填写以下内容。

个人 领域的连接器和信号 也支持不同国家士兵系统之间的设备和电池交换。

广泛采用北约标准 STANAG 4677 和 STANAG 5525 ，用于 士兵系统之间的通信，实现与联盟和联合部队的互动。然而，这些标准也推荐用于小型战术单位领域，使士兵系统更具未来性，并为其他供应商开放。因此，不同厂商在同一部队内实现士兵系统成为可能。

对于 ISR 视频流及 相关任务，推荐使用 STANAG 4609 及相关北约标准。

图 2-9 – 个人域名标准

图2-10 – STU 、联盟与联合领域标准

2.2.5 技术视角（ NTV ，第 6 卷）

NTV-1 技术标准配置文件陈 述了这些标准，这些标准经过精心挑选并推荐用于士兵系统的电气和电子组件。

NTV-1 的重要部分涉及无线电通信标准，包括视距（ LoS ）或视距外（ BLoS ），这些标准涉及 VHF/UHF 和 HF/SATCOM 。以下类别还提供了更多标准表：

• 物理接口，
• 媒体格式，
• 数据交换服务，
• 交通服务，
• 音频交流，
• 遥控器，
• 能源质量，
• 能源 / 电力管理，
• 产品一致性，以及
• 法律与法规。

这些表格分为通用标准（如产品一致性）和系统视图中实际引用的标准。

NTV-2 技术标准预测 讨论了主要推荐标准的发展过程，并预测这些标准将如何演变，以便首次评估未来概念的可行性。

2.2.6 安全视图（第 7 卷）

安全视图为 DSS 的 IT 安全风险评估（ SRA ）提供了推荐的方法。安全风险评估用于识别由潜在网络威胁引发的风险。了解这些风险后，组织可以判断是否、如何以及何时需要减轻这些风险，以最大限度减少潜在威胁对其实现目标的运营影响。

DSS 的安全问题可以根据士兵系统的数据交换通信场景进行组织。这种示意有助于制定 DSS SRA 并确定保障措施。 DSS SRA 基于 MAGERIT 方法论 / 12/ ，该方法使用 F igure 2-11 所示的循环过程模型 进行风险管理。该框架适用于各种风险，但这里适用于信息系统使用带来的风险。

图 2-11 – 风险管理框架

在描述 MAGERIT 方法的关键步骤之后，

• 识别了关键的 DSS 资产，
• 对每个资产类别进行威胁分析，
• DSS 的初始风险通过使用相应的软件工具来识别。

该架构中已确定了一套保障措施以降低初期风险。同时考虑了降低威胁发生概率的预防措施和限制后果的事后保障措施。

DSS 的保障措施从 SRA 工具建议的适当措施中选择，并根据 NIST 安全控制系统进行管理。 DSS 确定了技术保障措施，重点关注四大类：

• 与访问控制机制（ AC ）相关的保障措施
• 与身份识别与认证机制（ IA ）相关的保障措施
• 与审计机制相关的保障措施 [AU]
• 与安全通信（ SC ）相关的保障措施

2.3 NAV-2 综合词典

2.3.1 缩写

2.3.2 参考文献

2.3.2.1 GOSSRA 文件的参考文献

/1/ GOSSRA Architecture for Standardisation – Volume 1 – All View (NAV) and Summary, PADR-FPSS-01-2017: GA 800783 GOSSRA (Generic Open Soldier System Reference Architecture), BL8464A037 REP, (GOSSRA Deliverable D8.5), V1.0, 30-04-2020

/2/ GOSSRA Architecture for Standardisation – Volume 2 – Capability View (NCV), PADR- FPSS-01-2017: GA 800783 GOSSRA (Generic Open Soldier System Reference Architecture), BL8464A037 REP, (GOSSRA Deliverable D8.5), V1.0, 30-04-2020

/3/ GOSSRA Architecture for Standardisation – Volume 3 – Operational View (NOV), PADR- FPSS-01-2017: GA 800783 GOSSRA (Generic Open Soldier System Reference Architecture), BL8464A037 REP, (GOSSRA Deliverable D8.5), V1.0, 30-04-2020

/4/ GOSSRA Architecture for Standardisation – Volume 4 – Service Oriented View (NSOV), PADR-FPSS-01-2017: GA 800783 GOSSRA (Generic Open Soldier System Reference Architecture), BL8464A037 REP, (GOSSRA Deliverable D8.5), V1.0, 30-04-2020

/5/ GOSSRA Architecture for Standardisation – Volume 5 – System View (NSV), PADR-FPSS- 01-2017: GA 800783 GOSSRA (Generic Open Soldier System Reference Architecture), BL8464A037 REP, (GOSSRA Deliverable D8.5), V1.0, 30-04-2020

/6/ GOSSRA Architecture for Standardisation – Volume 6 –Technical View (NTV), PADR-FPSS- 01-2017: GA 800783 GOSSRA (Generic Open Soldier System Reference Architecture), BL8464A033 REP, (GOSSRA Deliverable D8.5), V1.0, 30-04-2020

/7/ GOSSRA Architecture for Standardisation – Volume 7 – Security View, PADR-FPSS-01- 2017: GA 800783 GOSSRA (Generic Open Soldier System Reference Architecture), BL8464A037 REP, (GOSSRA Deliverable D8.5), V1.0, 30-04-2020

/8/ GOSSRA Architecture Formal File for Standardisation, PADR-FPSS-01-2017: GA 800783 GOSSRA (Generic Open Soldier System Reference Architecture), BL8464A037 REP, (GOSSRA Deliverable D8.4), V1.0, 30-04-2020

2.3.2.2 文档相关参考

/9/ NATO Architecture Framework, Version 3, Annex 1, (AC/322)D(2007)XXX

/10/ Guidelines for the Development of Architectures Compliant to NAFv3, EDAU1/1201/RP/008 - 2013, 12/08/2013

/11/ Guidelines for the Development of Architectures Compliant to NAFv3, Annex I, EDAU1/1201/RP/008-2013, 12/08/2013

/12/ Amutio, M. A., Mañas, J. A. (2014). MAGERIT version 3.0 Methodology for Information Systems Risk Analysis and Management, Book I - The Method, Spanish Ministry of Finance and Public Administration, July 2014.

/13/ https://www.act.nato.int/activities/fmn