The Software Communication Architecture (SCA) is an open-architecture specification that defines the interactions between software applications and radio hardware platforms. The SCA framework has guided the development and evolution of the software defined radio domain, and its concepts have been used within multiple industries, products and countries beyond the Defense Department community.
A primary goal of military software defined radios is to minimize the level of effort required in migrating software applications to different radio platforms, in other words: to maximize application portability. The SCA establishes the infrastructure to achieve this objective. An SCA-based software defined radio enables enhanced software portability and provides a standardized infrastructure for software deployment and configuration — while ensuring interoperability between SCA products. SCA components may be extended by the Joint Tactical Radio System application program interfaces (APIs) to provide platform specific capabilities. As depicted in Figure 1, the SCA and JTRS APIs promote waveform portability and reuse by isolating the waveform application from the radio set.
How SCA4 was Developed
It's been more than 10 years since the first iteration of SCA and more than five years since the release of the previous version of the specification, SCA 2.2.2. While there have been numerous technological advancements and lessons learned in the field of software defined radio since the release of SCA 2.2.2, the framework remained relatively static and was extended to include a small subset of the candidate new features.
The latest specification release, commonly known as SCA4, incorporates a wider range of resolutions, significantly optimizes the framework and improves a programmer’s ability to develop software defined radios efficiently. The modular nature of SCA4 builds in flexibility for the evolution of SCA-compliant products and the standard itself as technology and requirements change.
In addition, SCA 4 is no longer a one-size-fits-all approach so product developers will be able to "right size" their SCA-based infrastructure so that more energy can be focused on providing mission specific solutions. The new standard builds on a decade of expertise and makes the SCA even more relevant in today’s market of resource constrained systems with the ever increasing need for secure mobile communications. With the breadth of potential SCA based target platforms and applications, SCA4 broadens its applicability beyond U.S. military software defined radios.
SCA4 Benefits, Advantages and Expectations
This newest framework, SCA4, emphasizes flexibility and scalability throughout the specification. From a system developer perspective, the flexibility can be used to innovate and provide solutions which are appropriately tailored to a particular product. For the radio user, the flexibility permits customization and extension of the features and capabilities of the original product.
Notable new SCA4 core features include lightweight components, profiles, static ports, push model registration, intra-application connectivity and Common Object Request Broker Architecture (CORBA) neutrality as depicted in Figure 2.
The SCA4 lightweight components can lower the cost of software defined radios with the new optional inheritance technology, which reduces software development and maintenance. Previously, the developer was required to implement all of the inherited interfaces even though all of the inherited interfaces may not have been necessary. For example, an SCA 2.2.2 Resource Interface inherits the TestableObject Interface and needs to implement the runTest operation regardless of whether or not the component provides a test capability.
SCA4 allows the developer to only include the interfaces necessary for the implementation, eliminating unused or underutilized code. With SCA4, the developer would not include TestableObject within the interface inheritance hierarchy and not be required to implement a runTest operation. An optional inheritance's benefit is the reduction in the number of appli-cable requirements; however, one should not lose sight of the fact that the savings associated with this feature are distributed across the entire software development life cycle.
Users that demand minimal boot-up times will benefit from the introduction of the "push" model design pattern in SCA4. The SCA was originally developed with a client-side "pull" design pattern which required components to register with the frame-work upon entry to the domain and then the framework would query the component for information needed to complete the deployment process. Within the SCA4’s push model approach, when a component registers with the framework it is able to provide all of its information upfront. The change in the interaction model can achieve reductions in boot-up time, perhaps a 50 percent decrease.
The push model can be optimized even more in SCA4 by extending it with the new static ports feature. Static ports allow for an implementation specific approach to connection establishment. Connections can be formed in an efficient manner at run time or at build time which will result in more savings that will become even more apparent for systems with applications that require hundreds of port connections.
Security aware customers will be pleased with the information assurance enhancements in SCA4. The original pull model approach allowed access points to vulnerable system data. SCA4's push model pattern eliminates the possibility of clients requesting information they should not have and removes susceptible access points. Security-minded developers of earlier versions of the SCA no longer have to manage these challenges in SCA4, it's simply built-in, and enables a cyber-hardened SCA4, software defined radio without increasing cost and battery consumption.
Suppose you want your software defined radio application to connect to another application running on the radio. SCA4 introduces intra-application connectivity to connect multiple applications for sharing and exchanging information. This permits the inclusion of tactical mobile apps, such as those found in the U.S. Army's Marketplace, an Android-based app store, to be deployed on military software defined radios and interconnected with military applications. The SCA4's new connectivity options are ideal for handling communication to these external apps seamlessly via the Android presentation layer.
The most anticipated stance in SCA4 was leniency on requiring specific middleware technologies, namely CORBA. The SCA no longer mandates the usage of CORBA as the sole middleware option. CORBA is still a viable alternative for SCA platforms and applications, but the SCA4 provides mechanisms to extend the specification with additional transfer mechanisms.
SCA4 transcends the boundaries of software developers and architects with mass appeal through a model driven architecture approach. A specific industry could tailor its own platform specific model from SCA4 by detailing which options and features are right for its system. SCA4 takes the next step in stream-lining the development and maintenance of software defined radios all while promoting flexibility and security as ingrained features. This newest standard, officially versioned as SCA 4.0, was approved by the JTRS Interface Control Working Group and the Wireless Innovation Forum Feb. 28, 2012.