OPM as a Basis for Model-Based Enterprise Standards

Report of the ISO TC184/SC5 OPM Working Group

to the Plenary ISO TC184/SC5Meeting, Tokyo 26, 2010

Dov Dori, David Howes, Alex Blekhman, and Richard Martin

Abstract

We report on the activity of the ISO TC184/SC5 OPM Working Group tasked with

examining the adoption of OPM as a basis for both existing and future enterprise

standards, and propose a model-based framework and a meta-model for enterprise

standards authoring—a standard for specifying how to develop enterprise (and later

possibly other) standards. Using ISO/IEC 62264 as a case in point, we demonstrate

the value of switching from text-based or model-accompanying standards to model-

based standards and discuss the merits of OPM as the modeling language and

methodology for this purpose. We conclude with recommendations for the next action

items proposed to be adopted by TC184/SC5 following the outcomes of this year’s

intensive work of the ISO OPM Working Group.

Introduction

Standards in general and enterprise standards in particular are supposed to be a solid

source of authority and must therefore be unambiguous, consistent, and accessible.

However, standards are often criticized as being difficult to use for a variety of

reasons, including inter- and intra-standard consistency, low accessibility, poor

traceability, and ambiguity. A primary source of these problems is the fact that

standards are not model-based. Rather, they are authored using primarily free text,

which is often accompanied by graphical annotations, figures or diagrams. Quite

often, the figures do not match the text or conflict with other figures.

Managing the quality of a technical document such as an ISO standard is a daunting

task given the variety of authors and relationships to other domain standards.

Currently there is no underlying analytical process that provides some sense of

technical document verification and validation.

Moving modeling to the early stage of standard formulating rather than as a post-

processing step has the major advantage of basing the specification on more solid

foundations than free text, which is notoriously susceptible to ambiguities,

discrepancies, and incompleteness. Yet, being aware of the fact that text is and will

remain the primary means of communications amongst humans, many of whom are

non-technical stakeholders, we integrate a human readable text that is derived from

and hence compatible with the model. This way we achieve the best of both worlds:

rigor and formality on the modeling side, along with readability and access to all

stakeholder types on the text side.

Technical documents are usually accompanied with graphics, which can be

illustrations or cartoons, pictures, and diagrams. The diagrams are drawn using

arbitrary symbols and arrow types or an ad-hoc set of symbols invented on-the-fly for

the sake of that particular diagram, possibly with legend. Sometimes the diagram can

be a UML class (or SysML block) diagram, but even then, as we show below, there is

often lack of agreement between the text and the diagram, because the document is

not model-based but at best model-accompanied.

Object-Process Methodology (OPM) [1] offers a holistic approach, backed by a

formal yet intuitive graphic and textual language, for modeling enterprise-related

standards. These standards are intended for such stakeholders as enterprise architects

and executives, system integrators, service providers, device suppliers, and designers

and developers of applications. These professionals are concerned with architecting

enterprises while holistically integrating enterprises. Integration within and across

enterprises encompasses systems that include supply chains, customer relations, the

projects they execute, the products they deliver, the services they get and provide, the

assets they maintain, and any other related components and processes needed to

facilitate automation and integration of their web of systems.

The ISO/TC 184/SC 5 OPM Working Group

ISO Technical Committee 184 Sub-Committee 5 (TC 184/SC 5) is tasked with

developing and overseeing standards related to enterprises. At its Plenary Meeting in

Paris on April 23-24, 2009, ISO/TC 184/SC 5, in Resolution 611 (Paris 21)

unanimously resolved that in order to explore the usefulness of Object Process

Methodology for creating, designing, analyzing, and simulating models of its

standards to improve the development, communication and understanding of these

standards, SC 5 established Object Process Methodology Study Group (OPM SG). A

call for expert mandated by this resolution asked the first two authors to collaborate

on a Terms of Reference document [3] for this study group that is to accompany the

call of experts. In response, a group of 27 experts from a dozen countries, listed in

Appendix B, expressed interest in participating in the WG. The WG conducted online

sessions and frequent electronic exchange of documents and models. The next

milestone in this standardization process is a report of OPM SG to the next ISO TC

184/SC5 Plenary at the end of March, 2010, in Tokyo.

OPM SG has been tasked with the goal of investigating the viability of using OPM as

a methodology and modeling language for the purpose of streamlining, formalizing,

and explicating the standard ontology and glossary, and making enterprise-related

standards more comprehensive, accessible, usable, and consistent both internally and

across standards. Five specific objectives were stated. The first is to identify needs

and requirements for elevating the levels of accessibility, inter- and intra-standard

consistency, coverage of enterprise-related domains by standards, and other desirable

features that a set of inter-related enterprise standards should exhibit. The second

objective is to examine problems and missing integration or verification activities in

current practices for developing and maintaining enterprise standards. Another

objective is to elicit requirements from a modeling language perspective and examine

advantages and disadvantages of current possible conceptual modeling language

candidates that potentially meet the requirements, including (but not necessarily

limited to) SysML, PSL (ISO 18629), BPMN, and OPM. Finally, using examples,

lessons need to be learned and generalized in modeling of ontology and glossary

definitions, detection of inter- and intra standards inconsistencies, evolving a set of a

Web-accessible set of model snippets to be used as standard building blocks for

enterprise architecture, and applying model snippets in an actual enterprise

architecture.

Object Process Methodology – OPM

OPM [1] is a holistic, integrated approach to the design and development of systems

in general and complex dynamic systems in particular. OPM is a formal yet intuitive

paradigm for systems architecting, engineering, development, lifecycle support, and

evolution. It has been used for modeling complex systems, both natural and artificial,

where artificial ones might comprise humans, physical objects, hardware, software,

regulations, and information. As its name suggests, the two basic building blocks in

OPM are (stateful) objects—things that exist (at some state), and processes—things

that transform objects by creating or destroying them, or by changing their state.

OPM elements are entities and links. OPM syntax and semantics are summarized in

Appendix A. The three entity types are objects and processes, collectively referred to

as "things", and object states. Objects are things that exist, and they can be stateful

(i.e., have states). Processes transform objects: they generate and consume objects, or

affect stateful objects by changing their states. Objects and processes are of equal

importance, as they complement each other in the single-model specification of the

system. Links, which are the OPM elements that connect entities, are of two types:

structural and procedural. The generic definitions of OPM elements make OPM

suitable for modeling complex systems that comprise technology and humans.

