Using the VME Standard as an Example 

By Ethan Plotkin, CEO, GDCA, Inc.

Over the past decade, more light has been shed on the real and debilitating problem of electronics obsolescence. Across the embedded electronics industry, there is growing recognition of both the costs that legacy products carry and the long-term value they provide to customers. And while the industry has made meaningful progress in how it approaches legacy product discontinuation, significant challenges remain—particularly when it comes to how we think about solving these problems in the first place. 

A State of Inertia 

Historically, engineers and product teams tend to take problems inward, relying on internal teams to fix things themselves. But even when in-house solutions are possible, it is worth asking: Should we be solving this ourselves? 

Preface by VITA’s Executive Director, Jerry Gipper:

Model-based engineering (MBE) uses models to represent the structure, behavior, operation and other characteristics of a real-world system. Models can define a products form, fit and function. Switching to a model-based approach helps coordinate system design activities, satisfy stakeholder requirements and provide a significant return on investment. The purpose of MBE is to move away from error prone “document-centric” approaches to complex system design. In this month’s blog, Tram shares a real-life experience that convinced him of the value of MBE.

OK, try it now; Tram Chase, Technical Director, SimVentions

Back in 1995, I worked on an effort to integrate the Navy’s Aegis Weapon System with several other US weapon systems in a distributed network in order to test the military’s ability to collaboratively defend against enemy missiles.

At the beginning of the project, we were given a document—the Distributed Interactive Simulation (DIS) Standard—that defined the messages (fields and data types) that should be used to enable communications between the various systems. It also included some guidance in the form of sequence diagrams as to how those messages should be exchanged, e.g. when one system sends message A, another system should respond with message B.

So, we went off for a few months and built our software, and then came the big event! Each of the sites brought up its systems and software and we all connected over a network. One site played a scripted scenario that simulated incoming missiles and our system, along with everyone else’s, began sending messages all around in an effort to track and shoot down the missiles. Now, rarely did all participants make it to the end of the scenario—it could vary from 20 seconds in or 20 minutes in—but almost always there was a phone call to say that we were stopping – one of the sites, possibly us (Aegis), had crashed or run into problems.

Now, I can’t speak for all of the other nodes in the exercise, but when that happened at our site, there was always the same scene: everyone frantically stared at code and log files trying to diagnose the problem.

Then, after an on-the-fly code change or magical reboot, we would say “OK, try it now.” And then everyone started the same process over again. And we repeated this MANY times until everyone made it through the entire scenario.

This approach eventually worked, but was far from ideal. Looking back, one of the reasons I think we had so many problems was that we used a document-centric approach. Each site used the same specification (DIS) to build their system, but the process of manually implementing that specification left too much room for misinterpretation and error. (Figure1)

Figure 1: A document-centric approach can inhibit efforts when integrating a standard across different military weapons systems.

Aside from manual errors, using a document-centric approach leads to several other issues:

• Stove-piped manual workflows are painfully repeated with each change or update – Each document revision forces everyone who has adopted that standard to design and implement the necessary changes.
• Difficulty in quickly finding information – Typically, each standard will reference one or many other standards and forcing engineers to maintain an enormous set of bookmarks in multiple documents, meaning too much time is spent turning pages to find answers to questions.
• Complex data synchronization – Take message formats, or example. They are documented in the standard, again in the source code, again in the comments for that code, and then often in other project specific documents, as well. Any changes in the standard document require several manual updates be applied across several other locations.

Moving from 1995 to 2019, I’m now working on building a software tool to make it easier to integrate the hardware that goes into a Navy jet. As part of that effort, I was at a “plugfest” where vendors brought a bunch of equipment and hooked it up together to demonstrate their latest and greatest capabilities.

The scene I witnessed was three guys standing around a test chassis and backplane. They would put a card in a slot, turn on the power, wait a few minutes for some lights to flash, maybe run a software utility to check some status, turn the power off, pull the card out, put it in a different slot, and say “OK, try it now.” Seem familiar?

Surely after almost 25 years, we would have eliminated a bunch of those problems that we had back in 1995. Not really, as it turns out.  These engineers were still relying heavily on documents, a lot of labor intensive analysis, and several “OK, try it now”s before they produced a working system, just like we did in 1995.

There’s got to be a better way!

I believe we can reduce the amount of time and pain involved in integrating components by adopting a more data-centric approach. We need to capture the data contained in the owner’s manuals, spec sheets and standards in a machine-readable, common digital format and let computers do the work. By doing this, we can then:

• Quickly search for existing components that meet requirements – Repositories or libraries of data describing components can be built that allow easy searching by all sorts of criteria.
• Easily compare specifications for components – Tools can be built that can compare components and facilitate faster replacement of legacy components.
• Automate the generation of source code and documents – Tools can be built that automatically generate spec sheets, requirement documents or parts lists based on the component data. Source code can also be autogenerated and shared across the community.
• Generate model components and systems of components – Models and simulations can be built allow engineers to detect and mitigate integration issues, before buying a single piece of hardware.

