Iec 62656 5 2017

Ide l y, an ontolog of activities model ed by this International Stan ard mu t b expres ible by a n mb r of existin gra hical presentation to ls an proces des ription lan uages f or acti

Terms and definitions

For the purpose of this document, the terms and definitions given in ISO 1 3584-24 and IEC 62656-1 , as well as the following apply

ISO and IEC maintain terminological databases for use in standardization at the following addresses:

• IEC Electropedia: available at http://www.electropedia.org/

• ISO Online browsing platform: available at http://www.iso.org/obp

3.1 1 activity organizational, logical or conceptual unit for performing a set of specific actions or functionalities

An activity may serve a single action or functionality, and in some cases, it may represent an endpoint that signifies the termination of activities without performing any action.

Note 2 to entry: An activity is not necessarily a process in time sequence in the PAM Two or more activities may concurrently work and interact with each other

Arrow mapping facilitates the transfer of information and physical items between different categories, representing a change of states or a directional correspondence This process is embodied as a functional relation, illustrating the dynamic connections between various collections of things.

In the context of IEC 62656, an "arrow" represents a mathematical entity derived from category theory, functioning similarly to a function It establishes a directional mapping from a specified collection known as the "domain" to another collection referred to as the "codomain."

Note 2 to entry: Arrows can also be used in a formula, such as in :

 where an arrow exists as the mapping F from an n- ary set

3.1 3 arrow overloading specialization of an arrow by narrowing or detailing either one of or both of the domain and codomain of the arrow, being considered as a function

Note 1 to entry: Overloading of an arrow typically takes place on the frame boundary of a diagram in a lower node of an activity

3.1 4 aspect way things appear, are looked at or expressed as an association among properties, classes, or ontological elements in general, by the use of a relation

Note 1 to entry: A property may belong to one or several aspects

3.1 5 branching point forking point point from which an arrow forks out into two or more arrows

3.1 6 connection point point at which arrows or lines fork out, or at which several arrows or lines meet each other

Note 1 to entry: Both branching point and junction points are included in the connection points

Integration Definition for Function Modelling graphical language to model decisions, actions, and activities of an organization or system, defined in the IDEF series of data modelling methods

I DEF0 was previously recognized as Federal Information Processing Standard (FIPS) 183 by the American National Standards Institute (ANSI) However, it was withdrawn from FIPS in 2012, as it is no longer essential to designate a single method as the exclusive graphical language for modeling activities.

Note 2 to entry: This note applies to the French language only

3.1 8 ontology shared and formal modelling of knowledge about a domain

The POM formal specification defines the concept of "being" by detailing the state and configuration of entities through their properties and relationships This is organized into a set of relational tables, with each table representing a distinct category of ontological entities.

Note 1 to entry: Parcellized ontology model is formally specified in IEC 62656-1

Note 2 to entry: Examples of the categories of the ontological entities are class, property, relation, datatype, unit of measurement, etc., which are essential constructs for the description of being

PAM specialized use of the parcellized ontology model defined in IEC 62656-1 for representing an activity as part of an ontology

Note 1 to entry: This note applies to the French language only

3.1 1 1 service activity performed or being performed for the purpose of someone or something

Note 1 to entry: Usually an activity is performed else than for oneself or for itself

3.1 1 2 subactivity subcomponent of an activity

An activity can be divided into multiple subactivities, which may represent either diachronical or synchronical divisions For instance, in a collaborative project, various task forces within an enterprise can work together, each focusing on different aspects of the overall activity.

3.1 1 3 transcendent arrow arrow that enters into an activity and interacts with some or all of its subactivities

Note 1 to entry: A transcendent arrow may be forking into multiple arrows or joining another in a lower node frame.

Abbreviations

For the purposes of this document, the following abbreviations apply

BPML Business Process Modelling Language

BPEL Business Process Execution Language

BPMN Business Process Modelling Notation

Activity described as an ontology

Ontology is a formal specification of conceptualization within a domain, and activities are integral to this framework Each activity typically has a clear objective, methods for achieving it, involved parties, time constraints, financial considerations, and specific requirements Activities are interconnected, often relating to prior or subsequent activities through the exchange of information, goods, or materials They may also encompass subactivities that contribute to the main objective Additionally, recurring patterns of activities can be modeled and instantiated Activities often involve collaboration across diverse languages and cultures, highlighting the need for a shared understanding of these processes on an international scale.

– 1 0 – IEC 62656-5:201 7 © IEC 201 7 normalized manner with their identification, canonical properties and concepts being expressed in a machine sensible way

The parcellized activity model (PAM) is a specialized application of the parcellized ontology model (POM) as defined in IEC 62656-1 It is designed to model activities and their interactions, utilizing the data structure established by this standard.

The Process Activity Model (PAM) represents activities through classes and captures the flow of information, goods, and materials via functional relations, distinguishing it from other models that only facilitate information exchange Unlike graphical presentation languages such as BPML, BPEL, and BPMN, PAM is not designed for flow charts or algorithmic diagrams; instead, it aims to establish a shared understanding of activity characteristics and their interrelations as metadata in a standard ontology format This metadata should be translatable and graphically representable in at least one graphical language, with IDEF0 chosen for primary translation PAM serves to coordinate the ontologies of products, services, and activities, necessitating alignment with the IEC's common metadata registry, specifically the IEC 61360-4 database, also known as the Common Data Dictionary (CDD), which is supported by the Parcel series of standards for input and output interfaces.

