AFSim 仿真系统----通信入门指南

最新推荐文章于 2024-08-21 17:44:24 发布

小道士写程序

最新推荐文章于 2024-08-21 17:44:24 发布

阅读量1.3k

点赞数 13

分类专栏： HLA-仿真分布式 # AFSim仿真系统文章标签： AfSim AFSim 仿真系统

本文链接：https://blog.csdn.net/zhanglixin999/article/details/141169830

版权

AFSim仿真系统同时被 2 个专栏收录

22 篇文章 18 订阅

订阅专栏

HLA-仿真分布式

21 篇文章 1 订阅

订阅专栏

引言

本指南旨在向用户提供有关通信功能的额外信息，包括通信的一般能力，以及 AFISIM 中通信框架特征扩展的机会。它并不旨在替代现有的、与现实世界等效的通信程序、术语、模型等的知识。一般而言，当 AFISIM 中的实现与传统理解有显著差异时，将特别强调，以避免混淆。最后，本指南并不是解释 AFISIM 先前版本所做更改的说明，但某些通信能力的介绍将在解释通信行为时提及这些差异（或“无差异”）。

地址分配

AFSIM 中的所有通信对象都必须具有一个标识符或地址，以唯一标识模拟中存在的每个通信对象。最广泛认可的可用地址方法是互联网协议（IP）地址方案，该方案用于 AFISIM 中通信对象的内部地址分配。此外，AFSIM 使用 IPV4 无类别域间路由（CIDR）表示法进行通信的内部地址分配。选择这种地址方法是因为它的普遍性，以及基于此类地址提供有关“组”或“网络”成员资格的额外信息，这允许在通信系统中删除将网络明确建模为对象的需求。（详见“网络”部分）

IPV4 CIDR 作为一种互联网地址方案，显然并不适用于所有通信对象，尤其是传统无线通信基础的对象。然而，需要注意的是，尽管这些对象仍需根据 IPV4 CIDR 提供地址以确保 AFISIM 内部的一致性，但它们的行为不受限于传统 IP 基于通信设备的预期方式。大多数情况下，用户可以选择忽略地址分配。

目前，IPV6 暂不可用，但该地址方案是在考虑到未来可能实现其他源于基本地址类别的地址方案的思想下开发的。一般而言，IPV4 应提供比仿真所需的更多主机地址，只要适当地限制 CIDR 值，避免过多的“稀疏”网络分配。

IPV4 CIDR 地址表示法使用一个 32 位值，它由四个整数组成，以点（‘.’）分隔，这些字节值可以从 0 到 255。这些地址中唯一受限制的是 0.0.0.0 的地址，该地址用于标识“空”地址（在仿真中尚未分配的地址）。在 AFISIM 中未实现现实世界 IPV4 地址的复杂性，这些复杂性是基于其他主要限制在 IP 功能上的能力（例如多播、广播等）来限制的。使用 CIDR 表示法，还提供了一个额外值，表示用于寻址网络本身的地址部分，同时直接指示在任何给定时间可以属于该网络的“主机”（单个通信对象）的数量。由于 CIDR 值是可变的，网络规模也很灵活。然而，需注意的是，使用过大的网络规模而不实际利用所提供的空间，会限制仿真中可分配的总体地址数。换句话说，如果手动确定地址，限制小 CIDR 值的使用。CIDR 值的范围限制在 1 到 31 之间，其意义如下：

向通信对象分配地址的可能性

在 AFSIM 中，可以通过以下方式为通信对象提供地址：

提供通信对象所属网络的名称。
- 在这种情况下，地址会自动分配给网络中最低的可用地址。
- 此外，指定的网络必须足够大（基于 CIDR 值），以支持分配给该网络的所有通信。
提供 IPV4/CIDR 表示法中的显式地址。
- 在这种情况下，通信对象将自动加入任何已存在的网络。
- 如果没有已存在的网络，则会创建一个，并提供一个引用创建平台/通信的名称。
在 IPV4/CIDR 表示法中提供显式网络地址。
- 如果没有与已存在网络的地址冲突，网络将被创建。
- 网络名称从创建平台/通信中引用。
- 提供给通信的地址是新创建网络中第一个可用地址。
不采取任何行动。
- 通信会自动加入一个在 AFSIM 中始终可用的通用网络，命名为“默认”。它将获得网络中最低可用的地址。

