iso/tc 184/sc 5 n1111 - israel institute of...

OPM SG Interim Report 2011-05-12

Reference number of working document: ISO/TC 184/SC 5 N1111 Date: 2011-5-12

Committee identification: ISO/TC 184/SC 5/OPM SG

Secretariat: ANSI

Object Process Methodology Study Group — Interim Report 2011

Document type: Study Group Interim Report Document stage: Preparation Document language: English This interim report is the second response from the OPM SG to SC5 regarding its Resolution 611 of April, 2009 and Resolution 624 of March 2010. The five objectives established by the OPM SG Terms of Reference and the three examples identified are addressed by two substantive Activity tracks with results to date presented in Section 3 and Section 4 with Annexes A and B and a separate Working Draft for a Meta-standard for Model-base Standards Authoring document. This WD represents progress on a normative document that ―specifies a generic approach to writing standards that uses OPM as the modelling framework and language‖ given in Annex A. Conclusions and Recommendations are stated in Section 2. The members of the OPM SG have continued to examine the utility of OPM as an aid in the preparation of SC5 work products. This effort has resulted in a better understanding of the modelling needs for various SC5 standards activities and the limits of particular modelling practices in developing ISO standards. This report details several uses of OPM to model existing standards, the use of OPM to address larger modelling issues associated with the discussion of SC5 standards activities, and identifies both the benefits and difficulties of using OPM in these efforts. Like all methodologies, adequate tools and training are critical and in this regard we find OPM less attractive than other possible methodological approaches even though the conceptual approach seems well suited to SC5 work. Therefore, we propose that SC5 adopt the following resolution. ISO TC184/SC5 meeting in Plenary session endorses the work carried out by the OPM Study Group over the past two years, accepts its second Interim Report and encourages them to extend its work so that it may address wider and still-open issues discussed in the 1st Interim Report of 2010. In particular the OPM Study Group should:

i) Continue the development of the WD for a Meta-standard for Model-based Standards Authoring as guidance for working groups to use in applying OPM to their projects with specific emphasis on the benefit of rigor supplied by the OPM models addressing consistency and completeness of the standards resulting from its application, and on the limitations of the OPM approach to the creation of SC5 standards products;

ii) Continue the effort to examine the use of OPM as an aid in the harmonization of IEC 62264 and ISO 19440 to produce a more robust standard for use by industrial enterprises that leverages the strengths of each approach and validates the guidance of the Meta-standard for Model-based Standards Authoring.

iii) Prepare a first draft of a formal definition of OPM as an ISO Technical Report to serve as the basis for model-based standards authoring and evolution.

iv) Create a proposal for a new SC5 Working Group to promulgate the Study Group efforts over the anticipated standards development interval.

TC184/SC5 N1111

ii

Contents Page

Motivation ............................................................................................................................................................v Organization ........................................................................................................................................................v

1 Scope ......................................................................................................................................................1 1.1 Terms of Reference ...............................................................................................................................1 1.2 Activity structure ...................................................................................................................................1

2 Conclusions and Recommendations...................................................................................................2 2.1 Conclusions from Activity A – Objectives 1, 2, and 5 ........................................................................2 2.2 Conclusions from Activity B – Objectives 1, 3, and 4 ........................................................................2 2.3 Conclusions from Activity C – Meta-standard for Model-based Standards Authoring ..................4 2.4 Recommendations .................................................................................................................................4 2.5 Contributing participants since the 2010 SC5 Plenary ......................................................................5 2.6 Corresponding participants ..................................................................................................................5

3 Activity A – Objectives 1, 2, and 5 ........................................................................................................6 3.1 Introduction to Object Process Methodology – OPM (retained from 1

st Interim Report) ...............6

3.2 From text-based to OPM model-based standards (retained from 1st

Interim Report) ....................6 3.3 Exploring IEC 62264-1 edition 2 draft ..................................................................................................7 3.3.1 Modelling the document and Scope statement ..................................................................................7 3.3.2 Modelling the Workflow Process revision ....................................................................................... 13 3.4 Exploring ISO 19440 ........................................................................................................................... 13 3.4.1 Clause 4 shall statements in ISO 19440 ........................................................................................... 13 3.4.1.1 Clause 4 text to model ................................................................................................................ 13 3.4.1.2 OPM model of Clause 4 shall statements ................................................................................. 14 3.4.1.3 Partitioning the Clause 4 shalls model ..................................................................................... 16 3.4.1.4 Lesson learned model Clause 4 ................................................................................................ 16 3.4.2 Clause 5.2 Construct common structure ......................................................................................... 17 3.4.2.1 OPM model of Clause 5.2 as single OPD and its partitions .................................................... 17 3.4.2.2 Clause 5.2 as partition snippets ................................................................................................ 20 3.4.2.3 Using Clause 5.2 snippets as templates for Clause 6 constructs ......................................... 27 3.4.3 An OPM model for using 19440 ......................................................................................................... 34 3.5 Exploring ISO/IEC 15416 using an OPM model ............................................................................... 40 3.6 Using OPM for a quick ‘Big Picture’ model ...................................................................................... 45 3.7 Using OPM in IEEE P2030 .................................................................................................................. 46 3.8 Using OPM for Model-based standards ........................................................................................... 46 3.8.1 Introduction to modelling of standards (retained from 1

st Interim Report) .................................. 46

3.8.2 Model-Based ISO Standard Authoring using OPM ......................................................................... 47 3.8.3 Model-Based ISO Standard Authoring OPD Hierarchy ................................................................... 48 3.8.4 Model-Based ISO Standard Authoring OPD with OPL .................................................................... 49

4 Activity B – Objectives 1, 3, and 4 ..................................................................................................... 72 4.1 Usefulness concerns .......................................................................................................................... 72 4.1.1 Fitness for Use .................................................................................................................................... 72 4.1.1.1 OPM-skills and domain experts ................................................................................................. 72 4.1.1.2 OPM for meta-modelling and harmonization ........................................................................... 73 4.1.1.3 Conformance criteria using the "shall", "should" and "may" qualifiers ............................... 73 4.1.1.4 Bi-modal expression of a standard ........................................................................................... 74 4.1.1.5 Expressive precision and efficiency ......................................................................................... 74 4.1.2 Gaining Acceptance ........................................................................................................................... 75 4.1.2.1 Advantages and disadvantages of OPM as a modelling language ........................................ 75 4.1.2.1.2 Modelling language distinct from modelling tool .................................................................... 75 4.1.2.2 Bi-modal representation of models in other languages ......................................................... 75 4.1.3 Availability and Stability .................................................................................................................... 76 4.1.3.1 Requirements for availability and stability ............................................................................... 76

TC184/SC5 N1111

iii

4.1.3.2 Extent of formal OPM, OPL, and Tesperanto specifications ................................................... 77 4.1.3.3 OPM Maturity and scalability ...................................................................................................... 78 4.1.4 Operational Considerations ............................................................................................................... 78 4.1.4.1 Requirements for operating in a standard's domain ............................................................... 78 4.1.4.2 OPM operational considerations ................................................................................................ 79 4.2 OPM as a Basis for Model-Based Standards .................................................................................... 80 4.2.1 The Standard Modelling Process ....................................................................................................... 80 4.2.1.1 OPM features essential for modelling standards ..................................................................... 80 4.2.1.2 Using OPM to model standards ................................................................................................. 81

5 Model-based standards authoring ..................................................................................................... 82 5.1 Meta-standard for model-based standard authoring ....................................................................... 82 5.2 Model authoring outline ...................................................................................................................... 82 5.3 Emerging model-based authoring capabilities ................................................................................ 83 A.1 OPM Symbology .................................................................................................................................. 84 A.2 Entities .................................................................................................................................................. 84 A.3 Structural Links and Complexity Management ................................................................................ 85 A.4 Enabling and Transforming Procedural Links ................................................................................. 86 A.5 Event, Condition and Invocation Procedural Links ......................................................................... 87 B.1 OPCAT User Guides and Tutorials .................................................................................................... 88 B.2 OPCAT OPD Hierarchy sequencing .................................................................................................. 88 B.2.1 OPCAT OPD Hierarchy in-zoom verses unfold ................................................................................ 88 B.2.2 OPCAT OPD Hierarchy sequence re-ordering ................................................................................. 89 B.3 OPCAT Model fragment management ............................................................................................... 89 B.4 OPCAT Helpful additions .................................................................................................................... 89

Table of Figures

Figure 1 — IEC 62264-1-ed2 OPM System Diagram ........................................................................................ 8 Figure 2 — IEC 62264-1-ed2 document object unfolded ................................................................................ 8 Figure 3 — Informative preliminary object unfolded ...................................................................................... 8 Figure 4 — Introduction object unfolded ......................................................................................................... 9 Figure 5 — Normative general object unfolded .............................................................................................. 9 Figure 6 — Clause 1 Scope object unfolded ................................................................................................. 10 Figure 7 — Normative technical object unfolded .......................................................................................... 11 Figure 8 — Informative supplementary object unfolded .............................................................................. 11 Figure 9 — IEC 62264-1-ed2 partial OPM model OPL listing ....................................................................... 12 Figure 10 — ISO 19440 Clause 4 shall statements as OPM model with OPD and OPL ............................ 16 Figure 11 — ISO 19440 Clause 4 shall statements as partitioned OPM model .......................................... 16 Figure 12 — ISO 19440 Clause 5.2 as OPM model with OPD and OPL ....................................................... 19 Figure 13 — ISO 19440 Clause 5.2 as partitioned OPM model .................................................................... 20 Figure 14 — OPCAT tool listing of Construct_template Views ................................................................... 20 Figure 15 — Clause 5.2 Construct_template System Diagram .................................................................... 21 Figure 16 — Clause 5.2 Construct_template View 2 : Relationship Attribute unfolded ........................... 22 Figure 17 — Clause 5.2 Construct_template View 2 : Header Part unfolded ............................................. 23 Figure 18 — Clause 5.2 Construct_template View 3 : A – Descriptives partition unfolded ...................... 24 Figure 19 — Clause 5.2 Construct_template View 4 : B – Relationships partition unfolded ................... 25 Figure 20 — Clause 5.2 Construct_template View 5 : Clause 6.1.3 – Notation .......................................... 26 Figure 21 — Clause 5.2 Construct_template View 6 : Textual Constituent unfolded ............................... 26 Figure 22 — Capturing Name attribute values in object detail description and notes ............................. 28 Figure 23 — Capturing Activity Behaviour attribute values in object detail description and notes ....... 28 Figure 24 — Clause 6 Business Process Descriptives partition ................................................................. 29 Figure 25 — Clause 6 Business Process Relationships partition ............................................................... 30 Figure 26 — Clause 6 Enterprise Activity Descriptives partition ................................................................ 31 Figure 27 — Clause 6 Enterprise Activity Relationships partition .............................................................. 32 Figure 28 — Clause 6 Event Descriptives partition ...................................................................................... 33 Figure 29 — Clause 6 Event Relationships partition .................................................................................... 33 Figure 30 — Enterprise modelling System Diagram using ISO 19440 ........................................................ 34 Figure 31 — Enterprise modelling OPD EN IS 19440 unfolded ................................................................... 34

TC184/SC5 N1111

iv

Figure 32 — Enterprise modelling OPD EN IS 19440 Specification unfolded ........................................... 35 Figure 33 — Enterprise modelling process in-zoomed ............................................................................... 35 Figure 34 — Model constructing in-zoomed ................................................................................................. 35 Figure 35 — Domain identifying in-zoomed .................................................................................................. 36 Figure 36 — DM Domain identifying in-zoomed ........................................................................................... 36 Figure 37 — EO Domain identifying in-zoomed ........................................................................................... 36 Figure 38 — Enterprise modelling OPM model whole OPL ......................................................................... 39 Figure 39 — ISO/IEC 15416 OPM SD model with OPL ................................................................................. 40 Figure 40 — Bar Code Print Quality Standard Text Specifying unfolded OPD with OPL ........................ 40 Figure 41 — ISO/IEC 15416 unfolded OPD with OPL ................................................................................... 41 Figure 42 — Bar Code Print Quality Standard Test Specification in-zoom with OPL .............................. 41 Figure 43 — Bar Code Symbol Attribute Measuring in-zoom with OPL .................................................... 42 Figure 44 — Bar Code Symbol Grading in-zoom with OPL ......................................................................... 42 Figure 45 — Informative Annex unfolded with OPL ..................................................................................... 43 Figure 46 — Normative Annex unfolded with OPL ....................................................................................... 43 Figure 47 — Clause 2 Normative References unfolded with OPL .............................................................. 44 Figure 48 — Bar Code unfolded with OPL .................................................................................................... 44 Figure 49 — Big Picture OPM model OPD and OPL ..................................................................................... 46 Figure 50 — Model-Based ISO Standard Authoring OPD Hierarchy .......................................................... 48 Figure 51 — Model-Based ISO Standard Authoring OPM model System Diagram with OPL .................. 49 Figure 52 — Model-Based ISO Standards Development Processing in-zoomed OPD with OPL ............ 50 Figure 53 — Model-Based ISO Standard Authoring in-zoomed OPD with OPL ........................................ 51 Figure 54 — Input Document Preparing in-zoomed OPD with OPL ........................................................... 52 Figure 55 — Input Content Identifying in-zoomed OPD with OPL .............................................................. 53 Figure 56 — Standard Foundation Laying in-zoomed OPD with OPL ........................................................ 54 Figure 57 — Standard Foundation Modeling in-zoomed OPD with OPL ................................................... 55 Figure 58 — Standard Foundation Modeling in-zoomed OPD with OPL ................................................... 56 Figure 59 — First Draft Preparing in-zoomed OPD with OPL ..................................................................... 57 Figure 60 — Proposed Standard Revising in-zoomed OPD with OPL ....................................................... 58 Figure 61 — Proposed Standard Managing in-zoomed OPD with OPL ..................................................... 59 Figure 62 — External Version Identifying in-zoomed OPD with OPL ......................................................... 60 Figure 63 — Existing Draft Setting in-zoomed OPD with OPL .................................................................... 61 Figure 64 — ISO Guidelines Checking in-zoomed OPD with OPL .............................................................. 62 Figure 65 — ISO Ballotting in-zoomed OPD with OPL ................................................................................. 63 Figure 66 — Ballot Initiating in-zoomed OPD with OPL ............................................................................... 64 Figure 67 — Ballot Registering in-zoomed OPD with OPL .......................................................................... 65 Figure 68 — New Work Item Proposal Registering in-zoomed OPD with OPL ......................................... 66 Figure 69 — Ballot Decision Recording in-zoomed OPD with OPL ............................................................ 67 Figure 70 — NSB Ballotting in-zoomed OPD with OPL ............................................................................... 68 Figure 71 — New Standard Document unfolded OPD with OPL ................................................................. 68 Figure 72 — Proposed Standard unfolded OPD with OPL .......................................................................... 69 Figure 73 — Part Set unfolded OPD with OPL .............................................................................................. 69 Figure 74 — Standard Document Parts unfolded OPD with OPL ............................................................... 69 Figure 75 — Normative technical unfolded OPD with OPL ......................................................................... 70 Figure 76 — Normative general unfolded OPD with OPL ............................................................................ 70 Figure 77 — Informative supplementary unfolded OPD with OPL ............................................................. 70 Figure 78 — Informative preliminary unfolded OPD with OPL.................................................................... 71 Figure 79 — ISO Ballot Result Comments unfolded OPD with OPL .......................................................... 71 Figure 80 — NSB Comment Set unfolded OPD with OPL ............................................................................ 71 Figure 81 — Proposed new constructs (OPD and OPL) for normative specification ............................... 74

TC184/SC5 N1111

v

Introduction

Motivation

International Standards are supposed to be a solid source of authority and must therefore be unambiguous, consistent, and accessible. However, standards are often criticized as difficult to use for a variety of reasons, including inter- and intra-standard consistency, low accessibility, poor traceability, and ambiguity. One source of these problems is that standards are authored using free text, which is sometimes accompanied by graphical annotation, figures, diagrams, or expressions in special language notations. Quite often the figures and expression notations do not match the text or conflict with other figures and expressions. In addition, many experts and authors contribute to the text with different writing styles and subject matter perspectives.

Over the past ten years the preferred modelling approaches and modelling languages used in International Standards under the guidance of SC5 are the graphical Universal Modelling Language (UML) and its codification as ISO/IEC 19501, Extensible Markup Language (XML) derived from ISO 8879, EXPRESS and its graphical form EXPRESS-G codified as ISO 10303-11, and various formal languages like the Knowledge Interchange Format (KIF) used for the Process Specification Language (PSL) series ISO 18629.

The examination of the Object-Process Methodology continues the effort on the part of SC5 experts to provide comprehensive standards with sufficient clarity that they are understandable by a wide range of international constituents. OPM offers a new opportunity to link the graphical forms of models with normative text in synchronization using simple graphical models and a structured English text.

Managing the quality of a technical document such as an International Standard is a daunting task given the variety of authors and relationships to other domain standards. Currently there is no commonly accepted analytical process that provides some sense of technical document verification and validation beyond acceptance and use by industry. Our objective is to assure that the standards documents we produce are internally consistent and conceptually complete so that the marketplace will find that compliance with our standards is useful and beneficial to international commerce.

Organization

ISO Technical Committee 184 Sub-Committee 5 (TC 184/SC 5) is tasked with developing and overseeing International Standards related to automation systems and integration for enterprises. At its Plenary Meeting in Paris on April 23-24, 2009, ISO/TC 184/SC 5, in Resolution 611 (Paris 21), unanimously resolved to establish the Object Process Methodology Study Group (OPM SG) "to explore the usefulness of Object Process Methodology for creating, designing, analysing, and simulating models of SC5 standards to improve the development, communication and understanding of these standards." The resolution asked the co-Conveners to collaborate on a Terms of Reference document [3] for this study group to accompany the call of experts. In response, a group of 27 experts from a dozen countries, listed in the clause 2.4, expressed interest in participating in the SG. The SG conducted online sessions between some participants and used electronic exchange of documents and models.

Upon delivery of the 1st Interim Report at its Plenary Meeting in Tokyo on March 25-26, 2010, ISO/TC184/SC5

adopted Resolution 624 that continued the effort with a focus on producing a ―draft normative document for a generic approach to standards using the OPM approach‖ and to draw examples for three existing standards: ISO/CEN 19440, ISO/IEC 19782, and IEC 62264.

Interim Report TC184/SC5 N1111

1

Object Process Methodology Study Group — Interim Report 2011

1 Scope

1.1 Terms of Reference

The Terms of Reference for the OPM Study Group identifies five objectives:

1. 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.

2. Examine problems and missing integration or verification activities in current practices for developing and maintaining enterprise standards.

3. Stipulate the requirements from a modelling language perspective that would meet the OPM SG goal in view of the needs identified and requirements elicited in item 1 above.

4. Examine advantages and disadvantages of current possible conceptual modelling language candidates that potentially meet the requirements, including (but not necessarily limited to) SysML, PSL (ISO 18629), BPMN, and OPM.

5. Work out examples and generalize lessons learned in the following areas:

a. Modelling of ontology and glossary definitions,

b. Modelling to detect and eliminate intra-standard inconsistency,

c. Modelling to detect and eliminate inter-standard inconsistency,

d. Creating and evolving a Web-accessible set of model snippets to be used as standard building blocks for enterprise architecture, and

e. Applying model snippets in one or more actual enterprise architecture showcases.

1.2 Activity structure

There are two broad activities outlined in the SC5 OPM Study Group Terms of Reference. Objectives 1, 2, and 5 have to do with the development of standards and OPM's utility in that effort. The first years effort based upon IEC 62264 is expanded to include efforts with ISO 19440 and ISO/IEC 19782 as existing standards to which OPM is applied. We group these objectives as Activity A. Work on these issues is presented in Section 3 of the Interim Report. Primary contributors to this section of the report are Dov Dori, Alex Blekhman, David Shorter, James Brucato, Chen Linchevski, and Richard Martin.

Objectives 1, 3, and 4 have to do with an evaluation of OPM as a modelling tool for SC5 use throughout the range of standard development and interoperation assessment that is the work of SC5 participants. Work on these objectives is presented in Section 4 of the Interim Report. Primary contributors to this section of the report are David Shorter, Richard Martin and Dov Dori.