Use cases and key technical concepts 1 0

This document primarily applies to engineering but also plays a crucial role in various industrial sectors such as process automation, agriculture, fishery, hazard prevention, jurisdiction, defense, transportation, medicine, nursery, and tourism While specialized engineering activities may only be understood by a select group of experts, experiences like visiting an art museum resonate with a broader audience For instance, the activity of "seeing fine arts at a museum" serves as an accessible example, as many readers have likely visited museums to appreciate different art genres in diverse cultural settings Additionally, we present a use case related to process automation, specifically an ontological description of enterprise-control system integration activities as outlined in IEC 62264-3, which is recognized as a foundational element of smart manufacturing.

Figure 1 demonstrates the modeling of the touristic activity "See fine arts at museum" as an ontology, featuring two hierarchical structures: a specialization tree, indicated by a small open triangle, and a composition tree, represented by a black diamond The specialization hierarchy allows properties of the generic activity, such as "language(s) for arts description," "admission fee," "open hours," and "genres of arts," to be inherited by specialized activities like "see fine arts at American museum," "see fine arts at French museum," and "see fine arts at Japanese museum."

Experience fine arts at prestigious museums, whether it's the world-famous Musée du Louvre or Musée d'Orsay in France, or a curated selection of artworks at a local museum in Japan.

IEC 62656-5:2017 outlines a generic activity model for experiencing fine arts in museums, highlighting that while the parametric values may vary, the fundamental components remain consistent across different specialized activities Each museum visit typically requires a ticket for admission, followed by a sequential exploration of art halls, culminating in an exit from one of the halls It is important to note that the arrows in the diagram indicate the flow of visitors between activities rather than a linear sequence of actions for an individual.

Figure 2 illustrates standardized industrial activities based on IEC 62264-3, represented through a Data Flow Diagram (DFD) Figure 3, aligned with the PAM specification per IEC 62656-5, corresponds to Figure 2 in IDEF0 format IEC 62264-3 suggests that all manufacturing production activities can follow the model in Figure 2, with each specialized manufacturing process explained through a variation of the diagram It is important to clarify that this use case does not imply that IEC 62264-3 content can be replaced by PAM functionality; rather, a significant portion of its semantic content can be transformed into ontology data, stored, and maintained in IEC CDD via PAM, facilitating interaction with related product definitions Additionally, internal communication flows, such as operational commands shown in Figure 2, are omitted from Figure 3, as they will be detailed when "Production execution management" (A5) is expanded into subactivities in PAM Since PAM is not a graphic presentation language, the figures are generated by tools interpreting ontology data according to IEC 62656-5 Annex C includes sample data corresponding to Figure 3 and showcases auto-generated figures from PAM in Figures C.4 and C.5.

Figure 1 – See fine arts at Museum

Figure 2 – Production operations management (extracted from IEC 62264-3)

Figure 3 – Production operations management modelled in PAM and depicted as IDEF-0 diagram

Relation among properties of different activities 1 4

Activities are modeled as classes with properties, leading to various types of relations among activities and their properties Some relations are directed, indicating a flow from a source to a destination, which can include multiple activities, while others are non-directional The IDEF0 framework illustrates these flows but does not impose additional constraints on the properties of the source and destination, representing directed relations through functional relations and non-directional ones through predicative relations, as defined in IEC 62656-1 However, there are instances where further specification of constraints among properties is necessary, and the method for integrating this detailed relation with a flow relation is outlined in section 5.1 3.

International Concept Identifier (ICID) 1 4

The International Concept Identifier (ICID), as defined in IEC 62656-1, is a specialized form of the International Registration Data Identifier (IRDI) outlined in ISO/IEC 11179-6 The primary distinction between the two lies in the choice of separator characters used within the identifier sequence, which includes the Registration Authority Identifier (RAI), the Data Identifier (DI), and the Version Identifier (VI) Specifically, the ICID employs pound signs “#” to denote separations among these components For further details, refer to IEC 62656-1.

The ICID format consists of the Registration Authority Identifier (RAI), Data Identifier (DI), Version Identifier (VI), and a character string known as "NOTE," which contains no "#" symbols and provides user annotations Traditionally, the RAI has been referred to as the "information supplier."

“data supplier” or more simply “supplier” in an old IEC 61 360-2 and ISO 1 3584-42 vocabulary

In the context of the POM, the RAI and VI are typically set by the instructions “#DEFAULT_SUPPLIER” and “#DEFAULT_VERSION” in the header, and “#DEFAULT_DATA_SUPPLIER” and “#DEFAULT_DATA_VERSION” in the data section of a Parcel sheet Therefore, RAI and VI are considered predefined defaults in the header of each parcel sheet For further details on using these default parameters, refer to IEC 62656-2.

