JTRS Ramblings

By paul ~ May 7th, 2007. Filed under: SDR & SCA, Systems Engr..

For the last three years, I’ve spent the bulk of my time using Foresight to help companies perform performance analysis of their JTRS software defined radio designs.  In that time, I’ve noticed some things that I’d like to comment on.  At the risk of biting the hand that feeds me, so to speak, here are my observations and opinions (for what they’re worth.)

Software Defined Radio?

When Foresight Systems was first approached in 2001 by the Joint Program Office (JPO) to build an example performance model of an SCA, JTRS-like radio with a simple waveform and platform, I said “What?”  I was familiar with what folks were doing in creating software modems running on DSPs and so-on, but my first look at the SCA architecture was a “shock and awe” experience.  Clearly, this was going to be a significant, complex, software application.  And CORBA in the data path?  Well, years later, lots of tax $$ spent, a program reorganization, and fortunately processors have gotten a lot more powerful, so we’re starting to see some working networks.  Cool!

One of the things that I’ve realized, over the years, is what a strange and risky transition our forces are making.  Up until now, the term “radio” has primarily meant a device that was designed by people who were mostly hardware designers and knew a whole lot about modulation, RF, amplifiers, antennas, propogation, etc.  They knew how to build radios and the process was predictable in terms of performance, time, and budget.  The migration to “software defined radio” has jerked the radio design process out of the hands of these capable people and placed it in the hands of a group that is completely new to “radio”;  the software developers.  The hardware guys are still important, but they’ve been pushed to a fairly small part of the radio, safely fenced off by the Hardware Abstraction Layer.

Now, stop and think about this for a minute.  I’ve been an application software developer for my entire career.  I know how the best of us do things.  I’ve been working with hardware designers all of my career.  I know how they do things.  What we’ve just done is to move the responsibility for our military force’s communication links from one of the most predictable disciplines to a discipline that is legendary for its unpredictability.

Remember when the old tube radios took a few minutes to warm up?  You might get to experience that wait again.  How many times have you heard from customer support for your computer or software “Try rebooting…”  When was the last time a major software project came in under-budget and on time?  When was the last time you heard that when you upgraded a software application that you’d need more memory and a faster processor?

I can hear some of you embedded guys reminding me that hardware-based systems (from cars to microwaves) have an ever-increasing software content.  The reasons for this are obvious, in most cases, and the benefits have been fantastic with only minor quality inconveniences.  (Last night, the battery in my car failed and the security system caused the horn to blare for several minutes before I could find and remove the horn fuse, so there are certainly examples to the contrary.)  But, let me remind you that the folks building software defined radios aren’t your traditional embedded software developers.  They’re application developers and they’re developing for a target environment with several layers of middle-ware, often built by different vendors.  Developing a JTRS waveform is much more like developing a software application for Windows or UNIX than anything else.  In fact, a JTRS waveform is much, much more than what comes to mind when I think of the term “waveform”.  And therein, I think, lies one of the major flaws in the JTRS/SCA architecture.

What I think we should have done is to keep the two distinct parts of a JTRS radio “terminal” separate:

  • the packet radio modem (which we’d call the “radio”), and
  • the various security, network and multimedia appliances that use it (which we’d call the “communications package” or something.)

Notice I’ve dumped the term “waveform” which means something closer to the signal-in-space or modulation strategy or something.

The radio part should be built by radio people, and the various “communications apps” should be built by appropriate teams with the appropiate competencies.  I maintain that partioning the design and development problem (and contract award) in this way would sigificantly help the JTRS program, even at this late date.  (Yes, I’m Monday night quarter-backing.)

(Note that some may argue that this separation does, in fact, exist.  However, in my experience with a number of waveforms, the two are not separated.  The waveform specification spans both the communication package(s) and the modem, with the platform only providing services to the waveform.  Certain waveform requirements certainly drive this decision, but the cost is very high.)

Who Should Be Doing What?

This all leads me to the question of competency.  If you look at the requirements for a JTRS radio terminal, some obvious things jump out at you:

  • It has/is a radio modem that connects to a radio network.
  • It must meet a lot of network-appliance requirements (i.e. IP routing, multimedia, differentiated service, network security) while
  • Providing traditional radio functionality (point-to-point and broadcast voice)
  • Often in a highly constrained platform (low power, high servivability, small form-factor)