A third activity involves the generation of an OPM model that is a Meta-standard for Model-based Standards Authoring as called for in SC5 Resolution 624. This work is based upon an original OPM effort by David Howes, which was revised and extended by Richard Martin, David Shorter and Chen Linchevski. The working

TC184/SC5 N1111

2

draft document and subsequent model revision are the work of Dov, Dori and Alex Blekhman. This work is reported briefly in Section 5 and fully expressed in SC5 N1112.

2 Conclusions and Recommendations

2.1 Conclusions from Activity A – Objectives 1, 2, and 5

Conclusions specific to IEC 62264, ISO 19440, and ISO/IEC 19782 as analyzed by the ISO TC184/SC5 OPM SG include:

- OPM offers a modelling methodology that can be applied to a wide variety of SC5 and other ISO and IEC standards to help understand their content.

- While OPM models of specific clauses may assist in identifying inconsistencies within or between standards, there seems to be little benefit from the extraordinary amount of effort required to produce OPM models for the entire standard. Sentence structure and sub-clause phrasing are often more complex as natural language than can be concisely expressed in the restricted language of a modelling methodology.

- For the most part these exemplar standards specify information models rather than process or procedural models. Therefore, the process oriented OPM approach is of less utility because the ‗object‘ only use of OPM produces much weaker correspondence to the clause structure of information only standards.

- This work indicates the viability and benefits of using a modelling language in general and OPM in particular to significantly improve the quality and the value of standards. Using OPM does identify opportunities for improvement in each of the standards. However, it is not clear whether the realization of improvement opportunity is the result of OPM use per se or the result of the modelling effort undertaken to utilize OPM. A significant aspect of this result is that OPM can be used to sketch the implementation of the information oriented standard and this sketching identifies weaknesses in the standard itself.

- Even when a standard exists, different experts will model the same text as sometimes substantially different models. This would imply that adopters of a standard will also comply with the standard in different ways. Therefore, a significant advantage for a model-based standard should be a uniformity of compliance based upon the model for which the model-based text becomes elaborated by further explanation of the specification. In this regard, consistency and completeness is necessary for the model-based standard to be of sufficient quality to allow uniform compliance.

- With the extent of inconsistencies that have been identified concerning the examination of the example standards, it is not likely the OPM snippets can fully resolve or even identify all of the potential compliance issues that might arise. For the very detailed specification of ISO/IEC 19782, compliance is much more straight-forward than for IEC 62264, which provides many isolated compliance points. ISO 19440, which is a standard for modelling constructs, may be implemented in many different ways, all of which could be in compliance.

- In the case of all three of the example standards, domain expertise is critical to the preparation of a satisfactory OPM model. Transposing the normative text into an OPM model with generated OPL that can be rearranged to parity the normative text is insufficient. Domain specific ontology and practice are implied qualities of a standard that cannot always be overcome.

2.2 Conclusions from Activity B – Objectives 1, 3, and 4

To determine the usefulness of OPM, we examined four significant areas of concern: fitness for use, gaining acceptance, availability and stability, and operational management. During this past year as our work with OPM escalated, we were able to resolve a few of the previously identified issues and verify the extent of other concerns. More specifically we find evidence that:

TC184/SC5 N1111

3

- OPM is on the surface a straightforward language to learn. But as with any modelling language, the nuance of use can be much more difficult as design and implementation choices of a tool impose further restrictions on language use.

- As a methodology OPM advocates top-down refinement beginning at the central process in the System Diagram. This approach aligns well with the way enterprise and device standards are structured beginning with a statement of scope. But seldom do we actually develop a standard from the top down once a scope is determined. Our work effort is most often middle out or even bottom up. And while OPM does promote the creation of model snippets or fragments, integrating those pieces into a uniformly presented model can be very difficult, just as it is in crafting the normative text in the manner to which we are already accustomed.

- The learning curve for OPM itself is not steep. The concepts are few in number. But because of the power that any set of simple concepts provide, using them well in a wide variety of situations is far more difficult. It will be especially difficult for ISO experts not familiar with graphical modelling sets to grasp the effective use of those concepts. For those crafting the information-oriented standard where process explication is minimal or non-existent, UML or XML will be a more natural choice for expressing the information model.

- We have seen no evidence that the Tesperanto language effort associated with OPM has made much progress over the past year and it is still necessary to restate the Object-Process Language result of Object-Process Models into natural language text that meets the style and usage criteria of the ISO CS editors. While the formal underpinning of OPM assures the integrity of the OPL statements, their translation into natural language can violate that formal basis. Of particular concern is language associated with the normative text were the lack of a suitable deontic OPM syntax can lead to incorrect or inadequate normative expressions. .

- It is clear that the bi-modal expression resulting from OPM could be beneficial to those developing a standard. Previously an examination of some other potential modelling languages for use in the same manner indicated their deficiencies with respect to OPM. In particular the nesting of concepts and a simple yet complete syntactic structure make OPM stand out.

- OPCAT is a Java-based tool to support OPM, normally provided as a PC exe executable file. With help of the OPCAT development team, we have managed to get a working version of the tool on the Apple OSX JVM environment and to document the steps necessary. The availability of satisfactory technical assistance for a large group of standards developers appears unlikely without much more market uptake of the OPCAT product. Without some competitive sources of tooling, OPM is a single supplier product that is not suitable for wide spread use.

- The formal specification of OPM and OPL as a Technical Report could spur uptake by other tool vendors and allow wider use opportunity. The basic product is satisfactory for our investigations but hardly suitable for more sustained efforts by the developers of new standards on an ISO timeline unless they were already conversant with the OPCAT tool and had available specific guidance for use in the ISO context.

- Operational management remains a concern. In a disciplined design and development environment the OPCAT collaboration facilities may be adequate but in the less constrained and widely divergent environment of ISO working groups that same extent of collaboration is insufficient. ISO experts are essentially volunteers, often working on their own time or constrained by other duties. They work independently with collaboration points occurring at the time of comment resolution. It is difficult to imagine how a ballot comment consisting of several different OPM snippet proposals could or should be resolved. Even simple UML models can take several sessions to resolve.

- The integration of model fragments upon which OPM depends for model consistency checking will be a management issue for large systems; however we note this problem exists with all current modelling paradigms. It will be especially important to identify the means and mechanisms for OPM model maintenance over revisions and amendments to a standard.

Finally, we have assembled in Annex B a list of OPCAT tool features that seem awkward or insufficient for large scale SC5 OPM use.

TC184/SC5 N1111

4

2.3 Conclusions from Activity C – Meta-standard for Model-based Standards Authoring

There are two portions to this activity. The first began as an effort to model the current ISO standard development process from inception of a concept for a standard through its balloting stages to final publication and identify where the model-based aspect of standardization fit into that process. The second portion was to take the processes that touched upon the model-based aspects and elaborate the model generation processes.

The first portion resulted in a fully executable OPM model Model-based ISO Standard Authoring – Final.opx that moves a document from concept through each of the ISO stages of balloting to final publication. The purpose of this model is to document, for those not already familiar with the ISO processes, the manner in which a document is managed and, for those already familiar with the process, the use of OPM with simulation to model a complex process with which they were familiar.

The second portion resulted in the preparation of the Model-base Standards Authoring – Final.opx OPM model and Meta-standard for model-base standards authoring working draft. Using the first portion to identify touch points, this model elaborates model-based aspects of standard‘s authoring.

2.4 Recommendations

This report presents what has been achieved and demonstrates the promise and applicability of OPM for supporting the analysis and drafting of enterprise standards. This report also identifies significant impediments for OPM, or any other modelling paradigm, to manage the complex tasks involved in the development, publishing and use of International Standards. The Study Group recommends that ISO TC184 SC5:

(i) Endorse the work carried out by the OPM Study Group over the past year;

(ii) Continue the development of the WD for a Meta-standard for Model-based Standards Authoring as guidance for working groups to use in applying OPM to their projects with specific emphasis on the benefit of rigor supplied by the OPM models addressing consistency and completeness of the standards resulting from its application, and on the limitations of the OPM approach to the creation of SC5 standards products;

(iii) Continue the effort to examine the use of OPM as an aid in the harmonization of IEC 62264 and ISO 19440 to produce a more robust standard for use by industrial enterprises that leverages the strengths of each approach and validates the guidance of the Meta-standard for Model-based Standards Authoring.

(iv) Prepare a first draft of a formal definition of OPM as an ISO Technical Report to serve as the basis for model-based standards authoring and evolution.

(v) Create a proposal for a new SC5 Working Group to promulgate the Study Group efforts over the anticipated standards development interval.

.

TC184/SC5 N1111

5

2.5 Contributing participants since the 2010 SC5 Plenary

**Co-convener

2.6 Corresponding participants

SC 5 P-Member/ Country

Name e-mail Organization

1. Great Britain

David Shorter [email protected] IT Focus;Convenor of CEN TC310 WG1

2. Israel Alex Blekhman [email protected] Technion

3. Israel Arnon Sturm [email protected] Ben Gurion University

4. Italy James Brucato [email protected]

U.Gi.J.srl

5. USA, Israel Dov Dori** [email protected] Massachusetts Institute of Technology and Technion

6. USA Dave Howes [email protected] Silver Bullet Solutions, Inc. San Diego, CA (ret.)

7. USA Richard Martin**

[email protected] Tinwisle Corporation

SC 5 P-Member/ Country

Name e-mail Organization

8. Canada Michael Gruninger

[email protected] University of Toronto

9. Canada Mark Richer [email protected] Pratt & Whitney Canada

10. China Liu Wenyin [email protected] City University of Hong Kong

11. China Qing Li [email protected] City University of Hong Kong

12. France Daniel Krob [email protected] Ecole Polytechnique

13. Germany Uwe Kaufmann

[email protected]

ModelAlchemy Consulting

14. Israel Pnina Soffer [email protected] Haifa University

15. Israel Mor Peleg [email protected] Haifa University and Stanford University,

16. Israel Amira Sharon [email protected] Israel Aerospace Industies and Technion

17. Korea Dongmin Shin [email protected] Hanyang University

18. Korea S.K. CHA [email protected] Advenced Computer Service Co., Ltd. Appointed by KATS – Korean Agency for Technology and Standards

19. Singapore Yeo Khim Teck [email protected] Nanyang Technological University

20. Sweden Charlotta Johnsson

[email protected]

Lund University

21. Switzerland Alain Wegmann

[email protected] Ecole Polytechnique Fédérale de Lausanne

22. USA Jim Clevenger [email protected] Silverglobe, Little Rock, Arkansas

23. USA Astier Sylvain [email protected] Axway, Inc. Phoenix, AZ

24. USA Olivier de Weck [email protected] Massachusetts Institute of Technology

25. USA Thomas Speller [email protected] George Mason University, Fairfax, VA

26. USA Keith Unger [email protected] Stone Technologies, Inc.

27. USA Ricardo Valerdi [email protected] Massachusetts Institute of Technology

mailto:[email protected]



























TC184/SC5 N1111

6

3 Activity A – Objectives 1, 2, and 5

3.1 Introduction to Object Process Methodology – OPM (retained from 1st Interim Report)

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 modelling 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 modelling complex systems that comprise technology and humans.

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 easily understood by domain experts, who need not learn any special language nor decipher cryptic code.

OPM notation supports conceptual modelling of systems. Its top-down approach includes refinement mechanisms of in-zooming and unfolding. OPM uses one kind of diagram to describe the functional, structural and behavioural aspects of the system. OPCAT [2], an OPM-based conceptual modelling 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. See Annex B for a discussion of OPCAT use by SC5.

OPM objects relate to each other via structural relations, expressed graphically as structural links. Structural links 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 mitigate a systems' complexity. Each OPD is obtained by in-zooming processes or unfolding objects 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.

3.2 From text-based to OPM model-based standards (retained from 1st Interim Report)

The reason for exploring the usefulness of OPM to SC5 work is the claim that formal documents of a technical nature that specify complex systems in general, and enterprise standards in particular, can and should be

TC184/SC5 N1111

7

verified and validated using a model that is both formal and humanly accessible with automatic translation into a constrained, normalized subset of English.

OPM is potentially suitable as the modelling language for the task at hand, since one of its most prominent features is the fact noted above that OPM is bi-modal, i.e., it has two equivalent representations: graphic, as a set of Object-Process Diagrams (OPDs), and textual, as a corresponding set of Object-Process Language (OPL) sentences, which are constrained English sentences constructed on-the-fly in response to the graphic input of the modeller.

An OPM model-based expression of the content of an International Standard should enable not only checking and establishing consistency between the graphic and textual representation, but also the capability to develop and to deploy tools for machine processing of a standards‘ text, automatic generation of links among ontology entities, automated consistency checks, and examining adherence of field implementations to pertinent enterprise standards.

The central premise of the OPM model-based approach is the development of an underlying extendable OPM model of the domain's ontology that could be shared by all the standards related to the same domain or domains of sufficient similarity. This comprehensive and multi-disciplinary framework could 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 would link terms and definitions, frequent phrase structures, business rules, enterprise design patterns, best practices, and more.

3.3 Exploring IEC 62264-1 edition 2 draft

3.3.1 Modelling the document and Scope statement

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. IEC 62264 is undergoing revision to reorganize the Parts and align text in appropriate clause. The OPM SG began to create an OPM model of the new Part 1 Scope statement as presented in N1091 dated July 14, 2010. The Scope statement examined is:

This standard describes the manufacturing operations management domain (Level 3) and its activities, and the interface content and associated transactions within Level 3 and between Level 3 and Level 4. This description enables integration between the manufacturing operations and control domain (Levels 3,2,1) and the enterprise domain (Level 4). The interface content between Level 3 and Level 2 is only briefly discussed. The goals are to increase uniformity and consistency of interface terminology and reduce the risk, cost, and errors associated with implementing these interfaces. The standard can be used to reduce the effort associated with implementing new product offerings. The goal is to have enterprise systems and control systems that inter-operate and easily integrate. . The scope of this part is limited to a) a presentation of the enterprise domain and the manufacturing operations and control domain; b) the definition of three hierarchical models; a functional hierarchy model, a role-based equipment hierarchy model, and a physical asset equipment hierarchy model; c) a listing of the functions associated with the interface between manufacturing operations and control functions and enterprise functions; and d) a description of the information that is shared between manufacturing operations and control functions and enterprise functions.

The set of figures below are OPM Object-Process Diagrams, OPDs, created to situate the scope statement within the standard and to express the scope as an OPM model. Each figure includes the graphic OPD and the associated Object-Process Language, OPL, statements generated by the graphic representation. The scope is depicted in Figure 6. The remaining figures in this section are for IEC 62264 to the extent our modelling was conducted in this activity.

TC184/SC5 N1111

8

In these figures and others throughout this report depicting the OPM OPL associated with an OPD, the green fonts indicates an object, blue indicates a process, and black indicates links between them.

IEC 62264-1:2012 Enterprise-Control System Integration - Part 1: Models and Terminology consists of IEC 62264-1-ed2

document and IEC 62264-1-ed2 Model-base standard model.

Figure 1 — IEC 62264-1-ed2 OPM System Diagram

IEC 62264-1-ed2 document consists of Informative preliminary, Normative Set, and Informative supplementary.

Normative Set consists of Normative general and Normative technical.

Figure 2 — IEC 62264-1-ed2 document object unfolded

Informative preliminary consists of Title Page, Table of Contents, Foreword, and Introduction.

Table of Contents consists of Clause Index and Figures Index.

Figure 3 — Informative preliminary object unfolded

TC184/SC5 N1111

9

ISO/IEC 62264-1-ed2 Standard exhibits Goal.

Introduction provides preparation & technical content reasons for ISO/IEC 62264-1-ed2 Standard.

Enterprise-Manufacturing Interoperability & Integration is a Goal.

Interface Implementation Risk Cost & Error Set Reducing requires Enterprise-Manufacturing Interoperability &

Integration and Uniformity & Consistency.

Interface Implementation Risk Cost & Error Set Reducing affects Risk Cost & Error Set.

Figure 4 — Introduction object unfolded

Normative general consists of Clause 1 - Scope, Clause 2 - Normative References, and Title.

Figure 5 — Normative general object unfolded

TC184/SC5 N1111

10

ISO/IEC 62264-1-ed2 Standard describes Enterprise Domain (Level 4).

ISO/IEC 62264-1-ed2 Standard specifies Enterprise Domain - MO&C Domain Interface.

ISO/IEC 62264-1-ed2 Standard defines Hierarchy Model.

ISO/IEC 62264-1-ed2 Standard describes Manufacturing Operations & Control Domain (Level 3).

Manufacturing Operations & Control Domain (Level 3) exhibits MO&C Functions Set (activities).

Manufacturing Operations & Control Domain (Level 3) and Enterprise Domain - MO&C Domain Interface are

connected.

Enterprise Domain - MO&C Domain Interface exhibits Interface Terminology and Shared Information, as well as

Interface Functions Set.

Enterprise Domain - MO&C Domain Interface enables Enterprise-Manufacturing Interoperability & Integration.

Enterprise Domain - MO&C Domain Interface utilizes Hierarchy Model.

Enterprise Domain - MO&C Domain Interface and Enterprise Domain (Level 4) are connected.

Enterprise Domain (Level 4) exhibits Enterprise Functions Set.

Clause 1 - Scope specifies the scope of ISO/IEC 62264-1-ed2 Standard.

Functional hierarchy model is a Hierarchy Model.

Role-base equipment hierarchy model is a Hierarchy Model.

Physical asset equipment hierarchy model is a Hierarchy Model.

Interface Implementing requires Enterprise Domain - MO&C Domain Interface.

Interface Implementing yields Interface Implementation.

Figure 6 — Clause 1 Scope object unfolded

Notice that this model snippet does not mention Levels 2 and 1, identified in the second sentence of the scope statement, as included in the Manufacturing Operations & Control Domain because they are not relevant to the specification of the Enterprise Domain – MO&C Domain Interface, which is the subject matter of the standard. However, there is a sentence in the scope statement indicating that ―The interface content between Level 3 and Level 2 is only briefly discussed.‖ Figure 4 addresses the 4th sentence of the scope statement to become a part of the whole OPL listing of Figure 9. The ―goal‖ statements of the scope are brought together into a single thread in Figure 4 to assure that they are not in conflict. The limitations, or more correctly the scope subject matter, of this part are expressed in Figure 6.

TC184/SC5 N1111

11

Normative technical consists of Clause 3 - Terms, Definitions And Abbreviations, Clause 4 - Enterprise-Control System

Integration Overview, Clause 5 - Hierarchy Models, Clause 6 - Functional Data Flow Model, Clause 7 - Manufacturing

Operations, Clause 8 - Information Model, and Clause 9 - Completeness, Compliance And Conformance.

Figure 7 — Normative technical object unfolded

Informative supplementary consists of Annex A, Annex B, Annex C, Annex D, and Bibliography.

Figure 8 — Informative supplementary object unfolded

TC184/SC5 N1111

12

Figure 9 below is the whole OPL listing derived from the 8 figures that compose the IEC 62264-1-ed2 OPM model. In this listing duplicates are eliminated as appropriate, e.g. unfolded objects are stated once.

ISO/IEC 62264-1-ed2 Standard exhibits Goal.

ISO/IEC 62264-1-ed2 Standard describes Enterprise Domain (Level 4).

ISO/IEC 62264-1-ed2 Standard specifies Enterprise Domain - MO&C Domain Interface.

ISO/IEC 62264-1-ed2 Standard defines Hierarchy Model.

ISO/IEC 62264-1-ed2 Standard describes Manufacturing Operations & Control Domain (Level 3).

Manufacturing Operations & Control Domain (Level 3) exhibits MO&C Functions Set (activities).

Manufacturing Operations & Control Domain (Level 3)

and Enterprise Domain - MO&C Domain Interface are connected.

Enterprise Domain - MO&C Domain Interface exhibits Interface Terminology and Shared Information,

as well as Interface Functions Set.

Enterprise Domain - MO&C Domain Interface enables Enterprise-Manufacturing Interoperability & Integration.

Enterprise Domain - MO&C Domain Interface utilizes Hierarchy Model.

Enterprise Domain - MO&C Domain Interface and Enterprise Domain (Level 4) are connected.

Enterprise Domain (Level 4) exhibits Enterprise Functions Set.

