Remedy IT revised submission for the Unified Component Model (UCM) for Distributed, Real-Time and Embedded Systems. Change of address Remedy IT: Melkrijder 11 3861 SG Nijkerk tel. +31 (0)88 053 0000

1. Date: February 2015
Revised Submission
Unified Component Model (UCM)
for
Distributed, Real-Time and Embedded Systems
Core Component
Remedy IT
Melkrijder 11
3861 SG Nijkerk
http://www.remedy.nl
Tel: +31-10-5220139
Primary contact: Johnny Willemsen (jwillemsen@remedy.nl)
OMG Document Number: mars/2015-01-01

2. Copyright © 1997-2012 Object Management Group.
Copyright © 2014-2015 Remedy IT
USE OF SPECIFICATION - TERMS, CONDITIONS & NOTICES
The material in this document details an Object Management Group specification in accordance with the terms, conditions and
notices set forth below. This document does not represent a commitment to implement any portion of this specification in any
company's products. The information contained in this document is subject to change without notice.
LICENSES
The companies listed above have granted to the Object Management Group, Inc. (OMG) a nonexclusive, royalty-free, paid up,
worldwide license to copy and distribute this document and to modify this document and distribute copies of the modified version.
Each of the copyright holders listed above has agreed that no person shall be deemed to have infringed the copyright in the
included material of any such copyright holder by reason of having used the specification set forth herein or having conformed any
computer software to the specification.
Subject to all of the terms and conditions below, the owners of the copyright in this specification hereby grant you a fully-paid up,
non-exclusive, nontransferable, perpetual, worldwide license (without the right to sublicense), to use this specification to create and
distribute software and special purpose specifications that are based upon this specification, and to use, copy, and distribute this
specification as provided under the Copyright Act; provided that: (1) both the copyright notice identified above and this permission
notice appear on any copies of this specification; (2) the use of the specifications is for informational purposes and will not be
copied or posted on any network computer or broadcast in any media and will not be otherwise resold or transferred for
commercial purposes; and (3) no modifications are made to this specification. This limited permission automatically terminates
without notice if you breach any of these terms or conditions. Upon termination, you will destroy immediately any copies of the
specifications in your possession or control.
PATENTS
The attention of adopters is directed to the possibility that compliance with or adoption of OMG specifications may require use of
an invention covered by patent rights. OMG shall not be responsible for identifying patents for which a license may be required by
any OMG specification, or for conducting legal inquiries into the legal validity or scope of those patents that are brought to its
attention. OMG specifications are prospective and advisory only. Prospective users are responsible for protecting themselves
against liability for infringement of patents.
GENERAL USE RESTRICTIONS
Any unauthorized use of this specification may violate copyright laws, trademark laws, and communications regulations and
statutes. This document contains information which is protected by copyright. All Rights Reserved. No part of this work covered
by copyright herein may be reproduced or used in any form or by any means--graphic, electronic, or mechanical, including
photocopying, recording, tng, or information storage and retrieval systems--without permission of the copyright owner.

