ISO 19450:2024

Automation systems and integration - Object-Process Methodology

This document specifies Object-Process Methodology (OPM) with detail sufficient for enabling practitioners to utilise the concepts, semantics, and syntax of OPM as a modelling paradigm and language for producing conceptual models at various extents of detail, and for enabling tool vendors to provide application modelling products to aid those practitioners. While this document presents some examples for the use of OPM to improve clarity, it does not attempt to provide a complete reference for all the possible applications of OPM.

Systèmes d'automatisation et intégration — Object-Process Methodology

General Information

• Status: Published
• Publication Date: 14-Jan-2024
• ICS: 25.040.40 - Industrial process measurement and control
• Technical Committee: ISO/TC 184/SC 5 - Interoperability, integration, and architectures for enterprise systems and automation applications
• Drafting Committee: ISO/TC 184/SC 5 - Interoperability, integration, and architectures for enterprise systems and automation applications
• Current Stage: 6060 - International Standard published
• Start Date: 15-Jan-2024
• Due Date: 09-Aug-2023
• Completion Date: 15-Jan-2024

Relations

• Revises: ISO/PAS 19450:2015 - Automation systems and integration - Object-Process Methodology
• Effective Date: 06-Jun-2022

Overview

ISO 19450:2024 - "Automation systems and integration - Object‑Process Methodology (OPM)" defines OPM as a modelling paradigm and language for producing conceptual models across levels of detail. The standard specifies the concepts, semantics, and syntax required for practitioners to build clear, consistent OPM models and for tool vendors to implement compliant modelling products. It includes modelling principles, a bimodal graphical/textual approach, examples for clarity, and rules for conformance, but does not attempt to catalogue every possible OPM application.

Key topics and technical requirements

• Modelling principles and purpose: Guidance on modelling as a purpose‑driven activity and on balancing clarity vs completeness (system boundary setting, functional value).
• Unification of function, structure, and behaviour: OPM’s integrated approach to represent objects (things) and processes.
• Bimodal representation: Rules for consistent graphical and textual representations.
• OPM things (objects & processes): Definitions, properties, default values, and object states.
• Link types and semantics:
  • Procedural links (transforming, enabling, control): consumption, result, effect, agent/instrument, event and condition semantics.
  • State‑specified links: links sensitive to object states for precise behaviour modelling.
  • Structural links: aggregation, characterization, generalization, classification, tagged links and state‑specified structural relations.
• Execution semantics: Event‑Condition‑Action flow, preprocess/postprocess sets, skip vs wait semantics, execution paths and path labels.
• Relationship cardinalities and constraints: Multiplicity expressions, attribute constraints.
• Logical operators: AND, XOR, OR procedural link semantics, divergence/convergence rules and probabilistic fans.
• Context management and conformance: Model context, implementation guidance and conformance criteria for tools and practitioners.
• Normative elements: Terms, symbols, definitions and normative references.

Practical applications and users

ISO 19450:2024 is aimed at anyone involved in conceptual modelling for automation and system integration:

• Systems engineers and architects using OPM for system specification, design reasoning and cross‑discipline communication.
• Automation integrators modelling processes, workflows and product‑service interactions.
• Model‑based systems engineering (MBSE) practitioners who need a rigorous, unified way to express structure and behaviour.
• Software and tool vendors implementing OPM editors, validators and model interchange functionality.
• Educators and analysts teaching or validating conceptual models in projects requiring traceability and clarity.

Adopting ISO 19450:2024 improves model clarity, supports tool interoperability, and helps teams produce consistent conceptual models for automation systems and integration projects.

Related standards

ISO 19450:2024 complements other systems and automation standards and can be used alongside model‑based systems engineering practices and domain‑specific integration standards to strengthen conceptual modelling and tool support.

Standards Content (Sample)

