RAPID PROTOTYPING AND TEST OF A C4ISR KU-BAND ANTENNA POINTING AND STABILIZATION SYSTEM FOR COMMUNICATIONS ON-THE-MOVE

Transcription

1 RAPID PROTOTYPING AND TEST OF A C4ISR KU-BAND ANTENNA POINTING AND STABILIZATION SYSTEM FOR COMMUNICATIONS ON-THE-MOVE Sam Nazari, Keith Brittain, David Haessig BAE SYSTEMS, CNIR Div. Wayne, NJ ABSTRACT A key requirement of the Army s Future Combat System (FCS) is that of wideband Communication-On- The-Move (COTM) while traversing rough, off-road terrain at moderate speed. This capability was recently demonstrated during COTM exercises involving the C4ISR Ku transmission subsystem operating on a HMMWV and communicating with an airborne vehicle. This paper provides an overview of this data link s functional architecture with emphasis given to the design, implementation, and test of the pointing and stabilization subsystem. Development cost and schedule advantages realized by using a model-based design approach for realization and test of the embedded control software are described. The performance of the stabilization system on MIT s 6DOF motion table is provided, and the end-to-end operation of the entire communication link on-the-move at Lakehurst NJ on a HMMWV while receiving live data from an airborne target is discussed. INTRODUCTION BAE s C4ISR equipment is designed to meet the communication requirements of the Army s Future Combat System (FCS), a networked system of systems utilizing advanced communications and technologies to link soldiers with both manned and unmanned ground and air platforms and sensors. 1 A critical FCS requirement is that of Communications On-The-Move (COTM) during Ka-band SATCOM and Ku-band terrestrial communication. A vehicle containing both of these systems is shown in Figure 1. This paper s focus is the Ku-band antenna subassembly, in particular the design, implementation and test of the pointing and stabilization system. 1 BAE Systems CNIR is the prime for system design and integration of FCS Integrated Platform Communications (IPCS) using JTRS Cluster 1 & 5, WIN-T, and Network Data Link (NDL) radios. Figure 1 Test vehicle containing BAE s C4ISR 2 channel radio driving the Ka SATCOM (larger) and the Ku point-to-point terrestrial (rear) antenna sub-assemblies POINTING/STABILIZATION SYSTEM DESCRIPTION Line-of-sight pointing and stabilization is affected using a two-axis gimbaled system supporting the Ku-band antenna, a flat plat slotted array with a 3 db beamwidth (at the 15.4 GHz high end of the spectrum) of approximately 4 degrees. In addition, this assembly involves a sub-array integrated with the main and allowing the larger pointing errors that may occur during near-zenith operation (i.e. when pointing overhead). When vehicles are overhead, altitude limitations reduce the maximum potential pathloss, allowing for a smaller antenna having a larger beamwidth. An allotment of 1 db pointing loss fixes the allowable overall pointing error at ±1 and approximately ±4 with the main and sub-array antennas respectively, accuracies achievable using a feed-forward, open-loop pointing approach. As shown in Figure 2, the attitude of the vehicle to which the assembly is attached is measured by a GPS/INS and used to derive a commanded pointing direction to the target, the vehicle hosting the other end of the data link. Target location is initially provided by a Mission Management System (MMS) for link establishment. Then after established, this location is passed through the data link itself. 1 of 7

