Position Paper for the OMG/DARPA Workshop on Compositional Software
Component Specification and Conformance:
Senior Member Technical Staff, Texas Instruments
Currently Assigned to SEMATECH
What Components must Expose to Compose
Since 1991 SEMATECH has coordinated the efforts of its member companies
and their Manufacturing Execution System (MES) suppliers to define an object
oriented application framework for semiconductor manufacturing. Through
an iterative series of specification releases and feedback cycles, the
SEMATECH CIM (Computer Integrated Manufacturing) Framework is now nearing
its final revision under the SEMATECH banner. These semiconductor manufacturers
and MES suppliers, along with counterparts from around the globe, are now
working to leverage the CIM Framework Specification into a healthy marketplace
of components that can compose to meet the software needs of the next generation
wafer fabrication factories. This process involves efforts to ballot and
adopt the CIM Framework specification within the Semiconductor Equipment
and Material International (SEMI) Standards Organization and to collaborate
with other industries to adopt MES specifications within the Object Management
Group through upcoming Request for Proposals.
This position paper outlines technical issues with the specification
of standard manufacturing components and describes some of the approaches
the SEMI CIM Framework Task Force is considering to help address those
issues. It also links the manufacturing domain efforts to specify
the CIM Framework with the broader activities of the OMG to adopt a Business
Object Facility to solve many of these same problems for many business
The CIM Framework Approach to Component Specification
The CIM Framework consists of a collection of components defined as part
of an object oriented application framework. These component specifications
are intended to serve as contracts for independently developed, but interdependent
software implementations that compose and work together. To achieve this
result, we must:
In the final analysis, the measure of our success will be the multi-supplier
availability of successful, conformant products that can actually compose
and work together in production factory installations.
partition a large and very complex domain into separate software components,
rigorously specify those components, including all required interdependencies,
provide an explicit definition of our conformance expectations.
The SEMI CIM Framework Task Force partitioned the CIM Framework into nine
"sub-frameworks" containing a total of thirty components. Together with
a set of abstract interfaces for base types, a technical architecture document,
and an overarching structure and functional architecture we will manage
the CIM Framework as twelve separate specification documents. The
twelve parts are listed here.
In arriving at this structure, we considered a range of partitions from
a single document for the entire framework (which is what SEMATECH has
done) to a separate document for each component. The key issue we encountered
in defining our partitioning was one of granularity. Some of the contributors
wished to interpret the sub-frameworks as larger course-grained components.
This allowed the possibility of unspecified interactions between the contained
implementations and seemed to map more closely to product boundaries of
current solutions. While this interpretation is pragmatic when considering
current product implementations, it limits the potential for more flexible
composition of future solutions. It could also tend to lock in current
product packaging boundaries.
CIM Framework Structure and Functional Architecture
CIM Framework Architecture Guide
Abstract Base Interfaces (these are not components)
Process Specification Management
Advanced Process Control
Factory Labor Management
Another Task Force consideration was the need to keep components grouped
in framework structures that emphasized the patterns of interactions.
Collecting cohesive sets of components together was deemed necessary to
aid human understanding of the individual components.
The final granularity interpretation adopted by the Task Force was that
each component within a sub-framework be considered an independently composable
unit. Further, we assume that components are not coupled to one another
except through the specified dependencies of the framework. This interpretation
then leads to the next issue: how do we adequately specify the components
so that hidden interactions or dependencies are not needed to implement
The SEMATECH CIM Framework project adopted a specification structure based
on the OMG Object Management Architecture. We continue to supplement OMG
IDL with Rumbaugh OMT models (intended to be migrated to UML) to address
additional exposed semantics.
IDL gives us the foundation for specifications:
Supplemented with extensions for:
We still have a long way to go to achieve the level of rigor required to
specify independent, but composable components. Our specifications
do an adequate job of representing the server-side of the specifications.
We define the operations offered, and the meaning of the information exchanged
through those operations. We also show the events that the components
are expected to generate. Where we encounter difficulty is in specifying
the client side of the dependency. What are the assumptions about
the operations a component requires, the events it consumes, and the collective
behavior that it exhibits through the interactions with the other components?
While we have captured some of these dependencies with models, we have
not achieved the rigor needed to drive conformance testing of collaborative
behaviors. Without additional rigor in the specifications, there
is inadequate foundation for independently developed and composable components.
Behavior Specifications (pre/post conditions, state models, interaction
Relationships and Dependencies
As a co-submitter to the OMG Business Object Facility RFP, SEMATECH
is helping OMG move toward a Business Object Facility and Component Definition
Language to further strengthen our specification toolset. The adoption
of a meta-model and specification language that supplements IDL with the
required concepts, that is expressible with an unambiguous syntax, that
is directly mappable to the existing IDL interfaces, and that supports
conformance measurements will be a needed first step. Then we will
be better prepared to tackle the challenging task of filling in the meaning
of the behaviors and dependencies that must be exposed to enable composition.
While object modeling, especially with the recent adoption of a standard
Unified Modeling Language from OMG, forms the conceptual basis for the
semantic specifications, we still need a still more narrowly targeted mechanism
for capturing the contracts for framework components.
Conformance Points and Levels
The CIM Framework Task Force is still working to define the specific conformance
points for the CIM Framework. While we agree that our goal is conformance
at the component level, current products are still evolving toward component
structuring and may be packaged to conform at a courser granularity for
some time to come. This would mean that products may support all of the
required interfaces and behaviors for a set of components, but may not
be fully decomposed and substitutable at the individual component level.
In order to chart a path from the present reality toward the target of
independent, composable components, we will need to define incremental
ways to define and measure conformance.
We have proposed the following types of conformance for further consideration
and definition. Each of these levels may require different measurement
approaches to validate products against the specification.
Each of these conformance levels are progressive, in that they build upon
prior levels and are necessary for the subsequent levels. Without
architectural conformance, there is no sound basis for a common syntax.
Without the syntactic specification of exposed interfaces, there is nothing
to hang the semantics on. Without exposed semantics, there is no
chance for true substitutability.
Architectural Conformance (required interoperability technology)
Syntactic Conformance (required interfaces)
Semantic Conformance (required behavior in test scenarios)
Substitutability Conformance (proven composition and decomposition)
The Component Specification Challenge: Expose and Minimize
Our collective experience with the CIM Framework has revealed some tension
between exposing semantics and hiding implementation details. The use of
IDL already couples clients to servers through exposed interfaces and couples
components to one another through inheritance. Richer semantic specification
exposes still more coupling through delegation and dependencies across
components. While we aspire to minimize coupling, we recognize that suppressing
semantic content doesn't necessarily reduce coupling, it often just pushes
it into an underground system of hidden dependencies. The coupling
will still be there in implementations and may impede progress toward independence
and composability of components.
By strengthening specification content and rigor we can expose the necessary
areas of coupling between components. Then we can work from that known
base to encapsulate and hide as much as possible to minimize the coupling,
enable implementation choices, foster innovation and increase healthy competition.
Our challenge is to specify and agree on what must be visible to meet our
objectives of partitioned and composable components for MES.
SEMI CIM Framework
Task Force - Europe