International
Standard
ISO 19450
First edition
Automation systems and
2024-01
integration — Object-Process
Methodology
Systèmes d'automatisation et intégration — Object-Process
Methodology
Reference number
© ISO 2024
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
ii
Contents Page
Foreword .vi
Introduction .vii
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Symbols . 8
5 Conformance . 10
6 Object-Process Methodology (OPM) principles and concepts .10
6.1 OPM modelling principles .10
6.1.1 Modelling as a purpose-serving activity .10
6.1.2 Unification of function, structure, and behaviour .11
6.1.3 Identify functional value .11
6.1.4 Function versus behaviour.11
6.1.5 System boundary setting . 12
6.1.6 Clarity and completeness trade-off . 12
6.2 OPM fundamental concepts . 12
6.2.1 Bimodal representation . 12
6.2.2 OPM modelling elements . 12
6.2.3 OPM things: objects and processes . 13
6.2.4 OPM links: procedural and structural . 13
6.2.5 OPM context management .14
6.2.6 OPM model implementation (informative) .14
7 OPM thing syntax and semantics .15
7.1 Objects . 15
7.1.1 Description . 15
7.1.2 Representation . 15
7.2 Processes . 15
7.2.1 Description . 15
7.2.2 Representation .16
7.3 OPM things .16
7.3.1 OPM thing defined . . .16
7.3.2 Object-process test .16
7.3.3 OPM thing generic properties .17
7.3.4 Default values of thing generic properties .17
7.3.5 Object states .18
8 OPM link syntax and semantics overview .20
8.1 Procedural link overview . 20
8.1.1 Kinds of procedural links . 20
8.1.2 Procedural link uniqueness OPM principle . 20
8.1.3 State-specified procedural links . 20
8.2 Operational semantics and flow of execution control . 20
8.2.1 Event-Condition-Action control mechanism . 20
8.2.2 Preprocess object set and postprocess object set .21
8.2.3 Skip semantics of condition versus wait semantics of non-condition links .21
9 Procedural links .22
9.1 Transforming links . 22
9.1.1 Kinds of transforming links . 22
9.1.2 Consumption link . . 22
9.1.3 Result link . 23
9.1.4 Effect link . 23
9.1.5 Basic transforming links summary . 23

iii
9.2 Enabling links .24
9.2.1 Kinds of enabling links . .24
9.2.2 Agent and agent link .24
9.2.3 Instrument and instrument link .24
9.2.4 Basic enabling links summary . 25
9.3 State-specified transforming links . 26
9.3.1 State-specified consumption link . 26
9.3.2 State-specified result link . 26
9.3.3 State-specified effect links .27
9.3.4 State-specified transforming links summary . 29
9.4 State-specified enabling links . 30
9.4.1 State-specified agent link . 30
9.4.2 State-specified instrument link . 30
9.4.3 State-specified enabling links summary .31
9.5 Control links .31
9.5.1 Kinds of control links .31
9.5.2 Event links . .32
9.5.3 Condition links .37
9.5.4 Exception links . 44
10 Structural links .45
10.1 Kinds of structural links .45
10.2 Tagged structural link .45
10.2.1 Unidirectional tagged structural link .45
10.2.2 Unidirectional null-tagged structural link .45
10.2.3 Bidirectional tagged structural link . 46
10.2.4 Reciprocal tagged structural link . 46
10.3 Fundamental structural relations.47
10.3.1 Kinds of fundamental structural relations .47
10.3.2 Aggregation-participation relation link . 48
10.3.3 Exhibition-characterization link . 49
10.3.4 Generalization-specialization and Inheritance .52
10.3.5 Classification-instantiation link . 55
10.3.6 Fundamental structural relation link and tagged structural link summary .57
10.4 State-specified structural relations and links . 58
10.4.1 State-specified characterization relation link . 58
10.4.2 State-specified tagged structural relations .59
11 Relationship cardinalities .64
11.1 Object multiplicity in structural and procedural links . 64
11.2 Object multiplicity expressions and constraints . 66
11.3 Attribute value and multiplicity constraints . 68
12 Logical operators: AND, XOR, and OR .68
12.1 Logical AND procedural links . 68
12.2 Logical XOR and OR procedural links .70
12.3 Diverging and converging XOR and OR links .71
12.4 State-specified XOR and OR link fans . 73
12.5 Control-modified link fans .74
12.6 State-specified control-modified link fans .74
12.7 Link probabilities and probabilistic link fans . 75
13 Execution path and path labels .77
14 Context management with Object-Process Methodology (OPM) .79
14.1 Completing the system diagram (SD) . 79
14.2 Achieving model comprehension . 79
14.2.1 OPM refinement-abstraction mechanisms . 79
14.2.2 Control (operational) semantics within an in-zoomed process context . 83
14.2.3 OPM fact consistency principle . 94
14.2.4 Abstraction ambiguity resolution for procedural links . 95