IEC 62264-1:2012 Enterprise-Control System Integration - Part 1: Models and Terminology

consists of IEC 62264-1-ed2 document

and IEC 62264-1-ed2 Model-base standard model.

IEC 62264-1-ed2 document consists of Informative preliminary, Normative Set,

and Informative supplementary.



Introduction provides preparation

& technical content reasons for ISO/IEC 62264-1-ed2 Standard.


Normative general consists of Clause 1 - Scope, Clause 2 - Normative References, and Title.

Clause 1 - Scope specifies the scope of ISO/IEC 62264-1-ed2 Standard.

Normative technical consists of Clause 3 - Terms, Definitions And Abbreviations,

Clause 4 - Enterprise-Control System Integration Overview,

Clause 5 - Hierarchy Models,

Clause 6 - Functional Data Flow Model,

Clause 7 - Manufacturing Operations,

Clause 8 - Information Model,

and Clause 9 - Completeness, Compliance And Conformance.

Informative supplementary consists of Annex A, Annex B, Annex C, Annex D, and Bibliography.

Functional hierarchy model is a Hierarchy Model.

Role-base equipment hierarchy model is a Hierarchy Model.

Physical asset equipment hierarchy model is a Hierarchy Model.

Enterprise-Manufacturing Interoperability & Integration is a Goal.

Interface Implementing requires Enterprise Domain - MO&C Domain Interface.

Interface Implementing yields Interface Implementation.

Interface Implementation Risk Cost & Error Set Reducing

requires Enterprise-Manufacturing Interoperability & Integration

and Uniformity & Consistency.

Interface Implementation Risk Cost & Error Set Reducing affects Risk Cost & Error Set.

Figure 9 — IEC 62264-1-ed2 partial OPM model OPL listing

This OPM model uses the outline for a standard document given in ISO/IEC Directives, Part 2 Table 2. The Scope statement is elaborated as two OPD snippets in Figure 4 and Figure 6. The actual major clause titles are given in Figure 5, Figure 7, and Figure 8. While we have attempted other work with the IEC 62264 series and the on-going revisions to them, the lack of technical expertise from the ISA or IEC working groups has severely impaired that effort. The direct involvement of relevant technical expertise is critical to any modelling effort and especially so for those focused on International Standards.

TC184/SC5 N1111

13

3.3.2 Modelling the Workflow Process revision

As a way to focus on a particular portion of the revision, we examined the proposal for a revision of Clause 8.14 Workflow process. The revision proposal is characteristic of the approach to describing the elements of the interface specification between ERP and MES found in other clauses of IEC 62264. A UML model depicts the information structure, which is augmented with brief textual description and tables of attributes. Unfortunately, the preliminary work on this model has languished as other projects of the OMP SG took priority.

To date Kurt Kosanke has adapted the Clause 8.14 proposal into an ISO 19440 compliant version. (R. Martin will report on this effort as part of the WG1 Convener‘s Report presentation.) We expect to continue this examination at some future date.

3.4 Exploring ISO 19440

ISO 19440 is a product resulting from the collaboration between ISO TC184/SC5/WG1 and CEN TC310/WG1 working under the guidance of the Vienna Agreement between ISO and CEN. ISO 19440 originated as European standard EN-12204 entered as the draft for the CEN led ISO project. The standard was revised and elaborated to become an International Standard in 2007. Because several OPM SG participants were involved in the 19440 effort, the standard became a suitable target for investigating the utility of OPM to model standards.

Three specific tasks emerged. The first is an examination of the ‗shall‘ statements in Clause 4 of the standard. To be useful for ISO authors, it is necessary that OPM models can correctly express the normative specifications found in ISO documents. The second involved the modelling of Clause 5 and Clause 6 while the third task involved using OPM to specify a way to use the constructs to build an operational model of an enterprise.

3.4.1 Clause 4 shall statements in ISO 19440

3.4.1.1 Clause 4 text to model

Clause 4 of ISO 19440 is titled ―Common characteristics of modelling language constructs‖. The text is as follows (emphasis added):

Clause 4, 3rd

paragraph -

This standard is concerned with business process-oriented enterprise modelling. Therefore, the enterprise entities to be represented shall be Business Processes with their dynamics (control flow/process behaviour), functionalities (activities, inputs/outputs, control, resources) and organizational aspects. These entities shall be represented at the different model phases and described at the appropriate level of detail. In addition, the representation of aggregations shall be supported not only for the Business Process/Enterprise Activity relation, but also for the enterprise entities that are affected by those Business Processes. Function-, information-, resource- and organization-model views shall be used to provide the foundation for user-oriented modelling. Those model views shall allow the identification of relevant object hierarchies and relationships between the different classes and sub-classes.

Clause 4 4th paragraph -

Modelling of the enterprise shall be supported at all enterprise model phases by modelling language constructs:

At the domain identification phase, to identify the contents of the domain and its inputs and outputs, in such a way that the domain identification model can be used as the starting point for a derivation of a consistent concept definition model.

TC184/SC5 N1111

14

At the concept definition phase, to define underlying missions, strategies, etc. and in such a way that the concept definition model can be used as the starting point for a derivation of a consistent requirement definition model.

At the requirements definition phase, to describe the Business Processes of the Domain from a business viewpoint, in such a way that the requirements definition model can be demonstrated to be sufficient to be used as the starting point for the derivation of a consistent design specification model. Therefore the requirements definition model shall also be capable of being processed.

At the design specification phase, to specify the Business Processes with all their components from both a business and ICT viewpoint, in such a way that the design specification model can be demonstrated to be sufficient to be used as the starting point for a consistent derivation of an implementation description model. Therefore the design specification model shall also be capable of being processed. At the design specification phase, constructs shall be derived from those of the requirements definition phase by enriching them with attributes that reflect all resources and general ICT interfaces.

At the implementation description phase, to describe the Business Processes with all their components as they are implemented in the actual system from both a business and ICT viewpoint, in such a way that the implementation model can be demonstrated to be sufficient to be used in the operation of the enterprise for decision support and Business Process monitoring and control. Therefore the implementation model shall also be capable of being processed. At the implementation description phase, constructs shall reflect the hardware/software platform or technology chosen to be consistent with design specification constructs.

At the domain operation phase, to use the released model for operational purposes such as decision support, monitoring and control.

At the decommission definition phase, to identify future use of the Business Process components, in such a way that the decommission definition model can be used as appropriate as the starting point for reuse at any model phase.

3.4.1.2 OPM model of Clause 4 shall statements

The OPM model for this text is given in Figure 10 below that includes the OPL text version for comparison.

TC184/SC5 N1111

15

Business Process-oriented Enterprise Modelling consists of Representation Of Aggregation.

Business Process-oriented Enterprise Modelling results in representation of Enterprise Entities.

Business Processes exhibits Dynamics (control flow / process behaviour), Functionalities (activities, inputs/outputs,

control, resources), and Organizational Aspects.

Enterprise Entities shall be represented at many All Model Phaseses.

Enterprise Entities shall be described at Appropriate Level Of Detail.

Enterprise Entities shall be Business Processes.

Enterprise Entities are affected by Business Processes.

Enterprise Entities is supported by Representation Of Aggregation.

All Model Phases consists of Domain Identification Phase, Concept Definition Phase, Requirements Definition Phase,

Design Specification Phase, Implementation Description Phase, Domain Operation Phase,

and Decommission Phase.

Requirements Definition Phase exhibits Requirements Definition Model.

Requirements Definition Model shall be Capable Of Being Processed.

Design Specification Phase exhibits Design Specification Model.

Design Specification Model shall be Capable Of Being Processed.

Design Specification Phase consists of DS Constructs.

DS Constructs shall be derived from those of Requirements Definition Phase.

Implementation Description Phase exhibits Implementation Model.

Implementation Model shall be Capable Of Being Processed.

Implementation Description Phase consists of ID Constructs.

ID Constructs shall reflect Hardware/Software Platform or Technology.

Model Views consists of Function View, Information View, Resource View, and Organization View.

Model Views shall provide foundation for User-oriented Modelling.

Model Views shall allow identification of Relevant Object Hierarchy.

Model Views shall allow identification of Relevant Object Relationship.

Enterprise Modelling shall be supported at All Model Phases.

Relevant Object Hierarchy consists of Different Classes & Sub-classes.

Relevant Object Relationship consists of Different Classes & Sub-classes.

Modelling Language Constructs shall provide support for Enterprise Modelling.

Hardware/Software Platform or Technology chosen to be consistent with DS Constructs.

Clause 4 - Common Characteristics of modelling language constructs exhibits This Standard.

This Standard is concerned with Business Process-oriented Enterprise Modelling.

This Standard is concerned with User-oriented Modelling.

Enterprise Activity is a Modelling Language Constructs.

Enterprise Activity is supported by Representation Of Aggregation.

TC184/SC5 N1111

16

Business Process is a Modelling Language Constructs.

Business Process is supported by Representation Of Aggregation.

Figure 10 — ISO 19440 Clause 4 shall statements as OPM model with OPD and OPL

3.4.1.3 Partitioning the Clause 4 shalls model

An examination of the OPD in Figure 10 reveals that the model has 4 major partitions (or modules) connected by single links as shown in Figure 11 below.

Figure 11 — ISO 19440 Clause 4 shall statements as partitioned OPM model

The two objects in the upper left are the Clause 4 title and link with This Standard being its participant. The upper right blue grouped objects are linked using ―This Standard is concerned with User-oriented Modelling―while the central green grouped objects are linked using ‖This Standard is concerned with Business Process-oriented Enterprise

Modelling.‖ This latter group is linked to the red grouped objects using ―All Model Phases consists of Domain

Identification Phase, Concept Definition Phase, Requirements Definition Phase, Design Specification Phase, Implementation

Description Phase, Domain Operation Phase, and Decommission Phase.” These links would appear to make good demarcations for separate paragraphs in the clause. However, in the standard text given above this partitioning was not used. Instead, the red group has an extended paragraph, paragraph 4, with bullets for each modeling phase. The blue and green groups appear as multiple sentences in the same paragraph 3.

Another iteration of this model unfolded the Clause into its four paragraphs with the blue and green groups placed in the OPD for the 3rd paragraph and the red grouping placed in the OPD of the 4th paragraph.

3.4.1.4 Lesson learned model Clause 4

The email exchange below identifies some of the highlighted ―lessons learned‖ in this portion of the 19440 examination.

Subject: A literal clause 4

I have posted a rather literal model for Clause 4 (3rd and 4th para) portions of 'Shalls' in 19440.

Attached is the OPL. Do you see any benefit is this kind of literal transformation of the text into an OPM model?

Subject: Re: A literal clause 4

TC184/SC5 N1111

17

My first reaction to your clause 4 email was that the generated OPL on its own would not have helped anyone to understand what 19440 was all about if he or she were not already familiar with the concepts. This was without looking at the OPDs which I have only just opened. The rationale, semantic overtones and flow of the argument in those paragraphs 3 and 4 of clause 4 was not being captured. That's to be expected of course - OPDs and the automatically generated OPL (even with semantically decorated relations) are a long way from natural language.

Then I looked at the OPD Views and things started to become much clearer and that says something about the usefulness of visual modelling. Some work's going to be required to align things (later) between clauses 4, 5 and 6.

For me, it's the act of modelling that should help us to analyze and structure the standard's actual or evolving text more logically and consistently. Using OPM (resulting in OPDs and a generated system OPL) is a route to doing that.

If that's right, we probably need to rework the MBSAM to make the use of OPM a sort of mid-way station or parallel activity between the gathering and consolidation of initial text and the formal drafting of the text in the standard.

(I also have a personal hang-up - "exhibits" is not a natural label for me - I just translate it mentally all the time into "has the attribute"... A thought - we could usefully compile a short list of such translations for our standards' purposes? Then it's just a set of global changes to fix.)

I'd change the attributes of BP to the singular form (Dynamic, Functionality, Organizational Aspect) and the attribute relation to "BP exhibits many Dynamics, many Functionalities and many Organizational Aspects (OPCAT will insert the plurals correctly). But the difficulty then is that the extra semantic information (control flow / process behavior) is lost. If you leave it in the name you'll get the wrong plural form... But the solution would be to have Control Flow, Process Behaviour, Activity, Input, Output etc. all as attributes of Dynamics, Functionality etc.

Lastly, you asked "Do you see any benefit is this kind of literal transformation of the text into an OPM model?" Not yet sure about that - think it depends on how much the exercise itself can improve the normative text (see my comment above about restructuring or reworking the text). The final resulting OPD models and generated OPL are probably useful only to those who need to revise the standard later.

3.4.2 Clause 5.2 Construct common structure

3.4.2.1 OPM model of Clause 5.2 as single OPD and its partitions

Clause 5 of ISO 19440 specifies a common structure for the sixteen constructs articulated in Clause 6. A central theme of the standard is that constructs can be defined in a generic sense and then be applied to specific situations as necessary. The initial OPM is shown with its OPL in Figure 12 below. The addition of Clause 6.1.3 provides the definitions and notation necessary to assign data type for values of construct attributes.

TC184/SC5 N1111

18

Clause 6.1.3 - Notation exhibits String, Literal, Predefined Data_type, and Construct Designation.

String is of type char.

Literal is of type String.

Predefined Data_type exhibits List, Optional List, and Base_type.

List consists of many Strings.

Optional List consists of optional Strings.

Construct Designation exhibits Construct Identifier, Origin Designator, Destination Designator, Dual Designation,

Optional Designator, Designator, Origin List, and Destination List.

Construct Identifier consists of Identifier and Construct Name.

Identifier shall be Unique within model.

Construct Name is of type String.

Origin Designator consists of Construct Identifier and Origin.

Origin is of type String.

Destination Designator consists of Construct Identifier and Destination.

Destination is of type String.

Dual Designation consists of 2 Construct Identifiers.

Optional Designator consists of optional Construct Identifiers.

Designator consists of Construct Identifier.

Origin List consists of Origin Designator.

Destination List consists of Destination Designator.

Clause 5.2 - Construct common structure specification consists of Construct Template Constituent and Textual Constituent.

Construct Template Constituent consists of Header Part and Body Part.

Header Part consists of Construct Label, Identifier, Construct Name, Design Authority, and Construct Description.

Construct Label is of type Literal.

Design Authority shall meet OU / OR constraint.

Construct Description is of type String.

Body Part consists of A - Descriptives partition and B - Relationships partition.

A - Descriptives partition exhibits A1 - Descriptives All phases and A2 - Descriptives Different phases.

A1 - Descriptives All phases consists of many Predefined Descriptive Attributes

and optional Additional Descriptive Attributes.

Predefined Descriptive Attribute exhibits Attribute Definition.

Attribute Definition exhibits Attribute Qualification and Explanation.

Attribute Qualification is of type String.

Explanation is of type String.

Attribute Definition consists of Attribute Name and Attribute Data_type.

Attribute Name is of type String.

Attribute Data_type is of type Predefined Data_type.

Additional Descriptive Attribute exhibits Attribute Definition.

Additional Descriptive Attribute shall be User-defined.

A2 - Descriptives Different phases consists of A2.1 - Concept phase & latter,

A2.2 - Requirements phase & latter,

A2.3 - Design phase & latter,

A2.4 - Implementation phase & latter,

and A2.5 - Operation phase & latter.

A2.1 - Concept phase & latter consists of many Predefined Descriptive Attributes

TC184/SC5 N1111

19


A2.2 - Requirements phase & latter consists of many Predefined Descriptive Attributes


A2.3 - Design phase & latter consists of many Predefined Descriptive Attributes


A2.4 - Implementation phase & latter consists of many Predefined Descriptive Attributes


A2.5 - Operation phase & latter consists of many Predefined Descriptive Attributes


B - Relationships partition exhibits B1 - Relationships All phases and B2 - Relationships Different phases.

B1 - Relationships All phases consists of many Relationship Attributes.

Relationship Attribute exhibits Explanation.

Relationship Attribute consists of Operational, Specialization_of, Part_of, Consists_of,

and Association.

Operational exhibits Relationship Qualification and OU / OR constraint.

Relationship Qualification is of type String.

OU / OR constraint is of type Dual Designation.

Specialization_of exhibits Relationship Qualification.

Specialization_of consists of Relationship Designation.

Relationship Designation is of type Construct Designation.

Part_of exhibits Relationship Qualification.

Part_of consists of Relationship Designation.

Consists_of exhibits Relationship Qualification.

Consists_of consists of Relationship Designation.

Association consists of Pre-defined Association and User-defined Association.

Pre-defined Association exhibits Relationship Qualification.

Pre-defined Association consists of Attribute Name.

User-defined Association exhibits Relationship Qualification.

User-defined Association consists of Attribute Name.

B2 - Relationships Different phases consists of B2.1 - Concept phase & latter,

B2.2 - Requirements phase & latter,

B2.3 - Design phase & latter,

B2.4 - Implementation phase & latter, and

B2.5 - Operation phase & latter.

B2.1 - Concept phase & latter consists of many Relationship Attributes.

B2.2 - Requirements phase & latter consists of many Relationship Attributes.

B2.3 - Design phase & latter consists of many Relationship Attributes.

B2.4 - Implementation phase & latter consists of many Relationship Attributes.

B2.5 - Operation phase & latter consists of many Relationship Attributes.

Textual Constituent consists of Brief Text Defining Purpose, Textual Description, and Intended Usage.

Brief Text Defining Purpose is of type String.

Textual Description is of type String.

Intended Usage is of type String.

Clause 5.2 - Construct common structure specification utilizes Clause 6.1.3 - Notation.

Clause 5.2 - Construct common structure specification provides many Consistent minimal attributes.

This International Standard specifies Clause 5.2 - Construct common structure specification.

Figure 12 — ISO 19440 Clause 5.2 as OPM model with OPD and OPL

This OPD is another case in which the original text is split into paragraphs that do not align with the single diagram. For example, to properly model the Clause 5 generic construct template, the notation of Clause 6.1.3 is necessary.

One consequence of this arrangement is that the use of the OPD as a template for the constructs of Clause 6 is almost impossible because object attributes must be added to the model explicitly and the figure becomes very crowded and complicated. One approach is to use unfolding of the various template Descriptive and Relationship attribute objects to characterize the template for a specific construct. While preserving the more generic Clause 5.2 template, this approach will result in many objects that have no unfolding and are in fact not used by the particular construct. While the individual attributes of different objects could be compared, it would be more difficult to visually examine the differences between construct body partitions as a set of attributed entities.

Another drawback to this approach is that the intent of the constructs is for them to serve as templates for particular construct instances for an application. The fragmentation resulting from further unfolding of objects

TC184/SC5 N1111

20

would make the application specific collection of constructs very difficult to manage and verify for consistency and completeness.

A different approach to making the model more manageable is to apply the same observation of single links forming suitable points for partitioning. This approach is shown in Figure 13 below. By splitting the SD into several views the reusable components of the template model appear. This narrowing of model snippet focus is an essential aspect of the OPM approach and in this situation better facilitates the understanding of the relationships among the constructs.

Figure 13 — ISO 19440 Clause 5.2 as partitioned OPM model

3.4.2.2 Clause 5.2 as partition snippets

The six partitions become the six Views of the new Clause 5.2 model as shown in Figure 14. The View snippets follow.

Figure 14 — OPCAT tool listing of Construct_template Views

5 SD

1 2

3 4

6

TC184/SC5 N1111

21

Clause 5.2 - Construct common structure specification consists of Construct Template Constituent and Textual Constituent.

Construct Template Constituent consists of Header Part and Body Part.

Body Part consists of A - Descriptives partition and B - Relationships partition.

Clause 5.2 - Construct common structure specification utilizes Clause 6.1.3 - Notation.

Clause 5.2 - Construct common structure specification provides many Consistent minimal attributes.

This International Standard specifies Clause 5.2 - Construct common structure specification.

Figure 15 — Clause 5.2 Construct_template System Diagram

TC184/SC5 N1111

22

Relationship Attribute exhibits Explanation.


Relationship Attribute consists of Operational, Specialization_of, Part_of, Consists_of, and Association.

Operational exhibits Relationship Qualification and OU / OR constraint.

Relationship Qualification is of type String.


Specialization_of exhibits Relationship Qualification.

Specialization_of consists of Relationship Designation.

Relationship Designation is of type Construct Designation.

Part_of exhibits Relationship Qualification.

