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 Functional Classes'

  • Last UpdatedJun 20, 2024
  • 3 minute read

This sheet defines Functional Classes and Sub Classes (or Tag Classes).

An abstract class, "Root Functional Class" (@id="ISM_ROOT_FUNCTIONAL"), 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_ FUNCTIONAL" 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 Functional 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 Functional Class forms a base for more specialized Sub Classes.

7

Discipline

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

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

8

Naming Template_Id

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

LifeCycleType

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

11

Extends

  • The identifier of the Functional Class being parent of target Class. For example, when defining a Functional Sub Class, this column typically contains the identifier of the parent Functional 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