注意：“默认”网络在 AFSIM 中是保留的地址 0.1.0.0/16。这为该网络提供了大约 65,000 个可分配的通信。

警告：请勿创建地址范围在 0.1.0.0 到 0.1.255.255 的网络，因为这些地址属于默认网络，并将在尝试时导致仿真初始化错误。

警告：请勿创建与多播相关的网络，范围是 224.0.0.0 到 239.255.255.255。

网络

AFSIM 中的网络是通过其 IPV4 CIDR 地址的相似网络地址前缀，将通信对象集合在一起的组成部分。在之前的 AFSIM 版本中，通信仅限于同一网络中的对象，除非使用其他对象和设置（例如现在已弃用的 AFSIM_COMM_ROUTER）。这一概念严重限制了通信对象的灵活性和建模能力，因此进行了移除，转而将每个通信设备建模为潜在可以与任何其他通信设备进行通信，具体限制由通信链路的存在和通信实现本身提供。为了在任意两个通信对象之间启用通信，只需要在它们之间存在一个链路。

AFSIM 中的网络对象是用户可定义的对象，可以通过场景输入或脚本语言进行定义。这些对象强制实施有关与网络相关的通信对象的成员资格、连接性和行为的特定规则。此外，还提供了几种预定义的网络类型。未来可能会提供更多类型，用户也可以扩展可用的框架，并添加自己的网络定义。在 AFSIM 中可用的网络对象通常强制实施特定的网络拓扑（如环形、网状、星形等），但在网络定义中，可以对添加/移除成员或添加/移除网络中的连接链接的行为施加任何规则。

未来计划提供一种方法，以便根据时间或事件驱动网络对象的更新，实现网络规则的执法。这将提供一种基于协议使用、仿真环境或用户所决定的推动事件的其他一般事件来更新网络状态的方法。尽管当前不可用，但预计该机制将提供基于通信发现（及丢失）事件的临时网络能力。

网络管理器

网络管理器是 AFSIM 中与通信相关数据的主要收集点。每个仿真中的通信对象都需要向网络管理器注册自己，以获得一个地址（无论是用户指定的还是动态分配的）。每个通信对象都作为节点添加到图对象中，通信对象之间的通信能力则表示为图中对象之间的边。网络管理器中维护的数据被视为“真实”数据，即在特定时间内 AFSIM 中通信的实际状态。它还提供一个对象，用户可以通过 AFSIM 仿真对象获取任何通信对象的地址、所属网络以及同一网络的其他成员列表。从本质上讲，网络管理器充当了一个 DNS 服务器。

路由与协议

AFSIM v2.5.0 更新信息

在 AFSIM 中，路由是指确定从发送通信设备到预期接收者的通信路径的能力。这也意味着能够根据是否找到路径来判断消息是否可以发送到目的地。

路由通过 AFSIM 中的路由器对象表示。需要注意的是，这与路由器作为网络硬件的通俗概念并不相同，而是路由和路径寻找能力的表示。它当然可以表示作为网络硬件的路由器，但这并不是它的主要目的。用户也不需要担心在基于无线电的通信系统中使用路由器的概念，因为关键的无线电功能（如中继）就是路由器对象在 AFSIM 中所表示的一种路径寻找方式，尽管这种形式非常简单。

路由器对象是平台组件，一个平台可以与任意数量的路由器关联。为了保持向后兼容性，AFSIM 提供了一个默认的路由器，用于以前版本中提供的默认功能。每个通信被称为路由器的接口，都是与路由器关联的，并且在任何给定时间只能与一个路由器关联。用户在简化的通信用例中通常不必了解这些概念，因为默认路由器在平台上存在，无需用户输入，且在平台上声明的所有通信都是默认路由器的接口。