Figure 2: Model-based engineering provide more efficient system development by streamlining data inputs and reducing manual errors.

And these are just some of the benefits. So, for those still reading this, I challenge you to “Try this now.” Collaborate. Work together to define a data model that describes your domain, in this case modules, backplanes, chassis, etc. And then use that data model as a basis for tools and repositories that allow engineers to focus on building great capabilities.

We need to enter the era of “Smart” standards based on data models!

Sponsored by Representative Commands from Branches of the United States Armed Services, Members of the Media, Program Managers, and Embedded Computing Industry Guests Will Witness the Future of Defense Acquisition

Atlanta, GA – August 27, 2019 – The Tri-Service Open Architecture Interoperability Demonstration – a new, exclusive event for the media, acquisition community and industry influencers, and hosted by the Georgia Tech Research Institute at the GTRI Conference Center in Atlanta, Georgia - announces it will be held Wednesday, January 29, 2020.

Open Architecture experts speaking include:

• Mr. Michael J. Hackert, US Navy former Lead Engineer of the Hardware Open Systems Technologies (HOST) team;
  
• Dr. Ilya Lipkin, US Air Force Open Architecture Technical Expert and Chair of The Open Group's Sensor Open Systems Architecture Consortium Steering Committee; and
  
• Mr. Jason Dirner, US Army Team Leader, Intel Technology and Architecture Branch, C5ISR Center.

