Development of the next-generation OpenVPX-based embedded system standard: A tri-service convergence of approaches: Part 3 of 3

Story

June 06, 2019

Dr. Ilya Lipkin

Air Force Life Cycle Management Center (ALCMC)

Something exciting is happening in the service representative community. Representatives from three different programs, one from each of the U.S. Department of Defense (DoD) services, have come together with a common objective to solve their respective acquisition problems with an agreed-upon, open architecture standard. Here is the final part of a 3-part article covering the SOSA [Sensor Open System Architecture] Consortium’s efforts. Read Part 1 in the March 2019 issue and Part 2 in the April/May 2019 issue of Military Embedded Systems.

In order to make SOSA [the Sensor Open System Architecture consortium] successful, the founders needed to get involvement by a number of stakeholders, with buy-in from the end user or acquisition community. Someone had to agree to use and specify hardware development using SOSA. So far, the customers or end-user representatives from each of the services includes Air Force’s AFLCMC, the Army’s Combat Capabilities Development Command (CCDC, formerly CERDEC), and the Navy’s Naval Air Systems Command (NAVAIR), all of which are responsible for acquiring technology for their respective service of the Department of Defense (DoD). Representatives from the key defense-industry suppliers are also noted among the members who are actively participating. [Note: See Open Group’s listing of participants in the SOSA Consortium (www.opengroup.org/sosa) to see the breadth of representation across the industry.] Participation is also being amplified by maintaining a close liaison with standards committees whose requirements are being assembled by SOSA. This includes collocating meetings with the VITA industry standard group, a number of whose members participate in SOSA, making this a convenient arrangement.

Technical subject matter experts (SMEs) are involved to define the requirements such as the “SHALLS” included as part of the standard. This effort includes a number of people whose names are easily recognized from the leadership of such efforts as development of the OpenVPX, VITA 46.11, MORA, and VICTORY standards. Representatives from the science and technology community are also serving as SMEs to support development on an as-required basis. SMEs may also include open-architecture experts who can advise SOSA regarding what does and does not work from a standardization perspective as well as historical perspective. SOSA has also taken the additional step of bringing together the appropriate business people who can clarify what the value proposition is for SOSA. Businesses need to justify their participation in SOSA’s development; this clarification can include increased sales as well as creation of an ecosystem for new hardware, similar to the way the IBM PC standard created the consumer market of today. All of this has to be done while the SOSA organization ensures that its standard remains on track to deliver that value proposition to both the customer and the supplier.

SOSA has organized itself to be successful by addressing each of the key elements composing the standard as well as providing an effective leadership structure. That organization structure, shown in Figure 1, illustrates how those elements are being practically addressed. SOSA has five working group as well as a number of focused subcommittees within these working groups or bridging them when necessary; these may change over time depending on the current development need. An example of one of the current “bridging” subcommittees under the hardware working group is a group organized to address systems-management standardization of the logic that gets created as part of embedded system integration, with others including cybersecurity and system drivers. Simple examples taken from existing systems include logic to create the built-in-test (BIT) tables/fault logs and configuration tables (which falls somewhere between firmware and application like software). These standing working groups include (going from high-level management and organization to more specific or detailed) the Business Working Group, the Architecture Working Group, the Software Working Group, the Hardware Working Group, and the Electrical/Mechanical Working Group.

Figure 1 | SOSA Committee structure.

The Business Working Group can be regarded as the glue that holds SOSA together: Its charter is to analyze and be aware of market forces that affect SOSA, establish plans to ensure its success, and effectively create and grow the SOSA market. Duties may include basic marketing ranging from information-gathering to communications to all stakeholders. This group may also aim at customers who are targeted for application of SOSA, as well as businesses who should become part of the growing ecosystem of suppliers and users of SOSA. The Business Working Group also informs the SOSA working groups of the market opportunities and impact of their potential standardization direction and provides guidance to the SOSA working groups to ensure that development progresses in the right direct to ensure the maintenance and growth of SOSA’s value proposition.

The next working group, the Architecture Working Group, defines and develops the architectural products that communicate the vision of SOSA. It works closely with the Business Working Group, especially where roles may seem similar or closely related. Part of the internal focus of this group is to ensure that other working group’s development is synched up, properly captured, and adherent to DODAF framework principles. This working group has been developing common architectural decomposition that is agnostic to software/hardware instantiations; it has also worked on aggregating common capabilities between sensor domains and modules, defining a common terminology dictionary across and within domains, and ensuring consistency of the SOSA effort across all working groups. Some of the current activities are cybersecurity, developing a consumer product matrix, and ensuring that alignment between selected specifications, working group activities, and selected standards all interoperate within SOSA. Its focus is both internal – for use within the consortium to guide its direction towards successful application and growth – as well as external, to attract other interested parties including the user community and the companies that represent the market ecosystem.