路由器还具备能够模拟路由器作为硬件功能的能力，例如通过在所有连接的成员之间创建通信链接（默认行为）来作为切换器，如果需要，该功能可以被禁用。

路由器寻找消息路径的方式并不是由路由器本身直接决定的，而是由它使用的路由器协议（或多个协议）来决定的。路由器支持任意数量的唯一协议，并在典型操作中按优先顺序查询每个协议，直到其中一个协议确定到目的地的路径。如果找到这样的路径，则会指示通信对象将消息传输到路径中的下一个跳点，并非所有路由器协议都要求为消息提供路径寻找能力，有些则启用不同的寻址方案、路由知识更新，或以其他方式增强（或限制）路由器的能力。

每个路由器对象默认提供两种路由协议，尽管如果需要，可以将其移除——WSF_COMM_ROUTER_PROTOCOL_LEGACY 和 WSF_COMM_ROUTER_PROTOCOL_MULTICAST。这些是通用协议实现，旨在提供一些 AFSIM 之前版本中的遗留功能，以便场景输入文件在当前和未来版本中无需任何（或最少的）更新即可保持功能，特别是在将消息从通信 A 传送到通信 B 时。

最后，在增强通信框架的早期修订中，路由器提供了感知与真实网络状态使用的概念和用户切换选项。这一功能已被移除，因为路由器协议现在根据具体情况决定是否在路径寻找中使用仿真的真实网络状态，或者在本地维护感知网络状态，或两者的某种混合。由于路由器对象可以使用多个协议，这允许根据用户可配置的真实或感知路由选择条件性路径寻找。

通信层实现与通信协议

AFSIM中的通信对象是基于7层OSI模型来组织的，以实现各种通信类型。每个通信对象包含一个称为协议栈的对象，该对象由多个“层”对象组成，这些层处理从通信对象发送和接收的消息。当指示通信对象发送消息时，该消息会通过协议栈中的每一层，每一层都有选择将消息传递下去或中止处理的选项。接收消息的过程类似，只不过消息是在协议栈中以相反的方向（从底层到顶层）传递，同样可选择将消息传递给更高一层或中止接收。

需要注意的是，虽然该模型用于AFSIM的通信对象，但并不能推断通信模型仅基于IP。这是一种逻辑、灵活且可扩展的建模方式，支持通信对象的建模，无论其功能或预期用途如何，甚至即使基于电磁（EM）模型也一样。最终用户仍然可以定义自己的通信对象，使用单层或省略层结构。此种设计旨在降低创建新模型、维护现有模型和支持尚未创建模型所带来的成本。

层结构的含义是，每一层可以执行与通信和/或消息相关的内部操作，并以适合特定通信实现的方式处理消息。许多通信对象可能选择重用相同的层实现，或创建自己的层，因为这些层通过AFSIM框架实现了完全的可扩展性。

当前，AFSIM提供以下基本功能层：

应用层：在发送时，确定目标平台上可能的接收者。
传输层：在发送时，为消息附加适当的传输协议，以便其他通信知道如何处理该消息。
网络层：
- 在发送时，使用路由器确定到目标接收者的路径，并选择“最佳”路径（由路由器的可用协议决定）。
- 在接收时，确定消息是否是针对本平台的，或者只是一个中转。如果只是中转，则找到目标的最佳路径，并转发该消息。
数据链路层：在发送时，将消息放入队列，直到通信能够物理传输。
物理层：在发送时，确定消息传输所需的时序，并发出电磁信号（如适用）。在有空余时间时通知数据链路层（如适用），可以发送更多排队的消息。如果使用可靠通信作为传输协议且发送失败，则通知网络层发送失败（以便更新路由）。

代码库中还提供了其他层，但目前未以有意义的方式使用。

可以向通信实现中添加任何数量或类型的层，并根据需要进行修改。这允许创建更详细的实现，甚至在必要时创建分组级别的实现。

