One of the most powerful features of REDHAWK is the deployment of its Waveforms (also known as Applications). In this article we’ll look at the impact of each of these elements through some brief descriptions and the interactive image at the bottom.
Components can have several implementations each potentially having its own set of dependencies and making use of either C++, Java, or Python. These dependencies must be met by special classes of Devices: Executable or Loadable. For example, the dependency could require a CPU architecture (ARM, x86, etc.), a resource allocation of memory, or the ability to load or save files. These dependencies result in
allocation calls on the Device in question which then responds with whether or not it could meet the dependencies.
Each Waveform is described as a collection of Components. Similar to Components, Waveforms can also have dependencies (called a
usesdevice relationship) for automating the connection of ports to external entities (most commonly, Devices). And similar to Component dependencies, launching the Waveform will result in
allocation calls on the Devices until a suitable candidate is found.
Another type of dependency specified in a Waveform is
collocation. This feature groups the dependencies of several Components so that all are deployed to the same Device. Indirectly then, this type of dependency also results in
allocation calls on the Devices.
In a nutshell, REDHAWK deployment process consists of launching a unique instance of a Waveform if resources exist in the REDHAWK Domain to support all of the dependencies of the Waveform, its Components, and any specified collocations. The process is a round robin among all resources in the system until each dependency, or group of dependencies, can be met.
The interactive elements are each Component, the receiver Device in Node A, and the different deployment options (bottom left). Each Component has its own specific dependencies and implementations.
The two connections created by the
usesdevice relationship are an example of a Frontend Interface for a Digital Tuner (DT). A single relationship would be described in the Waveform, but both ports would use it for pre-configuring a suitable digital tuner Device and then establishing the data and control connections (data* and *_DT, respectively).