3. DISCLAIMER OF WARRANTY
WHILE THIS PUBLICATION IS BELIEVED TO BE ACCURATE, IT IS PROVIDED "AS IS" AND MAY CONTAIN
ERRORS OR MISPRINTS. THE OBJECT MANAGEMENT GROUP AND THE COMPANIES LISTED ABOVE MAKE
NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH REGARD TO THIS PUBLICATION, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY OF TITLE OR OWNERSHIP, IMPLIED WARRANTY OF
MERCHANTABILITY OR WARRANTY OF FITNESS FOR A PARTICULAR PURPOSE OR USE.
IN NO EVENT SHALL THE OBJECT MANAGEMENT GROUP OR ANY OF THE COMPANIES LISTED ABOVE BE
LIABLE FOR ERRORS CONTAINED HEREIN OR FOR DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
CONSEQUENTIAL, RELIANCE OR COVER DAMAGES, INCLUDING LOSS OF PROFITS, REVENUE, DATA OR
USE, INCURRED BY ANY USER OR ANY THIRD PARTY IN CONNECTION WITH THE FURNISHING,
PERFORMANCE, OR USE OF THIS MATERIAL, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
The entire risk as to the quality and performance of software developed using this specification is borne by you. This
disclaimer of warranty constitutes an essential part of the license granted to you to use this specification.
RESTRICTED RIGHTS LEGEND
Use, duplication or disclosure by the U.S. Government is subject to the restrictions set forth in subparagraph (c) (1) (ii) of The
Rights in Technical Data and Computer Software Clause at DFARS 252.227-7013 or in subparagraph (c)(1) and (2) of the
Commercial Computer Software - Restricted Rights clauses at 48 C.F.R. 52.227-19 or as specified in 48 C.F.R. 227-7202-2 of
the DoD F.A.R. Supplement and its successors, or as specified in 48 C.F.R. 12.212 of the Federal Acquisition Regulations and
its successors, as applicable. The specification copyright owners are as indicated above and may be contacted through the
Object Management Group, 140 Kendrick Street, Needham, MA 02494, U.S.A.
TRADEMARKS
MDA®, Model Driven Architecture®, UML®, UML Cube logo®, OMG Logo®, CORBA® and XMI® are registered
trademarks of the Object Management Group, Inc., and Object Management Group™, OMG™ , Unified Modeling
Language™, Model Driven Architecture Logo™, Model Driven Architecture Diagram™, CORBA logos™, XMI Logo™,
CWM™, CWM Logo™, IIOP™ , IMM™ , MOF™ , OMG Interface Definition Language (IDL)™ , and OMG Systems
Modeling Language (OMG SysML)™ are trademarks of the Object Management Group. All other products or company
names mentioned are used for identification purposes only, and may be trademarks of their respective owners.
COMPLIANCE
The copyright holders listed above acknowledge that the Object Management Group (acting itself or through its designees) is
and shall at all times be the sole entity that may authorize developers, suppliers and sellers of computer software to use
certification marks, trademarks or other special designations to indicate compliance with these materials.
Software developed under the terms of this license may claim compliance or conformance with this specification if and only if
the software compliance is of a nature fully matching the applicable compliance points as stated in the specification. Software
developed only partially matching the applicable compliance points may claim only that the software was based on this
specification, but may not claim compliance or conformance with this specification. In the event that testing suites are
implemented or approved by Object Management Group, Inc., software developed using this specification may claim
compliance or conformance with the specification only if the software satisfactorily completes the testing suites.

5. OMG’s Issue Reporting Procedure
All OMG specifications are subject to continuous review and improvement. As part of this
process we encourage readers to report any ambiguities, inconsistencies, or inaccuracies they
may find by completing the Issue Reporting Form listed on the main web page http://
www.omg.org, under Documents, Report a Bug/Issue (http://www.omg.org/technology/agree-
ment.htm).

6. mars/2014-05-01 i
Preface..........................................................................................iii
1 Scope 1
2 Conformance 1
3 Normative References 1
4 Terms and Definitions 1
5 Symbols 2
6 Additional Information 2
6.1 Changes to Adopted OMG Specifications 2
6.2 How to Read this Specification 2
6.3 Acknowledgements 2
7 Platform Independent Model (PIM) 5
7.1 Overview 5
7.2 High Level Overview 5
7.3 Container 6
7.4 Execution Model 6
7.5 Component 6
7.5.1 Component Lifecycle 6
7.5.2 Configuration Values 7
7.5.3 Facets 7
7.5.4 Receptacles 7
8 IDL Platform Specific Model 11
8.1 Introduction 11
8.2 Core 11
8.3 Container 11
8.4 Component 11

7. ii mars/2014-05-01

