Fire ControlNode Engagement Technology FCNET

1
Fire Control-Node Engagement Technology (FC-NET)
Implementing FC-NET Initial Experiences
Deborah A. Butler Aviation and Missile Research,
Development, and Engineering Center [phone]
deborah.butler_at_rdec.redstone.army.mil
2
Overview

• Introduction
• XD1 Weapon System
• Development Environment
• Implementation Description
• Conclusion

3
The Fire Control Challenge
Unique Point Designs for Fire Control

• Stove-Pipe Solutions
• Proprietary Solutions
• Limited Software Reuse
• Non-Interoperable
• Large Logistic and OS Budgets
• Non-Scalable
• Non-Reconfigurable
• Single Weapon Centric
• Non-Standards Based

FCS
Reconfigurable, Flexible, System of Systems
Future Combat Systems
Requires a New Vision for Providing Fire Control
Capabilities for Multi-Missions, Weapons, and
Platforms.
FC-NET Solution
The FC-NET Fire Control Architecture is Modular,
Distributable, and Scalable to Match the
Flexible, Configurable Nature of FCS.
4
Fire Control Puts Munitions on Targets
Weapon Suite
Weapon System
Targets
Weapon
Munition
Launcher
Targeting
ECC/Gunner
Estimator
Sensor Suite
Target Acquisition
Manager
Target Selection
Sensor
Tracker
Acquisition
Weaponeering
Track DB
Tracking
Weapons Assignment
Correlator
Platform Suite
Target Engagement
Platform
Damage Assessment
Position
Operator
Environment
The Fire Control System is a Force Multiplier for
the Individual Soldier More Targets, More
Quickly, More Accurately!
5
Program Status

• FC-NET is a DoD Science and Technology Objective
  (STO) Program.
• Currently in Year 2 of the 5 Year Program.
• Developing a Series of Experimental Weapon
  Systems to
• Evolve the Capabilities of the FC-NET
  Architecture
• Populate a Set of Fire Control Foundation Classes
  (FCFC)
• Integrate Missile- and Gun-Target Pairing
  Algorithms
• Demonstrate FC-NET Applicability to Future Weapon
  Systems
• Partnering with TARDEC (Detroit Arsenal) for
• Reuse of Existing Integrated Crew Station
• User Interface Expertise
• Partnering with ARDEC (Picatinny Arsenal) for
• Gun-Target Pairing Algorithms

6
XD1 Weapon System

• XD1 is an Experimental Weapon System Composed of
  Both Real Hardware and Simulations of Tactical
  LRUs.

7
Integrated Crew Station (ICS)

• Using TARDECs Vetronics Technology Testbed (VTT)
  as ICS Provides Real Soldier Machine Interface
  (SMI) Functionality Using Tactical Hardware
• VTT Includes Touch Screen, Map Display and Target
  List
• VTT Provides an Upgrade Path to Next Generation
  Crew Station Technology Being Developed by the
  Crew Integration and Automation Testbed (CAT)
  Advanced Technology Demonstration (ATD).

8
Development System
Development Client
Windows 2000TM PC VNC, ssh, scp
Development Server Dual 2.4 Ghz XeonTM 2 GB
RAM 160 GB disk ------------------------ Redhat
GNU/Linux 7.3 gcc CVS Apache GNATS
TCP/IP
Development Client
Target System
TCP/IP
Windows XPTM PC VNC, ssh, scp
TFTP NFS RLOGIN
TCP/IP
TCP/IP
Development Client
Windows 2000TM PC VNC, ssh, scp
9
Free and Open Source Tools

• fcnetidl Compiler
• Custom Tool Based on ORBit IDL Parsing Library
• Automatically Generated Approximately 350,000 C
  SLOC
• Generated Code for
• Client-Server Communications
• XD1 Application and FCFC Class Skeletons
• Doxygen
• Automatically Generated 1282 Page API Description
  Document

