Radar Object Hierarchy

Description

This defines the core C++ class inheritance structure for simulation entities involved in radar operations.

• A base Object class provides fundamental properties like an associated Platform (for position/motion) and a Name.
• The Radar class inherits from Object and adds common radar-related attributes: an Antenna pointer, a Timing source pointer, an _attached pointer (primarily for linking Transmitter and Receiver in monostatic configurations), and multipath-related flags/pointers (_dual, _multipath_factor).
• Specific Transmitter and Receiver classes inherit from Radar, adding properties and methods unique to transmitting or receiving operations (e.g., PRF settings, signal references, windowing parameters, noise temperature).

Assumptions

• Assumes the Platform* provided during Object construction is valid and its lifetime exceeds that of the Object instance.
• Assumes the Antenna* and Timing* pointers assigned via setter methods (setAntenna, setTiming) are valid and their referenced objects remain valid for the Radar object's lifetime.
• Assumes the multipath dual creation logic (e.g., createMultipathDualBase) correctly clones or assigns necessary properties when creating _dual objects.
• Assumes the setAttached method is primarily intended for and used correctly with Monostatic radar pairs, linking one Radar object (e.g., Tx) to another (e.g., Rx).

Limitations

• Raw Pointer Ownership (_attached, _dual): The _attached member in Radar and the _dual pointers in Transmitter/Receiver are raw pointers. This creates potential ownership ambiguity – it's unclear if the object holding the pointer owns the pointed-to object or is merely observing it. This complicates lifetime management.
• Raw Pointer Dependencies (_antenna, _timing, _signal): Key dependencies like _antenna, _timing (in Radar) and potentially _signal (in Transmitter, depending on implementation details not fully shown) are stored as raw pointers. This requires careful external management to ensure the pointed-to objects (Antenna, Timing, Signal) outlive the Radar/Transmitter objects using them, otherwise dangling pointers can occur.
• Noise Temperature Inheritance: The Radar::getNoiseTemperature method is virtual. The base implementation delegates to the associated _antenna->getNoiseTemperature(). The Receiver::getNoiseTemperature override adds its own _noise_temperature value to the antenna's contribution. While functional, this specific inheritance pattern for combining noise sources should be noted.

Related Components

• Classes: Object, Radar, Transmitter, Receiver, Platform, Antenna, Timing
• Headers: object.h, radar_obj.h, transmitter.h, receiver.h, platform.h
• Logic: Multipath Dual Object Creation

Validation Status

• Needs Verification:
  • Robustness against potential dangling pointers due to lifetime mismatches of dependencies (Platform, Antenna, Timing, Signal, _attached, _dual).
  • Correctness of property cloning/sharing during multipath dual object creation.
  • Correct behavior of getNoiseTemperature in Receiver vs. base Radar.
  • Proper handling and intended usage of the _attached pointer, especially in non-monostatic or complex scenarios.
• Key Areas for Validation:
  • Test scenarios involving object destruction order (e.g., destroying an Antenna before the Radar using it).
  • Test scenarios involving multipath to ensure dual objects have correctly mirrored/assigned properties (Antenna, Timing, etc.).
  • Tests explicitly checking the noise temperature calculation via getNoiseTemperature for Receivers with and without inherent noise temp values.
  • Tests involving monostatic setups to confirm setAttached linkage works as expected.
• Priority: Medium (Core structure exists, but pointer safety and complex interactions warrant validation)