Enterprises are perfect examples of this type of systems, making the choice of OPM

natural for the purpose at hand.

OPM consists of two semantically equivalent modalities of the same model: graphical

and textual. A set of interrelated Object-Process-Diagrams (OPDs) constitute the

graphical model, and a set of automatically-generated sentences in a subset of English

constitute the Object-Process Language (OPL). In the graphical-visual model, each

OPD consists of OPM elements depicted as graphic symbols, while the OPD syntax

specifies the consistent and correct ways by which those elements can be managed.

Since the corresponding textual model is generated in a subset of English, it is

immediately understood by domain experts, who need not learn any special language

nor decipher cryptic code.

OPM notation supports conceptual modeling of systems. Its top-down approach

includes refinement mechanisms of in-zooming and unfolding. OPM uses a single

type of diagram to describe the functional, structural and behavioral aspects of the

system. OPCAT [2], an OPM-based conceptual modeling software environment,

features an accessible API, a basic animated class-level execution module, and

integration with files of various formats, e.g., XML and CSV, reducing the

development effort.

OPM objects relate to each other via structural relations, expressed graphically as

structural links. Structural relations specify relations between any two objects. The

four fundamental structural relations are aggregation-participation, generalization-

specialization, exhibition-characterization, and classification-instantiation. Objects

can also be structurally related to each other by unidirectional or bidirectional tagged

relations, similar to association links in UML class diagrams. Due to the object-

process symmetry, structural relations can also specify relations between any two

processes.

Procedural links connect a process with an object or an object's state to specify the

dynamics of the system. Procedural links include (1) transforming links: effect link,

consumption link, result link, and the pair of input-output links, (2) enabling links,

which are the agent and instrument links, and (3) control links: event, condition,

invocation, and time exception links.

An OPM model consists of a set of hierarchically organized Object-Process Diagrams

(OPDs) that alleviate systems' complexity. Each OPD is obtained by in-zooming or

unfolding of a thing (object or process) in its ancestor OPD. Copies of an existing

thing can be placed in any diagram, where some or all the details, such as object states

or links to other things, which are unimportant in the context of the diagram, can be

hidden. It is sufficient for some detail to appear once in some OPD for it to be true for

the system in general even though it is not shown in any other OPD.

From text-based to OPM model-based standards

At the heart of our proposed solution is the claim that formal documents of technical

nature that specify complex systems in general, and enterprise standards in particular,

can and should be verified and validated using a model that is both formal and

humanly accessible, which is translated automatically and on the fly into a

constrained, standard subset of English, which we call Tesperanto, short for

Technical Esperanto.

OPM is most suitable as the modeling language for the task at hand, since one of its

most prominent features is the fact noted above that OPM is bimodal, i.e., it has two

equivalent representation: graphic – a set of Object-Process Diagrams (OPDs) and

textual – a corresponding set of Object-Process Language (OPL) sentences, which are

constrained English sentences, which are constructed on the fly in response to the

graphic input of the modeler.

An OPM model-based expression of the content of a standard shall enable not only

checking and establishing consistency between the graphic and textual representation,

but also the ability to develop and deploy tools for machine processing of standards’

text, automatic generation of links among ontology entities, automated consistency

checks, and examining adherence of field implementations to pertinent enterprise

standards. As we report below, we have started developing a prototype of this

environment, called OPM-BEST, short for OPM-Based Enterprise Standards

Translation.

The basis of the OPM model-based approach is an underlying extendable central

OPM model of the domain's ontology that can be shared by all the standards related to

the same domain or domains of sufficient similarity. This comprehensive and multi-

disciplinary framework shall serve as a shared Web-based repository of normalized

OPM-based model modules, called snippets, for the evaluation of international

standards in the context of enterprise architecture and design. This central ontology

OPM model can link terms and definitions, frequent phrase structures, business rules,

enterprise design patterns, best practices, and more.

Tesperanto is like OPL, the text sentences currently derived from the graphical OPD.

However, it is richer in vocabulary and less mechanical, making it more readable by

humans.

IEC 62264 as a case in point

Following a discussion with the Chair of SC 5 regarding the use of OPM to examine

the restructuring of ISO/IEC 62264, we have proposed at the 2009 SC5 Plenary to

focus on ISO/IEC 62264 for the following reasons: (1) it is a joint effort of ISO, IEC,

and ISA; (2) it is currently under revision; and (3) it has seen success in the

marketplace. Those in attendance at the 2009 SC5 Plenary concurred in the choice.

The standard has four published parts and a fifth one in preparation, so it provides

ample material for different approaches to the use of OPM as a means for analyzing

the integration and interoperation of standards. ISO/IEC 62264 has a hook for

enterprise architecture considerations that are part of the SC5 charge.

ISO/IEC 62264 uses UML models to express the interface between ERP and MES

applications, so a model framework exists to compare with the normative textual

descriptions. As a proof-of-concept, we converted the text and figure for IEC 62264

paragraph 7.5.1.1 – Personnel Model (see Figure 1) to an OPM-based structured form,

shown in Figure 2, where the right column shows the Graphical OPM Model –

Object-Process Diagram (OPD). The Structured Text column on the left has two

parts: The automatically-generated Object-Process Language (OPL) paragraph, which

is too mechanical to be left as is in a standard, followed by sentences in Tesperanto –

a manually tweaked version of this OPL paragraph, which we propose to formalize

and incorporate into the contemplated OPM standard for enterprise standards

authoring.

Each one of the two text paragraphs conveys complete information in a consistent

form, so that the text is fully aligned with the model. The text is composed of simple,

light, unambiguous sentences that, in addition to their simplicity and explicit nature,

are also likely to significantly facilitate automated, yet reliable, translations to natural

languages other than English. Further detailed information, which causes confusion in

the original specification, is hidden in in-zoomed paragraphs for Specific Personnel,

Qualifications of Personnel and Classes of Personnel.

This paragraph illustrates some typical problems of combining free text with graphic

specifications:

Inconsistency between figure notation and notation in text: e. g., specific

personnel (text of this paragraph) vs. Person (in the model and later in the text)

or qualifications of personnel (in the text of this paragraph) vs. Person

property (in the model and later in the text).

Incomplete text (information in the model is not present in the text): e. g., the

relation "records the execution of" between Qualification test result and

Person property.

Incomplete figure (information in the text is not present in the figure): e.g.,

correspondence to ISO 15704 and ISO 15531-1.

Text Figure

