From 4fd4d95112f4e246115aa2cd81ab0b3445ee5663 Mon Sep 17 00:00:00 2001 From: Birgit Boss Date: Thu, 16 Nov 2023 13:21:40 +0100 Subject: [PATCH 001/124] add folder structure for documentation, empty .adoc-file --- documentation/IDTA-01003-a/ROOT/IDTA-01003-1.adoc | 0 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 documentation/IDTA-01003-a/ROOT/IDTA-01003-1.adoc diff --git a/documentation/IDTA-01003-a/ROOT/IDTA-01003-1.adoc b/documentation/IDTA-01003-a/ROOT/IDTA-01003-1.adoc new file mode 100644 index 0000000..e69de29 From 0611363d819b296779b361cd181da6aa9b7d1f21 Mon Sep 17 00:00:00 2001 From: Birgit Boss Date: Thu, 16 Nov 2023 15:29:41 +0100 Subject: [PATCH 002/124] correct readme: link to issues add issue templates --- .github/ISSUE_TEMPLATE/bug_report.md | 21 +++++++++++++++++++++ .github/ISSUE_TEMPLATE/feature_request.md | 20 ++++++++++++++++++++ README.md | 2 +- 3 files changed, 42 insertions(+), 1 deletion(-) create mode 100644 .github/ISSUE_TEMPLATE/bug_report.md create mode 100644 .github/ISSUE_TEMPLATE/feature_request.md diff --git a/.github/ISSUE_TEMPLATE/bug_report.md b/.github/ISSUE_TEMPLATE/bug_report.md new file mode 100644 index 0000000..b6da1e9 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/bug_report.md @@ -0,0 +1,21 @@ +--- +name: Bug report +about: Create a bug report to help us improve. +title: "[BUG]" +labels: bug +assignees: '' + +--- + +**Describe the bug** +A clear and concise description of what the bug is. + +**Where** +Indicate the location of the bug (e.g., in which document, section and paragraph you found the bug). + +**Screenshots** +If applicable, add screenshots to help explain your problem. + + +**Additional context** +Add any other context about the problem here. diff --git a/.github/ISSUE_TEMPLATE/feature_request.md b/.github/ISSUE_TEMPLATE/feature_request.md new file mode 100644 index 0000000..bbcbbe7 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/feature_request.md @@ -0,0 +1,20 @@ +--- +name: Feature request +about: Suggest an idea for this project +title: '' +labels: '' +assignees: '' + +--- + +**Is your feature request related to a problem? Please describe.** +A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] + +**Describe the solution you'd like** +A clear and concise description of what you want to happen. + +**Describe alternatives you've considered** +A clear and concise description of any alternative solutions or features you've considered. + +**Additional context** +Add any other context or screenshots about the feature request here. diff --git a/README.md b/README.md index f0c9865..67a9164 100644 --- a/README.md +++ b/README.md @@ -12,7 +12,7 @@ The specification number is: **IDTA-01003-a** Feature requests, reports about inconsistencies, mistakes *etc.* are highly welcome! Please [submit a new issue]( -https://github.com/admin-shell-io/aas-specs/issues/new +https://github.com/admin-shell-io/aas-specs-iec61360/issues/new ). If you want to contribute, see [CONTRIBUTING.md](https://github.com/admin-shell-io/aas-specs/blob/master/CONTRIBUTING.md). The same contribution rules apply as for [aas-specs](https://github.com/admin-shell-io/aas-specs) From 1f910a7d73e71c39b4efaba93049083911a09ada Mon Sep 17 00:00:00 2001 From: Birgit Boss Date: Thu, 1 Feb 2024 10:56:21 +0100 Subject: [PATCH 003/124] antora structure for Part 3a --- documentation/IDTA-01003-a/antora.yml | 6 ++++++ documentation/IDTA-01003-a/modules/ROOT/nav.adoc | 16 ++++++++++++++++ .../ROOT/pages/IDTA-01003-a.adoc} | 0 .../IDTA-01003-a/modules/ROOT/pages/index.adoc | 3 +++ 4 files changed, 25 insertions(+) create mode 100644 documentation/IDTA-01003-a/antora.yml create mode 100644 documentation/IDTA-01003-a/modules/ROOT/nav.adoc rename documentation/IDTA-01003-a/{ROOT/IDTA-01003-1.adoc => modules/ROOT/pages/IDTA-01003-a.adoc} (100%) create mode 100644 documentation/IDTA-01003-a/modules/ROOT/pages/index.adoc diff --git a/documentation/IDTA-01003-a/antora.yml b/documentation/IDTA-01003-a/antora.yml new file mode 100644 index 0000000..db71811 --- /dev/null +++ b/documentation/IDTA-01003-a/antora.yml @@ -0,0 +1,6 @@ +name: IDTA-01003-a +title: Specification Asset Administration Shell - Part 3a IEC61360 +version: 'snapshot' +start_page: ROOT:index.adoc +nav: + - modules/ROOT/nav.adoc \ No newline at end of file diff --git a/documentation/IDTA-01003-a/modules/ROOT/nav.adoc b/documentation/IDTA-01003-a/modules/ROOT/nav.adoc new file mode 100644 index 0000000..ecdc204 --- /dev/null +++ b/documentation/IDTA-01003-a/modules/ROOT/nav.adoc @@ -0,0 +1,16 @@ +//// +Copyright (c) 2023 Industrial Digital Twin Association + +This work is licensed under a [Creative Commons Attribution 4.0 International License]( +https://creativecommons.org/licenses/by/4.0/). + +SPDX-License-Identifier: CC-BY-4.0 + +Illustrations: +Plattform Industrie 4.0; Anna Salari, Publik. Agentur für Kommunikation GmbH, designed by Publik. Agentur für Kommunikation GmbH +//// + +* xref:IDTA-01003-a.adoc[Specification] + + + diff --git a/documentation/IDTA-01003-a/ROOT/IDTA-01003-1.adoc b/documentation/IDTA-01003-a/modules/ROOT/pages/IDTA-01003-a.adoc similarity index 100% rename from documentation/IDTA-01003-a/ROOT/IDTA-01003-1.adoc rename to documentation/IDTA-01003-a/modules/ROOT/pages/IDTA-01003-a.adoc diff --git a/documentation/IDTA-01003-a/modules/ROOT/pages/index.adoc b/documentation/IDTA-01003-a/modules/ROOT/pages/index.adoc new file mode 100644 index 0000000..abaa980 --- /dev/null +++ b/documentation/IDTA-01003-a/modules/ROOT/pages/index.adoc @@ -0,0 +1,3 @@ += Specification of the Asset Administration Shell. Part 3 IEC61360 + +This document specifies the data specification IEC61360 of the Asset Administration Shell. From bfa7391e20409d54c1c3a6889f831ee27ed0d55b Mon Sep 17 00:00:00 2001 From: Birgit Boss Date: Thu, 1 Feb 2024 11:00:57 +0100 Subject: [PATCH 004/124] generated content from .adoc, based on version V3.0 of IDTA-01003-a https://github.com/rwth-iat/aas-specs/blob/asciidoc_master/docs/AASiD/AASiD_3_iec61360/IDTA-01003-a-3-0_SpecificationAssetAdministrationShell_Part3a_DataSpecification_IEC61360.adoc --- .../modules/ROOT/pages/IDTA-01003-a.adoc | 2338 +++++++++++++++++ 1 file changed, 2338 insertions(+) diff --git a/documentation/IDTA-01003-a/modules/ROOT/pages/IDTA-01003-a.adoc b/documentation/IDTA-01003-a/modules/ROOT/pages/IDTA-01003-a.adoc index e69de29..1979ab5 100644 --- a/documentation/IDTA-01003-a/modules/ROOT/pages/IDTA-01003-a.adoc +++ b/documentation/IDTA-01003-a/modules/ROOT/pages/IDTA-01003-a.adoc @@ -0,0 +1,2338 @@ +:toc: left +:toc-title: Contents +:sectlinks: +:sectnums: +:stylesheet: ../../style.css +:favicon: ../../favicon.png +:imagesdir: media/ +:nofooter: + +// image::image1.png[align=center] + +== Preamble + +=== Editorial Notes + +The document "Details of the Asset Administration Shell – Part 1 – The exchange of information between partners in the value chain of Industie 4.0, V3.0RC02" was split into several parts. One of them is this document, which represents Part 3a and describes a data specification that is defined to be used with the core model as specified in Part 1. This is also why versioning now starts with V3.0: it is only valid in combination with V3.0 of Part 1. + +This document, version 3.0, was produced from June 2022 to November 2022 by the sub working group "Asset Administration Shell" of the joint working group of the Plattform Industrie 4.0 working group "Reference Architectures, Standards and Norms" and the "Open Technology" working group of the Industrial Digital Twin Association (IDTA). It is the first release published by the IDTA. + +For a complete history, please refer to Part 1a of the document series " Details of the Asset Administration Shell". + +For better readability, the abbreviation "I4.0" is consistently used for "Industrie 4.0" in compound terms. The term "Industrie 4.0" continues to be used when standing on its own. + +This specification is versioned using https://semver.org/spec/v2.0.0.html[Semantic Versioning 2.0.0] (semver) and follows the semver specification link:#bib13[[13\]]. + +The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in https://tools.ietf.org/html/bcp14[BCP 14] https://tools.ietf.org/html/rfc2119[RFC2119] https://tools.ietf.org/html/rfc8174[RFC8174footnote:[https://www.ietf.org/rfc/rfc2119.txt]]: + + +. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification. +. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification. +. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. +. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED", mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. +. MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein, an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.) + + + + +=== Scope of This Document + +The Asset Administration Shell (see Part 1a of the document series) allows to define data specification templates. Data specification templates aim to enable interoperability between the partners that agree on the template. A template defines a set of attributes, with each attribute having a clear semantics. This set of attributes corresponds to a (sub-)schema. + +This document specifies data specification templates conformant to IEC 61360. IEC 61360 specifies how to define the semantics of single properties or values. The value range of a property can be defined as a value list – an enumeration -, while each of the (coded) values of the value list are treated as single concepts. They are thus suited to be used as data specifications for concept descriptions. + +This document assumes familiarity with the concept and specification of the Asset Administration Shell as defined in Part 1. + +The main stakeholders addressed in this document are architects and software developers aiming to implement a digital twin using the Asset Administration Shell in an interoperable way. Additionally, the content can also be used as input for discussions with international standardization organizations and further collaborations. + +Please consult the continuously updated reading guide link:#bib15[[15\]] for an overview of documents on the Asset Administration Shell. The reading guide gives advice on which documents should be read depending on the role of the reader. + +=== Normative References + +[AAS-Part1] "The Exchange of information between partners in the value chain of Industrie 4.0", part of document series "Details of the Asset Administration Shell". V3.0. Jan. 2023. Industrial Digital Twin Association. + +[IEC61360-1] Standard data element types with associated classification scheme – + +Part 1: Definitions – Principles and methods. Edition 4.0 2017-07 + +[[IEC61360-2]] Standard data element types with associated classification scheme for electronic components. Part 2: EXPRESS dictionary schema. Edition 2012. + +[ISO 13584-42] ISO 13584-42:2010, _Industrial automation systems and integration – Parts library – Part 42: Description methodology: Methodology for structuring part families_ + +=== Structure of the Document + +All clauses that are normative have "(normative)" as a suffix in the heading of the clause. + +Clause <<#_terms_definitions_and_abbreviations,2>> provides terms and definitions as well as abbreviations, both for abbreviations used in the document and for abbreviations that may be used for elements of the metamodel defined in this document. + +Clause <<#_introduction,3>> gives a short introduction of Asset Administration Shell types and how this document is related to them. + +Clause <<#_general,4>> explains the purpose of the data specification template specified in this document by giving examples of existing data dictionaries. + +Clause <<#_predefined_data_specification_templates,5>> shows how the data specification template is related to Part 1 and its elements. + +Clause <<#_predefined_template_for_iec61360_properties_value_lists_and_values_normative,6>> is the main normative part of the document. It specifies the data specification templates supporting IEC 61360. + +Clause <<#_mapping_iec_61360_data_types_to_xsd_data_types,7>> explains how data types of IEC 61360 are mapped to data types of values as introduced in Part 1. + +Clause <<#_category_of_concept_descriptions,8>> introduces categories for concept descriptions and how they are used in combination with the data specification template IEC61360. The constraints as defined in Clause also mainly refer to the rules on how these categories should be applied. + + +==== +Note: since categories are deprecated since V3.0, Clause <<#_category_of_concept_descriptions,8>> can also be skipped. +==== + + +Clause <<#_primitive_and_simple_data_types_normative,10>> specifies the data types used in the data specification. + +Clause Error: Reference source not found provides information on the exchange of information compliant to this specification in existing data formats like XML, AutomationML, OPC UA information models, JSON or RDF. + +Finally, Clause <<#_summary_and_outlook,12>> summarizes the content and gives an outlook on future work. + +The Annex contains additional background information on the Asset Administration Shell (_<<#_background_information,Annex A>>_). It also provides information about UML (_<<#_legend_for_uml_modelling,Annex D>>_) and the tables used to specify UML classes as used in this specification (_<<#_templates_for_uml_tables,Annex C>>_). _<<#_backus_naur_form,Annex B>>_ introduces the Backus-Naur-Form used in the document series. + +Metamodel changes compared to previous versions are described in _<<#_Toc129945523,Annex E>>_. + +The bibliography can be found in Error: Reference source not found. + +=== Working Principles + +The work is based on the following principle: keep it simple but do not simplify if it affects interoperability. + +The partners represented in the Industrial Digital Twin Association (IDTA), as well as in the Plattform Industrie 4.0 and associations such as ZVEI, VDMA, VDI/ VDE and Bitkom, ensure that there is broad sectoral coverage of process, hybrid, and factory automation and in terms of integrating information technology (IT) and operational technology (OT). + +Design alternatives were intensively discussed within the working group. An extensive feedback process of this document series is additionally performed within the working groups of Plattform Industrie 4.0 and IDTA. + +Guiding principle for the specification was to provide detailed information, which can be easily implemented also by small and medium-sized enterprises. + +== Terms, Definitions and Abbreviations + +=== Terms and Definitions + ++++Please note+++: + +the definitions of terms are only valid in a certain context. This glossary applies only within the context of this document. For a more extensive list, please refer to Part 1 of the document series. + +If available, definitions were taken from IEC 63278-1 DRAFT, July 2022, and from IEC 61360. + +application + +software functional element specific to the solution of a problem in industrial-process measurement and control + + +==== +Note 1 to entry: an application can be distributed among resources and may communicate with other applications. +==== + + +* [SOURCE: IEC TR 62390:2005-01, 3.1.2] + +attribute + +data element of a _property_, a relation, or a class in information technology + +* [SOURCE: ISO/IEC Guide 77-2, ISO/IEC 27460, IEC 61360] + +Asset Administration Shell (AAS) + +standardized digital representation of an asset + + +==== +Note 1 to entry: Asset Administration Shell and Administration Shell are used synonymously. +==== + + +* [SOURCE: IEC 63278-1, note added] + +class + +description of a set of objects that share the same _attributes_, _operations_, methods, relationships, and semantics + +* [SOURCE: IEC TR 62390:2005-01, 3.1.4] + +concept + +unit of knowledge created by a unique combination of characteristics + +* [SOURCE: EC 63278-1; IEC 61360-1:2016, 3.1.8; ISO 22274:2013, 3.7] + +enumeration + +list of named constants called enumerators, each numerator name in the enumeration being unambiguous + +* [SOURCE:IEC 61360-1_2017] + +identifier (ID) + +identity information that unambiguously distinguishes one entity from another one in a given domain + + +==== +Note 1 to entry: there are specific identifiers, e.g. UUID Universal unique identifier, IEC 15418 (GS1). +==== + + +* [SOURCE: Glossary Industrie 4.0] + +minimum value + +lower bound of a range of values in which the said value is meaningful + + +==== +EXAMPLE 1: lowest value specified of a quantity, established for a specified set of operating conditions at which a +==== + + +component, device, equipment, or system can operate and perform according to specified requirements. + + +==== +Note 1 to entry: additional information about the nature of the value can be obtained from the definition of the +==== + + +_Property_ information object to which the value belongs. + +* [SOURCE:IEC 61360-1_2017] + +maximum value + +upper bound of a range of values in which the said value is meaningful + + +==== +EXAMPLE 1: highest value specified of a quantity, established for a specified set of operating conditions at which a component, device, equipment, or system can operate and perform according to specified requirements. +==== + + + +==== +Note 1 to entry: additional information about the nature of the value can be obtained from the definition of the +==== + + +_Property_ information object to which the value belongs. + +* [SOURCE:IEC 61360-1_2017] + +nominal value + +value of a quantity used to designate or identify an item with its value, and not necessarily corresponding to the real value of the property + + +==== +Note 1 to entry: additional information about the nature of the value can be obtained from the definition of the +==== + + +_Property_ information object to which the value belongs. + +* [SOURCE:IEC 61360-1_2017] + +non-quantitative property + +property that identifies or describes an object by means of codes, abbreviations, names, references or descriptions + + +==== +EXAMPLE 1: typical information content of non-quantitative properties is items such as codes, abbreviations, +==== + + +names, references, or descriptions. + +* [SOURCE: IEC 61360-2:201 7– based on IEC 61360-2:2012, 3.28, modified – "data element type" is replaced by "property" in the term and definition.] + +property + +defined characteristic suitable for the description and differentiation of products or components + + +==== +Note 1 to entry: the concept of type and instance applies to properties. +==== + + + +==== +Note 2 to entry: this definition applies to properties as described in IEC 61360/ ISO 13584-42. +==== + + + +==== +Note 3 to entry: the property types are defined in dictionaries (like IEC component data dictionary or ECLASS), they do not have a value. The property type is also called data element type in some standards. +==== + + + +==== +Note 4 to entry: the property instances have a value and are provided by the manufacturers. A property instance is also called property-value pair in certain standards. +==== + + + +==== +Note 5 to entry: properties include nominal value, actual value, runtime variables, measurement values, etc. +==== + + + +==== +Note 6 to entry: a property describes one characteristic of a given object. +==== + + + +==== +Note 7 to entry: a property can have attributes such as code, version, and revision. +==== + + + +==== +Note 8 to entry: the specification of a property can include predefined choices of values. +==== + + +* [SOURCE: according to ISO/IEC Guide 77-2] as well as [SOURCE: according Glossary Industrie 4.0] + +qualifier + +well-defined element associated with a _property_ instance or _submodel element_, restricting the value statement to a certain period of time or use case + + +==== +Note 1 to entry: qualifier can have associated values. +==== + + +* [SOURCE: according to IEC 62569-1] + +quantitative property + +property with a numerical value representing a physical quantity, a quantity of information or a count of objects + +* [SOURCE: IEC 61360-1_2017 – based on IEC 61360-2:2012, 3.40, modified – "data element type" is replaced by "property"] + +Submodel + +container of SubmodelElements defining a hierarchical structure consisting of SubmodelElements + +* [SOURCE: IEC 63278-1] + +SubmodelElement + +elements in a Submodel + +* [SOURCE: IEC 63278-1] + + + +=== Abbreviations Used in Document + +[width="100%",cols="21%,79%",options="header",] +|=== +|*Abbreviation* |*Description* +|AAS |Asset Administration Shell +|AASX |Package file format for the Asset Administration Shell +|AML |AutomationML +|API |Application Programming Interface +|BITKOM |Bundesverband Informationswirtschaft, Telekommunikation und neue Medien e. V. +|BLOB |Binary Large Object +|CDD |Common Data Dictionary +|GUID |Globally unique identifier +|I4.0 |Industrie 4.0 +|ID |Identifier +|IDTA |Industrial Digital Twin Association +|IEC |International Electrotechnical Commission +|IRDI |International Registration Data Identifier +|IRI |Internationalized Resource Identifier +|ISO |International Organization for Standardization +|JSON |JavaScript Object Notation +|MIME |Multipurpose Internet Mail Extensions +|OPC |Open Packaging Conventions (ECMA-376, ISO/IEC 29500-2) +|OPCF |OPC Foundation +|OPC UA |OPC Unified Architecture +|PDF |Portable Document Format +|RAMI4.0 |Reference Architecture Model Industrie 4.0 +|RDF |Resource Description Framework +|REST |Representational State Transfer +|RFC |Request for Comment +|SOA |Service Oriented Architecture +|UML |Unified Modelling Language +|URI |Uniform Resource Identifier +|URL |Uniform Resource Locator +|URN |Uniform Resource Name +|UTC |Universal Time Coordinated +|VDE |Verband der Elektrotechnik, Elektronik und Informationstechnik e.V. +|VDI |Verein Deutscher Ingenieure e.V. +|VDMA |Verband Deutscher Maschinen- und Anlagenbau e.V. +|W3C |World Wide Web Consortium +|XML |eXtensible Markup Language +|ZIP |archive file format that supports lossless data compression +|ZVEI |Zentralverband Elektrotechnik- und Elektronikindustrie e. V. +|=== + +== Introduction + +This document is part of the series "Details of the Asset Administration Shell" that provide the specifications for interoperable usage of the Asset Administration Shell. + +This part of the series extends Part 1 and defines a technology-neutral specification of data specification templates, enabling the description of concept descriptions conformant to IEC 61360 in UML. This UML meta model serves as the basis for deriving several different formats for exchanging Asset Administration Shells, e.g. for XML, JSON, RDF, AutomationML, and OPC UA information models. + +_<<#_Toc129706725,Figure 1>>_ shows the different ways of exchanging information via Asset Administration Shells. This part of the "Asset Administration Shell in Detail" series is the basis for all of these types of information exchange. + +[#_Toc129706725] +.Types of Information Exchange via Asset Administration Shells +image::image2.jpeg[align=center] + +File exchange (1) is described in Part 5 of this document series. + +The API (2) is specified in Part 2 of the document series "Details of the Asset Administration Shell" link:#bib14[[14\]]. It also includes access to concept descriptions using the data specifications as specified in this document. + +The I4.0 language (3) is based on the information metamodel specified in Part 1 and 3 link:#bib23[[23\]]. + +Part 3 is not a single document. Instead, it is an own series of documents, each featuring a specific use case that is supported by the specified data specification templates. + +== General + +=== Introduction + +IEC 61360 is a standard that describes how to define the semantics of properties in a data dictionary. The known data dictionaries ECLASS and IEC CDD are based on this standard. The data specification templates specified in this document make it possible to directly use concept descriptions as standardized in these data dictionaries. Additionally, concept descriptions, which do not (yet) exist in these data dictionaries, can be defined using the same schema. + +Concept descriptions, whether defined externally in existing data dictionaries or internally as part of the Asset Administration Shell environment, are the foundation for defining submodel templates link:#bib24[[24\]] link:#bib16[[16\]]. + +IEC 61360-1:2017 is largely compliant to IEC 61360-2:2012 and ISO 3584-42:2010. + + +==== +Note: for details on how to use the data specifications and for further explanations, please refer directly to IEC 61360. +==== + + +The following subclauses show some examples from these existing data dictionaries to ease understanding of the data specification templates. + +=== Concept Descriptions for Properties and Values + +The data specification template IEC 61360 introduces additional attributes to define the semantics – i.e. a concept description – of a property or a value based on IEC 61360. + +IEC 61360 requests to use IRDIs for the identification of a concept. The Asset Administration Shell allows to use other identifiers besides IRDI. The IRDI, the unique identifier of an IEC 61360 property or value, maps to ConceptDescription/id. + +_<<#_Toc129706726,Figure 2>>_ to _<<#_Toc129706729,Figure 5>>_ show examples from ECLASS _<<#_Toc129706727,Figure 3>>_ shows a property with enumeration type. One of the values in this enumeration is shown in _<<#_Toc129706728,Figure 4>>_, each value has its own unique ID. The unique identifier of a value ( _<<#_Toc129706728,Figure 4>>_) is also used for _Property/valueId._ + +_<<#_Ref129950722,Figure 6>>_ Example for Property with Level Type from IEC CDD shows an example from IEC CDD for a concept description of a _Property_ with usage of Level Type (in this example level type MIN, MAX and NOM, see data type). This is a short form of defining a collection of three properties with the same data type and semantics except for the level. + + +[#_Toc129706726] +.Example Property From ECLASS +image::image3.png[align=center] + +[#_Toc129706727] +.Example Property Description with Value List from ECLASS +image::image4.png[align=center] + +[#_Toc129706728] +.Example Value Description from ECLASS +image::image5.png[align=center] + +[#_Toc129706729] +.Example Value Description from ECLASS Advanced (Editor Modus) +image::image6.png[align=center] + +[#_Ref129950722] +.Example for Property with Level Type from IEC CDD +image::image7.png[align=center] + +== Predefined Data Specification Templates + +=== Overview + +A data specification template specifies which additional attributes shall be added to an element instance that are not part of the meta model. Typically, data specification templates have a specific scope. For example, templates for concept descriptions differ from templates for operations, etc. More than one data specification template can be defined and used for an element instance. Which templates are used for an element instance is defined via _HasDataSpecification_. + +There is one data specification template supporting IEC 61360 [IEC61360-1]: + +* _DataSpecificationIec61360:_ defining concept descriptions for both properties and coded values. + +_<<#_Ref129879629,Figure 7>>_ Overview Relationship Metamodel Part 1 a & Data Specifications IEC 61360 gives an overview of the data specification template and how it is used in combination with the information model as defined in Part 1 of the document series, namely _DataSpecification_, _DataSpecificationContent,_ and _ConceptDescription_. + +[#_Ref129879629] +.Overview Relationship Metamodel Part 1 a & Data Specifications IEC 61360 +image::image8.png[align=center] + +IEC 61360 is a standard that describes how to define the semantics of properties in a data dictionary. Part 1 does not prescribe how to define a concept description; it only supports the definition of concept descriptions. To do so, a data specification template needs to be assigned to the concept description. Which data specification is made available is defined via _HasDataSpecification/dataSpecification_. + +The legend for understanding the UML diagrams and the table specification of the classes is explained in _<<#_templates_for_uml_tables,Annex C>>_ and _<<#_legend_for_uml_modelling,Annex D>>_. + + +==== +Note: an xmi representation of the UML model can be found in the repository "aas-specs" in the github project admin-shell-io: https://github.com/admin-shell-io/aas-specs/. +==== + + +== Predefined Template for IEC61360 Properties, Value Lists, and Values (normative) + +=== Data Specification IEC61360 Template Specification + +[width="100%",cols="20%,20%,20%,40%",options="header",] +|=== +|*Template:* |IEC61360 | | +|*administration:* |version: 3 |revision: 0 |creator: IDTA +|*id:* |https://admin-shell.io/DataSpecificationTemplates/DataSpecificationIec61360/3/0 | | +|*dataSpecificationContent:* |DataSpecificationIec61360 | | +|*Description (EN):* |Data specification template for concept descriptions for properties and values conformant to IEC 61360. | | +|=== + +The id of the template was derived conformant to the rules for semantic IDs for data specifications as defined in Part 1 of the document series [AAS-Part1]): + +"https://admin-shell.io/DataSpecificationTemplates/DataSpecificationIec61360/3/0" + +This ID will be used in _hasDataSpecification/dataSpecification_. + +This namespace has the qualifier "IEC:" Examples: _IEC:DataSpecificationIec61360/preferredName_ or _IEC: DataSpecificationIec61360/levelType/Min_ or _IEC:LevelType/Min_ + +[#_Toc125981064] +.Metamodel of Data Specification IEC61360 +image::image9.png[align=center] + +==== Data Specification IEC61360 Attributes + +[width="100%",cols="19%,47%,27%,7%",options="header",] +|=== +|*Class:* |DataSpecificationIec61360 \<