Appendix D LIST OF ABBREVIATIONS by lnd15050

VIEWS: 5 PAGES: 17

									                   NAVAL COMBAT SUPPORT SYSTEM (NCSS)
                  SOFTWARE REQUIREMENTS SPECIFICATION

1.0   INTRODUCTION

1.1    The overall Naval Combat Support System is a real-time system whose purpose is to
       control the primary combat support systems aboard the Royal Nova Scotian Navy
       (RNSN) destroyers. The need for such a system was identified as a result of the RNSN
       having purchased a fleet of several destroyers from the Albanian Navy, only to discover
       that the combat support control software was proprietary to the Albanian government
       and not releasable to the Independent Republic of Nova Scotia.

1.2    The NCSS is responsible for the control and monitoring of onboard equipment involved
       with ship navigation and piloting, weapons management and electronic warfare. The
       system is broken down into the following subsystems:

            a. Bridge Control Subsystem (BCS) – responsible for the overall control and
               display of all of the other combat subsystems, including the ability to direct
               the piloting of the ship, to apply electronic warfare support and
               countermeasures, and to control and fire the weapons;
            b. Navigation & Engine Subsystem (NES) – responsible for the control of the
               navigation equipment and the piloting of the ship while in auto-pilot mode;
            c. Electronic Warfare Subsystem (EWS) – responsible for the control of the
               electronic warfare equipment and jamming of threats while in auto-jam mode.
            d. Weapons Management Subsystem (WMS) – responsible for the control of
               target tracking and weapons deployment equipment including target
               acquisition, tracking and launching of weapons when in the auto-fire mode.

1.3    In addition to being a real-time system, NCSS is also a mission and safety critical
       system. The lives of the crews of the RNSN destroyers depend upon the integrity of the
       NCSS equipment and software.

2.0   GENERAL REQUIREMENTS

2.1    The implementation shall be demonstrated by completing the 5-minute simulation
       exercise detailed below in Section 4. Each contractor team will be evaluated based upon
       several pass or fail criteria, again as set out below in the detailed requirements.

2.2    The implementation shall interface with the Government Furnished Equipment (GFE)
       Input /Output Emulator (IOEmulator). Interface control data for the IOEmulator is
       provided in Section 5. Further details as to the implementation of the IOEmulator will
       be provided under separate cover and/or briefed to the contractor teams.

2.3    Due to the fact that many aspects of the combat support systems are safety critical, the
       NCSS is expected to be appropriately fault tolerant.




                                              1
3.0     NCSS SOFTWARE REQUIREMENTS

3.1      Bridge Control Subsystem (BCS)

3.1.1    Modes of Operation

BCS-MR-01     The BCS shall support the following modes of operation:

              a. standby – any NCSS system level initialization shall take place within this
                 mode. The BCS shall only be in this mode during start-up or possibly re-start.
              b. operational – the BCS shall be in an operational mode during all normal
                 functioning of the NCSS. Start-up of the other subsystems shall not commence
                 until the BCS is in its operational mode of operation.
              c. failed – the BCS shall enter a failed mode of operation only if the entire NCSS
                 is inoperable. If a subsystem(s) fails and the NCSS is capable of operating in a
                 degraded state, the BCS shall remain in the operational mode.

BCS-MR-02     The operational mode of operation shall support a manual control mode and an
              automated control mode. For the purposes of this contract, only the automated
              mode of operation need be fully implemented. Manual control of the BCS through
              a user interface is beyond the scope of this contract.

3.1.2    Functional Requirements

BCS-FR-01     The BCS shall control the modes of operation of the NES.

BCS-FR-02     The BCS shall control the modes of operation of the EWS.

BCS-FR-03     The BCS shall control the modes of operation of the WMS.

BCS-FR-04     The BCS shall provide navigation waypoint data and urgency or desired speed to
              the NES to support auto-piloting of the ship.

BCS-FR-05     The BCS shall provide the rules of engagement to the EWS to support the auto-
              jamming of emitters.

BCS-FR-06     The BCS shall provide the rules of engagement to the WMS to support the auto-
              firing of weapons.

BCS-FR-07     The BCS shall maintain and display a status of all combat support subsystems in
              accordance with the timing requirements in paragraph 3.1.5. Status shall be
              interpreted as the current mode of operation of each subsystem.




                                               2
