填补COTS子系统集成的空白

随着数字战场的形成，定义嵌入式计算系统的边界和要求变得越来越困难。战斗机、直升机或无人机等平台本身可能包含数十个子系统，需要与任何其他类型的平台合作执行任务，从而增加了整体复杂性。COTS供应商必须加紧了解更广泛的问题，即如果他们要向客户提供集成的子系统，他们的产品将如何使用。

诺斯罗普·格鲁曼公司向海军提供的RQ-8火力侦察无人机就是这样一个复杂系统的一个很好的例子。火力侦察兵是为从军舰的直升机甲板上进行垂直起降（VTOL）操作而设计的，可以半自动地执行其大部分任务。Fire Scout最初被设计为一个空中监视平台，将视频流式传输到地面，它不断发展以适应多种传感器类型和空对地武器，成为RQ-8B。它现在被选为陆军未来作战系统（FCS）的IV-A级旅级无人机。

随着Fire Scout等平台的发展，它们采用了更多的嵌入式计算功能。这些平台通常采用增强型飞行管理系统、

多传感器有效载荷接口子系统以及基于以太网或交换结构技术的增强型平台内网络的形式。为了降低项目成本和部署时间，诸如此类的子系统基于COTS模块和软件，这也实现了快速原型组装和早期集成。为了巩固这些优势并利用他们广泛的产品知识，COTS供应商可能会试图为此类项目提供集成的，应用就绪的子系统，而没有对所涉及的复杂性有足够深入的了解。

成功的 COTS 子系统规范将包括以下应用级要求：

多级 I/O 和网络互操作性 – 物理、电气、协议性能和响应以及驱动程序要求

处理器性能、内存容量和带宽可用于 RTOS、驱动程序和中间件之上的用户应用

处理器/实时操作系统组合对外部刺激的响应

关键算法性能参数

对于许多人来说，COTS子系统可以通过其I / O端口，内存大小，内存带宽，处理器性能以及对现成RTOS的支持来充分描述。但是，这些只是可能需要指定的参数的一小部分，以便将新的子系统放入上述无人机示例中。新子系统的各个组件之间的互操作性应该是给定的，但是子系统与现有平台其余部分的互操作性应该如何定义？供应商的 I/O 设备驱动程序可能仅针对中断驱动的操作进行了优化，但子系统可能具有阻止使用中断的实时响应或确定性要求。另一个例子可能是IP堆栈的性能，它对平台内已经过测试和验证的子系统之间的通信产生不利影响。这些类型的问题需要在选择过程中在框中打勾。

为了在子系统集成业务中取得成功，COTS供应商必须投资于更好地了解客户需求的方法。有必要开发领域专业知识 - 具有控制定律，雷达，声纳，图形，安全关键性，确定性，网络和通信的应用知识的人员，以及传统的专业产品知识。有必要提供建议，并通过对标准产品的解决方法或修改来抢占潜在的问题区域。通常，解决方案是提供替代配置以克服潜在的性能缺陷。理想的情况是在配置铸成石头之前，在具有代表性的平台环境中通过基准测试或原型设计提供证明。

基于现成的子系统，交付给客户的这些子系统的最终配置展示了在项目开发的选择和原型设计阶段开放对话的价值。

即使从采用COTS作为强制性采购政策开始已有12年，仍然有最佳做法需要探索和吸取教训，特别是在子系统集成方面。技术发展的快速发展改变了当今军事系统的作战能力，这可能造成了只有COTS供应商自己才能填补的需求分析差距。最近的行业整合现在为主要参与者提供了成功填补这一空白并实现集成COTS子系统的市场潜力的肌肉。这些解决方案很可能在领域专家、基准测试、类似应用程序的环境中的性能规范以及可能成为通用设备规范语言一部分的新的分层互操作性模型的正确组合中找到。这只会有助于推动更多的COTS采用，并缩小承包商和供应商的需求和期望之间的差距。

审核编辑：郭婷