XML Monostatic Loading

Description

This parsing mechanism handles the <monostatic> element within the FERS XML configuration file. It provides a convenience method for defining a monostatic radar system where the transmitter and receiver share the same platform and potentially other components like the antenna and timing source.

Internally, this function reuses the parsing logic from XML Transmitter Loading and XML Receiver Loading, applying both to the same <monostatic> XML element. This process creates both a Transmitter object and a Receiver object based on the attributes and child elements found within that single tag. Once created, these two objects are linked together internally using the setAttached method.

Assumptions

• Assumes the <monostatic> XML element contains all necessary attributes and child elements required by both the parseTransmitter and parseReceiver functions (e.g., name, type, pulse, prf, antenna, timing, window properties, flags, etc.).
• Assumes it is the user's intention that the same attributes (like name, antenna, timing) are used for both the created Transmitter and Receiver objects derived from the single tag.
• Assumes the Radar::setAttached method functions correctly to link the Tx and Rx pair and includes checks to prevent redundant linking.
• Assumes the Platform* and World* pointers passed into the parsing function are valid and remain valid during parsing.

Limitations

• Inherited Limitations: Inherits all assumptions and limitations associated with the underlying XML Transmitter Loading and XML Receiver Loading processes, as it directly calls their respective parsing functions.
• Reduced Flexibility: The XML configuration structure is less flexible compared to defining separate <transmitter> and <receiver> elements, as a single <monostatic> element must satisfy the requirements of both roles.
• Attribute Ambiguity: There's potential for ambiguity if shared attributes ideally have different values for transmission versus reception. For example, while <prf> is parsed in both contexts, ensuring clarity about which PRF applies where (transmit scheduling vs. receiver windowing) relies on the underlying logic correctly interpreting it based on context or potentially requiring distinct tags if behavior differs significantly. (Note: The implementation does appear to call get_child_real_type for <prf> in both Tx and Rx contexts within parseMonostatic).
• Configuration Risk: Increased risk of configuration errors if the <monostatic> tag omits parameters that are essential for either the transmitter or the receiver functionality, as the parser might not explicitly warn about missing optional elements needed for the other role.

Related Components

• xml_parser.cpp::parseMonostatic (Entry function)
• XML Transmitter Loading (Called function)
• XML Receiver Loading (Called function)
• Transmitter::setAttached / Receiver::setAttached (Linking mechanism)
• Transmitter class
• Receiver class
• Radar Object Hierarchy
• XML Parsing (Category Page)

Validation Status

• Needs Verification: While the core parsing logic is reused from Tx/Rx loading, the specific behavior and constraints when using the combined <monostatic> tag require verification.
• Key Areas for Validation:
  • Confirm that all necessary Tx and Rx parameters can be successfully specified and parsed within a single <monostatic> tag.
  • Verify behavior when optional parameters (relevant to only Tx or only Rx) are omitted from the <monostatic> tag – does it default correctly or cause issues?
  • Test scenarios using shared attributes (like antenna, timing) to ensure they are applied correctly to both created Tx and Rx objects.
  • Validate that the setAttached linkage is correctly established between the generated Tx and Rx.
  • Check error handling if a required parameter for either Tx or Rx functionality is missing from the <monostatic> tag.
• Priority: Medium (Crucial for users wanting to define monostatic systems concisely, but relies on already validated Tx/Rx parsing logic).