How would you describe your role in the SOSA™ Consortium, how do you participate?
Right now, I am serving a second term as Chair of the SOSA Technical Working Group. I am also the primary representative from the US Army C5ISR Center on the SOSA Steering Committee. Prior to serving as the chair of TWG, I was Vice Chairman of the Hardware Working Group.
Since you do have that back history with SOSA, going back to 2015, how did you first get involved? Was C5ISR approached by SOSA, or was it the opposite? How did you combine forces, as it were?
When SOSA was initiated, the C5ISR Center had already been working on CMOSS for probably two years. My boss, Ben Peddicord, had spoken with Ilya [Lipkin] and Patrick Collier about their concept for SOSA. We realized right away it was a match made in heaven. While we were initially focused on ground vehicles and SOSA was initially focused on airborne pods, we both realized —in one way we like to say it— that “architecture is independent of altitude.” Regardless of whether [a capability is] in a pod, on a ground vehicle, surface ship, a sub, it doesn’t matter – it can work the same way.
We realized this was a good opportunity for us to collaborate, to align our architecture activities so we could benefit from economies of scale, reuse across services, and have a better opportunity to influence where industry is going.
With CMOSS already up and running for a couple years, was it CMOSS’ interest in VITA standards that brought OpenVPX into the SOSA activities, or was that already agreed upon?
The initial foundation for the hardware portion of the technical standard was a combination of what CMOSS had already done with 3U OpenVPX, as well as what HOST (Hardware Open System Technology) had done with 3U and 6U OpenVPX. So based on a look at what both standards had done and areas that differed, we aligned them, and that served as the foundation for the hardware specification. We continued to extend that, adding additional profiles based on gaps identified within the Consortium.
Have you seen a sea change in programs and requirements for open standards since the Tri-Service Memo and the EW&C Memo?
Yes, there’s definitely been an increase in momentum in the last year or two. Besides the Tri-Service Memo and the EW&C Memo, this year’s NDAA House Armed Services Committee report directly calls out CMOSS and SOSA, a huge win. From an Army acquisition perspective, the EW&C Memo established the requirement for programs to use CMOSS where applicable. In addition to that, recently an Abbreviated Capability Development Document (A-CDD), the CMOSS Mounted Form Factor, was approved, establishing a requirement for prototyping for a common chassis including EW, Mission Command, PNT, and Comms. The Network Cross Functional Team has been a strong advocate of CMOSS. Through their technical exchange meetings they have released RFPs for prototyping activities. In general, the answer is yes, there has been an increase in terms of acquisition community involvement and actual prototyping activities that make CMOSS a reality and hopefully gets it to our soldiers in the near future.
Have you seen a change from having to be in evangelizing mode to having open standards become de facto requirements?
Yes. It’s nice to be in a meeting and not have to advocate for open standards. Now our senior leaders advocate for [open standards], so our role can be more technical support, helping to write requirements and as vendors conduct engineering, making sure they apply the standard correctly. It is nice not to have to convince anyone anymore.
You’ve been very active not just in CMOSS but in VICTORY and MORA, too. Does that work intersect with SOSA or is it parallel?
All those activities directly intersect. We have intentionally invested a lot of time and energy in the SOSA Consortium. One thing CMOSS was not resourced to do is operate our own standards body. That’s why when Ilya and Patrick were looking to stand up the SOSA Consortium, we thought it was an excellent opportunity to the team because it provided a venue for us to get broader participation, not only from the other Services but from academia and industry. Even though we retain the CMOSS name, we heavily leverage the SOSA Consortium and points to the SOSA Technical Standard wherever possible as we evolve and maintain the specification. To that end, we have worked very carefully to ensure SOSA and CMOSS are aligned wherever they overlap. The OpenVPX profiles are aligned between SOSA and CMOSS, the CMOSS and HOST ones serve as the initial foundation. In terms of MORA, we got that adopted in the SOSA Technical Standard for the 2.x modules. As we continue to refine the SOSA Technical Standard, I’m hopeful that other aspects of CMOSS will get adopted. For example, as we define the Navigation Data Service and Timing & Frequency Service modules, I hope that we would at least consider adopting what the VICTORY community has done. There are Army PNT capabilities that are already being developed and maintained by PM PNT, so it would be great to be able to align and leverage those across the Services. One question we always get is: why the difference? Why are there two, CMOSS and SOSA? There are two answers to that. One -- certain aspects of SOSA that were initially out of scope for CMOSS. We’re looking at the value-added and the need, and we’re bringing them into CMOSS as required. Two -- since CMOSS is Government-defined, it allows us the flexibility to react more quickly. So if we are supporting a program and there’s a gap that needs to be resolved right away in order to meet a milestone, CMOSS can provide a solution. Our intent is always to bring such a change back to the SOSA Consortium to be adopted, or extended if the group comes up with a better alternative. But one of the risks, since SOSA is a consensus-based standards body and Government cannot dictate requirements, is that we are on equal footing with industry. Until now we’ve worked hard to make sure we come together through consensus so we are all on the same page. But in the event the Consortium does something that the Government doesn’t agree with or where the Government wants to provide additional specificity, that’s where we would do that under the CMOSS banner.
What is the interest from international partners in CMOSS and SOSA?
We have been working with our foreign partners and there is significant interest in leveraging what has been done with CMOSS and SOSA to the point where [our partners] are starting to reference the same standards for their acquisitions. The more folks build to and use the standard, the larger the ecosystem and greater the potential economies of scale. That’s why CMOSS has tried to make everything publicly releasable where possible, so the standard can be fully shared with foreign partners. We appreciate the fact that the SOSA Technical Standard is public. What we have not yet figured out is how to get our foreign partners more involved in the actual specification and development process. We have had those discussions with The Open Group and are collaborating with our foreign partners because it is something we want to pursue.
In terms of specific applications, what does SOSA bring to PNT, as an example?
From a a PNT perspective, there are multiple aspects. Previously —before CMOSS and SOSA‑ PNT was provided by each stovepiped system. So you had redundant hardware and redundant GPS receivers, which meant you were not making efficient use of your platform space and power. Sharing PNT services is important. That becomes increasingly important as we move to more assured or resilient PNT; where systems are more complex, they’re more expensive. If a function is not something each individual system provides, then it is ideally shared as service on the platform. On top of that, by aligning the PNT approach across CMOSS and SOSA we can define the same interfaces for the Navigation Data Service and Timing and Frequency Service modules, allowing us to leverage investments from each of the services to make sure we get the most capable PNT capability to the soldier, especially given how critical it is to operations. So that’s an example of how CMOSS and SOSA are critical enablers for future PNT.
Your point being that once A-PNT becomes a dedicated shared service the standardization of services becomes all the more important
Exactly.
What have you found most satisfying about the SOSA process and where we are now from where it started?
The most satisfying part has always been working with the people in the Consortium. There are a lot of smart folks, top people in their fields, so having the opportunity to work with, benefit and learn from their experience has been great. I learn something new every day.
In terms of lessons learned are there any frustrations, opportunities for improving the process, or over-the-horizon goals you’d like to share?
One of the biggest frustrations or challenges has been getting agreement on the scope for SOSA. That’s a trade between providing additional specificity in order to get the reuse and portability that the Government desires, without stifling innovation and preventing the reference architecture from being used in certain systems. Finding that line has been a challenge; there are different perspectives on where that line should be drawn. The Consortium is still trying to find where that sweet spot is.
Any suggestions for how to improve that process?
From a Government perspective, it is identifying which subsystems we would procure or upgrade independently, which in turn define the key interfaces. If there’s a business case for something we wish to rapidly integrate, rapidly upgrade or share across services and programs, that drives both key interfaces and level of specificity for efficient reuse and portability. As the acquisition community becomes more and more involved it might help further inform where those lines should be drawn. Acquisition offices will either be able to do or not do what they need, so we’ll have to learn and adjust.
Once Rev 1.0 of the SOSA specification gets finalized and out into the world what impact are you expecting or hoping to see as a result?
I’ve heard there are programs that want to use SOSA but can’t refer to a draft technical standard; they need the final technical standard. Hopefully getting the standard out will encourage those programs to use the SOSA Technical Standard, so we can continue to build the user community and foster adoption. I expect the release of v1.0 will be an impetus for more programs to adopt SOSA and by association CMOSS in actual solicitation and requirements documents.
What do you see as the biggest hurdles or obstacles for wide acceptance of SOSA? Is it a technical issue or a philosophical issue? Any challenges you see in fulfilling the promise of SOSA?
What we saw in CMOSS and may also hold true for SOSA, the biggest problem is the acquisition approach. We’re fundamentally changing how we build and procure systems. The acquisition community needs to get comfortable with that. We’re introducing dependencies where they didn’t previously exist, in order to be able to reuse and capitalize on investments others have made. We’re also inherently assuming more risk on the Government side because we are being more prescriptive in terms of interfaces. We only want to prescribe to a certain point, because if anything goes wrong, we’re accountable. We want to still make sure that industry can do what they do best: build systems that perform while maintaining portability, upgradeability, and interoperability. The biggest challenge for me is getting the acquisition approach right. From an Army perspective, what’s really helped is having senior leaders who realize the importance of open standards.
Is there anything you see that the SOSA Consortium can help in communicating to that community?
[SOSA] Business Working Group products like acquisition guides will help. Another thing I’m always fighting is to make the technical standard stand on its own. The less it has to be interpreted the greater the chances of success in terms of achieving reuse. If a standard can be interpreted in different ways, it will be interpreted in different ways, creating interoperability challenges. We are working to make sure the technical standard is clear and at the right level, so that it provides acquisition guidance that helps the acquisition community use it in solicitations and capability development.
What’s the biggest misconception people have about CMOSS?
If I could go back to the start, I wouldn’t call it CMOSS; it’s constantly confused with the transistor technology! One of the misconceptions we’ve seen is that people sometimes think CMOSS and SOSA are material solutions rather than standards. There is no official CMOSS chassis or CMOSS card. It’s meant to be a standard that everyone can reference to create an ecosystem of chassis and cards. Stakeholders now realize that. In the early days people would ask, “How do I buy the CMOSS chassis?” It doesn’t work that way.
How do you like to express the relationship between CMOSS and SOSA?
We want CMOSS and SOSA to be consistent in all the areas where they overlap in terms of scope. In any area where they address the same thing we want them to be aligned and in lock-step. There may be areas that are out of scope for CMOSS and in scope for SOSA, or vice versa, but moving forward we wish to minimize that. If you visualize a Venn diagram of CMOSS and SOSA, we are trying to bring the circles together moving forward. For example, one of the things we’ve done in CMOSS is not take a firm position with respect to selecting a single software framework. We encourage folks to use existing frameworks, and we’ve identified some frameworks, but we allow them all because as you get to different mission areas the frameworks can have different requirements. Thus it may not be practical to have a single framework to rule them all. Moreover, each framework usually comes with a library of capabilities, so it’s important to make sure we can reuse those existing capabilities. So, showing how software frameworks can align with and leverage the other layers is important.
REDHAWK is an excellent example. SOSA has shown how REDHAWK can operate within a SOSA sensor, but REDHAWK is not explicitly specified in the SOSA Technical Standard. Conversely, for some CMOSS acquisitions we’ve directed vendors use REDHAWK for certain applications. An example of something that’s in SOSA but not part of CMOSS, is in-band network-based system management using interfaces defined by VICTORY and MORA. For the most part, we have found them to be sufficient, so we have yet to require out-of-band system management interfaces defined by VITA 46.11 and HOST. That’s not to suggest that we can’t use a card that provides those, we just haven’t explicitly required that. Moving forward, if we encounter a gap those interfaces address, we may get more prescriptive, but in the meantime those are an optional capability. These examples show pieces on the periphery of the two [Venn Diagram] circles where SOSA and CMOSS overlap, which may come within scope as we identify future needs.
At the end of the day, we’d love to not have to refer to two standards, because that can cause confusion and force us to explain how they overlap and differ. It will take time to get to where we need to be. That said, we always leverage the SOSA Consortium as the standards body to move CMOSS forward. The Consortium is invaluable, providing a forum, access to industry, academia and a wealth of collective knowledge.