The implementation of ICID enables the explanation of a sequence of activities in multiple languages, utilizing a language-independent global ID that is fully version controlled This approach enhances the sharing and updating of knowledge related to activities, leading to reduced confusion and more informed decision-making among users This capability is particularly crucial for the database maintenance of industrial ontologies For further information, refer to IEC 62656-3 Additionally, as illustrated in Figure 2, each subcomponent of the generic activity "to see fine arts at museum" can possess both a specialization tree and a composition tree, the latter consisting of its subcomponents.

5 Basic structure of the PAM

Activity and arrows 1 4

An activity can be represented as a class with various characteristic properties For instance, when maintaining the coolant temperature in a reactor cooling system, the temperature range of the coolant is a crucial property Additionally, the "flow rate of the coolant" is another important characteristic These properties can either be defined as inherent characteristics of the activity or imported from a product class, such as the reactor cooling system, which must be registered as a component class in IEC 61360 CDD Typically, an activity's properties may include several status properties that detail the conditions of the activity.

An arrow symbolizes the flow of information or materials between activities, including the movement of people This flow is modeled as a function, which can be instantiated as specific arrows within the relation meta-class (MDC_C01 1) in the POM As a specialization of a relation, a function possesses both a domain and a codomain (range).

A function is defined as an arrow that maps instances from a specified source activity to an instance in a designated destination activity To clarify this relationship, the function's attribute, known as the "role of the relation" (MDC_P21 0), must be assigned a predefined value.

In the relation meta-class, the function is defined by designating the source activity or set of activities in an attribute called "domain of the function" (MDC_P202), while the destination activity represented by an arrow is identified in an attribute named "codomain of the function" (MDC_P203).

Subactivities 1 5

General 1 5

The POM features two hierarchical structures: the "specialization tree" and the "composition tree." The PAM serves as a specialized application of the POM, specifically designed to model a collection of phenomena referred to as activities, thereby inheriting the fundamental hierarchical structures of the POM.

Specialized activity 1 5

Activities can be categorized into a hierarchy of specialization, similar to product classifications outlined in IEC 61 360 CDD For instance, the activity of "designing products" serves as a broader concept compared to the more specific "designing electro-technical products," which in turn is more general than "designing electric motors." This hierarchy reflects the distinct characteristics that define specialized activities at different levels within the classification tree.

Component activity 1 5

An activity can consist of multiple sub-components, referred to as “component-activities,” “child activities,” or “subactivities” according to this International Standard In contrast, an activity that includes these sub-components is identified as having a hierarchical structure.

A composite activity, also known as a parent activity, encompasses its subcomponents, which are referred to as child activities The term "super-activity" is avoided to prevent confusion with superclass terminology In this context, a component activity is part of the parent activity rather than a specialization of it This "part-of" relationship, termed composition in POM terminology, is conceptualized as "is-composed-of" and is realized through class reference type properties The selective inheritance of flows to a subactivity is established in PAM via an "is-case-of" relationship, as defined in the IEC 61360-2/ISO 13584-42 common data model While a component activity may inherit some characteristics from its parent, it is important to note that a child activity, or subactivity, represents a decomposition of the parent rather than a specialization This relationship is illustrated in Figure 4, where both a subcomponent and its parent are modeled as a class named "activity," with components linked through the "is composed of" attribute and arrows imported via the "is case of" attribute The term "superclass" is used strictly to denote an "is-a" relationship, distinguishing it from the "is_composed_of" (part-of) relationship.

Figure 4 – Basic activity and its subcomponents

ICOM representation 1 6

In IDEF0, flows entering an activity are classified into three types: input (I), control (C), and mechanism (M), while all flows exiting an activity are categorized as output (O) This classification system is referred to as "ICOM," which represents the initial letters of the four groups In an IDEF0 diagram, each flow type is designated to enter or exit an activity from specific sides: inputs come from the front, control signals from the top, mechanisms from the bottom, and outputs from the rear This structured labeling is essential for accurately modeling the distinctions within the activity.

In the context of the relation parcel, the attribute "segment" (MDC_P21 1) is associated with labels such as "control," "output," and "mechanism." The distinction between a flow labeled as "input" and one labeled as "control" is nuanced; the latter represents a flow of information that establishes consistent criteria for an activity's actions or imposes constraints that influence the output In a business setting, this often manifests as management oversight or due diligence checks Additionally, the label "connectivity" denotes a connection point of arrows at the frame boundaries of an activity, with further elaboration provided in section 5.1 0.4.

Role of the mechanism (M) in the PAM 1 6

Before delving into the specifications of a parcel sheet conforming to the PAM, it is essential to understand the role of the mechanism (M) in integrating various ontologies Unlike UML activity diagrams, IDEF0 activities can detail the natural or industrial environments surrounding them, as indicated by the flows entering from the mechanism side specified in the “segment.” The PAM not only provides a functional description of the process from input to output but also specifies the contextual environment in which the activity occurs This is significant because PAM activities encompass not only the flow of information but also the flow of physical and human resources For instance, in a semiconductor chip factory, a facility must take base semiconductive material as input and transform it into semiconductor chips, all while being overseen by process engineers and managers.

