 base components, manage hardware and interact with external services framework control, and services. Figure 2.4a-4 is a dia- through a set of consistent interfaces and structures. gram of the different classes and their corresponding There are some clear limits to what the SCA provides. parts. For example, the SCA does not provide such real-time The SCA follows a component-based design, SO the support as maximum latency guarantees or process and whole infrastructure revolves around the goal of creating, thread management. Furthermore, the SCA also does installing, managing, and de-installing the components not specify how particular components must be imple- making up a particular waveform. mented, what hardware should support what type of functionality, or any other deployment strategy that the Base components user or developer may follow. The SCA provides a basic The base class of any SCA-compatible component is the set of rules for the management of software on a system, Resource class. The Resource class is used as the parent leaving many of the design decisions up to the developer. class for any one component. Since components are de- Such an approach provides a greater likelihood that the scribed in terms of interfaces and functionality, not the developer will be able to address the system's inherent individual makeup of the component, it follows that any needs. one component comprises one or more classes that in- The SCA is based on some underlying technology to herit from the Resource. For example, the developer may be able to fulfill two basic goals, namely, code portability create a general Filter category for components. In this and reuse. In order to maintain a consistent interface, the example, the filter may be implemented as an FIR or IIR SCA uses Common Object Request Broker Architecture filter. These filters can then be further partitioned into (CORBA) as part of its middleware. CORBA is software specific Filter implementations up to the developer's that allows a developer to perform remote pro