This paper details the application of Software Product Lines (SPLs)1 and Model-Driven Engineering (MDE)2 to the Software-Defined Radio domain. More specifically, it is an experience report emphasizing the synergy resulting from combining MDE and SPL technologies.
The Software-Defined Radio domain has very unique characteristics as its systems typically are a confluence of a number of typically challenging aspects of software development. These systems are usually described by modifiers such as, embedded, real-time, distributed, object-oriented, portable, heterogeneous, multithreaded, high-performance, dynamic, resource-constrained, safety-critical, secure, networked, component based, and fault-tolerant. Each one of these modifiers by itself carries with it a set of unique challenges, but building systems characterized by all of these modifiers all at the same time makes for a daunting task in software development. In addition to all of these, it is quite common in these embedded systems for components to have multiple implementations that must run on disparate processing elements.
(visit our sponsor below)
With all of this taken into account, it stands to reason that these systems could and should benefit greatly from advances in software technology such as product line engineering, domain-specific modeling, and model-driven engineering. It is our experience that one big benefit to the software development industry is the combination of the software product lines and model driven engineering technologies.
For the past 20 years, there has been a continuous evolution in electronic communications equipment. The evolution can be described as one of moving the radio functionality from being located in the hardware platform running with proprietary processors and circuitry to being located in firmware running on programmable logic and then to being located in software running on general purpose processors. The driving force behind this evolution has been the need to leverage the inherent greater malleability and configurability of software versus that of hardware. As radio functionality continues to move into software, or looking at it another way, as that software moves closer to the antenna, it becomes more commercially viable to maintain, configure, test, and reuse communications algorithms and functionality as well as the hardware on which it runs. This evolution is very similar to that of the computer itself with today’s PCs running applications, the bulk of which exist as software running on general purpose hardware.
The communications industry has coined a term for this type of communications equipment: the Software-Defined Radio3.
The conventional radio development paradigm during the 1980s and 1990s involved make one-off systems that had to be redesigned and recoded as new hardware platforms evolved. To solve this and to make the vision of a Software-Defined Radio concept a reality, the U.S. government formed the Modular Software-programmable Radio Consortium (MSRC) consisting of the four top military radio manufacturers at the time. This consortium was tasked with doing a full Commonality Variability Analysis (CVA) across the entire family of existing radios. Following this, they were contracted to devise production assets that could be deployed across the industry that would turn the existing one-off development paradigm into a more Software Product Line Architecture/Engineering (PLA/PLE) approach.
As the radio and communications domain moves into a software-centric solution, it is only natural that it leverages advances in the software domain as part of its implementation. These advances include object orientation, frameworks, component-based design, and middleware, in addition to imperative and declarative languages. More recently, the rise in abstraction level of the radio platform in the form of operating systems and middleware in combination with advances in modeling tools has opened the door to allow the evolution of communications software to enter the realm of a combination of product line engineering and model-driven development. This is fortuitous as the complexity of these communications systems has increased so dramatically that the viability of these new systems now hinges on the increased productivity, correctness, and robustness this synergy affords.
Detailed background
In 1999, the MSRC issued the results of their CVA. The result was the Software Communications Architecture (SCA)4. It was the key production asset released broadly to both the manufacturers of the entire family of military radios as well as the public domain.
This SCA defines five primary aspects of next-generation communications equipment software:
A standard component object model
A standard deployment and configuration component framework
A standard declarative programming format for describing software components and how they are connected
A standard portability layer upon which components run
A standard messaging format/middleware for intercomponent communication
As a result, the SCA significantly furthers standardization of the software radio domain and thus brings many benefits to the domain such as interoperability, portability, reuse, and a level of architecture consistency. As is the case with many new platform technologies, the SCA specification does a good job of solving many hard problems but leaves some unsolved while simultaneously introducing new problems. Some of the problems that remain or are introduced include:
Labor-intensive implementations of the SCA object model in 3GL languages
Lack of architectural consistency at various levels of implementations
The learning curve of the specification and lack of effective training materials
The technology gaps between software developers and radio domain experts
Ensuring correctness of implemented systems
The dynamic nature of the SCA, which opens the door to a host of runtime errors that would best be left shifted out of runtime into either into modeling or compile time
A complex set of XML descriptor files that are difficult to get correct by hand as there are many rules that govern them above and beyond being well formed
No formal metamodel or UML profile exists for the SCA.
While the SCA definitely raises the level of abstraction with regard to radio component development, it does not inherently provide an automatic and configurable means to get back to the lower, executable levels of abstraction or to its declarative languages.
We feel that the essence of the problem can be boiled down to: an advancement of platform technology without a commensurate increase in language technology. The languages most used in radios today for the entire system are C and C++. These two languages were invented more than 20 years ago. In that intervening time, there have been many advances in platform technology that have outpaced the ability of these third-generation languages to suffice as the only real tool in the hands of the software developer tasked with implementing these new complex systems. The middle two columns in Figure 1 illustrate the evolution of various areas of abstraction including language and platform technologies. Platform technologies have evolved from CPUs and operating systems to complex middleware and frameworks. Programming languages have evolved from writing ones and zeros to higher order 3rd Generation Languages such as C++ and Java. Note the gap between higher order languages and the platforms.
Enter domain-specific modeling languages and techniques
In order to tackle and tame the complexity of these systems, the new specification, and the platform technologies resulting from the product line analysis, new language technology was required to allow the developers tools to catch up to the platform technology. As such it was necessary to provide:
Effective support under the SCA that allows users to program directly in the terms of the language of the domain and specification, ideally in graphical and declarative form to the greatest extent possible
Means to ensure that the programming is correct
Means to automatically generate executable 3GL programming language implementations from these models
Means to automatically generate additional software artifacts that are synchronized with the model
Those familiar with domain-specific modeling will recognize the above bullets as part of the sacred triad5 of domain-specific modeling: language, editor, and generator. Couched in terms of domain specificity and at a finer granularity, these three elements map to:
A Domain-Specific Language (DSL)
A Domain-Specific Graphical Language (DSGL) and Domain Specific Views (DSV)
A Domain-Specific Constraint Language (DSCL)
A family of Domain-Specific Code Generators (DSCG)
Our experience is that these four bullets constitute the necessary quanta increase in language technology to keep pace with the increases in platform technology.
Table 1 lists the activities used in tackling the complexity in domain and then leveraging domain specific modeling techniques to it.
General approach
Radio domain
Isolate the abstractions and how they work together, including commonalities and variabilities
The SCA
Create a formalized grammar for these – DSL
Create a formalized SCA meta-model
Create a graphical representation of the grammar – GDSL
Create an SCA-specific graphical tool
Provide domain-specific constraints – GDSCL, DSCL
Program the constraints into the tool
Attach generators for necessary transformations
C++, C, Ada, and VHDL generators
Table 1
One type of tool that can be used to develop the above software artifacts are what some refer to as language workbenches1: tools that allow a developer to define a Domain-Specific Language and its graphical counterpart, the editor, as well as domain-specific generators that can iterate over the domain-specific model to produce executable artifacts. Some language workbenches available today include the Eclipse Modeling Framework and the Eclipse Graphical Editor Framework (EMF/GEF)6, the Generic Modeling Environment (GME)7, and Microsoft’s Visual Studio Team System Domain-Specific Language Tools (VSTS DSL) tools8.
To allow users to run on multiple host platforms most easily and to integrate with addition Eclipse tools and frameworks, we chose to use the EMF/GEF solution.
Defining the Domain-Specific Language (DSL)
The goal here is to provide a domain-specific higher level of abstraction with which both software and lay developers can program. Key to this is not only raising the level of abstraction but also providing domain-specific abstractions. Developers of SCA applications typically program in 3GL languages such as C, C++, and Ada. One of the goals of domain-specific modeling is simplified modeling and programming in the problem space vs. complex modeling and programming in the solution space. Figure 2 below juxtaposes two possible ways to represent the same concept in the SCA Software-Defined Radio domain. The left side diagram shows a typical UML diagram for a trivial SCA Component with two ports and two properties. The C++ source code is even more complicated. The right side diagram shows the same entity in terms of a higher abstract concept, a component with two ports and two properties, that is much more readable and less complex.
Of course, there are tradeoffs that come with raising the level of abstraction. These tradeoffs are indicated in the outermost columns of Figure 1 (shown previously). Higher level languages provide less control and ability to express concepts in detail. The control provided by lower levels of abstraction is frequently gratuitous. Additionally, the use of higher level languages does not advise against continuing to use the lower level, more detailed languages where appropriate. For example, sometimes, it is necessary to debug in the lower languages; since there is a high fidelity relationship between the higher abstractions and the lower level languages, this is possible.
The raising of the level of abstraction is made possible through the creation of a formalized metamodel expressed in terms of the particular language workbench. In this case, this involves creating a metamodel that the Eclipse Modeling Framework can understand. Figure 3 shows a greatly simplified metamodel for the SCA. Naturally, the full metamodel for the entire SCA is much more involved, but for the purposes of demonstration and saving space we have presented a simplified version of it.
As stated earlier, the SCA provides a general architecture and UML diagrams as well as text-based behavioral descriptions and requirements and annotated XML DTD documents. While these are very detailed, they are not formalized sufficiently to serve as a useful metamodel by themselves. The metamodel created and described here involved building upon the structure of the SCA and culling from the rest of the specification requirements, constraints, and behaviors that together make up a complete and comprehensive metamodel characterizing the entire specification. As is usual, the group of developers building the metamodel are experienced SCA and Software-Defined Radio developers as well as experienced modelers.
It is from this metamodel that one provides the end user with the ability to program more directly in the domain. Additionally, end users are able to program more in the declarative than in the imperative, for example, saying what they want to have, not specifying how it is to be done. Listing 1 shows a simple example of the persistent form of the Domain-Specific Language in accordance with the metamodel.
While providing a higher level of abstraction, this text-based language can still be labor intensive, error prone, and hard to read. This leads directly into the next step of domain-specific modeling.
Defining the Domain-Specific Graphical Language and Views
What is needed next is a way to express the Domain Specific-Language graphically or visually. This involves working within the language workbench of choice to adorn the Domain-Specific Language with graphical and visual artifacts that allow the user to program quickly and correctly and in a way that communicates correctly the essence of the architecture and design.
Figure 4 shows the PrismTech Spectra SDR Power Tool modeling tool. This modeling tool allows end users to quickly and accurately build Software-Defined Radio components and connect them together. The DSGL is built and based on the underlying metamodel described earlier and can be stored in textual form for processing by other programs. It is through this DSGL that end users program with very intuitive icons, images, tools, artifacts, and property sheets. Just as UML provides different views to describe various aspects of object-oriented systems, so too does this tool provide Domain-Specific Views that allow users to design, express, and communicate domain-specific aspects of their designs. Additionally, the domain-specific modeling tool provides the end user with ability to program in the declarative versus the imperative.
(visit our sponsor below)
The Domain-Specific Constraint Language
Almost as important as what you see in the graphical tool illustrated in Figure 4 is what you don’t see. The very fact that the DSGL is based on the metamodel means that it restricts programming to within the bounds of the metamodel. In other words, the tool is metamodel-centric as opposed to GUI-centric. In this case, the GUI itself forces the user to abide by the structural and creational aspects of the metamodel. This goes extremely far in enabling developers to program quickly and correctly in terms of their domain. Additional constraints can be added via various programming facilities of the language workbench being used. Concrete SCA-unique examples of these types of constraints include not being able to connect ports that support different interfaces or not exceeding connection thresholds of output ports. These are errors that are typically allowed to creep into the runtime system that lead to expensive integration and support problems. By left shifting these potential defects into the modeling/compilation phase, we can simultaneously harness the dynamic nature of the SCA runtime component deployment, configuration, and connection paradigm and do so in a correct and robust fashion. Errors can be reported in various different forms including dynamic dialog box feedback for instantaneous notification and fix, or via an error log in which the user can double click on the error and the tool will the take the user to the offending model element. The DSCL enforces structural compositional, and directional, constraints, pre-conditions, post-conditions, and invariants.
Domain-Specific Generators
Ultimately, the tool must be able to transform the Domain-Specific Language into an executable or imperative format, or to a form that can be transformed easily by other compilers into an executable form. This is achieved through the connection of Domain-Specific Generators to the Domain Specific Editors. Embedded systems are frequently targeted at disparate processing elements (such as general purpose processors, digital signal processors, and Field Programmable Gate Arrays (FPGAs) and as such, the tool needs to be able to plug in multiple domain-specific code generators that can iterate over the model and produce multiple types of executable code.
Figure 5 shows examples of the software artifacts coming from the domain-specific generators. Having the key information captured in the model, changes in the model are instantly reflected in the generated code. The generated code follows specific design patterns to allow the user’s business logic to be decoupled from the generated framework completion code.
The SCA architecture is most effectively implemented using a number of industry standard Design Patterns. Most notably are the Extension Object Pattern9, Extension Interface Pattern10, and the Component Configurator Pattern10. These patterns are typically repeated over and over again in an SCA implementation with minor paramaterization to account for the context in which they are used. The prevalidated implementations of these patterns can be generated directly from the domain-specific generators. Many of these patterns capture infrastructure scaffolding, behavior required by the SCA specification, as well as middleware concerns that can be difficult for radio developers to understand and get correct. Additional artifacts are generated from the model, including the XML descriptors, unit test cases, documentation, and so forth. The constraints of the tool straddle the editor and the generators. By using the generated code, the users can rely on prevalidated logic and patterns written by experts in the domain and thus they are constrained, if you will, to being correct in their implementation. Having the code generated automatically and no longer being saddled with this task, users can concentrate on writing, debugging, and integrating the business logic for their components.
Benefits of domain-specific modeling as applied to Software-Defined Radios
A number of notable benefits become extremely apparent as a result of providing a domain modeling tool and all its constituent parts to the Software-Defined Radio domain:
Increased productivity– Users can program at a much higher level of abstraction and use generators to automatically get to lower levels that can thereafter be transformed and executed. The increased level of abstraction is coupled with the fact that the DSL is much more declarative in nature and so users become less concerned with how actions are done and more concerned with that they are done. Users of the tool report a minimum of 500 percent increase in productivity and compare the magnitude of gains to be analogous to using a compiler to generate assembly code from higher order languages.
Increased correctness – The generators provide prevalidated logic and other artifacts.
Synchronization of software artifacts – Since the artifacts are generated directly from the model, the burden of maintaining them all is greatly reduced.
Involvement of domain expert engineers and increased communication amongst company teams – Since the model is expressed in problem domain terms and not solution domain terms, the communication of the model encompasses more disciplines beyond software engineering to include hardware and systems engineering and management teams.
Lower cost of entry – As much of the infrastructure detail is captured in the metamodel, editor, and generators, the learning curve of developing Software-Defined Radios for a particular domain is greatly reduced.
Architectural consistency at the implementation level – While the SCA mandates architectural form at the interface level, it does not at the implementation level. This opens the door to many different architectural implementations. While this is necessary in some uses cases, in many it is not and results in unnecessary complexity and maintenance burdens. The degree to which the applications have architectural consistency in their implementations determines the ease of maintenance by a central maintenance body.
Left shifting defects from runtime to modeling time – This provides orders of magnitude of cost savings across the development cycle.
Software evolution and the software radio domain
The history of software has seen the continued process of raising the level of programming abstraction while simultaneously providing an automatic and configurable means to traverse to lower levels of more executable forms of programs. Additionally, this evolution has included the continued introduction of ways and means to express domain concepts and design intent effectively so that the end user can program more directly in the problem space and not in the solution space.2 Using Model Driven Engineering and domain-specific modeling via existing language workbenches in combination with Software Product Line engineering is another effective step in this direction, moving toward a viable commoditization of the software industry. Application of these techniques to the software radio domain has yielded orders of magnitude of increase in productivity, correctness, and robustness of these systems and can serve as the foundation for a graceful evolution of its products. The tools referenced above are fielded and are being used by many Software-Defined Radio developers.
Bruce Trask is Chief Architect, SDR Products at PrismTech. He has been architecting, designing, and developing software for complex real-time embedded systems for more than 19 years. This includes extensive experience in the Software-Defined Radio domain. He is currently PrismTech's Chief Architect for its Spectra SDR products. In addition to developing systems, Bruce has been teaching software development classes and leading study groups on many software subjects including CORBA, Design Patterns, C++, UML, Object-Orientation, Software Communication Architecture, and others. He also has mentored large development teams. Bruce is a regular speaker and lecturer at industry conferences and is a graduate of Brown University.
)