In semiconductor production, certain elements are essential as a supportive environment rather than as inputs or outputs, as they do not consume, transform, or diminish resources These elements are classified as Mechanism in IDEF0 terminology In contrast, the IEC CDD typically categorizes these means as product classes Therefore, the Process Activity Model (PAM) effectively distinguishes between input, output, control, and mechanism, facilitating the integration of product classes, material classes, activities, and their interactions within an enterprise.

External function call 1 7

The "call" arrow in an IDEF 0 diagram, which typically points downward from an activity to indicate an external function, is not utilized in the PAM as it refers to functions outside the diagram that may not be included in the IEC CDD ontology Instead, it is represented as a dotted arrow in Figure 6, which can be substituted with a functional relation sharing the same name as the originating activity The term "call" is specifically reserved for linking to external functions, such as those provided by an operating system, indicating that these functions are not owned by the activity itself Consequently, while the call arrow will not appear in PAM-generated figures, the external function must be identifiable within a parcel Specifications for the call arrow can be provided similarly to other arrows, but it must be marked "call" with the attribute code MDC_P21 1 and named "segment." Although the call arrow does not need to be visually represented in the output of a parcel tool, it should reference an external function when invoked, with the implementation of the reference mechanism left to the tool's developer Importantly, the definition of the external function is platform-dependent and cannot be stored in the IEC CDD.

Basic PAM notation with function symbols 1 7

In the PAM, arrows are represented as functions identified by their relation IDs For clarity, function IDs are italicized in this context, but in the actual specification on parcel sheets, they will appear as f1, f2, f3, or F1, F2, F3, and similarly, A1, A2, A3 will be used for arrows A1, A2, A3.

In our analysis, we prefer to represent the interaction of arrows in a more straightforward manner Instead of using the complex notation \( f(A_1) + f(A_2) \rightarrow A_3 \), we simplify it to \( f(A_1, A_2) \rightarrow A_3 \) This notation clearly indicates that the arrow \( f \) maps the two activities \( A_1 \) and \( A_2 \) from the domain to the codomain \( A_3 \), regardless of how the arrows from \( A_1 \) and \( A_2 \) converge.

In graphics, two arrows, A 2, converge at a point before reaching A 3 and transform into another arrow, denoted as f This transformation is detailed in the parcel under the row labeled "G3" in the attribute "code" (MDC_P001_1 3) found in Table 1.

If the function \( g \) maps \( A_1 \) to both \( A_2 \) and \( A_3 \), indicated by \( g(A_1) \rightarrow A_2 \) and \( g(A_1) \rightarrow A_3 \), this forking of the arrow \( g \) into \( g_2 \) and \( g_3 \) must be clearly represented as a connectivity in the "segment" attribute (MDC_P21 1).

In the table below, it is assumed that arrows f , 3 g and 2 g all enter into activities as their 3 inputs

Table 1 – Basic PAM notation for arrows

MDC_P001 _1 3 MDC_P004_1 en MDC_P202 MDC_P203 MDC_P21 0 MDC_P21 1

Code Preferred name Domain of the function Codomain of the function Role Segment

F3 Material for report {A1 , A2} A3 arrow input

Figure 5 – Corresponding IDEF0 diagram for basic PAM notation

Figure 6 – Sample activity drawing in IDEF0 and ICOM

Joining arrows

The joining of arrows indicates that multiple source activities direct their outputs to a single target activity, with all arrows sharing the same codomain If arrows appear to overlap at the target, it is merely a coincidence in the graphical representation, as they are distinct by definition.

In this scenario, let \( f_1 \), \( f_2 \), and \( f \) represent the identifiers of arrows, while \( A_1 \), \( A_2 \), and \( A_3 \) denote the identifiers of three activities Arrows \( f \) and \( f_1 \) originate from activities \( A_2 \) and \( A_1 \), respectively, and converge into arrow \( f \), which leads to activity \( A_3 \) The presence of arrows \( f_3 \) and \( f \) joining into arrow \( f \) indicates that \( f_3 \) encompasses both arrows \( f \) and \( f_1 \) within the "domain of the function."

(MDC_P202) of the f arrow This may be represented as follows: 3

3( ( )1 1 2( ))2 3 f f A + f A → A , where the summation operator “+” must be understood such that the resulting instances from

1( )1 f A and f A 2 ( ) 2 are added as rows of instances in the domain of the function f 3

A simpler method to achieve the same outcome involves using A and 1 A as the domain of a function 2 f, without directly referencing the functions f 1 and f This approach allows users to define only 2 f, eliminating the need to specify 2 f 1 and f.

IEC 62656-5:2017 emphasizes the importance of being mindful of an arrow's final destination when it is drawn However, it is common to overlook the connections with other arrows that should be joined.

Forking arrows

An arrow can split into multiple branches at one or more midpoints, with each branch leading to a distinct activity at the end The identifiers for these arrows are represented as \( f_4, f, \) and \( f_5 \), while \( A \) and \( 1 \) denote additional elements in this context.

In this scenario, we consider activities A and 2A The arrow 3f4 splits into two arrows, f5 and f6, which correspondingly lead to activities A and 2A This bifurcation can be interpreted as two separate composite functions.

