From the Crows' Nest

Ken Miller (00:10):
Welcome to From the Crows' Nest, a podcast on electromagnetic spectrum operations or EMSO. So I'm your host, Ken Miller, director of advocacy and outreach for the Association of Old Crows. Thanks for listening. In today's episode, we talk about open systems architecture and how it's changing the way that the Department of Defense develops and fields new technology for our warfighters. I'm pleased to have on the show today Mr. Rodger Hosking, who is vice president and co-founder of Pentek, now part of Mercury, and Mr. Patrick Collier from the Aspen Consulting Group.

Ken Miller (00:39):
Before we begin, I'd like to thank our episode sponsor, Northrop Grumman Corporation. Northrop Grumman provides full-spectrum superiority. Their innovative multifunction interoperable solutions ensure warfighters have full-spectrum dominance to make real-time decisions no matter the environment or domain. Learn more at ngc.com/ew.

Ken Miller (00:58):
All right, I'm here with Mr. Rodger Hosking. He is vice president and co-founder of Pentek, now part of Mercury, where he is responsible for new product definition, technology development, and strategic alliances. And Mr. Hosking plays an important role in the Sensor Open Systems Architecture Consortium, and I am pleased to have him here to talk a little bit about how the consortium is addressing open systems architecture and the new standards that the consortium is releasing here in the coming weeks. Roger, it's great to have you on From the Crows' Nest. Thanks for joining me.

Rodger Hosking (01:26):
It's a pleasure to be here with you.

Ken Miller (01:28):
So today we're going to talk about open systems architecture, and it's a topic that is near and dear to you. And obviously, you're deep into the Sensor Open Systems Architecture Consortium. And so to get started, I wanted to talk a little bit about the problem that we face because obviously, when we're talking open systems architecture, this is a major shift in how DOD is preparing for the fight. It's a major change in how they do things. I want to talk a little bit about where we've come from. So I was wondering if you could talk a little bit about how DOD historically has been used to developing advanced technology and responding to the threat, and some of the concerns that have arisen over the years about the length of time it takes to actually bring something from development to the field.

Rodger Hosking (02:10):
It's definitely been one of the major concerns and one of the reasons for the open systems architecture initiative was started back, oh, maybe seven years ago or so. It was done because things were taking a lot longer to come up with new technologies solutions to problems, evolving problems, threats, and so forth in the warfighting arena. Government really had to rely on a lot of the big primes traditionally to get these systems put together and then finally deployed, often taking years and years to get them approved, to get them qualified. A lot of paperwork, a lot of new invention went into each one.

Rodger Hosking (02:50):
And each of those platforms tended to be rather unique and dedicated to the one purpose for which the program was initiated. So they were not easily adaptable to other applications or other platforms without starting over from scratch. That was a major problem that was identified by DOD so that new applications could be hopefully addressed better by adapting existing platforms, and one of the ways to do that would be to make those platforms more standardized so that the parts and pieces could be interchangeable and a part could be taken out, and a new part, a new element of the system, could replace it to achieve, let's say, a new application or a new threat or some new kind of signal, for example.

Ken Miller (03:37):
And part of this is because the pace of the threat is increasing so exponentially. It's my sense that obviously, 10, 20 years ago, 30 years ago, the DOD led the next advancement in technology. But today, you're talking it's from the commercial sector, and adversaries are pulling value out of the commercial sector development, and that's putting DOD behind. And so could you talk a little bit about how that shift is from DOD being the leader in advanced technology a generation ago to now it's trying to play catch-up with commercial? And that's of course means playing catch-up with potential adversaries.

Rodger Hosking (04:11):
Sure. And I think there has been, definitely in the last 15 years or so, there's been a shift towards the military trying to harness some of the commercial technologies, some of the wireless technologies, especially, and those have been extremely important for us as a vendor, for example, to use high-speed data converters and FPGAs and other devices that were originally invented for the commercial wireless space, but now could be very easily adaptable to address some really tough applications and the requirements for military and DOD.

Rodger Hosking (04:47):
We've done that. I think most of the vendors have done that. The 5G wireless is another example of a commercial technology that's led to a lot of innovation, especially in the phased array antennas and phased array systems that are very prevalent in the military and defense platforms today.

