implementation guide for parcel interchange with iec cdd

62656-2/Ed.1 Ó IEC:201X – 3 – 3D/183/NP

CONTENTS

FOREWORD .................................................................................................................. 4 1 Scope ...................................................................................................................... 5 2 Normative references ................................................................................................ 5 3 Terms and Definitions ............................................................................................... 6 4 Common cases for meta-class definition ..................................................................... 6

4.1 Parcel structure ............................................................................................... 6 4.2 Shorthand notation for identifiers ....................................................................... 7

4.2.1 Shorthand notation for header section ..................................................... 7 4.2.2 Shorthand notation for data section ......................................................... 8

4.3 Data exchange with CSV files ............................................................................ 9 4.3.1 CSV format for representation of data parcels .......................................... 9 4.3.2 Cell delimiter ...................................................................................... 10 4.3.3 Line feed character ............................................................................. 10 4.3.4 Character encoding ............................................................................. 10

5 Modelling dictionary structure .................................................................................. 10 5.1 Objective ....................................................................................................... 10 5.2 Basics for simple dictionary development ......................................................... 10

5.2.1 Classification tree ............................................................................... 10 5.3 Complex dictionary ......................................................................................... 12

5.3.1 Partial inheritance ............................................................................... 12 5.3.2 Composition tree ................................................................................. 14

6 Key modelling features ............................................................................................ 15 6.1 Property with unit ........................................................................................... 15 6.2 Cardinality ..................................................................................................... 16 6.3 Enumeration .................................................................................................. 17

6.3.1 Definition of an enumeration ................................................................. 17 6.3.2 Simple way ......................................................................................... 18 6.3.3 Complex way ...................................................................................... 19

7 Conformance to implementation for IEC CDD ............................................................ 20 Annex A (normative) Information object registration ......................................................... 22

A.1 Document identification .................................................................................. 22 Annex B (informative) Sample data ................................................................................ 23

62656-2/Ed.1 Ó IEC:201X – 4 – 3D/183/NP

INTERNATIONAL ELECTROTECHNICAL COMMISSION

____________

STANDARDIZED PRODUCT ONTOLOGY TRANSFER AND REGISTER BY

SPREADSHEETS

Part 2: Implementation guide for parcel interchange with IEC CDD

FOREWORD

1) The IEC (International Electrotechnical Commission) is a worldwide organization for standardization comprising all national electrotechnical committees (IEC National Committees). The object of the IEC is to promote international co-operation on all questions concerning standardization in the electrical and electronic f ields. To this end and in addition to other activities, the IEC publishes International Standards. Their preparation is entrusted to technical committees; any IEC National Committee interested in the subject dealt with may participate in this preparatory work. International, governmental and non-governmental organizations liaising with the IEC also participate in this preparation. The IEC collaborates closely with the International Organization for Standardization (ISO) in accordance with conditions determined by agreement between the two organizations.

2) The formal decisions or agreements of the IEC on technical matters express, as nearly as possible, an international consensus of opinion on the relevant subjects since each technical committee has representation from all interested National Committees.

3) The documents produced have the form of recommendations for international use and are published in the form of standards, technical reports or guides and they are accepted by the National Committees in that sense.

4) In order to promote international unif ication, IEC National Committees undertake to apply IEC International Standards transparently to the maximum extent possible in their national and regional standards. Any divergence between the IEC Standard and the corresponding national or regional standard shall be clearly indicated in the latter.

5) The IEC provides no marking procedure to indicate its approval and cannot be rendered responsible for any equipment declared to be in conformity with one of its standards.

6) Attention is drawn to the possibility that some of the elements of this International Standard may be the subject of patent rights. The IEC shall not be held responsible for identifying any or all such patent rights.

International Standard IEC 62656-2 has been prepared by subcommittee 3D, Data sets for libraries, of IEC technical committee 3: Information structures, documentation and graphical symbols.

IEC 62656 consists of the following parts, under the general title Standardized product ontology transfer and register by spreadsheets:

- Part 1: Logical structure for data parcels;

- Part 2: Implementation guide for parcel interchange with IEC CDD;

- Part 3: Application interface (planned). Annexes A and B form an integral part of this standard.

62656-2/Ed.1 Ó IEC:201X – 5 – 3D/183/NP

STANDARDIZED PRODUCT ONTOLOGY TRANSFER AND REGISTER BY SPREADSHEETS

Part 2: Implementation guide for parcel interchange with IEC CDD

1 Scope

The IEC 62656 series of standards entitled; “standardized product ontology register and transfer by spreadsheets” defines the means for registering and exchanging of product ontology(s) expressed in spreadsheet forms. The Part1 of this standard defines the semantics and syntax of the data parcels: a specialized use of a set of spreadsheets.

This part of IEC 62656 provides an implementation guide for the logical structure of data parcels specified in IEC 62656-1. The guide intends to illustrate how to implement the standard as an application in order to prevent implementers from misunderstanding the standard. The guide also intends to introduce some good examples of data parcels enabling not only the building of a simple dictionary but also the definition of a domain dictionary that can be imported into or exported from IEC 61360-4 Component Data Dictionary, or IEC CDD in short.

The implementation guide defined in this part of IEC 62656 contains the following:

· Illustration of the principal information for defining data parcels for data dictionaries,

· Illustration of typical examples of representation of IEC CDD compliant dictionaries on data parcels, and

· Illustration of conformance classes for implementation of parcel based systems.

The following items are outside the scope of this part of IEC 62656:

· Procedures for building IEC61360 compliant domain dictionaries,

· Semantics of a standard dictionary itself,

· Theoretical explanation of the logical structure of data parcels, and

· Interface for CIM (Common Information Model) (IEC 61970 / IEC 61968).

2 Normative references