The personnel model

contains the information

about specific personnel,

classes of personnel, and

qualifications of personnel.

Figure 14 illustrates the

personnel model. This

corresponds to a resource

model for personnel, as given

in ISO 15704 and ISO

15531-1

Figure 1. Source standard specification: text and figure fragment of paragraph 7.5.1.1 – Personnel Model of

ISO/IEC 62264

Structured Text Graphical OPM Model – Object-Process Diagram (OPD)

Automatically-generated Object-Process Language (OPL) paragraph Personnel model exhibits many Specific personnels, many Class of personnels, and many Qualifications of personnels. Specific personnel may be a member of many Class of personnels. Class of personnel represents a group of many Specific personnels. Qualifications of personnel may be associated with Class of personnel. Qualifications of personnel may be associated with Specific personnel. Personnel model corresponds to ISO 15531-1 resource model. Personnel model corresponds to ISO 15704 resource model.

Manually tweaked OPL Personnel model corresponds to ISO 15704 and ISO 15531-1

resource models and contains the information about Specific

personnel, Qualifications of personnel and Classes of personnel:

Class of personnel represents a group of many Specific

personnel.

Specific personnel may be a member of many Classes

of personnel.

Qualifications of personnel may be associated with

Class of personnel and/or with Specific personnel.

Figure 2. Model-Based specification of the text in Figure 1

Only a few of these issues are resolved later in the standard's text, while the majority

must be inferred from context. This situation can be avoided if we move from text-

only to a model-based representation for standards.

The OPM-Based Enterprise Standards Translation (OPM-BEST)

Software Environment

To enable implementing this approach, we are developing a prototype of a software

environment, called OPM-BEST (OPM-Based Enterprise Standards Translation),

which integrates OPCAT [2] with natural language processing tools, tools for editing

and transforming existing standards from their current text-based form to their OPM

model-based form, and tools for authoring new structured model-based elements for

filling gaps in existing standards.

In this environment, a standard is coupled with its model. This coupling inherently

guarantees text-model consistency. Any change in a standard's text is reflected in its

model and vice versa, so that both are fully consistent and interchangeable at all

times. Figure 3 is the System Diagram of OPM-BEST.

Figure 3. OPM-BEST System (top-level) Diagram

The current OPM-BEST implementation has the following capabilities:

Pre-processing: Extracting structure and keywords from documents: tables of

contents, indices, glossaries, etc.

Natural Language Processing: integrated open-source tools for sentence

simplification, parts-of-speech tagging, semantic similarity analysis, and text

modeling.

Ontology tools: Object-process-link heuristics and phrase repository, text-to-

model consistency.

General editing tools: Syntax highlighting, phrase completion, smart tips, and

snippets.

Figure 3 is the System Diagram – the top-level Object-Process Diagram (OPD) of

OPM-BSET, which provides an overview of the complete semi-automatic process of

OPM-based enterprise standard specification formalization. Describing as text the

content of Figure 3, using the Object-Process Language (OPL) color scheme, where

blue is process, green is object and brown is state, the OPM-Based Enterprise

Standards Modeling system is operated by an Enterprise Standards Expert with the aid

of a NLP and Modeling environment. The system performs a process of converting

Enterprise Standards Set (free-text documents) into a structured OPM Model-Based

form. This conversion is based upon the OPM-Based Enterprise Ontology Model

identified above.

The Standard Modeling Process

The process of reverse-engineering a text document, i.e., translating a text document

of an enterprise standard into a formal model is by and large domain-independent.

Model-based authoring of a new document, akin to forward engineering, which is

beyond the scope of this paper, is going to be different, but it too can use OPM-BEST

– the model-based authoring environment we are developing.

The ISO OPM WG has developed a process that assures a significant reduction of

content inconsistencies through a bimodal presentation that enables deep cognitive

analysis of the standard’s technical content. Some standards, such as the ISO/IEC

62264, use models to support the presentation of their content. However, in this

model-supported approach the UML class diagrams in the standard do not stem from

underlying base model. Rather, they are provided on an ad-hoc manner to go with

nearby text, with no guarantee of conformance between the two.

The need for a participating domain expert is largely dependent upon the domain of

the technical document and the background of the modeling analyst. In most cases,

only rudimentary knowledge of the domain’s subject matter is sufficient for the

analysis, but working knowledge of the modeling methodology, in our case OPM, is

important.

Our model-based approach derives the standard’s content from an underlying model

rather than a model-supported approach. Due to its bimodal graphic-text capabilities,

OPM provides a means for validating the standard’s clauses and producing ontology

that encompasses the document content, which significantly enhances the document’s

testability and validability. These capabilities, described using clauses from ISO/IEC

62264, demonstrate the identification of inconsistencies in the standard. The use of

natural language processing is demonstrated as a means to add a level of automation

to the reviewing and improving of existing standards and to author new standards.

The ontology model can provide reference to other standards in the same domain and

a basis for integrating standards across domains.

The concept for this approach was conceived in association with systems engineering

process studies, when the dual text/graphic nature of OPM and model- based

engineering suggested that the use of models for describing systems could be moved

to an earlier stage in the system definition process. Modeling is suggested to be

moved from the stag of trying to interpret textual specification for model construction

to the stage in which the system is initially defined, such as the stage of Concept of

Operations (CONOPS) definition. Having tested this approach with success on

CONCOPS of human space travel, the approach has been extended to modeling

technical standards in general and enterprise standards in particular.

A Critical Review of 62264 Functions Derived from Its Modeling

Attempts

In this section we present a critical review of IEC 62264 Derived from Its Modeling

Attempts. The standard presents activities, functions, information flows, and objects

for a Level 3, Manufacturing Operations and Control [3]. The review of this

document has been carried out from the point of view of a systems engineer and an

OPM analyst interested in applying document modeling to the IEC 62264.

General Comments

A conventional description of an enterprise is expected to start at the top, specifying

the enterprise, and then the top enterprise functions designed to achieve its mission,

goals and objectives. The ISO/IEC 62264 standard focuses on manufacturing control

and operations, so the enterprise description starts at a lower level, with the enterprise

functions for manufacturing-related functions. In a full enterprise description, the

manufacturing functions would be a subprocess of some higher enterprise function.

The 62264 enterprise functions are presented as Level 4 functions under the category

of ―Business Planning and Logistics - Plant production scheduling, operational

management, etc.‖ These Level 4 enterprise functions are presented in Figure 5 of the

