2/3rds of SDR is SD

Developing Software Define Radio (SDR) Software is hard. Really hard.
About seven years ago a group of us were in a lab getting ready to field a JTRS radio.
We were having some troubles getting some final integration points handled. We sat
back for a moment and thought to ourselves about the type of software we were
developing. Think about it for a moment. If you had to come up with a list of
modifiers that describe the type of software we are making for SDRs, it might
include some or all of but not limited to the following:

Distributed

Real-time

Embedded

High Performance

Fault Tolerant

Dynamic

Secure

Networked

Heterogeneous

Portable

Compliant

Life Critical

Multi-threaded

Multi-process

Object Oriented

C/C++

Software

Each one of these items introduces unique challenges by themselves. For example, embedded
usually brings with it the sometimes onerous task of cross compilation; embedded systems
typically have limited input and display devices; they have limited tools, limited resources
etc. Embedded usually includes with it the use of a Real-time Operating System and all the
idiosyncrasies that come with that. Portable implies a well architected software base that
behaves robustly in the presence of multiple degrees of freedom or axes of change (see section
degrees of freedom below). Software that's portable has to evolve gracefully into the future
in the presence of these changes. Distributed brings with it all the challenges of networked
systems, including performance, interoperability, connection mangement, distributed error
handling etc. The list goes when considering the challenges the above items introduce when
considered alone.

Let's take it a step further. When we are asked to develop these types of systems,
we are being asked to tackle these various aspects all at the same time.
Now consider that many of these apsects above are somewhat, if not diametrically,
conflicting concerns with each other. In other words we need to reconcile all these
forces which are not necessarily pushing our software systems in the same direction.
In fact they may be pushing our software in opposite directions simultaneously.
Consider Dynamic and Secure. Dynamic implies that the system is extremely flexible
and configurable. With the dynamic facilities provided by some of the standard
SDR deployment and configuration frameworks, we can load whole new waveforms onto
the radios over the air. This flexibility and dynamism introduces some Security
challenges that are not easy to solve. High Performance and Portable is another
example pair that don't necessarily work well together. Typically we handle
portability with standards and/or the introduction of levels of indirection each
of which can strain the performance of the system. Similar stories could be told
for other pairs, such as Fault Tolerant and Real-time or Dynamic and High Performance

Let's look at it from the perspective of change.

A brief list of degrees of freedom against which many types of SDR software has
to behave and evolve gracefully include:

Hardware (x86, arm, ppc and various versions thereof)

Operating System (Linux, Integrity, VxWorks ...)

Middleware (vendors, configurations)

Core Framework (vendors, versions)

Optimization Levels (space - speed)

Memory Footprint

Processor Power (size weight and power)

Virtualization

Transports (TCP/IP, Shared Memory, Custom IPC)

Tool chains

Kernel Versions

So, in short, we have to successfully tackle all of the above, individually and together and
in a way that reconciles, resolves and unifies the seemingly conflicting concerns. All the
while doing it on time and under budget of course!

Needless to say, this is quite a cross to bear.

Given the complexities and changes of the problem domain and the complexities and changes in the
solution domain, your company's technology has to be at a maximum to even have a chance of success.

Many teams have reached a complexity ceiling when using their current tools, techniques and
infrastructure. Many engineers and their teams are buried in software artifacts that do not
effectively capture their domain.

We have worked very closely with many teams and have found similar situations across each.
It looks somewhat similar to the figure below.

Development teams have attempting to handle the development of SDR systems through the use
of XML descriptor files, UML diagrams and 3rd generation imperative languages only. These
tools are all good but not to address all problems.

Many companies have many teams within their walls solving these problems in similar ways and
so have many instances of this problem.

Additionally, in many cases upto 80 percent of the code many SDR development teams are writing
is duplicate code. It may not seem like that but consider the following diagrams.

What may seems like a shockingly high amount of duplicate, rote code (the boxes on the left)
is actually interleaved with the non-duplicate creative code (the boxes in the middle).
And it can be so finely interleaved that it appears to be one monolith of new code
(the boxes on the right). This is a huge problem for companies.

Due to a number of recent critical innovations, development teams are now able to combat
these challenges and problems. They can use extremely powerful domain specific modeling
and programming tools such as those shown below.