Live demonstrations will guide the audience from Systems Acquisition and Integration, to Module Specification and Development, then Conformance (qualification), and finally, Open Systems Realization. Joining Tri-Service representatives in demos will also be industry vendors representing Industry and Government partnership with: CMOSS, HOST, SOSA and VITA standards development organizations spanning over 70 members (view members at https://www.opengroup.org/sosa/members).

“This unique showcase will demonstrate a greater maturity and acceptance of Open Architecture development. With FACE as well as standards defined through HOST, SOSA, CMOSS, several Army, Navy and Air Force representatives will reveal the ease of interoperability (exchange of hardware and software modules), faster incorporation of innovation and delivery of new capabilities (or replacement technology) to alleviate being forced into changing all components in an entire system. The growing market ecosystem achievement breaks decades-long barriers created by tightly integrated systems, thus allowing new capabilities to be transitioned orders of magnitude faster than the past” states Sally Bixby, Independent Consultant to NAVAIR PMA-209, and event coordinator for the TSOA-ID.

To learn more or request an attendee pass, register at www.tsoa-id.com. For more details or to confirm a pass (seating is limited), email sally@sallybixby.com.

Reference / Background

HOST – Hardware Open Systems Technologies standard. Initiated by the United States Navy’s Naval Air Systems Command (NAVAIR) Patuxent River, MD in 2014; version 4.0 published 14 August 2019

CMOSS – Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance (C4ISR) / Electronic Warfare (EW) Module Open Suite of Standards. Initiated by the United States Army’s Communications Electronics Research, Development and Engineering Center (C5ISR Center) at Aberdeen Proving Grounds MD in 2013

SOSA^TM– The Open Group Sensor Open Systems Architecture (SOSA) Consortium standard. Initiated by the United States Air Force’s Life Cycle Management Center (AFLCMC) at Wright-Patterson AFB, OH and The Open Group SOSA Consortium. Incubated within FACE^TM– Future Airborne Computing Environment Consortium in 2015.

In today’s embedded market, opportunities for emerging technologies have become a necessity.  From more adept design-in solutions to entirely bleeding edge technologies, embedded systems thrive on “new.”  One of the biggest vehicles driving these developments are Standard Development Organizations, or SDOs. 

Many of these groups develop standards that are considered “open.”  But, what does this mean? 

An open standard is one that is readily available to the public and allows for adoption from any user for a variety of applications and end-uses.  In brief, an open standard allows the technology to stay open and available for mass use.

This differs from a “corporate” or “de-facto” standard that may employ closed technologies only accessible to a select group.

Consider challenges upfront
While open standards offer many benefits, there are also several challenges in getting them off the ground and seeing them to completion.  As would be expected, participation is crucial.  Often, this involves much more than just attending and observing a meeting. 

Active participation from various industry leaders is essential.  The more people and perspectives that weigh in, the better the outcome. Without a diverse set of contributions from the working group, the benefits of being open are lost and progress can grind to a halt.

Many of the challenges facing SDOs today are easily overcome.  And many are universal, not just contained to the embedded realm, but apply throughout technology initiatives.  Here, we look at some of the most common ones that can obstruct open industry innovation.

Challenge 1: Not Being a Member of an SDO
While perhaps more obvious than some of the other challenges facing standard development, non-membership is one of the most common.  Often, this can create insurmountable obstacles to participation, collaboration and ultimate completion of specifications.

Due to bylaws and potential NDAs, nonmembers often are denied access to documentation as well as voting rights.  This can cause frustration, since an organization or individual may have valid points for consideration but are unable to voices their contributions.  Beneficial concepts can be gone unheard. 

The solution is simple; join the standard organization in question.  Often, these consortiums offer a variety of membership tiers to fit a company budget and degree of participation.  Even with associate-level memberships, companies are often able to gain access to important documentation, participate in group discussions as well as have voting rights.  All of these are essential in standard development. 

Challenge 2: Late Participation
Another challenge that often plagues organizations is late participation.  At times, this is due to conflicting schedules and different interests during the time of development.  Further complicating matters, late participation often arises from nonmembers having a limited ability to participate in an actively, timely manner.

Within certain organizations, many comments regarding finalization of a spec may arrive during the final stage of development.  In the case of VITA, this would be during the ANSI vetting process. 

While the concerns presented may be valid, the result may not prove ideal.  Often, these late contributions set back the vetting process, causing significant turnaround.  One standard we worked on was delayed over six months due to late participation, causing considerable frustration across the group. 

Getting involved early proves to be the best remedy.  Being an active member of the organization and participating in the initial work group efforts, you ensure your position in the group.  This supports not only the best interests of the community early on, but also the interests of your company or industry.

Challenge 3: Building a Solid Team
Let’s say challenges 1 and 2 have been bypassed and efforts to write a specification are underway.  It’s no secret that teamwork is essential to keep the process moving forward.  However, building a dedicated team may present a challenge. 

To help ensure success, look to groups with existing solid teams.  Standards such as IEEE, PCI-SIG, Gen-Z, and SOSA all have dedicated teams, with driven and dedicated members that have been present since the group’s beginning.  It is also helpful to have a group with a varied background for a more well-rounded approach to new standards and technologies. 

For example, in the embedded market, a standard development group could benefit from the experience of system designers, electrical and mechanical engineers as well as connector manufacturers.  It’s also helpful to involve marketing and sales expertise as needed to rate a specification’s marketability. 

Challenge 4: Lack of Interest
Try as we may, some communities may not be interested in the proposed specification.  Others may want to see changes, but don’t have the bandwidth to support the effort.  Both can lead to a lack of balance or eventual shutdown. 

In these types of situations, community chairmen or officers may need to step in and draw a line, another reason a strong team is critical. 

Often, these pitfalls can be avoided utilizing tools such as ballots to gauge the interest of the community, not only during, but even before a standards effort is undertaken.  This approach determines interest and proper allocation of resources as well as avoids delegating all the development to one company or individual.   It also helps identify what aspects the standard needs to address and potential road bumps in the standard’s development.

Challenge 5: Internal Conflict
A final challenge, internal conflict, could be potentially positive or negative, depending on the outcome, as it’s a natural part of any collaborative effort. 

In the case of standards development, competitors may be working on the specification together, while trying to represent the interest of their companies.  On other occasions, active members may not be able to “standardize.”  This could mean not coming to a collective consensus or limiting the scope of the specification in question. 

Without a quorum, progressive standards can often become derailed or stuck in an endless cycle.  To resolve issues, difficult decisions may need to be made by those leading the group efforts.  Different manners of conflict resolution can be employed such as comment resolutions, necessary meetings and leverage of the community-at-large. 

Although some decisions may not satisfy the entire group, these may need to be made for the good of progress and the community.  Often, these changes can be ratified at a later time. 

Progress despite some challenges
It’s true, no standard development will be flawless.  Most of the time, members may run into all five of these issues—maybe even more, depending on the circumstances.  However, it’s important to realize the benefit of Open Standards in today’s embedded market. 

The value of being open and fast-tracking developments can only work with active participation of all members. 

More often than not, the benefits of driving these groups to completion far outweigh both the time and resources demanded.  This results not only in new technologies for the industry, but in benefits that represent the interests of your company within a wide variety of specifications.  The future of Open Standards is now, but only through active participation.

Article by: Jerry Gipper, VITA Executive Director

Published by: Electronic Design

VITA and its members play a key role in the critical embedded computing industry. Technology innovation by these members have opened the doors to new applications in several industries. VITA, the organization that provides an environment for the development and evangelization of these technologies has entered a new chapter in its history. There were key changes in personnel at VITA in 2014 that also included many improvements to the tools the members use for collaboration. 2015 promises to continue with more improvements on the roadmap including a re-kindling of VITA’s international appeal; reinforcing VITA’s tradition of creating the best open architectures, open standards remain the sole focus.

Read more . . .