:orphan: .. **************************************************************************** .. CUI .. .. The Advanced Framework for Simulation, Integration, and Modeling (AFSIM) .. .. The use, dissemination or disclosure of data in this file is subject to .. limitation or restriction. See accompanying README and LICENSE for details. .. **************************************************************************** xio_interface ------------- .. contents:: :local: :depth: 4 .. command:: xio_interface ... end_xio_interface :block: .. parsed-literal:: xio_interface broadcast_ ... [ port_ ... | send_port_ ... receive_port_ ... ] multicast_ ... [ port_ ... | send_port_ ... receive_port_ ... ] unicast_ ... [ port_ ... | send_port_ ... receive_port_ ... ] mover_update_timer_ ... entity_position_threshold_ ... entity_orientation_threshold_ ... connect_to_simulations_ application_ ... debug_ ... auto_dis_mapping_ ... auto_map_application_ ... no_auto_map_application_ ... falling_behind_threshold_ ... send_aux_data_updates_ ... end_xio_interface Overview ======== The eXternal IO Interface (XIO) is a protocol primarily for use between WSF applications. In most cases, using XIO requires writing source code and compiling with the WSF library. However some features available without writing code are noted below and in the :class:`WsfXIO` script documentation. The xio_interface command configures the basic parameters. .. _xio_interface.Commands: Commands ======== .. command:: broadcast Specifies a broadcast IP address and port that will be used to communicate with other WSF applications. .. note:: A port specification is required directly after the broadcast command. Example:: broadcast 123.42.21.255 port 54321 .. command:: multicast Specifies a multicast IP address, interface, and port that will be used to communicate with other WSF applications. .. note:: A port specification is required directly after the multicast command. Example:: multicast 224.92.2.2 192.168.10 port 32991 .. command:: unicast Specifies an address to communicate with other WSF applications. A port specification is required directly after the unicast command. Example:: unicast www.google.com send_port 80 receive_port 88 .. command:: port Specifies the port used for a connection command. Must be used directly after multicast, broadcast, or unicast command. .. command:: send_port .. command:: receive_port Specifies the send and receive ports used for a connection command. Must be used directly after multicast, broadcast, or unicast command. This is an alternative to the port command, and allows different ports for sending and receiving. .. command:: mover_update_timer If greater than 0, the interface will generate events to force platforms to update their position at the specified interval. This is useful for event-driven simulations where position updates may occur infrequently due to the lack of interaction between objects. **Default:** 1.0 seconds .. command:: entity_position_threshold Specify the entity position threshold used for some interfaces. **Default:** 1.0 meters .. command:: entity_orientation_threshold Specify the entity orientation threshold used for some interfaces. **Default:** 3.0 degrees .. command:: connect_to_simulations Specifies that the WSF application should try to connect to other WSF simulations. By default, most simulation applications, like SAGE, will not connect to each other. This command is not required when connecting only to WSF display applications such as **trackview**. .. command:: application Specifies the application's name as text. The application name communicated between applications primarily for user identification. This value is optional. .. command:: debug Enables or suppresses XIO status information printed to the screen. **Default:** off .. command:: auto_dis_mapping Enables or disables automatic mapping of DIS entities. Currently this option will only work for pure WSF exercises, and does **not** support DIS exercises with non-WSF applications. In this mode, platform types of DIS objects are communicated over XIO. The entity_type command is not required in this case. DIS platforms for Remote DIS bodies are created in the following way: * If a platform is defined in the input file with the same name as the remote platform, this platform definition is used. Note, this input platform must be disabled using :command:`platform_availability`. * If a platform_type is defined in the input file with the same type as the remote platform, this type is used. After the platform is created, it is modified in the following way: * It receives the same name as the remote platform. Ex: platform *iads-cmdr* owned by Application-1 is named *iads-cmdr* when it is created from DIS in Application-2. * Command chains are created on the new DIS platform to maintain reporting roles as defined in the remote application. * Platform parts (i.e. subsystems) such as sensors, processors and comms are removed, as is normally done with external platforms. * Comm devices are created to mimic the remote platform's comm devices. These devices are configured to communicate messages between the two applications. *Note: This method does not currently map emitters, use the :command:`dis_interface.emitter_type` instead.* **Default:** off .. command:: auto_map_application : .. command:: no_auto_map_application : * : Site number to which this command applies. Must either be an integer in the range 1-65534, or an asterisk (*). * : Application number to which this command applies. Must either be an integer in the range 1-65534, or an asterisk (*). **auto_map_application** enables auto-DIS mapping for the specified application. **no_auto_map_application** disables auto-DIS mapping for the specified application. Applications specified with no_auto_map_application has precedence over ones specified with auto_map_application. Both commands override the auto_dis_mapping command. Example::: auto_dis_mapping no auto_map_application 99:* no_auto_map_application 99:5 * Maps application 99:5 with regular DIS mapping. * Maps any other application with 99 as a site ID with auto_dis_mapping * Maps any other application regular DIS mapping .. command:: maximum_modelled_sensors Specifies the maximum number of external sensor modelling request the application is able to handle simultaneously. **Default:** infinite .. command:: debug_modelled_sensors Specifies that external sensors modeled locally will be put in debug mode. **Default:** false .. command:: falling_behind_threshold Specifies how far a simulation must fall behind real time before notifying connected simulations. **Default:** 0.5 seconds .. command:: send_aux_data_updates Enables or suppresses :command:`_.aux_data` updates for local platforms. **Default:** true Distributed Scenarios ===================== Using DIS it is possible to run some scenarios across multiple machines. However, the scenario must be able to be split into pieces that do not require intercommunication. Sometimes scenarios cannot be easily split in this way. Using XIO it is possible to run scenarios across multiple machines, even if the scenario requires communication between each part. Generally, these are the requirements: * Split the scenario up into a number of sections. * Set up an WSF application to run each section. Each application needs an input file defining the types used and available platforms. * Set up the :command:`dis_interface` connection parameters. * Set up :command:`xio_interface` connection parameters. The following is a demonstration of splitting a simulation into 2 parts. XIO automatically forwards track messages over the network between the two simulations. **dist_test.txt**:: xio_interface broadcast 192.168.10.255 port 39583 debug yes connect_to_simulations auto_dis_mapping yes end_xio_interface platform_type my_type WSF_PLATFORM side red icon f-18 mover WSF_AIR_MOVER end_mover comm com1 WSF_COMM_TRANSCEIVER on processor dumper processor link-proc end_comm sensor sensor-1 WSF_GEOMETRIC_SENSOR off maximum_range 100 nm frame_time 2.0 s reports_location processor link-proc end_sensor processor link-proc WSF_LINKED_PROCESSOR on external_link commander via com1 end_processor processor dumper WSF_SCRIPT_PROCESSOR off on_message default script # Writes all received message to output writeln("T=", TIME_NOW, " ", PLATFORM.Name(), " Received ", MESSAGE.Type(), " from ", MESSAGE.Originator()); end_script end_on_message end_processor end_platform_type platform air-1 my_type route position 0.0n 0.0e altitude 20000 ft heading 90 deg extrapolate end_route edit processor dumper on end_processor end_platform platform air-2 my_type route position 0.001n 0.0e altitude 20000 ft heading 90 deg extrapolate end_route commander air-1 end_platform platform air-3 my_type route position 0.001s 0.0e altitude 20000 ft heading 90 deg extrapolate end_route edit sensor sensor-1 on end_sensor commander air-2 end_platform realtime end_time 10 min **scenario_part_1.txt**:: include_once dist_test.txt dis_interface broadcast 192.168.10.255 port 27322 application 11 site 22 autostart end_dis_interface # air-2 and air-3 are modelled externally platform_availability default availability 1.0 name air-2 availability 0.0 name air-3 availability 0.0 end_platform_availability **scenario_part_2.txt**:: include_once dist_test.txt dis_interface broadcast 192.168.10.255 port 27322 application 12 site 22 autostart end_dis_interface # air-2 and air-3 are modelled internally platform_availability default availability 0.0 name air-2 availability 1.0 name air-3 availability 1.0 end_platform_availability event_output ============ .. comment I didn't want to add this stuff to the event_output page yet, it's still in development There are a few extra events available when using XIO. These may be used in addition to the events in :command:`event_output`. * XIO_CONNECT * XIO_DISCONNECT * XIO_SENSOR_HANDOFF * XIO_SENSOR_HANDOFF_RECEIVE