WSF_TASK_PROCESSOR¶
Derives From: WSF_SCRIPT_PROCESSOR Script Classes: WsfTaskProcessor
- processor WSF_TASK_PROCESSOR¶
processor <name> WSF_TASK_PROCESSOR WSF_SCRIPT_PROCESSOR Commands ... # Track State Controller Commands evaluate_candidate_tracks ... evaluation_interval ... number_of_servers ... show_state_evaluations show_state_transitions state <state-name> ... state definition ... on_entry ...end_on_entry on_exit ...end_on_exit next_state...end_next_state end_state time_to_evaluate ... # Task Processor Commands track_processor ... comm_retry_attempts ... comm_retry_interval ... operating_level ... time_to_recognize_messages ... track_update_interval ... track_update_strategy ... weapon_uplink_path ... uplink_source ... uplink_comm ... uplink_delay ... auto_weapon_uplink ... auto_weapon_uplink_platform ... uplink_send_interval ... show_task_messages show_uncompleted_tasks # Script Interface on_initialize ... end_on_initialize on_initialize2 ... end_on_initialize2 on_update ... end_on_update script_variables ... end_script_variables script ... end_script .. Other Script Commands ... script void on_task_assign(WsfTask aTask, WsfTrack aTrack) ... script commands ... end_script script void on_task_cancel(WsfTask aTask) ... script commands ... end_script script void on_task_complete(WsfTask aTask) ... script commands ... end_script script void on_task_assign_sent(WsfTask aTask, WsfTrack aTrack) ... script commands ... end_script script void on_task_cancel_sent(WsfTask aTask) ... script commands ... end_script script void on_task_complete_sent(WsfTask aTask) ... script commands ... end_script script void on_operating_level_change(string aLevel) ... script commands ... end_script script void on_track_drop() ... script commands ... end_script end_processor
Overview¶
WSF_TASK_PROCESSOR (WSF_TRACK_STATE_CONTROLLER) is an extension of WSF_TRACK_STATE_CONTROLLER that provides a common mechanism for sending and receiving ‘task assignments’ that are associated with tracks. This utilizes the facilities of WSF_TRACK_STATE_CONTROLLER to categorize tracks. WSF_TASK_PROCESSOR provides additional script commands (e.g., AssignTask, CancelTask as defined in WsfTaskManager) that allow tasks to be sent and received.
Track State Controller Commands¶
- evaluate_candidate_tracks <boolean>¶
Indicates if ‘candidate tracks’ are to be evaluated. A candidate track is one that has been received but has not yet been determined to be ‘stable’ as defined by the filter.
Default: false
- evaluation_interval <state-name> <random-time-reference>¶
Specifies how often a track in the indicated state should be (re)evaluated.
- number_of_servers <integer>¶
Indicates the maximum number of track evaluations that can occur simultaneously. The time to perform the evaluation is set using the time_to_evaluate command.
Default: 1
- show_state_evaluations¶
Indicates that information about state evaluations should be written to standard output. This essentially shows the true or false status of the evaluation of each next_state block.
- show_state_transitions¶
Indicates that information about state transitions should be written to standard output.
- state <state-name>¶
Defines a state in a state machine with the name <state-name>.
- on_entry … end_on_entry¶
When entering this state, performs these script commands. This is an optional subcommand.
- on_exit … end_on_exit¶
When leaving this state, performs these script commands. This is an optional subcommand.
- next_state *<next-state-name>* …end_next_state¶
This optional subcommand is a script block that must return a true/false value. When evaluated, the return value determines whether to transition to the named state defined by the <next-state-name>. If next_state is not defined, it will “dead end” in this state.
Multiple next_state subcommands are allowed but will be evaluated only if all preceding transition evaluations are false (the first “true” short-circuits further evaluations). Because of this, it is recommended to perform the simplest next_state evaluations before more computationally intensive evaluations are done to save CPU cycles.
The state command definition structure:
state <state-name> on_entry ... <script-commands> ... end_on_entry on_exit ... <script-commands> ... end_on_exit next_state <next-state-name-1> ... <script-commands> ... end_next_state next_state <next-state-name-2> ... <script-commands> ... end_next_state end_state
- time_to_evaluate <state-name> <random-time-reference>¶
Specifies how long it takes to perform an evaluation of track in the indicated state. This simulates how long it takes to “think’ or perform an evaluation in a logical sense.
Default: 0.01 sec
Task Processor Commands¶
- track_processor <track-proc-name>¶
Specifies the name of a WSF_TRACK_PROCESSOR (typically operating as a non_master_track_processor) whose track list will provide the tracks used in the evaluation process.
Default: Uses the platforms master track list.
- comm_retry_interval <time-value>¶
Indicates the amount of time between attempts to retry failed communications.
- operating_level <name> <level>¶
Indicates the operating condition or state and the associated level.
Example:
operating_level Engage 0
- time_to_recognize_messages <time-value>¶
Indicates the amount of time it takes to recognize a message.
- track_update_interval <time-value>¶
Indicates the time interval for sending track updates to assignees.
- track_update_strategy [ default | suppressor ]¶
Indicates how track updates are sent. With default behavior, if a task has been accepted then periodic track updates are sent to the assignee. With the Suppressor behavior, track updates are sent to assignees only when the track manager indicates a track has been updated.
- weapon_uplink_path <sensor-name> <comm-name>¶
Indicates the sensor and communication device to use when supporting a weapon uplink. If a tracking task is assigned to the sensor and a weapon is fired, the weapon is supported with an uplinked track.
Note
weapon_uplink_path provides a method of uplinking which is unrelated to any other uplink commands. Mixing uplinking methods can result in creation of multiple uplinks.
- uplink_source <sensor-name>¶
Indicates the source of the track when uplinking. If this command is not used, the uplink will be sent any time the track is updated in the track manager. If this command is used, only sensor tracks originating from the uplink source will be used. The sensor must report tracks to the track manager.
Default: track-manager
- uplink_comm <comm-name>¶
Indicates the comm system used to transmit an uplink. If this command is not used, the first compatible comm system will be chosen.
- uplink_delay <time-value>¶
Indicates the delay before an uplink is initiated after an uplink task is received.
Default: 0.0 seconds
- auto_weapon_uplink <boolean-value>¶
Indicates that the task manager will automatically assign an uplink task for each weapon fired when the FireAt() script is called. Other commands that determine the uplink parameters are uplink_source uplink_comm uplink_delay auto_weapon_uplink_platform.
Default: off
- auto_weapon_uplink_platform <platform-name>¶
Indicates the assignee of the uplink task initiated with auto_weapon_uplink. This allows specifying a specific uplink platform.
Default: This platform
- uplink_send_interval <time-value>¶
Minimum interval between sending uplink tracks (for task-based uplinking only)
Default: 0.0 seconds
- show_task_messages¶
Indicates that information related task assignment, cancellation and completion are to be written to standard output.
- show_uncompleted_tasks¶
This is a debugging tool that indicates information about uncompleted tasks is to be written to standard output during the destruction of the task processor.
Script Interface¶
WSF_TASK_PROCESSOR utilizes capabilities of the Common Script Interface and WSF_SCRIPT_PROCESSOR, and provides the following additional scripts:
- on_task_assign¶
script void on_task_assign(WsfTask aTask, WsfTrack aTrack) ... end_script
This is invoked when a task assignment is received.
- on_task_cancel¶
script void on_task_cancel(WsfTask aTask) ... end_script
This is invoked when a task cancel is received.
- on_task_complete¶
script void on_task_complete(WsfTask aTask) ... end_script
This is invoked when the assigner of task receives notification that an assignee has completed the specified task.
- on_task_assign_sent¶
script void on_task_assign_sent(WsfTask aTask, WsfTrack aTrack) ... end_script
This is invoked when a task assignment is sent.
- on_task_cancel_sent¶
script void on_task_cancel_sent(WsfTask aTask) ... end_script
This is invoked when a task cancel is sent.
- on_task_complete_sent¶
script void on_task_complete_sent(WsfTask aTask) ... end_script
This is invoked when the assignee of task sends a task compete message.
- on_operating_level_change¶
script void on_operating_level_change(string aLevel) ... end_script
This is invoked whenever a change in ‘operating level’ in detected. This is mostly used when a commander changes the operating level of a subordinate to reflect a change in ‘alert status’.
- on_track_drop¶
script void on_track_drop() ... end_script
This is invoked whenever a processor is informed of a track drop by the track manager. The implicitly defined script variable TRACK (of type WsfLocalTrack) represents the last known state of the track that is being dropped.
Method of Operation¶
Each track, when it is first discovered is initially put into the first state as defined in the input file after the time_to_evaluate interval has elapsed. From that point on it will continue to evaluate the transition rules for whatever state it is currently in and will transition to new states as the rules allow. When a transition occurs, the on_exit script for the current state will be executed (if it is defined) and the on_entry script for the new state will be executed (if it is defined). The first time the state is entered the time_to_evaluate interval is applied. This serves as a thinking delay on state entry.
Each track is (re)-evaluated at the interval defined by the state in which the track currently exists. The logical time that it takes to perform the evaluation is defined by the time_to_evaluate for that state. The controller can perform up to number_of_servers evaluations at a time. When it comes time to evaluate a state for a given track, it is determined if a server is available to perform the evaluation. If a server is available, it is marked busy for the time_to_evaluate and will perform the actual rule evaluation at the completion of the interval (thus simulating the thinking process) and schedule the next evaluation. If a server is not available then it is put on a pending queue for evaluation by the next server that becomes available.