BCS-FR-08     The BCS shall coordinate the display of all essential combat support system
              information; it is not essential that the BCS actually perform the displaying, but
              merely coordinate display such that it is orderly. Periodicity of display data shall
              be in accordance with the timing requirements specified in paragraph 3.1.5. As a
              minimum, the data to be displayed shall include:

                     a. current navigation data (heading, speed, latitude and longitude);
                     b. emitter(s) being jammed (see definition in section 3.3);
                     c. targets being tracked;
                     d. weapons fired and their respective trajectory (azimuth and elevation);



3.1.3    Interface Requirements

BCS-IR-01     The BCS shall interface with the NES in accordance with a set of protocols to be
              determined by the contractor.

BCS-IR-02     The BCS shall interface with the EWS in accordance with a set of protocols to be
              determined by the contractor.

BCS-IR-03     The BCS shall interface with the WMS in accordance with a set of protocols to be
              determined by the contractor.


3.1.4    Data Requirements

BCS-DR-01     There shall be minimum redundancy in the use of data constants, classes,
              attributes and methods employed within the NCSS. The contractor is encouraged
              to import common data classes from the IOEmulator.

3.1.5    Timing Requirements

BCS-TR-01     NCSS status data shall be displayed every 15 seconds.

BCS-TR-02     NCSS essential combat support information shall be displayed every 5 seconds,
              except for weapons release data, which shall be displayed in real-time.

3.1.6    Fault Tolerance Requirements

BCS-FTR-01 The BCS shall be fault tolerant of subsystem failures and exhibit graceful
           degradation. To achieve this, the BCS shall operate each of the three subsystems
           on their own thread of control so that the failure of a subsystem does not prevent
           the BCS from continuing to operate, albeit in a degraded state.




                                                3
3.1.7   User Interface Requirements

             Ultimately, the BCS shall be fully implemented with a graphical user interface
             layer. However, provision of a user interface layer is beyond the scope of this
             contract. For the purposes of complying with the demonstration requirements
             detailed in Section 4, all sequences of commands, events and rules of
             engagements may be hard coded into the BCS using a state machine model.

3.1.8   Miscellaneous Requirements

             Not applicable.

3.1.9   Notes

             For more information regarding any data or protocol definitions, see the
             IOEmulator specification in Section 5.

             Commonly used C define statements are provided in the servoLib.h include file.




                                              4
Navigation & Engine Subsystem (NES)

3.2     Modes of Operation

NES-MR-01    The NES shall support the following modes of operation:

             a. standby – any NES initialization shall take place within this mode. The NES
                shall go to this mode during start-up or possibly re-start, and remain there until
                told by BCS to go to operational;
             b. operational – the NES shall be in operational mode during all normal
                functioning of the navigation subsystem and during any degraded modes of
                operation; and
             c. failed – the NES shall enter a failed mode of operation only if the entire
                navigation system is inoperable. If one of the navigation components fail and
                the subsystem is capable of operating in a degraded state, the NES shall
                remain in the operational mode.

NES-MR-02    The operational mode of operation shall support a manual pilot mode and an auto-
             pilot mode. For the purposes of this contract, only the auto-pilot mode of
             operation need be fully implemented. Auto-pilot control is further described in the
             functional requirements.

3.2.1   Functional Requirements

NES-FR-01    The NES shall be composed of the following components:

             a. an auto-pilot unit (APU) to control the piloting of the ship without constant
                monitoring and intervention by the BCS;
             b. two identical inertial navigation units (INU), one acting as primary the other
                as back-up; and
             c. an engine control unit (ECU) to control the ships engine settings.

NES-FR-02    The APU shall use waypoint data received from the BCS to determine the desired
             heading of the ship.

NES-FR-03    The APU shall use urgency or desired speed data received from the BCS to
             determine the desired speed of the ship.

NES-FR-04    The APU shall control the engine settings in order to achieve the desired heading
             and speed.

NES-FR-05    The NES shall display, or provide to the BCS for display, the following data:
             a. ship speed (in knots, use miles per hour);
             b. ship heading (in degrees);
             c. ship position (Latitude and Longitude in degrees / minutes / seconds)




                                               5
NES-FR-06    The INUs shall be capable of receiving navigation data from the IOEmulator as
             detailed below.

NES-FR-07    While operational, the primary INU shall provide navigation data to the auto-pilot.

NES-FR-08    The INUs shall be capable of receiving a failed signal from the IOEmulator. If a
             failed signal is received, it shall go to a failed state, and remain there for the
             duration of a mission.

