What is Software Communications Architecture (SCA)?

Software has become the largest component of electronic systems today demanding more development resources than hardware. Software Defined Systems (SDS) provide the flexibility to be reconfigured to adapt to changing environment and requirements. However, as the underlying electronics become more complex with the rapid evolution of processors and heterogeneous nature of embedded systems, developing software has also become a challenge.   

The international community, under the leadership of the US Department of Defense and the Wireless Innovation Forum (WInnF), has developed an open standard for the development of software that promotes software portability between platforms and reusability of software. This open standard allows for greater interoperability and reduced development cost and time-to-market, both of which benefit the equipment manufacturer and end user. The Software Communications Architecture (SCA) standard follows a Component Based Development (CBD) approach and defines a set of implementation rules to abstract the application from the platform hardware.  Software deployment and configuration rules have been standardized as well as several Application Programming Interfaces (APIs) for wireless communications systems.  

Software Defined Radio (SDR) is commonly defined as a “Radio in which some or all of the physical layer functions are software defined”. SDR technology uses software, instead of conventional hardware, to perform radio-signal processing functions. Filters, error correction, synchronizers, modulators/demodulators, and frequency tuners used in conventional systems can all be written in software. Software defined devices can be reconfigured to adapt to changing product requirements. 

Yes, SCA is an open standard, developed by the international radio community to make the development of Software Defined Products more efficient, thus reducing time-to-market and development cost and improving product quality and performance. 

A key element of any software-based system is the overall software architecture that the development teams follow to integrate the software to the hardware platform. In most cases, till today, organizations make use of proprietary software architectures that tightly couple software applications to the hardware platforms. With changes to the platforms (e.g. through hardware evolution), the software often needs to be significantly modified to adapt to the new characteristics of the hardware, adding additional time-to-market the product. This unique and proprietary approach is also prone to obsolescence when the original team members move on to other projects, positions, or companies. 

The Software Communications Architecture (SCA) was originally created by the Modular Software programmable Radio Consortium (MSRC): Raytheon, BAE Systems, Rockwell Collins, and ITT, under contract to the U.S. Department of Defense Joint Tactical Radio System (JTRS) Joint Program Office (JPO).

SCA version 1.0 was first introduced early in the year 2000 and was followed by revisions that culminated in the release of SCA version 2.0 later that same year. 2001 saw the release of version 2.2, a time at which the specification was deemed ‘implementable’. With the knowledge gained by implementations developed during the next two years, the specification was updated to version 2.2.1 in 2004. Version 3.0 was released later that same year, but work on that version was stopped one year later. Focus was returned to improve version 2.2.1, and version 2.2.2 saw the light of day in the year 2006. With more lessons learned through the following years, in 2009 work started towards the new version of the SCA. It was code-named SCA Next, and 4.0 was released in 2012. The scope of improvements from version 2.2.2 to version 4.0 were substantial, and industry feedback identified backwards compatibility issues that needed to be solved. Version 4.1 addressed those issues and was published in August 2015. 

VIAVI has the industry’s largest team of SCA experts that have implemented all major versions of the SCA specification. From version 0.3 back in the early 2000s, to SCA 2.1, 2.2, 2.2.1, 2.2.2 and now the latest version 4.1.

Proven Performance In Deployed Systems

• General Dynamics AN/PRC-154 Rifleman Radios – 19,000 Units Ordered, 190,000 planned
• General Dynamics AN/PRC-155 – 3700 Units ordered
• Harris AN/PRC-117G – 25,000 Units Deployed
• Harris AN/PRC-152 – 160,000 Units Deployed
• Thales AN/PRC148 JTRS Enhanced MBITR – 200,000 Units Deployed

Other SCA Based Radios In Deployment

• Harris Falcon III Radio Family
• Rockwell Collins/Thales FlexNet
• ViaSat/Rockwell Collins MIDS-JTRS
• Raytheon (RT-1987 / ARC231, MAINGATE, NMT, FAB-T)
• Rockwell Collins RT-840
• Rohde & Schwarz SOVERON® Radios 
• Selex ES Swave™ Family (HH, VM-3, MB-1, VB-1, VQ-1)
• Thales (FlexNet, Fastnet, and Nextwave Families)

SCA Based Waveforms – Deployed*