iv
Annex A (normative) Object-Process Language (OPL) formal syntax in Extended Bachus-Naur
form (EBNF) .98
Annex B (informative) Guidance for Object-Process Methodology (OPM) .114
Annex C (informative) Modelling OPM using OPM .117
Annex D (informative) OPM dynamics and simulation .151
Bibliography .157

v
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out through
ISO technical committees. Each member body interested in a subject for which a technical committee
has been established has the right to be represented on that committee. International organizations,
governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely
with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types
of ISO documents should be noted. This document was drafted in accordance with the editorial rules of the
ISO/IEC Directives, Part 2 (see www.iso.org/directives).
ISO draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). ISO takes no position concerning the evidence, validity or applicability of any claimed patent
rights in respect thereof. As of the date of publication of this document, ISO had not received notice of (a)
patent(s) which may be required to implement this document. However, implementers are cautioned that
this may not represent the latest information, which may be obtained from the patent database available at
www.iso.org/patents. ISO shall not be held responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 184, Automation systems and integration,
Subcommittee SC 5, Interoperability, integration, and architectures for enterprise systems and automation
applications.
This first edition cancels and replaces ISO/PAS 19450:2015, which has been technically revised.
The main changes are as follows:
— document designation from PAS to International Standard (this document);
— clarified several defined terms and added term cross references;
— added introduction statement for all figures and tables;
— clarified use of “may” or “can” as appropriate;
— corrected identified errors in figures and tables.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.

vi
Introduction
Object-Process Methodology (OPM) is a compact conceptual approach, language, and methodology for
modelling and knowledge representation of automation systems. The application of OPM ranges from simple
assemblies of elemental components to complex, multidisciplinary, dynamic systems. OPM is suitable for
implementation and support by tools using information and computer technology. This document specifies
both the language and methodology aspects of OPM in order to establish a common basis for system
architects, designers, and OPM-compliant tool developers to model all kinds of systems.
OPM provides two semantically equivalent modalities of representation for the same model: graphical
and textual. A set of hierarchically structured, interrelated Object-Process-Diagrams (OPDs) constitutes
the graphical model, and a set of automatically generated sentences in a subset of the English language
constitutes the textual model expressed in the Object-Process Language (OPL). In a graphical-visual model,
each OPD consists of OPM elements, depicted as graphical symbols, sometimes with label annotation.
The OPD syntax specifies the consistent and correct ways to manage the arrangement of those graphical
elements. Using OPL, OPM generates the corresponding textual model for each OPD in a manner that retains
the constraints of the graphical model. Since OPL's syntax and semantics are a subset of English natural
language, domain experts easily understand the textual model.
OPM notation supports the conceptual modelling of systems with formal syntax and semantics. This
formality serves as the basis for model-based systems engineering in general, including systems architecting,
engineering, development, life cycle support, communication, and evolution. Furthermore, the domain-
independent nature of OPM opens system modelling to the entire scientific, commercial and industrial
community for developing, investigating and analysing manufacturing and other industrial and business
systems inside their specific application domains, thereby enabling companies to merge and provide for
interoperability of different skills and competencies into a common intuitive yet formal framework.
OPM facilitates a common view of the system under construction, test, integration, and daily maintenance,
providing for working in a multidisciplinary environment. Moreover, using OPM, companies can improve
their overall, big-picture view of the system's functionality, flexibility in assignment of personnel to tasks,
and managing exceptions and error recovery. System specification is extensible for any necessary detail,
encompassing the functional, structural and behavioural aspects of a system.
One particular application of OPM is in the drafting and authoring of technical standards. OPM helps sketch
the implementation of a standard and identify weaknesses in the standard to reduce, thereby significantly
improving the quality of successive drafts. With OPM, even as the model-based text of a system expands to
include more details, the underlying model keeps maintaining its high degree of formality and consistency.
This document provides a baseline for system architects and designers, who can use it to model systems
concisely and effectively. OPM tool vendors can utilise this document as a formal standard specification for
creating software tools to enhance conceptual modelling.
This document provides a presentation of the normative text that follows the Extended Bachus Naur Form
(EBNF) specification of the language syntax. All elements are presented in Clause 6 to 13 with only minimal
reference to methodological aspects, Clause 14 presents the context management mechanisms related to in-
zooming and unfolding.
NOTE OPM is an established modelling paradigm with a 15-year history of use in international commerce. As
such, several conventions for its use and presentation already exist in the literature and practice.
This document uses the presentation conventions for the expression of OPM related constructs found in the originating
and current literature for OPM. Using a different set of conventions, or simply applying the ISO/IEC Directives, Part
2 drafting guidelines for these terms and presentations, creates a discontinuity between this document and the
supporting references and practice, and can cause confusion in application of this document to existing and future
practice.
This document applies the following conventions for the presentation of OPM elements and terminology:
— The phrases and associated abbreviations “Object-Process Methodology (OPM)”, “Object-Process Diagram (OPD)”
and “Object-Process Language (OPL)” are terms of art associated with the OPM paradigm and appear as specified
with the hyphen and capitalization of each word in the phrase.