2 GPS/INS Euler Angles Body Rates Body Accel (200 Hz) RS422 Figure 2 Open-loop Pointing/Stabilization System Architecture An estimate of pointing accuracy achievable is determined using a Pointing Error Budget, a list of pointing error sources which each contribute to the overall error. In this system the terms of the pointing budget, shown in Table 1 for both axes, are summed. Not only does this produce a worst-case estimate of performance, but it also sensible to sum many of these. For example, positioner dynamic error, INS drift, data latency, and misalignment often occur simultaneously and with the same polarity and direction, thus they should be summed ( = 0.62). Static error, target location acceleration and GPS error all occur with directions that are uncorrelated and random in nature, thus these components are added through rss ing, yielding a total of approximately 0.66 degree per axis. This error budget applies when the host vehicle is subjected to a proving ground course identified as Churchville B, a particularly severe course representing off road motion of a HMMWV at 25 mph. Several of the contributors to this budget have been verified through a 6DOF motion table implementing this Churchville B course during testing described in the sections that follow. Table 1 Ku-band Pointing & Stabilization System Error Budget OVERALL POINTING ERROR BUDGET Error Source WBUT Command Generator 200 Hz Target Location Predictor Az & El Commands (1000 Hz) Mode control, Status 1 Hz Azimuth Error (deg) Elevation Positioner Dynamic Error Positioner Static Error GPS/INS Drift Error (TALIN sigma) GPS/INS Data Latency Error Aircraft to vehicle coordinate frame misalignment Target Location Uncertainty due to target acceleration Target Location Uncertainty due to GPS error at 65k ft TOTAL POINTING ERROR (Sum of Component Parts): Recognize that this error applies when not pointing at very high elevation angles (near zenith). Pointing error grows significantly due to torque limitations when the nominal pointing direction is near the zenith location, as discussed in the testing section below. RS42 2-Axis Pointing System Target Location and Velocity data (1 Hz) Target Location and Velocity data from Host (GD) UAV Slotted array antenna An open-loop approach is one that does not employ a direct measure of pointing error, i.e. there is no closed-loop feedback of pointing error to the controller. One simply computes a pointing direction relative to an earth fixed (local level) coordinate frame, and then drives the antenna to that angular location using a closed-loop pointing servo. This has the effect of achieving both pointing relative a known earth fixed frame, and stabilizing the antenna s line-of-sight by rejecting host vehicle riling motion through accurate and highly dynamic pointing relative to an inertial frame. The Command Generator algorithm (see Figure 3) uses vehicle and target location data defining the vector along which to point in an earth-fixed local level frame, and it receives vehicle attitude data to allow computation of the required pointing angles in the vehicle body frame. TALIN GPS/INS Vehicle Location (lat, lon, alt) Compute Target Location in Local Level Coordinates Euler Angles Target Location - PT (lat, lon, alt) Body Angular Rates Trans. Onto Vehicle Body Frame Body Angular Accelerations Figure 3 The Command Generator uses attitude and location data to generate high fidelity pointing commands driving the 2-axis pedestal RAPID PROTOTYPING AND TEST High Level Characteristics For the pointing system under consideration, the Rapid Prototyping process can be characterized into three separate discussions: Pre-Deployment Process Actual Deployment Process Post-Deployment Process Command Generator Compute pointing vector at current time Briefly, the Pre-Deployment Process consists of : Identification of the development approach (essentially, Model Based Prototyping vs. Conventional Approaches), identification of actual system specifications that are to be mapped into either software documents for the conventional approach or models which will be enhanced for Prototype Deployment, selection of sampling frequency and real-time data logging considerations. The Actual Deployment discussion is limited to our experience with Real-Time Parameter Adjustment in the prototype algorithm, Execution Speed of Prototype, an xpc RTOS primer and our overall experience with the general process. 200 Hz Compute Az and El angles to target 1000 Hz Az / El 1000 Hz 2 of 7