• Easy II
• FlexNet Waveform
• HAVEQUICK II
• HDR-AJ
• Mobile User Objective System (MUOS)
• PR4G-Fastnet
• SATURN
• Soldier Radio Waveform (SRW)
• Soldier Broadband Waveform (SBW)
• VHF/UHF Line of Sight (VULOS)
• Wideband Networking Waveform (WNW)
• Legacy Waveforms (COBRA, SATCOM 181/182/183/184, SINCGARS, EPLRS, JTRS Bowman, Link-16 & HF)

SCA Based Waveforms – In Development*

• Coalition Wideband Networking Waveform (COALWNW)
• ESSOR High Data Rate Waveform (HDRWF)

*These lists are representative, not all-inclusive

With SCA 4.1, implementers can tailor the SCA set of features to better match their radio requirements. As such, three profiles have been defined:

SCA Lightweight Profile

• Best suited for radio platforms where the hardware modules have a static configuration.
• Provides a minimum set of functionalities which is applicable for resource (e.g. SWAP) constrained platforms.

SCA Medium Profile

• Suited for radio platforms with plug-and-play but not removable hardware modules.
• Still rather lightweight but it introduces a configurable, dynamic aspect.
• The most flexible profile providing the lightest weight implementation that supports the legacy SCA deployment model.

SCA Full Profile

• Suited for radio platforms with removable, plug-and-play hardware modules.
• Provides the full breadth of SCA deployment and management capabilities. 
• Aligned to support prime power, multi-channel sets.

Component scalability:

• Allows component developers to choose whether to implement some of the standard sub-component interfaces. The scalability will also be used to support the different profiles of the specification. 

Scalability of the manager components:

• Allows developers to choose whether to implement all the manager interfaces. The manager scalability will also be used to support the different profiles of the specification. 

Minimal ultra-Lightweight (uLw) AEP definition:

• Provides minimal uLw specification with optional grouping to extend capability

• Design patterns and strategies incorporated for security awareness 
• Remove ability for a component to query information that could be inappropriately used
• Harder to get an object reference to the DomainManager and learn about the system
• Naming Service deleted

Faster Boot Times due to Port Connection improvements

• Allows faster connections, reducing waveform startup boot time
• Permits connections to be defined at build time
• Reduces startup and security issues

Total test time reduced based on profile implemented:

• Cost of increase test coverage complexity

Units of functionality and multiple base AEP profiles with optional function groups allow crisper test definitions

Static analysis tools will have more prominence:

• Test all paths in the code
• Find errors much earlier in the development process.
• Provide immediate assistance by linking errors directly to the specification -this is a good way to “teach” the spec as code is being written.

Requirements cleanup:

• Reduced number of requirements
• Removal of some redundant requirements

• Specification of PIM (Platform Independent Model) IDL Profiles
  • Full Profile
  • Ulw Profile
• Rationalization of PSM (Platform Specific Model) IDL Profiles
• Expanding scope to PHY Layers
• Full and Ulw PIM IDL Profile applicable to DSP and FPGA

SCA 4.1 ensures investment in SCA 2.2.2 applications can be reused in SCA 4.1 environment:

• An SCA 4.1 can now run any SCA 2.2.2 applications
• Required several changes to SCAv4.1 to keep new features and still be backwards compatible
• NordiaSoft led this effort for JTNC on behalf of WInnF

Support for applications composed of a mixture of SCA 4.1 and SCA 2.2.2 components:

• Allow developers to perform a more incremental transition from SCA 2.2.2 to SCA 4.1

Enhance the ability to migrate legacy waveforms to an SCA model:

• Naming convention changes

This article is based on excerpts of a White Paper from the Advanced Radio Systems group at the Communications Research Centre Canada.

The Communications Research Centre Canada (CRC) Software Communications Architecture (SCA) Core Framework, SCARI-GT, enabled Android™ smart phones to host JTRS SCA public safety waveforms: AM, FM, and APCO-P25.

Given their ability to host a wide variety of applications, commercial smart phones are surging in popularity and reaching new markets like public safety and military. Smart phones have essentially become computers with transmit and receive capabilities.

With this achievement, CRC demonstrated that the high performance general purpose processors now equipping these mobile platforms can be used to execute complex signal processing functions required for a wider set of communications protocols.

