华为超节点系统对军事体系仿真分布式计算的需求影响与技术路线变革研究

摘要：本文以 AFSIM 2.9.0 公开源码与华为超节点公开技术资料为依据，考察三个问题：军事体系仿真中分布式计算的需求究竟是什么，其技术难点分布于哪些层面，超节点架构对需求结构与技术路线的影响边界何在。基本判断是：AFSIM 的"分布式"并非 MPI 式并行计算，而是多进程 XIO 联邦；其深层问题不在带宽与时延，而在语义保真；超节点能够系统性化解域内资源类问题，同时使域间语义类问题更加突出------分布式计算不仅未被替代，其研究重心反而由底层通信工程上移至体系协同层面。

一、问题的提出

军事体系仿真对计算规模的需求持续增长：联合作战体系对抗推演要求对多域实体进行高保真建模，装备级仿真的多物理场耦合模型状态数据量显著上升，智能博弈与数字孪生进一步引入高频交互负载。当规模需求超出单进程的内存与调度能力时，通常的应对是将仿真分布到多个进程或多台计算节点，由各进程承载一个想定分域。这一转换使技术难点分布在两个层面：域内资源层面，包括单计算域的内存容量、访存时延与异构算力利用；域间语义层面，包括跨进程的状态一致性、时间同步与想定保真。

工程实践中的常见情形是：后一类问题在前一类问题得到缓解之后才充分暴露。以 AFSIM 为代表的军事仿真平台采用多应用联邦形态，跨进程交换粗粒度报文，报文内容与协议语义直接决定协同仿真的保真度；而在单域内部，平台状态驻留本进程内存，规模上限受制于单机资源。与此同时，以华为 CloudMatrix384 为代表的超节点架构将单计算域的算力与内存上限提升了一个量级------数百颗处理器全对等互联、百 TB 级统一内存、单跳时延进入两百纳秒量级。

由此产生两个值得考察的问题：其一，军事分布式仿真的技术难点分布于哪些层面，其需求结构是什么；其二，超节点架构能够解决什么、不能解决什么，技术路线将如何随之调整。本文以 AFSIM 2.9.0 源码为主要证据，结合超节点公开技术资料对上述问题进行分析。为使结论可复核，文中涉及机制的表述均给出源码文件与行号。

二、机制界定：AFSIM 的分布式形态

讨论任何问题之前，须先界定机制------机制界定有误，后续分析将全部失效。

2.1 概念澄清：并非 MPI 并行

谈"分布式仿真"时，常见的理解是 MPI 式并行计算：将一个大计算任务拆分为多份，分发到多台机器上执行，彼此频繁交换中间结果。若以此框架理解 AFSIM，源码核查的结论是否定的。在 AFSIM 2.9.0 源码树中检索 mpi.h、MPI_Init、MPI_Comm，src/core 全树无命中；dependencies/3rd_party 依赖目录中亦不存在 MPI 库。AFSIM 的"分布式"与高性能计算领域"任务拆分到多节点"的并行模式是两回事，这一区分是后文全部分析的前提。

2.2 实际机制：多进程 XIO 联邦

AFSIM 的实际分布式形态是多进程联邦：

每个 ‎mission.exe 进程承载本域平台的完整推演------机动、传感器探测、武器、通信、行为树，全部在本进程内完成；
进程之间通过 XIO 机制交换粗粒度报文：航迹、任务指派、遥控指令、部件状态等；
当需要与遵循 IEEE 1278（DIS）标准的外部系统交互时，可以可选启用 DIS 接口，交换位置与姿态等协议数据单元。

就其分工而言，XIO 承载消息类数据（航迹、任务指派、遥控指令、部件状态等），DIS 承载位置与姿态等协议数据单元；探测计算则不发生跨进程迁移，始终在本进程内完成。这一分工是后文全部分析的基础。

2.3 官方演示的配置实录

AFSIM 源码自带一个双应用演示（src/core/wsf_mil/test_mission/xio/），启动脚本只有几行：

复制代码

rem run-both.bat（节选）
start run.bat xio-app1.txt realtime.txt
start run.bat xio-app2.txt realtime.txt

两个进程各加载一份场景配置。app1 的配置里，萨姆指挥官与目标两类平台的可获得率为 0------它们只存在于 app2 中：

复制代码

