The OMG PIM and PSM for software radio (SR) components specification is based upon the concepts found in the SCA (such as a waveform application consisting of resource components, domain manager component, logical device and device manager components), but represent these concepts in a domain-specific language known as the UML profile for software radio. The SCA mandates specific technologies such as common object request broker architecture (CORBA) and extensible markup language (XML) and further describes the use of these technologies to support the definition and development of software-defined radio (SDR) software.

The UML profile for SR, on the other hand, expresses these concepts in strictly architectural terms (not mandating any particular technologies) using only UML. In this manner, the relationships between the software elements making up the SR architecture can be strictly defined and constrained. This level of “software engineering completeness” further allows the ability to transform models built to this UML profile directly into executable software that can be deployed on SRs.

The OMG PIM and PSM for SR components consists of a UML profile for software radio, data link and physical layer facilities, and POSIX profiles, which are explained in the following sections.

The UML profile for SR extends the elements in the UML 2.0 specification (such as artifact, component, device, interface, property) by forming new definitions pertaining to a SR domain specific language. These new definitions extend UML elements via additional attributes, constraints and semantics. The UML profile for SR provides the required language to support modeling waveform applications, platform components, and communication channels independent of specific technology choice and then allows one to transform these elements directly into the implementation technologies required. This allows the design of the radio software to be captured independent of technology (e.g., C, CORBA, Java or XML) and then later mapped to technology as required to meet the developer's needs as illustrated in Figure 1.

For example, waveform application components might initially be implemented in C++ for the Linux operating system running on a Pentium general-purpose processor (GPP). Later, possibly due to technology upgrades, the same wave-form components might be needed in VHDL to support a field-programmable gate array (FPGA) or in C to support a digital signal processor (DSP). Since the specification does not force technology choice, the developer can transform the architectural concepts found in the specification to support the VHDL (FPGA) or C (DSP) implementation. Figure 2 serves to illustrate the concept. In all cases, however, the new technology-dependent implementations must adhere to design set forth by the original designer of the component and is enforced by the UML profile.

Tooling makes this task significantly easier as models of the waveform and radio platform designs can be captured in a technology-independent manner then transformed using generative programming approaches into the source code language of choice.

Tools can further capture the designs in a language called XML metadata inter-change format (XMI). XMI, another standard managed by the OMG, allows the import and export of model information between tools. The XMI is expressed in terms of the UML profile for SR. Using XMI allows modeling tools designed for particular aspects of radio development to exchange the information needed to support seamless integration. Tools implementing the SR profile will likely also have domain specific editors and generators as illustrated in Figure 3. These editors and generators will vary across tools, however, having a single UML profile under-pinning these tools. And import and export capabilities via XMI ensure the users of these tools are not locked to any particular vendor.

The UML profile for SR is designed to be extended for specific domains such as military radio, space/ground-based radios, robotics, commercial handset and base station domains via extension points that allow the incorporation of additional architectural concepts and/or constraints. It comprises two UML profiles: component framework profile and communication channel profile.

1 2 3 Next

RSS    Save to Del.icio.us  Digg This