OPAF experience: not all standards are created equally

Being involved with other important standards efforts in the past (both hardware and software related), it was clear that each shares much in common, but this one is different in one important way.

At a simplistic, high level, here is what is involved in creating a standard – this after the initial vision has been formed, and a decision to engage has been taken:

• Companies representing end users become involved (or in this case, actually hatched the  original idea)
• Suppliers become involved
• Formal processes are adopted and followed (under the auspices of an established and trusted standards body)
• Committees and subcommittees are formed and staffed
• Charters are adopted
• A framework and timeline is established
• Regular meetings are held, both face-to-face and over the phone
• Minutes are taken and published…many times
• Skeleton documents and outlines are created
• Content is drafted, informally reviewed and revised.  This cycle is repeated many times until all parties involved are satisfied (or eye-drop liquid is exhausted)
• Final drafts are submitted and formal reviews are held
• Voting takes place, the standard is ratified
• The newly adopted standard is then published, the industry reacts, raucous cheering is heard
• Work continues on the next version…

Breault became involved with OPAF in March of 2018, attending his first face-to-face meeting in April. At that time, the committees had been formed, charters adopted and some of the general frame work was in place.

Based on what was heard the leadership team wanted to accomplish, and assumed a target of two or three years.  To say being surprised and taken aback that the target for initial publication was in less than a year away would be an understatement!  None of the prior experience with standards suggested such a target would be reasonable or achievable.

Well, December now finds us, completing a formal review of a set of well written technical documents.  These documents cover such topics as Technical Architecture, Communications Framework, System Management, Security, and Component Profiles.  It’s actually quite shocking at the progress that has been made!

To be sure, getting this far hasn’t been easy: weekly conference calls across many groups; monthly face-to-face meetings; countless discussions; proposals and reviews; unspeakable quantities of coffee. Even with all that, we wouldn’t have moved forward as rapidly and smoothly as we did without a lot of heavy lifting on the part of a small subset of individuals (you know who you are) and the relentless drive forward by the OPAF leadership team.

While we’re not over the final hurdles yet, the end of the race is in sight – at least for the first version.

Once the specification is adopted and published, then the work at Wind River will be to use that specification to inform and influence future product direction. Titanium Control, the industrial software virtualisation platform, VxWorks the real-time operating system, and Wind River Linux, the commercial Linux distribution may all be influenced in some way by this specification and the goals it represents.

Breault: “2018 has been an incredible year for the OPAF community and I am proud to have been a part of it, working alongside some truly remarkable individuals.  My takeaway from this activity is that many standards are created using similar processes, but clearly not all standards are created equally!”

Courtesy of Wind River.