8. mars/2015-01-01 iii
Preface
About the Object Management Group
OMG
Founded in 1989, the Object Management Group, Inc. (OMG) is an open membership, not-for-profit computer industry
standards consortium that produces and maintains computer industry specifications for interoperable, portable and
reusable enterprise applications in distributed, heterogeneous environments. Membership includes Information
Technology vendors, end users, government agencies and academia.
OMG member companies write, adopt, and maintain its specifications a mature, open process. OMG's specifications
implement the Model Driven Architecture® (MDA®), maximizing ROI through a full-lifecycle approach to enterprise
integration that covers multiple operating systems, programming languages, middleware and networking infrastructures,
and software development environments. OMG's specifications include: UML® (Unified Modeling Language™);
CORBA® (Common Object Request Broker Architecture); CWM™ (Common Warehouse Metamodel); and industry-
specific standards for dozens of vertical markets.
More information on the OMG is available at http://www.omg.org/.
OMG Specifications
As noted, OMG specifications address middleware, modeling and vertical domain frameworks. All OMG Specifications
are available from this URL:
http://www.omg.org/spec
Specifications are organized by the categories:
Business Modeling Specifications
Middleware Specifications
• CORBA/IIOP
• Data Distribution Services
• Specialized CORBA
IDL/Language Mapping Specifications
Modeling and Metadata Specifications
• UML, MOF, CWM, XMI
• UML Profile
Modernization Specifications

9. iv mars/2015-01-01
Platform Independent Model (PIM), Platform Specific Model (PSM), Interface Specifications
• CORBAServices
• CORBAFacilities
OMG Domain Specifications
CORBA Embedded Intelligence Specifications
CORBA Security Specifications
All of OMG’s formal specifications may be downloaded without charge from our website. (Products implementing OMG
specifications are available from individual suppliers.) Copies of specifications, available in PostScript and PDF format,
may be obtained from the Specifications Catalog cited above or by contacting the Object Management Group, Inc. (as of
January 16, 2006) at:
OMG Headquarters
109 Highland Ave
Needham
MA 02494 USA
USA
Tel: +1-781-444-0404
Fax: +1-781-444-0320
Email: pubs@omg.org
Certain OMG specifications are also available as ISO standards. Please consult http://www.iso.org
Issues
The reader is encouraged to report any technical or editing issues/problems with this specification to http://www.omg.org/
report_issue.htm.

10. mars/2015-01-01 1
1 Scope
This specification defines the Unified Component Model (UCM) for Distributed, Real-Time and Embedded Systems.
2 Conformance
This specification defines X conformance points. Implementations must support at least one of these conformance points:
• TBD
3 Normative References
The normative documents contain provisions which, through reference in this text, constitute provisions of this
specification. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply.
• Asynchronous Method Invocation for CORBA Component Model [AMI4CCM] formal/2013-04-01
• Common Object Request Broker [CORBA] formal/2012-11-12
• Deployment and Configuration of Component-based Distributed Applications [DEPL] formal/2006-04-02
• Quality of Service for CCM [QOS4CCM] formal/2008-10-02
• Data Distribution Service [DDS] formal/2007-01-01
• DDS for Lightweight CCM [DDS4CCM] formal/2012-02-01
• IDL to C++11 [CPP11] formal/2014-01-01
• IDL4 [IDL4] mars/2014-12-01
• Robotic Technology Component [RTC] formal/2012-09-01
• TAO AMH [AMH] https://www.dre.vanderbilt.edu/~schmidt/PDF/AMH2.pdf
• RPC over DDS [RPCDDS] http://www.omg.org/techprocess/meetings/schedule/RPC_over_DDS_RFP.html
4 Terms and Definitions
For the purposes of this specification, the following terms and definitions apply.
Component
A specific, named collection of features and capabilities that can be described by a component definition
Component Executor
The user created business logic implementation for a specific component
Connector