The next three working groups is where the more traditional process of standards development is being performed. The Hardware Working Group’s objective is to create a standard that fulfills the vision of common, modular units of hardware functionality providing interchangeability, interoperability, upgradeability, and scalability. These units are in fact plug-in modules or circuit card assemblies, which fit in a traditional chassis and consequently leverage the existing embedded-system COTS [commercial off-the-shelf] industry. The linkage to the market is clear, which explains the large participation in this working group by the typical embedded system designers and developers. A simple example of the working group’s products is standardization of the interfaces on a single-board computer and a network switch. Its progress and accomplishments are readily evident in its recently released snapshot. Similar to the approach of HOST [Hardware Open Systems Technologies] and CMOSS [C4ISR/EW Modular Open Suite of Standards], SOSA pulls together industry standards where available and when not available, create the necessary “SHALLS.” The objective of and the approach being applied by the Software and Electrical/Mechanical Working Group is similar to that of the Hardware Working Group.

The Software Working Group intends to apply existing standards (e.g., FACE [the Future Airborne Computing Environment standard], the Air Force’s Open Mission Systems (OMS) [1], Model Based Engineering (MBE), National Security Agency (NSA) REDHAWK [2], Army Modular Open RF Architecture (MORA), Fires Radar Open System Technologies (FROST) [3], and Vehicle Integration for C4ISR/EW Interoperability (VICTORY) standards) or develop where necessary to achieve agile, affordable, reusable, software-based capabilities supporting multiple platforms and variants. Currently there are about 25 sensor software modules that are being standardized to cover EO/IR [4], electronic warfare (EW), communications, radar, and signal-intelligence (SIGINT) domains based on commonality of existing capabilities, thereby enabling multi-modal sensor development. Furthermore, this working group is developing a common data structure, data model, and C2 mapping between higher-level open architectures; STANAG-4586 would be one example for interoperability of the sensors. Additional work within the Software Working Group is to integrate lower-level software specifications that are in the gray zone between hardware and software such as chassis manager, drivers in common, Application Programming Interfaces (API), cybersecurity, and the like.

The Electrical/Mechanical Working Group intends to define standardized interfaces between the SOSA systems and the particular platform on which the system is intended to interface. The goal of this working group is to develop common connectors for C4ISR. For example, this working group adopted SAE-6129 and SAE-6169 for EO/IR mechanical and electrical specifications and expanded them to carry radar, SIGINT, EW, and communication system interconnects. These capabilities were tested during initial flight of the Air Force Research Lab (AFRL) AgilePOD at Wright-Patterson Air Force Base (AFB), where several sensors were swapped on a flightline rapidly between takeoffs and landings on a DC-3, as a steppingstone for later flights on an MQ-9. The next step for this working group is development of a small class of sensor interconnects for smaller unmanned aircraft systems (UASs) along with medium sensor packages. At the end of the process these specifications will enable a Universal Serial Bus (USB [5])-like interconnect between vehicle and sensor being bolted on and not baked in (as the current family of sensors is today).

Going forward with SOSA

SOSA has become the nexus of convergence for addressing a number of different but related applications requiring embedded system development as well as pulling together a wide range of stakeholders and experts from all corners of the market and intended application spaces. This includes the end-user community including the Air Force’s AFLCMC-related programs, the Navy’s HOST program and its major programs, and the Army’s CMOSS solution. Involvement from all areas mean that the effort is clarifying expectations and mention requirements. This involvement is also being solidified by a three-service MOA that will codify the agreements to cooperate in the development ongoing in SOSA and will be a show of commitment for anyone signing on.

SOSA has also achieved a minimum critical mass of participation necessary to be promulgated as an independent consortium. Now signing on are the system integrators who know what it takes to build up components and make them into a useable system. SMEs on the applicable technology are already lined up and are participating in and contributing to the development ongoing on each of the Working Groups (e.g., Business, Architecture, Hardware, Software, and Electrical/Mechanical). Lastly, component vendors are assisting in enabling a path to faster upgrade of technology and are influencing the development of the market ecosystem to better satisfy the end-customers’ needs for transitioning greater capability on shorter timelines at lower cost. With this, industry will be able to leverage government investment to focus their own investments.

SOSA has gone well past simply defining its problem statement (which is in fact a significant accomplishment in any case and often is the hardest part of solving a problem). It achieved a major milestone when it was made a separate consortium under the Open Group in November 2018. It also achieved a significant milestone with the release of its hardware snapshot in the same time frame. That said, SOSA is ready to ramp up its development effort, for which lots of volunteers are critical. All interested parties/stakeholders are invited to participate.

References

[1] https://www.vdl.afrl.af.mil/programs/uci/oms.php

[2] https://redhawksdr.github.io/Documentation

[3] http://ciena-frost.github.io/

[4] Generic sensor classification referring to Electro-Optic/Infrared sensors

[5] http://www.usb.org/home

Mike Hackert is program sponsor at NAVAIR [Naval Air Systems Command], Ben Peddicord is chief of the Army’s Combat Capabilities Development Command [CCDC, formerly CERDEC] Intel Technology and Architecture Branch, and Dr. Ilya Lipkin is lead manager for SOSA at the AFLCMC [Air Force Life Cycle Management Center].

NAVAIR | www.navair.navy.mil
CCDC | www.cerdec.army.mil
AFLCMC | www.wpafb.af.mil/aflcmc