3 The Post-Deployment Process discussion wraps up with a description of the xpc host to target data management system, Revisions and Tuning for future Deployments and sets the stage for a discussion of the Production Code Generation Phase. After the Post-Deployment Process it is customary to begin the discussion of Production Code Generation or the Flight Code Phase. It is in this phase that Automatic C Code was generated from the Command Generator and carefully integrated with the hand written C4ISR Radio software. Pre-Deployment Preparation At the outset of this project the Model Based Prototyping Paradigm was viewed with some skepticism. Nevertheless, given the short schedule and the lack of deployment hardware on which to test the algorithm, the Model Based Prototyping approach was selected. In addition to saving time by allowing the testing of the Command Generator Algorithm early on, the Model Based Prototyping approach offered two other attractive incentives: 1) allowing deployment of code generated using Simulink models created when developing and simulation testing the system, and 2) permitting complete control over the fine tuning of the algorithm. This is particularly attractive since it eliminates the possibility of error or misinterpretation introduced by a second party. Once the Model Based Prototyping Approach was selected, a particular Target was to be identified. The xpc toolbox offered a particularly attractive Target for two very simple reasons: 1) the toolbox included interface blocks which were essentially device drivers written in C and 2) the toolbox turns any desktop PC into a Real-Time system on which the Pointing Algorithm could be deployed. This was accomplished by booting the Desktop PC into the Vendor provided RTOS. Since this toolbox comes with the device driver blocks, it is not necessary to re-write these device drivers for the Vendor s RTOS. Furthermore, the source code is available for inspection and customization by the user. After identification of the Target and its associated hardware, identification of all the relevant specifications to be included in the model begins. Essentially this includes all the Command Generation specification document, the TALIN 5000 Attitude, Position and Status ICD and the Ku-Pedestal ICD. These three categories of specifications and ICD s capture all the relevant interfacing and algorithm development necessary for this prototype. At the core of the new model is the Command Generator algorithm. Inputs to the algorithm are provided primarily by the TALIN 5000 Inertial Navigation Unit. These inputs are Euler Angles and Rates which are parsed in the Simulink sub-module responsible for parsing input messages. Executive level communication protocol supervision was performed the Simulink tool Stateflow. A similar approach proved satisfactory for the communications interface to the Ku-Pedestal (see Figures 4 and 5). TALIN 5000 Antenna Pedestal Figure 4-Block Diagram of the Rapid Prototyping Apparatus, Ku-Pedestal & TALIN 5000 Inertial Navigation Unit Data Logging/ Post Processing TALIN 5000 Triggers GPS data, inertial data Initialization messages Quatech RS422 Board (500 kbps) Quatech RS422 Board (460.8 kbps) xpc RS422 Device Driver xpc RS422 Device Driver xpc Target Control & Interface Model Gimbal Commands, Status Host PC (Laptop) Target PC RTOS ( Realtime Target - Specific Code generated from Simulink model) Antenna Positioner Message received trigger Parsing, Processing Scaling Model ( StateFlow ) Message Packing CRC, IEEE 754 model Status Ethernet Live Parameter updates and control coefficients 2 nd Ethernet (WIN - T) Intranet Command Generator Data Logging Figure 5 Data Communications illustration for the RPA, Ku-Pedestal and TALIN 5000 Inertial Navigation Unit. With the aid of Stateflow, supervisory logic was introduced into our Rapid Prototyping Model. After measuring the TALIN latency and timing jitter carefully, it became clear that the TALIN clock used in conjunction with Stateflow could adequately provide system timing and synchronization. Stateflow was a critical element in accomplishing this. The Rapid Prototyping Model employs Stateflow to trigger the execution of the Command Generator Algorithm so that it is in exact synchronization with 3 of 7

4 the TALIN 5000 Inertial Attitude Message (broadcast every 5 msec ). One important observation to note is that the synchronization procedure does involve increasing the overall sampling rate of the model. The Rapid Prototyping Model is a Single Rate Model and some considerations are necessary. Sampling too low may cause poor performance or even instability (cannot close the loop fast enough to compensate for Churchville B inputs, cannot parse data and many not complete the data communications protocol etc.) However, a sampling rate that is too fast has a higher computational cost. We have also experienced some xpc RTOS issues at higher sample rates. Also worth mentioning is the Target s internal hardware latency (from bus/bridge to processor etc). For this system, the hardware internal latency was found to be negligible with specific HIL testing. However, this may not be the case for more cost effective implementations. In general it is possible to obtain these parameters from the desktop Vendor before the time of purchase. The Target used in this application had a considerable capability for on-line data storage. 1 GB of RAM was allocated to the overall system. From that, about 1 MB was allocated to the RTOS, model C-Code and various drivers (Network and RS-422). The remaining portion was used for on-line Data Storage. We also found it useful to display many signals on the Target Desktop in a near realtime fashion; however, this was not a requirement. In the future, it may be possible to use a shared memory card to divide the Rapid Prototyping Model into two sections: 1) the pointing algorithm and 2) the supporting interfacing models. Each of these sections would be run on two separate desktop PC s. These machines would share the same memory space and would trigger tasks on each other via an interrupt line. With the shared memory card, one would have to carefully model the supporting interfacing models to avoid incorrect system execution; however the computational advantage of isolating the pointing algorithm from the supporting interfacing models makes this an attractive option for future implementations. Actual Deployment & Post-Deployment At the time of the actual deployment it was necessary to adjust some controller parameters in real time. This was not a problem since the xpc Target toolbox allows the Rapid Prototyping Model to be connected through Simulink directly to its c-code counter part on the Target. To use the term loosely: it is a debug mode. In this debug mode, one has control over all parameters in the model, changing them induces an instantaneous change in the associated c-code actually being executed in real time on the Target. This is a feature that was a great advantage of the Model Based Prototyping Paradigm. The execution of the code and the resulting CPU Time loading was measured very accurately in two ways: First with the tools provided with the xpc Target toolbox and secondly through actual data from the Target Desktop. We were able to verify that our sample rate was the optimal choice based on typical time and cpu loading values. Internal execution of the Model C-Code is essentially divided into three sections: code initialization, code termination and code execution. The xpc Target RTOS executes the code initialization and code termination sections of the c-code once after any new model is loaded into the Target memory. After this one time process, the Target does not repeat initialization unless in debug mode. Instead, it continuously executes the Code Execution section of the c- code (the system algorithm and all its supporting modules). During this phase, if any data is to be stored for further processing (offline), it is stored locally in the Target s RAM. If real-time execution of the model is stopped, the Target may communicate via TCP or RS232 to a host computer in order to transfer the RAM Stored data. In this way it is possible to perform operational tests that involve the capture of large quantities of data. After Post-Deployment it is assumed that the controller or algorithm is completely ready for production. This part of the Production Code Generation Phase consists only of the Core Command Generator Model. The Mathworks Code Generation Technology is capable of Expression Folding and Loop Fusion to reduce generated SLOC and customization of the generated c-code. Furthermore, use of the provided dictionary of Simulink blocks helped to reduce generated c-code defects. The flexible structure of the custom code option allows one to modify the existing generated code or incorporate hand written legacy code into the final Production Grade C-Code. The Code Generation Technology is also very usable. One can deploy to a variety of Targets with just a few clicks. Options specific to various Targets are available. One area which we can explore in the future is the model advisor, which was not available at the time of our deployment. The generated code is also readable, with copious relevant comments. Once the code is generated, it is possible to trace the code back to the actual model with a click. There are persistent identifiers and the capability exists to add a DOORS interface. Furthermore, the generated code also offers Multi-Rate support. This facilitates sample-time constraints, rate grouping and enhanced asynchronous time and event support. A flow diagram of the overall Model Based Prototyping Paradigm is given in Figure 6. 4 of 7