11. 2 mars/2015-01-01
A logical entity that defines a specific interaction pattern between components, per GIS concepts. A connector is
defined by an aggregation of port types, each of which identifies a particular role to play in the connector's
interaction pattern.
Container
A container provides the execution environment for a component
Facet
A port that defines a service a component provides
Receptacle
A port that defines a service a component uses
Generic Interaction Support (GIS)
The generic connector concept as defined in the IDL4 specification
Port
Fundamental interaction mechanism used by a connector to allow components to communicate with each other.
5 Symbols
List of symbols/abbreviations.
6 Additional Information
6.1 Changes to Adopted OMG Specifications
None
6.2 How to Read this Specification
The rest of this document contains the technical content of this specification.
Although the chapters are organized in a logical manner and can be read sequentially, this reference specification is
intended to be read in a non-sequential manner. Consequently, extensive cross-references are provided to facilitate
browsing and search.
6.3 Acknowledgements
The following companies submitted and/or supported parts of this specification:
• Northrop Grumman Corporation (NGC)

12. mars/2015-01-01 5
7 Platform Independent Model (PIM)
7.1 Overview
The Unified Component Model (UCM) for Distributed, Real-Time and Embedded Systems is defined as a Platform
Independent Model (PIM). This PIM can be transformed into the IDL Platform Specific Model (PSM) defined in Section
8 of this document, or into alternative PSMs.
UCM is defined as a suite of specifications that supplement the UCM core component model as defined in this document.
Future supplements could specify interaction models, deployment models, or possible generic or domain specific
extensions.
UCM focuses on distributed, real-time and embedded systems. The generic meta model defines a platform and
communication middleware agnostic component model. Using Generic Interaction Support (GIS) UCM defines standards
based interoperability between components at deployment time without tying UCM to a specific communication
middleware.
The separation between the Platform Independent Model and the Platform Specific Model makes it possible to specialize
a UCM implementation for a specific environment.
The UCM meta model enables the modeling of the type system, interfaces, ports, and components. This meta model is a
subset of the IDL4 [IDL4] meta model.
7.1.1 Core Component Overview
UCM defines a unified component model in order to model, implement, and deploy modular software components in a
standardized way. Components use ports to provide and use services to/from other entities including (but not limited to)
UCM components, other (legacy) software services, and hardware devices. Ports provide the specific role-based
connections using different interaction patterns which at the end allow interaction with other entities.
Components are hosted at deployment time by a UCM container. The container provides services to a “component
executor” which implements the user business logic. The container also provides a standardized “deployment API” for
managing components hosted by the UCM container. Using this standardized API additional deployment models can be
defined. These deployment models can, for example, use the OMG Deployment and Configuration [DEPL] standard. In
more constrained environments a minimalistic deployment model can use this standardized API.
At deployment time a connector-defined interaction pattern is implemented by a connector fragment which is deployed
collocated with the component in the container. The connector fragment implementation handles interoperability of the
port using a specific communication mechanism. In a minimalistic environment the port could directly be implemented
using a specific communication mechanism leading to a smaller implementation but less flexibility for the deployment
model.
An implementation of UCM uses a specific PSM. Components implemented using different PSMs interoperate when they
use the same connector-defined interaction pattern with the same communication mechanism.
Components can be grouped together to form an assembly. Either a component or an assembly can be deployed as one
entity by the deployment model.

13. 6 mars/2015-01-01
7.1.2 Container
The UCM container hosts the components at deployment time. The container exposes a “deployment API”. This
deployment API provides an API to manage the set of hosted components within the container. This can for example be
used by a deployment tool that interacts with the container or a monitor tool that provides insight into the running system.
The deployment API of the container consists out of the following operations:
• install_component: installs a component into this container.
• get_component: retrieves a component from this container.
• uninstall_component: removes a component from this container.
7.1.3 Execution Model
The default UCM execution model is a single threaded and non reentrant model with inversion of control. This model is
the simplest execution model, but will not work for all UCM based systems. UCM will not restrict the number of different
execution models.
7.1.4 Component
A component definition can use attributes and ports. Ports define the services that are used and provided by a component.
Facets are the ports that define the services the component provides, receptacles are the ports that define the services the
component uses. A component definition can inherit from another component definition.
A component has a predefined lifecycle during its existence. Based on the user provided component definition, the same
implied component API is always created. This is a generic and minimalistic API that must be implemented by the component
developer as the “component executor”.
7.1.4.1 Component Lifecycle
A component goes through a predefined lifecycle during its existence. Using the lifecycle callbacks the component
executor can react at specific predefined points in its existence. These lifecycle callbacks are called by the deployment
model in the run-time environment at predefined moments. The following lifecycle callbacks are specified:
• on_create: the component has been created and together with this callback the unique component instance id, the
component configuration values, and the container in which this component has been created are passed. On successful
return of this operation the component changes from created state to the passive state, on failure the component stays
in the passive state. When this operation returns successfully it has to be ready to serve these incoming requests.
• on_activate: the component is allowed to make outgoing requests and changes from the passive state to the active
state.
• on_passivate: the component must stop making outgoing requests and but still should expect incoming requests. It
changes to the passive state.
• on_remove: the component changes from the passive state to the created state. It could now get destroyed, or get a dif
• on_destroy: the component is not needed anymore and can cleanup its final resources and destroy itself.

