Butler

Fire Control-Node Engagement Technology (FC-NET): 

Fire Control-Node Engagement Technology (FC-NET) Deborah A. Butler Aviation and Missile Research, Development, and Engineering Center (256)876-1303 deborah.butler@rdec.redstone.army.mil Implementing FC-NET: Initial Experiences

Overview: 

Overview Introduction XD1 Weapon System Development Environment Implementation Description Conclusion

Slide3: 

“Stove-Pipe” Solutions Proprietary Solutions Limited Software Reuse Non-Interoperable Large Logistic and O&S Budgets Non-Scalable Non-Reconfigurable Single Weapon Centric Non-Standards Based FCS Unique Point Designs for Fire Control Reconfigurable, Flexible, System of Systems The FC-NET Fire Control Architecture is Modular, Distributable, and Scalable to Match the Flexible, Configurable Nature of FCS. FC-NET Solution The Fire Control Challenge

Fire Control Puts Munitions on Targets: 

Fire Control Puts Munitions on Targets Target Acquisition ECC/Gunner Target Selection Weaponeering Weapons Assignment Target Engagement Damage Assessment Weapon System Estimator Targeting Tracker Track DB Correlator Weapon Suite Munition Launcher Sensor Suite Sensor Acquisition Tracking Platform Suite Platform Position Operator Environment Manager Weapon Targets

Program Status: 

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

XD1 Weapon System: 

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

Integrated Crew Station (ICS): 

Integrated Crew Station (ICS) Using TARDEC’s 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).

Development System: 

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

Free and Open Source Tools: 

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

Target System: 

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 C++ WSTAWG OE 2.0 libXML2 xmlwrap Development System VTT M20 Platform TCP/IP RS232 CMS LEU TCP/IP LCPK LEU TCP/IP TCP/IP TFTP NFS RLOGIN

Free and Open Source Libraries: 

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

FC-NET SIL Logical Connectivity: 

FC-NET SIL Logical Connectivity

FC-NET API Implementation: 

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

Impact of IDL on Implementation: 

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

Impact of Implementation on Architecture: 

Impact of Implementation on Architecture Implementation Required Refinement of the Architecture’s 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

Example Munition Domain Component Consolidation: 

Example Munition Domain Component Consolidation Munition Munition Predictor Physical Munition Devices Launcher Domain Munition Operator Munition Devices BEFORE AFTER Munition Predictor Physical Munition Devices Launcher Domain Munition Munition Devices

FC-NET XD1 Source Code Structure: 

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 FC-NET Fire Control Foundation Classes XD1 Skeleton Classes FC-NET Communications Library

Conclusions: 

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

Contact Information: 

Contact Information Joel Sherrill Director of Research and Development OAR Corporation 4910-L Corporate Drive Huntsville, AL 35805 Voice: 256-722-9985 FAX: 256-722-0985 Joel.Sherrill@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: 256-876-9476 Deborah.Butler@rdec.redstone.army.mil