通信还具有一个独特的组件——通信协议。可以将任意数量的唯一通信协议与AFSIM中的任何特定通信实例关联。通信协议修改通信模型层处理的默认行为，因为AFSIM提供的通信模型中的默认层实现将在消息发送/接收操作中查询每一层的通信协议。因此，通信协议允许在不需要创建全新模型的情况下修改现有通信模型的行为。这减少了创建新通信功能所需的开发量，使其能够在现有模型上使用，并大大减少了代码重复。目前，只预定义了一个用于AFSIM的通信协议，WSF_COMM_PROTOCOL_IGMP，它通过通信接口启用多播组成员资格，并允许通信对象接收多播消息。

关于命令链、平台指定消息目标和通信的说明

AFSIM的早期版本使用命令链来构建通信布局/网络状态表示。随着AFSIM中通信的更新，这一功能正在逐步移除。这样做的原因如下：

假设通信布局反映命令链并不现实，即使其方便。
假设命令链代表通信结构会强迫在行为上做出假设，限制了高保真建模，并因此限制了将AFSIM作为通信是重要变量的工具进行实验的能力。
这是一种被某些旧模拟框架使用的模型，最初在AFSIM中复制以帮助进行一致性行为的验证和验证。现在，在有效通信建模日益重要的情况下，它限制了AFSIM的能力。

命令链指定接收的目标平台，而不是目标通信（见下文，解释为何这有害）。

此外，在AFSIM中，尽可能地移除仅指定目标平台的通信消息，原因如下：

平台可以维护多个通信。仅指定一个平台为消息接收者并不表示该消息将由哪个通信接收。
由于上述原因，选择将接收消息的通信是在假设行为的基础上，或者更糟，随机排序。这是不可接受的，因为模拟需要是确定性和可重复的。
不知道具体的通信接口可能会导致在场景建模中的调试困难，例如平台上的链接可能不会将传入消息路由到正确的目标部分，或者：
用户必须在所有通信接口上始终如一地复制内部链接，以确保消息的正确内部平台路由，从而迫使使用唯一消息类型进行过滤，这增加了布局的复杂性。

分布式模拟与通信

在分布式环境中使用通信时，用户需要注意某些细节以确保正常功能。

默认情况下，通信设备可以在本地模拟上下文中动态寻址。虽然具体是如何发生的超出了本文件的范围，但需要注意，当用户让模拟为通信设备分配地址而未明确定义时，生成的地址是基于该通信设备属于的网络中后续寻址的可用性，采用先到先得的方式，从最低可用地址开始并递增到最高地址。

这是在分布式模拟用例中存在问题，因为通信设备的顺序可能在不同的模拟实例之间不一致。这可能导致冲突的地址分配，并且由于消息到达其他模拟实例时地址在发送模拟实例中是正确的，但在接收实例中是错误的，因此会造成明显的错误交付和/或消息丢失。

目前，在使用动态寻址的情况下，没有确保在分布式模拟实例之间进行正确和唯一地址分配的机制。

强烈建议在分布式用例中使用通信的用户使用静态寻址。静态寻址可以规避上述问题。此外，只要确保使用动态寻址的通信设备属于同一模拟上下文中仅包含定义和使用过的成员的网络，动态寻址在分布式用例中仍然可行。因此，用户可以配置他们的场景，以便仍然利用动态寻址，只要他们修改网络布局，使其仅包含在本地定义和管理的通信设备。

其他说明

在AFSIM中，关于通信还有几个额外的重要点需要注意。

通信框架并不支持端到端消息传递（之前的AFSIM版本在某些情况下是这样做的）。发送消息可能会生成多个跳点的路径。AFSIM中的每个通信对象都接收、处理并重新发送这些消息，直到到达目的地。

默认情况下，AFSIM会将对象分配到名为“default”的网状网络中，并提供初始链接。