The above functions are simply achieved by describing the code of the arrow f in the 4 attribute “domain of the function” of both f 5 and f , respectively, in the PAM 6

Branching or joining of arrows

In IDEF0 diagrams, branching, joining, or connection points of arrows are not explicitly represented as distinct points or graphically indicated In contrast, other graphical modeling languages for activities do explicitly model these branching and joining elements.

Subactivities do not inherit arrows from their parent node; instead, the frame directly below the parent node contains all incoming and outgoing arrows associated with it This means that the area within the frame represents the subactivities of the parent activity For instance, in Figure 7, the frame labeled “Node:A0” illustrates the interactions among activities A1 to A4 within activity A0, with all relevant arrows depicted in Figure 6 appearing within this rectangular frame For additional clarification, refer to Figures 10 and 11 The primed IDs of arrows in Figure 11 will be explained later.

Figure 1 0 – Transcendental arrows to be taken over by child nodes

Figure 1 1 – Transcendental arrows from the parent node

In the activity box depicted in Figure 1, arrows f and 1 f enter from the input side and emerge as f 1 ′ and f 2 ′ from the corresponding side of the rectangular frame A in Figure 1 1 Similarly, the arrow 0 f enters from the control side and transforms into f 3 ′ directed towards activity A within the rectangular frame The arrow 1 f, entering from the mechanism side, extends upward as f 4 ′ and bifurcates to reach activities A and 1 A as arrows 2 f 4a ′ and f 4b ′ The outgoing arrow from the output side of activity A in Figure 1 0 appears as f 5 ′ from the output side of box A in Figure 1 1 Additionally, a new arrow f 6 is created in node A0 2 to connect activities A and 1 A.

Modeling incoming arrows in the PAM involves accurately representing forking, joining, and transcendent arrows as relations or functions It is essential that all arrow types are depicted as functions at the boundary of the activity box, where arrows enter through one of three sides: Input, Control, or Mechanism, with no arrows entering from the Output side Additionally, the arrow \( f \) extends from activity 2.

The relationship between activities A−0 and A is illustrated by the arrows f and f′, indicating that their domains and codomains are distinct yet interconnected Similarly, the arrow f connects activity A−0 to A, while f′ connects A to 0A This pattern continues with arrow f linking activity A−0 to A, and f′ extending from A to both 0A and 1A, bifurcating into two distinct arrows, f′a and f′b Consequently, these relationships must be represented as separate mathematical functions Table 2 summarizes this relationship, with codes AM0, A0, A1, and A2 representing A−0, A, 0A, and 1A, respectively.

Modeling outgoing arrows in the PAM requires accurately representing forking, joining, and transcendent arrows as relations or functions Unlike incoming arrows, outgoing arrows always originate from the Output side of an activity box and connect to other activities through one of the Input, Control, or Output channels.