10
Target System
Fire Control Computer Radstone VME64
SBC 400 Mhz PowerPC 7410 256 MB RAM 64 MB Flash 4
serial ports 10/100 BaseT UltraSCSI Dual
redundant 1553 Interface -------------------------
----------------- LynxOS 3.1.1 FCFC FCNETcomms GNU
Common CWSTAWG OE 2.0 libXML2 xmlwrap
VTT
TCP/IP
Development System
CMS LEU
TCP/IP
TCP/IP
TFTP NFS RLOGIN
LCPK LEU
TCP/IP
M20 Platform
RS232
11
Free and Open Source Libraries

• GNU Common C
• Provides an Abstract Interface for Serial Ports
  and TCP/IP Sockets
• WSTAWG OE 2.0
• C Bindings Developed for TARDEC OE 2.0
  Implementation
• libXML2
• Support for XML-Based Configuration Files
• xmlwrap
• C Wrapper for libXML2

12
FC-NET SIL Logical Connectivity
13
FC-NET API Implementation

• Based Upon the FC-NET Architecture
• Defined in Object Management Group (OMG) IDL
• IDL is Standardized and Compilable
• IDL has Mappings to C, C, Java, Ada, ...
• IDL use Forced Consideration of Implementation
  Issues
• Implementation Issues Led to Revisions in
  Architecture
• Language-Independence of IDL Limits
  Object-Oriented Implementations
• No Function Overloading
• No Polymorphism
• Single Inheritance Only

14
Impact of IDL on Implementation

• Identified and Isolated Commonalities in
  Position- and Device-Oriented Components
• Developed a Position Class Hierarchy that
  Incrementally Exposes Different Types of Position
  Information (e.g., Location, Orientation,
  Acceleration)
• Developed a Common State Model for all Physical
  Devices (e.g., Launcher, Platform, Munition).
• Device State Model is Embedded in a Device Class
  Hierarchy Built on Top of the Position Class
  Hierarchy

15
Impact of Implementation on Architecture

• Implementation Required Refinement of the
  Architectures Initial Set of Attributes,
  Services, and Notifications
• Services, Attributes, and Notifications were
  Renamed to Enhance Naming Consistency Across
  Components.
• Services, Attributes, and Notifications were
  Added to Ease Necessary Component Interactions
• Components were Consolidated to Enhance
  Encapsulation

16
Example Munition Domain Component Consolidation
Launcher Domain
Munition Operator
Munition Predictor
Munition
BEFORE
Physical Munition Devices
Munition Devices
Launcher Domain
Munition Predictor
AFTER
Munition
Physical Munition Devices
Munition Devices
17
FC-NET XD1 Source Code Structure

• FC-NET is Written in ANSI C
• XD1 Application is Built on a Multi-Tiered
  Foundation of Supporting Classes
• Every Application Component Runs as an
  Independent Process

XD1 Application Code
XD1 Skeleton Classes
FC-NET Fire Control Foundation Classes
FC-NET Communications Library
18
Conclusions

• The Architecture is Feasible
• Implementing Components as Separate Processes Has
• Eased Assignment of Programming Tasks to
  Developers
• Reduced Developer Interdependence During Testing
• Eased Construction of Test Clients and Subsystems
• Eased Fault Isolation
• Communication Overhead of Separate Processes is
  Acceptable, Even in Initial Implementation
• Use of XML Files Provides Flexible, Uniform, and
  Readable Component Configuration Capability

19
Contact Information

• Joel Sherrill
• Director of Research and Development
• OAR Corporation
• 4910-L Corporate Drive
• Huntsville, AL 35805
• Voice 256-722-9985
• FAX [phone]
• Joel.Sherrill_at_OARcorp.com

• Deborah A. Butler
• FC-NET Program Manager
• U.S. Army Aviation and Missile Command
• ATTN AMSAM-RD-MG-NC (Deborah A. Butler)
• Redstone Arsenal, AL 35898-5000
• Voice 256-876-1303
• FAX [phone]
• Deborah.Butler_at_rdec.redstone.army.mil