NES-FR-09    The secondary INU shall automatically take over communication with the auto-
             pilot if the primary fails.

NES-FR-10    The ECU shall be capable of sending engine control data to the IOEmulator as
             detailed below.


3.2.2   Interface Requirements

NES-IR-01    The INUs shall interface to the IOEmulator using the INS_EmuProtocol from the
             EmulatorProtocols package detailed in Section 5.

NES-IR-02    The ECU shall interface to the IOEmulator using the Engine_EmuProtocol from
             the EmulatorProtocols package detailed in Section 5.


3.2.3   Data Requirements

NES-DR-01    The INUs shall support the data class NavData from the CommonPassiveClasses
             package detailed in Section 5.

NES-DR-02    The ECU shall support the data class EngineData from the
             CommonPassiveClasses package detailed in Section 5.

NES-DR-03 The NES shall observe the constants class IOEmConstants from the IOEmulator
          package detailed in Section 5.


3.2.4   Timing Requirements

NES-TR-01    The APU shall support timing requirement BCS-TR-02.

NES-TR-02    The INU shall acquire new navigation data from the IOEmulator 5 times per
             second.




                                               6
NES-TR-03    The ECU shall update the engine control data as necessary to maintain the correct
             speed and heading.

3.2.5   Fault Tolerance Requirements

NES-FTR-01 The NES shall be capable of operating in a degraded mode of operation wherein
           one of the two INUs can fail, and the subsystem shall continue to operate
           normally.

3.2.6   User Interface Requirements

             Not applicable.

3.2.7   Miscellaneous Requirements

NES-MR-01    The INUs shall employ unwired ports and application registration in their
             communication with the IOEmulator. The IOEmulator navigation service is
             registered under the name “INS_service”.

NES-MR-02    The ECU shall employ unwired ports and application registration in its
             communication with the IOEmulator. The IOEmulator engine service is registered
             under the name “Engine_service”.

NES-MR-03    The NES shall interchangeably interface with the navigation emulator or the
             rudder servo motor and electronic compass driver software through setting of the
             USE_RUDDER_INU_EMULATOR define in the ServoLib.h include file
             provided as GFE.


3.2.8   Notes

             For more information regarding any data or protocol definitions, see the
             IOEmulator specification in Section 5.

             The destroyers received from the Albanian’s have two notable deficiencies that
             will affect your implementation of the NES software:

                    1) The Inertial Navigation Units (INUs) are not very precise, and their
                       reliability is quite low.
                    2) The rudder deflection surface is enormous, thus giving the ships an
                       incredible turn rate (the ship can turn on the order of 35 degrees per
                       second). While this allows the ship to change direction very quickly,
                       combine it with the other deficiency above and it makes it difficult to
                       accurately maneuver, especially in combat.




                                              7
Electronic Warfare Subsystem (EWS)

3.3     Modes of Operation

EWS-MR-01 The EWS shall support the following modes of operation:

             a. standby – any EWS initialization shall take place within this mode. The EWS
                shall go to this mode during start-up or possibly re-start, and remain there until
                told by BCS to go to operational;
             b. operational – the EWS shall be in operational mode during all normal
                functioning of the electronic warfare subsystem and during any degraded
                modes of operation; and
             c. failed – the EWS shall enter a failed mode of operation only if the entire EW
                system is inoperable. If one of the EW components fail and the subsystem is
                still capable of operating in a degraded state, the EWS shall remain in the
                operational mode.

EWS-MR-02 The operational mode shall support a receive-only mode and an auto-jamming
          mode. Both modes must be fully implemented. Both modes are further described
          in the functional requirements.


3.3.1   Functional Requirements

EWS-FR-01    The EWS shall be composed of the following components:

             a. an electronic support measures unit (ESM) to provide radar band emitter
                situational awareness; and
             b. an electronic counter measures unit (ECM) to provide wide band radar
                jamming of emitters.
             c. an electronic warfare control unit (EWC) to coordinate the ESM and ECM
                usage of the electromagnetic spectrum, and to implement jamming policy.

EWS-FR-02    The ESM shall send scan signals to the IOEmulator and use returned emitter data
             received from the IOEmulator to provide emitter situational awareness to both the
             BCS and the WMS. Multiple returns are possible (probable) and include
             information regarding the emitter’s identity, quadrant location, probable platform
             type and signal characteristics.

EWS-FR-03    The ESM shall be safely in a blanking mode (and not scan) while the ECM is
             jamming. The ESM receiver will fail if this is ignored.

