An Operations and Maintenance Information Open System Alliance

MIMOSA CCOM

MIMOSA CCOM (Common Collaborative Object Model) serves as an information model for the exchange of asset information. Its core mission is to facilitate standards-based interoperability between systems: providing an XML model to allow systems to electronically exchange data.

Releases

MIMOSA CCOM is released under the MIMOSA License Agreement.

Title Specificaton File Date
CCOM 4.0.0 Package icon ccom-4.0.0.zip, Package icon ccom-reference-data-4.0.0.zip Friday, 30 September 2016

What's New

Past OSA-EAI releases have been based on CRIS (Common Relational Information Schema), which was designed as a persistence model and also used as an exchange model. The focus for CCOM is on effectively representing data for the purpose of data exchange and by adopting object-oriented concepts such as inheritance, CCOM provides a cleaner and more flexible model for Enterprise Application Integration.

CCOM uses a similar approach to the other OpenO&M organizations in leveraging the UN/CEFACT Core Component Types and OAGIS Platform Specification. The latter has been employed due to the move toward message-based integration in order to fit within the MIMOSA OIIE Architecture. Thus, the Tech-XML Web Services of prior OSA-EAI release have been migrated to CCOM BODs (Business Object Documents) that can be used in conjunction with any message transport specification, such as the OpenO&M ws-ISBM.

Getting Started

If you're not familiar with CCOM:

  • Review the MIMOSA OIIE Architecture, Use Cases and Scenarios and see how the CCOM fits within the interoperability architecture
  • Read this page including the links to the UML Class Model diagrams and BODs

If you're developing an adapter and want to get started:

Principles

CCOM has been developed according to the following principles:

  • Open collaboration. All organizations are invited to be part of the development process.
  • Open specification. Releases are available freely for anyone to download and use.
  • Industry, organization and product agnostic. Requirements must be "common" across industries or organizations or to various classes of software products and not proprietary.
  • Pragmatic technology selection. Using mature, well tested technologies that have broad adoption by owner/operators and the IT industry: between bleeding-edge and legacy.
  • Reference rather than reimplement. Use existing standards where possible and reference files rather than redefine.

Architecture

CCOM follows the other MIMOSA standards in following the layered architecture specified by ISO 13374-2, but collapsing the first two layers due to the integrated capabilities in UML documentation tooling.

Each of these components are addressed in sections below.

Information Scope

OSA-EAI addresses the following categories of asset-related information:

UML Class Model

The UML Class Model provides a diagrammatic representation of CCOM. In addition, documentation is provided for classes, attributes and associations to explain concepts. The UML Class Model can be viewed either as HTML or PDF.

Conventions

The following conventions have been used when developing the UML Class Model:

  • Classes have been color coded:
    • Red to represent an abstract class
    • Green to represent a class whose attributes are visible (usually the primary diagram for the class)
    • White to represent a class whose attributes have been hidden (for diagrammatic clarity)
    • Blue to represent a trait
  • Bidirectional relationships can be considered as two IOR (inclusive or) directional relationships between two classes (an occurrence of either entity must be related to the other entity). For example, the bidirectional relationships between Entity and InfoSource, either the "registers" relationship, "registered by" relationship, or both can specified.
  • As the only implementation of CCOM UML is in XML Schema, XML Schema stereotypes have been added where they add clarity. Invariant constraints (purple color) will also document exclusive choices (i.e. XML Schema choices) to avoid having to create a pseudo-class with the choices as attributes.
  • An <<override>> stereotype has been added to associations to indicate that the association overrides one that is inherited from a superclass. This is usually used to specialize the association, for example, the Type association inherited by Site from Segment is specialized to SiteType rather than SegmentType.
  • As the UN/CEFACT XML Naming and Design Rules are followed for the XML Schema representation, the conventions are also followed for CCOM UML. Classes, XML Element-based attributes and associations are specified in upper CamelCase, while XML Attribute-based are specified in lower CamelCase.

Entity Last Edited Timestamp and Aggregate Children

The semantics of the LastEdited and LastEditor fields must respect all UML Aggregation relationships from the entity. For example, changing adding or modifying a SegmentConnection in a BreakdownStructure must result in a change to the BreakdownStructure's LastEdited and LastEditor fields.

XML Schema

The CCOM XML Schema encodes the CCOM UML Class Model as an implementation model. It serves as the underlying schema when employed as BOD Messages or the sole schema when employed for Compound Document file exchange.

The XML Schema can be viewed as HTML.

The following files are available in the XSD directory:

File Description
CCOM.xsd Primary schema; implementation of the UML Class Model
CoreComponentType_2p0.xsd UN/CEFACT Core Component Types v2.01. Used by CCOM as primitive data types in addition to base XML Schema types.

Conventions

The following conventions have been used when developing the XML Schema:

  • The Venetian Blind design pattern has been adopted as it follows a similar paradigm to most object-oriented programming languages. This makes it straightforward to understand how the XML Schema types match application classes (e.g. code generated classes from the XSD).
  • The UN/CEFACT XML Naming and Design Rules are followed such that types and elements are specified in upper CamelCase, while attributes are specified in lower CamelCase.