standard using a data flow diagram and described in clause 6.4.

Traditionally, functions are decomposed into lower levels containing more detail. It

would then be expected that the Level 3 functions would be derived from the Level 4

functions. This, however, does not appear to be the case in the 62264 document.

There is additional confusion in the description of functions in that 62264 uses the

term ―activity‖, with no explicit definition, seemingly as a higher level function. In

clause 5.2.3.1, Level 3 activities are presented with their ―functionalities‖ described in

5.2.3.2-12. The relationship between activities and functions is not presented. There

are 8 activities and 12 ―functionalities‖, with the captions of the functionalities not

related to the activities. The apparent lack of traceability from Level 4 functions to

Level 3 functions is an inconsistency that is carried throughout the document.

In an OPM model, the appropriate portion of the document’s enterprise model would

also be a top-down model, starting at the processes and objects corresponding to

Level 4. Ideally the Level 4 processes would be decomposed (zoomed into) into

subprocesses, some of which would be Level 3 processes. This would describe the

information (objects) flowing into Level 3. Using OPM, the packaging of information

in 62264 has to be translated to equivalent objects, such as reports, datasets, or

messages. The OPM model would continue the decomposition of the processes until

Level 2 was reached. This approach implies a consistent, integration of activities and

objects from Level 4 down to Level 2. The 62264 standard does not have the needed

consistency in objects and activities. The following material covers the areas where

problems have been identified.

Enterprise Processes

Clause 5.2.2 describes Level 4 activities under the scheduling and control hierarchies.

This textual description of activities is not referenced to anything. As with Level 4

there is a list of Level 3 activities in Clause 5.2, which also states that any activities

―not explicitly presented as part of the Level 3 control domain to be part of the

enterprise domain‖. The corresponding diagram for the functional hierarchies

provides a general heading of ―Business planning and logistics‖ for these activities.

These do not seem to be creditable enterprise processes for Level 4.

Clause 6, Functional Data Flow Model, presents in its Figure 5 an enterprise control

model with data flows between activities. The boundary between Level 3 and 4

includes some activities, divides some, and excludes others. Clause 6.4 describes the

functions, but with no indication of which sub-functions are in Level 3 or 4 for those

functions which are partitioned. Only Production Control and possibly Quality

Control are wholly within Level 3.

Without additional information, Level 4 activities cannot be represented as a starting

point for refinement (via OPM in-zooming) of Level 4 processes. Given the current

information in 62264, the OPM integrated model would need to begin at Level 3

processes.

Level 3 Processes

The list of Level 3 activities and their associated functionalities in Clause 5.2.3.1 are

not correlated with the Clause 6.4 functions of the enterprise/control model or with

the data flows. The Clause 6 data flow definitions are based upon the Purdue

Reference Model (PRM) described in Annex D of the standard. There is a

presentation of information in Clause 7.2 which organizes the Clause 6 information

into categories but does not relate the information to Clause 6 functions. The object

model structures of Clause 7.2 are not explicitly related to activities, but presented as

resources, materiel, production capability, production definition information, and

production information.

The Level 3 functions are described in more detail in 62264-3 but are presented in a

different type of view than 62264-1. The functions for Level 3 in 62264-3 are

organized into four management components: production operations, maintenance,

inventory, and quality control. Additionally, the categories for information exchange

for 62264-3 are different than those for 62264-1, having four categories vs. three.

Moreover, the four information categories in 62264-3 are not aligned with the four

divisions of manufacturing operations information in Figure 6 of 62264-3. The data

flows presented in 62264-3 is not directly related to the Level 3 functions and is

organized differently in that a generic data flow template is used for each of the 4

components of management. The 62264-3 information flows do not have an

identified relationship to the data flows in the -1 Figure 5 and 62264-1 object models.

Modeling 62264 Clause 5.3.2.1 – Level 3 Functions In an attempt to discover if there was some latent definition of Level 3 functions in

the activities listed in clause 5.2.3.1, the activities were treated as functions and an

OPM analysis was applied to them. The steps of this analysis, listed below, are the

same as those used in building a model based document, except only Clause 5.2.3.1

was addressed. These steps are as follows.

• Identify OPM things, namely objects and processes, in the text.

• Create a snippet—a small OPM model that represents the text element (sentence or

paragraph).

• Integrate the snippet with existing snippets, gradually building a consolidated

model.

• Restate the snippet based upon the consolidated model.

• Form the structured text associated with the snippet, produce (currently manually,

later automatically) more facile Tesperanto text for documentation as part of the

model-based standard.

Figure 4. 62264 Clause 5.3.2.1 color-coded

The actions were marked up for OPM elements, such as objects and processes using

color codes, as shown in Figure 4. The marked-up sentences were then modeled in

OPM to produce model snippets. These snippets are shown in Figure 5 through

Figure 11. Each figure presents the source snippet, the OPM generated text and the

―smoothed text‖ for the document sentence replacement. The smoothed text is not

materially different, in fact left the same as the generated text in this case because it is

very readable as is. The developed snippets are incorporated into an integrated,

ontological model representing all the snippets. A class and a process view of the

ontology model are presented in Figures 12 and 13.

The abridged list of derived functions from clause 5.2.3.1 follows.

Area Production Report Developing

Area Data Collecting

Area Data Maintaining

Data Collection

Offline Analysis

Personnel Functions Managing

Immediate Detailed Production Schedule Developing

Production Schedule Executing

Production Schedule Modifying

Whether these constitute a meaningful set of Level 3 functions is to be verified by a

domain or subject matter expert (SME). The list has obvious subtypes at the same

level as the parent in the case of Data Collecting. If the analysis had not tried to

preserve the original clause format, a) through g) in Figure 4, and used the processes

from the ontological model, the following more compact set of functions would have

emerged.

Scheduling

Production Schedule Executing

Training

Personnel Functions Managing

Area Data Management

a) reporting on area production including variable manufacturing costs;

OPL

Area Production Report

Area Production Report Developing yields Area Production Report.

Tesperanto

Area Production Report Developing

yields Area Production Report,

which consists of Variable Manufacturing Cost.

Figure 5. 62264 Clause 5.3.2.1 a) snippet template

b) collecting and maintaining area data on production, inventory, manpower, raw

materials, spare parts and energy usage;

OPL Area Data Collecting yields Area

Data.

Area Data Maintaining affects Area Data.

Area Data exhibits Production,

Inventory, Manpower, Raw