EWS-FR-04    The ESM shall be capable of receiving a failed signal from the IOEmulator. If a
             failed signal is received, it shall go to a failed state, and remain there for the
             duration of a mission.




                                               8
EWS-FR-05    The ECM shall be capable of sending appropriate start and stop RF energy signals
             (containing a quadrant, a center frequency and a proper technique) to the
             IOEmulator in order to affect jamming of a specific emitter(s).

EWS-FR-06    The ECM shall be capable of receiving a failed signal from the IOEmulator. If a
             failed signal is received, it shall go to a failed state, and remain there for the
             duration of a mission.

EWS-FR-07    The ECM shall ensure that a look-through policy is implemented such that all
             EWS timing requirements are met including:

             a. the ESM gets safe and required use of the spectrum,
             b. that jamming is effective (25% integrated time) and
             c. to prevent a high power amplifier (HPA) failure (continuous transmission of
                RF for longer than 1 second will result in an ECM HPA failure)

EWS-FR-08    The EWC shall implement an appropriate jamming policy based upon the rules of
             engagement received from the BCS. Specifically:

             a. the EWC shall support a receive-only mode wherein all jamming is disabled,
                and
             b. the EWC shall support an auto-jam mode wherein it shall ensure that the
                highest priority emitters are jammed subject to the rules of engagement as set
                by the BCS while in auto-jam mode.
             c. the EWC shall support multiple emitter jamming using the single (hardware)
                jammer; a minimum of three emitters should be “jammable”.

EWS-FR-09    The EWS shall display, or provide to the BCS for display, the following data:
             a. emitters being jammed (include transmission quadrant, centre frequency and
                technique mode selected);

3.3.2   Interface Requirements

EWS-IR-01    The ESM shall interface to the IOEmulator using the ESM_EmuProtocol from the
             EmulatorProtocols package detailed in Section 5.

EWS-IR-02    The ECM shall interface to the IOEmulator using the RF_EmuProtocol from the
             EmulatorProtocols package detailed in Section 5.

3.3.3   Data Requirements

EWS-DR-01    The ESM shall support the data class ESMData from the CommonPassiveClasses
             package detailed in Section 5.




                                               9
EWS-DR-02     The ECM shall support the data classes RFData from the CommonPassiveClasses
              package detailed in Section 5.

EWS-DR-03 The EWS shall observe the constants class IOEmConstants from the IOEmulator
          package detailed in Section 5.


3.3.4   Timing Requirements

EWS-TR-01     The ESM shall scan for emitters every 1 second.

EWS-TR-02     In order for jamming to be effective, an emitter shall be properly jammed for at
              least 25% of integrated time (in this sense, the duty cycle of jam versus look-
              through shall be relatively short; ie no longer than a second shall pass without a
              full jam look-through cycle).

3.3.5   Fault Tolerance Requirements

EWS-FTR-01 The ECM shall be fail-safe and always under direct control of the EWC, thus
           necessitating a watchdog timer implementation.

EWS-FTR-02 The EWS shall be capable of operating in a degraded mode of operation wherein
           the ECM may fail, and the subsystem shall continue to operate in receive-only
           mode of operation. If the ESM fails, the entire EWS system is deemed to have
           failed.


3.3.6   User Interface Requirements

              Not applicable.

3.3.7   Miscellaneous Requirements

EWS-MR-01 The ESM shall employ unwired ports and application registration in its
          communication with the IOEmulator. The IOEmulator electronic support
          measures service is registered under the name “ESM_service”.

EWS-MR-02 The ECM shall employ unwired ports and application registration in its
          communication with the IOEmulator. The IOEmulator radio frequency service is
          registered under the name “RF_service”.




                                               10
3.3.8   Notes

            The EWS is based upon a previously designed system under separate contract.
            Significant modifications to the system may be required to support the NCSS
            unique requirements.

            ECM techniques are pre-set in the IOEmulator. A technique’s effectiveness is
            measured against its ability to handle different Pulse Repetition Frequency (PRF)
            ranges. The pre-set jamming techniques operate as follows: modes 0-4 for low
            PRF emitters, modes 5-9 for medium and modes 10-15 for high.

            For more information regarding any data or protocol definitions, see the
            IOEmulator specification in Section 5.




                                            11
3.4     Weapons Management Subsystem (WMS)

3.4.1   Modes of Operation

