Software Communications Architecture
From Wikipedia, the free encyclopedia
The Software Communications Architecture (SCA) is an open architecture framework that tells designers how elements of hardware and software are to operate in harmony within a software defined radio. SCA is a key element in the U.S. military's Joint Tactical Radio System (JTRS). It governs the structure and operation of the JTRS, enabling programmable radios to load waveforms, run applications, and be networked into an integrated system. A Core Framework, providing a standard operating environment, must be implemented on every hardware set. Interoperability among radio sets is enhanced because the same waveform software can be easily ported to all radio sets.
The Object Management Group (OMG), a not-for-profit consortium that produces and maintains computer industry specifications for interoperable enterprise applications, has established a Domain Special Interest Group for software radios (SWRADIO DSIG). This group, along with the Software Defined Radio Forum (SDRF), is working toward building an international commercial standard based on the SCA.
The SCA is currently extending its coverage to programmable hardware FPGA and digital signal processors DSP.
Contents |
[edit] Overview
A software-defined radio includes a transmitter in which one can alter the operating parameters of the transmitter by changing only the software without making any hardware changes. The operating parameters include the frequency range, modulation type, and maximum radiated or conducted output power.
The Software Communication Architecture (SCA) is a complex specification with several different interfaces. The diagram below shows the primary SCA interfaces. An interface is an important concept. The interface is the only exposure of a software component to the outside world. Components in the system can only execute the operations defined in the interface definition.
[edit] Member variables
Member variables are not exposed to the outside world. To explain this, consider the device interface shown in the diagram. It provides an interface with both attributes and operations. (The attributes are the first compartment and operations listed in the second compartment.) It is easy to make the erroneous association of CORBA attributes to C++ member variables and CORBA operations to C++ operations. In CORBA, both attributes and operations are operations. Attributes have implicit set and query operations. Again using the device interface in the diagram as an example, the label attribute has implicit operation signatures:
- label(in listString:string):void
- label(void):string
The software component is responsible for providing the internal storage variable for the label string. It is not directly available to the outside world. The CORBA interface provides the implicit operations for changing the variable.
In contrast, the allocateCapacity() operation of the device interface has a defined function signature instead of the implicit signatures of attributes. Since operations have improved exception handling capability, many programmers use only operations in an interface definition. However, the SCA uses both attributes and operations in some interfaces.
[edit] Resource interface
An important interface for SCA components is the resource interface. As shown in the diagram, it inherits interfaces from four other interfaces:
- TestableObject
- PortSupplier
- LifeCycle
- PropertySet
The resource interface is inherited by both applications and hardware devices. Because of its importance, the example in this section will define a software component that inherits the resource interface. It could inherit other interfaces, but this would add complexity without providing further insight into the development of SCA components.
[edit] Component Placement
- The CORBA middleware allows software components to be distributed anywhere within the radio.
- The Core Framework provides distributed object launchers for each processor board within the set.
- The radio’s application factory launches a waveform or application by providing the object files and execution parameters to the various processors within the radio.
The following diagram shows the configuration after these components are launched. 
After the objects are instantiated, they may be co-located, or distributed among the different processing elements within the radio. These objects do not have any knowledge of other application objects or the hardware resources within the radio.
A set of XML files is associated with each software and hardware object. These files provide information about the objects, including their port references. The application factory parses these files along with an application schematic file, the Software Assembly Descriptor (SAD). The SAD provides the necessary information to connect the hardware and software components together.
[edit] Dynamic Software Configuration
The following diagram shows two software components of a waveform within a JTRS radio. As depicted, the two software components have port objects which are dynamically connected by the Core Framework’s application factory. After connection, the CORBA middleware allows the two objects to pass data or send control information. Because CORBA provides distributed processing the two software components in the diagram can actually reside in different processors within the radio.
The software components shown in the diagram function as adapters An intermediary that translates between incompatible component interfaces, allowing them to communicate. (drivers) for the hardware components. By providing CORBA adapters for the hardware components, every hardware item and software component can communicate and be controlled via CORBA within the JTRS radio.
[edit] Hardware Configuration
The SCA System Communications Architecture does not specify a particular hardware configuration. However, one of the requirements for SCA certification is that the waveform must be ported successfully to a government test platform. These test platforms have a configuration similar to that shown in the following diagram. As would be expected, most waveform software is being designed for such a configuration.
The DAC and A/D in this diagram connect directly to the RF hardware. Most previous military radios had a specialized downconverter and modulator integrated circuits. With the non-standard JTRS configuration shown here, the waveform developers must provide FPGA code that can perform the function of operating directly with the A/Ds and D/As. The hardware does not provide direct digital synthesizers and upsamplers typical in previous radios. The waveform designer must provide that functionality in specialized FPGA code that constitutes part of the delivered waveform.
