Mobies standardization in OMG

This is my personal take on meetings I attended on November 21st and 22nd in Washington D.C. The first meeting was a meeting of contractors in the Mobies DARPA project with OMG representatives. The second was the NEPHEST quarterly meeting.

OMG presentation

UML is an example that shows well how standardization benefits tool vendors as well as tool users. Resistance to standardization from tool vendors is misplaced -- enabling creation of an active marketplace around open standards benefits everybody. The UML tools market is growing at a rate of about 23% per year.

Established OMG standards include

• UML (unified modeling language)
• CORBA (common object request broker architecture)
• CWM (common warehouse meta-model)
• MOF (meta-object format)
• XMI (XML meta-data interchange)

MDA (model-driven architecture) is the "next big thing" and has been in the works for three years or so. The speaker gave an example of practical application of the MDA in the modeling and generation of the fire control system on the F-16. I believe this work was done at Lockheed-Martin. He claimed that about 40 to 60% of the 800 klines of Ada95 code was generated from models and that the total development schedule was reduced by about 20%.

Dave Sharpe from Boeing raised the question that the MDA work was an exercise only, and was not actually deployed. The speaker did not have any further information.

A long discussion occurred concerning definitions of "platform" and independence or dependence on such a thing. It seems fairly clear that the OMG has a different concept of platform from the embedded systems community. In embedded systems world, I think we're much more used to dealing with diverse models and platforms, and active research is addressing ways of integrating and/or reconciling them. Reading through some of the OMG whitepapers, it seems to me that MDA is mostly targeted at large enterprise applications in which the code to be generated tends to be instantiations of generic patterns. (For example, generation of database queries.)

OMG standardization process

The OMG standardization process consists of:

1. An optional RFI (request for information)
2. An RFP (request for proposals)
3. [I think I left something out from my notes here]

RFP submissions are written outside of the OMG. That is, OMG itself does not get involved in the actual writing of standards.

An alternative process called RFC (Request for comment) can be used to fast-track existing specification of interest to only a small constituency. Example: PL/1 binding to CORBA.

The speaker floated a contentious opinion: "Reference implementations are a bad thing."

DARPA/IXO candidates for standardization

Garbor Karsai of VU gave a thought-provoking presentation outlining the various DARPA programs in the area of embedded systems and the possible standardization products that might emerge from them:

	Large-grain	Small-grain
System technologies	ARMS SEC	ANTS NEST
Design technologies	Mobies	PCES

• ARMS --- QoS APIs, ORB support for QoS
• SEC --- Controls APIs, design platforms for assured software
• Mobies -- Interchange formats: HSIF, OTIF, MTF
• ANTS -- Architecture frameworks, ?something? protocols
• NEST --- coordination APIs, composable, lean micro-middleware
• PCES --- Aspect/weaving APIs, componentized/aspectized middleware

In the context of Mobies specifically he suggested that following candidates for standardization work:

• HSIF (hybrid systems interchange format)
• OTIF (open tool integration framework)
• MTF (?)
• ESCF (embedded systems component frameworks)
• ESTI (embedded systems tool interchange)

I was struck in particular by the difference in the Vanderbilt approach to the Berkeley approach (so far). Vanderbilt have made efforts to produce, as a result of their research work, concepts that can be standardized. I predict that this approach to having research work make an impact in the greater community will become more effective than writing software, if not already, then in the next few years, for the simple reason that software is become more and more complex, and the standards approach provides much more leverage.

Results

As a result of the meeting there was a consensus that it would be mutually beneficial for Mobies and the DARPA-sponsored embedded systems research community to be involved in OMG standardization efforts. The vehicle for doing so is a new embedded systems SIG (special interest group), which does not itself have power to propose standards but is able to form a focus from which to feed input into the OMG technical committees.

Why be involved in standardization efforts? (for academics)

The OMG meeting was the first topic of discussion at the Nephest meeting the following day. Joe Cross of LMS asked the academic people there for their take on the standardization issue. I was, quite frankly, surprised that most there were overwhelming positive. Personally, I expect to meet a lot of resistance to the idea, for several reasons:

• Premature standardization kills innovation
• Standardization involves a lot of compromise
• Standardization is extremely time-consuming and does not yield fruits commonly associated with research work, like conference papers or research grants

With help from the assembled and in particular Helen Gill, I arrived at some reasons why the academic community wants to be involved in standardization efforts:

• Impact. This is the big one. If your research has relevance to the broader (including embedded) software community, then feeding it into the OMG standards process is an effective way to "transition" it from research into practice.
• Access to industry resources. Potentially, the standardization process is another way for the university research community to contact and gain access to industry resources. (I'm not so convinced about this myself.)
• "Everyone else is." If you don't get on the boat you'll be left on the shore.

Doug Schmidt of DARPA expects that an embdded systems SIG can be up and running by the next OMG technical committee meeting, in January '03.