WMS-MR-01 The WMS shall support the following modes of operation:

              a. standby – any WMS initialization shall take place within this mode. The
                 WMS shall go to this mode during start-up or possibly re-start, and remain
                 there until told by BCS to go to operational;
              b. operational – the WMS shall be in operational mode during all normal
                 functioning of the weapons management equipment; and
              c. failed – the WMS shall enter a failed mode of operation if any component of
                 the subsystem is inoperable.

WMS-MR-02 The operational mode shall support a safety-lock mode and an auto-fire mode.
          Both modes shall be fully implemented. Both modes are further described in the
          functional requirements.

3.4.2   Functional Requirements

WMS-FR-01 The WMS shall be composed of the following components:

              a. a radar control unit (RCU) to provide radar based situational awareness;
              b. a turret control unit (TCU) to control the trajectory of the missile launcher and
                 the gun, each mounted on the ship’s turret; and
              c. a weapons control unit (WCU) to control the firing of the missile launcher and
                 gun.

WMS-FR-02 The RCU shall be capable of sending scan signals to the IOEmulator and use
          radar return data from the IOEmulator to determine the location of surrounding
          ships and aircraft. Multiple returns are possible (probable) and include
          information regarding the craft’s azimuth, elevation and range.

WMS-FR-03 The TCU shall be capable of sending appropriate turret control signals (start and
          stop movements in both azimuth and pitch) to the IOEmulator in order to control
          the turret movements, thus enabling target tracking.

WMS-FR-04 The WCU shall ensure that the weapons are safely locked and that tracking is
          disabled in accordance with the rules of engagement provided by the BCS.

WMS-FR-05 The WCU shall use coordinated radar and ESM data to affect target acquisition in
          accordance with the rules of engagement provided by the BCS.




                                               12
WMS-FR-06 The WCU shall be capable of sending appropriate fire control signals to the
          IOEmulator in order to control the firing of the missile launcher and gun.

WMS-FR-07 The WMS shall display, or provide to the BCS for display, the following data:

              a. targets being tracked, and
              b. targets fired upon (include intended target, weapon selected, and trajectory).

WMS-FR-08 The WMS shall conform to the target acquisition strategy as detailed in Note 1 of
          paragraph 3.4.9.


3.4.3   Interface Requirements

WMS-IR-01     The RCU shall interface to the IOEmulator using the Radar_EmuProtocol from
              the EmulatorProtocols package detailed in Section 5.

WMS-IR-02     The TCU shall interface to the IOEmulator using the Turret_EmuProtocol from
              the EmulatorProtocols package detailed in Section 5.

WMS-IR-03     The WCU shall interface to the IOEmulator using the Fire_EmuProtocol from the
              EmulatorProtocols package detailed in Section 5.


3.4.4   Data Requirements

WMS-DR-01 The RCU shall support the data class RadarData from the CommonPassiveClasses
          package detailed in Section 5.

WMS-DR-02 The TCU shall support the data class TurData from the CommonPassiveClasses
          package detailed in Section 5.

WMS-DR-03 The TCU shall support the defined types AZIMUTH, CLOCKWISE
          CTR_CLOCWISE, AZIMUTH_STOP, PITCH, PITCH_UP, PITCH_DOWN, and
          PITCH_STOP as well as observe the defined types CLOSE, VERY_CLOSE and
          ON_TOP_OF from the ServoLib.h include file provided as GFE.

WMS-DR-04 The WCU shall support the defined types MISSILES, BULLETS from the
          ServoLib.h include file provided as GFE.

WMS-DR-05 The WMS shall observe the constants class IOEmConstants from the IOEmulator
          package detailed in Section 5.

WMS-DR-06 The WMS shall observe the constants class SimCraftConstants from the
          MovingObjects package detailed in Section 5.




                                               13
3.4.5   Timing Requirements

WMS-TR-01     The RCU shall implement a radar scan rate of 4 times per second.

WMS-TR-02     In order to hit a moving target with a missile or bullet burst, the turret must
              accurately track the target within the tolerances described below.


3.4.6   Fault Tolerance Requirements

WMS-FTR-01 The WMS shall be fully fail-safe, meaning that any subsystem failure shall render
           the entire WMS inoperable.

WMS-FTR-02 The WMS shall ensure that it is always under the direct control of the BCS, thus
           necessitating a watchdog timer implementation.



3.4.7   User Interface Requirements

              Not applicable.

3.4.8   Miscellaneous Requirements