Materials, Spare Parts, and Energy

Usage.

Tesperanto

Area Data Collecting yields Area

Data, which exhibits Production,

Inventory, Manpower, Raw

Materials, Spare Parts, and Energy Usage.

Area Data Maintaining affects Area Data.

Figure 6. 62264 Clause 5.3.2.1 b) snippet template

c) the performance of data collection and off-line analysis as required by (instrument ? ) engineering

functions. This may include statistical quality analysis and related control functions;

OPL Data Collection as required by

Engineering Functions Managing.

Offline Analysis [is done] as

required by Engineering Functions Managing.

Offline Analysis consists of

Statistical Quality Analysis and Related Control Functions.

Tesperanto

Data Collection and Offline Analysis

[are done] as required by

Engineering Functions Managing.

Offline Analysis consists of

Statistical Quality Analysis and Related Control Functions.

Figure 7. 62264 Clause 5.3.2.1 c) snippet template

Focus on the Quality Assurance Thread

The scope of the 62264 document and the apparent inconsistencies revealed during

analysis of the total document not feasible for the time available for the working

group activity. Therefore, a simpler approach was tried which involved selecting a

single, simpler function. Analysis of the functions for quality assurance was selected

because it was mostly within the Level 3 boundary of Level 4 functions and had fewer

data flows.

The initial statement of a quality assurance function is in clause d) of 5.2.2 ―Level 4

activities,‖ which refers only to the management of quality assurance data. There is

no mention of any quality assurance functions in Level 3 activities in clause 5.2.3.1.

However, there is a quality management function stated for Level 3 in clause 5.2.3.5.

This clause is analyzed in what follows.

d) carrying out (managing) needed personnel functions such as: work period statistics [work

period statistics] (for example, time, task), vacation schedule, work force schedules, union line

of progression, and in-house training and personnel qualification;

OPL Personnel Functions Managing

exhibits Work Period Statistics

Preparation, Vacation Scheduling,

Work Force Scheduling, Union Line

of Progression Planning, In-House

Training, and Personnel Qualifying.

Work Period Statistics Preparation

exhibits Time Statistics and Task

Statistics.

Tesperanto Personnel Functions Managing

exhibits Work Period Statistics

Preparation, Vacation Scheduling,

Work Force Scheduling, Union Line

of Progression Planning, In-House

Training, and Personnel Qualifying.

Work Period Statistics Preparation

exhibits Time Statistics and Task

Statistics.

Figure 8. 62264 Clause 5.3.2.1 d) snippet template

Clause 5.2.3.5 Quality Management Analysis

The purpose of analyzing clause 5.3.2.5 is to determine what Level 3 functions it

identifies. As there is no Level 3 quality action in Clause 5.3.2.1, and the clause

5.2.3.5 functions are stated to flow from the clause 5.3.2.1 actions, a quality action is

assumed for the Level 3 activities. This situation is depicted in the top processes

diagram in Figure 12, where the assumed quality assurance function is depicted as a

specialization (subtype) of Quality Management, specified in clause 5.2.3.5. Figure

13 presents a Control Domain exemplary snippet, based on 62264 clause 5.2.3.5.

The three sentences in the clause are analyzed to produce snippets in Figures 15-17.

As the goal of this analysis is not to produce clause frames, some of the analysis is not

presented as before. The three sentences produce a set of what is considered to be the

top processes. The selection of these functions is somewhat of an educated guess as

the analyst is not a SME in this domain. The top Level 3 functions derived from

Clause 5.3.2.1 are shown in Figure 18.

Clause 6.4.6 Quality Assurance (6.0) Analysis

The purpose of this analysis is to identify Level 4 quality assurance functions by

modeling the 6.4.6 functional clauses, a) through h) shown in Figure 17. The analysis

is not carried to the point of developing modeled Tesperanto clauses in lieu of the

original OPL. Clause 5.2.2. – Level 4 Activities has only one activity associated with

quality assurance:

d) Collecting and maintaining quality control files as they relate to customer

requirements”

This inconsistency with 6.4.6 was the motivation to determine whether a reasonable

set of Level 4 functions could be derived for serving as an example of the basis for a

flow of Level 4 functions down to Level 3. Lacking the involvement of a domain

expert (SME) in this analysis, the derived Level 4 functions are just an educated, but

reasonable guess.

The analysis started with a manual mark-up of the 8 functions as shown in Figure 17.

Each clause was then modeled with OPCAT, the OPM modeling tool, to produce a

model snippet, a small model of the clause. In some cases, additional objects or

processes were introduced to make the model logically consistent. The usual

modification involves adding a modifier to an object or process to make the item

specific, as changing ―testing‖ in a) to ―material testing‖. Another example of a

typical modification is the introduction of a ―Material Quality Standard‖ object, as the

product of the ―Standards Setting‖ process in Figure 17. The snippets for the clauses

are shown in Figures 18-24 with their associated OPCAT generated OPL.

Upon completion of the snippets, an integrated model was developed that

encompasses the eight snippet models. One of the largest unknowns in this

integration for the processes was the issue of whether the process was synchronous or

asynchronous. This issue defines whether a process is periodic, such as part of a

sequence, or occasional. As there was no SEM support, guesses were made in

determining the final configuration of the processes shown in Figures 10. There was

sufficient information in the clauses to suggest an encompassing process of Material

Management, which is shown as an expanded set of processes an Figure 11. An

integrated class model was developed and is shown in Figures 25 and 26. To the

untrained eye, the set of Level 4 functions looks reasonable. The class structure for

Level 4 functions is shown in Figure 27. While replacement text for the document

wasn’t developed, a casual review of the automatically generated OPL shows that

with minor changes, a reasonable set of replacement text could easily be developed.

e) establishing the immediate detailed production schedule for its own area including maintenance,

transportation and other production-related needs;

OPL Production Area exhibits Immediate

Detailed Production Schedule

Developing Immediate Detailed Production

Schedule Developing exhibits

Maintenance, Transportation, and

Other Production Related Needs.

Immediate Detailed Production

Schedule Developing yields

Immediate Detailed Production Schedule.

Tesperanto

Production Area exhibits Immediate

Detailed Production Schedule

Developing, which exhibits

Maintenance, Transportation, and

Other Production Related Needs.

Immediate Detailed Production

Schedule Developing yields

Immediate Detailed Production

Schedule.

Figure 9. 62264 Clause 5.3.2.1 e) snippet template