Ken Miller (05:05):
And you mentioned the reliance on a lot of prime contractors in terms of when changes needed to be made to certain programs. And that, of course, would cause DOD to run into issues of, in a proprietary nature, that certain companies owned a particular slice of technology that they had to stay within as they tried to adapt. So could you talk a little bit about some of the struggles that DOD has had with this?

Rodger Hosking (05:30):
Sure. I think the invention of the technology, the intellectual property that the primes have put into a particular platform, that's something that they want to protect and they want to carry forward as a competitive advantage for their next program. So opening everything up along the lines of the open systems architecture is not necessarily inherently intuitive to the big primes. They would probably prefer to continue with the proprietary nature of things. However, what's changed is that with SOSA, the intellectual property is protected in that the functions within a SOSA system are defined only in terms of input and output and not what's inside of the element or inside the box. It's called the gray box concept where it's very well-defined what it does and how it interfaces, but the magic that goes on inside the box does not need to be disclosed, just its function. So that preserves some protection for investments that need to be paid for one way or the other. And so I think the primes are on board with that concept as a compromise to what was the old, traditional way of doing things.

Ken Miller (06:42):
I was wondering if you could talk a little bit about SOSA as a consortium and what role it plays in driving additional resources to development of technology.

Rodger Hosking (06:54):
I think one of the big missions is to make new technology insertion less expensive and much faster to create. And that is by creating a smaller set of standardized modules and interfaces rather than the whole gamut of let's say OpenVPX, which has tremendous varieties and flavors. So by standardizing on the hardware elements, and then by making those hardware elements and their interfaces well-defined, you can insert new technology by taking one element out of a system and replacing it with a new element that has a new algorithm or some new technology or some new target classification built into it without having to start over again and build a whole new system around that new application. And that's really the key to what the SOSA initiative is really all about is to make things happen more quickly. It's to inspire innovation among multiple vendors so that the vendor with the best solution... and that, of course, will give the warfighter this new technology that he needs more quickly in a more timely fashion than before so he's better able to counteract whatever the enemy might be throwing at him.

Ken Miller (08:11):
Now, you're the co-founder of Pentek, and you're now with Mercury. And so you're familiar with the embedded systems industry. And so I was wondering if you could talk a little bit specifically about how SOSA benefits your sector of the defense industry for embedded systems.

Rodger Hosking (08:27):
We are still considered a small business. We're a little bit bigger than we were before we were acquired by Mercury a few months ago, but we're still considered small business. And I think the opportunity for small businesses to play a bigger role in defense procurement processes will then be enabled by this replaceable element, replaceable standardized interfaces on the elements within the systems. So the primes will now then look to vendors, and they all look to suppliers and sub-tier vendors for pieces of their system. I think this is going to open up that activity so that the smaller companies will be able to compete for a quicker response to supply the prime with the part that he needs, as opposed to having a prime develop it himself and perhaps take two, three, four times longer than they could obtain it out of the vendor community.

Ken Miller (09:25):
But if the prime is relying more on small businesses and embedded systems manufacturers and so forth to develop the technology, how do they then protect the intellectual property and the proprietary nature of their work? Could you talk a little bit about how SOSA and this effort seeks to keep everyone's interests aligned moving forward with technology development?

Rodger Hosking (09:47):
Sure. We make platforms that are highly configurable. They contain typically FPGAs. They're controlled by software and they can do a tremendous range of different applications at all different frequencies and bandwidths and algorithms. And all of our customers will customize the FPGA, will customize the software that drives it and the control structures that make it do exactly what they need to do. So that intellectual property remains with the system integrator or the prime contractor who's putting it together and interacting with all other elements of the system to create the final, deployable package that he delivers to the government customer. So we are not involved at that level of system integration. We help the prime do the system integration by supporting his efforts, but we are not directly involved in creating his work product. That belongs to him.

Ken Miller (10:42):
As I understand it, SOSA is preparing to release its standard 1.0, I believe, in the coming weeks. And I was wondering if you could talk a little bit about what industry and the defense community can expect when the standard is released.