5 Modeling of physical system & design level controller development (simulink) Design control algorithm & system performance Upgrade controller model to code generation level Extract controller subsystem to new model RTW / Embedded Coder code generation Hand code to SW developers for product integration Add interface models (stateflow) and device drivers (xpc) Truth Model Interface with physical system & test Data acquisition, actual hardware (xpc) Truth model validation, post processing (Matlab, Simulink) Figure 6 -- Outline of the Model Based Prototyping Paradigm STABILIZATION SYSTEM TEST AT LINCOLN LABS The Ku-Pedestal along with the TALIN 5000 INU and the Rapid Prototyping real-time control hardware were reassembled on a 6DOF Motion Simulator Table at Lincoln Labs in Lexington MA. Angular motion data representing the Churchville B proving course supplied the excitation source to the table. A large aperture collimated light source attached to the ground provided a fixed inertial reference. Use of a large aperture light source allows the unit under test to translate through significant distances while remaining within the light source field-of-regard, thereby making the angular deflection measurement insensitive to linear translation. A corresponding photo detector was attached to the antenna face to measure angular deflection. The antenna face plate was designed so that this addition in camera mass would not upset the overall balance of the Ku-Pedestal. A tilting fixture was used to adjust elevation angle to the target (see Figure 7 showing fixture at an angle of approximately +60 ). By changing the elevation angle of the tilt fixture, BAE SYSTEMS was able to assess line of sight error as a function of nominal elevation to the target. It was also possible to control the intensity of the angular motion of the 6DOF Motion Simulator. Figure 7 The prototype pedestal with the UUT on the 6 DOF motion simulator, surrounded by the telescope support structure holding the collimated laser light source at elevation angles ranging from 0 to 90 degrees. The performance measured on the 6DOF motion table is given in Figures 8 and 9. Figure 8 contains the results of a single experiment for a nominal elevation angle of 0 degrees, and shows the required accuracy for that part of the system under test (0.4 degree see accuracy budget). A summary of performance over all elevation angles, shown in Figure 9, along with the performance requirement curve generated from the main and sub-array antenna patterns (shown as a thick line). Note that the dark blue requirement line falls at approximately 0.4, the requirement given in Table 1, for low elevation angles. Elevation angles above 30 result in reduced range due to target altitude limitations, allowing the maximum allowable error to increase with elevation as shown. At very high elevation angles above 65 the knee in the requirement curve indicates the use of the sub-array antenna which permits larger tracking error. 5 of 7