f) locally optimizing the costs for its individual production area while carrying out the

production schedule established by the Level 4 functions;

OPL Production Area exhibits Local Cost

Optimizing and Production Schedule

Executing.

Production Schedule established by

Level 4 Functions Management.

Production Schedule Executing

requires Production Schedule.

Tesperanto

Production Area exhibits Local Cost

Optimizing and Production Schedule

Executing.

Production Schedule Executing

requires Production Schedule, which

is established by Level 4 Functions

Management.

Figure 10. 62264 Clause 5.3.2.1 f) snippet template

g) modification of production schedules to compensate for plant production interruptions that may occur

in its < area > area of responsibility.

OPL Production Schedule Modifying

yields Modified Production

Schedule.

Modified Production Schedule

compensates for Plant Production

Interruption.

Area exhibits Area of Responsibility

Plant Production Interruption may

occur in Area of Responsibility.

Production Interrupting yields Plant

Production Interruption.

Tesperanto

Production Schedule Modifying

yields Modified Production

Schedule, which compensates for

Plant Production Interruption.

Production Interrupting yields Plant

Production Interruption.

Plant Production Interruption may

occur in Area of Responsibility of

Area.

Figure 11. 62264 Clause 5.3.2.1 g) snippet template

Figure 12. 62264 Quality Assurance assumed as a generalization of Quality Management in 5.2.3.5

OPL Real Time Measurement Providing consists of Data Collecting.

Data Collecting requires Analysis & Manufacturing Data.

Real Time Measurement Providing yields Real Time Q/A Data.

Product Quality Control Assuring requires Real Time Q/A Data.

Problem Identification exhibits Problem Requiring Attention.

Problem Identification requires Real Time Q/A Data.

Manufacturing & Analysis exhibits Analysis & Manufacturing Data.

Figure 13. Control Domain exemplary snippet, based on the note above from 62264

OPL Problem Resolving requires Problem Requiring Attention.

Problem Identification yields Problem.

Cause Determining consists of Problem Correlating.

Problem Correlating requires Problem Result, Problem Symptom, and Problem

Action.

Cause Determining requires Problem.

Cause Determining yields Problem Cause.

Corrective Action Recommending requires Problem Cause.

Corrective Action Recommending yields Problem Resolution Action.

Figure 14. Zooming into Problem Resolving, based on the note above from 62264

OPL Quality Management 5.2.3.5 consists of Statistical Process Controlling

(SPC), Statistical Quality Controlling (SQC), Of-Line Inspection

Operations, and Quality Assurance Analysis.

Of-Line Inspection Operations consists of Off-Line Tracking

and Off-Line Management.

Laboratory Information System exhibits Quality Assurance Analysis.

Figure 15. Unfolding Quality Management, based on the note above from 62264 clause 5.2.3.2.

OPL Quality Management 5.2.3.5 consists of Real Time

Measurement Providing, Product Quality Control Assuring,

Statistical Process Controlling (SPC), Statistical Quality

Controlling (SQC), Of-Line Inspection Operations, and

Quality Assurance Analysis.

Figure 16. Another unfolding of Quality Management, based on the note above from 62264 clause 5.2.3.2.

6.4.6 Quality Assurance (6.0) [ Process, Object, Relationship ]

The functions of quality assurance typically include

a) testing and classification of materials;

b) setting standards for material quality;

c) issuing standards to manufacturing and testing laboratories in accordance with requirements from

technology, marketing and customer services;

d) collecting and maintaining material quality data;

e) releasing material for further use (delivery or further processing);

f) certifying that the product was produced according to standard process conditions;

g) checking of product data versus customer's requirements and statistical quality control routines to

assure adequate quality before shipment.

h) relaying material deviations to process engineering for re-evaluation to upgrade processes.

The functions of quality assurance typically generate or modify the following information for use in other

control functions.

1) Quality assurance test results.

2) Approval to release materials or waivers on compliance.

3) Applicable standards and customer requirements for material quality.

Some of the functions within quality assurance may be inside the control domain, based on local

organizational structures; for example, quality assurance requests. Therefore, selected data flows into

and out of quality assurance are addressed because they may cross the enterprise-control system

boundary.

Figure 17. Marked up version of Level 4 functions

OPL Material Testing requires Material.

Material Classification requires Material.

Figure 18. Snippet for Quality Assurance based on 62264 clause 6.4.6 a) listed at the top

OPL Standards Setting requires Material Quality.

Standards Setting yields Material Quality Standard.

Figure 19. Snippet for Quality Assurance based on 62264 clause 6.4.6 b) listed at the top

OPL Requirement in accordance with Customer Service. Requirement in accordance

with Marketing. Requirement in accordance with Technology. Standards

Issuing requires Requirement. Standards Issuing yields Manufacturing Standard

and Laboratory Testing Standard.

Figure 20. Snippet for Quality Assurance based on 62264 clause 6.4.6 c) listed at the top

OPL Data Collecting requires Material Quality Data.

Data Maintaining requires Material Quality Data.

Figure 21. Snippet for Quality Assurance based on 62264 clause 6.4.6 d) listed at the top

OPL Releasing Material requires Material.

Releasing Material yields Released Material.

Delivering requires Released Material.

Further Processing requires Released Material.

Figure 22. Snippet for Quality Assurance based on 62264 clause 6.4.6 e) listed at the top

OPL Manufactured Product was produced Product. Product Certifying requires Standard Process Condition and Manufactured

Product. Product Certifying yields Certified Product.

Figure 23. Snippet for Quality Assurance based on 62264 clause 6.4.6 f) listed at the top

OPL Assured Product Quality exhibits Adequate Quality.

Product Shipping requires Assured Product Quality. Product Data Checking requires Product Data, Customer

Requirements, and Statistical Quality Control Routines.

Product Data Checking yields Assured Product Quality.

Figure 24. Snippet for Quality Assurance based on 62264 clause 6.4.6 g) listed at the top

OPL Material Deviation relaying to Process

Engineering. Material Deviation Re-evaluating requires

Process Engineering and Material Deviation. Material

Deviation Re-evaluating yields either Existing Process or

Upgraded Process.

Figure 25. Snippet for Quality Assurance based on 62264 clause 6.4.6 h) listed at the top

Figure 26. Level 4 Functions in-zoomed (for synchronous processes) and unfolded (for asynchronous

processes)

Figure 27. Material Management from Figure 26 in-zoomed (for synchronous processes) and unfolded (for

asynchronous processes)

