Sheet: 'ISM Class Library Header'

1

Id

Required

• The value to use as the unique identifier for the Class Library definition

• When setting up inheritance between Class Library instances, the identifier is used as reference

• To avoid potential collisions of identifier values, when, for example, the Class Library is stored in a common repository, it is recommended to include your company’s domain name, such as "CorporateStandard@mydomain.com"

• For a concrete, Asset specific, Class Library definition (see Abstract below), it is recommended to compose the Id as "Asset@mydomain.com", where Asset represents the code value used to identify the Asset in instance data

2

Name

The name of the target Class Library, typically a bit more verbose and more human friendly than the identifier value.

3

Description

A description of the target Class Library

4

Version

Required

• The version number consists of up to 4 segments of integer numbers on the form "major.minor.revision.build", for example "1.0.1.1"

• You only have to specify the number of segments that you find applicable, the reminding segments will automatically be set to 0

5

VersionDate

• The date when the Class Library content was submitted

• If specified as text, the value has to be on the form ""yyyy.MM.dd" (four digits for year, two digits for month and two digits for day of month)

6

Extends

• A reference to the Id of another Class Library to derive from

• Syntax is "id[, versionRequirements]" where

  • id: Required, represents the Id value of the parent Class Library

  • versionRequirements: Optional, and if not specified the highest available version number will be used. If specified, you can use wildcard, such as "1.2.*", meaning version number has to start on "1.2.", but the reminding two segments in the version number are not significant

7

Abstract

• true

• false

• A deployable Class Library will typically be a composition of multiple definitions (or fragments), such as:

  • A corporate standard, containing the foundation of attributes and class definitions

  • A collection of naming templates, reflecting the target ENS

  • Application specific annotations, configuring consuming software applications

  • Industry standard and nomenclature mappings, making the Class Library compliant with other standards

• Separately none of these fragments will constitute a consistent Class Library for consumption, but combined they will. Hence they should be annotated with Abstract=true

• Typically a deployable Class Library is targeting a specific Asset (or Plant), covering requirements specific to the target Asset. The Class Library fragment representing these Asset specific requirements will include all the other fragments as a composition, and should be considered a concrete definition (Abstract=false)

• This setting will dictate certain behaviour of AVEVA ISM:

  • A fragment can only extend another fragment

  • A fragment cannot be checked for consistency by the AVEVA ISM consistency validators

  • A fragment cannot be used for generating software configuration artefacts in AVEVA ISM