Part_of consists of Relationship Designation.

Consists_of exhibits Relationship Qualification.

Consists_of consists of Relationship Designation.

Association consists of Pre-defined Association and User-defined Association.

Pre-defined Association exhibits Relationship Qualification.

Pre-defined Association consists of Attribute Name.


User-defined Association exhibits Relationship Qualification.

User-defined Association consists of Attribute Name.

Figure 16 — Clause 5.2 Construct_template View 2 : Relationship Attribute unfolded

TC184/SC5 N1111

23


Header Part consists of Construct Label, Identifier, Construct Name, Design Authority, and Construct Description.

Construct Label is of type Literal.

Identifier relates to Unique within model.



Design Authority relates to OU / OR constraint.

Construct Description is of type String.

Figure 17 — Clause 5.2 Construct_template View 2 : Header Part unfolded

TC184/SC5 N1111

24


A1 - Descriptives All phases consists of many Predefined Descriptive Attributes


Predefined Descriptive Attribute exhibits Attribute Definition.

Attribute Definition exhibits Attribute Qualification and Explanation.

Attribute Qualification is of type String.


Attribute Definition consists of Attribute Name and Attribute Data_type.


Attribute Data_type is of type Predefined Data_type.

Additional Descriptive Attribute exhibits Attribute Definition.

Additional Descriptive Attribute shall be User-defined.

A2 - Descriptives Different phases consists of A2.1 - Concept phase & latter, A2.2 - Requirements phase & latter,

A2.3 - Design phase & latter, A2.4 - Implementation phase & latter,

and A2.5 - Operation phase & latter.

A2.1 - Concept phase & latter consists of many Predefined Descriptive Attributes


A2.2 - Requirements phase & latter consists of many Predefined Descriptive Attributes


A2.3 - Design phase & latter consists of many Predefined Descriptive Attributes


A2.4 - Implementation phase & latter consists of many Predefined Descriptive Attributes


A2.5 - Operation phase & latter consists of many Predefined Descriptive Attributes


Figure 18 — Clause 5.2 Construct_template View 3 : A – Descriptives partition unfolded

TC184/SC5 N1111

25


B1 - Relationships All phases consists of many Relationship Attributes.

B2 - Relationships Different phases consists of B2.1 - Concept phase & latter, B2.2 - Requirements phase & latter,

B2.3 - Design phase & latter, B2.4 - Implementation phase & latter,

and B2.5 - Operation phase & latter.

B2.1 - Concept phase & latter consists of many Relationship Attributes.

B2.2 - Requirements phase & latter consists of many Relationship Attributes.

B2.3 - Design phase & latter consists of many Relationship Attributes.

B2.4 - Implementation phase & latter consists of many Relationship Attributes.

B2.5 - Operation phase & latter consists of many Relationship Attributes.

Figure 19 — Clause 5.2 Construct_template View 4 : B – Relationships partition unfolded

TC184/SC5 N1111

26

Clause 6.1.3 - Notation exhibits Predefined Data_type and Construct Designation.

Predefined Data_type exhibits Literal, List, Optional List, and Base_type.

Literal consists of String.

String is of type char.

List consists of many Strings.

Optional List consists of optional Strings.

Construct Designation exhibits Dual Designation, Optional Designator, Designator, Origin List, and Destination List.

Dual Designation consists of 2 Construct Identifiers.

Construct Identifier consists of Identifier and Construct Name.



Optional Designator consists of optional Construct Identifiers.

Designator consists of Construct Identifier.

Origin List consists of Origin Designator.

Origin Designator consists of Construct Identifier and Origin.

Origin is of type String.

Destination List consists of Destination Designator.

Destination Designator consists of Construct Identifier and Destination.

Destination is of type String.

Figure 20 — Clause 5.2 Construct_template View 5 : Clause 6.1.3 – Notation

Textual Constituent consists of Brief Text Defining Purpose, Textual Description, and Intended Usage.

Brief Text Defining Purpose is of type String.


Intended Usage is of type String.

Figure 21 — Clause 5.2 Construct_template View 6 : Textual Constituent unfolded

TC184/SC5 N1111

27

3.4.2.3 Using Clause 5.2 snippets as templates for Clause 6 constructs

Since the purpose of ISO 19440 is the specification of generic modelling constructs, the use of the Clause 5 snippets to create the construct templates of Clause 6 is a good first effort for template reuse. In this situation, the Clause 5.2 snippets are a meta-model for the sixteen Clause 6 constructs.

Three of the Clause 6 construct templates are given below: Business Process (Figure 24 and Figure 25), Enterprise Activity (Figure 26 and Figure 27), and Event (Figure 28 and Figure 29) . For each, only the Descriptives and Relationships partition views are shown. The other views have identical structure and differ only in attribute values.

To capture more of the original template text as values in the OPM model within the OPCAT tool, the object details facility is used for specifying construct attribute and relation associated values and the explanatory text as shown in Figure 22 and Figure 23.

From an inspection of these values it becomes clear that the Clause 6 constructs are themselves meta-models for the constructs that are actually created for a particular enterprise.

TC184/SC5 N1111

28

Figure 22 — Capturing Name attribute values in object detail description and notes

Figure 23 — Capturing Activity Behaviour attribute values in object detail description and notes

TC184/SC5 N1111

29

3.4.2.3.1 Clause 6.3 – Business Process


A1 - Descriptives All phases consists of Objectives.

Objectives is of type List.

A2 - Descriptives Different phases consists of A2.2 - Requirements phase & latter and A2.3 - Design phase & latter.

A2.2 - Requirements phase & latter consists of Constraints, Performance Indicators, Declarative Rules,

and Behaviour Rule Set.

Constraints is of type Optional List.

Performance Indicators is of type Optional List.

Declarative Rules is of type Optional List.

Behaviour Rule Set is of type List.

A2.3 - Design phase & latter consists of Priority.

Figure 24 — Clause 6 Business Process Descriptives partition

TC184/SC5 N1111

30


B1 - Relationships All phases consists of Where_used.

Where_used is of type Optional Designator.

B2 - Relationships Different phases consists of B2.2 - Requirements phase & latter and B2.3 - Design phase & latter.

B2.2 - Requirements phase & latter consists of Part_of, Consists_of, and Input/Outputs.

Part_of is of type Optional Designator.

Consists_of is of type Designator.

Input/Outputs consists of Object View Inputs, Event Inputs, Object View Outputs, and Event Outputs.

Object View Inputs is of type Origin List.

Event Inputs is of type Origin List.

Object View Outputs is of type Destination List.

Event Outputs is of type Destination List.

B2.3 - Design phase & latter consists of Operational.

Operational consists of Operational Responsibility and Operational Authority.

Operational Responsibility is of type Dual Designation.

Operational Authority is of type Dual Designation.

Figure 25 — Clause 6 Business Process Relationships partition

TC184/SC5 N1111

31

3.4.2.3.2 Clause 6.4 – Enterprise Activity

A - Descriptives partition exhibits A2 - Descriptives Different phases.

A2 - Descriptives Different phases consists of A2.2 - Requirements phase & latter and A2.3 - Design phase & latter.

A2.2 - Requirements phase & latter consists of Objectives, Constraints, Performance Indicators,

and Activity Behaviour.

Objectives is of type List.

Constraints is of type Optional List.

Performance Indicators is of type Optional List.

Activity Behaviour is of type Description.

A2.3 - Design phase & latter consists of Consists_of, Duration, and A2.3 Inputs/Outputs.

Consists_of is of type List.

Duration is of type Optional List.

A2.3 Inputs/Outputs consists of Ending Statuses.

Ending Statuses is of type Optional List.

Figure 26 — Clause 6 Enterprise Activity Descriptives partition

TC184/SC5 N1111

32

B - Relationships partition exhibits B2 - Relationships Different phases.

B2 - Relationships Different phases consists of B2.2 - Requirements phase & latter and B2.3 - Design phase & latter.

B2.2 - Requirements phase & latter consists of B2.2 Inputs/Outputs, Where_used, Required Operational Roles,

and Required Capabilities.

B2.2 Inputs/Outputs consists of Function Inputs, Control Inputs, Function Outputs, Input Events,

and Output Events.

Function Inputs is of type Origin List.

Control Inputs is of type Origin List.

Function Outputs is of type Destination List.

Input Events is of type Origin List.

Output Events is of type Destination List.

Where_used is of type List.

Required Operational Roles is of type List.

Required Capabilities is of type List.

B2.3 - Design phase & latter consists of Operational Relationships and B2.3 Inputs/Outputs.

Operational Relationships consists of Operation Responsibility and Operation Authority.

Operation Responsibility is of type Dual Designation.

Operation Authority is of type Dual Designation.

B2.3 Inputs/Outputs consists of Operational Role Outputs, Control Outputs, Resource Inputs,

and Resource Outputs.

Operational Role Outputs is of type Destination List.

Control Outputs is of type Destination List.

Resource Inputs is of type Origin List.

Resource Outputs is of type Destination List.

Figure 27 — Clause 6 Enterprise Activity Relationships partition

TC184/SC5 N1111

33

3.4.2.3.3 Clause 6.5 – Event

A - Descriptives partition exhibits A2 - Descriptives Different phases.

A2 - Descriptives Different phases consists of A2.3 - Design phase & latter.

A2.3 - Design phase & latter consists of Timestamp and Priority.

Timestamp is of type String.

Priority is of type INT10.

Figure 28 — Clause 6 Event Descriptives partition


B1 - Relationships All phases consists of Object Views, Generated_by, and Initiates.

Object Views is of type Optional Designator.

Generated_by is of type Origin List.

Initiates is of type Destination List.

B2 - Relationships Different phases consists of B2.3 - Design phase & latter.

B2.3 - Design phase & latter consists of Operational Relationships.

Operational Relationships consists of Operational Responsibility and Operational Authority.

Operational Responsibility is of type Dual Designation.

Operational Authority is of type Dual Designation.

Figure 29 — Clause 6 Event Relationships partition

TC184/SC5 N1111

34

3.4.3 An OPM model for using 19440

Another approach to utilizing OPM for existing standards is using OPM to model the implementation of the standard by creating expected implementation processes, especially those implied by the structure and explanatory text of the standard. The figure and whole OPL below are the result of an OPM model being used to examine the implementation of ISO 19440. One obvious observation by the author of this model, David Shorter, is that creating all of the model snippets necessary to capture all of the text as well as an implementation process is very time consuming. Therefore only the first construct, Domain, and a means to assign Enterprise Object constructs to that Domain are expressed.

The OPL listing includes OPD snippets that are not shown as figures in this report.

Figure 30 — Enterprise modelling System Diagram using ISO 19440

Figure 31 — Enterprise modelling OPD EN IS 19440 unfolded

TC184/SC5 N1111

35

Figure 32 — Enterprise modelling OPD EN IS 19440 Specification unfolded

Figure 33 — Enterprise modelling process in-zoomed

Figure 34 — Model constructing in-zoomed

TC184/SC5 N1111

36

Figure 35 — Domain identifying in-zoomed

Figure 36 — DM Domain identifying in-zoomed

Figure 37 — EO Domain identifying in-zoomed

TC184/SC5 N1111

37

Enterprise Model can be domain contents & I/O identified, mission & strategy concepts defined, business process reqts identified,

business process parts specified,

or implementation descripn complete for release.

Enterprise Modeller exhibits many Concerns.

Many Concerns determine many Views.

Enterprise Modeller determines Another EO Identified?.

Enterprise Modeller determines DM Identifying EO?.

Enterprise Modeller handles EO Domain Identifying, Domain identifying, Decommissioning, Model Constructing, View Constructing,

and Enterprise Modelling.

Enterprise is environmental.

Stakeholder is environmental.

Stakeholder exhibits many Concerns.

Stakeholder handles View Constructing and Enterprise Modelling.

Many Views express many Concerns.

EN IS 19440 consists of many Constructs and many Complementary Concepts.

Construct consists of Specification.

Specification exhibits Textual Description, Purpose, and Usage.


Purpose is of type String.

Usage is of type String.

Specification consists of Template and Graphic.

Template consists of Header and Body.

Header exhibits Label, Identifier, Name, and Design Authority.

Label is of type Literal.

Identifier is of type String.

Name is of type String.

Design Authority is of type Organizational Unit (OU).

Body exhibits Descriptive and Relationship.

Graphic is environmental.

Specification uses Notation.

Many Constructs used in many Enterprise Model Views.

Complementary Concept exhibits Objective, Constraint, Behavioral Rule, Functional Operation, Integrity Rule,

Performance Indicator, and Declarative Rule.

Objective is of type String.

Constraint is of type String.

Behavioral Rule is of type String.

Integrity Rule is of type String.

Performance Indicator is of type String.

Declarative Rule is of type String.

EN IS 19440 handles EO Domain Identifying, Domain identifying, and Model Constructing.

Notation exhibits String and Literal.

String consists of many String Characters.

String Character is of type char.

Literal is of type String.

EO Identification Desc is of type Descriptive.

EO Identification Reln is of type Relationship.

Enterprise Model View is an Enterprise Model.

Many Enterprise Model Views composed of many Constructs.

AS-IS is physical.

AS-IS is an Enterprise.

TO-BE is an Enterprise.

Function-related Construct is a Construct.

Function-related Construct exhibits Specification.

Resource-related Construct is a Construct.

Resource-related Construct exhibits Specification.

Information-related Construct is a Construct.

Information-related Construct exhibits Specification.

Organization-related Construct is a Construct.

Organization-related Construct exhibits Specification.

Domain (DM) is a Function-related Construct.

Domain (DM) exhibits DM Manifest.

DM Manifest is a Template.

DM Manifest can be DM identified, DM conceptualized, DM reqts defined, or DM specified.

DM Manifest exhibits DM, DM Identification Desc, DM Identification Reln, DM Concept Desc, DM Requirement Desc,

DM Requirement Reln, and DM Specification Reln.

DM is of type Label.

DM Identification Desc consists of DM description, many BP descriptions, many Objectives, and many Constraints.

TC184/SC5 N1111

38

DM description is of type String.

BP description is of type String.

DM Identification Reln consists of many OV inputs, many OV outputs, many EV inputs, and many EV outputs.

OV input is of type Object View (OV).

OV output is of type Object View (OV).

EV input is of type Event (EV).

EV output is of type Event (EV).

DM Concept Desc is of type Descriptive.

DM Requirement Desc is of type Descriptive.

DM Requirement Reln is of type Relationship.

DM Specification Reln is of type Relationship.

Domain (DM) consists of Business Process (BP).

Business Process (BP) is a Function-related Construct.

Domain (DM) outputs many Event (EV)s.

Domain (DM) outputs many Object View (OV)s.

Enterprise Activity (EA) is a Function-related Construct.

Event (EV) is a Function-related Construct.

Many Event (EV)s inputs Domain (DM).

Enterprise Object (EO) is an Information-related Construct.

Object View (OV) is an Information-related Construct.

Many Object View (OV)s inputs Domain (DM).

Product (PR) is an Information-related Construct.

Order (OR) is an Information-related Construct.

Resource (RE) is a Resource-related Construct.

Capability (CA) is a Resource-related Construct.

Functional Entity (FE) is a Resource-related Construct.

Organizational Unit (OU) is an Organization-related Construct.

Decision Centre (DC) is an Organization-related Construct.

Person Profile (PPR) is an Organization-related Construct.

Organizational Role (ORR) is an Organization-related Construct.

Operational Role (OPR) is an Organization-related Construct.

Enterprise Modelling exhibits Released Enterprise Model.

Enterprise Modelling consists of Model Constructing, Operating, Decommisioning, and View Constructing.

Enterprise Modelling requires EN IS 19440 and View.

Enterprise Modelling affects Enterprise.

Enterprise Modelling yields Enterprise Model View and Enterprise Model.

Enterprise Modelling zooms into Model Constructing, View Constructing, Operating, and Decommissioning,

as well as Released Enterprise Model.

Released Enterprise Model is an Enterprise Model.

Model Constructing consists of Domain identifying, Concepts Defining, Requirements Defining, Design Specifying,

and Implementation Describing.

Model Constructing consumes Enterprise.

Model Constructing yields Released Enterprise Model and Enterprise Model.

Model Constructing zooms into Implementation Describing, Domain identifying, Design Specifying,

Requirements Defining, and Concepts Defining.

Implementation Describing changes Enterprise Model from business process parts specified

to implementation descripn complete for release.

Implementation Describing yields Released Enterprise Model.

Domain identifying exhibits DM Identifying EO?.

Domain identifying consists of DM Domain Identifying, BP Domain Identifying, EV Domain Identifying,

EO Domain Identifying, OV Domain Identifying, PR Domain Identifying,

OR Domain Identifying, RE Domain Identifying, and OU Domain Identifying.

Domain identifying consumes Enterprise.

Domain identifying yields Enterprise Model and domain contents & I/O identified Enterprise Model.

Domain identifying zooms into DM Domain Identifying, EV Domain Identifying, EO Domain Identifying,

OR Domain Identifying, BP Domain Identifying, PR Domain Identifying,

OV Domain Identifying, OU Domain Identifying, and RE Domain Identifying,

as well as DM Identifying EO?.

DM Identifying EO? can be Yes or No.

No is initial.

DM Domain Identifying consists of DM Domain Describing and DM Domain Relating.

DM Domain Identifying yields DM Identification Reln.

DM Domain Identifying zooms into DM Domain Describing and DM Domain Relating.

DM Domain Describing yields DM Identification Desc.

DM Domain Relating requires DM Identification Desc.

DM Domain Relating yields EV output, EV input, OV output, and OV input.

EO Domain Identifying exhibits Another EO Identified?.

TC184/SC5 N1111

39

EO Domain Identifying consists of EO Domain ID Describing, EO Domain Relating,

and Another EO Identifying.

EO Domain Identifying requires DM Identification Reln and Yes DM Identifying EO?.

EO Domain Identifying consumes Enterprise.

EO Domain Identifying zooms into EO Domain ID Describing, EO Domain Relating,

and Another EO Identifying, as well as Another EO Identified?.

Another EO Identified? can be Yes or No.

No is initial.

Another EO Identified? triggers Another EO Identifying when it enters Yes.

EO Domain ID Describing yields EO Identification Desc.

EO Domain Relating requires EO Identification Desc.

EO Domain Relating yields EO Identification Reln.

Another EO Identifying requires Yes Another EO Identified?.

Another EO Identifying invokes EO Domain Identifying.

Design Specifying changes Enterprise Model from business process reqts identified to business process parts specified.

Requirements Defining changes Enterprise Model from mission & strategy concepts defined

to business process reqts identified.

Concepts Defining changes Enterprise Model from domain contents & I/O identified

to mission & strategy concepts defined.

View Constructing requires View.

View Constructing consumes Enterprise Model.

View Constructing yields Enterprise Model View.

Operating consumes Released Enterprise Model.

Decommissioning and Operating equivalent.

Figure 38 — Enterprise modelling OPM model whole OPL

TC184/SC5 N1111

40

3.5 Exploring ISO/IEC 15416 using an OPM model

ISO/IEC 15416:2000(E) exhibits ISO/IEC 15416:2000(E) Technical Content.

ISO/IEC 15416:2000(E) consists of Foreword, Introduction, Clause 1 Scope, Clause 2 Normative References,

Clause 3 Terms and Definitions, Clause 4 Symbols and Abbreviated Terms,

Clause 5 Measurement Methodology, Clause 6 Symbol Grading,

Clause 7 Substrate Characteristics, Bibliography, 8 Informative Annexes,

and 2 Normative Annexes.

EN 1635 Technical Content and ISO/IEC 15416:2000(E) Technical Content are equivalent.

ANSI/UCC5 Technical Content and ISO/IEC 15416:2000(E) Technical Content are equivalent.

ANSI X3.182 Technical Content and ISO/IEC 15416:2000(E) Technical Content are equivalent.

Figure 39 — ISO/IEC 15416 OPM SD model with OPL

Bar Code Print Quality Standard Test Specifying consists of Bar Code Symbol Attribute Measuring and Bar Code Symbol Grading.

Bar Code Print Quality Standard Test Specifying zooms into Bar Code Symbol Attribute Measuring and Bar Code Symbol Grading.

Bar Code Symbol Attribute Measuring consists of Bar Reflectivity Measuring, Space Reflectivity Measuring, Bar Width

