Follow us:

MDA Success Story

How an Open Standard Development Process Led to an MDA-like Solution

Open System Architecture for Condition Based Monitoring (OSA-CBM) is a developing standard for open, integrated, condition-based monitoring system. It specifies a set of application pro-grammer interfaces (API) in various target platforms, such as OMG CORBA, COM/DCOM, XML, and CIP.

The key challenge was to keep the standard independent from any technology, while providing definitions that ensure binary compatibility. Also, this standard must be congruent with existing standards for condition-based monitoring. This paper describes the overall structure of the OSA-CBM framework and its relation to OMG MDA.

Project background
An industry led team partially funded by the Navy through a DUST (Dual Use Science and Technology) program was asked to develop and demonstrate an Open System Architecture for Condition Based Maintenance specification model. The team participants cover a wide range of industrial, commercial, and military applications of CBM technology: Boeing, Caterpillar, Rockwell Automation, Rockwell Scientific Company, Newport News, and Oceana Sensor Technologies. Other team contributors include the Applied Research Laboratory at Penn State and MIMOSA (Machinery Information Management Open System Alliance). The team's focus was developing and demonstrating an open software architecture standard that would facilitate interoperability of CBM software modules.

Key OSA-CBM challenges:

• Standard must be independent of any technology. In other words, the standard will not rely on a single communication technology or single operating system.
•  Standard must ensure binary compatibility. This means that if two parties develop two components using the same communication technology, the compliancy with the standard ensures component interoperate.
• Standard must confirm with existing standards and technologies that relate to condition-based monitoring.

The first two challenges seem to be contradicting each other. The OSA-CBM standard should be independent of any technology, but specific enough to ensure binary compatibility. A specifica-tion and development approach that satisfied both requirements was researched. At that time nothing like MDA was available, thus the team developed its own solution. The approach that was developed by the OSA/CBM team, in retrospect, seems to be very similar to the OMG MDA.

Development process for a new standard
Platform independence and binary compatibility were defined as major requirements for the OSA-CBM emerging standard. In other words, the standard should specify optimal target definitions for each target platform, such as OMG CORBA IDLs, Microsoft IDLs, or XML Schemas. It was necessary to build the OSA-CBM standard on top of middleware technologies to abstract from implementation details of communication, operating system implementation, etc., as well as to allow for easier integration with legacy systems.

To permit interoperability between OSA-CBM compatible components across different target platforms, all of the target definitions must share some common ground. Therefore, they should describe the same concepts and share vocabulary as well as semantics.

A process similar to MDA was used to reach the goal of developing a set of optimal and yet interoperable target definitions. The process consists of these four steps:

1. A domain analysis was conducted, gathering information from domain experts and related standards. As a result, an object model for the CBM domain was created in the form of a Unified Modeling Language (UML) static class diagram. We have used only a subset of UML to keep the meta-model as simple as possible. Namely, packages, classes with attributes, generalizations, and associations were employed.

2. For practical reasons, the domain object model was rearticulated as an Abstract Interface Definition Language (AIDL) model. This is a textual file with syntax similar to OMG CORBA IDL. It stores the object relationships, documentation, and some extending information. Due to the extensions, we have avoided using the OMG CORBA IDL directly. Technically, it is a subset of IDL extended with user-defined tags.

3. The AIDL model was mapped to implementation models. During this phase it is decided how the abstract concepts from the domain model map to elements of target platforms, such as remote interfaces, messages, data types, etc. Also, the models are extended with non-domain information, such as GUID definitions, etc. The platform specific models are stored in AIDL format as well.
The implementation model is a convenient definition of what the abstract concepts look like for a given target platform. Using a common syntax makes these models understandable for people without detailed knowledge of the target platform, yet these models contain all the information necessary to produce the target definition. In other words, the implementation model reformulates the abstract concepts in terms of communication elements: message types and remote objects.