vii
— In OPD and OPL text, the object name and process name appear in Cambria bold font text with capitalization of
each word to distinguish the object and process from the other OPD and OPL text. The same convention for object
and process name bold capitalization is carried into the text of this document as well to indicate that in the text,
the word or phrase corresponds to an OPM object or process.
— In OPD and OPL text, the object state label and attribute value label appear in Cambria bold font text in lowercase,
and somewhat smaller font in OPD figures, to distinguish the object state label and attribute value label from the
other OPD and OPL text. The same convention for object state label and attribute value label in bold font lowercase
is carried into the text of this document as well to indicate that in the text, the word or phrase corresponds to an
OPM object state label or attribute value label.
— In OPD and OPL text, link tags that are not user-specified appear in Cambria lowercase, and somewhat smaller font
in OPD. Link tags that are user-specified appear as entered by the user in Cambria bold font text, and somewhat
smaller font in OPD.
— In OPL, the first letter of the first word of a sentence is capitalized.
— Some of these conventions are repeated in the text as appropriate to remind the reader of the distinctions. Some
OPD figures contain colour to help distinguish OPM modelling element type distinctions.
Most figures contain both a graphical image, the OPD portion, and a textual equivalent, the OPL portion
of the figure. Because this is a language specification, the precise use of term definitions is essential and
several terms in common use have particular meaning when using OPM. In addition to those listed above as
OPM presentation conventions, Annex B explains other conventions for the use of OPM.
Annex A presents the formal syntax for OPL, in EBNF form.
Annex B presents conventions and patterns commonly used in OPM applications.
Annex C presents aspects of OPM as OPM models.
Annex D summarizes the dynamic and simulation capabilities of OPM.

viii
International Standard ISO 19450:2024(en)
Automation systems and integration — Object-Process
Methodology
1 Scope
This document specifies Object-Process Methodology (OPM) with detail sufficient for enabling practitioners
to utilise the concepts, semantics, and syntax of OPM as a modelling paradigm and language for producing
conceptual models at various extents of detail, and for enabling tool vendors to provide application modelling
products to aid those practitioners.
While this document presents some examples for the use of OPM to improve clarity, it does not attempt to
provide a complete reference for all the possible applications of OPM.
2 Normative references
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
Note 1 to entry To facilitate a term search, terms are in alphabetical sequence.
3.1
abstraction, noun
outcome of an abstraction process (3.2)
3.2
abstraction process
decreasing the extent of detail and system model completeness (3.9) in order to achieve better comprehension
3.3
affectee
transformee (3.79) that is affected by a process (3.59) occurrence, i.e. its state (3.69) changes
Note 1 to entry: An affectee can only be a stateful object. A stateless object can only be created or consumed, but not
affected.
3.4
agent
enabler (3.18) that is a human or a group of humans
3.5
attribute
object (3.40) that characterizes a thing (3.77) other than itself