This accomplishment was the first step in turning smart phones into “smart radios”, as they can be reconfigured on the spot to adapt to the current tactical needs. Using the same commercial device, first responders and military personnel could switch from commercial networks to their own private networks, while continuing to have access to the plethora of other Android applications.

The demonstration worked as follows. To transmit from the smart phone to the commercial handset, the voice input was obtained via the phone microphone. An SCA Audio Device read the voice samples from the phone sound card device driver and fed the SCA waveform application. The waveform application performed the required signal processing (vocoder, modulator, squelch tone injector, etc.) and used an SCA RF Device to tune and transmit at a specific frequency. The SCA RF Device did not run on the smart phone. The demonstration works using any of the following: SDR4000 from Spectrum Signal Processing, a USRP1 or a USRP E100 both from Ettus Research LLC.

When the SDR4000 was used, the SCA RF Device actually was hosted on the PowerPC located on the SDR4000 blade itself. Using the USRP1, the SCA RF Device was hosted on a laptop connected to the USRP1. Using the USRP E100, the SCA RF Device was hosted on the ARM Cortex A8 located on the GumSTIX Overo inside the USRP E100 enclosure.

The SCA waveform applications communicated with the SCA RF Device via CORBA which provided location transparency. The smart phones were running ORBexpress™ for Android (C++ and Java) from OIS. The SCA waveform application was unaware of the actual physical location of the SCA RF Device which was being hosted by a remote processor. This made it very easy to run this demonstration using different hardware, which is exactly what the SCA specification was designed to allow.

Once the waveform reached the SCA RF Device, a signal was transmitted over the air to commercial-off-the-shelf public safety handheld devices. The waveform running on the smart phone used a virtual push-to-talk button to allow the user to toggle between transmission and reception modes.

The transmission from a commercial-off-the-shelf public safety handheld device to the smart phone used the reverse path. In this situation, the SCA RF Device fed the application with samples of the signal received over the air. The waveform applications performed the entire signal processing (demodulator, squelch detection, filtering, etc.) on the smart phone platform. And the resulting voice signal was sent from the waveform application to an SCA Audio Device which used the smart phone speakers to play the samples.

The Wireless Innovation Forum (WInnF), an international non-profit corporation dedicated to advocating the advancement of radio technologies that support essential or critical communications worldwide, identifies a Software Defined Radio (SDR) as a “Radio in which some or all of the physical layer functions are Software Defined”.

SDR technology addresses the exponential growth in the ways and means by which people need to communicate. Data, voice, video, messaging, command and control, emergency response communications, etc. are all encompassing communication mechanisms currently within the SDR domain.

SDR is a solution to competing demands about providing greater access to communication means while keeping a tap on the equipment costs. SDR is a flexible and cost efficient solution where benefits can be realized by service providers, product developers and even reaching end users.

As Software-defined radios (SDRs) are being more widely deployed, test and measurement instruments are ramping up to be able to test SDRs in a way that was not possible before. The market is moving so fast, manufacturers need to be able to react quickly.

In many cases, the products and protocols under test are evolving or still being defined until very late in the product development life-cycle. Supporting all the changes in hardware is very expensive and far too slow. In fact, traditional tester are often obsolete by the time they are brought to market. Software-defined testers (also known as virtual instruments) provide the level of flexibility required to adjust as the standards and protocols evolve. Furthermore, next generation software-defined instruments allow engineers to peak inside the radios to monitor and alter internal signals of the waveform. Not being constrained to the antenna port (i.e black box testing) provides an unprecedented way of testing and qualifying radios.

The Software Communications Architecture (SCA) follows a Component Based Development (CBD) paradigm that provides a framework for software components reuse that is highly suited for the EW domain.

Radar systems must perform massive signal analysis to convert information, collected by the antennas, into some form accessible by the user, be it an air traffic controller, weather monitoring or an embedded computer autonomously controlling a larger system (cars, robots, drones). Current state-of-the art radars perform this analysis by exploiting the capabilities of modern digital processors. The microwave signal is digitized and fed to one, many, or a combination of field programmable gate arrays (FPGAs), digital signal processors (DSPs), graphic processor units (GPUs), or general purpose processors (GPPs) where it will be filtered, down-converted, weighted, delayed, combined, and passed through many  other algorithms to obtain the desired information with the required accuracy. Those digitally processing radars are dubbed Software Defined Radars, by analogy to the Software Defined Radios that are now being commonly used in the military and commercial sectors.