rem xio-app1.txt（节选）
include scenario.txt
include xio-common.txt

platform_availability
   type SAM_COMMANDER   availability 0.0
   type TARGET          availability 0.0
   default              availability 1.0
end_platform_availability

dis_interface
   broadcast 127.255.255.255 port 3226
   site 1
   application 1
   autostart
end_dis_interface

xio_interface
   application app1
end_xio_interface

两个进程的公共 XIO 配置：

复制代码

rem xio-common.txt（节选）
xio_interface
   broadcast 127.255.255.255 port 3225
   connect_to_simulations
   auto_dis_mapping yes
end_xio_interface

再加上实时节拍配置：

复制代码

rem realtime.txt
clock_rate 2.0
realtime

该演示完整展示了联邦形态：想定被划分为两份，由两个进程分别推演；app2 中的指挥官经 XIO 向 app1 中的萨姆阵地指派任务；DIS 接口默认启用，将本域平台位置广播给遵循 IEEE 1278 标准的外部系统。可见 AFSIM 的分布式不是"把一个计算拆成多份"，而是"把想定切成多份、各自推演、按需交换"。

2.4 六条源码事实

以下六条事实均可在 AFSIM 2.9.0 源码中逐条复核，它们决定了后文缺陷分析的性质：

#	事实	源码位置
1	探测计算只枚举本机平台表，跨进程不发生探测计算	‎`WsfDefaultSensorScheduler.cpp`
2	远端平台以"影子"形式存在，且传感器按设计忽略影子实体	‎`WsfPlatform.hpp`
3	XIO 跨应用报文不经物理层，直接投递对端通信组件	‎`WsfXIO_CommComponent.cpp`、‎`WsfXIO_AutoDisMapping.cpp`
4	航迹按整对象序列化，且携带真值目标索引与目标标识	‎`WsfXIO_SerializeTypes.cpp`
5	任务状态只在指派方写入，只有状态上报、没有查询协议	‎`WsfTaskManager.cpp`
6	默认通信介质为 GUIDED，只查连通图；换 radio 类介质才禁用 GUIDED	‎`WsfComm.cpp`、‎`WsfRadioXmtrRcvr.cpp`

第 1、2 条共同意味着：跨应用协同中，A 进程所获得的 B 进程目标信息并非本进程探测结果，而是 B 进程上报的航迹；第 3 条意味着该上报通道绕过物理层；第 4、5、6 条分别对应语义保真、状态可观测性与想定有效性三个层面的问题。联邦整体形态如图 A 所示。

三、源码层面的四类问题

3.1 内存墙：单域规模缺乏架构级扩展

从源码结构看，AFSIM 的平台状态、传感器队列、航迹历史全部驻留本进程内存，多应用之间不共享内存（2.2 节机制使然）。这意味着单任务规模的上限由单进程的可用内存与墙钟时间决定，框架未提供架构级的跨节点内存扩展。突破单域限制的路径有两条：更换容量更大的机器，或将模型手动分区、部署到多个进程，再通过边界数据交换维持全局一致。

手动分区是典型的"被迫分布式"：开发者为每个大规模场景设计域划分与边界交换，数据拷贝带来精度损失与性能开销，且每增加一类场景即需重做一遍。在万级实体量级，单节点尚可承受；但战场环境精度、航迹历史长度、并行想定数量每一项上量，挤占的都是同一块内存，而框架未给出架构级的答案。

3.2 语义保真缺口：粗粒度联邦下的状态分叉风险

以下三方面问题在"升级硬件即可缓解"的叙述中容易被掩盖，是本节考察的重点。

问题一：真值信息随航迹外泄。 航迹序列化字段里带着真值目标索引、目标名与目标类型：

复制代码

// WsfXIO_SerializeTypes.cpp:279-281（WsfTrack 序列化字段节选）
aBuff&                 mFalseTargetId& mTargetIndex;
aBuff& mTargetName&    mTargetType;
aBuff&                 mLastSourceName;

mTargetIndex 是航迹对应的真值平台索引。它随报文跨应用边界外传，意味着接收方可以绕过"感知"直接获得真值指向；更为关键的隐患在于一致性：两个进程对同一实体的感知状态可能长期分叉，而框架未提供强制一致机制。对"按传感器探测结果决策"的仿真逻辑，这是结构性缺陷。