14. mars/2015-01-01 7
7.1.4.2 Configuration Values
Components can define attributes using the UCM type system. The concrete attribute values are passed at deployment
time as a sequence of string/any pairs to the on_create lifecycle operation.
7.1.4.3 Facets
A facet is a port that is provided by a component. As part of the implied component definition the following operation is
specified:
• get_facet: returns a reference to a component facet. This operation has the facet name as an argument and returns a
reference to the facet. This operation can be called in the passive and active states.
7.1.4.4 Receptacles
A receptacle is a port that is used by a component. Receptacle references will be provided to the component at deployment
time. Receptacle references are made available to the component business logic to support dynamic connection changes. The
following implied component operation can be called in the created, passive, and active states:
• set_receptacle: provides a receptacle reference to the component and returns the previously set reference to the caller.
A nil reference can be passed to indicate that a previously provided reference has to be released.

15. 8 mars/2015-01-01

16. mars/2015-01-01 11
8 IDL Platform Specific Model
This chapter describes the IDL PSM for UCM. The IDL within this chapter can be translated to a specific programming
language using the already existing standardized IDL Language Mappings.
As reference for the IDL specification this submission refers to IDL4 [IDL4]. From IDL4 the UCM IDL PSM uses the
following building blocks:
• Core Data Types
• Extended Data-Types
• Interfaces - Basic
• Components - Basic
• Extended Ports and Connectors
• Template Modules
8.1 Introduction
In the context of UCM all IDL interfaces are local interfaces.
8.2 Core
The UCM core IDL types are all defined in the ucm.idl IDL file.
8.3 Container
The container provides a deployment API which further refined in a future revision of this document. The container
interfaced is defined in ucm_container.idl.
module UCM {
interface Container {
// Install a component into the container
void install_component (in string component_id, in UCM::Component comp);
// Retrieve a component from the container but keep it installed
UCM::Component get_component (in string component_id);
// Uninstall the component from the container, will return the component
UCM::Component uninstall_component (in string component_id);
};
};
8.4 Component
All UCM components are mapped to UCM::Component in the UCM Core IDL PSM which is defined in
ucm_component.idl.
module UCM {
struct ConfigValue {

17. 12 mars/2015-01-01
string name;
any value;
};
typedef sequence<ConfigValue> ConfigValues;
typedef sequence<string> NameList;
exception ConfigurationError {
// List of config value names which we were unable to set
NameList name_list;
};
// Exception thrown when the component doesn’t support the provided facet
exception UnknownFacet {
// Name of the facet that is not support, simplifies tracing and logging heavily by putting
// this into the exception
string facet_name
};
// Exception thrown when the component doesn’t support the provided receptacle
exception UnknownReceptacle {
// Name of the receptacle that is not support, simplifies tracing and logging heavily by putting
// this into the exception
string receptacle_name
};
interface Component {
void on_create (in string instance_id, in ConfigValue values, in Container the_container)
throw (ConfigurationError);
void on_activate ();
void on_passivate ();
void on_remove ();
void on_destroy ();
object get_facet (in string facet_name)
throw (UnknownFacet);
object set_receptacle (in string receptacle_name, in object reference, in string connection_name)
throw (UnknownReceptacle);
};
};