3.6
behaviour
transformation (3.78) of objects (3.40) resulting from the execution of an Object-Process Methodology (OPM)
(3.44) model comprising a collection of processes (3.59) and links (3.37) to objects in the model
3.7
beneficiary
stakeholder who gains functional value (3.83) from the system's operation (3.47)
3.8
class
collection of things (3.77) with the same perseverance (3.51), essence, and affiliation valuation, and the same
feature (3.22) and state (3.69) set
Note 1 to entry: Perseverance, essence and affiliation are properties of things (see 7.3.3).
3.9
completeness
extent to which all the details of a system are specified in a model
3.10
condition link
procedural link (3.57) from an object (3.40) or object state (3.69) to a process (3.59), denoting a procedural
constraint
3.11
consumee
transformee (3.79) that a process (3.59) occurrence consumes or eliminates
3.12
context
portion of an Object-Process Methodology (OPM) (3.44) model represented by an Object-Process
Diagram (OPD) (3.42) and corresponding Object-Process Language (OPL) (3.43) text
3.13
control link
procedural link (3.57) with additional control semantics
3.14
control modifier
symbol embellishing a link (3.37) to add control semantics to the link, making it a control link (3.13)
Note 1 to entry: The control modifiers are the symbols 'e' for event and 'c' for condition.
3.15
discriminating attribute
attribute (3.5) whose different values (3.82) identify corresponding specialization relations
3.16
effect
change in the state (3.69) of an object (3.40) or the value (3.82) of an attribute (3.5)
Note 1 to entry: An effect only applies to a stateful object.
3.17
element
thing (3.77) or link (3.37)
3.18
enabler
object (3.40) that enables a process (3.59) but which the process does not transform

3.19
event
point in time of creation (or appearance) of an object (3.40), or entrance of an object to a particular
state (3.69), initiating an evaluation of the precondition (3.54)
3.20
event link
control link (3.13) denoting an event (3.19) originating from an object (3.40) or object state (3.69) to a process
(3.59)
3.21
exhibitor
thing (3.77) that exhibits (is characterized by) a feature (3.22) by means of the exhibition-characterization
relation
3.22
feature
attribute (3.5) or operation (3.47)
3.23
folding
abstraction (3.1) achieved by hiding the refineables (3.62) of a refinee (3.63) to which unfolding (3.81) applies
Note 1 to entry: The four kinds of folded refineables are parts (part folding), features (feature folding), specializations
(specialization folding), and instances (instance folding).
Note 2 to entry: Folding is primarily applied to objects. When applied to a process, its subprocesses are unordered,
which is adequate for modelling asynchronous systems, in which processes' temporal order is undefined.
Note 3 to entry: The opposite of folding is unfolding.
3.24
function
process (3.59) that provides functional value (3.83) to a beneficiary (3.7)
3.25
general, noun
refineable (3.62) with specializations
3.26
informatical, adj.
of, or pertaining to informatics, e.g. data, information, knowledge
3.27
inheritance
assignment of Object-Process Methodology (OPM) (3.44) elements (3.17) of a general (3.25) to its specializations
3.28
input link
link (3.37) from object (3.40) source (input) state (3.69) to the transforming process (3.59)
3.29
instance
modelled thing (3.77) that is a refinee (3.63) in a classification-instantiation relation
3.30
instance
actual, uniquely identifiable thing (3.77) that exists during model execution, e.g. during
simulation or runtime implementation
Note 1 to entry: A process instance is identifiable by the operational instances of the involved object set during process
occurrence and the process start and end time stamps of the occurrence.

3.31
instrument
non-human enabler (3.18)
3.32
invocation
initiating of a process (3.59) by a process
3.33
involved object set
union of preprocess object set (3.55) and postprocess object set (3.53)
3.34
in-zoom context
things (3.77) and links (3.37) within the boundary of the thing to which object (3.40) in-zooming (3.35) or
process (3.59) in-zooming (3.36) applies
3.35
in-zooming
object (3.40) part unfolding (3.81) that indicates spatial ordering of the constituent objects
3.36
in-zooming
process (3.59) part unfolding (3.81) that indicates temporal partial ordering of the constituent
processes
3.37
link
graphical expression of a structural relation (3.74) or a procedural relation (3.58) between two Object-Process
Methodology (OPM) (3.44) things (3.77)
3.38
metamodel
model of a modelling language or part of a modelling language
3.39
model fact
relation between two Object-Process Methodology (OPM) (3.44) things (3.77) or states (3.69) in the OPM model
3.40
object
model element (3.17) representing something that does or can exist physically or informatically
(3.26)
3.41
object class
pattern for objects (3.40) that have the same structure (3.75) and pattern of transformation (3.78)
3.42
Object-Process Diagram
OPD
Object-Process Methodology (OPM) (3.44) graphic representation of an OPM model or part of a model, in
which objects (3.40) and processes (3.59) in the universe of interest appear together with the structural links
(3.73) and procedural links (3.57) among them
3.43
Object-Process Language
OPL
subset of English natural language that represents textually the Object-Process Methodology (OPM) (3.44)
model that the Object-Process Diagram (OPD) (3.42) represents graphically