Measuring, Space Width Measuring, and Scan Reflectance Profile Analysing.

Bar Code Symbol Grading consists of Scan Reflectance Profile Grading.

Figure 40 — Bar Code Print Quality Standard Text Specifying unfolded OPD with OPL

TC184/SC5 N1111

41

Bar Code Equipment Manufacturer requires Publicly Available Standard Test Specification.

Bar Code Producer requires Publicly Available Standard Test Specification.

Bar Code User requires Publicly Available Standard Test Specification.

ISO/IEC 15416:2000(E) consists of Bar Code Symbol Attribute Measurement Methodology and Bar Code Symbol Attribute Overall

Assesment Deriving Method.

ISO/IEC 15416:2000(E) improves Application Standard Development.

ISO/IEC 15416:2000(E) improves Bar Code Equipment Development.

ISO/IEC 15416:2000(E) improves Bar Code Measuring Equipment Development.

ISO/IEC 15416:2000(E) specifies Bar Code Symbol Attribute Measurement Methodology.

ISO/IEC 15416:2000(E) defines Bar Code Symbol Attribute Overall Assesment Deriving Method.

ISO/IEC 15416:2000(E) provides List of Possible Cause for Deviation from Optimum Bar Code Symbol Attribute Values Set.

Bar Code Print Quality Standard Test Specifying consumes Publicly Available Standard Test Specification.

Bar Code Print Quality Standard Test Specifying yields ISO/IEC 15416:2000(E).

Figure 41 — ISO/IEC 15416 unfolded OPD with OPL

Publicly Available Standard Test Specification can be required or available.

Bar Code Print Quality Standard Test Specifying consists of Bar Code Symbol Attribute Measuring and Bar Code Symbol Grading.

Bar Code Print Quality Standard Test Specifying changes Publicly Available Standard Test Specification from required to available.

Bar Code Print Quality Standard Test Specifying yields ISO/IEC 15416:2000(E).

Bar Code Print Quality Standard Test Specifying zooms into Bar Code Symbol Attribute Measuring and Bar Code Symbol Grading.

Bar Code Symbol Attribute Measuring invokes Bar Code Symbol Grading.

Figure 42 — Bar Code Print Quality Standard Test Specification in-zoom with OPL

TC184/SC5 N1111

42

Bar Code Symbol Grading yields ISO/IEC 15416:2000(E).

Bar Code Symbol Attribute Measuring consists of Bar Reflectivity Measuring, Space Reflectivity Measuring, Bar Width Measuring,

Space Width Measuring, and Scan Reflectance Profile Analysing.

Bar Code Symbol Attribute Measuring yields ISO/IEC 15416:2000(E).


Bar Code Symbol Attribute Measuring zooms into Bar Reflectivity Measuring, Space Reflectivity Measuring, Space Width

Measuring, Bar Width Measuring, and Scan Reflectance Profile Analysing.

Figure 43 — Bar Code Symbol Attribute Measuring in-zoom with OPL

Bar Code Symbol Attribute Measuring yields ISO/IEC 15416:2000(E).


Bar Code Symbol Grading consists of Scan Reflectance Profile Grading.

Bar Code Symbol Grading yields ISO/IEC 15416:2000(E).

Bar Code Symbol Grading zooms into Scan Reflectance Profile Grading.

Figure 44 — Bar Code Symbol Grading in-zoom with OPL

TC184/SC5 N1111

43

Informative Annex consists of Annex C, Annex D, Annex E, Annex F, Annex G, Annex H, Annex I, and Annex J.

Annex C illustrates Symbol Grading Flowchart.

Annex D asseses Accepatability of Substartes and/or Ink Colours.

Annex E provides Interpretation of theScan Reflectance Profile and Profile Grades.

Annex F provides Information about the Light Wavelenght Selection.

Annex G defines Number of Scans per Symbol.

Annex H provides Example of Verification Report.

Annex I compares ISO/IEC 15416 Methodology and Traditional Methodologies.

Annex J describes Application of Scan Reflectance Profile Analysis Methodology.

Figure 45 — Informative Annex unfolded with OPL

Normative Annex consists of Annex A and Annex B.

Annex A specifies Symbology for Bar Code Decodability.

Annex B illustrates Example of Symbol Quality Grading.

Figure 46 — Normative Annex unfolded with OPL

TC184/SC5 N1111

44

Clause 2 Normative References consists of ISO 7724-2:1984, Paints and Varnishes - Colorimetry - Part 2: Colour Measurement

and EN 1556:1998, Bar Coding - Terminology.

Figure 47 — Clause 2 Normative References unfolded with OPL

Linear Bar Code is a Bar Code.

Linear Bar Code exhibits many Symbols.

Bar is a Symbol.

Bar exhibits Attributes Set.

Attributes Set consists of Reflectivity and Widht.

Reflectivity exhibits Value.

Value can be optimal or non optimal.

Widht exhibits Value.

Space is a Symbol.

Space exhibits Attributes Set.

Figure 48 — Bar Code unfolded with OPL

TC184/SC5 N1111

45

3.6 Using OPM for a quick ‘Big Picture’ model

Component & Equipment Supplier is environmental and physical.

Component & Equipment Supplier handles Component & Equipment Supplying.

Design Partner is environmental and physical.

Design Partner handles Design Partner Provisioning.

Automation Provider is environmental and physical.

Automation Provider handles Automation Providing.

Market Channel Partner is environmental and physical.

Market Channel Partner handles Market Channel Partnering.

Consumer is environmental and physical.

Consumer handles Goods & Services Consuming.

Utilities, Equipment & Materials Supplier is environmental and physical.

Utilities, Equipment & Materials Supplier handles Utilities, Equipment & Materials Supplying.

Automation User is environmental and physical.

Automation User handles Automation Using.

ISO 11354: Framework for enterprise interoperability is environmental.

Manufacturer is environmental and physical.

Manufacturer is an Automation User.

Producer is environmental and physical.

Producer is an Automation User.

SC5 Interoperability Standards Applying exhibits Design Partner Services, Components & Services, Materials,

energy & equipment, Raw material & energy, Products,

Solutions & Services, Products & Services Information,

Products, Solutions & Services, Goods & Services,

and Raw materials, energy & equipment.

SC5 Interoperability Standards Applying consists of Goods & Services Consuming, Automation Using,

Market Channel Partnering, Automation Providing,

Utilities, Equipment & Materials Supplying,

Design Partner Provisioning,

and Component & Equipment Supplying.

SC5 Interoperability Standards Applying requires ISO 11354: Framework for enterprise interoperability.

SC5 Interoperability Standards Applying zooms into Utilities, Equipment & Materials Supplying, Design Partner Provisioning,

Component & Equipment Supplying, Automation Providing,

Market Channel Partnering, Automation Using,

and Goods & Services Consuming,

as well as Raw materials, energy & equipment,

Goods & Services, Products, Solutions & Services,

Products & Services Information, Products,

Solutions & Services, Raw material & energy,

Materials, energy & equipment, Components & Services,

TC184/SC5 N1111

46

and Design Partner Services.

Raw materials, energy & equipment is physical.

Goods & Services is physical.

Products, Solutions & Services is physical.

Raw material & energy is physical.

Components & Services is physical.

Utilities, Equipment & Materials Supplying yields Raw materials, energy & equipment, Materials, energy & equipment,

and Raw material & energy.

Design Partner Provisioning yields Design Partner Services.

Component & Equipment Supplying requires Raw material & energy.

Component & Equipment Supplying yields Components & Services.

Automation Providing requires Materials, energy & equipment, Components & Services, and Design Partner Services.

Automation Providing yields Products, Solutions & Services and Products & Services Information.

Market Channel Partnering requires Products & Services Information.

Market Channel Partnering yields Products, Solutions & Services.

Automation Using requires Products, Solutions & Services, Raw materials, energy & equipment,

and Products, Solutions & Services.

Automation Using yields Goods & Services.

Goods & Services Consuming requires Goods & Services.

Figure 49 — Big Picture OPM model OPD and OPL

The model depicted above is derived from a graphic created by Em delaHostria as part of the effort to express a ‗big picture‘ of TC184 and SC5 domains. The advantage of such a model is the opportunity to elaborate the model as necessary while maintaining the rigor of the objects, processes, and rules for their linking.

3.7 Using OPM in IEEE P2030

IEEE P2030 consolidates much of the world-wide effort to enable a Smart Grid for the distribution and consumption of electrical power. The title of the document is Guide for Smart Grid Interoperability of Energy Technology and Information Technology Operation With the Electrical Power System (EPS), and End-Use Applications and Loads. In the draft dated 02-23-2011, Section 8.2 Logical description of information technology systems includes two OPM diagrams – Figure 8-2 Information exchange between two application elements and Figure 8-3 SGIRM application element model using ISO 15745. Annex E (informative) Smart Grid interoperability in Object Process Methodology (OPM) notation includes Figure E-2 depicting an OPM system diagram for the Application interoperability framework central to Smart Grid operation. Each of these figures is a single OPD intended to express at a high level of abstraction the content of several sections of explanatory text.

3.8 Using OPM for Model-based standards

3.8.1 Introduction to modelling of standards (retained from 1st

Interim Report)

Technical documents are usually accompanied with graphics, which can be illustrations or cartoons, pictures, and diagrams. The diagrams are drawn using a variety of symbols and arrow types or using an ad-hoc set of symbols assembled for that particular diagram, possibly with legend. Sometimes the diagram may be a UML class (or SysML block) diagram or other standardized notation. Unfortunately the diagrams do not always correspond to the text or are intended to summarize several sections of text as an abstract.

International Standards are intended to reach a global audience but are usually available only in English natural language. This results in translations, either formally by NSB organizations or informally by implementers of the standard. Because the semantics of natural language text is necessarily contextual and local, assuring consistency and completeness in treatment of the subject matter of a standard can be very difficult, especially when several authors are involved.

One way to improve the usefulness of technical documents is to apply a modelling formalism to the early stages of standard formulating rather than as a post-processing implementation step as presented in the previous examples. This approach has the major advantage of basing the resulting specification on more solid foundations than free text, which is notoriously susceptible to ambiguities, discrepancies, and incompleteness.

TC184/SC5 N1111

47

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, it is essential to integrate a human readable text that is consistent with the formally expressed model. This way we achieve the best of both worlds: rigor and formality on the modelling side, along with readability and access to stakeholders on the text side.

Object-Process Methodology (OPM) [1] offers a holistic approach, backed by a formal yet intuitive graphic and textual language, for modelling enterprise-related standards. These model-based standards are intended for use by stakeholders such as enterprise architects and executives, system integrators, service providers, device suppliers, and designers and developers of applications. These professionals are concerned with creating and operating enterprises while holistically integrating enterprises. Integration within and across enterprises encompasses systems for -manufacturing, supply chain, 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.

3.8.2 Model-Based ISO Standard Authoring using OPM

Considerable effort has gone into using OPM to model aspects of IEC 62264 and ISO 19440 to demonstrate the utility of OPM and OPL to aide in the development of consistent, accessible, and traceable International Standards. This portion of the Interim Report examines issues related to the use of OPM to model a new standard where the modelling effort is placed up-front before any text is written.

For this exercise, the concept of a model about modelling standards was chosen. This subject matter serves to enlighten OPM modellers about the ISO standards adoption process and to show ISO experts the ways in which the model-based approach can guide standard development to be more consistent and complete. This exercise also utilizes the single threaded OPM simulation capability to verify that the process presented in the OPM model does execute correctly from beginning with a concept for a standard through its publication.

The Model-Based ISO Standards Authoring model grew out of earlier work by David Howes that was augmented and enhanced by Richard Martin with assistance from Dov Dori, Chen Linchevski, and David Shorter. The portion of the model dealing with the early model-based formulation of a proposed standard‘s model is the basis for the work of D. Dori and A. Blekhman in preparing the working draft for the Model-based Standards Authoring proposal contained in TC184/SC5 N1112.

The model presented here includes two essential sub-processes of ISO. The first is that occurring with a SC and WG to draft and revise a document. The second is that occurring with a SC and ISO CS to ballot the documents resulting from the first sub-process. The output documents of the first sub-process are the input documents for the second and the ballot results and comments of the second sub-process are inputs for the first. Thus the model depicts the interoperation of these two sub-processes as the document moves through its various stages of development in both sub-processes. The model has three distinct decision points that determine progress through the stages.

While there are certainly more paths actually taken in the development process of most standards, this model envisions routine progress for the standard. The intent is not to express every possible nuance of authoring and agreeing for publishing a standard. The intent is to demonstrate in the context of the OPM approach what a model-based standard looks like, the kind of detail it can express, the extent of text it generates as OPL, and the effect that the model-based standard approach might have on the work of ISO experts.

Inherent in this effort is the skill, and lack thereof, for the primary author of the model in using the OPM approach and specifically the OPCAT tool for recording the work. As with all methodologies, the learning effort is not a straight line escalating rapidly. It is a curve that starts to rise slowly, accelerates with many bumpy portions, and then begins to level off as time and importance wane.

The presentation of the model begins with the OPD hierarchy, Figure 40, as displayed by the OPCAT tool. There are 31 figures or model snippets. While there may be some opportunity to reuse some of the model snippets, only the view snippets associated with information objects are reused. Many of the processes reiterate as the proposal document moves through the overall IOS development process. The default values for decisions are set to progress the document.

TC184/SC5 N1111

48

3.8.3 Model-Based ISO Standard Authoring OPD Hierarchy

Figure 50 — Model-Based ISO Standard Authoring OPD Hierarchy

TC184/SC5 N1111

49

3.8.4 Model-Based ISO Standard Authoring OPD with OPL

Committee Secretariat is environmental.

Committee Secretariat handles Model-based ISO Standards Development Processing.

Related Subject Material is environmental.

Nominated Expert is environmental.

Nominated Expert handles Model-based ISO Standards Development Processing.

Project Leader coordinates many Nominated Experts.

Project Leader handles Model-based ISO Standards Development Processing.

Contributing Expert handles Model-based ISO Standards Development Processing.

ISO Secratariat is environmental.

ISO Secratariat handles Model-based ISO Standards Development Processing.

Working Group Active? can be Yes or No.

Yes is final.

No is initial.

Model-based ISO Standards Development Processing requires Yes Working Group Active?, Authoring Support Set,

and Related Subject Material.

Model-based ISO Standards Development Processing yields Published International Standard.

Figure 51 — Model-Based ISO Standard Authoring OPM model System Diagram with OPL

TC184/SC5 N1111

50


Committee Secretariat handles Model-based ISO Standards Development Processing.

Authoring Support Set consists of Drafting Template and Standardization Rules & Procedures.


Related Subject Material consists of Related Standard Set, Strategic Standardization Plan, and Domain BOK.

Related Standard Set is environmental.

Strategic Standardization Plan is environmental.

Domain BOK is environmental.

Nominated Expert is environmental.

Project Leader solicits Contributing Expert.

Project Leader coordinates many Nominated Experts.

Project Leader handles Model-based ISO Standards Development Processing.

Contributing Expert handles Model-based Standard Authoring.


ISO Secratariat handles Model-based ISO Standards Development Processing.

ISO Stage is proceed.

Standard Exists? can be Yes or No.

No is initial.

Working Group Active? can be Yes or No.

Yes is final.

No is initial.

Authoring Expert is a Nominated Expert.

Authoring Expert handles Model-based Standard Authoring.

Balloting Expert is environmental.

Balloting Expert is a Nominated Expert.

Balloting Expert handles ISO Balloting.

Model-based ISO Standards Development Processing exhibits Proposed Standard and New Standard Document.

Model-based ISO Standards Development Processing consists of Model-based Standard Authoring and ISO Balloting.

Model-based ISO Standards Development Processing requires Standard Exists? and Yes Working Group Active?.

Model-based ISO Standards Development Processing zooms into Model-based Standard Authoring and ISO Balloting,

as well as New Standard Document and Proposed Standard.

Model-based Standard Authoring requires Authoring Support Set and Related Subject Material.

Model-based Standard Authoring yields Proposed Standard.

Following path may produce, Model-based Standard Authoring yields New Standard Document.

ISO Balloting requires Proposed Standard.

ISO Balloting yields ISO Stage and Published International Standard.

ISO Balloting invokes Model-based ISO Standards Development Processing.

Figure 52 — Model-Based ISO Standards Development Processing in-zoomed OPD with OPL

TC184/SC5 N1111

51


Committee Secretariat handles Model-based Standard Authoring.


Project Leader handles Model-based Standard Authoring.

Contributing Expert handles Model-based Standard Authoring.

Authoring Expert handles Model-based Standard Authoring.



No is initial.

Model-based Standard Authoring consists of Input Document Preparing, Proposed Standard Revising,

and Proposed Standard Managing.

Model-based Standard Authoring requires Authoring Support Set and Related Subject Material.

Model-based Standard Authoring zooms into Input Document Preparing, Proposed Standard Revising,

and Proposed Standard Managing.

Input Document Preparing occurs if Standard Exists? is No.

Input Document Preparing yields New Standard Document and New Work Item Proposal.

Proposed Standard Revising occurs if Standard Exists? is Yes and ISO Ballot Result Comments is in existent.

Proposed Standard Revising requires proceed ISO Stage.

Proposed Standard Revising affects Balloted Circulation Document.

Proposed Standard Revising yields ISO WG Resolved Comments and Proposed Standard Draft.

Following path initial initial, Proposed Standard Managing occurs if New Standard Document is in existent.

Following path revised revised, Proposed Standard Managing occurs if Proposed Standard Draft is in existent.

Proposed Standard Managing yields Proposed Standard and Working Group Output.

Figure 53 — Model-Based ISO Standard Authoring in-zoomed OPD with OPL

TC184/SC5 N1111

52


Project Leader handles Input Document Preparing.

Contributing Expert handles Input Document Preparing.

Authoring Expert handles Input Document Preparing.


No is initial.

Input Document Preparing exhibits Draft NWIP.

Input Document Preparing consists of Initial Content Identifying, Standard Forming, and First Draft Preparing.

Input Document Preparing occurs if Standard Exists? is No.

Input Document Preparing requires Authoring Support Set.

Input Document Preparing zooms into Initial Content Identifying, Standard Forming, and First Draft Preparing, as well as Draft NWIP.

Initial Content Identifying requires Related Subject Material.

Initial Content Identifying yields Draft NWIP and Standard Foundation Model.

Standard Forming requires Standard Foundation Model.

Standard Forming yields Initial MBS Model and Initial MBS Content.

First Draft Preparing requires Draft NWIP and Initial MBS Content.

First Draft Preparing yields New Standard Document and New Work Item Proposal.

Figure 54 — Input Document Preparing in-zoomed OPD with OPL

TC184/SC5 N1111

53


Project Leader handles Initial Content Identifying.


Contributing Expert handles Initial Content Identifying.

Authoring Expert handles Initial Content Identifying.

Initial Content Identifying consists of Standard Foundation Laying and Standard Foundation Modeling.

Initial Content Identifying zooms into Standard Foundation Laying and Standard Foundation Modeling.

Standard Foundation Laying requires Strategic Standardization Plan and Related Subject Material.

Standard Foundation Laying yields Standardization Project Mission, Draft NWIP, and Standard Foundation.

Standard Foundation Modeling requires Standard Foundation.

Standard Foundation Modeling yields Standard Foundation Model.

Figure 55 — Input Content Identifying in-zoomed OPD with OPL

TC184/SC5 N1111

54


Project Leader handles Standard Foundation Laying.


Contributing Expert handles Standard Foundation Laying.

Authoring Expert handles Standard Foundation Laying.

Standard Foundation Laying consists of Mission Defining, Reference Base Harvesting, and Reference Base Analyzing.

Standard Foundation Laying zooms into Mission Defining, Reference Base Harvesting, and Reference Base Analyzing.

Mission Defining requires Strategic Standardization Plan.

Mission Defining yields Standardization Project Mission.

Reference Base Harvesting requires Related Subject Material and Standardization Project Mission.

Reference Base Harvesting yields Reference Base.

Reference Base Analyzing requires Reference Base.

Reference Base Analyzing yields Draft NWIP and Standard Foundation.

Figure 56 — Standard Foundation Laying in-zoomed OPD with OPL

TC184/SC5 N1111

55

Project Leader handles Standard Foundation Modeling.