The mere fact that the signal processing is now performed in the digital domain provides a huge advantage over the older and more traditional all RF implementations. The processing algorithms can be modified faster and easier in software than in an all hardware implementation. Depending on the application scenario, transmit and receive signal processing functions can be adapted on demand to suit requirements. New functionalities can be added without the need to upgrade or replace hardware components. Maintenance cost can decrease as the system can be upgraded or fixed in-situ.

But this flexibility comes at a cost, trading hardware inflexibility by added software complexity. Code generation and debugging is increasingly complex due not only to the number of algorithms that must now be programmed but also due to the distributed and heterogeneous nature of the hardware processing platforms required for radar applications. Nowadays is not uncommon to find applications that make combined use of GPPs, DSPs and FPGAs (some even using GPUs) where the application software is partitioned, deployed and configured across such distributed heterogeneous processors.

Software integration thus becomes in some cases a major source of cost overrun. Not to count that often most of the software-related work will need to be redone from the beginning with every new generation of the product, as the hardware platform changes.

With the growth of the software size and complexity, traditional approach to software development is increasingly inefficient, leading to lower productivity and consequently higher cost.

An approach to improve on this has been developed and adopted by military organizations for their communications systems. Under the joint efforts of US DoD’s Joint Tactical Networking Center (JTNC)(erstwhile JTRS) and the Wireless Innovation Forum (WInnF) (SDR Forum v2.0), a system design architecture framework has been developed promoting software portability and reuse, facilitating hardware upgrades and overall system scalability in an attempt to reduce development time and cost of new products. The software architecture, called Software Communications Architecture (SCA), has been adopted by the major Armed Forces around the world, and is now used by the major military radios manufacturers. The SCA promotes software portability and reuse to address software size and complexity growth in the Radar domain.

Electronic Warfare (EW) capabilities are becoming invaluable necessities in combat situations. Advanced warning, searching, intercepting, locating, recording, detecting and target acquisition are indispensable tasks in EW. 

Combat scenarios are changing due to new threats being developed while defenses are being tested with the aid of the electromagnetic spectrum. In EW, the need to gather, validate and process data from many different sources is a must. Identifying what electronic emitters are up to – whether friendly, hostile or unidentified – is crucial for effective electronic warfare operations. Decisions need to be made quickly with such acquired intelligence. Mission success now requires a comprehensive knowledge of the electronic battlespace. 

In sensing for potential threats, microwave signals are digitized and fed to one, many, or a combination of Field Programmable Gate Arrays (FPGAs), Digital Signal Processors (DSPs), Graphics Processing Units (GPUs), or General Purpose Processors (GPPs). The signals are then filtered, down-converted, weighted, delayed, combined, and passed through many other algorithms to obtain the desired information with the required accuracy. .

The main challenges in EW include signal detection, emitter parameter measurement and correlation, emitter sorting, identification, and operator notification, which are often classified as Electronic Support Measures (ESM) or Radar Warning Receiver (RWR) systems. ESM systems are often tasked to preserve electronic data for future analysis. Traditionally, ESM systems focus on emitters locations with the support of RWRs that estimate position/distance.

A non-comprehensive lists of a typical emitter characteristics, that ESM system functions can measure, includes radio frequency, amplitude, direction of arrival, time of arrival, pulse repetition interval, pulse width, scan type and rate and lobe duration (beam width). Other advanced ESM systems can also measure pulse repetition interval modulation characteristics, inter-and intra-pulse frequency modulation (FM), missile guidance characteristics, and continuous wave signals. 

By relying on a collection of algorithm implementations mostly done in software, EW is part of a larger trend of Software Defined domains that are looking into component-based architectures with enhanced portability and reuse of algorithm implementations. For large organizations that work on EW, Software Defined Radios, Software Defined Radars, etc., the benefits are multiplied as algorithm implementations can be shared as software components across those multiple domains. 

The Software Communications Architecture (SCA) follows a Component Based Development (CBD) paradigm that provides a framework for software components reuse that is highly suited for the EW domain.