The following normative documents contain provisions which through reference in this text constitute provisions of this part of IEC 62656. At the time of publication, the editions indicated were valid. All normative documents are subject to revision, and parties to agreements based on this part of IEC 62656 are encouraged to investigate the possibility of applying the most recent editions of the normative documents indicated below. Members of IEC and ISO maintain registers of currently valid International Standards.

IEC 62656-1(to-be), Standardized product ontology register and transfer by spreadsheets — Part 1: Logical structure for data parcels

IEC 61360-1:2009, Standard data element types with associated classification scheme for electric components — Part 1: Definitions – Principles and methods.

IEC 61360-4:1998, Standard data element types with associated classification scheme for electric components — Part 4: IEC reference collection of standard data element types, component classes and terms.

ISO 10303-11:1994, Industrial automation systems and integration — Product data representation and exchange — Part 11: Description methods: The EXPRESS language reference manual.

ISO 13584-42:2010, Industrial automation systems and integration — Parts library — Part 42: Methodology for structuring part families.

62656-2/Ed.1 Ó IEC:201X – 6 – 3D/183/NP

3 Terms and Definitions

For the purpose of this document, the terms and definitions given in clause 2 of IEC 62656-1 Ed.1:2010 apply. Additionally, the following terms and definitions apply:

3.1 classification tree acyclic graph of classes and relations as nodes and edges, where each node represents a concept and each edge represents a specialization, or so called “is-a” relationship between the two concepts connected by the edge

3.2 composition tree acyclic graph of classes and relations as nodes and edges, where each node represents a concept and each edge represents a part-whole relationship, or so called “has-a” relationship, between the two concepts connected by the edge

NOTE In a composition tree, one node may have several sub-nodes as parts and this state of being is also called an aggregation.

4 Common cases for meta-class definition

4.1 Parcel structure

As shown in Figure 1 derived from IEC 62656-1, every parcelling sheet is horizontally separated into two parts, a header section and a data section. The header section is further horizontally separated into two parts, a class header section and a schema header section.

Cla

ss

head

er

sect

ion

Sche

ma

head

er

sect

ion

Dat

a se

ctio

n

Hea

der s

ectio

n

Figure 1 - Structure of a parcelling sheet

In a meta-layer to describe a data dictionary such as IEC CDD, information about a meta-class is described in the class header section and information about meta-properties of the meta-class is listed in the schema header section, while instances of the meta-class is described in data section.

In the meta-layer, identifiers of a meta-class and meta-properties usually have the same RAI and the same VI. Moreover, almost all identifiers described as meta-property values in data

62656-2/Ed.1 Ó IEC:201X – 7 – 3D/183/NP

section may also have the same RAI and the same VI. Therefore, this part of IEC 62656 strongly recommends the use of shorthand notation for the description of an identifier because of the following advantages.

· To increase readability of a parcel sheet,

· To avoid writing the same RAI and the same VI over and over, and

· To reduce data volume of a parcel sheet.

According to IEC 62656-1, shorthand notation of RAI and VI for identifiers is provided for both of the header section and the data section. The usage and example of each are described hereafter.

4.2 Shorthand notation for identifiers

4.2.1 Shorthand notation for header section

#DEFAULT_SUPPLIER and #DEFAULT_VERSION placed in the class header section are reserved keywords for the shorthand notation for all identifiers described in the header section. According to IEC 62656-1, the reserved keywords #CLASS_ID and #ALTERNATE_CLASS_ID in the class header section and #PROPERTY_ID, #ALTERNATE_ID, #UNIT_ID and #ALTERNATE_UNIT_IDS in the schema header section have an identifier, so their values are the scope of this type of shorthand notation.

A default RAI is described after concatenation of “#DEFAULT_SUPPLIER” and a separator “:=” on the instruction column. For example, a default RAI “0112/2///62656_1” is described as “#DEFAULT_SUPPLIER:=0112/2///62656_1”. As well as the default RAI, a default VI is described after concatenation of the “#DEFAULT_VERSION” and a separator “:=” on the instruction column. For example, a default VI “1” is described as “#DEFAULT_VERSION:=1”.

In the class header section, each value of a reserved keyword is described after concatenation of the keyword and a separator “:=”. For example, an identifier “0112/2///62656_1#MDC_C002##1” of the class meta-class is described as “#CLASS_ID:=0112/2///62656_1#MDC_C002##1”. If a default RAI and a default VI are given as “#DEFAULT_SUPPLIER:=0112/2///62656_1” and “#DEFAULT_VERSION:=1” respectively, the cell value may be one of followings:

· “#CLASS_ID:=0112/2///62656_1#MDC_C002##1” (neither the default RAI nor the default VI are applied),

· “#CLASS_ID:=MDC_C002##1” (only the default RAI is applied),

· “#CLASS_ID:=0112/2///62656_1#MDC_C002” (only the default VI is applied), and

· “#CLASS_ID:=MDC_C002” (both the default RAI and the default VI are applied).

In the schema header section, each value of a reserved keyword is described in a cell after the second cell column on the line of the keyword. For example, an identifier “0112/2///62656_1#MDC_P001_5##1” of the meta-property is described in the cell on the line of the preserved keyword “#PROPERTY_ID”. If the same RAI and the same VI described in the above example for the class header section are given as default values, the cell value may be one of followings:

· “0112/2///62656_1#MDC_P001_5##1” (neither the default RAI and the default VI are applied),

· “MDC_P001_5##1” (only the default RAI is applied),

· “0112/2///62656_1#MDC_P001_5” (only the default VI is applied), and

· “MDC_P001_5” (both the default RAI and the default VI are applied).

NOTE1 Default values of RAI and VI are applied only when RAI and VI are omitted from an identif ier. If RAI and VI are not omitted from an identif ier, the default values shall be ignored for the identif ier.

NOTE2 The line of the preserved keyword #DATATYPE may contain an identif ier of an enumeration for a property, if the data type of the property is an enumeration type.

62656-2/Ed.1 Ó IEC:201X – 8 – 3D/183/NP