Contributing Expert handles Standard Foundation Modeling.

Authoring Expert handles Standard Foundation Modeling.

Standard Foundation Modeling consists of Reference Base Modeling, Initial Model Verifying, and Concept Positioning.

Standard Foundation Modeling zooms into Reference Base Modeling, Initial Model Verifying, and Concept Positioning.

Reference Base Modeling requires Standard Foundation.

Reference Base Modeling yields Candidate Reference Base Model.

Initial Model Verifying requires Candidate Reference Base Model.

Initial Model Verifying yields Reference Base Model.

Concept Positioning requires Reference Base Model.

Concept Positioning yields Standard Foundation Model.

Figure 57 — Standard Foundation Modeling in-zoomed OPD with OPL

TC184/SC5 N1111

56

Project Leader handles Standard Forming.

Contributing Expert handles Standard Forming.

Authoring Expert handles Standard Forming.

Balloted Circulation Document is in-process within WG.

Standard Forming consists of Part Structuring, Content Identifying, and Technical Element Modeling.

Standard Forming zooms into Part Structuring, Content Identifying, and Technical Element Modeling.

Part Structuring requires Standard Foundation Model.

Part Structuring yields Part Manifest.

Content Identifying requires Part Manifest.

Content Identifying yields Technical Element Set.

Technical Element Modeling requires Technical Element Set.

Technical Element Modeling yields in-process within WG Balloted Circulation Document, Initial MBS Content,

and Initial MBS Model.

Figure 58 — Standard Foundation Modeling in-zoomed OPD with OPL

TC184/SC5 N1111

57

Project Leader handles First Draft Preparing.

Contributing Expert handles First Draft Preparing.

Authoring Expert handles First Draft Preparing.

New Standard Document is in-process.

Balloted Circulation Document can be in-process within WG or ready for ISO.

New Work Item Proposal is in-process.

in-process is initial.

First Draft Preparing exhibits First Working Draft.

First Draft Preparing consists of Template Initializing and First Ballot Document Preparing.

First Draft Preparing requires Authoring Support Set.

First Draft Preparing zooms into Template Initializing and First Ballot Document Preparing, as well as First Working Draft.

Template Initializing requires Initial MBS Content.

Template Initializing yields First Working Draft.

First Ballot Document Preparing requires Draft NWIP and First Working Draft.

First Ballot Document Preparing changes Balloted Circulation Document from in-process within WG to ready for ISO.

First Ballot Document Preparing yields in-process New Work Item Proposal and in-process New Standard Document.

Figure 59 — First Draft Preparing in-zoomed OPD with OPL

TC184/SC5 N1111

58


Committee Secretariat handles Proposed Standard Revising.


Project Leader handles Proposed Standard Revising.

Contributing Expert handles Proposed Standard Revising.

Authoring Expert handles Proposed Standard Revising.

Balloted Circulation Document can be rcv'd from ISO, in-process within WG, or ready for ISO.


Proposed Standard Draft is in-process.

Proposed Standard Revising consists of Comment Resolving and Draft Review and Editing.

Proposed Standard Revising requires Related Subject Material and Authoring Support Set.

Proposed Standard Revising zooms into Comment Resolving and Draft Review and Editing.

Comment Resolving occurs if ISO Ballot Result Comments is in existent.

Comment Resolving requires proceed ISO Stage.

Comment Resolving changes Balloted Circulation Document from rcv'd from ISO to in-process within WG.

Comment Resolving yields ISO WG Resolved Comments.

Draft Review and Editing occurs if ISO WG Resolved Comments is in existent.

Draft Review and Editing changes Balloted Circulation Document from in-process within WG to ready for ISO.

Draft Review and Editing yields in-process Proposed Standard Draft.

Figure 60 — Proposed Standard Revising in-zoomed OPD with OPL

TC184/SC5 N1111

59

Project Leader handles Readiness For Ballot Deciding.


Balloted Circulation Document can be in-process within WG or ready for ISO.

Proposed Standard Draft can be in-process or processed.

Proposed Standard Managing exhibits Draft Ready For Ballot?, Guideline Verified Draft, and Guideline Failed Draft.

Proposed Standard Managing consists of ISO Guidelines Checking, Readiness For Ballot Deciding, External Version Identifying,

and Internal Version Identifying.

Proposed Standard Managing requires Authoring Support Set.

Proposed Standard Managing zooms into ISO Guidelines Checking, Readiness For Ballot Deciding, Internal Version Identifying,

and External Version Identifying, as well as Guideline Failed Draft, Guideline Verified Draft,

and Draft Ready For Ballot?.

Draft Ready For Ballot? can be Yes by default or No.

Yes is initial.

Following path initial initial, ISO Guidelines Checking occurs if New Standard Document is in-process.

Following path revised revised, ISO Guidelines Checking occurs if Proposed Standard Draft is in-process.

ISO Guidelines Checking yields either Guideline Failed Draft or Guideline Verified Draft.

Readiness For Ballot Deciding yields Draft Ready For Ballot?.

Internal Version Identifying occurs if Draft Ready For Ballot? is No.

Following path failed failed, Internal Version Identifying occurs if Guideline Failed Draft is in existent.

Following path verified verified, Internal Version Identifying occurs if Guideline Verified Draft is in existent.

Internal Version Identifying changes Proposed Standard Draft from processed to in-process

and Balloted Circulation Document from ready for ISO to in-process within WG.

External Version Identifying occurs if Guideline Verified Draft is in existent and Draft Ready For Ballot? is Yes.

External Version Identifying yields Working Group Output and Proposed Standard.

Figure 61 — Proposed Standard Managing in-zoomed OPD with OPL

TC184/SC5 N1111

60

New Standard Document can be in-process or processed.

Working Group Output can be working draft, committee draft, draft international standard, final draft international standard,

or published international standard.


No is initial.


External Version Identifying consists of Identifier Adding, WD Setting, and Existing Draft Setting.

External Version Identifying zooms into WD Setting, Existing Draft Setting, and Identifier Adding.

WD Setting occurs if New Standard Document is in-process.

WD Setting changes Standard Exists? from No to Yes.

WD Setting yields working draft Working Group Output.

Existing Draft Setting occurs if Proposed Standard Draft is in-process.

Existing Draft Setting requires Yes Standard Exists?.

Existing Draft Setting affects Working Group Output.

Identifier Adding occurs if Guideline Verified Draft is in existent.

Identifier Adding requires Working Group Output.

Identifier Adding yields processed Proposed Standard Draft, processed New Standard Document, and Proposed Standard.

Figure 62 — External Version Identifying in-zoomed OPD with OPL

TC184/SC5 N1111

61




No is initial.


Existing Draft Setting consists of CD Setting, DIS Setting, FDIS Setting, and Publication Setting.

Existing Draft Setting requires Yes Standard Exists?.

Existing Draft Setting zooms into CD Setting, DIS Setting, FDIS Setting, and Publication Setting.

CD Setting occurs if Working Group Output is working draft and Proposed Standard Draft is in-process.

CD Setting yields processed Proposed Standard Draft and committee draft Working Group Output.

DIS Setting occurs if Working Group Output is committee draft and Proposed Standard Draft is in-process.

DIS Setting yields processed Proposed Standard Draft and draft international standard Working Group Output.

FDIS Setting occurs if Working Group Output is draft international standard and Proposed Standard Draft is in-process.

FDIS Setting yields processed Proposed Standard Draft and final draft international standard Working Group Output.

Publication Setting occurs if Working Group Output is final draft international standard

and Proposed Standard Draft is in-process.

Publication Setting yields processed Proposed Standard Draft and published international standard Working Group Output.

Figure 63 — Existing Draft Setting in-zoomed OPD with OPL

TC184/SC5 N1111

62

Project Leader determines Draft Compared?.

Project Leader handles ISO Guidelines Checking.


Proposed Standard Draft is in-process.

ISO Guidelines Checking exhibits Draft Compared?.

ISO Guidelines Checking consists of Failed Guidelines Documenting, Guideline Comparing, and Guidelines Achieved Verifying.

ISO Guidelines Checking zooms into Guideline Comparing, Guidelines Achieved Verifying, and Failed Guidelines Documenting,

as well as Draft Compared?.

Draft Compared? can be satisfactory for phase by default or not satisfactory for phase.

satisfactory for phase is initial.

Following path existing existing, Guideline Comparing occurs if Proposed Standard Draft is in-process.

Following path new new, Guideline Comparing occurs if New Standard Document is in-process.

Guideline Comparing requires Authoring Support Set.

Guideline Comparing yields Draft Compared?.

Guidelines Achieved Verifying occurs if Draft Compared? is satisfactory for phase.

Guidelines Achieved Verifying yields Guideline Verified Draft.

Failed Guidelines Documenting occurs if Draft Compared? is not satisfactory for phase.

Failed Guidelines Documenting yields Guideline Failed Draft.

Figure 64 — ISO Guidelines Checking in-zoomed OPD with OPL

TC184/SC5 N1111

63


Committee Secretariat handles ISO Balloting.

Project Leader handles ISO Balloting.


Balloting Expert handles NSB Balloting.


ISO Secratariat handles ISO Balloting.

Balloted Circulation Document is rcv'd from ISO.

Standard Published? is No by default.

No is initial.

ISO Balloting exhibits Registered Ballot Document.

ISO Balloting consists of Ballot Initiating, NSB Balloting, and Ballot Decision Recording.

ISO Balloting zooms into Ballot Initiating, NSB Balloting, and Ballot Decision Recording, as well as Registered Ballot Document.

Following path doc doc, Ballot Initiating occurs if Proposed Standard is in existent.

Following path nwip nwip, Ballot Initiating occurs if New Work Item Proposal is in existent.

Ballot Initiating requires Working Group Output.

Ballot Initiating yields Registered Ballot Document and ISO Phase.

NSB Balloting requires No Standard Published? and Registered Ballot Document.

NSB Balloting yields NSB Comment Set.

Ballot Decision Recording requires No Standard Published? and NSB Comment Set.

Ballot Decision Recording yields rcv'd from ISO Balloted Circulation Document, ISO Stage, and ISO Ballot Result Comments.

Figure 65 — ISO Ballotting in-zoomed OPD with OPL

TC184/SC5 N1111

64


Committee Secretariat handles Ballot Initiating.

Project Leader handles Ballot Initiating.


ISO Secratariat handles Ballot Initiating.

ISO Stage can be registration or start main action.

Standard Published? can be No by default or Yes.

No is initial.

Yes is final.

Ballot Initiating consists of Ballot Registering, NSB Review Starting, New Work Item Proposal Registering, and Standard Publishing.

Ballot Initiating zooms into New Work Item Proposal Registering, Ballot Registering, NSB Review Starting, and Standard Publishing.

Following path nwip nwip, New Work Item Proposal Registering occurs if New Work Item Proposal is in existent.

New Work Item Proposal Registering yields Standard Published? and Registered Ballot Document.

Following path doc doc, Ballot Registering occurs if Proposed Standard is in existent.

Ballot Registering requires Working Group Output.

Ballot Registering yields registration ISO Stage and Registered Ballot Document.

NSB Review Starting occurs if Standard Published? is No.

NSB Review Starting requires Registered Ballot Document.

NSB Review Starting changes ISO Stage from registration to start main action.

Standard Publishing occurs if Standard Published? is Yes.

Standard Publishing requires Registered Ballot Document.

Standard Publishing yields Published International Standard.

Figure 66 — Ballot Initiating in-zoomed OPD with OPL

TC184/SC5 N1111

65


Committee Secretariat handles Ballot Registering.


ISO Secratariat handles Ballot Registering.



ISO Phase can be proposal, preparatory, committee, inquiry, approval, or publication.

proposal is initial.

publication is final.

Standard Published? can be No by default or Yes.

No is initial.

Yes is final.

Ballot Registering consists of Preparatory Phase Setting, Committee Phase Setting, Inquiry Phase Setting, Approval Phase Setting,

Publication Phase Setting, and Document Registering.

Ballot Registering zooms into Document Registering, Preparatory Phase Setting, Committee Phase Setting, Inquiry Phase Setting,

Approval Phase Setting, and Publication Phase Setting.

Document Registering requires Proposed Standard.

Document Registering yields Registered Ballot Document.

Preparatory Phase Setting occurs if Working Group Output is working draft.

Preparatory Phase Setting changes ISO Phase from proposal to preparatory.

Committee Phase Setting occurs if Working Group Output is committee draft.

Committee Phase Setting changes ISO Phase from preparatory to committee.

Inquiry Phase Setting occurs if Working Group Output is draft international standard.

Inquiry Phase Setting changes ISO Phase from committee to inquiry.

Approval Phase Setting occurs if Working Group Output is final draft international standard.

Approval Phase Setting changes ISO Phase from inquiry to approval.

Publication Phase Setting occurs if Working Group Output is published international standard.

Publication Phase Setting changes Standard Published? from No to Yes and ISO Phase from approval to publication.

Figure 67 — Ballot Registering in-zoomed OPD with OPL

TC184/SC5 N1111

66


Committee Secretariat handles New Work Item Proposal Registering.


ISO Secratariat handles New Work Item Proposal Registering.

ISO Stage is registration.

New Work Item Proposal is in-process.


ISO Phase is proposal.

proposal is initial.


No is initial.

New Work Item Proposal Registering consists of Proposal Phase Setting.

New Work Item Proposal Registering zooms into Proposal Phase Setting.

Proposal Phase Setting occurs if New Work Item Proposal is in-process.

Proposal Phase Setting yields No Standard Published?, Registered Ballot Document, registration ISO Stage,

and proposal ISO Phase.

Figure 68 — New Work Item Proposal Registering in-zoomed OPD with OPL

TC184/SC5 N1111

67


Committee Secretariat handles Ballot Decision Recording.

Project Leader handles Ballot Decision Recording.


ISO Secratariat handles Vote Tallying.

ISO Stage can be repeat current phase or proceed.

New Work Item Proposal can be in-process or approved.


approved is final.


No is initial.

Ballot Decision Recording exhibits Vote Tally?.

Ballot Decision Recording consists of Vote Tallying, Phase Advancing, and Phase Failing.

Ballot Decision Recording requires No Standard Published?.

Ballot Decision Recording zooms into Vote Tallying, Phase Advancing, and Phase Failing, as well as Vote Tally?.

Vote Tally? can be approve with comments by defaultapprove, or disapproval.

approve with comments is initial.

Vote Tallying requires NSB Comment Set.

Vote Tallying affects Balloted Circulation Document.

Vote Tallying yields Vote Tally?.

Following path a a, Phase Advancing occurs if Vote Tally? is approve.

Following path ac ac, Phase Advancing occurs if Vote Tally? is approve with comments.

Phase Advancing yields approved New Work Item Proposal, ISO Ballot Result Comments, and proceed ISO Stage.

Phase Failing occurs if Vote Tally? is disapproval.

Phase Failing yields repeat current phase ISO Stage.

Figure 69 — Ballot Decision Recording in-zoomed OPD with OPL

TC184/SC5 N1111

68


Committee Secretariat handles Ballot Accumulating.


Balloting Expert handles NSB Balloting.

ISO Stage can be start main action or completion of main action.


No is initial.

NSB Balloting consists of Ballot Accumulating.

NSB Balloting requires No Standard Published?.

NSB Balloting zooms into Ballot Accumulating.

Ballot Accumulating requires Registered Ballot Document.

Ballot Accumulating changes ISO Stage from start main action to completion of main actiion.

Ballot Accumulating yields NSB Comment Set.

Figure 70 — NSB Ballotting in-zoomed OPD with OPL

New Standard Document consists of Part Set.

Figure 71 — New Standard Document unfolded OPD with OPL

TC184/SC5 N1111

69

Proposed Standard exhibits Document Title, Document ISO Stage, ISO Project Identifier, and SC document number identifier.

Document ISO Stage can be Proposal, Preparatory, Committee, Enquiry, Approval, or Publication.

Proposed Standard has Part Set.

Figure 72 — Proposed Standard unfolded OPD with OPL

Proposed International Standard consists of Standard Document Parts and Proposed Standard Model-Base Standard Model.

Part Set may include many Proposed International Standards.

Figure 73 — Part Set unfolded OPD with OPL

Standard Document Parts consists of Informative preliminary, Normative Set, and Informative supplementary.


Figure 74 — Standard Document Parts unfolded OPD with OPL

TC184/SC5 N1111

70

Normative technical consists of Symbols and abbreviated terms, Normative annex, Technical requirements, Terms & Definitions, and

Conformance assessment.

Figure 75 — Normative technical unfolded OPD with OPL

Normative general consists of Scope, Normative References, and Title.

Figure 76 — Normative general unfolded OPD with OPL

Informative supplementary consists of Informative Annex, Bibliography, and Indexes.

Figure 77 — Informative supplementary unfolded OPD with OPL

TC184/SC5 N1111

71



Figure 78 — Informative preliminary unfolded OPD with OPL

ISO Ballot Result Comments consists of NSB Comment Set.

Figure 79 — ISO Ballot Result Comments unfolded OPD with OPL

NSB Comment Set consists of NSB Vote and Comments.

Addition is a Comments.

Deletion is a Comments.

Change is a Comments.

Issue is a Comments.

Figure 80 — NSB Comment Set unfolded OPD with OPL

TC184/SC5 N1111

72

4 Activity B – Objectives 1, 3, and 4

4.1 Usefulness concerns

4.1.1 Fitness for Use

4.1.1.1 OPM-skills and domain experts

4.1.1.1.1 Requirements for modelling with OPM

In addition to the technical adequacy of the modelling language to be used (i.e. its technical capability or 'competence' in the Mark Fox sense), OPM needs to be appropriate and usable by those who will be drafting standards. The intended users are identified in the Introduction to Activity B, but as stated in the Activity A report, an OPM expert is required to 'mediate' between the domain expert ("who need not learn any special language nor decipher cryptic code") and the underlying domain model when information required to prepare a satisfactory OPM model is missing or ambiguous.

There are two usage scenarios that would require different OPM-skills. The effort in Activity A is an examination of an International Standard by a professional system engineer with OPM-skills but lacking domain specific knowledge. In this scenario, no domain expert is required unless new content is necessary to complete the OPM modelling tasks. As Activity A shows, an OPM expert can identify difficulties within a document without specific domain knowledge.

The other scenario that would require OPM-skills is the creation of a new document that is based upon OPM and OPL for model generation of normative content. Both domain knowledge and OPM-skills are necessary. OPM use in this scenario is outlined in the Activity A Report beginning at Section 4.3. For this scenario, a team approach probably is necessary with engagement by both OPM and domain experts, at least until OPM-skills would become prevalent among the international experts upon which SC5 relies for domain knowledge.

4.1.1.1.2 OPM use to model in a standard's domain

We observe that many practitioners now use a variety of modelling tools to aide in the preparation of International Standards with such tools requiring various extents of training and experience in use. The situation with OPM could hardly be different. While it remains to be seen if the learning curve for OPM among those involved in writing International Standards is better than for UML, SysML, BPMN, or other modelling approaches, the OPM approach does seem feasible.

How best can current standards and domain experts be persuaded to engage with OPM? There are already several models that have been developed relating to SC5 standards – can these be reused as a stepping stone to OPM-based models? Can an OPL (Object-Process Language) or Tesperanto specification (maybe partial) be derived automatically or semi-automatically from (some parts of) a UML model?

OPM features a compact set of foundational concepts that appear sufficient for modelling complex and complicated systems of all kinds. OPM user experience indicates that due to OPM‘s intuitive nature, people can start using the tool (OPCAT) after a short introduction to principles of OPM modelling and the basic elements (objects, processes, and structural and procedural links). As with other methodologies, while experience is then gained and increases with ―on the job training‖, a short formal training course is helpful in reaping full potential.

Based on our experience in the past year, domain experts are needed as part of the team in evaluating or creating new standards with the aide of OPM technology. For existing standards, most of the work can be done based on the text. However, when there are too many mismatches, a domain expert needs to resolve detected discrepancies.

TC184/SC5 N1111

73

4.1.1.2 OPM for meta-modelling and harmonization

4.1.1.2.1 Requirements for meta-modelling and harmonization