问题二：任务协同"只推不拉"。 任务状态只在指派方写入------WsfTaskManager.cpp:2326 是整个文件中唯一的 SetStatus 调用点：

复制代码

// WsfTaskManager.cpp:2322-2327（节选）
if (messageProcessed)
{
   WsfTask& task = *xtli;
   task.SetUpdateTime(aSimTime);
   task.SetStatus(statusId);
   task.SetSubStatus(aMessage.GetSubStatus());

执行方的实时状态只能通过状态上报"推"给指派方，没有查询协议可以"拉"。跨应用任务协同因此依赖上报的完整性------报文丢失即失察，指派方不知道任务是已被接受、正在执行还是已经失败。

问题三："通信受限"想定在跨应用条件下失真。 XIO 跨应用报文在接收侧被直接转发给下一跳通信组件，不经物理层：

复制代码

// WsfXIO_CommComponent.cpp:94-103（节选）
bool CommComponent::Receive(double aSimTime, wsf::comm::Comm* aXmtrPtr, wsf::comm::Message& aMessage)
{
   if (mDisMappingPtr->CanTranslateMessage(aMessage.SourceMessage()->GetType()))
   {
      WsfXIO_DisMessagePkt pkt;
      pkt.mSimTime       = aSimTime;
      pkt.mMessagePtr    = aMessage.SourceMessage().get();
      pkt.mPlatformIndex = static_cast<int32_t>(GetComm()->GetPlatform()->GetIndex());
      pkt.mCommName      = GetComm()->GetNameId();
      mConnectionPtr->Send(pkt);
   }

// WsfXIO_AutoDisMapping.cpp:380-384（节选）
if (nextHopCommPtr && originatorCommPtr)
{
   wsf::comm::Message commMessage(ut::clone(aMessage));
   messageForwarded = nextHopCommPtr->Receive(mSimulation.GetSimTime(), originatorCommPtr, commMessage);
}

同时，默认通信介质是 GUIDED，只查连通图，不查任何链路条件：

复制代码

// WsfComm.cpp:77-78
containerPtr->AddValidMedium(medium::cGUIDED);
containerPtr->SetDefaultMedium(medium::cGUIDED);

只有显式换用 radio 类介质，GUIDED 才被禁用：

复制代码

// WsfRadioXmtrRcvr.cpp:57-59
containerPtr->AddForbiddenMedium(medium::cGUIDED);
containerPtr->AddValidMedium(medium::cUNGUIDED);
containerPtr->SetDefaultMedium(medium::cUNGUIDED);

由此可得一条操作性结论：欲仿真"链路受损条件下的指挥控制"，必须显式配置 radio 类介质；以默认配置运行跨应用想定，"通信受限"这一条件并不成立。相关想定的有效性因此需要在设计阶段予以确认。

这三类问题具有共同性质：均不属于带宽或时延问题，而属于语义与协议问题------互联硬件性能成倍提升，其中任何一类都不会随之自动修复。

3.3 异构协同：语言边界摩擦与负载侧割裂

本节首先澄清一处被广泛误引的结论。兰德公司报告 RRA1722-6《Harnessing Constructive Simulations for Reinforcement Learning》常被转述为"AFSIM 与 AI 框架兼容性不足"。报告的实际结论相反：通过专门的软件支撑层，强化学习框架可以很低的开销嵌入 AFSIM 运行------原文评价该支撑层 "runs with very little cost to performance"，训练后的智能体可直接部署回 AFSIM 而无需 Python 参与。兰德识别出的摩擦在语言边界（Python 生态与 C++ 仿真引擎）与工具链支持，而非兼容性或效率缺陷。

真正的异构问题在负载侧：传统架构里 CPU 通用算力与 GPU/NPU 加速算力物理隔离，仿真逻辑（标量计算为主）跑在 CPU 上，AI 训练（矩阵计算为主）跑在加速卡上，两类数据要经主机内存中转。在多智能体强化学习这种"仿真环境与 AI 训练"高频交互的场景里，数据迁移开销直接制约训练效率------强化学习通常需要百万步以上的环境交互，每一步都跨一次总线的话，迁移开销会被交互次数持续放大。

3.4 研发负担：分布式适配的投入

基于消息联邦的开发模式要求使用者自行设计域划分、通信拓扑、同步策略与异常处理机制。每新增一类大规模跨应用场景，均需投入相应的适配与调优工作；分布式程序的调试难度高于单机程序，问题定位周期更长。本文不对此项投入作定量结论：分布式工程在研发工作量中的占比高度依赖团队基础与场景特征，公开文献中不存在一致口径。

四、两堵墙：问题的分类框架

将上述四类问题置于同一框架下考察，可以发现它们分属两个性质不同的范畴。本文将其概括为"两堵墙"（图B）：域内的资源墙与域间的语义墙。

域内的资源墙包括内存容量限制、访存时延、异构算力割裂与被迫分区，其共性是单计算域内部的工程问题，可通过底层计算架构的系统性改进获得整体性化解。

域间的语义墙包括真值边界、状态分叉、时间同步、安全隔离与故障容错，其共性是跨域协同中的语义与协议问题，只能依靠协议、算法与标准的演进化解，不随硬件升级自动消除。

这一区分的意义在于为后续分析提供判据：哪些问题可以通过计算架构的升级获得显著改善，哪些问题必须依靠分布式技术自身的研究。后文将表明，超节点对前者作用显著；而对后者，硬件性能的提升反而使问题更加尖锐------这正是超节点时代分布式研究必要性不减反增的依据。

五、超节点架构的影响边界

5.1 公开参数与限定条件

以已商用的华为 CloudMatrix384（Atlas 900 A3 SuperPoD）为参照，公开规格如下（时延与容量以官方公开口径为准，随产品代际变化）：

指标	公开口径
算力构成	384 颗昇腾 910C NPU + 192 颗鲲鹏 920 CPU
互联	灵衢 UnifiedBus，全对等互联，全光方案
内存	128TB 全局内存统一编址
单跳时延	200 纳秒以内（官方对比基线约 2 微秒，约一个数量级）

两点必要的限定：其一，跨柜远程访存为亚微秒至微秒量级，"域内任意访存都是 200ns"是不准确的；其二，UB 编程仍需显式的内存注册与分布式共享内存软件栈支撑，"像单机一样透明"是演进方向而非当前现状。这两点决定了后文所有收益判断都是方向性的。

5.2 可化解的问题：域内四类工程问题

对应第三节的四类问题与两堵墙的左半：

‎内存墙：百 TB 级统一内存池让大规模模型可全量常驻，消解"被迫分布式"；开发者不必再为内存容量做分区设计，也避免分区带来的精度损失。
‎访存时延：跨节点单跳从约 2 微秒量级压到 200 纳秒以内，且数据交互以内存语义完成，不经过传统协议栈；域内细粒度实体交互的同步开销有望显著下降。
‎异构割裂：鲲鹏通用算力与昇腾 AI 算力可接入同一内存池，机理仿真与 AI 模型共享全局内存，数据无需经主机内存中转------3.3 节的训练迁移开销具备被大幅消除的条件。
‎开发门槛：域内可采用共享内存编程范式，减少消息传递与手动分区相关的适配代码，调试难度显著下降。

同时需要限定收益的判断边界：实际增益取决于负载的访存与计算比、UB 软件栈的成熟度以及域划分方式，本文不作定量承诺。可以确认的是方向性变化------原本因单域资源受限而难以落地的推演，在超节点域内获得了更大的可行空间。

5.3 难以化解的问题：域间四类体系需求

对应两堵墙的右半，这四类需求不仅不会减弱，反而随超节点普及而增强：

‎广域跨地域协同。超节点的统一内存具有明确的物理边界（机柜级、机群级），无法覆盖跨机房、跨基地、跨战场的场景。LVC 混合仿真要接入分布在不同地域的实装与训练设施，只能依托标准分布式协议；且每个节点算力提升后，广域联合推演的规模与复杂度只会更高。
‎松耦合的体系解耦与故障隔离。军事仿真包含多分系统、多类模型、多个安全域，需要解耦设计与故障隔离。把所有系统耦合进单一超节点域，一个分系统的故障可能影响全局，不同密级的系统也难以安全隔离。此外，紧耦合长时推演的检查点、任务热迁移等容错机制，本身就要求分布式层保留独立的协同与容错协议。
‎跨架构、跨生态的异构互联。存量仿真平台、不同年代的系统、实装接入设备，架构差异大、技术栈不统一，互联只能靠 HLA/DIS 这类标准协议。超节点无法强制存量系统全部迁移重构。
‎更大规模的跨域推演。单域上限被抬高后，用户自然会追求更大规模的全域推演------这需要多套超节点之间的分布式协同。此时"分布式"的内涵已经升级：不再是服务器之间的细粒度消息传递，而是超节点与超节点之间的粗粒度域间协同，研究重心转向域划分策略、域间同步、全局状态一致性。

综合 5.2 与 5.3，可以得出一个总体判断：域间语义问题不是带宽或时延问题。互联性能提升一个数量级，并不会自动产生真值边界协议；相反，硬件透明化程度越高，语义一致性、时间同步与安全隔离等方面的问题会越突出。

六、需求重构：什么需求、多大规模

缺陷与能力都清楚之后，看需求侧：超节点时代，分布式仿真的需求不是消失，而是结构性迁移------底层的工程型需求下沉收敛，业务级的体系型需求上移深化，智能融合类需求新增爆发（见图1）。

6.1 四类典型场景

‎大规模实体类（联合作战体系对抗推演）：单域目标是万级实体全状态常驻，跨域联邦追求更大规模。可行性的关键不在内存，而在交互拓扑（见 6.3）。
‎紧耦合数值类（装备多物理场耦合仿真）：整机级多物理场模型的状态数据在 TB 级以上（随离散精度而变），传统单节点必须分区切割并引入边界交换；域内全模型常驻消解分区后，需求转向耦合接口的一致性与时间步协同设计。
‎广域集成类（多级联合训练与 LVC 协同）：多基地、多联邦成员跨域互联，链路带宽与时延随网络条件而变。此类需求的核心不是算力而是协同：低带宽下的按需分发、松耦合时间管理、多密级安全隔离，均属协议层问题。
‎混合负载类（智能博弈与数字孪生）：多智能体强化学习通常需要百万步以上的环境交互，训练墙钟时间由仿真环境吞吐直接决定；实时数字孪生要求毫秒级的"感知---仿真---决策"闭环。"机理+AI"同池提供了硬件条件，混合调度策略成为新的架构级需求。

6.2 六类需求 × 三个层级

综合四类场景，需求可归纳为六种类型：承载规模、访存与通信、一致性与语义、时间同步、安全与隔离、智能融合。它们在三个规模层级上的量级与核心挑战见图2。

三个层级的界定：L1 单超节点域 ，以统一内存池承载万级实体或单装备全尺度模型，矛盾集中在调度与交互拓扑；L2 跨超节点域 ，多域联邦支撑更大规模推演，矛盾集中在域间协议与全局一致性；L3 广域 LVC，多级联邦成员跨战区互联，矛盾集中在低带宽协同与安全隔离。需要强调：图中规模量为论证性目标量级（基于公开架构参数与交互假设的推算），用于界定需求结构，不构成性能承诺；层级跃迁不靠单一硬件指标，而靠协议、算法与标准的协同演进。

6.3 规模可行性的量级测算：交互拓扑约束

"可行性的关键不在内存"这一判断可以通过量级测算予以说明。以万级实体为例：若实体间为全对等交互，实体对数约为 N(N−1)/2 ≈ 5×10⁷；即便按超节点单跳 200 纳秒的公开口径计，一轮全对等扫描也需 10 秒量级，超出合理的推演步长预算。内存容量的增加并不能改变这一量级关系。

实际系统通过传感器作用距离将交互限制在局部范围内。若平均邻居数为数十，交互量降至 10⁶ 量级，在同样时延口径下约为 0.2 秒，进入可用范围。该测算的含义在于：规模化的约束条件主要不是内存容量或互联速度，而是交互拓扑。因此，交互拓扑感知的调度与剪枝算法是从万级实体迈向更大规模的核心需求------它属于算法与软件范畴，而非单纯的硬件扩容问题。

七、技术路线：紧耦合域 + 松耦合网

综合以上，技术路线的演进方向是"紧耦合超节点域 + 松耦合广域网"的两级架构（见图3）。

‎下层：紧耦合超节点计算域。单域内经统一内存与高速互联实现紧耦合高性能计算，承载核心仿真逻辑：全局统一内存（128TB 级）、内存语义访存、"机理+AI"同池、细粒度强同步负载在域内闭环。
‎上层：松耦合广域协同网络。多个超节点域之间、超节点与边缘/实装节点之间，通过标准化分布式协议松耦合协同，承载跨域、跨级、跨地域的体系级交互：HLA/DIS/XIO 联邦、时间管理、安全隔离。域边界同时是协议边界、速率边界与故障域边界。

由此带来五个范式的系统性重构：并行范式从纯消息传递转向"域内共享内存 + 域间消息传递"；架构范式从多级松耦合转向"紧耦合域 + 广域网"；求解范式从纯机理转向"机理+AI"混合；开发范式从底层通信开发转向体系架构设计；自主范式从跟随国外标准转向全栈自主闭环。

结合军事指挥体系的层级特征，两级架构可形成"战略/战役级中心 + 战术级边缘"的分层适配：中心部署大型超节点集群，承载全域体系对抗推演等重负载；战术级部署轻量化超节点或边缘仿真节点，承载本地实时推演；两级之间经军用网络按需同步，形成"中心强算力 + 边缘低时延"的分层体系。

一个容易被忽视的衍生问题是时间管理：域内可依托超节点总线的确定性获得高精度同步条件，域间则必须依赖标准时间管理服务；两级之间的时间基准一致性，是两级架构特有的新研究问题。对应到 AFSIM 类平台的升级路线：单域内的仿真引擎向超节点原生架构重构，充分释放紧耦合算力；域间协同保留并升级分布式交互协议，同步补齐语义一致与时间管理机制。

八、对仿真研发活动的影响

上述变化对仿真平台的研发活动提出三方面要求。

研发重心的迁移。 核心工作由通信代码编写与并行性能调试，转向分布式体系架构设计、域划分策略、业务协同逻辑与标准接口定义。相应地，需要补齐的能力包括：统一内存与共享内存编程（UB 内存语义、显式内存注册与分布式共享内存软件栈）；交互拓扑分析与域划分方法（6.3 节的量级测算可作为基础工具）；时间管理与一致性协议（域内确定性同步与域间时间管理的叠加）；协议与标准的理解与运用（HLA/DIS/XIO 各自的能力边界及自主协议的空间）。

研发路径的分阶段推进。 第一阶段为兼容迁移：在保留既有联邦逻辑的前提下将现有框架迁移至超节点平台，通过系统层优化先行化解内存与访存压力；第二阶段为架构重构：核心并行模块按共享内存范式重构，升级域间协议，构建两级架构，补齐语义一致与时间管理机制；第三阶段为体系创新：形成原生支持两级分布式、原生融合 AI 算力的新一代仿真框架。

能力结构的调整。 硬件性能带来的改善具有明确的窗口期，而协议与语义能力的积累不存在捷径。超节点主要回应的是系统能否承载运行的问题；而"运行是否正确"------跨域态势一致、时间基准统一、任务状态可观测、想定保真------仍取决于协议设计与工程实现的细致程度。对研发主体而言，后者是更持久的竞争力来源。

九、结语

综合以上分析，可以得出三点结论。

其一，就机制而言，AFSIM 的"分布式"是多进程 XIO 联邦，而非 MPI 紧耦合并行；其技术问题分属单域资源约束与域间语义约束两类，相关源码证据均可在 AFSIM 2.9.0 中复核。

其二，就能力边界而言，域内资源约束可望通过超节点一类计算架构创新获得系统性改善；域间语义约束则只能依靠协议、算法与标准的演进化解，且硬件性能越高，语义问题越突出。这是"超节点时代分布式研究重要性不减"的基本依据。

其三，就技术路线而言，演进方向是"紧耦合超节点域 + 松耦合广域网"的两级架构，并行、架构、求解、开发四个层面随之调整，研究重心由底层通信工程上移至体系协同设计。分布式计算未被超节点替代，而是在新的架构条件下承担更高层级的职能。

参考资料

$1$ AFSIM Version 2.9.0 源码树与官方技术文档（本文全部源码结论给出文件与行号，可在 AFSIM 2.9.0 发行版复核）

$2$ 华为技术有限公司. 超节点与灵衢（UnifiedBus）互联协议公开技术材料（华为全联接大会、昇腾社区技术文档），2025

$3$ Briggs G J. Harnessing Constructive Simulations for Reinforcement Learning $R$ . Santa Monica: RAND Corporation, RRA1722-6