How did you first become involved in The Open Group SOSA™️ Consortium?
I started my career at the AFRL Research Space Vehicles Directorate at Kirtland AFB, Albuquerque, NM. With respect to how I first became involved with standards, I was a co-founder of an effort called Next Generation Space Interconnect Standards (NGSIS) with a colleague from NASA JPL, an umbrella organization that developed two separate standards. One was called SpaceVPX. SpaceVPX became a baseline standard for all space applications, like an OpenVPX for terrestrial applications. The other standard was the RapidIO Space Device Class. This was an effort with the RapidIO Trade Association. Just like SOSA, the NGSIS/SpaceVPX/RapidIO Space Device Class efforts had input from both Government and industry.
When you mention SpaceVPX, when you were starting those efforts, were you already aware of the VITA suite of open standards?
Yes, we were all aware of the VITA suite of standards. SpaceVPX, under NGSIS, is its own VITA standard. There was a group of us developing the RapidIO Space Device Class, and everyone mentioned they were already using OpenVPX. We agreed it would be ideal if we could develop a related standard for space, so I went to the VSO and presented a proposal for starting a working group within the VITA Standards Organization (VSO). That working group became VITA 78. We used OpenVPX as a baseline from the start.
Was that process your introduction to the model of consortium-based standards definition and maintenance?
Yes. The development of SpaceVPX and RapidIO was my introduction to standards. It all started in 2010. In 2016, I was transferred to NAVAIR at Pax River, where I began working on the HOST standard. HOST already existed, but I was brought in to help mature it.
Was that in part because of your involvement and familiarity with open standards?
Yes, we had started to develop the SOSA Technical Standard while I was at AFRL. Bob Matthews, the IPT Lead at the time, was working with the FACE Consortium. He asked me if I wanted to transfer out and work with them on HOST.
Is that when you first met Ilya Lipkin, was he already involved?
I first met Ilya while I was with the AFRL Space Vehicles Directorate, Kirtland AFB. After Ilya got involved, we began work on the first documents that would become SOSA. Others from the Air Force, Army, and Navy were also involved, including Bob Matthews from NAVAIR, John Bowling from the Air Force, Ben Peddicord, and Jason Dirner from Army CMOSS. We interacted with the FACE™ Consortium and set up the SOSA Consortium to incubate under The Open Group FACE Consortium. After that, [interest and momentum] started to build so we did a kickoff for the SOSA Technical Standard. All the Services were represented at the kickoff because everybody was already doing HOST, CMOSS, FACE, and other standards work together, so we agreed to work together rather than do things independently.
From NAVAIR you went to Harris?
Yes, from NAVAIR, I moved to Florida to work for Harris, now L3Harris. Bob Matthews, who had transferred out of NAVAIR before me, was at Harris, and invited me to work with him. I was there for a little over two years, after which I started working with Aspen Consulting Group supporting C5ISR. Aspen wanted me to continue to work on the SOSA Technical Standard and CMOSS, and to help with the overall standards effort.
Were you interested or involved in the conformance process from the very start?
No, I wasn’t involved in conformance at the beginning. I was mainly involved with hardware and electromechanical interfaces. John Bowling, who was chair of the Business Working Group (BWG) at the time, needed a volunteer to run the Conformance Subcommittee. Before we re-structured the organization, the BWG included conformance. So, I volunteered to help stand up the Conformance Subcommittee, and after the restructuring, John asked if I would stay on and run the conformance activity.
Since a main raison d’être of the SOSA Technical Standard is interoperability/interchangeability, conformance rises to one of the highest levels in terms of the opportunity and success of the standard. Were there models of how other standards had approached conformance that inspired your approach, or did you start with a clean slate?
It’s a little bit of both. The Open Group person who was helping us do hardware was also involved in the FACE Consortium, so initially we looked at whether The Open Group had a conformance verification/certification process in place. They did for the FACE Consortium, and we are basically using that same process. The SOSA Conformance process does differ somewhat from the FACE Conformance with respect to the template, because FACE involves software only. With the SOSA Conformance, we have hardware pieces to verify and certify. There’s a vast difference in terms of the responsibility for verifying and certifying hardware versus software. One example is the challenge of setting up a Verification Authority that can verify different types of hardware, whether it’s a plug-in card, or another type of hardware element, which can be anything. If somebody has an entire subsystem they want to incorporate, it necessitates the SOSA Conformance process be quite different than that used by the FACE Conformance. In that sense, we are starting from a clean slate, at least regarding how The Open Group was doing the FACE Conformance.
I’d imagine that one of the benefits of bringing The SOSA Technical Standard into an established standards management organization like The Open Group, among a wide variety of reasons, was that they already had an infrastructure and processes in place that you could leverage and modify as needed.
One of the primary motivations for joining The Open Group, besides offering the experience and the opportunity to incubate under the FACE Consortium, was the fact that they provide infrastructure for managing day-to-day operations. That enables the ability to focus on the technical, conformance and business issues. The Open Group also helps manage configuration and development of the standard, with the added benefit of being able to distribute copies of the standard to people without having to pay for each copy. Another big thing is having someone to help manage the health and status of the initiative while we work on the critical technical parts. Also, regarding the conformance piece, the Government wants Third Party confirmation that a supplier has adhered to the standard with respect to verification and certification. That’s also a big part of the partnership value proposition because it ensures the SOSA customers actually get what they paid for.
How do you refer to the SOSA Conformance process - is it a plan?
Yes, you can call it a plan. More appropriately, we refer to it as a program. There are different pieces to it. There’s a policy document that provides some guidance, but there’s also a Conformance Guide, which explains in detail how to prepare a candidate system or component for verification and then certification.
One of the criticisms against OpenVPX, as successful as it’s been, is that it was an open standard that allowed suppliers to define their own profiles. Since vendors naturally have the tendency to look out for their self-interest, how did you ensure that the SOSA Technical Standard would not replicate that history?
From a hardware perspective, industry was already invested in using VITA standards and developing products based on those standards. VITA actually started with the Army and the Navy, but eventually everyone adopted VITA since that’s what industry was using. The approach we took was to reflect on those things that are important to us. What you see in the standard focuses on technical principles and quality attributes. We wanted to down-select to a subset of profiles that would maximize the interchangeability or portability of the SOSA building blocks. That ensures the ability to take a given hardware component and re-use it for another application. We actively discussed the extent to which you can actually plug and play components because there are limits. We had to consider exactly what one would have to do in order to re-use a component. The intent was to reduce the amount of user-defined space in the profiles. With OpenVPX, having a lot of available user-defined space provides flexibility for a supplier to say “OK, I can take this user-defined space and put signals on it that will help a certain application.” In doing that, however, you limit the utility of that hardware to a custom application. The result is that re-use goes down. We did a trade study to explore how to maximize re-use; one of the ways is to reduce user-defined space, specifically in profiles. That finding informed the hardware section of the SOSA Technical Standard. None of the profiles, except for two that were included for specific reasons, have any user-defined space. The SOSA profiles were designed or developed that way so that the Government can take a SOSA component —for example, a plug-in card from a profile that has a VITA slot profile— and readily re-use it for another application. Granted, it may be necessary to do some re-configuration, and that’s where conformance comes it. It makes it possible to verify that a supplier has adhered to the standard, which in turn means adhering to the interface definitions for those profiles.
Now a Government customer can say, “I have this profile and it’s supposed to do this and this, and I can put it here in this application, but I also know I can also use it somewhere else because the interfaces are similar or the same”.
Did you have to battle the desire to create areas of special dispensation and exemption and still claim conformance?
That’s another benefit of the SOSA Consortium, where both industry and Government are involved. We worked the problem together and everybody agreed to share some of the pain. We agreed that reducing flexibility increases interchangeability and portability. As a result, industry is incentivized to optimize the most prevalent interfaces they currently use or think they or the Government will need to use. There was a constant conversation and a lot of work that went into making those decisions. Granted, a lot of the profiles in the standard were baselined from some that were already works in progress by the Army. With that in mind, discussions focused on establishing consensus regarding the types of profiles and their interfaces. Those conversations are still going on today, especially on some of the interfaces and protocols. There’s a lot of discussion about what makes the most sense and how to make the best use of those profiles. And conformance is going to make sure we can verify that a supplier properly used those interfaces in creating a product.
So, basically, the philosophy was, there’s an onus, in that vendors are going to sacrifice the ability to have uniqueness, but the bonus is the wider market opportunity because they’ll make it up in volume, arguably?
Yes, that’s one of the reasons why you see the Services wanting to do this together, to increase those economies of scale. Uniqueness is defined inside the SOSA components, not at the interfaces.
At this juncture, we have SOSA 1.0 about to be released, so conformance starts looming large. Suppliers are going to want to go to the market and say the SOSA Technical Standard is public, and that they’ve got product. What is the status of the conformance process today?
Right now, the Conformance Subcommittee is trying to help consortium members develop verification matrices. These matrices allow us to understand which requirements get tested depending on the type of product. The standard is organized into conformance segments,. One of the motivations for creating matrices was to understand what needs verification and determine how to perform verification. After we create the matrices, we plan to interact with 1) test tool developers so they can build appropriate verification capabilities, and 2) potential verification authorities to provide them with the information they need to understand what they are responsible for and what to be aware of during the verification process. We are just now developing all those matrices and recently finished reviewing the conformance certification policy. We have been awaiting publication of the SOSA Technical Standard v1.0. The SOSA Conformance Guide will probably not go out until after the v1.0 standard goes into public release, because the guide must also undergo a consortium review. After that, conformance will involve development of tools and accreditation of VA’s. This process will take time, and we must wait until the standard has been fully released. We’ve been doing a lot, in parallel, to help shorten the delay between when the standard is published and when the conformance program goes online. Still, a lot of details obviously depend on what the published standard includes, and when we can start using it.
Do you envision a distinction between verification and certification? Might companies self-verify or does that require a third-party?
The way it will run is there will be third-party VAs that will collect information from a supplier and perform verification. The nice thing is that the people involved in the Consortium —say, for example those in a software environment or security subcommittee,— will develop the conformance methodologies that the VA will use to inspect, analyze, test and/or demonstrate that the product comports with the standard. The subcommittee experts will have a voice in what makes the most sense. Then the VA, which is an independent organization, will execute those conformance methodologies. Once the verification process is finished, the product goes to a certification body run by The Open Group. The certification body will conduct the requisite checks required to declare the product “SOSA conformant.”
What are the most common questions that you get asked about the conformance process?
There are a lot of questions about the cost of conformance and the cost of verification, because there’s a concern that it will be too expensive to get a product certified. The certification process will have a flat fee. The cost of verification, according to The Open Group, will be by agreement between the product supplier and the VA. I get a lot of financial questions, and a lot of questions about verification matrices and associated procedures. People want to understand “how would you verify this?” because there will need to be conversations between matrix developers and a potential VA. We get questions about external standards and how to execute requirements from an external standard, because, according to The Open Group, we have to account for those cases. There are also a lot of questions about how we plan to phase in the conformance program. Right now, we are phasing in the program because of limited resources. We need to build an understanding of what industry might bring in for verification, because companies are already developing products. We are looking for the lowest hanging fruit to address first, to get the program off the ground and running. The challenges are that we have to go through all those gates, and get funding for test tool development and VA certification. We can’t do anything without adequate resources. Those are some of the most common questions we’ve heard over the past few months.
So, you’ve been getting ready for a huge wave of activity that will follow release of 1.0., is most of the work already done or are does your work really start after the release?
The SOSA Technical Standard has morphed over time, which is normal. The real work, with respect to securing funds, getting test tools developed and identifying accredited VAs, will be done over the next couple of months. Again, the big challenge that will drive the timeline is financial. Without funding, the conformance program will be delayed, and without a formal conformance program, suppliers will only be able to represent that products are aligned to the SOSA Technical Standard, and not in fact conformant.
Do you have sense of timing in regards to when suppliers will be able to offer certified products?
Based on a roadmap that’s been coordinated through the Conformance Standing Committee, we will not have an operational program until an estimated twelve months after the standard is published. There are many dependencies.
Will there be a database of certified products that is maintained by The Open Group?
Yes, I believe that The Open Group will maintain a SOSA registry, as they do in support of the FACE Consortium.
What would you say has been the greatest satisfaction that you’ve derived from your role and participation in the SOSA process?
I’d say just being able to help develop the SOSA Technical Standard and contribute content for an important standard. Also, it’s been gratifying to help others who are involved get over hurdles they encounter while working to develop and refine content. For me, seeing SOSA v1.0 published is a huge accomplishment, because as the SOSA Technical Standard transitions from a “snapshot” into an official standard, it becomes a real thing.