基于平台的消息发送在所有情况下被移除，包括任何基于命令链的操作。新的框架的保真度已大幅提高，以至于将消息泛化为发送到平台引用假定接收方上只有一个通信，这可能并非如此。所有通信发送调用都需要一个发送通信和一个接收通信，以多种格式之一进行。目前，在这些之前发送到平台的方法中，发送方上可用的所有通信都会发送消息，以提供过渡输入文件的临时方法。然而，这将为未送达的消息创建相当多的额外事件。建议确保通信定义的正确性。

网关仍然可用，任何失败的消息路由将自动将消息传递给定义的网关（假设用户选择的协议支持此功能）。网关是根据每个通信对象定义的，因此任何通信都可以定义自己的网关。旧的“default_gateway”命令不再支持。

AFSIM 2.3 通信更新

AFSIM中内置的通信对象路由器在消息传输时间上与之前的AFSIM_COMM_ROUTER有所不同。AFSIM_COMM_ROUTER没有考虑来自平台的消息及随后从不同通信对象重新传输的时间延迟。目前的路由能力考虑了这一延迟，基于发送消息的通信对象的传输规格。如果在此类操作中使用两个通信，则可以通过在平台上使用单个通信设备进行接收/传输，或者通过使用具有瞬时传输/传播属性的接收通信的本地桥接连接来避免这种延迟。在未来的版本中，AFSIM可能支持具有多个通信对象作为多个定义接口的路由器，以避免这种情况。

retransmit_link功能不再存在，因为它是避免之前架构限制的方法，而这些限制现在已不存在。

relay命令不再存在，因为AFSIM中所有通信对象现在都有隐式的中继能力。

link_protocol命令目前已被移除。它们在大多数应用中没有功能，可能在AFSIM未来版本中重新引入。

number_of_channels命令也被移除，因为它是上述link_protocol命令的一个功能。

AFSIM 2.4 通信更新

随着AFSIM 2.4的发布，进行了一些通信更改，以允许附加的分析能力。有关场景转换和AFSIM 2.4中通信使用的示例指南可在此处获取：AFSIM Comms 2.4 Conversion Guide。

基于平台的通信被移除，消息的发送仅限于通信之间。这也包括所有基于命令链的操作。新的框架的保真度已大幅提高，以至于将消息泛化为发送到平台引用假定接收方上只有一个通信，这可能并非如此。所有通信链接都需要一个发送通信和一个接收通信，以多种格式之一进行。目前，在这些之前发送到平台的方法中，发送方上可用的所有通信都会发送消息，以提供过渡输入文件的临时方法。然而，这将会为未送达的消息创建额外事件。建议确保通信定义的正确性。

AFSIM 2.5 通信更新

AFSIM 2.5中的通信的主要变化，如提供将路由器作为平台部件/组件和router_protocol的使用，已在上述路由部分的更新中体现。

此外，需要注意的是，最近提供的“bridge”输入已被移除，因为路由器现在固有地提供这一能力。

任何其他更改均在AFSIM v2.5的更改日志中注明。

AFSIM 2.6 通信更新

AFSIM 2.6引入中介对象。中介的使用提供了一种方法，能够变化消息的传输和传播特性，不再仅仅基于发送对象，并消除了通信框架建模能力中长期存在的不足。此外，此更新为未来在各种中介上提供更高保真度的物理建模打下了基础。最后，此更新包括现在所有通信模型中固有的简单复用能力，同时使得将来能够建模更复杂的复用协议。

任何其他更改均在AFSIM v2.6的更改日志中注明。

此更新支持所有旧版输入。

AFSIM 2.8 通信更新

以前，由于AFSIM模拟初始化平台的方法存在限制，通信初始化必须推迟到典型初始化过程之后，因此许多通信的脚本接口功能在on_initialize和on_initialize2脚本块中无效或不可用。自AFSIM 2.8及模拟初始化程序的修改以来，通信的脚本功能可在on_initialize2脚本块中使用。大多数与通信相关的脚本功能仍不可在on_initialize的上下文中使用。