The mechanism on one side of the box leads to the output side of the frame, ultimately resulting in an exit from the frame For instance, in Figure 1, arrow \( f \) illustrates this initial scenario, while arrow \( 6 f 5' \) represents the latter case, where arrow \( f 6 \) originates from the output side of the activity.

The input side of activity A is represented by A, while the output side emits the arrow 2 f 5 ′, which connects to the corresponding frame within the output of activity A− 0 The PAM representation of these outgoing arrows is detailed in Table 2, specifically in the rows for f and 5 f 5 ′, identified by the codes F0005 and F0015, respectively.

5.1 0.4 Modelling connections of arrows at frame boundary

In Table 2, the domains of the functions \( f_1' \), \( f_2' \), \( f_3' \), and \( f_4' \) are specified as \( f \), \( 2f \), and \( 3f \) rather than \( A_0 \), indicating that these domains are the codomains of the functions \( f \), \( f_1 \), \( f_2 \), and \( f_3 \) Similarly, the codomain of the function \( f_5' \) is designated as \( f \) to show that it overwrites the domain of \( f \) This does not require changing the codomains of the original functions, as the sub-node functions \( f_1' \), \( f_2' \), \( f_3' \), and \( f_4' \) were not determined at the time of designing \( f \), \( f_1 \), \( f_2 \), and \( f_3 \) Consequently, the domain of \( f \) does not need to be rewritten as \( 5f \) since \( 5f \) is not known at node \( A_0 \) In practical notation within the PAM, the activity identifiers in curly brackets next to a function ID can be omitted in the domain and codomain columns.

An arrow within the code frame Ak (where k = -0, 0, 1) must originate from either the activity Ak or one of its subactivities If the arrow is transcendent, it comes from an upper node; if it emanates from an activity, it does so from the output side For clarification on the appearance of arrows, refer to the “Definition class” (MDC_P021).

The values in the "Definition class" (MDC_P021) defined in IEC 62656-1 are crucial for the POM, with the attribute marked as "key" for its requirement (MMDC_P102) These values serve as the "frame of the arrow" in IEC 62656, aiding in the comprehension of activity layouts similar to IDEF0 Suppliers of a dictionary (ontology) for a set of activities are responsible for defining these values, which are instrumental for users and applications in understanding and implementing the tree structure formed by the activities and arrows.

Table 2 – Extracts of relation meta-class definitions for activities

#Preferred name Symbols in the figures CODE Domain of the function Codomain of the function Definition class b

The article discusses various property IDs, including MDC_P001, MDC_P202, and PDC_P021, along with their associated attributes and definitions It highlights that "AM0" refers to "A-0," indicating the exterior of Activity A0, which is represented as the frame for the activity box Additionally, it notes that the "Definition class" (MDC_P021) is a meta-property derived from IEC 62656-1, emphasizing its significance in the context of property identification.

The "frame of the arrow" in IEC 62656 aids in comprehending the layout of activities within an IDEF0-like diagram The supplier of a dictionary (ontology) must define the value of these activities, which can enhance the understanding of the tree structure created by the activities and arrows It is important to note that AM0, A0, A1, and similar notations are used in the "Domain of the function."

The terms "Codomain of the function" and "Definition class" do not represent the actual codes for activities as defined by the attribute MDC_P001_5 Instead, they are simplified labels that are identical to activity IDs typically generated dynamically by a graphical tool.

5.1 0.5 Contracted form of representation for branching and joining arrows

Table 3 illustrates a simplified connectivity between an arrow \( f \) and two forking arrows \( f 4a' \) and \( f 4b' \), with bold letters denoting the codes of the affected arrows Specifically, \( f (F0004) \) is directly linked to \( f 4a' (FA014) \) and \( f 4b' (FB014) \) without the need for an intermediary arrow \( f 4' (F0014) \) This connection is established by designating \( f (F0004) \) as the domain for both \( f 4a' \) and \( f 4b' \) The remaining rows in the table remain unchanged Importantly, the existence of \( f 4' (F0014) \) does not impact the mathematical specification of the forking arrows, as \( f 4' \) is equivalent to \( f \), allowing for direct forking from \( f 4 \) into \( f 4a' \) and \( f 4b' \) at the frame boundary.

5.1 0.6 Domain or codomain overloading for transcendent arrows

General

This annex outlines the essential meta-properties for activity descriptions, emphasizing that the function's domain (MDC_P202) and codomain (MDC_P203) are mandatory for arrow descriptions as specified in IEC 62656.

List of meta-properties

Table A.1 outlines the meta-properties of the relation meta-class specified in the POM, which can be utilized to describe the connections between activities As the POM is fully defined in IEC 62656-1, this document focuses solely on establishing an interface for the reuse of these meta-properties.

Table A.1 – Meta-properties of relation meta-class used for activity description (1 of 2)

MMDC_P001 MMDC_P1 02 MMDC_P004_1 EN MMDC_P004_1 FR MMDC_P008 MMDC_P01 3

Property ID Requirement Preferred name in English Preferred name in French Data type Version number

Identificateur de propriộtộ Exigence Nom prộfộrentiel en Anglais Nom prộfộrentiel en Franỗais Type de donnộes Numộro de version

MDC_P001 _1 3 KEY Code Code ICID_STRI NG 001

MDC_P002_1 KEY Version number Numéro de version STRING_TYPE 001

MDC_P002_2. MAND Revision number Numéro de révision STRING_TYPE 001

MDC_P003_1 MAND Date of original definition Date de la définition originale STRING_TYPE 001

MDC_P003_2 MAND Date of current version Date de la version actuelle STRING_TYPE 001

OPT Date of current revision Date de la révision actuelle STRING_TYPE 001

MAND Preferred name Nom préférentiel TRANSLATABLE_STRI NG_TYPE 001

MDC_P004_2 OPT Synonymous name Nom synonyme SET(0,?) OF LIST(2, 2) OF

OPT Short name Nom abrégé TRANSLATABLE_STRI NG_TYPE 001

MDC_P004_4 OPT Name icon Icône de nom STRING_TYPE 001

MAND Definition Définition TRANSLATABLE_STRI NG_TYPE 001

MDC_P006_1 OPT Source document of definition Document source de définition STRING_TYPE 001

OPT Note Note TRANSLATABLE_STRI NG_TYPE 001

OPT Remark Remarque TRANSLATABLE_STRI NG_TYPE 001

MDC_P008_2 OPT Graphics Graphisme STRING_TYPE 001

MDC_P008_3 OPT Graphic Properties Propriétés graphiques LIST OF ICID_STRING 001

MMDC_P001 MMDC_P1 02 MMDC_P004_1 EN MMDC_P004_1 FR MMDC_P008 MMDC_P01 3

Property ID Requirement Preferred name in English Preferred name in French Data type Version number

Identificateur de propriộtộ Exigence Nom prộfộrentiel en Anglais Nom prộfộrentiel en Franỗais Type de donnộes Numộro de version

MDC_P021 KEY Definition Class Classe de définition STRING_TYPE 001

MDC_P1 1 2 OPT Description Description TRANSLATABLE_STRI NG_TYPE 001

MDC_P1 1 3 OPT Example Exemple STRING / LIST OF STRING 001

MDC_P200 MAND Relation type Type de relation STRING_TYPE 001

MDC_P201 OPT Domain of the relation Domaine de la relation LIST OF ICID_STRING 001

MDC_P202 MAND Domain of the function Domaine de la fonction LIST OF ICID_STRING 001

MDC_P203 MAND Codomain of the function Co-domaine de la fonction ICID_STRI NG 001

MDC_P204 OPT Formula Formule STRING_TYPE 001

MDC_P205 OPT Language for formula interpretation Langage pour l’interprétation de la formule STRING_TYPE 001

MDC_P206 OPT External solver for the formula Résolveur externe pour la formule STRING_TYPE 001

MDC_P207 OPT Trigger event Déclencheur d’événement STRING_TYPE 001

MDC_P208 OPT Domain element type Type d’élément de domaine STRING_TYPE 001

MDC_P209 OPT Codomain element type Type d’élément de co-domaine STRING_TYPE 001

MDC_P21 0 OPT Role of the relation Rôle de la relation STRING_TYPE 001

MDC_P21 1 OPT Segment Segment LIST OF STRING 001

MDC_P21 2 OPT Super relation Super-relation ICID_STRI NG 001

Annex B (informative) Description examples for the PAM

Design product

This article provides an example of a Process Activity Model (PAM) for a fictional activity called "design product." It includes IDEF0-like graphical representations that are automatically generated from a prototype tool, which evaluates the data model outlined in this International Standard These images can be found in Clause B.2 and Figures B.4 and B.5.

In the example provided, the activity codes (MDC_P001_5) coincidentally match the activity numbers This alignment is intended for ease of data preparation and is not a requirement within the PAM framework.

#PROPERTY_I D MDC_P001 _5 MDC_P004_1 en MDC_P01 0 MDC_P01 4 MDC_P221

#PROPERTY_NAME.en Code Prefered_name Superclass Applicable properties Segment

#DATATYPE STRING_TYPE STRING_TYPE STRING_TYPE STRING_TYPE STRING_TYPE

A0 Desigin product UNIVERSE {CAE001 , CAE002, CAE003} Activity

A1 Plan product {CAE01 1 ,CAE01 2, CAE01 3,CAE01 4, CAE01 5} Activity

A2 Do specification {CAE021 ,CAE022, CAE023,CAE024, CAE025} Activity

A3 Review spec {CAE031 ,CAE032, CAE033,CAE034, CAE035} Activity

A4 Authorize design {CAE041 ,CAE042, CAE043 } Activity

Figure B.1 – Class meta-class example of the PAM for “design product” activity (1 of 2)

#PROPERTY_I D MDC_P001 _5 MDC_P004_1 en MDC_P01 0 MDC_P01 4 MDC_P221

#PROPERTY_NAME.en Code Prefered_name Superclass Applicable properties Segment

#DATATYPE STRING_TYPE STRING_TYPE STRING_TYPE STRING_TYPE STRING_TYPE

A22 Gather data for spec Activity

A32 Show spec for review Activity

Figure B.2 – Property meta-class example of the PAM for “design product” activity (1 of 2)

#PROPERTY_I D MDC_P001 _6 MDC_P004_1 en MDC_P022

#PROPERTY_NAME.en Code Preferred name Data type

#DATATYPE STRING_TYPE TRANSLATABLE_STRI NG STRING_TYPE

#REQUI REMENT KEY MAND MAND

CAE001 Plan product CLASS_REFERENCE_TYPE(A1 )

CAE002 Do specification CLASS_REFERENCE_TYPE(A2)

CAE003 Review specification CLASS_REFERENCE_TYPE(A3)

CAE004 Authorize desigin CLASS_REFERENCE_TYPE(A4)

CAE01 1 Clarify requirement CLASS_REFERENCE_TYPE(A1 1 )

CAE01 2 Set required specification CLASS_REFERENCE_TYPE(A1 2)

CAE01 3 Schedule product design CLASS_REFERENCE_TYPE(A1 3)

CAE01 4 Estimate rough cost CLASS_REFERENCE_TYPE(A1 4)

CAE01 5 Set product concept CLASS_REFERENCE_TYPE(A1 5)

#PROPERTY_I D MDC_P001 _6 MDC_P004_1 en MDC_P022

#PROPERTY_NAME.en Code Preferred name Data type

#DATATYPE STRING_TYPE TRANSLATABLE_STRI NG STRING_TYPE

CAE021 Plan specification CLASS_REFERENCE_TYPE(A21 )

CAE022 Gather data for spec CLASS_REFERENCE_TYPE(A22)

CAE023 Set spec CLASS_REFERENCE_TYPE(A23)

CAE024 Check errors CLASS_REFERENCE_TYPE(A24)

CAE025 Provide resource CLASS_REFERENCE_TYPE(A25)

CAE031 Plan review CLASS_REFERENCE_TYPE(A31 )

CAE032 Show spec for review CLASS_REFERENCE_TYPE(A32)

CAE033 Exchange comments CLASS_REFERENCE_TYPE(A33)

CAE034 Advisory comments CLASS_REFERENCE_TYPE(A34)

CAE035 Compile report CLASS_REFERENCE_TYPE(A35)

CAE041 Request authorization CLASS_REFERENCE_TYPE(A41 )

CAE042 Authorize specification CLASS_REFERENCE_TYPE(A42)

CAE043 Publish design CLASS_REFERENCE_TYPE(A43)

#PROPERTY_I D MDC_P001 _1 3 MDC_P004_1 en MDC_P200 MDC_P202 MDC_P203 MDC_P21 0 MDC_P21 1

#PROPERTY_NAME.en Code Preferred name Relation type Domain of the function Codomain of the funciton Role of relation Segment

#DATATYPE STRING_TYPE STRING_TYPE STRING_TYPE STRING_TYPE STRING_TYPE STRING_TYPE STRING_TYPE

F1 Client request FUNC A-1 A0 Arrow input

F1 ’ Client request FUNC F1 C1 Arrow input

F2 Parts spec FUNC A-1 A0 Arrow input

F2’ Parts spec FUNC F2 C2 Arrow input

F4 International standards FUNC A-1 A0 Arrow control

F4a International standards FUNC F4 C2 Arrow control

F4b International standards FUNC F4 A3 Arrow control

Figure B.3 – Relation meta-class example of the PAM for “design product” activity (1 of 6)

F5 Design tools FUNC A-1 A0 Arrow mechanics

F5a Design tools FUNC F5 C2 Arrow mechanics

F5b Design tools FUNC F5 A3 Arrow mechanics

F6 Law & regulation FUNC A-1 A0 Arrow control

F6’ Law & regulation FUNC F6 A4 Arrow control

F7 Agreed spec & evaluation FUNC A-1 A0 Arrow mechanics

F7’ Agreed spec & evaluation FUNC F7 A4 Arrow mechanics

F8 Product design FUNC A0 A-1 Arrow output

F8’ Product design FUNC A4 F8 Arrow output

F1 1 Product idea FUNC C1 {F1 1 a, F1 1 b } Arrow connectivity

F1 1 a Product idea FUNC F1 1 C2 Arrow connectivity

F1 1 b Product idea FUNC F1 1 A4 Arrow input

F21 Draft spec FUNC C2 A3 Arrow input

F22 Final spec FUNC C2 A4 Arrow input

F31 Review comments FUNC A3 C2 Arrow input

F1 ” Client request FUNC F1 ’ A1 1 Arrow Input

F1 1 1 Design requirement FUNC A1 1 A1 2 Arrow Input

F1 21 Required specification FUNC A1 2 {F1 21 a,F1 21 b,F1 21 c} Arrow connectivity

F1 21 a Required specification FUNC F1 21 A1 3 Arrow Input

F1 21 b Required specification FUNC F1 21 A1 4 Arrow Input

F1 21 c Required specification FUNC F1 21 A1 5 Arrow Input

F1 41 Cost estimation FUNC A1 4 { F1 41 a, F1 41 b, F1 41 c} Arrow connectivity

F1 41 a Cost estimation FUNC F1 41 A1 2 Arrow control

F1 41 b Cost estimation FUNC F1 41 A1 5 Arrow Input

F1 41 c Cost estimation FUNC F1 41 A1 4 Arrow control

F1 51 Product idea FUNC A1 5 F1 1 Arrow output

F1 1 a’ Product data FUNC F1 1 a A21 Arrow Input

F2” Parts spec FUNC F2’ A22 Arrow Input

F31 ’ Review comments FUNC F31 A23 Arrow input

F4a’ International standards FUNC F4a A22 Arrow Control

F5a’ Design tools FUNC F5a A23 Arrow Mechanics

F21 1 Spec plan FUNC A21 A22 Arrow Input

F221 Gathered data FUNC A22 A23 Arrow Input

F231 Final spec FUNC A23 F22 Arrow output

F232 Draft spec FUNC A23 F21 Arrow Ouput

F233 Raw spec FUNC A23 A24 Arrow input

F241 Error report FUNC A24 A23 Arrow control

F251 a Human resource FUNC F251 A22 Arrow mechanics

F251 b Human resource FUNC F251 A23 Arrow mechanics

F21 ’ Draft spec FUNC F21 A31 Arrow Input

F31 1 Review plan FUNC A31 A32 Arrow input

F331 Final comments FUNC {A33, A34} A35 Arrow input

F4ba International stadards FUNC F4b A32 Arrow control

F4bb International stadards FUNC F4b A33 Arrow control

F5b’ Design tools FUNC F5b A32 Arrow mechanics

F352 Review comments FUNC A35 F31 Arrow output

F6” Law & regulation FUNC F6’ A42 Arrow control

F22’ Final spec FUNC F22 A41 Arrow input

F1 1 b’ Product idea FUNC F1 1 b A41 Arrow input

F41 1 Document for authorization FUNC A41 A42 Arrow Input

F421 Authorized specification FUNC A42 A43 Arrow input

F431 Product design FUNC A43 F8’ Arrow output

F331 X Imperative comments FUNC {A33, A34 } A35 Arrow control

Tiêu đề	Interface for Activity Description
Trường học	Unknown University
Chuyên ngành	Electrical and Electronic Technologies
Thể loại	standards document
Năm xuất bản	2017
Thành phố	Geneva

Định dạng
Số trang	148
Dung lượng	2,59 MB