SOSA Newsletter Interview Questions
Subject: Dr. Ilya Lipkin
SOSA Newsletter Interview Questions
Subject: Dr. Ilya Lipkin
Q. What is your role in SOSA?
My role is very simple; I started the Sensor Open Systems Architecture (SOSA) initiative and am the elected chair of the The Open Group SOSA Consortium Steering Committee. The Air Force Life Cycle Management Center (AFLCMC) was interested in promoting an open architecture for US Air Force (USAF) sensors, so we approached a number of industry partners. Initial industry feedback wasn’t enthusiastic because of the relatively small market for USAF sensors. Consequently, we proposed a compromise wherein we would get the other Military Services to participate, in order to build a meaningful open architecture sensor market. We modeled the SOSA Consortium after the existing FACE (Future Airborne Capability Environment) Consortium, which featured what we saw as an appropriate approach for addressing our open architecture challenge.
Early on John Bowling was the USAF member of the FACE Consortium. At one point, I attended a FACE Technical Interchange Meeting (TIM) in Dayton, OH. As I gained familiarity with FACE, I joined FACE Consortium to learn about and participate in the evolution of that set of standards.
The initial concept for SOSA came from Gibbs Dickson, who ran the AFLCMC/WING Sensors Directorate branch and Dick Sorenson who was a Chief Engineer for AFLCMC/WIN. The challenge was to secure maximum participation and buy-in. When we looked at existing business models, the FACE Consortium seemed like the most logical fit. We refined the model based on input from several key players including John Bowling (Air Force), Dr. Steve Davidson (Raytheon), Dr. Michael Moore (SWRI), Patrick Collier (AFRL), Ben Peddicord (Army), and Robert Matthews (Navy), and OGA partner, at the initial meeting at Pax River hosted by NAVAIR.
One of the attractive aspects of the Consortium model is that it is a sustainable approach with a relatively low initial cost. A primary goal was to access a large industry support base; the other consideration was to minimize initial Government start-up costs. Alternative approach we explored was the OMS-UCI (Open Mission Systems/Universal Command & Control Interface) model, basically a Government-sponsored collaborative working group where the Government contracts with a number of companies to design the standard. The FACE approach allowed Government investment to multiply funding available while giving us broad access to industry talent, from both large and small companies.
In spite of its cost advantage, the FACE approach proved more challenging from the perspective of gaining Government approval, because it meant giving up a degree of control in exchange for buy-in and strong influence into the commercial COTS marketplace. The SOSA model prioritizes inclusiveness. We encourage small businesses and academia to participate and contribute, which strengthens the technical standard. Also, the “crowd-sourcing” enables us to innovate faster because our members have more access to the latest and greatest technologies. Finally, the Consortium creates a level playing field for industry because it doesn’t favor the largest players.
Q. What has most surprised you about the standard’s evolution as it proceeded to Snapshot 3?
Did it go exactly as I planned? No, because there are still critical technologies that we haven’t agreed on. A positive surprise has been the level of buy-in and the proliferation of components that broadly comply with a technical standard that hasn’t been released. Every time a vendor designs or builds a component to a particular standard, they risk that the standard might not be adopted. Industry invests millions of dollars in non-recurring engineering (NRE). It’s encouraging that industry is willing to invest in SOSA, which suggests there has been a need for a SOSA technical standard all along. That said, there are also quite a few technologies I wish we had adopted but didn’t because of industry concerns. For example, last year we couldn’t agree on a single network protocol. Ultimately, we found middle ground that seems to be working. For a standard as complicated as SOSA, I’d credit the Consortium membership for impressive progress and technical rigor.
Q. You’ve stated that one of the goals of SOSA was to use existing standards, and only develop new ones when absolutely necessary. Has that proven to be the case?
Yes and no. In retrospect, there have been positives and negatives to that strategy. The most significant positive is that by leveraging mature existing standards you quickly benefit from years of design and development experience. On the other hand, you also inherit the concerns and limitations (technical and political) associated with those standards. It’s been incredibly difficult to gain consensus allowing one organizations open standard to become part of SOSA. At the same time, it’s incredibly rewarding because once a standard is accepted, we benefit from 5, 10 or even 20 years of investment and engineering as it becomes part of the SOSA technical baseline.
We also enjoy a unique situation with SOSA in that VITA —an existing standards body— joined as a member of the Consortium. That may represent a first for a collaborative standards organization: it enables VITA to extend, modify and feed back into their own effort.
To go faster and be more agile, you have to build on others’ work and stand on their shoulders. That’s one of the lessons from research: don’t start from scratch. Start with a solid foundation, then modify, adapt and add to it. The “add to it” piece is usually based on what’s already there. Are we also doing new stuff? Yes, for example, in small form factor sensors. For SOSA, we started with VNX or PC104 and either diverge or converge, depending on where the working group takes us. The result is based partly on somebody else’s experience but is also partly brand new.
Q. SOSA is the first standard to be based on Model Based System Engineering (MBSE). What are the benefits of that approach?
The Air Force has a campaign to adopt digital engineering as a way to effectively address emerging and future challenges. One of the things I recognized and invested in from the very beginning is the need for SOSA to have a modern tool foundation. At the moment, SOSA Snapshot 3 and v1.0 are captured in Word documents. In parallel, we are constructing a digital model that can auto-generate the technical parameters, interface designs and functional relationships in the SOSA Technical Standard, using the Sparx Enterprise Architect modeling tool. The reason for that is simple: SOSA is very complex, and to manage that complexity you must have tools that can support it. I envision that v2.0 will be captured in an Enterprise Architect or Cameo Systems model that will become the authoritative engineering source for the SOSA Technical Standard, and even auto-generate consistent sensor “shall” statements for capability acquisition.
Q. Are there any other firsts that SOSA is establishing?
Yes. Recently, Intel Corporation joined the Consortium. Why would the addition of one company represent a singular success when we already enjoy contributions from so many companies including large prime integrators? The reason is that SOSA becomes the first technical standard to produce a vertically integrated product specification. Intel produces silicon, that is, microprocessors. Curtiss-Wright, Mercury, Kontron and Abaco build cards using that silicon. Those cards are sold directly to the primes, or to third-tier suppliers, such as Leonardo DRS, HTL, or Spectranetix, whose components are ultimately sold to the primes for integration into the sensor system. Ultimately the primes produce fully-integrated sensor systems for the Government. SOSA is only technical standard I’m aware of that has participants representing an entire product lifecycle sit next to each other discussing how sensor systems will be deployed, employed and sustained.
Q. What do you see as the most important benefits that the SOSA Technical Standard will bring to the warfighter?
One important benefit is that we have a venue for the Air Force, Army, Navy, and Other Government Organizations (OGAs) to collaborate on sensor systems. In the sensor business, everyone has a silo of excellence, and we’ve built firewalls of protection around those silos. SOSA has created a soda straw between those silos for people to peer across and say, “Look, we’re doing the same thing as other end-user and prime activities!” In doing so, we’ve encouraged convergence of phenomenologies and end users addressing the same requirements. It’s not so much about paying several times for the same product (we do that all the time), it’s about investment efficiency – how can I quickly modify an existing product to make it meet new requirements? That’s the biggest thing that we’ve done, opening up new lines of cross-program communication. Basically, in order to innovate faster, we have to communicate faster.
Think of it this way: if you develop a fancy component that can process a lot of data quickly on an aircraft, wouldn’t you want others to discover and use that component? Today, that doesn’t happen very effectively because of the independent silos of excellence. Basing sensor components, modules and systems on a common technical standard helps speed discovery and re-use, and significantly advances interoperability.
The initial vision was for SOSA to be an Air Force open standard for sensors. Ultimately that wasn’t viable, so the vision expanded to become an open standard for the DoD. I would say that’s the biggest change. While the Air Force initially developed the concept, subsequently Army, Navy and other customers also provided support, helping to make SOSA a true DoD effort. In terms of leaders, both Ben Peddicord and Jason Dirner have dedicated an enormous number of hours to help SOSA be successful. Ditto for Mike Hackert and Tyler Robinson (Mike’s replacement) from the Navy. SOSA is not just an Air Force standard, but one of the first truly joint standards. And while we continue to reduce the barriers for industry stakeholders to talk to the DoD, ironically we’ve also reduced barriers for productive conversation across the Military Services.
Q. What do you see as the greatest challenges/opportunities for broadening acceptance and use of the SOSA Technical Standard once it’s finalized?
I think it’s already accepted! There are more contracts lined up than we know what to do with. The next challenge is maintaining and maturing the standard. Version 1.0 is not going to be mature in all respects. The hardware specification will have a high maturity level, the software specs not so much. There are still missing pieces that need to be developed for v2.0. I’m not worried about buy-in, product lines or customers based on what we’re seeing. There are many DoD programs now that want to use SOSA. Our challenge is not to disappoint them!
We do need to keep SOSA from trying to specify 10,000 different hardware profiles. SOSA has primary and secondary hardware profiles, and there’s been constant debate over which profile should be primary. We use the two-option approach because it allows for a primary hardware profile to provide greater interoperability, with a secondary profile that enables perhaps greater performance. The key promise of SOSA is interoperability. So anything that limits interoperability is a problem. As SOSA gains momentum, managing “good idea theories” becomes harder and harder…everybody brings a unique use case. Proving whether an idea should become part of the standard or should be a one-off is becoming more of a challenge. At the end of the day, interoperability is the key to how we win. We need to avoid having edge cases dilute effectiveness. If a proposed use case resonates with a large customer base, it deserves to be part of the standard. With that said, SOSA does accommodate components with custom profiles to be used in the same box with standard components, but you can’t label the custom items as SOSA.
Q. What is the biggest misconception about SOSA?
The biggest misconception people have may be that SOSA is a hardware-only standard. In fact we have a lot of software specifications. Misconception it that the SOSA Technical Standard is developing slowly. We are not slow. Considering the complexity of a fully-realized SOSA sensor system, the volume of technical content we’ve created in four years is huge. It could easily have taken 15 years to develop that much content. The Consortium model and consensus approach has proven to be quite efficient.
Q. What would you like to say about the validation process for the Snapshots as you’re working toward 1.0?
We’ve been validating SOSA Snapshots through prototyping. The process is very simple. The program has resources to support prototype development. So I engage with various programs of record to learn what sensor prototypes might benefit them and simultaneously help validate the SOSA Technical Standard. In response, I get detailed requirements, and we commission a real-world sensor component prototype that can also be operationally deployed. All SOSA prototypes are designed to be operationally deployed for field testing purposes. Prototyping provides valuable lessons learned, for example revealing situations where the standard doesn’t work. The prototype vendors are asked to develop appropriate integration workarounds, and then document that work and bring the information back to the SOSA Consortium to support updates to the Technical Standard. The goal of prototyping isn’t simply to please a program manager, but to leverage their requirement to refine the Technical Standard. We try to develop at least two prototypes for each Snapshot, but it obviously depends on available funding. Our approach reflects Air Force and DoD direction to build, test, build, test, build, test.
The Air Force also conducts testing against the candidate standard releases, in conjunction with meeting program requirements and milestones.
Q. Are you pleased with the progress made so far?
I am extremely excited to see the large volume of work we’ve completed. We’re especially pleased that industry has come along to share the risk with the Government by helping to develop a standard that will benefit us all in the long term.