Back on track: JTRS JPEO assures open SCA and coalition use
StorySeptember 19, 2008
Q&A with Dennis M. Bauman, JTRS JPEO
MIL EMBEDDED: JTRS is all about interoperability between services, different waveforms, and hardware types. But how would you describe the applicability of the JTRS Software Communications Architecture (SCA) to all of your vendors - and to the greater SDR industry at large?
BAUMAN: We think it's very open, based on our SCA and APIs. There are 26 of them currently (corresponding to the JTRS waveforms). Those are the Increment One APIs, and we're continuing to refine them for future increments. What we do is obtain government-purpose rights on all the software developed on JTRS, and then we put it into an information repository. The repository is like a library, and we give out library cards to any industry people who want it. But they have to agree to, number one, use it for government purposes and tell us what they are using it for. Number two, if they change it, they've got to give back the changed code for the repository with government-purpose rights or better.
So JTRS is not quite as open as Linux because we have security issues that Linux doesn't, but we think we are pretty close. What we achieve by doing this is reusability and the resulting cost savings, along with interoperability because we are using the same software across all our products. This allows us to swap out vendors because we have these kinds of "Lego" building blocks in our repository. So if we aren't getting what we want from one vendor, we can buy that same module from another vendor.
MIL EMBEDDED: To what extent have you verified that Boeing's SCA implementation, for example, is consistent with GE Fanuc's SCA implementation?
BAUMAN: We have something called the JTEL lab, which tests and certifies all products for SCA compliance. The lab does that through a series of automated tools that go through and look for possible discrepancies that are then flagged. Next, the lab performs manual tests and inspections to determine whether a vendor's product meets the SCA. If it doesn't, then we send specific problems back to the vendor and get them to correct them.
MIL EMBEDDED: So could you, API issues notwithstanding, unbolt Thales' implementation of SCA and marry it to a Boeing AMR cluster?
BAUMAN: We're doing that already. The waveforms that are going to be used in Boeing's products are produced by a variety of vendors, for instance, ITT is under contract to do SRWs. There are multiple vendors who are under contract and are producing waveforms that are going to go on all the different boxes. That's the whole idea of the repository, and the whole operating environment on GMR was shared and used on MIDS-J [Multifunctional Information Distribution System].
MIL EMBEDDED: How many of the original 32 waveforms are still being ported and made SCA compliant?
BAUMAN: I'd have to check the number, but it's between 9 and 12. But we didn't drop the others. One of the things we did in the short term was go for a "big bang" approach to JTRS, with the incremental approach. And so in Increment One, we have a subset of those original 32 waveforms, decreased down to the 9 or 12, but we also added a couple.
Anyway, everybody says we shrunk the requirement, but that's not entirely true. We shrunk it in some aspects, but we went from a single waveform networking form, WNW, to three of them in Increment One, for example. The reason is that there's a difference in number, like in UHF satcom. If you count 181, 182, 183, and 184 as four different waveforms, then you have a different number at the end than if you count UHF satcom as one waveform.
MIL EMBEDDED: To what extent do you think the SCA will be adopted by the commercial market, which was one of the original pushes of the program?
BAUMAN: I don't know. I know that it's being seriously considered for adoption by our international coalition partners. There was at one point a push in Europe to build their own SCA, and that's atrophied. You know that you could define many standards that are like the SCA (yet different), and they'd probably work just as well. But what we're trying to convince the world is, here's one that's here, so why not use it?
MIL EMBEDDED: Are there any definite outreach efforts to the likes of Nokia, Ericsson, or other civilian companies?
BAUMAN: We have done that through the Software-Defined Radio Forum. Quite frankly, we're seeing a lot more traction with that in the past six months. And the reason for it is that if you compare where JTRS is now with the big downturn in the IT world, there was a big "Let's go from second-generation cellular to third-gen" push five years ago. Well, the business case in light of the downturn just wasn't there. But now you're seeing some of the third- and fourth-generation cellular products being rolled out. So there is now increased interest on the industry's part to look for more open systems standards, and we have one that's perfectly viable. One detractor to it, though, is that we make it so open that a lot of vendors who embed their own Intellectual Property and are dependent upon maintaining IP are a bit taken aback by how open the standard can be.
MIL EMBEDDED: To what extent do you think any JTRS implementation is going to utilize cognitive radio capabilities?
BAUMAN: We consider cognitive radio to be at the forefront of technology. Well, one thing you do as an acquisition fundamental is you don't adopt technology before its time. I think cognitive radio technology is very promising: It can help us with spectrum - and in a lot of ways. But it's too leading edge to put into production at this time. We are working with DARPA on that. Actually, I believe cognitive radio is a capability cap in Implement Two that we're currently looking at. But it's not ready for prime time, and we're not putting it into Increment One as part of our requirements discipline.
MIL EMBEDDED: What are your plans for tech refresh?
BAUMAN: Our plans for tech refresh will be part of Increment Two, and we will be filling capability gaps as defined by the JROC (Joint Requirements Oversight Council) as part of the requirements process. When we roll out the new capability, we intend to do technology refresh as needed in that same development to minimize future changes to our boxes' architecture and thereby preserve affordability. When you make a fundamental architecture change, there's a very long process with the NSA to make sure you don't have a vulnerability. We want to be careful that we don't require ourselves to spend more money recertifying and restudying that architecture. So we'll be doing technology refresh in terms of upgrading processors, and upgrading all sorts of technology. But we would like to maintain stability in the fundamental architecture for some time.
MIL EMBEDDED: To what extent are there requirements on the table or being talked about for coalition interoperability or Non-Governmental Organization (NGO) interoperability?
BAUMAN: First of all, our MIDS program is a cooperative program paid for by five nations: the U.S., France, Italy, Spain, and Germany. MIDS-LVT was that way, and MIDS-J has financial participation from our allies. Our plan is to deliver a tech data package to them at the end of the MIDS-J core radio development, which is coming up soon. We are also working with those particular countries in terms of them developing their own capability, based on our design (or buying our capability).
We also have the U.K.'s Bowman waveform - through formal qualification tests and in our repository. And as part of our enterprise business model, we are making that waveform available to all vendors so that they can add it to the radios they're already selling. We're hoping that Thales and Harris might port the Bowman waveform to their JEM and Falcon III products that we're already buying, which would allow us to buy that capability from existing contracts. We also have a coalition waveform development effort with primarily European allies, and that's just getting underway. Beyond that, we're also looking at a coalition wideband networking waveform tool to allow networking interoperability among the U.S. and coalition partners.
We have some difficulty with taking our waveforms and giving them to everybody in the world. We have an information repository within the U.S., for U.S. vendors, for U.S. government purposes. For security reasons, it's not quite easy to give that code away to our allies. It's not something that we will probably do directly. But that doesn't preclude us from working on a waveform with our coalition partners, and that's exactly what we're doing.
Dennis M. Bauman has been a Joint Program Executive Officer, Joint Tactical Radio System, since 2005. His current job duties include directing all waveform, radio, and common ancillary equipment development; performance and design specifications; standards for system operation; and JTRS systems engineering. Previous positions include Weapons Officer and Qualified Surface Warfare Officer in the U.S. Navy, Software Manager for the Naval Ocean Systems Center in San Diego, Head of the Operational Systems Branch of the Submarine Communications Division, and SPAWAR Program Director for C2I and Combat Support Applications, among others. He earned his Bachelor's degree from Pennsylvania State University and a Master's degree in Computer Science from the University of California at San Diego. For more information on JTRS, email [email protected].
JPEO JTRS
http://jpeojtrs.mil
EDITOR'S NOTE
Group editorial director Chris Ciufo and editor Terri Thorson conducted an exclusive interview with Dennis M. Bauman, Joint Program Executive Officer, Joint Tactical Radio System (JTRS) at the AFCEA West show in San Diego earlier this year. The key questions on their minds surrounded the progress of JTRS - which had just been essentially "rescued from the dead" after a "stop work" order had been rescinded - as well as how COTS and open architectures might benefit the many JTRS product lines. Edited excerpts follow.