Rodger Hosking (10:56):
Sure. It's called the SOSA Technical Standard 1.0. That is the official document that describes the whole SOSA architecture and reference design. What it will do is it will make the standard specification document of exactly how each of the elements within the SOSA platform shall be made and the conformance specifications that they shall have to comply with in order to be fully SOSA conformant. And I know you'll be talking about that a little bit later on with Patrick. But the whole idea here is to have a government procurement when referencing that a new program shall be SOSA conformant, or to have a high degree of SOSA content. That will then drive the procurement and the win process for winning a particular program by a prime. The primes with higher content of SOSA elements are more likely to win the program than those with less content. And that will immediately put a very sharp point on what people are going to be spending efforts on because they want to be part of the winning team.

Ken Miller (12:10):
So SOSA is DOD-wide. It's going to affect systems across the services. But each of the services are also involved in their own standards efforts. Army, Navy, I think Navy HOST, Army CMOSS, Air Force has one. How does SOSA tie into the service standard efforts? And is there overlap or is it complementary? Could you talk a little bit about how that interacts?

Rodger Hosking (12:36):
Sure. Going back to when the open system architecture concept was initiated by DOD back seven, eight years ago. Each of the three services came up with their own vision of what that meant for them, and they each created standards like the ones you mentioned. It turned out that maybe about three years ago, the standards seemed to have a lot of common elements and there seemed to be some themes like OpenVPX, for example. And unlike a lot of the things that were in the software, the REDHAWK software, for example.

Rodger Hosking (13:08):
These common elements were recognized. And each of the three services along with DOD said, "Hey, you guys are doing a lot of the same kind of standardization in terms of what's driving your vision. Let's unify this into a single combined standard called SOSA so that we're all working on the same page with the same set of rules and standards." It was definitely something that everybody said, "We did our own thing, but you're right. It's time for us to get together to make a more efficient standard that will be across the three services, thereby helping each of the three services acquire perhaps better value for a standardized platform that might be used in another service."

Ken Miller (13:55):
We were just having a series on this podcast on Joint All-Domain Command and Control and the DOD vision for having a unified network connecting different sensors across the services, across domains, being able to gather, process, distribute large sums of data using AI. And a lot of that got into this idea of compatibility of systems, interoperability of systems. What role do you see SOSA playing in implementing DOD's vision of JADC2?

Rodger Hosking (14:27):
I think it'll definitely happen. One of the things about communicating across different platforms that we've been directly involved in for years is the VITA 49 initiative, which is the radio transport protocol that will allow different platforms to communicate in a standardized way with a standard protocol that will be understood by different applications, whether it's [Sig Ent 00:14:51], [E Lent 00:14:51], EW. The same protocol will allow each application to pull the data in, know where it came from, and then be able to act on it consistently across a wide range of different platform applications and across different services. So that's a major benefit. Instead of having the redundancy of everybody collecting the same signal in their own antenna, the signals can be collected in a common or a shared antenna platform and then distributed through network connections to wherever they may need to go. And that'll be a big part of this platform you're talking about.

Ken Miller (15:27):
Earlier, you mentioned OpenVPX standards, and they are already in use. And I was wondering if they're already in use, then why is there another standard being released or what is the need for additional standards?

Rodger Hosking (15:39):
The OpenVPX is extremely prolific in terms of its number of profiles. It's just hundreds and hundreds of different profiles. What SOSA has done is chosen, say a dozen of those for 3U and 6U VPX for the board profiles that will then be the ones that SOSA conformant platforms will use. And there are extensions to each of those selected profiles to make them flexible so that they can do different things for different applications. It's kind of a working ongoing compromise between trying to get everything done as much as possible in terms of application space, but then trying to do so with as few different module profiles or... they call plugin card profiles in SOSA... as possible for that standardization effort.

Ken Miller (16:32):
So you have 1.0 standards coming out later this summer in several weeks. What is the next step? I mean, obviously we talked about conformance, but are there other levels of standards coming out looking into the future over the next year?

Rodger Hosking (16:46):
The areas that still need more definition are going to be in the software and the interoperability on the software level. And I think that that's moving, but it's a much tougher job because there are so many different aspects to it and people have different topological and architectural visions of how that should be laid out. And those discussions are ongoing now in the software through working groups. But that will probably be the biggest significant amount of effort that will take place next after the Technical Standard 1.0 is released.