Historically and traditionally the communications facilities and autonomous capabilities of an unmanned system have been completely independent. Communications and autonomy were stove piped sub-systems whose only interface was a port through which binary data was sent to the radio for transmission, and received from the radio for processing.

Advances in technologies have significantly changed the way radios are built, to the point where it is no longer just hardware that modulates and demodulates waveforms. On the leading edge of radio technology is the Software Defined Radio (SDR) paradigm, which implements a majority of the radio functionality as software, including the modulation and demodulation of waveforms. With its software underpinning, the SDR is an extremely flexible device whose performance characteristics can be easily modified via a software update. With such a large degree of flexibility, as is offered by a software approach, the question then becomes how to implement a SDR and how to ensure radio compatibility.

These questions of implementation and standards are addressed by the Software Communications Architecture (SCA), which is the defining standard for the U.S. Army’s Joint Tactical Radio Systems (JTRS) and is being adopted throughout the world for national SDR programs for countries in Europe, Asia, the Middle East and South America. The SCA responds to the challenges of implementing sophisticated radio control and algorithms by adopting the Component Based Software Engineering (CBSE) paradigm that provides a formalized approach to address the complexity problem.

Given that the robotics community has also adopted the same CBSE approach to deal with software complexity, a strong convergence exists between the communications and autonomy capabilities of an unmanned system. More specifically, it is now not only possible, but also desirable, to integrate autonomous capabilities with radio communications functionality. This integration onto a single hardware system offers a number of potential advantages:

• Reduced implementation complexity
• Weight savings
• Lower overall power consumption
• Increased flexibility, portability, reusability and expandability
• Opportunities to optimize radio communications

Both the required hardware and software architecture/framework now exist that allows for the close integration of radio communications and autonomy capabilities into a single processor. The software development process can be expedited through the use of commercially available graphical modeling Integrated Development Environments (IDEs) that greatly simplify the development of software components that implement core radio and autonomy capabilities. Those software components are then taken into the autonomous system and executed via the SCA Core Framework, which is a standardized deployment engine of software components for Heterogeneous Embedded Distributed Systems (HEDS). 

It is no longer necessary to consider unmanned system radio communications and autonomy capabilities as separate stove piped systems. Technology is now available that allows for the close integration of the formerly independent sub-systems. With this close integration the autonomy software can influence the radio configuration and vice versa. The advantages to such an approach are numerous and will assist the designer/engineer in producing ever more capable unmanned systems that are more flexible and expandable than the currently fielded products.

• Clear separation of the application’s core business logic from the underlying hardware and software in which it is to execute.
• Higher value business logic implementations, as SCA source code is easier to port from one platform to another.
• Application developers can focus on the actual application rather than spending time integrating it with the platform.
• Change of hardware or software is simpler as they are not tightly integrated and thus easier to upgrade.

SCA Platform abstraction is achieved through the identification of an Operating Environment (OE) that defines the Real-Time Operating System, inter process communication mechanism, and physical hardware in which the application is to be executed.

The hardware platform is abstracted through a set of common Application Programming Interfaces (APIs) that define the functionalities of the hardware, independently of their implementation. 

The application software is shielded from hardware changes by making invocations to well-defined APIs for different types of hardware. To do this, SCA platforms provide software proxies called SCA Devices that interact with the software application using such well-defined APIs, and then forward the application’s invocations to the physical hardware using the latter’s native drivers. Changing the hardware, therefore, does not require any modification of the application software. It only requires an adaptation of the software proxy to use the new hardware via its own native drivers. 

Operating Environment

SCA Devices can be used as proxies to any kind of hardware for software development in embedded systems domains.

Embedded systems software is often developed targeting only one Real-Time Operating System (RTOS) for execution. Such approach causes the software under development to hard-code its interactions with the RTOS, thus making it difficult to port to a different RTOS. Business opportunities are often cut short because of the lack of capacity to take fully functioning source code from one RTOS to another. The SCA addresses this constraint with the definition of an Application Environment Profile (AEP) that identifies a set of operations that can be invoked into a compliant RTOS from an SCA Application. The SCA AEP is a subset of the Portable Operating System Interface (POSIX) standard, and most RTOS nowadays comply with the POSIX SCA requirements. The impact on embedded systems software development under this approach is profound, as now complex algorithms implemented in source code can be easily moved from one RTOS to another.