Another use for OPM would be the ISO TC184 SC5 WG1's current work on revisions and improvement of 19439 and 19440, and indeed the joint work on the 15704 revision and 42010 harmonizations. For these standards we are concerned to model the abstractions themselves, not with modelling an abstract enterprise. (In the past we have used concepts maps initially before moving to more 'formal' methods.) The OPM approach may be suitable for some standards in the SC5 suite and not be as suitable for others. Standards like the 16100 series that use a formal XML expression of profile templates may not benefit as much as those solely expressed in text and simple graphic figures.

4.1.1.2.2 Meta-modelling and harmonization with OPM

OPM is a reflective meta-modelling language, i.e., it is capable of specifying itself. See the 2005 book chapter ―A Reflective Metamodel of Object-Process Methodology: The System Modeling Building Blocks‖ [5]. Previously it has been used for meta-model development and indeed such use is proposed in clause 4.3.2.

Harmonization efforts could benefit by comparing the OPM models derived from the original works. Identifying common objects or processes should lead to a better understanding of the relationships between the two separate standards.

4.1.1.3 Conformance criteria using the "shall", "should" and "may" qualifiers

4.1.1.3.1 Requirements for establishing normative criteria

The normative criteria of a standard are bound to very specific verb forms for the expression of provisions related to requirements, recommendations and permissions. These verb forms identify for the user of the standard the criteria by which they implement the standard for a product in a conformant manner? In the OPM paradigm the means for expressing the graphical equivalent of the normative text is a major concern. How are the 'shall', 'should', and 'may' normative verb forms retained in a way that enables the standard to be applied in another development environment?

The verb forms are qualifiers on the relations between parts in the text sentence structure. In modelling these qualifiers are attributes of the relation that can only be stated if the relations have a "first-class" characteristic as in E-R modelling. In some modelling languages like UML, relation cardinality constraints are used to indicate mandatory or optional associations, as is the case with OPM, but lack distinctions between recommendation and permission.

TC184/SC5 N1111

74

4.1.1.3.2 Expressing normative criteria in OPM

Current OPL syntax (without req. qualifiers) Future OPL syntax (with req. qualifiers)

Agent handles Processing.

Processing requires Instrument A.

Processing requires Instrument B.

Processing yields Product.

Agent shall handle Processing.

Processing should use Instrument A.

Processing may use Instrument B.

Processing shall yield Product.

Figure 81 — Proposed new constructs (OPD and OPL) for normative specification

Conformance criteria can be added to OPM as tags, see Figure 81 for the proposed Object-Process Diagram (OPD) and corresponding current and future versions of the Object-Process Language (OPL) syntax to be automatically produced from this OPD.

Another way of expressing conformance would be by reifying the relation as an object or process and attaching an Exhibition/Characterization link.

4.1.1.4 Bi-modal expression of a standard

OPM is one of only a few modelling languages that exhibit built-in dual graphics-text model representation, with automatic generation of a textual representation. For example, Concept maps [10] also provide dual representation but have a much weaker set of underlying rules for the syntax and semantics of the representation. OPM appears to be the only one that does so in a robust constrained English. This, along with its single-model view and compact, straightforward generic ontology of stateful objects and processes that transform them makes OPM a reasonable choice for model-based enterprise standards authoring.

4.1.1.5 Expressive precision and efficiency

Previously the issue of content size was mentioned in the presentation of ISO 19440. In that case the observation was made that a simple table can be a very efficient way to express differences between the modelling constructs. Taking that observation further, the various Construct templates in ISO 19440 are all normative and place quite specific requirements on descriptive and relationship attributes in each of the modelling phases as shown in Figures 24 – 29. This is an important part of the 'Modelling 19440 in OPM' exercise of section 3.4.3. The question is whether and how we can specify this kind of normative detail in OPM precisely (does the generated OPL express precisely the normative intent) and efficiently (in 19440 each template is less than one page and the OO class models are very 'page-space'-efficient in representing attributes and their relationships - can OPM compete?). David Shorter observers that for ISO 19440 when Richard Martin added a process to express that multiple EO can be created for one DM … and dependency with DI_xxx To DI_Domain_Reln: Relationship, ―I'm not at all happy about introducing two further sub-processes in the Domain Identification process to do this. My reasoning is that no such sub-processes are specified by the normative part of 19440 (and we do not want to overemphasize how Constructs are constructed. (I agree with you there) and that it will introduce yet more complexity into the other constructs and other modelling phase processes. There is a remark in the footnotes along the lines of "it is the

TC184/SC5 N1111

75

responsibility of the tool to keep such relationships in step". This does imply some sort of Event (e.g. XYZ Manifest Updated) and Notifying process, but it's getting horribly close to implementation detail (so out of scope of 19440)....‖ The issues of maintain scope for model-based standards is well taken because so often we find ―scope creep‖ as a standard progresses. For model-based standards, the NWIP and resulting statement of scope must be carefully crafted to enable an appropriate extent of model articulation without making conformance beyond the means of international commerce.

4.1.2 Gaining Acceptance

4.1.2.1 Advantages and disadvantages of OPM as a modelling language

4.1.2.1.1 OPM and other modelling languages

There needs to be a convincing argument to support the adoption of the OPM (which will be seen by many as yet another) language and notation. An outstanding objective is to understand the advantages and disadvantages of OPM compared to current possible conceptual modelling language candidates, which potentially meet our needs, including (but not necessarily limited to) SysML, PSL (ISO 18629), BPMN.

This report identifies many of the benefits to using OPM as well as some of the problems it presents for use by existing ISO experts. It is important to remember that any new tool use experiences the pains of adoption in route to achieving its benefits. And certainly while no tool can be expected to meet all of our needs, selecting the right tool for the task at hand is more important than using a tool not up to the task.

Complex systems can be modeled in a single view using the functions of in-zooming/out-zooming and folding/unfolding in OPM. But in UML, you have to describe them separately. In UML (or SysML) you need to use several structural (static) and several procedural (dynamic) views or models to do what in OPM is done in a single model. The OPM approach makes modelling much simpler and more intuitive and easy to follow and communicate. Also, in OPCAT you have automatic text generation which helps validate the model.

Both static systems and dynamic systems can be modeled in OPM, in forms of objects and processes. The activity models in IEC62264-3, which are dynamic, but it is much more difficult to do with UML.

4.1.2.1.2 Modelling language distinct from modelling tool

Many of the more popular modelling tools, like suites from Atego, Troux or No Magic, support a variety of modelling languages in the context of a model management paradigm. At present OPM is available in only one tool, OPCAT. For sustained use by ISO experts it will be necessary for OPM to become a staple in the suites offered by several vendors. Many corporate users are limited in the tools they can use by organization policy and the dependence upon access by professionals to selected modelling languages in the tools at their disposal is critical.

4.1.2.2 Bi-modal representation of models in other languages

Several modelling products provide some extent of bi-modal representation. Concept maps (Cmaps) [10] from Florida Institute for Human and Machine Cognition has a textual expression of the graphical model but only supports a very limited set of relationships and entities for modelling. In addition, the lack of modelling constraints makes model verification and validation entirely subjective. Whereas Cmaps can perform well in initial model development, large models with many layers of abstraction and detail are difficult to create. Moreover, the textual expression is limited to single relationships per statement. UML 2 has its characteristic class model that can be expressed in XML structured text but does not present an easily readable form.

If bi-modality of text and models is crucial, can we expect a realistic attempt for those modelling tools to add a more user friendly and semantically rich capability for bi-modal expression? Specifically, without digressing into the shortfalls of UML, why cannot the UML language and notation be adapted or extended (as happened with the SysML extension)? And that could then make it easier for existing tools to be modified accordingly. (Compare the SysML additions for MagicDraw.) Can an OPL (Object-Process Language) or Tesperanto

TC184/SC5 N1111

76

specification be derived from (some parts of) a UML model? If not, what's missing from UML and could the OMG be persuaded to remedy that? This lack of bi-modal express is becoming a well-recognized problem that OMG and others are beginning to address with new group efforts.

Currently OPM is the only modelling language that has bi-modal representation sufficient to meet the needs of evaluators and creators of International Standards. And, there is no current or contemplated effort to introduce bi-modality into UML or SysML of which this Study Group is aware. The subject was not even raised in the recent INCOSE MBSE Workshop held during Feb. 2010 in Phoenix, AZ, where the leading SysML authors and many UML users were present. Based on recent SysML RFI analysis results [9], presented at that workshop, there is currently no intention to make any significant changes to SysML on top of the upcoming SysML 1.2 version.

4.1.3 Availability and Stability

4.1.3.1 Requirements for availability and stability

The underlying specifications of techniques and methodologies need to be stable, accepted and in the public domain for them to be useful for the range of SC5 efforts.

The basic ideas of OPM including its bi-modality, are patented in US Patent and Trademark Office, number 7,099,809 (granted: August 29, 2006) and held by OPCAT LTD. However, OPM ideas and principles are in the public domain, published in a book [1] and numerous scientific, peer reviewed publications. The patent holders, whose central interest is the dissemination of OPM worldwide for any potential application, have never blocked its use. Conversely, OPCAT is, and has always been, distributed free of charge to academic

and other non-for-profit organizations, such as ISO (see link in1 for immediate download). This open attitude is not going to change in the future, as the major shareholder in OPCAT is one of the co-convenors of the OPM Study Group. Formal steps to assure that OPM meets the requirements for inclusion in ISO standards in terms of availability to users of the standard shall be made.

A 'formal definition of OPM' and a BNF expression of the OPL syntax, which already exists but needs revision, are necessary to enable tool vendors the opportunity to provide an OPM-based tool suite Tools are needed to apply OPM in a fashion suitable for use by the standard's development community. The Activity A Report identifies an initiative to develop such tools. Since they are developed as part of an academic research effort, they will be published and should be made available freely. In contrast the OO-based modelling tools that are being used now are robust and readily available (and often free), albeit lacking in specificity for use by standard's developers.

We need a publicly available specification for the OPM syntax, semantics and pragmatics (as distinct from the capabilities of the OPCAT tool) in a single free-standing Word document (as distinct from information in PowerPoint form), to answer questions such as: what are legal 'sentences' in OPM, how to use types, how to represent specific attribute values for object instances etc. In investigating OPM use over the past year we have encountered many heuristic of use that must be accessible by ISO experts without the need for special training. Given suitable resources, ISO experts can generally move ahead independently.

For any modelling language to successfully support the development and maintenance of International Standards it must be "platform independent" in the sense that no single operating environment is required for its use by our cadre of international experts that participate in the SC5 standards process. OPCAT is developed on top of JAVA Virtual Machine that, in principle, makes it platform independent. It is this independence that allowed the Apple environment to be exploited as an OPCAT tool platform. Unfortunately, the interface with the underlying OS file system required some significant effort to align with OPCAT assumptions about the platform configuration. New tools, including MBASE, intend to use the same framework.

One persistent problem we have encountered is the continual evolution of the OPCAT tool that has resulted in some frustrating moments as version compatibility has caused some difficulties. And on occasion it has been

1 The academic and evaluation software version can be obtained from http://dl.getdropbox.com/u/2083290/opcat-3.1-

limited-installer.exe.

http://dl.getdropbox.com/u/2083290/opcat-3.1-limited-installer.exe


TC184/SC5 N1111

77

necessary to recover a backup copy to restore access to a model. The extent to which these difficulties result from improper tool use or platform specific issues is unknown.

4.1.3.2 Extent of formal OPM, OPL, and Tesperanto specifications

OPM is formally defined [1] along with OPL. A BNF formal specification of OPL as well as a graph-grammar-based specification of OPD is available. After their validation and update, these formal definitions of an OPM model will be part of the proposed meta-standard or technical report for OPM definition.

Beyond the formal definition is the need to make clear the semantics of the link symbols with examples of their usage in different contexts. The distinction between exhibition and aggregation is often confusing as is the object activation rule when sub-objects of a structural link hierarchy become active. The nuance of the symbols as interpreted by a simulation is not always reflected in the associated OPL.

Tesperanto is not yet fully defined. Some case study examples show that it will not deviate significantly from OPL but will enhance the textual representation by connecting short sentences into longer, less mechanical, and more meaningful sentences. Part of the meta-standard authoring will be BNF definition of Tesperanto. As an example of the kind of difficulties to overcome in moving from the constrained text of OPL to the natural language necessary to support the authoring work of ISO experts, the following discussion is offered by a recent work from Blekhman and Dori:

Object-Process Diagrams (OPDs) are inherently accompanied with auto-generated OPL Object-Process Language) text. OPL cannot be used, though, for specifications, as it is too mechanical and repetitive. According to [Dov's book on OPM], "… OPL is a dual-purpose language. First, it serves domain experts and system architects engaged in analyzing and designing a system, such as an electronic commerce system or a Web-based enterprise resource planning system. Second, it provides a firm basis for automatically generating the designed application". Therefore, OPL was never meant to become a text to be read by a general audience. Based on these two goals, the OPL generation algorithm is based on DFS Depth-First Search) [the link above]. Obviously, it is not suitable for human reading, although it may be good for code generation, for example (as all possible contexts of an item are brought together). OPL is too detailed, technical and is structured in a way which makes it difficult for humans to comprehend. Given this, we define Tesperanto as a language alternative to OPL. Unlike the DFS specification of OPL, Tesperanto is defined and presented in a BFS (Breadth-First Search) style. An overall Tesperanto generation algorithm follows the next guidelines:

1. For each process: i. List the name and the definition of the process along with its outcomes. ii. List the agents. iii. List the instruments. iv. List all other related items (conditions, etc.) v. List the dynamic aspects (events, invocations etc.)

2. Align and rephrase the text according to a set of rules. For example, if a process has an instrument that is comprised of two object parts, add them parenthesized in the same line. If there is a list of, say, 5 or more instruments, consider splitting it into two groups with a sentence for each.

3. If there are more processes in the same level, repeat the above for each process. If not, in-zoom and repeat doing the above for the next level.

A further complication is that the graphical layout most understandable to an ISO expert may not align well with the corresponding structure of the text. For example, in Figure 12 the notation is placed to the right as Clause 6.1.3 because the notation is used in the Clause 6 construct definitions. However in the OPL, that notation is given before the Clause 5.2 model that is the real subject of the Figure.

TC184/SC5 N1111

78

While this may be a tool implementation issue, the definition of OPM requires a progression of elements to create a logical flow for implementation that may not be the logical flow most suitable for presentation in the standard. This situation would be most pronounced at the higher levels of abstraction in the development of the model where the contents of the standard and the ISO layout of the standard‘s clauses do not align as in informative annex material that is necessary to understand the standard normative text.

We must make clear that this difficulty in crafting a model-based standard is not unique to OPM, Standards that use IDEF0 or UML or XML all share this characteristic. Our models work best in the standard context when we use them as snippets for specific portions of the standards. However, this usage does little to address the wider consistency and completeness concerns. OPM at least gives us a way to examine these issues at a both a high extent of abstraction and as concrete clause statements, and therein lies its utility for the work of authoring International Standards.

4.1.3.3 OPM Maturity and scalability

OPM has evolved since 1995, when the first paper appeared [11] into a mature methodology, complete with language and guidelines for systems development and life cycle support. OPCAT [2], a commercial tool, is freely available for academia and small projects. The tool originated in academia (Technion, Israel and MIT, USA) and is constantly evolving and supporting a growing number of life cycle activities. The OPM diagrams

in this document were prepared using OPCAT.2

With the assistance of OPCAT staff and an enterprising MIT student, Shirish Ranjit, David Shorter has been able to install the OPCAT tool on the Mac OSX JVM platform and the material in section 3.4.3 exemplifies its use on that platform. However, an install package for the Apple platform is not a standard deliverable for OPCAT although there are now instructions for doing the installation..

We anticipate that the reliance upon the JAVA Virtual Machine will carry forward and enable multi-platform use. The repository provided to the ISO OPMSG has worked fairly well given our very undisciplined use of the facility. So long as the use of International Standards and industry de-facto standards is the basis for evolution of the OPCAT tool and, hopefully, the introduction of other OPM tools, OPM has great potential for use by ISO experts.

OPM is scalable with implementations bounded only by the size of memory available to the modelling activity. But the issue of scalability also extend beyond the use of a specific OPM model on a specific computing platform. Previously we discussed the difficulty of producing models that are very similar in concept but distinct in detail, most often different labels for the same basic structure. This kind of model snippet explosion is a scalability issue easily handled by a table in a text document but not well handled by graphical models. We suspect there are other circumstances where the most appropriate means of representation depend upon the specifics of the information to be represented.

4.1.4 Operational Considerations

4.1.4.1 Requirements for operating in a standard's domain

Which clauses of a standard should use OPM-based modelling to express content? Some clauses would become excessively long if both text and graphics are included in the published standard. Some clauses may not benefit from the rigorous correspondence that bi-modality provides, and some clauses may not benefit from modelling at all. How could an integrated model that spans several clauses be incorporated into a standard?

It is very useful during the standard drafting process to generate (automatically) selective views (as a diagram) of the underlying model, where each view corresponds to the central concern of some clause. An example would be to focus on say ‗clause A: Quality Assurance‘ and the ‗things‘ that directly support it or are involved in it some way. Those ‗things‘ would probably be specified in other and often textually separated) clauses B1, B2, etc). Then the A and B1, B2, … clauses can be checked individually for consistency with the diagram,

2 The academic and evaluation software version can be obtained from http://dl.getdropbox.com/u/2083290/opcat-3.1-

limited-installer.exe.



TC184/SC5 N1111

79

assuring internal consistency amongst the clauses. This is a different capability to that of ensuring that text and model snippets are individually consistent.

OPM and supporting tools can ensure similar constancy between text and model fragments that have been separately drafted (and by different authors), as distinct from being derived from some overarching hierarchical model by relying on a agreed underlying ontology, modelled as an OPM model and imported into and used by the separate drafting efforts.

But questions about OPM use remain:

How are OPM models (and the snippets from which they are composed) to be registered and maintained (especially how to handle any knock-on effects), after they are reduced to a printed form without inclusion of a machine readable format, e.g. during amendments and when standards are revised after 5 years or so?

Similarly for the "underlying extendable central OPM model of the domain's ontology" and the "shared Web-based repository of normalized OPM-based model modules". Who has that responsibility over the life-cycle of the standard?

Will that responsibility be split between domain and OPM experts?

It is one thing to develop a standard using modelling tools to aide in the specification of normative language but it is quite another to provide the information and means to maintain the standard over time as personnel and the demands for utility change. Indeed, doing so requires a life cycle approach to an International Standard beyond that provided by the Systematic Review process as a specialization of a technical document, which is analogous to the modern life cycle approach to physical and software-intensive systems. This is one focus of the on-going academic research related to this effort.

While many want to consider a standard to be a complete whole concerning a specific topic, this is not always the case. Therefore, a top-down hierarchic perspective may not exist. Rather, a set of models with a common theme is present. This may be the situation with IEC 62264 where a variety of Level 3 and Level 4 implementation models are supported by one standard. Different enterprises partition their domain space in different ways and the standard is intended to serve whatever partitioning is employed by an enterprise.

The overall structure of a standard has to be ordered (with a minimum number of forward references, ideally none) as clauses that name and describe the things being specified in a recognizable and sensible (but necessarily linear) order to domain experts and engineers. The details of these clauses should range from the more general to the more specific. It may be and probably will be the case that formal semantics (e.g. OPL text and OPDs) are presented only as fragments at the 'specific' class level. However, they should be derived (or derivable) from some unique underlying integrated model. This is the case with the use of OPM in IEEE P2030 in section 3.7.

As noted earlier, the structure of the standard as linear text (organized for comprehension) may often be different than that of the underlying model (constructed by modelling or domain experts, possibly organized according to some methodology, but sometimes arising from brainstorming and 'formalized' later). It is important to recognized the essential role for this part of the standard (even though it may not be published), which needs to be retained to support later revisions or maybe new interpretations.

4.1.4.2 OPM operational considerations

With bi-modal representation documents structure may include many more graphical models, but many current standards documents already have a significant number of diagrams of various kinds to enhance usefulness of the standard to its users. The structure and exact way of embedding and ordering the OPD snippets and OPL or Tesperanto paragraphs within a standard document will be suggested as part of the meta-modelling activity together with clear mechanisms for author placement of text and graphics. Model and ontology maintenance over the standard‘s development and use life cycle may be managed using the advanced OPM features of model versioning, which are already implemented in the current OPCAT 4 version.