Now, what are the big name companies that come to mind that provide products in these areas?  I mean, doesn’t “radio modem in low power, small form factor” sound a little like a cell phone or aviation radio and make you think of Motorola, Nokia, or Ericsson?  Doesn’t “network-appliance” immediately make you think of Cisco?  Interestingly, you won’t find them involved.

I wouldn’t raise this issue if I hadn’t seen questionable and complex designs for waveform components that companies like Cisco could have delivered “off-the-shelf”.  Seriously, I think a team made up of Cisco and Motorola would be very successful designing JTRS radios and waveforms.  They have the necessary competencies and the program would benefit greatly from emerging technologies developed in the commercial sector while the commercial sector would benefit from technologies developed to meet military requirements (see MANet below.)

Software Defined Radio is Hard

All this being said, designing JTRS radios (platforms and waveforms) is hard.  There are many competing requirements.  The SCA alone demands a significant amount of system resources.  Add in the performance requirements associated with a real-time radio and the network and information security requirements associated with a military terminal.  Deploy this in a form factor and power footprint that allows it to be installed in an aircraft or carried by a soldier.  Finally, add the requirement that waveforms must be portable to many different platforms and that waveforms, platforms, and middleware may all be delivered by different vendors.  It’s tough, and the people who are involved are working very hard.

One of my favorite scenes from the old Star Trek series appears in “City on the Edge of Forever.”  Kirk and Spock are marooned in the US in the 1930s and Spock is trying to build part of a tricorder from the technology available at that time.  At one point, Kirk trys to increase Spock’s sense of urgency and Spock replies “Captain, you’re asking me to [construct a mnemonic circuit] with equipment that is hardly better than stone knives and bearskins.”

JTRS needs the best in systems engineering tools and methodologies.  Sadly, as with so many other large software projects, schedule pressures crowd out good engineering practice.  Truly useful design and analysis tools (and the expertise required to use them) are often unavailable.  Let’s face it, defense contractors are incentivized (unintentionally) to do it wrong a couple of times before they do it right.  (I’m not implying that they do this on purpose, just that this is the way the system works so schedule often takes precedence over “doing it right”.)

I have a challenge for you.  If you’re one of those overworked people working on the JTRS radio program, try the following exercise (when you just need to get away from it all.)  If you can pull it off, send me an E-mail and I’ll send you a signed certificate that says “I know how my radio works!” that you can hang proudly in your cubicle.  Here’s the exercise:  Sit down and draw an end-to-end block diagram (data flow diagram) from baseband input to RF output of the transmit data path through your radio that includes every queue and software component that the packet passes through.  To keep it scoped, feel free to ignore peripheral components that are not actually involved in the data flow.  This will test not only your understanding of how the signal and packet processing works, but also your understanding of how the SCA works.

Can’t do it?  OK, we’ll make it open book.  Go to your UML model (after all, you’re doing Model-Driven Design, right?) and your software design documents and try to draw it from the info you find there.  (I know, if you’re one of the hardware guys, you’re at a distinct disadvantage because you might not even be able to get at the software design.)

If you succeed, send me an E-mail describing your role (i.e.  software developer on the OE, waveform, hardware designer on the modem, etc.)  (I promise I won’t put your E-mail address in a database and flood you with Foresight sales material!)  It goes without saying, but don’t send me your DFD!! I will tally up how many responses I get for each role and post the summary here.  (As of today, Feb. 23, 2008, I’ve had no takers on this offer.)

Here’s what I would expect (based on my experience) to see.  The waveform software guys will have a clear advantage, but only the architects will be able to draw the whole picture.  The hardware guys and systems engineers won’t be able to do it.  Program management folks won’t be able to do it.  Just as a point of reference, I’ve worked on a number of projects where it took me two weeks or more (and a lot of running around) to get such a DFD out of the team.

As an aside, once you develop such a DFD, you’ll find it extremely useful and your co-workers will all want a copy.  Just think how great it would be to have a complete, executable model!

My point?

  • To put it bluntly, in many cases there isn’t a lot of true, top-down systems engineering going on!
  • Many of the people who ought and need to know how their system works don’t.
  • Current “Model Driven Design” methodologies using UML really only produce a collection of UML diagrams instead of useful design documentation or analysable models.