Reference Data

CCOM provides an industry-agnostic information model; however, it allows for industry specificity through the use of Reference Data. For example, an asset can be classified as a pump by associating the Asset with a Pump AssetType.

While MIMOSA publishes a basic reference data set for the CCOM, it is not mandatory to use. Other international, industry, or company-specific reference data libraries can be used instead as long as all parties using CCOM for data exchange are made aware what reference data will be used.

The following files are available in the Reference Data package:

File Description
CCOM Reference Data.xml A list of all the types (classes) provided in the release.
CCOM Reference Data Taxonomy.xml The same types from CCOM Reference Data.xml but organized into hierarchical taxonomies.
CCOM Reference Data Constraints.xml Indicates restrictions on which AttributeTypes from CCOM Reference Data.xml should be used for which classes.
CCOM Reference Data.xlsx An Excel-formatted conversion of the CCOM Reference Data that provides easier human-readability than XML.

Undetermined Types

The CCOM Reference Data contain Undetermined records for subclasses of BaseType. This is to allow an application to explicitly indicate that the type is unknown at a point in time; rather than omitting an element or using xsi:nil, both of which infer different semantics.

The following subclasses specifically do not have an Undetermined record, because it does not make sense in all contexts/usages of the class:

  • AlgorithmProcessType
  • AmbiguitySetType
  • EffectiveStatusType
  • LogicalConnectorType
  • MultiParameterType
  • OSACBMDataType
  • OSACBMFunctionBlockType
  • StandardDataType

Data Exchange

OSA-EAI supports two methods of data exchange between applications: (1) as a compound document and (2) as BOD messages. Selecting which method to use is case-specific, but in general, if integration is required between applications in an ecosystem, use BOD messages; if data just needs an XML representation (e.g. for storage and consumption by public), use compound documents.

Compound Documents

Compound Documents simply provide a container for CCOM XML objects and does not restrict what content can be inserted nor the top-level order of objects. It uses the CCOMData element (included in CCOM.xsd), which then can have any combination of entities as sub-elements.

Compound Documents are useful when a large amount of varying data needs to be packaged in an XML file. For example, the OSA-EAI Reference Data uses the Compound Document approach for representing types, taxonomies and constraints, as well as organizations, sites and info sources.

BOD Messages

BOD Messages facilitate a message-oriented exchange between applications by providing additional data and constraints related to a message. The BODs are an additional set of XML Schemas, building on the base CCOM XML Schema (CCOM.xsd) and include support for:

  • The purpose of the message (i.e. BOD name)
  • Message metadata (e.g. identifier, sender, timestamp) based on the OAGIS Platform Specification 1.2.1
  • A verb to indicate how to interpret the noun
  • Nouns that provide a constrained set of CCOM entities

Additional documentation on the structure of a BOD and a description of the metadata and verbs can be viewed here.

Extensibility

CCOM can be extended in several different ways depending on the level of customization required.

  • CCOM does not embed reference data within the schema (e.g. XML Schema enumerations) unless the domain of values is a finite handful (e.g. two options). Instead, it is expected that reference data is identified for an implementation and referenced by the model.
  • The CCOM Attribute model follows the Entity-Attribute-Value (EAV) approach and allows users to define their own custom AttributeTypes for use within the model. For example, a Segment can be assigned an Attribute with an AttributeType of "Cost Code". Thus the "hard-coded" fields within a CCOM class simply represent the "common" fields.
  • The XML Schema can be included in other schemas and used as a set of base types. For example, Segments, Assets, and Models may be referenced from a schema that focuses on a domain outside of the OSA-EAI scope, but allows for a shared asset registry model.
  • Additional BODs can be defined to support specific scenarios.

MIMOSA welcomes all feedback and suggestions for expanding the scope and improving the capability of CCOM.

Versioning

All CCOM releases are designated a version number with the format: MAJOR.MINOR.PATCH.

The MAJOR component is incremented when a non-backward compatible change is introduced. It may include MINOR and PATCH level changes. MINOR and PATCH components must be reset to 0 when the MAJOR component is incremented.

The MINOR component is incremented when backward compatible functionality is introduced. It must be incremented if any functionality is marked as deprecated. It may include patch level changes. The PATCH component must be reset to 0 when the MINOR component is incremented.

The optional PATCH component is incremented when there is a of an error. Correction of errors may not be backward compatible, depending on the error.

Release preview or candidate versions will add a hyphen and a label to the above format, for example, 1.0.0-rc1.

MAJOR, MINOR and PATCH must be non-negative integers and must not contain leading zeroes.

Once a release has been issued, the contents must not be modified. Modifications must be issued as a new release.

XML Schema Versioning

All XML Schema namespaces must include a version number that includes the MAJOR component of its release. The MINOR component is not included since backward compatible XSD changes must also be forward compatible and changing a namespace generally results in code changes.

XML Schemas must also contain a version using the version attribute.

License

The MIMOSA CCOM is released under the MIMOSA License Agreement.