4. Target definitions, like OMG CORBA IDL, Microsoft COM / DCOM IDL, or XML Schema are produced from the platform specific models. These target definitions are specific to a concrete target platform. They fulfill all the formal requirements for each platform, such as definition of namespaces, GUID definitions, or external references.

Figure 1 illustrates the OSA-CBM development process. The boxes depict documents, such as UML diagrams, AIDL models, or platform target definitions. The numbered arrows relate to development process steps.

Figure 1 The development process

There exist many concrete results of described development process for the target platforms:

• Microsoft COM/DCOM platform
  The COM/DCOM implementation model was used to generate MIDL description of COM/DCOM implementation model, HTML documentation of implementation model, and source codes of C++ objects implementing OSA/CBM interfaces.
• OMG CORBA platform
  CORBA IDLs for Real Time CORBA middleware were defined from CORBA implementation model.
  CIP platform
  The CIP implementation model was used to generate HTML documentation that describes OSA-CBM CIP related object specification.
• XML platform
  XML implementation model was used to generate XML schemas.
  

Example of development process
The development process transforms domain description to software definitions. A small portion of an UML domain model is shown in Figure 2.

Figure 2 Example of a UML domain model

The same domain concepts are expressed in AIDL notation and extended with textual descriptions, see Figure 3. This AIDL model was defined in a generic syntax in order to promote interoperability between implementations in different technologies. The AIDL model makes use of special tags that aid in manual or automated generation of implementation models.

Figure 3 Example of an AIDL domain model

The transformation of the domain model to an implementation model yields results shown in Figure 4.

Figure 4 Example of implementation model for COM / DCOM middleware

During the last step, the implementation model is transformed to a specification for a given target platform. In our example, this step produces part of IDL file shown in Figure 5.

Figure 5 Example of IDL definition for Microsoft COM/DCOM

The development process uses domain analysis as the input and produces target definitions for concrete target platforms. The domain concepts of the abstract domain model are transformed to target platform concepts and gradually to platform-specific elements, such as structures, enums, and interfaces.

Some parts of the development process can be automated. Step 1 has to be done by a domain expert. Step 2 rewrites the domain model from one notation (UML) to another (AIDL), with extensions that support the mapping to the individual implementation models. This process was done manually although it would be possible to automate it. During Step 3, it must be decided which domain concepts map to which elements of a concrete target platform. We can see a possibility to automate this step, but since the rules used here are very complex, we have not automated this step. Step 4 has much simpler rules for transformation in comparison with 3 and has been successfully automated for some target platforms.

Benefits of our solution
The proposed solution has provided many benefits during initial development, through evolution and improvement, and now during maintenance of the OSA-CBM standard:

• Domain model is expressed independently from any concrete target platform. It is fully focused only on domain description.
•  Domain model is easy to maintain and improve.
•  Rapid and safe propagation of model changes to target specifications because the rules of mapping remain the same.
•  Standard can be easily extended to new target platforms.
• The whole approach can be used for other domains; only the domain model should be created
  
  

Relationship between OSA-CBM development process and MDA
As described above, the whole development process of OSA-CBM standard seems to be very similar to MDA development cycle. Below is a table that shows how the OSA-CBM development compares to the MDA development process.

Conclusion
Our model-based strategy proved to be a viable approach for executing the OSA/CBM project. It assisted in capturing of the domain information, its transformation to sets of software definition for target platforms, and production of relevant documentation. Also, our approach contributed to a significant reduction of time while preparing project demos and application prototypes.

In retrospect, we have independently developed a strategy that is very close to MDA in the overall concept, steps, and the use of technology. The successful results in the OSA/CBM program are proof that MDA is a viable approach that should be further extended and put in use. In the near future, we will consider to switch from our homegrown solution to the MDA process, because it is (1) an open standard, (2) it uses widely accepted tools, and (3) it should provide standardized mappings from PIM to PSM for many platforms.