Please ensure Javascript is enabled for purposes of website accessibility
Powered by Zoomin Software. For more details please contactZoomin

AVEVA™ Information Standards Manager

Sheet: 'ISM Physical Classes'

  • Last UpdatedJun 20, 2024
  • 3 minute read

This sheet defines Physical Classes and Sub Classes (or Equipment Classes).

An abstract class, "Root Physical Class" (@id="ISM_ROOT_PHYSICAL"), will be created automatically as the root of the class hierarchy, with all top level classes (classes with no "Extends") extending this class. You are free to define properties for this root class, by including a class definition with Id=" ISM_ROOT_ PHYSICAL" in this sheet.

Item

Column Name

Constraint

Description

1

Id

Required

  • The identifier for the Class definition. There is a requirement that this value is unique within the collection of Physical Classes in the target Class Library model

  • Even though it is not an absolute requirement, it is recommended that identifier values do not contain white space characters

  • To avoid identifier naming conflicts in applications implementing the Class Library it is recommended that all identifiers, across all concepts, are unique within a Class Library. This can easily be achieved by using a naming convention, such as "TAG_nnnn".

  • It is strongly recommended, when a Class Library evolves over time, to never change the value of any identifiers

2

Name

A human readable name for the Class definition

3

Name

{language}

  • A human readable name for the Class definition, in a specific language

  • The value for {language} is composed as {languageCode}- {countryCode} (see the Sheets and Column Headers for AVEVA ISM Intrinsic Definitions)

  • This column can be repeated as many times as required, each with a different value for {language}

4

Description

An arbitrary description for the purpose/role of the Class

5

Description

{language}

  • An arbitrary description of the purpose/role of the Class, in a specific language

  • The value for {language} is composed as {languageCode}- {countryCode} (see the Sheets and Column Headers for AVEVA ISM Intrinsic Definitions)

  • This column can be repeated as many times as required, each with a different value for {language}

6

Abstract

  • true

  • false

  • Specifies whether the Class should be considered Abstract

  • Abstract classes are typically base definitions for more specialized concrete classes, like the way a Physical Class forms a base for more specialized Sub Classes

7

Discipline

  • The discipline "owning" the Class (or Tag Discipline)

  • An Enumeration@aspect="Enumerations.PhysicalTypes" will be created automatically, and populated with the values supplied in this column

8

Naming Template_Id

  • The value of this column should contain the identifier of a Naming Template definition to associate with the Class (see Naming Template definitions elsewhere in this document)

  • If you need to associate more than one Naming Template to a Class, you have to use the Sheet: 'ISM Document Class Naming Tpl' sheet

9

Naming Template_ ApplicableFor

  • Validation

  • Allocation

  • Specifies the applicability of the Naming Template, for example, a Naming Template containing pattern matching regular expressions will only be applicable for Validation

  • It is possible to specify more than one value, in which case the values need to be separated by a single space character

10

LifeCycle Type

A reference to the identifier of a Life Cycle Type that is applicable for the Class

11

Extends

  • The identifier of the Physical Class being parent of target Class. For example, when defining a Physical Sub Class, this column typically contains the identifier of the parent Physical Class

  • When extending a parent class, all aspects (properties, attributes, naming templates, extensions) of the parent class will automatically be derived by the target class. Any explicit definitions on the target class will override corresponding values being derived from parent class

12

Aspect

Annotating a Class with an aspect is a way to associate the Class with a specific semantic definition. Application logic will look for these aspects, and apply associated processing rules. Definition of available aspect values is outside the scope of this document

13

Obsolete

true

false

When evolving a Class Library over time, removing previously existing definitions might cause issues with consuming software systems (for example, they might not support deleting a class that is in use for existing data). Obsoleting deprecated definitions might therefore be a less intrusive approach. How, or whether, obsoleting is implemented might vary across consuming software though

14

SortOrder

- A signed integer value

  • Decides on the order in which classes are presented in the AVEVA ISM user interface

  • Classes not having a value specified for this property will be ordered as if they have the highest SortOrder value

TitleResults for “How to create a CRG?”Also Available in