TC184/SC5 N1111

80

The use of the ISO LiveLink facilities as a repository may also be necessary and therefore formal agreements will be necessary for the protection of intellectual property for ISO and OPCAT or other tool providers.

And then there are the significant initial and on-going training in OPM use for a cadre of ISO experts that is necessary to achieve any kind of wide acceptance and use for OPM. The benefits of OPM are only available when our experts use it. The effort to become proficient, as with all modelling methodologies is significant. Even those that do not become proficient must accept the results of model-based methodologies in the development of standards if we are to benefit form that activity. We accept the bi-modal approach of OPM to a significant advantage in this regard.

4.2 OPM as a Basis for Model-Based Standards

4.2.1 The Standard Modelling Process

4.2.1.1 OPM features essential for modelling standards

4.2.1.1.1 OPM Processes as First Class Citizens

Underlying OPM is a philosophy stipulating that in order to faithfully and naturally model, analyse, and design systems in any domain, processes need to be recognized as "first class citizens." Like objects, OPM processes are considered as bona fide, stand-alone "things" rather than being encapsulated within objects, as the object-oriented (OO) approach advocates.

4.2.1.1.2 Physical vs. Informational and Systemic vs. Environmental Things

Geared for systems engineering from the outset and treating software systems as specializations of general systems, OPM has no inherent "software-oriented" language semantics. For example, OPM objects and processes can be informatical, which may exist in models of both software systems and other general systems, or physical, which is atypical of pure software systems but obviously essential for systems in general. Both objects and processes can be physical or informational. Not only can objects and processes be physical or informational, they can also be systemic (part of the system) or environmental (part of the environment interacting with the system).

4.2.1.1.3 Graphics vs. Bimodal Graphics-Text Combination

OPM combines mathematically-grounded formal yet simple graphical language with natural language sentences to express the function, structure, and behaviour of systems in an integrated, single model. The two semantically equivalent modalities, one graphic and the other textual, jointly express the same OPM model. While the visual-graphic and the verbal-textual modalities are semantically equivalent, they appeal to two different information processing channels of the brain, the visual and the lingual.

4.2.1.1.4 Using an International Standard appropriate ontology

In addition to the deontic terms and phrasing identified above in 4.1.1.3.2, several other of the terms in the OPM lexicon present problems for use in standards, especially when encountered by ISO experts without OPM experience. For example, the four structural links of aggregation/participation, exhibition/characterization, generalization/specialization, and classification/instantiation are interpreted differently in different domains of practice even within the information systems community. This becomes apparent when the OPL produced does not result in the statements expected by the person creating the figure. In standards we do not use the term ―unfolded‖ or ―in-zoom‖ to express decomposition or refinement and seldom use the OPL phrase of ―exhibits‖ or ―yields‖ or ―consumes‖. David Shorter comments that, ―exhibits" is not a natural label for me - I just translate it mentally all the time into "has the attribute". The term ―view‖ as used in OPM has a slightly different sematic than customarily used by SC5 experts.

TC184/SC5 N1111

81

The lexicon of OPM was selected for particular reasons associated with process modelling and a desire to specify terms in relation to the underlying formal model of OPM. For ISO and IEC standards we likely will need a somewhat different lexicon to gain wide use and probably will need to modify the lexicon for distinct expert domains to aid in transforming the OPL for models in those domains to text for the standard.

4.2.1.2 Using OPM to model standards

OPM is a prime vehicle for carrying out the tasks that are involved in system development. It does so in a straightforward, mostly friendly, unambiguous manner. One important reason for this is that the design of OPM has not been influenced by what current programming languages can or cannot do, but rather, what makes the most sense when trying to represent and conceptually model systems as best as possible.

Due to the resulting intuitiveness, OPM is communicable to both technical and non-technical stakeholders of the system being developed, including peers, customers and implementers. At the same time, the formality of OPM makes it amenable to computer manipulation for generating, automatically or semi-automatically, large portions of the conceived system, notably program code and database schema. More importantly for our situation, it makes possible checking the completeness and soundness of standards.

These robust features come at a cost of time and effort on the part of expert modellers to learn the basics of OPM at a minimum and to master OPM for full benefit. This time and effort is not insignificant for volunteers in any case and particularly burdensome for those inexperienced with graphical modelling. Support for using OPM is sparse and a sole product vendor cannot be expected to have available the resource to manage a large cadre of ISO experts using OPM on various platforms for a wide range of efforts over long intervals of time.

These are significant challenges for using OPM in other than narrowly targeted situations. The use of a specific modelling methodology can force a generalist in tool use to act as a specialist, which they are not. We need to assure that the authors of standards remain focused in their areas of expertise.

We need to be clearer about whether we're recommending the use of OPD as a notation, or OPM as a methodology. Once a good OPD model of a TO-BE standard exists, then there are clear benefits of increased consistency etc., but how to get to that stage? For standards that are more concerned with processes (as in section 3), the OPM methodology (stakeholder -> processes that deliver benefit -> resources) is clearly helpful - our exercise at in NEMA showed that. What is not so clear is, for standards that are more concerned with specifying structures (or meta-structures) rather than processes, whether or how to apply OPD notation in collectively thinking about and capturing requirements at an early stage, and to what extent that might slow down or assist that activity. Consider the somewhat rambling brain-storming sessions we've needed to have at the outset of new work in order to get everyone on board (think of the joint ontology session we had at Fraunhöfer Berlin).

The process of reverse-engineering a text document, i.e., translating a text document into a formal model is by and large domain-independent and, as shown in this report, of questionable utility. Model-based authoring of a new document, akin to forward engineering is the subject of the new section and SC5 N1112 Working Draft for Meta-standard for Model-based standard authoring.

The SC5 OPM SG has identified a process that may result in a reduction of content inconsistencies through a bi-modal presentation, which enables deep cognitive analysis of the standard‘s technical content. Some standards, such as the IEC 62264 series, use models to support the presentation of their content. However, in this particular model-supported approach the UML class diagrams in the standard do not stem from an underlying base model. Rather, they are provided on an ad-hoc manner to go with nearby text, with no assurance of conformance between the two. We note that use of OPM in IEEE P2040 is very much the same. In contrast the UML diagrams underpinning ISO 19940 (see ISO 19440 Annex C) are derived (automatically) from a single underlying base model, and concordance checking was used to check diagram correspondences with the normative text – this is one example of an analytical technique that has been used successfully.

The need for a participating domain expert is largely dependent upon the domain of the technical document and the background of the modelling analyst. In situations where content is not being added to a standard, only rudimentary knowledge of the domain‘s subject matter is sufficient for the analysis, but working

TC184/SC5 N1111

82

knowledge of the modelling methodology, in our case OPM, is important. Our work with IEC 62264 has shown that even relatively small efforts can require significant domain expertise as well as expertise with a particular existing standard.

5 Model-based standards authoring

The model-based approach derives the standard‘s content from an underlying semantic model rather than a syntactic model-supported approach. Due to its bi-modal graphic-text capabilities, OPM provides a means for verifying the standard‘s clauses and producing ontology that encompasses the document content, which significantly enhances the document‘s testability and validity. 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. Modelling can be successfully moved from the interpretation of textual specifications for model construction to initial system definition, 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 modelling technical standards in general and enterprise standards in particular.

5.1 Meta-standard for model-based standard authoring

The Model-based ISO Standard Authoring OPM model presented in section 3.8 identifies an Initial MBS Model as a result of the Standard Forming process but does not elaborate on the process by which that model is created or used in subsequent authoring activities. As directed by SC5 Resolution 624, a working draft for Meta-standard for model-based standard authoring, SC5 document N1112, has been developed to address that aspect of the section 3.8 model. The working draft leverages the processes defined in section 3.8 and extends the notion of a model-based standard by articulating the use of OPM to create a semantic model for a target domain.

The focus of N1112 is on the objects and processes of Input Document Preparing, particularly Standard Forming where model-based and text-based are only distinguished in the end by the section 3.8 model. In fact, elaborating processes up to that differentiated result reveals that modelling dominates these early aspects of standard development. Most of the discontinuity and confusion found in the final adopted standard is the result of a failure to continue fidelity with the model first considered – the language is ―improved‖ in conflict with the model, which is all but forgotten.

In developing International Standards we are trying to codify established best practice – not invent a new way of doing international commerce, although that is often the practical outcome. So modelling is already essential to developing standards and all manner of business practices. Our objective is to provide an International Standard that carriers the early modelling in some formal way through the entire life cycle of the standard‘s development enterprise, thereby significantly improving the clarity and usefulness of that product.

5.2 Model authoring outline

Future revisions and enhancements to the various IEC 62264 parts, harmonization of IEC 62264 with ISO 19440, and for other standards can be conducted following the methodology demonstrated in our work as codified in the Meta-standard for model-based standard authoring, N1112, and every briefly outlined as follows:

Obtain Standard Definition, including Scope, Goal and Objectives according to the Expected Benefit, as expressed by the Stakeholders;

Harvest and Analyse Potential Reference Base for the Standard, obtaining Domain Ontology Reference Base;

TC184/SC5 N1111

83

Perform Functional Analysis and OPM Modelling to obtain Preliminary OPM Standard Model on the basis of OPM Domain Model obtained from Domain Ontology Reference Base according to Standard Definition;

Elaborate and Refine the Preliminary OPM Standard Model by checking consistency, removing duplicates and verification against Standard Definition and Stakeholders' needs; and

Identify Standard Structure and create Model-Based Standard Text with the aid of MBASE - Model-Based Authoring of Specifications Environment.

As with any International Standard development effort, a range of perspectives within a domain and relevant domain expertise is essential to successfully crafting a useable standard that can gain acceptance in the marketplace. Modelling skill alone will not produce successful standards.

5.3 Emerging model-based authoring capabilities

As a current research effort the Model-Based Authoring of Specifications Environment, MBASE, intends to provide a capability of supporting large-scale model-based product development. This methodology forms the basis for N1112 as the working draft for Meta-standard for Model-based Enterprise Standards Authoring (MEMESA), which is based on the following principles:

An enterprise standard shall be model-based;

OPM shall serve as the modelling language and methodology for authoring and evolving model-based enterprise standards;

MEMESA shall itself be model-based;

MEMESA shall be constructed following the principles and guidelines recommended in this work.

TC184/SC5 N1111

84

Annex A

OPM Syntax and Semantics

A.1 OPM Symbology

ENTITIES

STRUCTURAL LINKS & COMPLEXITY MANAGEMENT

ENABLING AND TRANSFORMING PROCEDURAL LINKS

EVENT, CONDITION, AND INVOCATION PROCEDURAL LINKS

A.2 Entities

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.

TC184/SC5 N1111

85

A.3 Structural Links and Complexity Management

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.

TC184/SC5 N1111

86

A.4 Enabling and Transforming Procedural Links

ENABLING AND TRANSFORMING PROCEDURAL LINKS


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.

TC184/SC5 N1111

87

A.5 Event, Condition and Invocation Procedural Links

EVENT, CONDITION, AND INVOCATION PROCEDURAL LINKS


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

s2.

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).

TC184/SC5 N1111

88

Annex B

OPCAT Feature Shortcomings for ISO experts

B.1 OPCAT User Guides and Tutorials

The guides and tutorials available for OPCAT do provide a basic introduction to OPM and the use of the OPCAT platform. The tutorials in particular are helpful but do not cover the pragmatic used of OPCAT to the depth needed for ISO experts. Adding Dov Dori book as a resource is also helpful but probably not a practical approach for volunteers. Below is an email about pragmatic usage from Chen Linchevski to Richard Martin regarding the use of in-zoom, unfold and the OPCAT ―Use-Expose‖ feature. It will be necessary to ISO experts to have at their disposal a guided to use of OPCAT oriented toward the kind of modelling situations they encounter. In part this is the subject of the MBASE effort.

Few comments from my experience:

1. in-zoom - in real life it is used for processes. If the processes have a set time-line then the nested processes will be inside the in-zoomed process. If not they will be at the newly created OPD but will be outside the ellipse and connected with Aggregation Relation.

2. unfold- I do not use unfold for design. I use it only to collect all the relations from my model. I describe the objects in my model as needed while describing the processes. At any point I can unfold and get a view of the entire structure from different OPDs. I often do unfold for processes as well to get the processes tree. It is not recommended to add new things at the unfolded view.

3. In cases where I need to describe only the structure of the something, I would consider creating a separate model for the structure and use the "Use-Expose" mechanism to bring objects from the other general model to my model. The assumption is that in many cases this structure model will be used by some other models. For example, I would use this if I want to describe the structure of the standard document (and not its creation process). I can then use parts of the structure at the models describing the creation process.

B.2 OPCAT OPD Hierarchy sequencing

The OPD hierarchy is quite difficult to use as a reliable way of navigating - often it seems to collapse back to the outermost OPD and everything has to be expanded again. You should be able to return to the OPD hierarchy in the form at the time you made the previous selection without manipulating the structure.

If one changes the name of a Process (and probably an Object) in an OPD, the corresponding name in the OPD hierarchy is not updated properly. I've got round this by editing the names in the tree manually - but hope that doesn't mean the two things are now different. Label should correspond to the elements to which they are attached independent of use.

B.2.1 OPCAT OPD Hierarchy in-zoom verses unfold

All unfolded Objects are presented in a flat list in the OPD hierarchy at the end of processes. I'd like to have the OPD hierarchy contain the 'Views' (aka unfolded Objects) presented in the hierarchy immediately underneath the first OPD in which they are shown to be unfolded objects. Without that it's very difficult to get an impression of the overall OPD process/object structure (not easy anyway). This is one area where OPD definitely falls short for me in not being able to present a comprehensive view of a collection of related objects - compare Figure C.3 of 19440.

TC184/SC5 N1111

89

B.2.2 OPCAT OPD Hierarchy sequence re-ordering

It should be possible to change the order of appearance in the OPD Hierarchy. On some occasions the presentation order is no the logical order of presentation in the OPD. Notice in Figure 51 that ISO Guidelines Checking occurs before External Version Identifying but in the OPD Hierarchy of Figure 40 they appear in the opposite order. Short of deleting a redoing the OPDs there seemed to be no way to correct the OPD Hierarchy sequence. The sequence of clauses and sub-clauses in ISO documents is very important and model fidelity to the ISO guidelines is essential.

Distinct from but related to this is the sequence of OPL statements resulting from and OPD. This sequence needs to be easily modified perhaps by tagging the processes and objects in the OPD. This kind of sequence tagging would also enable a more straightforward Tesperanto rendition of the OPL text.

B.3 OPCAT Model fragment management

In the OPD it's possible to in-zoom a process down to a sub-process (i.e. navigate down using the OPD) but not apparently up (out-zoom?). Not all modelling occurs from the top down. A need exists for identifying one or more processes and then creating a parent process that contains them – a way to abstract their combined effect.

How does one out-zoom (un-zoom?, zoom-out? ) a process. Don't seem to be able to click on a sub-process and navigate to the containing process. Instead you need to use the OPD hierarchy button (LH window).

We've found one can also 'in-zoom' an object (surely that should be 'unfold' in line with OPM usage/vocabulary?) to get a new OPD and add component parts and presumably states. But how does one fold such an object to suppress its internal structure (states, components) and so collapse that part of an OPD to its containing object, e.g. collapsing the links between a 'process P and the input/output states of an object A' to 'P affects A'. The description of OPM seems to imply that this should be possible. Using the 'right-click' menu doesn't give me that option. So it looks as though, other than 'in-zooming' (AKA 'unfolding' for objects) the only way of navigating between entities and their containing entities is via the OPD window.

It is often difficult to determine where you are in the model OPD hierarchy when you navigate without the OPD Hierarchy menu. This is particularly the case when doing a simulation. A persistent OPD Hierarchy that tracks where you are in the hierarchy is needed at all times.

B.4 OPCAT Helpful additions

Explanatory text added as detail to processes or objects should be available in the OPL listing, perhaps as an option, when that text is not germane to the model itself but important to the text of the standard.

Help > Contents? ............ doesn't do anything (the button blinks but nothing happens)

The Undo facility seems limited - some operations are just not undoable.

The drawing algorithm used for structural relations seems rather primitive and produces lots of crossing lines. One cannot select the parts of the connecting lines and manipulate those to sort that out (if one selects the triangle symbol, there are small boxes on the various corners of the lines, but one cannot always select them or move them...). Instead you have to move the objects at each end or the triangle on the line. Also (a minor aesthetic point) one can't produce 'A is a specialization of B' without a kink in the connecting line.

Print doesn't work well for OPDs (maybe a Java problem), but there are work-arounds using print screen and Paint. Similarly the 'save as image' truncates part of the diagram.

TC184/SC5 N1111

90

A wish-list for OPCAT features that would make things a lot easier (some may just be issues with v4 Beta of course):

* keyboard shortcuts for New Object and New Process (they may be there but I haven't found them)

* ability to Copy and Paste text from other documents works on Windows but not Mac.

* ability to Copy something named in the Things list as an Object or Process directly into an OPD, again a Mac problem.

* keeping the OPD hierarchy fully expanded so can copy and paste entities from one OPD to another more easily (at the moment the hierarchy collapses when something is Copied or Cut from its containing OPD)

* improved navigation up and down the OPD hierarchy - why no Down arrow to show the first of contained OPDs? So could go from SD3.1.1 to say SD3.1.1.1. And update the enabled navigation buttons according to where you are in the tree (so Left is not enabled for a first item, nor Down for an un-zoomed item etc). It seems that Up often (always?) takes me back to the top level, which is not what I want.

* at present double-clicking on an object opens its specification. It would be good to have a shift- or control-click to expand or unfold a thing into its OPD (and maybe that should be the default?)

* ability to export Object or Process details as text (maybe within the OPL?) But this is all incidental at the moment.

TC184/SC5 N1111

91

Bibliography

[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

[5] Iris Reinhartz-Berger and Dov Dori, A Reflective Metamodel of Object-Process Methodology: The System Modeling Building Blocks. In Business Systems Analysis with Ontologies, P. Green and M. Rosemann (Eds.), Idea Group, Hershey, PA, USA, pp. 130-173, 2005.

[6] ISO/WD 18629-11 standard (PSL Core) specified in ISO TC184/SC4/JWG8 N 236 dated 2001-02-19.

[7] OMG SysML 1.1 specification. Avilable: http://www.omg.org/spec/SysML/1.1/PDF

[8] Mor Peleg and Dov Dori, The Model Multiplicity Problem: Experimenting with Real-Time Specification Methods. IEEE Transaction on Software Engineering, 26, 8, pp. 742-759, 2000

[9] Cloutier R. & Friedenthal, S. SysML Analysis Results. Available: http://www.omg.org/cgi-bin/doc?syseng/2009-12-04

[10] Novak, J. D. & A. J. Cañas, The Theory Underlying Concept Maps and How to Construct Them, Technical Report IHMC CmapTools 2006-01 Rev 01-2008, Florida Institute for Human and Machine Cognition, 2008, available at: http://cmap.ihmc.us/Publications/ResearchPapers/TheoryUnderlyingConceptMaps.pdf.

[11] Dov Dori, Object-Process Analysis: Maintaining the Balance between System Structure and Behavior. Journal of Logic and Computation, 5, 2, pp. 227-249, 1995.

http://www.springerlink.com/media/CHBKUPQXULV5LU7PNQT1/Contributions/A/1/Y/9/A1Y9E34PBKD0P9KU.pdf

http://www.springerlink.com/media/CHBKUPQXULV5LU7PNQT1/Contributions/A/1/Y/9/A1Y9E34PBKD0P9KU.pdf

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

http://isotc.iso.org/livelink/livelink/fetch/2000/2489/Ittf_Home/MoU-MG/Moumg159.pdf

http://www.omg.org/spec/SysML/1.1/PDF/

http://ieeexplore.ieee.org/iel5/32/19036/00879812.pdf?isNumber=19036&prod=JNL&arnumber=879812&arSt=742&ared=759&arAuthor=Peleg,+M.;+Dori,+D.

http://www.omg.org/cgi-bin/doc?syseng/2009-12-04

http://www.omg.org/cgi-bin/doc?syseng/2009-12-04

http://cmap.ihmc.us/Publications/ResearchPapers/TheoryUnderlyingConceptMaps.pdf

iso/tc 184/sc 5 n1111 - israel institute of...

Documents