WMS-MR-01 The RCU shall employ unwired ports and application registration in its
          communication with the IOEmulator. The IOEmulator radar service is registered
          under the name “Radar_service”.

WMS-MR-02 The TCU shall employ unwired ports and application registration in its
          communication with the IOEmulator. The IOEmulator turret service is registered
          under the name “Turret_service”.

WMS-MR-03 The WCU shall employ unwired ports and application registration in its
          communication with the IOEmulator. The IOEmulator weapons firing service is
          registered under the name “Fire_service”.

WMS-MR-04 The TCU shall interchangeably interface with the turret emulator or the turret
          servo motors driver software through setting of the USE_TURRET_EMULATOR
          define in the ServoLib.h include file provided as GFE.




                                                14
3.4.9    Notes

Note 1. Target acquisition shall be based upon a prioritization strategy that ranks targets by
emitter priority, then high to medium PRF and finally whether or not they are inside gun range.
The following table illustrates such an acquisition strategy.

             Target Priority      Emitter Priority         PRF             Gun Range
                   1                  Lethal               High              Inside
                   2                  Lethal               High             Outside
                   3                  Lethal              Medium             Inside
                   4                  Lethal              Medium            Outside
                   5                  Hostile              High              Inside
                   6                  Hostile              High             Outside
                   7                  Hostile             Medium             Inside
                   8                  Hostile             Medium            Outside


Note 2. The accuracy required of a bullet burst or missile fired at a target is as follows:

                       a. 3o azimuth and 3o elevation for a hit, which afflicts minor damage,
                       b. 2o azimuth and 2o elevation for a hit, which afflicts medium damage,
                          and
                       c. 1o azimuth and 1o elevation for a hit, which afflicts major damage.


               The software drivers for the turret servo motors are provided as GFE.

               For more information regarding any data or protocol definitions, see the
               IOEmulator specification in Section 5 or in the model documentation.




                                                 15
DEMONSTRATION REQUIREMENTS

4.1      Mission Scenario

         You are the crew of the HMCS Funky. It is 0430 hours on 29 Mar 04. You are anchored
         off the coast of Nova Scotia at 44o N 62o W. You receive a secure radio communication
         from headquarters in Halifax to proceed due east at 7 knots (use miles per hour) towards
         Sable Island. You are accompanied by a sister ship, the HMCS Digby, and an escort
         fighter aircraft. You are advised to expect possible fishing trawlers in the general area.
         Your rules of engagement with any contacts are as follows: employment of ESM and
         radar sensors is permissible, but under no circumstances do you have the authorization to
         jam or track any contacts. Weapons are to be safely secured from firing.

         At 0431 hrs you receive another secure communication from headquarters. There have
         been reports of a possible attack from the Cape Breton Air Force; F-18s have been
         launched from their deployment station on Sable Island. You are to proceed as soon as
         possible to a rendezvous point at 44o 0’ 22’’ N, 61o 59’ 25” W where you will await
         further instructions. Due to the potential for hostilities in the area your rules of
         engagement are now as follows: any threat above a friendly may be jammed. Any threat
         above an unknown may be tracked. Any hostile threat with a medium or high PRF shall
         be fired upon.

Dem-01          You are to demonstrate the compliance of your NCSS software by fulfilling this
                mission. The sequences of necessary commands from the BCS may be coded into
                a state machine model as per paragraph 3.1.7 above.

Dem-02          By 0435, or exactly 5 minutes into the simulated mission, your systems shall be
                fully shut down (with all timers cancelled).

Dem-03          The subsystem’s status, failed or operational, and the final location of your ship
                shall be the last data displayed prior to shut down.

Dem-04          The success of your mission will be judged based upon your final ship data above
                and the simulation summary reported by the IOEmulator. Factors to be considered
                will be your proximity to the rendezvous point, the status of your systems, the
                results of your jamming and the success and efficiency of weapons deployment.
                Of course you must have obeyed your rules of engagement.




                                                 16
5.0    IOEMULTOR SPECIFICATION

5.1    RoseRT Report Link

5.1.1 The hyperlink below is a RoseRT generated Web-based report that includes a complete
      specification for all passive classes, constants and protocols employed within the
      IOEmulator. For more specific details on the implementation of the IOEmulator, refer to
      the shared model packages provided as GFE.

5.1.2 The IOEmulator protocol and data specification is located at:
      http://tarpit/smithr/EE585_CISC846/NCSS_Project/IOEmulator_Docs/frames.html




                                              17

								
To top