Ken Miller (17:17):
And so you mentioned that in the future with SOSA 1.0 standards, in order to win a bid for a contract, there's going to be great attention paid to the amount of conformance to the 1.0 standard. Could you talk a little more about the flow down requirements are going to stem from SOSA's 1.0 standard in terms of how the services and DOD start out in building the requirement for a new system to respond to a threat? So we know that a company may to conform to a standard on one end. But on the other end, you're going to have the services and the COCOM saying, "Okay, we need a capability to do this. We need a technology solution. Here's a requirement." So how does the SOSA standard impact the requirement formation?

Rodger Hosking (18:05):
I think it actually starts at the funding level. I think a proposed new program, a proposed new platform that's seeking DOD funding will win that funding more readily when it's a SOSA-based program. That's the start. After the program is funded and acquisition and request for proposal, request for bids are underway, then there will be a scoring metric for each of the responses to the request for proposal that will be evaluated and scored. The weighting of the scoring will be definitely influenced by the level of SOSA content in the respondent's proposal. So it's working from both ends, the way it starts, and then the way the bid proposals are weighted, scored, and then finally awarded. That will then drive the procurements that the prime who wins the award will then have to flow down those requirements to the vendor community that supplies that product.

Ken Miller (19:06):
And being a part of the SOSA Consortium will key you in to opportunities for joining teams on various contracts. Correct?

Rodger Hosking (19:17):
Exactly. It also gives companies the vision of where the vendor community must be headed in order to win business going forward. And so being part of those discussions in the working groups are critical not only to understanding where it's going, but also to influence it in a path that makes more sense for the type of business that vendor is in. And if he can successfully argue that this is a good thing, and everybody agrees, then he's moved the effort forward by making it so.

Ken Miller (19:49):
So who can join SOSA? Any company?

Rodger Hosking (19:53):
Yes. As long as it's a US citizen. That's the requirement. So there are certain international companies that have divisions in the US or have personnel that are in the US have cleared that can participate. But the simple answer is you have to be a US person. And that is not a restriction for an organization like VITA, for example, which is worldwide with no such restriction. There's a lot of overlap in the membership between VITA and SOSA for the US members of SOSA. So it's a very synergistic relationship, but one which is kept separated by that restriction on us persons for the SOSA group.

Ken Miller (20:37):
So how is your company Mercury now and formerly Pentek, how is your company involved in SOSA? What is it doing to move that consortium forward?

Rodger Hosking (20:46):
Well, we do have Paul Mesibov, who's our VP of Pentek now and Mercury, is the co-chair of the hardware subcommittee of the technical working group. We also have Gina Peter, who is our director of marketing here, is a co-chair in the SOSA outreach group, which is a marketing organization. I am doing presentations like this, papers and webcasts and so forth to do some promotion of the SOSA initiative because I really do believe in it. So we are quite heavily involved. And for a small company, we represent a lot of contributions to the SOSA initiative.

Ken Miller (21:34):
I appreciate your time. Thank you for joining me. It was a great discussion. I look forward to talking with you again soon.

Rodger Hosking (21:39):
Ken, thank you very much. It's been a pleasure for me.

Ken Miller (21:42):
Thank you. At this time, let's take a short break to hear from our episode sponsor, Northrop Grumman Corporation.

Speaker 3 (21:50):
Providing full-spectrum superiority across all domains. That's defining possible. Giving warfighters the freedom to act across the spectrum, especially in highly contested battle spaces, can seem impossible. At Northrop Grumman, we've pushed the boundaries of possible across the spectrum for decades. Today, our cutting-edge, interoperable, multi-function technologies are a revolutionary leap in spectrum dominance. How revolutionary? Imagine detecting the precise location of an adversary long before they ever detect you. Or better yet, denying or degrading an adversary system without them being able to do a thing about it.

Speaker 3 (22:26):
Your freedom to shape the spectrum is an overwhelming advantage in every domain, an advantage made possible by Northrop Grumman's unique, software-defined, open, safe, secure architecture solutions. It's all part of our commitment to ensure our warfighters have full-spectrum dominance to make real-time decisions no matter the environment. That's defining possible. Learn more at ngc.com/ew.