6 Figure 8 Actual pointing error scatter (degrees) during Churchville B shaker motion, nominal elevation = 0 degrees Error (deg) Error vs Elevation -- MIT Lincoln Labs Table Input Performance Requirement Elevation (deg) Requirement Performance Achieved 100% Figure 9 Summary of achieved performance showing that the requirement is met for 99% of the overall pointing error levels measured during test Note that as elevation angle increases, line-of-sight pointing error tends to increase due to the zenith effect that occurs with 2-axis pointing devices. However you will note that tracking error exceeds the performance requirement only 1% of the time during the (approximately 3 minute) Churchville B proving ground course. BAE CNIR COMMUNICATION S ON THE MOVE DEMONSTRATION 99% 95% 90% BAE SYSTEMS CNIR has successfully demonstrated key Communications-on-the-Move technologies (a C4ISR Strategic Initiative) to an elite group of Officials from the Army, Navy and Airforce. The technologies demonstrated included the C4ISR radio, a Ku Tracking antenna, a Ka Tracking Antenna, a GBS receiver as well as the associated controlling software/firmware. In addition, various Legacy Radios and Commercial equipment have been used to increase the impact and to provide a simulated scenario based demonstration. These demonstrations mark significant Communications on the Move Milestones at BAE CNIR. COTM Point to Point Utilizing the antenna systems proven on the Lincoln Lab s COTM Churchville B simulator, BAE CNIR concluded its initial systems integration with a major demonstration in November of This demonstration was comprised of a Mobile Integration Vehicle (MIV) equipped with the COTM equipment driving near BAE facilities while communicating to a fixed 30 meter tower which was connected to a Command Center and BAE s Systems Integration Lab Facilities. These three entities allowed BAE CNIR to demonstrate the ability to: 1.) pass simulated situational awareness tracks from the Systems Integration Lab in plant 18 via to the 30m tower down into the Reston RV (Command RV) displayed and then routed the data to the C4ISR radio, retransmitted using the TCDL Symmetric Wave via a Ku Omni Antenna Subsystem Assembly to the MIV while on the move which in turn displayed the data. 2.) receive a GBS video feed from UFO 9 via the Ka Tracking Antenna Subsystem Assembly decoded and displayed the video on the move. The video display was then halted and re-routed to the C4ISR radio and re-transmitted using the TCDL Symmetric Waveform. This was received at the tower and passed into the Command Center RV and displayed on a TV Monitor. 3.) displayed GPS coordinates of the MIV on a Large Flat panel Monitor in the Command RV This information was provided from the MIVs GPS via a VRC-99 Link. 4.) established a Voice over IP call from the Command RV to the MIV requesting transfer of the video source to the mobile IP camera, which could be controlled via the Command RV. 5.) established a Voice over IP call from the truck to the Command RV and provided a previously captured Hyperspectrual Video Clip for viewing in the Command RV. COTM via Bridged Network Building on the success of the capabilities demonstrated in November 2004, BAE through a Cooperative Research and Development Agreement with CECOM utilized an Airship (shown in Figure 11) and a second Mobile Integration Vehicle (shown in Figures 1& 13) to demonstrate the ability to seamlessly pass data between three On-the-Move nodes as a small bridged network. During this demonstration BAE utilized the proving grounds of the Lakehurst Naval Station to demonstrate not only BAE CNIR s capabilities to perform COTM but to maintain that communications while moving off road. During the final demonstra- 6 of 7

7 tion a motor failure on the Airship forced an Emergency Crash Landing and subsequent grounding of the Airship but BAE CNIR quickly responded by reconfiguring the Airborne Electronics for ground operation, mounted this equipment on a third Vehicle (Shown in Figure 12) and was able to demonstrate COTM communications on the Ground. However in the weeks preceding this event BAE CNIR was able to: 6.) establish a bridged network between two Mobile Integration Vehicles via an Airborne Frequency Division Multiplexed Payload on station at 1500 ft while passing full duplex 8 Mbps data. 7.) validate the ability to point to the Airship while performing On The Move maneuvers both on and off road. 8.) prove the capability of zenith pointing and switching between the main and sub-arrays of the mobile ground antennas. 9.) demonstrate the ability to control the Airborne Payload Video Equipment and Combat ID Simulation Software and to display this information in either MIV. Figure Emergency Reconfiguration Figure MIV2 On-The-Move CONCLUSIONS Figure Airborne Communications Payload A major milestone of BAE s C4ISR Strategic Initiative was reached with the development and demonstration of both Ku- and Ka-band on-the-move communications capabilities. This paper discussed the Ku antenna subsystem, specifically focusing on the model-based design, integration, and test of the antenna pointing and stabilization controller. In addition it provided an overview of the full system testing experience during which off-road communications on the move while transmitting 8 Mbps data to an airborne blimp was demonstrated. Figure Airship Ready for Launch 7 of 7