3.44
Object-Process Methodology
OPM
formal language and method for specifying complex, multidisciplinary systems in a single function-
structure-behaviour unifying model that uses a bimodal graphic-text representation of objects (3.40) in the
system and their transformation (3.78) or use by processes (3.59)
3.45
Object-Process Diagram object tree
OPD object tree
tree graph, whose root is an object (3.40), depicting elaboration of the object through refinement (3.64)
3.46
Object-Process Diagram process tree
OPD process tree
tree graph whose root is the System Diagram (SD) (3.76) and each node is an Object-Process Diagram (OPD)
(3.42) obtained by in-zooming (3.36) of a process (3.59) in its ancestor OPD (or the SD) and for which each
directed edge connected to the ancestor OPD process points to the same process in the child OPD
Note 1 to entry: OPM model elaboration usually occurs by process decomposition through in-zooming, therefore the
OPD process tree is the primary way to navigate an OPM model.
3.47
operation
process (3.59) that a thing (3.77) performs, which characterizes the thing other than itself
3.48
output link
link (3.37) from the transforming process (3.59) to the output (destination) state (3.69) of an object (3.40)
3.49
out-zooming
inverse of object (3.40) in-zooming (3.35)
3.50
out-zooming
inverse of process (3.59) in-zooming (3.36)
3.51
perseverance
property (3.61) of thing (3.77) which can be static, defining an object (3.40), or dynamic, defining a process
(3.59)
3.52
postcondition
condition that is the outcome of successful process (3.59) completion
3.53
postprocess object set
collection of objects (3.40) remaining or resulting from process (3.59) completion
Note 1 to entry: The postprocess object set can include stateful objects, for which specific states result from process
performance.
3.54
precondition
condition for starting a process (3.59)

3.55
preprocess object set
collection of objects (3.40) to evaluate prior to starting a process (3.59)
Note 1 to entry: The collection of the objects can include stateful objects for which specific states are necessary for
process performance.
3.56
primary essence
essence of the majority of things (3.77) in a system
Note 1 to entry: Essence pertains to the physical or informatical nature of a thing (see 7.3.3).
3.57
procedural link
graphical notation of procedural relation (3.58) in Object-Process Methodology (OPM) (3.44)
3.58
procedural relation
connection or association between an object (3.40) or object state (3.69) and a process (3.59)
Note 1 to entry: Procedural relations specify how the system operates to attain its function, designating time-
dependent or conditional initiating of processes that transform objects.
Note 2 to entry: An invocation or exception link signifies a transient object in the flow of execution control between
two processes.
3.59
process
transformation (3.78) of one or more objects (3.40) in the system
3.60
process class
pattern for processes (3.59) that perform the same object (3.40) transformation (3.78) pattern
3.61
property
modelling annotation common to all elements (3.17) of a specific kind that serve to distinguish that element
Note 1 to entry: Cardinality constraints, path labels, and structural link tags are frequent property annotations.
Note 2 to entry: Unlike an attribute, the value of a property cannot change during model simulation or operational
implementation. Each kind of element has its own set of properties.
Note 3 to entry: Property is an attribute of an element in the OPM metamodel.
3.62
refineable, noun
thing (3.77) amenable to refinement (3.64)
Note 1 to entry: A refineable can be a whole, an exhibitor, a general, or a class.
3.63
refinee
thing (3.77) that refines a refineable (3.62),
Note 1 to entry: A refinee can be a part, a feature, a specialization, or an instance.
Note 2 to entry: Each of the four kinds of refinees has a corresponding refineable (part-whole, feature-exhibitor,
specialization-generalization, instance-class).
3.64
refinement
elaboration that increases the extent of detail and the consequent model completeness (3.9)

3.65
resultee
transformee (3.75) that a process (3.59) occurrence creates
3.66
stakeholder
individual, organization, or group of people that has an interest in, or can be affected by, the system
being contemplated, developed, or deployed
3.67
stateful object
object (3.40) with specified states (3.69)
3.68
sta
...