Ken Miller (22:52):
Welcome back. For our next segment, we take a deeper dive into the new Sensor Open Systems Architecture Standards 1.0 on the horizon, and look at the issue of conformance. And I am pleased to be here with Mr. Patrick Collier. He is a senior open systems architect and systems engineer at Aspen Consulting Group. Patrick focuses on the development and use of open architectures for both space and non-space application. And Patrick, your experience spans just about every aspect of open systems architecture here. And so I'm really thankful that you're able to join me to talk about an issue that really, I don't think gets enough airtime. We talk a lot about compatibility, but we really don't talk about conformance to the standards and what that's going to do to industry and some of the challenges and opportunities with that. So thank you for being on from The Crows' Nest.

Patrick Collier (23:41):
You're welcome. Thank you for inviting me.

Ken Miller (23:43):
All right. So I was talking to Roger earlier, obviously about the open architecture hardware standards and the importance that they're going to be playing in building an adaptive force. We talked a little bit about obviously the role that that plays in JADC2. SOSA Standards 1.0 are coming out in a matter of weeks. From your perspective and that of conformance, what will be the next step once those release in terms of what industry must do to meet some of those standards?

Patrick Collier (24:12):
Industry will be required to develop a set of verification matrices, or even just a verification matrix. So there's the program. The conformance program itself has documentation that say somebody like Pentek or another supplier wants to bring a product or sets of products to SOSA or to SOSA verification authorities more specifically for verification and for certification through the open group. So the industry will have to develop the documentation and go through the process of getting their product verified with an independent organization, and then having that verification certified by the open group. And then once that's done, then they'll get essentially, for lack of better words, a stamp of approval saying, "Here you are now, SOSA conformant."

Ken Miller (24:56):
So once they're SOSA conformant, then that allows them to bid on the next contract regarding that system. But it only pertains to that one particular system. They can't do multiple products at a time.

Patrick Collier (25:08):
Well, they can. SOSA chose [inaudible 00:25:11] and that reason is having that independent verification certification. So when a supplier goes through the process, they'll have a SOSA conformant product. It doesn't mean it's for a specific program, or they can then go out in bid for a contractor. They could have sets of SOSA products that might be general to a degree or that might sit for more than one product. Although I think we do expect acquisition authorities or the user community to want to specify you will generate a SOSA conformant product per contract. So a supplier may bid on a contract, and as part of that contract may go through the verification certification process. Independently, like I said, they may do it on their own.

Ken Miller (25:49):
So how long does this process take? If a company is wanting to become conformant, it seems to be there's a period of measurement and verification, so forth. How long do that period of time?

Patrick Collier (26:00):
I think... and this is a rough estimate on my part... probably say 60 days to go through verification and certification.

Ken Miller (26:09):
And so what does that do in terms of the overall bidding process? Does this extend the bidding process at all that a company has time to respond because if they have to go through this conformance process beforehand, or as a part of, how does that affect downstream the contracting process?

Patrick Collier (26:31):
I don't think it's going to affect the contracting process. Like I said a minute ago, it's more than likely that process will be rolled into contracts I think initially before we get to the point where we have set SOSA conformance products, and you have a robust registry where users can go and look for existing product. I don't think it's going to cause any concern. Hopefully from a supplier perspective, say, "Okay, well, we want to bid, but now we have to do all this stuff first." I think what you're going to see is the user community requesting it.

Ken Miller (27:00):
And so what are some of the best practices or what are some of the recommendations you have for a company wanting to start this process in and obviously play a role in [inaudible 00:27:10]? What are some of the steps that they ought to be taking today even before the standards come out or certainly after they come out, some of the best practices or next steps that you would recommend?

Patrick Collier (27:20):
I would break that into more than one category. So they are existing suppliers that are already producing SOSA-aligned products. Then the alignment term is used simply because there's not a program in existence right now, a conformance program. So best practices would be to make sure you're adhering to their requirements to the best of your ability, independent of potentially what a customer might want. Or even at this point, if you're listening to a customer, making sure you understand what the customer needs and that you're adhering to the requirements.

Patrick Collier (27:49):
For those that are new, you want to make sure that you look at what the SOSA standard is requiring, and then what your customer needs. So you make sure that that's an alignment. So when you go in for verification and certification, you're not missing anything that might be key for that product and for what the user needs.

Patrick Collier (28:07):
There's also making sure that you go through the conformance documents, like the certification policy and the certification guide. The latter's actually in process right now for approval and distribution. And that lists out all the documentation that the supplier will need to have ready when they go to a verification authority.