Figure 28. Partial structural view of several key objects in 62264

Figure 29. Partial procedural view of Manufacturing Operations & Control in 62264

Figure 30. Partial structural view of several key objects in 62264

Figures 28 through 30 depict partial structural and procedural views of the parts we

analyzed from 62264. Examining these views it is obvious that some of the thing

names should be improved. For example, it makes little sense to have Area of

Responsibly as an attribute of Area, underlying the need for model-based domain

ontology.

Conclusions and Recommendations

We start with conclusions specific to ISO/IEC 62264, which was quite thoroughly

analyzed by the ISO TC184/SC5 OPM WG. With the Level of inconsistencies

concerning the definition of 62264 activities, it is not likely that model snippets could

be developed that interacted with the 62264-1 object models. It would take a domain

expert (subject matter expert, SME) to define what is to be used. This concern

extends to defining a hierarchy of OPM processes within Level 3 that are derived

from higher Level 4 processes in order to present a comprehensive, integrated model.

The information in 62264 can potentially support an integrated model-based standard

document, but the model set could not be extracted from the current documentation by

a modeled document analyst unless a SME is involved in the activity as part of the

modeling team.

Following this observation, we conjecture that the situation with respect to other

enterprise standards is not principally different, and that significant voids,

discrepancies and ambiguities are quite prevalent in enterprise standards in general.

The Choice of OPM as a language and methodology for model-based enterprise

standards

This work has demonstrated the viability and benefits of using a modeling language in

general and OPM in particular to significantly improve the quality and the value of

standards. OPM is in fact the only modeling language that exhibits built-in dual

graphics-text model representation, with automatic generation of constrained English.

This, along with its single-model view and compact, straightforward generic ontology

of stateful objects and processes that transform them, which provides for quick

learning, makes OPM the natural choice for model-based enterprise standards

authoring. Not only is OPM a straightforward language to learn; as a methodology,

OPM advocated top-down refinement of the major function of the system, which is its

central process in the System Diagram. This is perfectly aligned with the way

enterprise standards are structured.

A Guideline to Future Model Authoring

Future revisions and enhancements to the various 62264 parts and to other standards

should be conducted following the methodology demonstrated in our work, and which

is applicable to other enterprise standards:

• Perform a functional analysis, starting with the top-level function of the

enterprise; determine the process aggregation (whole-part) and specialization

hierarchies to establish the top-down functional flow through the enterprise. As

processes are identified, insert them into the OPM model at the appropriate

hierarchy levels.

• Hand-in-hand, identify the material, energy, and data objects (blocks) in the

enterprise system and define their flow among the processes (functions) at the

various hierarchy levels commensurate with the processes that transform (create,

consume, or change the state of) these objects.

• As things (objects or processes) are incorporated into the evolving OPM model,

make sure to avoid duplications (i.e., creating two separate entities for the same

ontological entity). • Continuously examine the auto-generated text for sanity and preciseness. The

text is currently OPL, and will evolve into Tesperanto as we proceed with our

OPM-BEST development. • Establish a stringent configuration management process for the models and text.

The OPM-BEST software authoring environment we are developing is geared to

support this requirement.

• Include in the enterprise standard authoring team at least one unbiased domain

expert, an SME who is free of any particular content agendas.

MEMESA – a proposed Meta-standard for Model-based Enterprise Standards

Authoring

MEMESA – a Meta-standard for Model-based Enterprise Standards Authoring, which

will take in account the recommendations of this work and will be based on the

following principles:

1. An enterprise standard shall be model-based.

2. OPM shall serve as the modeling language and methodology for authoring and

evolving model-based enterprise standards.

3. MEMESA shall itself be model-based; it shall be constructed following the

principles and guidelines recommended in this work, to be elaborated in

MEMESA.

Action Items

Based on the work of the TC184/SC5 OPM WG and the findings presented in this

report, we recommend that ISO TC184/SC5 adopts the following decision as action

items.

1. Take up the formal next steps in developing MEMESA—the Meta-standard

for Model-based Enterprise Standards Authoring proposed above.

2. Adopt the formal definition of OPM as an ISO standard. This OPM ISO

standard shall be referenced by MEMESA as the basis for model-based

standards authoring and evolution.

3. Extend the ISO OPM standard to include Tesperanto for better human

readability.

4. Make a decision about the future model-based development of 62264 and

other enterprise standards, both current and contemplated, under the

responsibility of ISO TC184/SC5, including priorities, timeline, developing

team, etc.

5. Encourage the development of a software environment for model-based

standards authoring environment to implement MEMESA in the spirit of

OPM-BEST proposed in this work.

References

1. Dori, D. Object-Process Methodology - A Holistic Systems Paradigm. Berlin : Springer Verlag,

2002.

2. Dori, D. Reinhartz-Berger, I. and Sturm, A. Developing Complex Systems with Object-Process

Methodology using OPCAT. LNCS 2813, pp. 570-572, 2003.

3. ISO/TC 184/SC 5. Terms of Reference: Study Group to Explore OPM for Modeling Standards,

2009. http://forums.nema.org:443/upload/N1049_OPM_Study_Group_Terms_of_Reference.doc

4. Johnsson, C. An introduction to IEC/ISO 62264, 2003.

http://isotc.iso.org/livelink/livelink/fetch/2000/2489/Ittf_Home/MoU-MG/Moumg159.pdf , Accessed Nov. 12 2009.

Appendix A - OPM Syntax and Semantics

ENTITIES

STRUCTURAL LINKS & COMPLEXITY MANAGEMENT

ENABLING AND TRANSFORMING PROCEDURAL LINKS

EVENT, CONDITION, AND INVOCATION PROCEDURAL LINKS

ENTITIES

Name Symbol OPL Definition

Th

ing

s

Object

Process

B is physical.

(shaded rectangle)

C is physical and

environmental.

(shaded dashed

rectangle)

E is physical.

(shaded ellipse)

F is physical and

environmental.

(shaded dashed ellipse)

An object is a thing that exists.

A process is a thing that transforms

at least one object.

Transformation is object generation

or consumption, or effect—a change

in the state of an object.

State

A is s1.

B can be s1 or s2.

C can be s1, s2, or s3.

s1 is initial.

s3 is final.

A state is situation an object can be at

or a value it can assume.

States are always within an object.

States can be initial or final.

STRUCTURAL LINKS & COMPLEXITY

MANAGEMENT

