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.

MDE Systems has been ... for years

  • Training
  • Continuous Integration
  • Automated Testing
  • Programming Language Techniques
  • Agile Software Develop
  • Software Product Lines
  • Model Driven Development
  • Working Effectively with Legacy Systems