Ken Miller (28:24):
And all that would be available through SOSA. So if you have questions about this, you can go through SOSA and get all that documentation.

Patrick Collier (28:30):
Correct.

Ken Miller (28:30):
I was talking earlier with Roger, and obviously, SOSA is DOD-wide. And we were talking a little bit about how that interfaces with some of the service-specific standards that have been developed over the recent years. You've worked on actually many of them. How does the notion of conformance, how is that going to interact with standards and conformance of standards with service-specific efforts?

Patrick Collier (28:54):
It depends on how closely SOSA is aligned with the other standard. A good example of that would be CMOSS and SOSA. CMOSS and SOSA from the outset have made sure that they're essentially in complete alignment. Now, there are some things that CMOSS is more specific about, things that they want from their supplier base, say than SOSA is, and I'm saying that generally because I've only seen a small set of documents.

Patrick Collier (29:20):
But CMOSS and SOSA have made sure that from a hardware perspective, that they're in complete alignment. So if you have a SOSA conformant plugin card, I would say that you're essentially in alignment and you're good to go with CMOSS. HOST I think is not as close as CMOSS and SOSA. All three services have worked hard to be in alignment, but there are a few differences in HOST just like there are a few differences in CMOSS where you may see something that is HOST-specific that you don't see in SOSA. I would say high level that if you're SOSA conformant, you're probably more than 90, 95% there for the other standards that you can work. [inaudible 00:30:02] like I said, the intent between them to say, "Look. We want to take a card that is Air Force and it's SOSA, and say the Army wants to use it." So that's been the going in proposition.

Ken Miller (30:12):
Do you see the SOSA standards and the conformance effort as accelerating some of these other efforts? Obviously, you just talked that CMOSS and SOSA are almost completely aligned, but maybe HOST is a little bit further behind. Do you see the conformance effort to accelerate standards across the services?

Patrick Collier (30:32):
The [inaudible 00:30:32] is there to make sure that you have conformant products. The effort between the Army and the Navy and the Air Force from the outset with SOSA was to ensure that there's alignment between all of those standards. And alignment has been achieved. But like I said, there, there are specific pieces that are different for each one. So you may have something that's very Army-specific that's different than what SOSA needs, which is not necessarily a hardware thing that could be something different. And then the same thing for HOST. But the evolution of all of this is to get to that point where we have a common baseline hardware architecture that everybody can draw from.

Ken Miller (31:10):
So the standards that are coming out, it's a very big development. It's a great milestone. And it sounds like everything is moving along exactly the way it should be. But from your perspective, what is one thing about this that keeps you awake? Is there any particular challenge you see that the community really has to make sure that they pay special attention to?

Patrick Collier (31:30):
My biggest concern right now is to make sure that we work to continue to develop what those aspects of these standards that are important for the government. And a lot of those, some of those happened to be reusability of the hardware elements, or the terms we use in SOSA, or being able to refresh technologies quickly. That's the reason why we've done what we've done in SOSA and the same for CMOSS and HOST is to ensure that we have this common baseline product architecture that we can use.

Patrick Collier (32:00):
So the conformance piece, it concerns me because I want to make sure that everybody's happy or at least content that we can get the products that we need in order to do the job that we have to do, and that industry is content with their position in developing the products they can, not have a large concern about losing IP and stuff like that. And the conformance program is there to make sure that that happens. So I really want to make sure the conformance program is successful and execute those desires.

Ken Miller (32:26):
All right. Well, thank you Patrick for joining me. This is great information, and we are going to be covering this topic again throughout the fall, particularly once the standards come out. So hopefully we'll have an opportunity to talk again on the other side of the release of the standards, and discuss a little bit more about how that effort is going. But I really appreciate your time and giving us some insight into what's on the horizon with the standards coming out later this summer. Thanks for joining me.

Patrick Collier (32:51):
Thank you very much for inviting me. I appreciate it.

Ken Miller (32:53):
That will conclude this episode of From the Crows' Nest. I'd like to thank my guests, Mr. Rodger Hosking from Mercury and Mr. Patrick Collier from the Aspen Consulting Group. I also want to thank our episode sponsor, Northrop Grumman Corporation. Northrop Grumman's multifunction interoperable solutions create full-spectrum superiority for our warfighters across all domains. Learn more at ngc.com/ew.