EXAMPLE The default RAI “0112/2///62656_1” is applied to the third and the f if th cells from left-hand side on the line of #PROPERTY_ID as well as a value of #CLASS_ID, while the default VI “001” is applied to the second, the fourth and the f ifth cells f rom left-hand side on the line of #PROPERTY_ID as well as a value of #CLASS_ID.

#CLASS_ID:=MDC_C002

#ALTERNATE_CLASS_ID:=

#CLASS_NAME.en:=Class meta-class

#DEFAULT_SUPPLIER:=0112/2///62656_1

#DEFAULT_VERSION:=001

#PROPERTY_ID 0112/2///62656_1#MDC_P001_5

MDC_P004_1.en##001

0112/2///62656_1#MDC_P010

MDC_P014 MDC_P017

#ALTERNATE_ID

#PROPERTY_NAME.en

Code Preferred name

Superclass Applicable properties

Class value assignment

#DATATYPE STRING TRANSLATABLE_STRING

STRING SET(0,?) OF STRING

SET(0,?) OF LIST(2,2) OF STRING

#UNIT_ID

#ALTERNATE_UNIT_IDS

0112/2///61360_4#AAA000##001

IEC reference collection

UNIVERSE {0112/2///61360_4#AAE000##001}

0112/2///61360_4#AAA001##001

Components 0112///61360_4#AAA000##001

{0112/2///61360_4#AAE001##005,0112/2///61360_4#AAE006##006,…}

{(0112/2///61360_4#AAE000##001,CO)}

0112/2///61360_4#AAA002##003

Electric/electronic components

0112/2///61360_4#AAA001##001

{0112/2///61360_4#AAE002##006,0112/2///61360_4#AAE007##005,…}

{(0112/2///61360_4#AAE001##005,EE)}

Figure 2 – Display example of default RAI and VI for the header section

4.2.2 Shorthand notation for data section

According to IEC 62656-1, preserved keywords #DEFAULT_DATA_SUPPLIER and #DEFAULT_DATA_VERSION placed in the schema header section enables shorthand notation for property values in the data section. For meta-properties defined in IEC 62656-1, there are 3 types of properties which may have an identifier within their values.

· Singularity: Meta-property which has an identifier, e.g. MDC_P001_x (Code for each meta-class), MDC_P010 (Superclass), MDC_P021 (Definition class), etc. For example, a value is described as “0112/2///61360_4#AAA000##1”.

· Plurality: Meta-property which has aggregation of identifiers, e.g. MDC_P013 (Is case of), MDC_P014 (Applicable properties), MDC_P043 (Enumerated list of terms), etc. For example, a value is described like “{0112/2///61360_4#AAF332##005,0112/2///61360_4#AAF333##005,0112/2///61360_4#AAF336##005}”.

· Mixture: Meta-property which has mixture of an identifier and other value, e.g. MDC_P017 (Class value assignment), MDC_P022 (Data type), etc. For example, a value is described like “{(0112/2///61360_4#AAE000##1,CO)}”.

A default RAI and VI for a property are described in a cell column of the property, and they are applied to values of the properties. For example, if a default RAI “0112/2///61630_4” and a default VI “1” are given, a value “0112/2///61360_4#AAA000##1” of the meta-property “MDC_P001_5” may be one of the followings:

62656-2/Ed.1 Ó IEC:201X – 9 – 3D/183/NP

· “0112/2///61360_4#AAA000##1” (neither the default RAI and the default VI are applied),

· “AAA##1” (only the default RAI is applied),

· “0112/2///61360_4#AAA000” (only the default VI is applied), and

· “AAA000” (both the default RAI and the default VI are applied).

For another example with the same default values, a value “{(112/2///61360_4#AAE000##1,CO)}” of the meta-property “MDC_P017” may be one of the followings:

· “{(0112/2///61360_4#AAE000##1,CO)}” (neither the default RAI and the default VI are applied),

· “{(AAE000##1,CO)}” (only the default RAI is applied),

· “{(0112/2///61360_4#AAE000,CO)}” (only the default VI is applied), and

· “{(AAE000,CO)}” (both the default RAI and the default VI are applied).

NOTE If RAI and VI are not omitted from an identif ier, the default values shall be ignored for that identif ier.

EXAMPLE According to IEC 62656-1, meta-properties MDC_P001_5 (Code), MDC_P010 (Superclass), MDC_P014 (Applicable properties) and MDC_P017 (Class value assignment) include an identif ier in their values. Figure 5 shows the same data shown in Figure 2, but the shorthand notation is applied to its data section.

#CLASS_ID:=MDC_C002


#DEFAULT_SUPPLIER:=0112/2///62656_1

#DEFAULT_VERSION:=001

#PROPERTY_ID MDC_P001_5

MDC_P004_1.en MDC_P010 MDC_P014 MDC_P017

#PROPERTY_NAME.en

Code Preferred name Superclass Applicable properties

Class value assignment



SET(0,?) OF LIST(2,2) OF STRING

#DEFAULT_DATA_SUPPLIER

0112/2///61360_4

0112/2///61360_4

0112/2///61360_4 0112/2///61360_4

#DEFAULT_DATA_VERSION

001 001 001

AAA000 IEC reference collection

UNIVERSE {AAE000##001}

AAA001 Components AAA000 {AAE001##005,AAE006##006,…}

{(AAE000,CO)}

AAA002##003

Electric/electronic components

AAA001 {AAE002##006,AAE007##005,…}

{(AAE001##005,EE)}

Figure 3 – Display example of default RAI and VI for property values

4.3 Data exchange with CSV files

4.3.1 CSV format for representation of data parcels

IEC 62656-1 does not specify a file format for data exchange, but the CSV (Comma Separated Values) format is recommended because the format is quite similar to the structure of a parcel sheet. The following subclauses provide some information to generate and read data in CSV files correctly.

62656-2/Ed.1 Ó IEC:201X – 10 – 3D/183/NP

4.3.2 Cell delimiter

As shown in the name “CSV”, a comma character is generally used as a cell delimiter. However, several applications use another character as the delimiter, because a comma character is used for another purpose, e.g. as a decimal point in some of European languages. Therefore, any parcelling tool should recognize what character is used as a cell delimiter and get the value of each cell correctly.

EXAMPLE 1 If a semi-colon character is used for a cell delimiter in a CSV f ile, a value “yes;no;unknown” shall be enclosed between text qualif iers, while a value “yes, no or unknown” does not need to be enclosed between such qualif iers.

4.3.3 Line feed character

Some commercial and non-commercial tools allow the use of a line feed character in a cell value, and others do not. Therefore, the use of this character within a cell is not recommended. If it is required to use the character, the cell value including the character shall be enclosed between text qualifiers.

The number of text qualifiers in a line shall always be even in a CSV file. Therefore, if the number of text qualifiers in a line is odd, the line shall be concatenated with a line feed character and next line.

EXAMPLE

If a value is “sentence 1.<LF>sentence 2.<LF>sentence 3.<l ine feed>”, the value is described in a CSV file as follows:

“sentence 1.<LF>

sentence 2.<LF>

sentence 3”

The number of a text qualif ier in the f irst line is 1, therefore, the f irst line is concatenated with a line feed character and the second line. Next, the number of a text qualif ier in the two lines is 1, therefore, the lines are also concatenated with a line feed character and the third line. Finally, the number of a text qualif ier in the three lines is 2, therefore, a l ine actually consists of the above three lines.

4.3.4 Character encoding

A data parcel may contain a multi-byte character. In this case, a character encoding for a CSV file shall support the character in order to avoid any problem while data exchange. Therefore, UTF-8 or UTF-16 is recommended.

5 Modelling dictionary structure

5.1 Objective

This clause gives examples of minimum set of data parcels for modelling an easy dictionary and complex dictionaries. As an example of an easy dictionary, data parcels of a classification tree are given in 5.2.1. Also as examples of the complex dictionaries, data parcels of partial inheritance and a composition tree are given in 5.3.1 and 5.3.2 respectively. In every case, the RAI and VI of each identifier are omitted for readability of this document unless they are required.

5.2 Basics for simple dictionary development

5.2.1 Classification tree

A classification tree is a structure of inheritance of concepts, and it is a basic structure of IEC CDD. To represent it with data parcels, meta-properties MDC_P010 (Superclass) and MDC_P014 (Applicable properties) of MDC_C002 (Class meta-class) and a meta-property MDC_P021 of MDC_C003 (Property meta-class) are required.

62656-2/Ed.1 Ó IEC:201X – 11 – 3D/183/NP

Each class defined in a class meta-class sheet has a parent class whose identifier is described as a value of the meta-property MDC_P010. For a domain dictionary of IEC CDD, a virtual root “112/2///61360_1#AAA000##1” is provided, therefore, a value of the meta-property of a root class of a domain dictionary should be the identifier of the virtual root.

The meta-property MDC_P014 lists properties of a class which are newly specified as applicable for the class and any of its subclasses. Therefore, to get all properties of a class, it is necessary to gather all properties described in the meta-property MDC_P014 of the class and its superclasses.

NOTE A root class of the virtual root of IEC CDD is “UNIVERSE” which is a universal root of all classes.

EXAMPLE Figure 4 shows an example of a classif ication tree. A class FC01 (Fastener), which is a domain root under the IEC CDD root, has 3 subclasses FC02 (Screw), FC03 (Nut) and FC04 (Bolt), and the class FC03 also has 2 subclasses FC05 (Wing nut) and FC06 (Hexagon nut). There are two properties FP1 and FP2 defined on the class FC01, and the former property immediately becomes applicable. The latter property is visible on the class FC01 and becomes applicable on the classes FC02 and FC04 respectively.

Figure 4 – Example of classification hierarchy of concepts

Figure 5 gives a class meta-class sheet including a minimum set of data for representation of the classif ication tree and applicable properties of each class shown in Figure 4.

#CLASS_ID:=MDC_C002


#PROPERTY_ID MDC_P001_5 MDC_P004_1.en MDC_P010 MDC_P014

#PROPERTY_NAME.en


#DATATYPE STRING TRANSLATABLE_STRING STRING SET(0,?) OF STRING

FC01 Fastener AAA000 {FP1}

FC02 Screw FC01 {FP2,FP3}

FC03 Nut FC01 {FP4}

FC04 Bolt FC01 {FP2,FP5}

FC05 Wing nut FC03 {FP6}

FC06 Hexagon nut FC03 {FP7}

Figure 5 – Example of class meta-class sheet for Figure 4

Figure 6 gives a property meta-class sheet including a code and definition class of each property shown in Figure 4.

62656-2/Ed.1 Ó IEC:201X – 12 – 3D/183/NP

#CLASS_ID:=MDC_C003

#CLASS_NAME.en:=Property meta-class

#PROPERTY_ID MDC_P001_6 MDC_P021

#PROPERTY_NAME.en

Code Definition class

#DATATYPE STRING STRING

FP1 FC01

FP2 FC01

FP3 FC02

FP4 FC03

FP5 FC04

FP6 FC05

FP7 FC06

Figure 6 – Example of property meta-class sheet for Figure 4

5.3 Complex dictionary

5.3.1 Partial inheritance

In the meta-model described in IEC 62656-1, every node is allowed to have only one parent, namely, multiple inheritance used in the object oriented way is prohibited. Instead, the way to import a part of properties of another class, a kind of partial inheritance, is given. For representation of a partial inheritance, two meta-properties, MDC_P013 (Is case of) to specify a class for import of a part of its properties and MDC_P090 (Imported properties) to specify the properties, are required.

Each class listed in the meta-property MDC_P013 of a class should be selected from classes other than its superclasses, its subclasses and itself; however, a class defined in another domain dictionary is selectable.

Each property listed in the meta-property MDC_P090 of a class should be selected from applicable properties of the classes listed in the meta-property MDC_P013 of the class. The listed properties in the meta-property MDC_P090 are applicable for the class; therefore, applicable properties for a class are gathered with referring to values of both meta-properties MDC_P014 and MDC_P090 of the class and its superclasses.

EXAMPLE Figure 7 gives another example of the is-a relationship including a partial inheritance. A class VC01 (Vehicle) has two subclasses VC02 (Gasoline powered vehicle) and VC03 (Electric vehicle). The class VC03 has a property EP2 (e.g. Motor power, which is a property of Motor) which is imported from a class EC02 (Motor) defined in another domain dictionary.

62656-2/Ed.1 Ó IEC:201X – 13 – 3D/183/NP

IEC CDD rootAAA000

VehicleVC01

Gasoline powered vehicle VC02

Electric vehicleVC03

VP01

VP03 VP04

Electrical componentsEC01

VP02

EP01

MotorEC02

EP02EP02import

Another domain dictionary

13

Figure 7 – Example of partial inheritance

Figure 8 gives a class meta-class sheet for a minimum set of data for representation of the vehicle dictionary shown in Figure 7. The class VC03 has a value “{EC02}” of the meta-property MDC_P013 and a value “{EP2}” of the meta-property MDC_P090 in order to represent a partial inheritance between the class VC03 and the class EC02.

#CLASS_ID:=MDC_C002


#PROPERTY_ID MDC_P001_5

MDC_P004_1.en MDC_P010 MDC_P013 MDC_P014 MDC_P090

#PROPERTY_NAME.en

Code Preferred name Superclass Is case of Applicable properties

Imported properties



SET(0,?) OF STRING

SET(0,?) OF STRING

VC01 Vehicle AAA000 {VP01}

VC02 Gasoline powered vehicle

VC01 {VP02,VP03}

VC03 Electric vehicle VC01 {EC02} {VP04} {EP02}


Figure 9 gives a property meta-class sheet including a code and definition class of each property shown in Figure 7.

#CLASS_ID:=MDC_C003


#PROPERTY_ID MDC_P001_6 MDC_P021

#PROPERTY_NAME.en

Code Definition class

#DATATYPE STRING STRING

VP01 VC01

VP02 VC02

VP03 VC02

VP04 VC03


62656-2/Ed.1 Ó IEC:201X – 14 – 3D/183/NP

5.3.2 Composition tree

A composition tree is used for representing a part-whole relationship between a product and its part(s). In the parcel structure, a class reference type property is used to point to a part class. A value of a meta-property MDC_P022 (Data type) for such a property is described in a form “CLASS_REFERENCE(xxx)”, where xxx is the identifier of a part class. For example, If the identifier of a part class is “0112/2///61987_11#ABA833##1”, the data type of a property which points to the class is described as “CLASS_REFERENCE(0112/2///61987_11#ABA833##1)”.

In order to define a relation between a whole class and a part class, the whole class should have a class reference type property which points to the part class. A whole class may have plural part classes and a part class may further have its part class. Therefore, the relationship constructs a tree structure.

EXAMPLE Figure 10 gives an example of has-a relationship. A left-hand side tree shows an inheritance tree, where a class C01 (Product A) has two class reference type properties P01 and P02 which point to classes C02 (Part X) and C03 (Part Y) respectively, and the class C03 also has a class reference type property which points to a class C04 (Part Z). A right-hand side tree shows a composition tree of the class C01 derived from the inheritance tree. According to the definition in the inheritance tree, the c lass C01 has two components, the classes C02 and C03, and the class C03 also has the class C04 as its component.

Figure 10 – Example of composition tree

Figure 11 gives a class meta-class sheet including a minimum set of data for representation of trees shown in Figure 10. In the cell column of MDC_P014, the class C01 has the class reference type properties P01 and P02 as its applicable properties, and the class C03 has the class reference type property P07 as its applicable property.

#CLASS_ID:=MDC_C002



#PROPERTY_NAME.en


#DATATYPE STRING TRANSLATABLE_STRING STRING SET(0,?) OF STRING

C00 Domain root AAA000 {P00}

C01 Product A C00 {P01,P02,P03}

C02 Part X C00 {P04,P05}

C03 Part Y C00 {P06,P07}

C04 Part Z C00 {P08}


62656-2/Ed.1 Ó IEC:201X – 15 – 3D/183/NP

Figure 12 gives a property meta-class sheet including a minimum set of data for definition of a class reference type property. Here, the properties P01, P02 and P07 are defined as the class reference type, and point to the classes C02, C03 and C04 respectively.

#CLASS_ID:=MDC_C003


#PROPERTY_ID MDC_P001_6 MDC_P021 MDC_P022

#PROPERTY_NAME.en

Code Definition class Data type

#DATATYPE STRING STRING STRING

P00 C00 STRING

P01 C01 CLASS_REFERENCE(C02)


P03 C01 STRING

P04 C02 LEVEL(NOM) OF REAL_MEASURE

P05 C02 INT_MEASURE

P06 C03 BOOLEAN


P08 C04 LEVEL(MAX) OF REAL_MEASURE


6 Key modelling features

6.1 Property with unit

If a property has a unit of measure or currency, a data type of the property shall be defined as a measurement type or currency type respectively with its unit. INT_MEASURE and REAL_MEASURE are defined as data types for a unit of measure, while INT_CURRENCY and REAL_CURRENCY are defined as data types for a unit of currency. Complex data types, namely, LEVEL type, ENUM type and aggregation type, are also permitted as data types for a property with a unit.

According to the meta-model defined in IEC 62656-1, at least one of the meta-properties MDC_P023 (Unit structure), MDC_P023_1 (Unit in text) and MDC_P041 (Code for unit) in a property meta-class sheet shall have a value for such a property. The meta-property MDC_P023 has a STEP expression of a unit, and the meta-property MDC_P023_1 has a text expression of a unit. While the meta-property MDC_P041 has an identifier of a unit defined as an instance of the UoM meta-class. If one of the meta-properties MDC_P023 and MDC_P023_1 has a value, it takes precedence over a value of the meta-property MDC_P041.

The meta-property MDC_P042 (Codes for alternative units) may have a set of identifiers of units defined in the UoM meta-class which are alternative to a primary unit described as a value of the meta-property MDC_P041. Thus, the meta-property MDC_P041 shall have a value whenever the meta-property MDC_P042 has a value.

EXAMPLE Figure 13 gives definitions of 3 properties. The property UP001 has “m” as a unit in text, and the property UP003 has “g” as a unit in text. Also the properties UP002 and UP003 have references to UU001 and UU002 respectively defined in a UoM meta-class sheet shown in Figure 14. The property UP003 has both the unit in text and the reference to the defined unit; therefore, the unit in text takes precedence for the property UP003. The property also has a set of alternative units UU003 and UU004 for the defined unit UU002.

62656-2/Ed.1 Ó IEC:201X – 16 – 3D/183/NP

#CLASS_ID:=MDC_C003


#PROPERTY_ID

MDC_P001_6

MDC_P004_1.en

MDC_P022 MDC_P023_1

MDC_P041

MDC_P042

#PROPERTY_NAME.en

Code Preferred name

Data type Unit in text

Code for unit

Codes for alternative units


STRING STRING STRING SET(0,?) OF STRING

UP001 Length REAL_MEASURE m

UP002 Width REAL_MEASURE_TYPE

UAA726

UP003 Weight LEVEL(MIN,MAX) OF

REAL_MEASURE

g UAA594 {UAB197,UAA917}

Figure 13 – Example of property meta-class sheet for property with a unit

Figure 14 gives definitions of 7 units of measure referred from the properties shown in Figure 13.

#CLASS_ID:=MDC_C009

#CLASS_NAME.en:=UoM meta-class

#PROPERTY_ID MDC_P001_10 MDC_P004_1.en MDC_P023_1

#PROPERTY_NAME.en

Code Preferred name Unit in text

#DATATYPE STRING TRANSLATABLE_STRING STRING

UAA726 metre m

UAA594 kilogram kg

UAB197 Pound lb

UAA917 Ounce oz

UAA033 Celsius temperature °C

UAA185 kelvin K

UAA039 Fahrenheit temperature °F

Figure 14 – Example of UoM meta-class sheet for property with a unit

6.2 Cardinality

Cardinality is for restricting the boundaries of a collection of components, parts, materials, etc; namely, it defines the minimum and maximum number of the collection. As its feature, heterogeneous elements may appear in the collection. For example, for 3 USB ports embedded in a computer, different devices such as an optical mouse, a USB flash drive and a webcam may be connected at the same time.

In the parcel structure, aggregation data types, namely LIST, ARRAY, BAG and SET of a class reference type, enable representing the cardinality. CONSTRAINED_SET also provides the representation of the cardinality. Among these data types, either LIST or ARRAY is recommended for representing cardinality of items, because in many cases, the order of the items is recognized implicitly or explicitly. If the order of the items is not actually needed, BAG may be used. SET and CONSTRAINED_SET may be used for representing cardinality only when duplication of the same item is obviously prohibited.

There are two parameters "minimum" and "maximum" for each of the above data types. According to ISO 10303-11, the parameters for ARRAY define the range of index values, namely the lower index and the higher index respectively, and the fixed size of the collection.

62656-2/Ed.1 Ó IEC:201X – 17 – 3D/183/NP

While the parameters for the other data types define the minimum and maximum number of the collection respectively. Regarding CONSTRAINED_SET, there are further two parameters, namely "cardinality minimum" and "cardinality maximum", which define the minimum and maximum number of elements in an extracted subset from the collection.

EXAMPLE Figure 15 gives a class meta-class sheet to show an example of cardinality. There are 4 classes defined there; Sedan and Laptop are products, and Tire and DDR SDRAM are parts for them. Sedan has two front tires and two rear tires, therefore, it has two properties CP001 (Front tire) and CP002 (Rear tire) to represent them as its applicable properties. Laptop has three memory slots inside it; therefore, it has a property CP003 (Memory) to represent it.

#CLASS_ID:=MDC_C002



#PROPERTY_NAME.en




CC001 Sedan AAA000 {CP001,CP002}

CC002 Laptop AAA000 {CP003}

CC003 Tire AAA000

CC004 DDR SDRAM AAA000

Figure 15 – Example of class meta-class sheet for cardinality

Figure 16 gives a property meta-class sheet to define properties referred from the classes shown in Figure 15. Because the properties CP001 and CP002 are defined as “SET(2,2) OF CLASS_REFERENCE”, a class referring to the properties have just 2 front tires and 2 rear tires. Also because the property CP003 is defined as “SET(1,2) OF CLASS_REFERENCE”, a class referring to the property has at least 1 memory and at most 2 memories.

#CLASS_ID:=MDC_C003


#PROPERTY_ID MDC_P001_6 MDC_P004_1.en MDC_P022

#PROPERTY_NAME.en

Code Preferred name Data type


STRING

CP001 Front tire BAG(2,2) OF CLASS_REFERENCE(CC003)

CP002 Rear tire BAG(2,2) OF CLASS_REFERENCE(CC003)

CP003 Memory LIST(1,2) OF CLASS_REFERENCE(CC004)

Figure 16 – Example of property meta-class sheet for cardinality

6.3 Enumeration

6.3.1 Definition of an enumeration

Enumeration is a way to provide value candidates for a property. An enumeration for a property value shall be defined as an instance of an enumeration meta-class. Therefore, if at least one property is defined as an enumeration type, an enumeration meta-class sheet is required.

There are two ways to define an enumeration, one is a simple way without a value definition described in 6.3.2, and the other is a complex way with a value definition described in 6.3.3. In each way, there are further two ways to define an enumeration of simple type; one is to use primitive type of enumeration such as ENUM_REAL and ENUM_BOOLEAN, and the other is

62656-2/Ed.1 Ó IEC:201X – 18 – 3D/183/NP

to use subset_constraint for simple type; however, this part of IEC 62656 recommends the former for ease of understanding.

6.3.2 Simple way

If it is not necessary to define a meaning of a value or to share a constant value, selectable candidates of values shall be directly listed in an enumeration in an enumeration meta-class sheet. An enumeration type property shall refer to an enumeration which gives selectable candidates of values of the property. For example, an enumerated values “(1,2,3)” may give selectable candidates of values of a number type property.

A property can refer to an enumeration as long as the data type of the property encloses the data type of the enumeration. For example, if a data type of a property is REAL, a data type of an enumeration shall be either INT or REAL.

A list of values is directly described as a value of the meta-property MDC_P044 (Enumeration code list) in the enumeration meta-class sheet. Each value in the list depends on a data type defined in the meta-property MDC_P022 (Data type) in the same sheet.

NOTE ISO13584-42 ed.2 does not provide a way to define a meaning of a value. Therefore, possible values of a property should be listed in an enumeration.

EXAMPLE Figure 17 gives an example of a property meta-class sheet including 3 enumeration type properties ZP01, ZP02 and ZP03 which point to ZE01, ZE02 and ZE03 defined in an enumeration meta-class sheet shown in Figure 18 respectively. The data type of the property ZP02 is defined without a list of the values of the enumeration ZE02. In this case, values listed in MDC_P044 of the enumeration ZE02 are used.

#CLASS_ID:=MDC_C003


#PROPERTY_ID

MDC_P001_6 MDC_P004_1.en MDC_P022

#PROPERTY_NAME.en

Code Preferred name Data type

#DATATYPE STRING TRANSLATABLE_STRING STRING

ZP01 Length ENUM_REAL_MEASURE(ZE01(1.5,3.0,4.5))

ZP02 Colour ENUM_STRING(ZE02)

ZP03 Attachment ENUM_BOOLEAN(ZE03(yes,no))

Figure 17 – Example of property meta-class sheet for enumeration without value definition

Figure 18 gives an example of an enumeration meta-class sheet for properties shown in Figure 17. Each value of each enumeration has no meaning, therefore, a value of MDC_P043 is empty.

#CLASS_ID:=MDC_C005

#CLASS_NAME.en:=Enumeration meta-class

#PROPERTY_ID MDC_P001_12 MDC_P004_1.en MDC_P022 MDC_P044 MDC_P043

#PROPERTY_NAME.en

Code Preferred name Data type Enumeration code list

Enumerated list of terms

#DATATYPE STRING STRING STRING LIST(0,?) OF STRING

LIST(0,?) OF STRING

ZE01 Length REAL (1.5,3,4.5)

ZE02 Car body colours STRING (blue,red,yellow)

ZE03 BOOLEAN (yes,no)

Figure 18 – Example of enumeration meta-class sheet for enumeration without value definition

62656-2/Ed.1 Ó IEC:201X – 19 – 3D/183/NP

6.3.3 Complex way

A possible value for a property may sometimes be defined to clarify the its meaning or to share the same value among properties. For example, a property has a colour “red” as its value, but the colour is actually not RGB colour “#FF0000” but “#FE0000”. In this case, the colour should be defined to distinguish it from other colours categorized as “red”.

In order to define a meaning of a value, a term for the value should be defined in a term meta-class sheet. A meta-property MDC_P001_11 (Code) defines an identifier of a term, and a meta-property MDC_P025_1 (Preferred letter symbol in text) describes a value itself in the term meta-class sheet. A meta-property MDC_P022 (Data type) specifies a data type of the term.

The meta-property MDC_P043 (Enumerated list of terms) in the enumeration meta-class sheet gives a list of Identifiers of terms defined in a term meta-class sheet. A list of values for an enumeration type property is usually derived from values of a meta-property MDC_P025_1 of terms defined in the term meta-class sheet, but if the meta-property MDC_P044 gives another list of values, the list derived from the meta-property MDC_P043 shall be overridden. Each value in an enumeration depends on a data type defined in the meta-property MDC_P022 in the term meta-class sheet. Therefore, a property can refer to the enumeration as long as the data type of the property encloses the data type of each value.

NOTE If both of the meta-properties MDC_P043 and MDC_P044 have values, the number of elements of MDC_P043 shall be the same as the one of MDC_P044.

EXAMPLE Figure 19 gives a similar data to the example shown in Figure 17, but values listed in the enumerations ZE01 and ZE03 in Figure 19 have meanings. In this case, a value of MDC_P043 has a list of identif iers of terms which defines meanings of the values. The enumeration ZE01 has only a list of terms, so when an enumeration type property refers to the enumeration, a l ist of preferred letter symbols of terms is implicitly derived for a property value. W hile the enumeration ZE03 has not only a list of terms but also a list of values. In this case, the list of values is referred from an enumeration type property.

#CLASS_ID:=MDC_C005

#CLASS_NAME.en:=Enumeration meta-class

#PROPERTY_ID MDC_P001_12 MDC_P004_1.en MDC_P022 MDC_P044 MDC_P043

#PROPERTY_NAME.en

Code Preferred name Data type Enumeration code list

Enumerated list of terms

#DATATYPE STRING STRING STRING LIST(0,?) OF STRING

LIST(0,?) OF STRING

ZE01 Length (ZT01,ZT02,ZT03}

ZE02 Colours for cars STRING (blue,red,yellow)

ZE03 (yes,no) (ZT04,ZT05)

Figure 19 – Example of enumeration meta-class sheet for enumeration without value definition

Figure 20 gives a term meta-class sheet in which terms for the values listed in Figure 18 are defined. A value referred from an enumeration is defined as a value of MDC_P025_1.

62656-2/Ed.1 Ó IEC:201X – 20 – 3D/183/NP

#CLASS_ID:=MDC_C010

#CLASS_NAME.en:=Term meta-class

#PROPERTY_ID MDC_P001_11 MDC_P004_1.en MDC_P022 MDC_P025_1

#PROPERTY_NAME.en

Code Preferred name Data type Preferred letter symbol in text

#DATATYPE STRING STRING STRING STRING

ZT01 REAL_MEASURE 1.5

ZT02 INT_MEASURE 3

ZT03 REAL_MEASURE 4.5

ZT04 True BOOLEAN T

ZT05 False BOOLEAN F

Figure 20 – Example of term meta-class sheet for enumeration without value definition

7 Conformance to implementation for IEC CDD

IEC 62656-1 defines the POM (Parcelized Ontology Model) conformance classes. The conformance classes are classified with the number of a top layer among MoF (Meta-object Facility) layers, and further classified with what layers are comprised and whether local extension exists or not in their conformance classes.

IEC62656-1 allows the specification of the name of an ontology model that is assumed as the immediate upper layer for the processing of data parcels in the parentheses added to the Conformance Class ID abbreviated as CCID. This part of IEC62656 defines two additional conformance classes, 2(CCD) and 2X(CCD) as the specialization of the conformance classes 2 and 2X defined in IEC62656-1, for uploading and downloading of domain ontologies or dictionaries to and from IEC CDD.

The conformance classes including both the M3-M2 layer (MO: Meta Ontology) and M2-M1 (DO: Domain Ontology) layer also satisfy the requirement conformance for IEC CDD only when all the meta-properties for IEC CDD are defined in data parcels in the M3-M2 layer, where Mn-Mm means a pair of n-th and m-th levels defined in MoF standards. According to IEC 62656-1, the conformance classes, 3A, 3AX, 3B, 3BX, 4A, 4AX, 4C and 4CX may satisfy the requirement conformance for IEC CDD.

Table 1 lists all the conformance classes defined in IEC 62656-1 and the additional conformance classes, 2(CDD) and 2X(CDD).

62656-2/Ed.1 Ó IEC:201X – 21 – 3D/183/NP

Table 1 – POM conformance classes

CCID Definition MoF layers

1 Data parcel just for DL (Domain Library) M1-M0

1X Data parcel only for DL with local extension of properties and possibly their instance values

M1-M0

2 Data parcel just for DO (Domain Ontology) M2-M1

2X Data parcel just for DO with local extension of properties and possibly their instance values

M2-M1

2(CDD) Data parcel for DO to be registered into IEC CDD M2-M1

2X(CDD) Data parcel for DO to be registered into IEC CDD with local extension of properties

M2-M1

2A Data parcels for all layers below comprising DO and DL

M2-M1, M1-M0

2AX Data parcels for all layers below comprising DO and DL with local extension of properties and possibly their instance values

M2-M1, M1-M0

3 Data parcel just for MO (Meta Ontology) M3-M2

3X Data parcel only for MO with local extension of properties and possibly their instance values

M3-M2

3A Data parcel with all layers below, comprising MO, DO, and DL

M3-M2, M2-M1, M1-M0

3AX Data parcel with all layers below, comprising MO, DO, and DL with local extension of properties and possibly their instance values

M3-M2, M2-M1, M1-M0

3B Data parcels with the layer below comprising MO and DO

M3-M2, M2-M1

3BX Data parcels with the layer below comprising MO and DO with local extension of properties and possibly their instance values

M3-M2, M2-M1

4 Data parcel just for AO (Axiomatic Ontology) M4-M3

4X Data parcel just for AO with local extension of properties and possibly their instance values

M4-M3

4A Data parcels with all layers below, comprising AO, MO, DO, and DL

M4-M3, M3-M2, M2-M1, M1-M0

4AX Data parcels with all layers below, comprising AO, MO, DO, and DL with local extension of properties and possibly their values

M4-M3, M3-M2, M2-M1, M1-M0

4B Data parcels with the layer below comprising AO and MO

M4-M3, M3-M2

4BX Data parcels with the layer below comprising AO and MO with local extension of properties and possibly their instance values

M4-M3, M3-M2

4C Data parcels with all layers except DL comprising AO, MO and DO.

M4-M3, M3-M2, M2-M1

4CX Data parcels with all layers except DL comprising AO, MO and DO with local extension of properties and possibly their instance values

M4-M3, M3-M2, M2-M1

62656-2/Ed.1 Ó IEC:201X – 22 – 3D/183/NP

Annex A (normative)

Information object registration

A.1 Document identification

In order to provide for unambiguous identification of an information object in an open system, the object identifier;

{ iec standard 62656 part (2) version (1) }

is assigned to this part of IEC 62656. The meaning of this value is defined in ISO/IEC 8824-1.

62656-2/Ed.1 Ó IEC:201X – 23 – 3D/183/NP

Annex B (informative) Sample data

During the development of the standard period, sample data parcels for dictionaries described in clause 5 will be available from the following URL:

http://www.toplib.com/sample/dictionary/

http://www.toplib.com/sample/dictionary/

62656-2/Ed.1 Ó IEC:201X – 24 – 3D/183/NP

Bibliography

[1] RFC4180: Common Format and MIME Type for Comma-Separated Values (CSV) Files, Network Working Group, 2005-10, http://www.rfc-editor.org/rfc/rfc4180.txt

[2] Meta Object Facility (MOF) Core Specification, OMG Available Specification Version 2.0, OMG (Object Management Group Inc.) , 2006-06-01, http://www.omg.org/docs/formal/06-01-01.pdf

implementation guide for parcel interchange with iec cdd

Documents

shorthand notation

data section

complex dictionary

modelling dictionary

data exchange

simple dictionary development

simple way

complex way