 systems, and hence limiting its ability to PSE-52 compliant OS, but CORBA need not limit itself support high-bandwidth protocols. to such an OS. Its GPP-centric focus leads to a flow for the SCA, as seen in Figure 2.4a-3. As seen in Figure 2.4a-3, at the center of the SCA 2.4a.4.2 Software communications implementation is an OS, implying but not requiring the architecture use of a GPP. Different pieces of the SCA are linked to this structure through CORBA and the interface defini- The other open architecture is the SCA, sponsored by tion language (IDL) IDL is the language used by CORBA the Joint Program Office (JPO) of the US Department of to describe component interfaces, and is an integral part Defense (DoD) under the Joint Tactical Radio System of CORBA. The different pieces of the system are at- (JTRS) program. The SCA is a relatively complex ar- tached together by using IDL. An aspect of the SCA that chitecture that is designed to provide support for secure is not obvious from Figure 2.4a-3 is that there can be signal processing applications running on heterogenous, more than one processor at the core, since CORBA distributed hardware. Furthermore, several solutions are provides location independence to the implementation. available today that provide support for systems using Beyond this architecture constraint are the actual pieces this architecture, some of which are available openly, that make up the functioning SCA system, namely SCA such as Virginia Tech's OSSIE [8] or Communications and legacy software, non-CORBA processing hardware, Research Center's SCARI [9], providing the developer security, management software, and an integrated file with a broad and growing support base. system. The SCA is a component management architecture; it The SCA is partitioned into four parts: the framework, provides the infrastructure to create, install, manage, and the profiles, the API, and the waveforms. The framework de-install waveforms as well as the ability to control and is further partitioned into three parts,