Name Symbol OPL Semantics

Fu

nd

amen

tal Stru

ctural R

elation

s

Aggregation-

Participation

A consists of B

and C.

A is the whole, B and C are parts.

A consists of B

and C.

Exhibition-

Characterization

A exhibits B, as

well as C. Object B is an attribute of A and

process C is its operation (method).

A can be an object or a process.

A exhibits B, as

well as C.

Generalization-

Specialization

B is an A.

C is an A. A specializes into B and C.

A, B, and C can be either all objects or

all processes.

B is A.

C is A.

Classification-

Instantiation

B is an instance

of A.

C is an instance

of A.

Object A is the class, for which B and

C are instances.

Applicable to processes too.

Unidirectional &

bidirectional

tagged structural

links

A relates to B.

(for

unidirectional)

A and C are

related.

(for

bidirectional)

A user-defined textual tag describes

any structural relation between two

objects or between two processes.

In-zooming

A exhibits C.

A consists of B.

A zooms into B,

as well as C.

Zooming into process A, B is its part

and C is its attribute.

A exhibits C.

A consists of B.

A zooms into B,

as well as C.

Zooming into object A, B is its part and

C is its operation.

ENABLING AND TRANSFORMING PROCEDURAL LINKS

Name Symbol OPL Semantics

En

ablin

g lin

ks

Agent Link

A handles B. Denotes that the object is a human

operator.

Instrument

Link

B requires A.

"Wait until" semantics: Process B

cannot happen if object A does not

exist.

State-

Specified

Instrument

Link

B requires s1

A.

"Wait until" semantics: Process B

cannot happen if object A is not at

state s1.

Tran

sform

ing

link

s

Consumption

Link

B consumes A. Process B consumes Object A.

State-

Specified

Consumption

Link

B consumes s1

A.

Process B consumes Object A

when it is at State s1.

Result Link

B yields A. Process B creates Object A.

State-

Specified

Result Link

B yields s1 A. Process B creates Object A at State

s1.

Input-Output

Link Pair

B changes A

from s1 to s2.

Process B changes the state of

Object A from State s1 to State s2.

Effect Link

B affects A.

Process B changes the state of

Object A; the details of the effect

may be added at a lower level.

EVENT, CONDITION, AND INVOCATION

PROCEDURAL LINKS

Name Symbol OPL Semantics

Instrument

Event Link

A triggers B.

B triggers A.

Existence or generation of object A will

attempt to trigger process B once.

Execution will proceed if the triggering

failed.

State-

Specified

Instrument

Event Link

A triggers B.

when it enters s1.

B requires s1 A.

Entering state s1 will attempt to trigger

the process once. Execution will proceed

if the triggering failed.

Consumption

Event Link

A triggers B.

B consumes A.

Existence or generation of object A will

attempt to trigger process B once. If B is

triggered, it will consume A. Execution

will proceed if the triggering failed.

State-

Specified

Consumption

Event Link

A triggers B

when it enters s2.

B consumes s2

A.

Entering state s2 will attempt to trigger

the process once. If B is triggered, it will

consume A. Execution will proceed if the

triggering failed.

Condition

Link

B occurs if A

exists.

Existence of object A is a condition to

the execution of B.

If object A does not exist, then process B

is skipped and regular system flow

continues.

State-

Specified

Condition

Link

B occurs if A is

s1.

Existence of object A at state s2 is a

condition to the execution of B.

If object A does not exist, then process B

is skipped and regular system flow

continues.

Invocation

Link

B invokes C.

Execution will proceed if the triggering

failed (due to failure to fulfill one or

more of the conditions in the

precondition set).

Appendix B – ISO TC184/SC5 WG Members List

SC 5 P-

Member/

Country

Name e-mail Organization

1. Canada Michael

Gruninger

gruninger@mie.utoront

o.ca

University of Toronto

2. Canada Mark Richer mark.richer@pwc.ca Pratt & Whitney Canada

3. China Liu Wenyin csliuwy@cityu.edu.hk City University of Hong Kong

4. China Qing Li itqli@cityu.edu.hk City University of Hong Kong

5. France Daniel Krob dk@lix.polytechnique.f

r

Ecole Polytechnique

6. Germany Uwe

Kaufmann

uwe.kaufmann@model

alchemy.com

OMG Co-chair of ManTIS

7. Great

Britain

David Short david.itfocus@zen.co.u

k

IT Focus;Convenor of CEN TC310

WG1

8. Israel Alex Blekhman ablekhman@gmail.com Technion

9. Israel Pnina Soffer spnina@is.haifa.ac.il Haifa University

10. Israel Arnon Sturm sturm@bgu.ac.il Ben Gurion University

11. Italy James Brucato jamesbrucato@gmail.c

om

12. Korea Dongmin Shin dmshin@hanyang.ac.kr Hanyang University

13. Korea S.K. CHA skcha@acs.co.kr Advenced Computer Service Co., Ltd.

Appointed by KATS – Korean Agency

for Technology and Standards

14. Singapore Yeo Khim Teck mktyeo@ntu.edu.sg Nanyang Technological University

15. Sweden Charlotta

Johnsson

charlotte.johnsson@co

ntrol.lth.se

Lund University

16. Switzerlan

d

Alain

Wegmann

Alain.Wegmann@epfl.

ch

Ecole Polytechnique Fédérale de

Lausanne

17. USA Jim Clevenger jim@silverglobe.com Silverglobe, Little Rock, Arkansas

18. USA,

Israel

Dov Dori** dori@mit.edu Massachusetts Institute of Technology

and Technion

19. USA Dave Howes dbhowes@usa.net Silver Bullet Solutions, Inc. San Diego,

CA (ret.)

20. USA Richard richardm@tinwisle.co Tinwisle Corporation

**Co-convener

Martin** m

21. USA Astier Sylvain sastier@axway.com Axway, Inc. Phoenix, AZ

22. USA Olivier de

Weck

deweck@mit.edu Massachusetts Institute of Technology

23. Israel Mor Peleg peleg.mor@gmail.com Haifa University and Stanford

University,

24. Israel Amira Sharon sharon.amira@gmail.co

m

Israel Aerospace Industies and Technion

25. USA Thomas Speller tspeller@gmu.edu George Mason University, Fairfax, VA

26. USA Keith Unger kunger@stonetek.com Stone Technologies, Inc.

27. USA Ricardo Valerdi rvalerdi@mit.edu Massachusetts Institute of Technology