Program Non-Management

Before I get hard on program management, I need to admit at the outset that I can’t even imagine all of the constraints that JTRS program management must work under.  The rules associated with managing government acquisition are on a par with income tax law.  And the breadth of the program is breathtaking.  So, I’m sympathetic, and I don’t want to imply that I think any particular office or sub-contractor is at fault.  As a whole, though, aren’t you a little embarrassed?

Let me list a few specifics.  I know that many who are involved in JTRS program management at some level will say “but you don’t know how our hands are tied.”  Yep, you’re right, that’s why I think it’s an overall problem, from congress down.

  • Somehow, the concept of “Simulation-Based Acquisition” got left out of the JTRS program, or it didn’t go deep enough.  Requiring vendors to provide functional and performance models & simulations throughout the proposal and award process could have been invaluable in evaluating the credibility of approaches as well as fine-tuning requirements.  Carrying this through the design and test phases could identify potential problem areas early, while providing useful artifacts to other stakeholders.  (i.e. A performance model of a waveform that could be mapped to a radio builder’s platform and simulated during platform design would greatly reduce the risk of not finding a serious performance incompatibility at integration.  The same model could be used to calibrate a node model in a network-level waveform model for operational simulations.)  [Yep, I’m selling Foresight, can’t help it.  Choose your own tool, though, and it would still be invaluable.]  Ultimately, simulate-able models that the vendor stands behind should be a part of the deliverables that the government can share with whomever it wishes.
  • There needs to be a way for “best practices” and “key learnings” to be shared between “clusters” and vendors.  The fact that team members are also sometimes competitors makes this difficult, as do various other contractual rules about who can talk to whom about what.  As it is, the real and perceived barriers keep important information from being shared.
  • Program management should not shy away from mandating systems engineering processes and deliverables.  There should be a “design” phase during which vendors are allowed to give their input to the creation of the “process” after which it should be mandated and followed.  For a program this complex and risk-intensive a quality, consistent systems engineering process is a must.

I welcome your comments on this subject.  It’s incredibly complex and my comments here have only just touched the surface. I admit that my views have developed from the rather limited perspective of one who has worked on a number of radio platform designs and waveforms within the radios.  But, isn’t that where a lot of the problems have been?

MANets Are Cool

On a more positive note, one of the areas of research where defense-related requirements and investment could result in some really interesting civilian, commercial applications is Mobile Ad-hoc Networks (MANets.)  Imagine being able to participate in broad-band data networks while riding around in a car or even flying.  There is great commercial/defense collaborative potential in this area, and I hope that we’ll see more DoD funding in the form of SBIR topics and so-on.

In Summary

I hope this is received as more than a gripe session.  I’d like the industry to see my comments as an open challenge.  First and foremost, let’s admit that we have a deficiency in our systems engineering, at a number of different levels, and try to figure out a way to improve things.  (It’s no use saying we have an SEI level 5 software organization and development process if we’re building the wrong thing.)  Secondly, I firmly believe that model driven design (where the model is executable or simulatable) is a significant aid in the design of highly constrained, complex systems such as the JTRS radios and waveforms.  Thirdly, any significant, long-term application development project needs to be able to stop from time to time, re-evaluate itself, and re-factor, if necessary, in order to deliver something useful.  The re-organization of program management last year and the refactoring that occurred at that time was probably good, but not sufficient.  I’d really like to see the industry, those who’ve been doing the work, invest in some re-evaluation for the good of the program.

2 Responses to JTRS Ramblings

  1. » JTRS GMR, A Cautionary Tale -- Performance Engineering

    […] Second, Foresight Systems M&S was not involved with the GMR program (this is actually one of the problems, but I’m jumping ahead of myself).  Finally, the issues with the GMR program do not […]

  2. » Embedded System Porting Benefits From Performance Modeling -- Performance Engineering

    […] Making the investment to reverse-engineer an application and build a simulatable model of it will save significant time and money in the long-run.  This is particularly true of large, complex applications where the team doing the porting is not the original development team.  On the other hand, blindly undertaking such a challenging port will always be much more costly than anticipated.  JTRS waveform porting is a case in point. […]