1 Scope

This standard is an extension of the overall OPC Unified Architecture standards and defines an information model that conforms to the Common Object Models defined in ANSI/ISA-95.00.02-2010 Enterprise/Control System Integration – Part 2: Object Model Attributes standard, referred to as ISA-95 in this document. The Common Object Models describe the object model for Personnel Information, Role Base Equipment Information, Physical Asset Information, and Material Information as resources for manufacturing operations and controls, and is widely used in many industries for information exchange in Manufacturing Operations Management (MOM) systems. The international version of this ISA-95 standard is IEC 62264-2:2013, the Common Object Models in both are the same.

The Business To Manufacturing Markup Language (B2MML) is an open source XML implementation of the ISA-95 and IEC 62264 standards. The Business To Manufacturing Markup Language (B2MML) is used courtesy of the Manufacturing Enterprise Solutions Association (MESA International). B2MML is used as the de facto standard interface to exchange the contents defined in ISA-95. The OPC UA implementation will complement the existing B2MML implementations by providing a secure and reliable environment that is widely accepted in the manufacturing industries.

The modelling targets of this standard shall exist in an OPC UA Address Space. This standard does not consider the modelling targets that are identified in other standards or vendor specifications.

2 Normative References

The following referenced documents are indispensable for the application of this standard. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

OPC 10000-1, OPC Unified Architecture - Part 1: Overview and Concepts

3 Terms, definitions and conventions

3.1 Overview

It is assumed that basic concepts of OPC UA information modelling are understood in this specification. This specification will use these concepts to describe the ISA-95 Common Object Models. The concepts and terms used to describe the OPC UA Information models are defined in other parts and listed in the following sections. Note that OPC UA terms and terms defined in this standard are italicized.

For the purposes of this document, the terms and definitions given in OPC 10000-1, OPC 10000-3, OPC 10000-8, and OPC 10000-9 as well as the following apply.

3.2 OPC UA ISA-95 Terms

3.2.1 ISA95<Term>

3.2.1.1 General

This standard adopts adding an ISA95 prefix to all ISA-95 defined terms that are used in this standard that are also defined by OPC. The <Term> is the terminology defined by ISA-95. This allows the terminology used in ISA-95 to be easily distinguished from terminology defined in OPC UA.

3.2.1.2 ISA95Class

a concept that categorizes a modelling target defined as a Class in ISA-95 Part2.

Note: It is different than the concept of a Type defined in OPC UA OPC 10000-3, even though the OPC UA Type is also a concept to classify a modelling target and it is similar to a concept of class used in OOAD.

3.2.1.3 ISA95Object

a concept that represents Equipment, Personnel, Physical Assets, and Material defined in ISA-95.

3.2.1.4 ISA95Property

a concept that represents characteristics of a modelling target defined as a Property in ISA-95 Part2.

Note: The semantic of the ISA95Property is similar to Property defined in OPC UA, but the model structure is different since an ISA95Property may have a Reference to an ISA95TestSpecification and an ISA95TestResult and such References are not allowed in an OPC UA Property. An ISA95Property more closely matches an OPC UA Variable, which is allowed to have children.

3.2.1.5 ISA95Attribute

a concept that represents an attribute of a modelling target defined as attribute in ISA-95.

Note: It is different from a concept of Attribute defined in OPC UA, where Attribute is a concept to represent information of a NodeClass. ISA95Attribute is represented as VariableType in this standard.

3.2.2 UML<Term>

3.2.2.1 General

UML<Term> is a terminology defined in UML. In this standard, terminologies used in UML are described in this format to distinguish terminology defined in OPC UA and ISA-95.

3.3 Abbreviations and symbols

3.4 OPC UA Notation

This standard uses ModellingRule that are OptionalPlaceholder and MandatoryPlaceholder to define instance declarations, and defines a rule that the BrowseName of instance declarations having an OptionalPlaceholder or MandatoryPlaceholder ModellingRule be enclosed in angle brackets (<>). Originally, this rule is defined in OPC 10000-3 as a recommendation. This naming rule is also used in the description of a table. The BrowseName of a Node that has OptionalPlaceholder or MandatoryPlaceholder ModellingRule are described with angle brackets, which denotes that the name is not fixed. For example BrowseName of Property is described as <PropertyName> in graphical notation and tables results in a Property that can have any name.

4 Concept

4.1 Overview

Automation does not end with equipment control; it also includes higher levels of control that manage personnel, equipment, and materials across production areas. Effectiveness in manufacturing companies is not based solely on equipment control capability. The ISA-95 Enterprise/Control System Integration standard defines 5 levels of activities in a manufacturing organization. Generally, automation and control support Levels 1 and 2, Manufacturing Operations Management (MOM) systems support Level 3, and business Enterprise Resource Planning (ERP) systems support Level 4 activities. ISA-95 defines four primary types of information that often must be exchanged among MOM systems and between ERP systems and MOM systems, these types are;

Information about material and the properties of materials,

Information about equipment as it pertains to the operations being performed,

Information about the physical assets that make up the equipment,

Information about personnel and their roles and qualifications.

ISA-95 provides a standard manner to uniquely describe this information for exchange, including the interrelationships between the various types of information. The ISA-95 standard is described in multiple parts, where each part describes a portion of the standard. The 2010 versions of Parts 1 and 2 of the ISA-95 standard have been used to define a UA companion standard using OPC UA constructs for the purpose of exposing the ISA-95 objects and attributes in an OPC UA environment. This first release of the UA companion standard supports a subset of the entire ISA-95 standard, covering the role based equipment, physical asset, material and personnel object models in ISA-95 (see Figure 1). Later revisions of the companion standard may include support for the other ISA-95 object models such as process segment, operations definition, operations schedule, operations performance and operations capability object models.

4.2 ISA-95 Summary

4.2.1 Introduction

For an OPC UA user that may not be familiar with ISA-95, the following section provides a brief overview of key features that ISA-95 provides along with a little background related to ISA-95 and the concepts behind it.

4.2.2 Why ISA-95?

Typically in a manufacturing world plants optimize their control systems to maximize production and profits. Manufacturing companies must also be efficient at coordinating and controlling personnel, materials, and equipment across different control systems in order to reach their maximum potential. This coordination and control must occur in at least four different parts of an organization; production, quality tests and test labs, warehousing and inventory management, and maintenance.

This coordination and control is often supported by Manufacturing Execution Systems (MES) for ma­nagement of production operations, Laboratory Information Management Systems (LIMS) for quality tests and test lab management, Warehouse Management Systems (WMS) or Tank Farm Management systems for management of inventory operations, and Asset Management or Computerized Maintenance Management Systems (CMMS) for maintenance operations. These systems together are collectively called Manufacturing Operations Management (MOM) systems. MOM defines a diverse set of functions that operate above automation control systems, reside below the level of enterprise business systems and are local to a site or area.

ISA-95 was created to allow efficient sharing and coordination of information between the various levels. The following subsections summarize the information that needs to be exchanged.

Sharing Material Information: Manufacturing requires materials. It is not surprising that manufacturing systems have a requirement to identify and track materials because the main purpose of manufacturing is to convert materials in one form into materials of another form. An important part of MOM integration is maintaining and exchanging material identification and information.

MES identify materials and their suitability for use, batch management systems confirm that the correct materials are used as specified in the recipes,

Tracking and tracing systems (bar-code scanners and RFID readers),

LIMS confirm that the correct materials are tested and the correct materials are used in testing,

WMS identify materials in their storage locations.

Shared material information can be divided into three main categories;

material class information identifies the materials without regard to the source of the material,

material definition information identifies material from specific vendors or sources,

material lot information identifies actual material, its location and quantity.

Sharing Equipment Information: One important element of managed information is the correct identification of the equipment used for manufacturing. Equipment identification is used for:

scheduling,

tracking and tracing,

maintenance,

troubleshooting,

visualization (HMI),

capacity tracking,

OEE (Overall Equipment Effectiveness) calculations.

Unfortunately, it is not uncommon for a manufacturing company to have multiple identifications for a single piece of equipment. Therefore, a critical aspect of equipment information management is managing different equipment ID’s across multiple vendor systems and applications.

Sharing Physical Asset Information: Identification of a unique physical asset, irrespective of the role the equipment is performing is vital for:

maintenance,

equipment qualification and regulatory compliance,

financial asset tracking

While equipment is typically identified by a tag, such as TT-101 for a temperature transmitter, that identifies the role, or current function, of a specific asset physical asset information this is not sufficient for tracking individual assets for maintenance and financial purposes. To manage assets a company must have a unique identifier for the physical asset that is independent of the role it serves at a specific point in time. For example temperature transmitter TT-101 may have a serial number of X2 on a specific day, the next day the transmitter may be swapped out with a replacement transmitter with the same specifications but with the serial number X3. X3 would then be configured to have the tag TT-101 and X2 would no longer be known as TT-101. In order to track the transmitters X2 and X3 the physical asset information model would be used, while for operations purposes it is only important that TT-101 is in use and providing a temperature reading, the operators and control systems do not generally need to know the asset tag of TT-101, they just need the tag.

Tracking of individual physical assets allows companies to monitor individual asset’s health records, ensure they are qualified for production and track them in financial systems.

Sharing Personnel Information: Multiple regulatory rules, laws, and internal procedures require that personnel who perform shop floor actions are unequivocally identified, are authorized to perform the actions, and have valid training or qualifications to perform the actions. Because personnel information is usually maintained in multiple IT systems and control systems, it is a key area of exchanged information. Specific uses in different systems that require coordination and sharing include:

MES Personnel qualification to be checked before someone is allowed to take an action

LIMS Identification of approved personnel to perform tests and handle materials, often based on their training qualifications,

AM Certification information about personnel performing maintenance activities to ensure that they have the proper training required by the activity,

WMS Certification that personnel are trained and qualified to handle material movement systems, such as fork trucks or crane systems.

4.2.3 ISA-95

The ISA-95 Enterprise/Control System Integration standard defines five levels of activities in a manufacturing organization. Generally, automation and control support Levels 1 and 2, MOM systems support Level 3, and business Enterprise Resource Planning (ERP) systems support Level 4 activities. The ISA-95 levels are shown in Figure 1.

Level 0 defines the actual physical processes.

Level 1 elements are the sensors and actuators attached to the control functions in automation systems.

Level 2 automation and control systems have real-time responses measured in sub-seconds and are typically implemented on Programmable Logic Controllers (PLC), Distributed Control Systems (DCS), and Open Control Systems (OCS).

Level 3 typically operates on time frames of days, shifts, hours, minutes, and seconds. Level 3 functions also include maintenance functions, quality assurance and laboratory functions, and inventory movement functions, and are collectively called Manufacturing Operations Management. A wide variety of systems support the activities, including SCADA (Supervisory Control and Data Acquisition) systems for monitoring the process and providing operator control, batch control systems for execution of recipes, data historians for the collection and preservation of time based data from Level 2 systems, recipe and document management systems for managing recipes and workflow instructions, detailed scheduling, campaign management or work dispatching, and work or product tracking.

Level 4 typically operates on time frames of months, weeks, and days. Enterprise Resource Planning (ERP) logistics systems are used to automate Level 4 functions. Level 4 is called Business Planning and Logistics.

It is important to remember that each level has some form of control and each level has its own definition for real-time. Level 3 systems consider real-time to mean information available a few seconds after shop floor events occur. Level 4 systems consider real-time to mean that logistics and material information is available daily or within a few hours after the end of a shift.

ISA-95 typically deals with information exchange across Level 3 systems or between Level 3 and Level 4 systems. Specifically this would involve information exchange between ERP, EAM, CMMS, MES, WMS, LIMS, PLC and DCS systems. This information exchange in real-time is often required in order to allow workflows and recipes to execute in a timely manner. ISA-95 defines four primary types of information that often must be exchanged among MOM systems and between ERP systems and MOM systems, these types are; information about material and the properties of materials, information about equipment as it pertains to the operations being performed, information about the physical assets that make up the equipment, and information about personnel and their roles and qualifications.

4.2.4 Modelling Approach of ISA-95

The ISA-95 modelling approach to information is based on a “Property” model. [Note this is an ISA Property not a Property as defined by OPC UA] The ISA-95 models define a minimum set of industry-independent information as attributes. Industry specific, application specific, and company specific information are represented as property objects. For example, the personnel class property would be used to define application or industry specific attributes for personnel classes, and person property would be used to contain instance values for the properties.

In the ISA-95 resource models there are “Classes” and “Instances”. The word “Class” used as part of an object definition name should be considered as a classification, not as a “Class” in the official UML Modelling definition. For example: “Personnel Class” should be considered a “Personnel Classification”, because it is used to distinguish between the kinds of personnel in the real world and to define properties that would be common to personnel within the same classification. The UML description of each of the ISA Information models is described. The ISA-95 Model also includes definitions of common attributes. These definitions are not part of the UML figures, but are included as text in the ISA-95 specification.

Material: is from ISA-95.00.02, it is the ISA-95 material object model. This is the definition of the lots, sublots, material definitions, and material classes involved in production. This information allows Level 3 and Level 4 systems to unambiguously identify material specified in production schedules and consumed or produced in actual production. A prime business driver for using the material model is to provide the ability to trace all materials used in the manufacture of a product to aide in quality analysis and product recalls.

Each Material Definition instance defines a type of material, such as Acetic Acid, grade 4. Each Material Definition may have specific properties, such as pH. These properties can be nested, in that a property can have its own properties. Material Definitions may be assembled from other Material Definitions, as in the case of a sub-assembly in car manufacturing, such as a transaxle which is identified as a Material Definition but is pre-assembled from multiple other Material Definitions. The sub-assembly record keeping is important to maintain traceability.

Material Definitions may belong to a Material Class. Material Classes are used as logical groups to manage Material definitions. Material Classes also have properties that can be nested and may also use the same assembly construct as used by Material Definitions.

Each Material Lot is an instance of a Material Definition that is uniquely identified. Material Lots also have properties that can be nested and may also use an assembly construct similar to that used by Material Definitions, the difference is that a Material Lot may be assembled from other Material Lots and/or Material Sublots. Material Lot instance properties are typically used to track specific shipments or orders of material.

Each Material Sublot is an instance of a Material Definition that is uniquely identified. Material Sublots do not have properties since each sublot instance must have the same properties as the Material Lot it is part of. Material Sublots may also use the same assembly construct as used by Material Lots. Material Sublot instances are typically used to provide tracking resolution within Material Lots, for example a Material Lot may have been received from a vendor in ten barrels, each barrel may be identified as a separate Material Sublot in order to track its movements and environmental conditions during storage and production.

The Material Test Specification identifies a test that may be associated with determining the value for a property of a Material Class, Material Definition or Material Lot instance. The information obtained from running the test can be modelled in the QA Test Result.

Personnel: Figure 2 is from ISA-95.00.02, it is the ISA-95 personnel object model. This is the definition of the persons and personnel classes (roles) involved in production. This information may be used to associate production with specific persons as part of a production record, or with personnel classes to allocate production costs.

Each instance of the Personnel Class from ANSI/ISA-95.00.02, is the Personnel object model. Each instance of the Personnel Class defines a role that a person can perform, such as a Draftsman. Each role may have specific properties, such as a Drafting License Number and a License Expiration Date. These Properties can also have their own nested properties. Each Person can be associated to one or more Personnel Class Roles. If the person is a Draftsman, then the Person Properties define the values for the Drafting License Number and License Expiration Date for that person. The Qualification Test Specification identifies a test that may be associated with determining the value for a property (such as a test for Draftsman used to obtain a Drafting License Number.) The information obtained from taking the test can be modelled in the Qualification Test Result.

This modelling approach for ISA-95 means that properties must be able to be dynamically queried and browsed. The properties available for individual objects will be different, for example in Figure 22 - Personnel Overview, Joe Smith has a Drafting License Number, but Sally Jones does not.

Equipment: Figure 5 is, from ISA-95.00.02, it is the equipment object model. This is the definition of the roles that equipment and equipment classes perform in production, inventory management, and quality test labs. This information may be used to associate production with specific equipment as part of a production record, or with equipment classes to schedule production and allocate costs

Each instance of the Equipment Class defines a classification of equipment, such as a tank. Each Equipment Class may have specific properties, such as a volume. These properties can be nested, in that a property can have its own properties. Each piece of Equipment can be associated to one or more Equipment Classes. If the Equipment is a tank, then the Equipment Properties define the values for the volume of the tank. Equipment can also be nested, in that they can contain other Equipment. The tank may also include several sensors such as temperature. The modeller can choose between extra properties or next properties and nest equipment depending on their own criteria. The Equipment Capability Test Specification identifies a test that may be associated with determining the value for a property. The information obtained from running the test can be modelled in the Equipment Capability Test Result.

The Modelling approach for ISA-95 results in multiple levels of Equipment and Equipment Classes. By definition if an Equipment is defined by an Equipment Class then it will have Equipment Properties that correspond to the Equipment Class Properties in the defining Equipment Class.

Physical Assets: Figure 6 is from ISA-95.00.02, it is the physical asset object model. This is an identification of the specific physical asset (by serial number or asset ID) used in manufacturing operations. It also includes the make and model information that identifies the type of physical asset and its properties.

Each instance of the Physical Asset Class defines a classification of Physical Asset, such as a valve. Each class may have specific properties, such as a percent open. These properties can be nested, in that a property can have its own properties. Each Physical Asset is associated to one Physical Asset Classes. This relationship is more like a type of, for example a car would be a Porsche 911 Carrera S, and it could not also be any other model. If the Physical Asset is a car, then the Physical Asset Properties define the values for the colour of the car and maybe the option package associated with the car. The option package would have its own properties such as leather interior, sun roof etc.. Physical Assets can also be nested, in that they can contain other Physical Assets. For example a Car would contain four tires that have their own Physical Asset Class. The Physical Asset Capability Test Specification identifies a test that may be associated with determining the value for a property. The information obtained from running the test can be modelled in the Physical Asset Capability Test Result.

The Modelling approach for ISA-95 results in multiple levels of Physical Assets. By definition if a Physical Asset is defined by a Physical Asset Class then it will have Physical Asset Properties that correspond to the Physical Asset Class Properties in the defining Physical Asset Class.

4.2.5 Key Points

ISA-95 is an abstract specification in that it does not provide any implementation. Other organizations, such as MESA, have created an implementation (B2MML) of the ISA-95 standard. B2MML generated a mapping of the ISA-95 standard that is appropriate for the technology used in the mapping, but the mapping used does not in all cases map well to OPC UA. This specification generates a mapping based on the ISA-95 specification, and where possible it follows the B2MML mapping to allow an easier translation of a B2MML model to an OPC UA Model.

The ISA-95 Model also expects end users to generate a custom model that is based on the defined constructs. The resulting model contains a large amount of information and can require considerable time to develop. The ability to translate a B2MML model to an OPC UA model is an attempt to allow reuse of the extended effort to define a B2MML model.

4.3 OPC UA Summary

4.3.1 Introduction

For ISA-95 user that may not be familiar with OPC UA the following section provides a brief overview of key features that OPC UA provides.

4.3.2 What is OPC UA?

OPC UA is an open and royalty free set of standards designed as a universal communications protocol. While there are numerous communication solutions available, OPC UA has several advantages:

A state of art security model (see OPC 10000-2).

A fault tolerant communication protocol.

An information modelling framework that allows application developers to represent their data in a way that makes sense to them.

OPC UA has a broad scope which delivers for economies of scale for application developers. This means that a larger number of high quality applications at a reasonable cost are available. When combined with powerful semantic models such as ISA-95, OPC UA makes it easier for end users to access data via generic commercial application.

The OPC UA model is scalable from small devices to ERP systems. OPC UA devices process information locally and then provide that data in a consistent format to any application requesting data - ERP, MES, PMS, Maintenance Systems, HMI, Smartphone or a standard Browser, for examples. For a more complete overview see OPC 10000-1.

4.3.3 Basics of OPC UA

As an Open Standard, OPC UA is based on standard Internet technologies – TCP/IP, HTTP, Ethernet, and XML.

As an Extensible Standard, OPC UA provides a set of services (see OPC 10000-4) and a basic information model framework. This framework provides an easy manner for creating and exposing vendor defined information in a standard way. More importantly all OPC UA Clients are expected to be able to discover and use vendor defined information. This means OPC UA users can benefit from the economies of scale that come with generic visualization and historian applications. This specification is an example of an OPC UA Information Model designed to meet the needs of developers and users.

OPC UA Clients can be any consumer of data from another device on the network to browser based thin clients and ERP systems. The full scope of OPC UA applications are shown in Figure 7.

OPC UA provides a robust and reliable communication infrastructure having mechanisms for handling lost messages, failover, heartbeat, etc. With its binary encoded data it offers a high-performing data exchange solution. Security is built into OPC UA as security requirements become more and more important especially since environments are connected to the office network or the internet and attackers are starting to focus on automation systems

4.3.4 Information Modelling in OPC UA

4.3.4.1 Concepts

OPC UA provides a framework that can be used to represent complex information as Objects in an address space which can be accessed with standard web services. These Objects consist of Nodes connected by References. Different classes of Nodes convey different semantics. For example a Variable Node represents a value that can be read or written. The Variable Node has an associated DataType that can define the actual value, such as a string, float, structure etc. It can also describe the variable value as a variant. A Method Node represents a function that can be called. Every Node has a number of Attributes including a unique identifier called a NodeId and non-localized name called as BrowseName. An Object representing a ‘Reservation’ is shown in Figure 8.

Object and Variable Nodes are called Instance Nodes and they always reference a Type Definition (ObjectType or VariableType) Node which describes their semantics and structure. Figure 9 illustrates the relationship between an Instance and its Type Definition.

The Type Nodes are templates that define all of the children that can be present in an Instance of the Type. In the example in Figure 9 the PersonType ObjectType defines two children: First Name and Last Name. All instances of PersonType are expected to have the same children with the same BrowseNames. Within a Type the BrowseNames uniquely identify the child. This means Client applications can be designed to search for children based on the BrowseNames from the Type instead of NodeIds. This eliminates the need for manual reconfiguration of systems if a Client uses Types that multiple devices implement.

OPC UA also supports the concept of sub typing. This allows a modeller to take an existing Type and extend it. There are rules regarding sub typing defined in OPC 10000-3, but in general they allow the extension of a given type or the restriction of a DataType. For example the modeller may decide that the existing ObjectType in some cases needs an additional variable. The modeller can create a Subtype of the object and add the variable. A client that is expecting the parent type can treat the new Type as if it was of the parent Type. With regard to DataTypes, if a variable is defined to have a numeric value, a sub type could restrict the Value to a float.

References allow Nodes to be connected together in ways that describe their relationships. All References have a ReferenceType that specifies the semantics of the relationship. References can be hierarchical or non-hierarchical. Hierarchical references are used to create the structure of Objects and Variables. Non-hierarchical are used to create arbitrary associations. Applications can define their own ReferenceType by creating Subtypes of the existing ReferenceType. Subtypes inherit the semantics of the parent but may add additional restrictions. Figure 10 depicts several references connecting different Objects.

The figures above use a notation that was developed for the OPC UA specification. The notation is summarized in Figure 11. UML representations can also be used; however, the OPC UA notation is less ambiguous because there is a direct mapping from the elements in the figures to Nodes in the address space of an OPC UA server.

A complete description of the different types of Nodes and References can be found in OPC 10000-3 and the base OPC UA Address space is described in OPC 10000-5.

OPC UA specification defines a very wide range of functionality in its basic information model. It is not expected that all Clients or Servers support all functionality in the OPC UA specifications. OPC UA includes the concept of profiles, which segment the functionality into testable certifiable units. This allows the development of companion specification (such as OPC UA for ISA-95) that can describe the subset of functionality that is expected to be implemented. The profiles do not restrict functionality, but generate requirements for a minimum set of functionality (see OPC 10000-7)

The OPC Foundation also defines a set of information models that provide a basic set of functionality. The Data Access specification (see OPC 10000-8) provides a basic information model for typical data. The Alarm and Condition specification (see OPC 10000-9) defines a standard information model for Alarms and Conditions. The Programs specification (see OPC 10000-10) defines a standard information model for extending the functionality available via method calls and state machines. The Historical Access specification (see OPC 10000-11) defines the information model associated with Historical Data and Historical Events. The aggregates specification (see OPC 10000-13) defines a series of standard aggregate functions that allow a Client to request summary data. Examples of aggregates include averages, minimums, time in state, Standard deviation, etc.

4.3.4.2 Namespaces

OPC UA allows information from many different sources to be combined into a single coherent address space. Namespaces are used to make this possible by eliminating naming and id conflicts between information from different sources. Namespaces in OPC UA have a globally unique string called a NamespaceUri and a locally unique integer called a NamespaceIndex. The NamespaceIndex is only unique within the context of a Session between an OPC UA Client and an OPC UA Server. All of the web services defined for OPC UA use the NamespaceIndex to specify the Namespace for qualified values.

There are two types of values in OPC UA that are qualified with Namespaces: NodeIds and QualifiedNames. NodeIds are globally unique identifiers for Nodes. This means the same Node with the same NodeId can appear in many Servers. This, in turn, means Clients can have built in knowledge of some Nodes. OPC UA Information Models generally define globally unique NodeIds for the TypeDefinitions defined by the Information Model.

QualifiedNames are non-localized names qualified with a Namespace. They are used for the BrowseNames of Nodes and allow the same Names to be used by different information models without conflict. The BrowseName is used to identify the children within a TypeDefinitions. Instances of a TypeDefinition are expected to have children with the same BrowseNames. TypeDefinitions are not allowed to have children with duplicate BrowseNames; however, Instances do not have that restriction.

4.3.4.3 Companion Specifications

An OPC UA companion specification for an industry specific vertical market describes an information model by defining ObjectTypes, VariableTypes, DataTypes and ReferenceTypes that represent the concepts used in the vertical market. Table 1 contains an example of an ObjectType definition.

The BrowseName is a non-localized name for an ObjectType.

IsAbstract is a flag indicating whether instances of the ObjectType can be created.

The bottom of the table lists the child nodes for the type. The Reference is the type of reference between the Object instance and the child Node. The NodeClass is the class of Node. The BrowseName is the non-localized name for the child. The DataType is the structure of the Value accessible via the Node (only used for Variable NodeClass Nodes) and the TypeDefinition is the ObjectType or VariableType for the child.

The ModellingRule indicates whether a child is Mandatory or Optional. It can also indicate cardinality. Note that the BrowseName is not defined if the cardinality is greater than 1. Figure 12 visually depicts the ObjectType defined in Table 1 along with two instances of the ObjectType.

4.4 Modelling Approach of ISA-95

The modelling approach for generating an UA model from an existing ISA-95 follows the following general concepts / suggestions.

Review the ISA-95 model documentation.

Map all ISA95 properties to OPC UA Variables and OPC UA VariableTypes, creating OPC UA VariableTypes as needed. Create a subtype of a VariableType whenever the item will be reused multiple times; otherwise just create an instance of the appropriate OPC UA VariableType (Equipment Property Type or PhysicalAssetPropertyType ….).

Map all ISA Classes and ISA Objects to OPC UA ObjectTypes, creating OPC UA ObjectTypes as needed. Again ObjectType need only be created for Objects where multiple instance of the Object will exist, otherwise simply creating an instance of the appropriate ObjectType (EquipmentType, PhysicalAssetType).

Create all types as part of a hierarchical set of types, to allow for easier implementation and maintenance.

Convert IDs that are used to indicate a relationship between ISA-95 Model items to OPC UA References. Use the References defined in this specification as needed. Generate Custom References only if an existing reference does not exist, and the Reference provides some unique semantic information.

Reuse existing OPC UA concepts wherever possible, such as Descriptions, Names, EngineeringUnits etc. These items should not be duplicated as additional ISA properties.

Compare any resulting model to the B2MML model for the same concept. This comparison is to ensure that no concepts were misunderstood or modelled very differently. The goal does include being able to transform a UA model into B2MML and also to transform B2MML Models into UA Models. The two models do not need to be identical, but they need to be transformable.

5 Fundamentals

5.1 Meta-model Mapping Approach

5.1.1 General

ISA-95 defines the meta-models to describe object models using UML notation (See Annex E). This standard defines mapping between the UML notation and the OPC UA meta-model to transform the object model defined in ISA-95 into an OPC UA Address Space Model. (See OPC 10000-3, 0, OPC UA Meta Model)

5.1.2 ISA95Class

ISA95Class is a concept to represent a classification of ISA95 Resource and is represented by a UML Class and an OPC UA ObjectType (see Table 2).

5.1.3 ISA95Object

ISA95Object is a concept to represent resources like a Role Base Equipment and is represented by a UML Class and an OPC UA ObjectType and OPC UA Objects (see Table 3).

5.1.4 ISA95Attribute

ISA95Attribute is a minimum set of industry-independent information and is described in the attribute table defined in ISA-95. ISA-95 doesn’t describe an attribute in UML. In OPC UA it can be represented by Attributes, VariableTypes, Variables, and Properties (see Table 4),

5.1.5 ISA95Property

ISA95Property is a concept to represent characteristics for domain specific information. Accordingly ISA-95 defines that attributes that are application or industry specific are to be modelled in terms of properties and represented in property classes in the model. ISA-95 doesn’t describe a property as an attribute in UML, but describes a property as a Class. In OPC UA it can be represented by VariableTypes and Variables (see Table 5)

5.1.6 Complex Value

5.1.6.1 General

OPC UA allows information to be represented as complex Variables (Variable with nested sub-variable) and/or as complex DataTypes, where a DataType has a structure or other special meaning associated with it. Each of the nested Variables can have a value that represents a simple base DataType such as an Integer or can represent a custom DataType such as a Currency or a structure.

The format of a value is represented by Attributes of Variables. This standard maps all value formats defined in ISA-95 into those attributes.

5.1.6.2 Array value

Arrays of values are represented by DataType, ValueRank, ArrayDimensions, and MaxArrayLength attribute of a VariableType. (See OPC 10000-3). The following examples illustrate the usage of these Attributes:

1. A set of values for a single dimension array of integers with 6 values

2. EBNF: [ 1 , 2 , 3 , 4 , 5 , 6]

3. OPC UA: DataType=Int32(any), ValueRank=OneDimension(1), ArrayDimensions=6, MaxArrayLength=6.

4. A set of values for a two dimension array of size 2x3

5. EBNF: [ [1 , 2] , [3 , 4] ,[5 , 6]]

6. OPC UA: DataType=Int32(any), ValueRank= 2, ArrayDimensions=[2,3], MaxArrayLength=6

7. A set of values for a four dimension array of size 2x3x4x5

8. EBNF: omitted for simplicity

9. OPC UA: DataType=Int32(any), ValueRank= 4, ArrayDimensions=[2,3,4,5], MaxArrayLength=120

5.1.6.3 Range value

Ranges of values are represented by Range DataType defined in OPC 10000-8. If the Range is an array, then ValueRank, ArrayDimensions, and MaxArrayLength attributes are utilized to indicate an array.

1. A simple range of values

2. EBNF: {0..100}

3. OPC UA : DataType=Range, ValueRank= Scalar (−1)

4. A non-continuous range of values

5. EBNF: {0 .. 100 , 200 .. 300 , 500 , 600 .. 650}

6. OPC UA : DataType=Range, ValueRank= OneDimension (1), ArrayDimensions=4

5.1.6.4 Series value

A set of allowed values is defined in EnumStrings and the EnumValues Standard Property of Enumeration DataType.

1. A series of values that defines colours.

2. EBNF: <Red, Green, Yellow, Blue>

3. OPC UA : Array of LocalizedText that is a list of the enumeration strings is set to EnumStrings

5.1.6.5 Structured value

Structured data element is defined in custom DataType derived from Structure DataType or is represented by nested VariableType that has Variables as children.

1. A structured data element represented as flattened Property Name

2. Struct Simple {

3. Integer Position;

4. Float LastValue;

5. Boolean Exists;

6. String Comment;}

7. ISA-95: Simple.Position, Simple.LastValue, Simple.Exists, Simple.Comment

1. A structured data element represented by creating an ISA95Property with no data value with nested child ISA95Properties and identification of element.

2. Struct Simple {

3. public int Position;

4. public double LastValue;

5. public bool Exists;

6. public string Comment;}

7. ISA-95: Property [ID=”Simple”]

8. Property [ID=”Simple”]\ Property [ID=”Position”]

9. Property [ID=”Simple”]\ Property [ID=”LastValue”]

10. Property [ID=”Simple”]\ Property [ID=”Exists”]

11. Property [ID=”Simple”]\ Property [ID=”Comment”]

A combination of a) and b) where a structured data element represented by creating a ISA95 Property with a data value that is a structured data element and with nested child properties and identification of element (see Figure 14). This is the preferred method for modelling complex information. [Note: the figure flow the template defined in OPC 10000-3 with some extensions defined in Annex F]

5.1.7 ISA95Reference

5.1.7.1 General

ISA95Reference is a concept that represents a relationship between modelling targets and is represented by UML Association and by OPC UA ReferenceType (see Table 6).

5.1.7.2 UMLAssociation

UMLAssociation represents an association between elements of a class and elements of another or the same class. The UMLAssociation is transformed to subtypes of OPC UA NonHierarchicalReferences (see Table 7).

Instance Nodes that are referenced by NonHierarchicalReferences are not instantiated when an instance of an ObjectType or VariableType is created.

5.1.7.3 UMLGeneralization

UMLGeneralization is used to describe that an element of UMLClass is a specialized type of the super UML Class, it mapped to the OPC UA HasSubtype ReferenceType.

5.1.7.4 UMLDependence

UMLDependence is a weak association that is used to describe a modelling element that depends on another modelling element. This standard doesn’t support this concept in general terms. Depending on the nature of the dependence it may be modelled as a custom reference.

5.1.7.5 UMLAggregation

UMLAggregation is used to describe that an element of the class is made up of elements of other classes; it is mapped to subtypes of the OPC UA Aggregates ReferenceType (see Table 8).

5.1.7.6 UMLComposite

UMLComposite is used to describe a strong form of aggregation, it is mapped to OPC UA HasComponent or subtypes of OPC UA HasComponent ReferenceType (see Table 9).

5.2 Model Overview

Figure 15 illustrates an overview of ISA-95 OPC UA Information Model. This overview is not complete, additional figures in later section will provide additional details of the information model. ISA-95 Base Information Model defines all models that are commonly utilized in this standard. This model includes a data representation model that is based on UN/CEFACT Core Data Type (CDT) (see UN/ECE). ISA-95 Common Object Model defines the models that represent all ISA95Resources and relationship between them.

6 ISA-95 Data Representation Model

6.1 General

ISA-95 is an abstract specification that has no data model. The B2MML implementation further refined the ISA-95 standard to include a set of standard data types. They selected the UN/CEFACT for this data type definition. These standard data type are now the default data type of ISA-95 Models In order to support transformation between the B2MML mapping and the OPC UA mapping of the ISA-95 Information models a mapping of UN/CEFACT is required.

The UN/CEFACT core component types are a common set of types that define specific terms with semantic meaning, such as the meaning of a quantity, currency, amount, identifier, and language. The UN/CEFACT core components were defined in a core components technical specification (CCTS) developed by the ebXML project now organized by UN/CEFACT and ISO TC 154. This definition also includes supplementary components which provide metadata that refine the value domain. See CCTS for additional information.

This standard defines a data representation model that is compatible with CCTS. The value of a content component is represented by the Value Attribute of a Variable, and the supplemental components that are defined in CCTS are represented as Properties of the DataType. In addition these supplemental Properties may optionally be defined for Variables.

Most of the CDTs, defined in CCTS, are defined as CDT DataTypes in this standard but some CDTs are mapped to OPC UA Built-in DataTypes directly.

All supplemental Properties defined as part of a CDT DataType include the definition of a default value. This allows a Server to not require the addition of the optional Properties, while still allowing a client to obtain the value for the CDT DataType supplemental Properties. However, for some DataTypes or VariableTypes the supplemental Properties may have different values on instances than the default value. For example, a Unit of Measure type depends upon measurement data. In this case, the Server shall duplicate the supplemental Property from the CDT DataType and to the Variable. A client shall try to read the supplemental Property from the Variable first, if the Property does not exist on the variable than the Client shall read the supplemental Property from the CDT DataType.

Third parties may define VariableTypes that rely on CDT DataTypes to enhance data representation methodology. This approach will allow the use of generic clients that support performing actions based on a type system (programming against a type system). Figure 17 illustrates a type definition based on a CDT type. This is an enhanced feature but this standard recommends using the enhanced representation instead of the basic representation model.

Figure 18 illustrates an example of the Amount and the Measure types defined in CCTS. In this example, a value of Currency Property is commonly used in UA Server but a value of Unit Property relates to a measurement value that is temperature.

6.2 Content Component DataType

6.2.1 General

CCTS defines a finite set of primitive data types that shall be used for a Content Component. These data types are mapped to OPC UA CC (Content Component) DataTypes which are OPC UA Built-in DataTypes or DataTypes defined in the following clauses. Table 10 defines mapping between the primitive data types for the Content Component and the CC DataTypes.

6.2.2 CurrencyCode

This is a structured DataType which represents a currency code. Its elements are defined in Table 11.

Its representation in the Address Space is defined in Table 12.

6.2.3 DateString

This DataType defines a value which is a day in the Gregorian calendar in string. Lexical representation of the string conforms to ISO 8601-2000.

According to ISO 8601—2000, ‘calendar date representations are in the form [YYYY-MM-DD]. [YYYY] indicates a four-digit year, 0000 through 9999. [MM] indicates a two-digit month of the year, 01 through 12. [DD] indicates a two-digit day of that month, 01 through 31. For example, "the 5th of April 1981" may be represented as either "1981-04-05" in the extended format or "19810405" in the basic format.’

The standard also allows for calendar dates to be written with reduced precision. For example, one may write "1981-04" to mean "1981 April", and one may simply write "1981" to refer to that year or "19" to refer to the century from 1900 to 1999 inclusive.

Although the standard allows both the YYYY-MM-DD and YYYYMMDD formats for complete calendar date representations, if the day [DD] is omitted then only the YYYY-MM format is allowed. By disallowing dates of the form YYYYMM, the standard avoids confusion with the truncated representation YYMMDD (still often used).

6.2.4 Decimal

This DataType defines a decimal value. The format of this value conforms to the following formula

(-1)^sign x coefficient x 10^exponent

For this release the OPC UA stacks and infrastructure does not support Decimal as a base type, thus this type must be mapped to a ByteString and the ByteString must be passed to the SDK and/or Stack. This DataType has to be handled by the application.

Decimal can be encoded in a number of ways and can be defined to have 32, 64 and 128 varieties. Since the OPC UA stacks do not natively support this encoding only a single Decimal type is being defined. This will allow the stacks in the future to be expanded to support Decimal32, Decimal64 and Decimal128. The encoding of decimal is also defined by more than one group using different encodings. The binary encoding being used for this release (and will always be used for the plain decimal binary string encoding) is a string that is 128 bit and follows the IEC TR 24732 definition for a decimal. It is summarised in the table below.

6.2.5 DecimalString

This primitive DataType defines a value which can be represented by decimal number in string. Lexical representation of the string conforms to W3C XML Schema Definition Language (XSD) 1.1 Part 2: DataTypes.

OPC UA Applications may have the responsibility to encode / decode the DecimalString to an appropriate data type which is supported by the application’s platform. The DecimalString is a numeric string with an optional sign and decimal point.

6.2.6 DurationString

This DataType defines a value which is a string representation of a duration of time. It conforms to lexical rules in ISO 8601-2000.

According to ISO 8601—2000 ‘Durations are represented by the format P[n]Y[n]M[n]DT[n]H[n]M[n]S or P[n]W as shown to the right. In these representations, the [n] is replaced by the value for each of the date and time elements that follow the [n]. Leading zeros are not required, but the maximum number of digits for each element should be agreed to by the communicating parties. The capital letters P, Y, M, W, D, T, H, M, and S are designators for each of the date and time elements and are not replaced.

P is the duration designator (historically called "period") placed at the start of the duration representation.

Y is the year designator that follows the value for the number of years.

M is the month designator that follows the value for the number of months.

W is the week designator that follows the value for the number of weeks.

D is the day designator that follows the value for the number of days.

T is the time designator that precedes the time components of the representation.

H is the hour designator that follows the value for the number of hours.

M is the minute designator that follows the value for the number of minutes.

S is the second designator that follows the value for the number of seconds.

For example, "P3Y6M4DT12H30M5S" represents a duration of "three years, six months, four days, twelve hours, thirty minutes, and five seconds". Date and time elements including their designator may be omitted if their value is zero, and lower order elements may also be omitted for reduced precision. For example, "P23DT23H" and "P4Y" are both acceptable duration representations’

6.2.7 NormalizedString

This DataType defines a value which is a normalized string. Some Unicode characters have multiple equivalent binary representations consisting of sets of combining and/or composite Unicode characters. The Unicode standard defines a process called normalization that returns one binary representation when given any of the equivalent binary representations of a character. The Win32 and the .NET Framework currently support normalization forms C, D, KC, and KD, as defined in Annex15. This definition of NormalizedString uses Normalization Form C for all content, because this form avoids potential interoperability problems arising from the use of canonically equivalent, yet different, character sequences in document formats

6.2.8 TimeString

This DataType defines a value which is the string representation of a time. It conforms to lexical rules in ISO 8601-2000.

ISO 8601 uses the 24-hour clock system. The basic format is [hh][mm][ss] and the extended format is [hh]:[mm]:[ss].

[hh] refers to a zero-padded hour between 00 and 24 (where 24 is only used to notate midnight at the end of a calendar day).

[mm] refers to a zero-padded minute between 00 and 59.

[ss] refers to a zero-padded second between 00 and 60 (where 60 is only used to notate an added leap second).

So a time might appear as either "134730" in the basic format or "13:47:30" in the extended format.

It is also acceptable to omit lower order time elements for reduced accuracy: [hh]:[mm], [hh][mm] and [hh] are all used.

Midnight is a special case and can be referred to as both "00:00" and "24:00". The notation "00:00" is used at the beginning of a calendar day and is the more frequently used. At the end of a day use "24:00"

6.3 Core Data Type DataType

6.3.1 General

All data types defined as CDT are mapped to CDT DataTypes or CC DataTypes. Table 20 defines mapping of data types between CCTS and OPC UA.

Semantic of CDT that is mapped to CC DataType may be defined in ObjectTypes or VariableTypes.

6.3.2 CDTAmountDecimal

The CDTAmountDecimal is a DataType that conforms to Amount type. Table 21 defines the DataTypes.

The CDTAmountDecimal is a number of monetary units specified in a currency. CDTAmountDecimal type is “used to represent amounts, such as costs, remunerations, and fees” from CCTS. All CC types (integer, float…) are mapped to a decimal value.

6.3.3 CDTBinaryObject

The DataType CDTBinaryObject is a subtype of ByteString that defines CCTS binary data based on MIME type. The CDTBinaryObject type is “used for embedding documents such as Word, PDF and/or engineering documents” from CCTS. CDTBinaryObject is differentiated from its related types - CDTGraphic, CDTPicture, CDTSound, and CDTVideo.

MIMEContentType defines the Multipurpose Internet Mail Extensions (MIME) media type of the binary object. This standard recommends use of text code defined in IETF RFC2045, IETF RFC2046 and IETF RFC2047 for the MIME. In this case the MIMEContentType is actually referencing the Content-Type that is defined as part of the MIME type and commonly used as a reference to a specific MIME. The top-level media type is used to declare the general type of data, while the subtype specifies a specific format for that type of data. Thus, a media type of "image/xyz" is enough to tell a user agent that the data is an image, even if the user agent has no knowledge of the specific image format "xyz". Such information can be used, for example, to decide whether or not to show a user the raw data from an unrecognized subtype such an action might be reasonable for unrecognized subtypes of "text", but not for unrecognized subtypes of "image" or "audio".

CharacterSet defines a specific character set of text data if MIME is text. This standard recommends use of text code defined in IANA for the CharacterSet.

Encoding defines an encoding/decoding mechanism of the Binary Object. If contents of the Binary Object are encoded in specific formats, UA Server represents the formats using this supplemental to indicate a code to identify the encoding. Generally, UA Server doesn’t need to encode Binary Objects since the UA Stack always Encodes Messages in the appropriate format defined in OPC 10000-6. This standard recommends the use of text codes defined in IETF RFC2045, IETF RFC2046 and IETF RFC2047 for the Encoding.

MIMEListId represents the identification of a list of codes (refers to the MIMEContentType).

MIMEListAgencyId represents the identification of the agency that manages the code list (refers to the MIMEContentType).

MIMEListVersionId represents the identification of the version of the list of codes (refers to the MIMEContentType).

CharacterSetListId represents the identification of a list of codes (refers to the CharacterSet).

CharacterSetListAgencyId represents the identification of the agency that manages the code list (refers to the CharacterSet).

CharacterSetListVersionId represents the identification of the version of the list of codes (refers to the CharacterSet).

EncodingListId represents the identification of a list of codes (refers to the Encoding).

EncodingListAgencyId represents the identification of the agency that manages the code list (refers to the Encoding).

EncodingListVersionId represents the identification of the version of the list of codes (refers to the Encoding).

Filename defines the recommended file name that can be used to store data. The file name is usually the name of the original data file that is represented in the Binary Object.

6.3.4 CDTCode

The DataType CDTCode is a subtype of String that defines CCTS Code type. The CDTCode Type is a character string (letters, figures or symbols) that for brevity and/or language independence may be used to represent or replace a definitive value or text of an attribute” from CCTS.

OPC UA Client may have the code list as its implementation or OPC UA Server may provide it in an Address Space. OPC UA Application will get symbol of a code from the code list in any case.

ListId represents the identification of a list of codes.

ListAgencyId represents the identification of the agency that manages the code list.

ListVersionId represents the identification of the version of the list of codes.

6.3.5 CDTDateTime

The DataType CDTDateTime is a subtype of DateTime that defines CCTS DateTime. The DateTime identifies a date and time of day to various common resolutions: year, month, week, day, hour, minute, second, and fraction of second from CCTS and is used to represent a Gregorian calendar date with UTC time.

The Timezone can be used to indicate the time zone associated with the data source. The UtcTime value is in GMT and does not have a time zone factor applied. This parameter is provided to allow a client to display the provided time in the time zone that was associated with to original value.

The DaylightSavings can be used to indicate daylights saving if DaylightSavings was in effect when for the given DateTime. The UtcTime value is in GMT and does not have a Timezone factor applied. This parameter is provided to allow a client to display the provided time with the daylight savings time adjustment that was associated with to original value.

6.3.6 CDTGraphic

The DataType CDTGraphic is a subtype of ByteString that defines CCTS Graphic type. The CDTGraphic type is used to represent binary data and binary files for vector based graphics, such as CAD drawings, diagrams, graphs, mathematical curves and charts from CCTS.

MIMEContentType defines the Multipurpose Internet Mail Extensions (MIME) media type of the binary object. For additional information see 6.3.3

MIMEListId represents the identification of a list of codes (refers to the MIMEContentType).

MIMEListAgencyId represents the identification of the agency that manages the code list (refers to the MIMEContentType).

MIMEListVersionId represents the identification of the version of the list of codes (refers to the MIMEContentType).

Filename defines the recommended file name that can be used to store data. The file name is usually the name of the original data file that is represented in the Binary Object.

6.3.7 CDTIdentifier

The DataType CDTIdentifier is a subtype of String that defines CCTS Identifier Type. The CDTIdentifier type is an identifier is a character string used to uniquely identify one instance of an object within an identification scheme that is managed by an agency from CCTS.

SchemeId represent the identification of the identifier scheme.

SchemeVersionId represents the identification of the version of the identifier scheme.

SchemeAgencyId represents the identification of the agency that manages the identifier scheme.

6.3.8 CDTMeasure

The CDTMeasure is a generic term for DataTypes that conform to the Measure type. The actual DataTypes are defined separately according to each primitive data type of content component. Table 28 defines the DataTypes.

The CDTMeasure is a numeric value determined by measuring an object along with the specified unit of measure. It “is used to represent a kind of physical dimension such as temperature, length, speed, width, weight, volume, latitude of an object. More precisely, it should be used to measure intrinsic or physical properties of an object seen as a whole according to CCTS.

Unit defines measurement units defined in OPC 10000-8. EUInformation identifies unit by three letters specified in Unit element. This rule is reasonable if code set of Unit is based on UNECE. Otherwise, code shall be set into Display, and Unit shall be set to (-1).

NOTE: OPC 10000-8 defines EUInformation DataType to indicate code of the unit defined in UN/ECE. This standard uses the EUInformation to represent code defined in UN/ECE instead of CDTCode.

6.3.9 CDTOrdinal

The DataType CDTOrdinal is a subtype of Int32 that defines CCTS Ordinal type. It is an assigned mathematical number that represents order or sequence according to CCTS.

6.3.10 CDTPicture

The DataType CDTPicture is a subtype of Image that defines CCTS Picture type. It is a visual representation of a person, object, or scene in binary notation (octets). It should be used for embedding binary data of pictures such as photos, art, and clip art according to CCTS. If no supplemental data is to be provided it is also acceptable to directly map any CDTPicture data to a subtype of the standard OPC UA Image dataType (ImageBMP, ImageGIF, ImageJPG, ImagePNG).

The MIMEContentType supplemental property is rarely used, since in most cases the picture binary blob includes header information that includes the MIME information. Most applications can just obtain the information directly from the picture blob

MIMEContentType defines the Multipurpose Internet Mail Extensions (MIME) media type of the binary object. For additional information see 6.3.3

MIMEListId represents the identification of a list of codes (refers to the MIMEContentType).

MIMEListAgencyId represents the identification of the agency that manages the code list (refers to the MIMEContentType).

MIMEListVersionId represents the identification of the version of the list of codes (refers to the MIMEContentType).

Filename defines the recommended file name that can be used to store data. The file name is usually the name of the original data file that is represented in the Binary Object.

6.3.11 CDTRate

The CDTRate is a generic term for DataTypes that conform to the Rate type. The actual DataTypes are defined separately according to each primitive data type of content component. Table 32 defines the DataTypes.

The CDTRate is a quantity, amount, frequency, or dimensionless factor, measured against an independent base unit, expressed as a quotient. In addition CCTS describe it is used to represent the numerical quotient resulting from a comparison of two independent things such as a quantity measured with respect to another measured quantity such as a rate of speed, a measure of a part with respect to a whole - a proportion such as the mortality rate, a tax rate, the cost per unit of a commodity or service or a charge or payment calculated in relation to a particular sum or quantity such as interest rates. The quotient is calculated by taking into account the Rate.Multiplier.Value and Rate.Base.Multiplier. Value supplementary components that affect the unit codes used at the numerator and the denominator.

Multiplier defines multiplier of the numerator. The default value is "1" if the element is omitted.

Unit defines the unit of measure of the numerator. The Unit is represented in EUInformation defined in OPC UA Part8.

Currency defines the currency unit of the numerator.

BaseMultiplier defines multiplier of the denominator. The default value is "1" if the element is omitted.

BaseCurrency defines the currency unit of the denominator BaseUnit defines the unit of measure of the denominator. The BaseUnit is represented in EUInformation defined in OPC UA Part8.

6.3.12 CDTSound

The DataType CDTSound is a subtype of ByteString that defines CCTS Sound type. It is any form of an audio file such as audio recordings in binary notation according to CCTS.

The MIMEContentType supplemental property is rarely used, since in most cases the sound binary blob includes header information that includes the MIME information. Most applications can just obtain the information directly from the sound blob

MIMEContentType defines the Multipurpose Internet Mail Extensions (MIME) media type of the binary object. For additional information see 6.3.3

MIMEListId represents the identification of a list of codes (refers to the MIMEContentType).

MIMEListAgencyId represents the identification of the agency that manages the code list (refers to the MIMEContentType).

MIMEListVersionId represents the identification of the version of the list of codes (refers to the MIMEContentType).

FileName defines the recommended file name that can be used to store data. The file name is usually the name of the original data file that is represented in the Binary Object.

6.3.13 CDTVideo

The DataType CDTVideo is a subtype of ByteString that defines CCTS Video type. It is a recording, reproducing or broadcasting of visual images on magnetic tape or digitally in binary notation.

The MIMEContentType supplemental property is rarely used, since in most cases the Video blob includes header information that includes the MIME information. Most applications can just obtain the information directly from the Video blob

MIMEContentType defines the Multipurpose Internet Mail Extensions (MIME) media type of the binary object. For additional information see 6.3.3

MIMEListId represents the identification of a list of codes (refers to the MIMEContentType).

MIMEListAgencyId represents the identification of the agency that manages the code list (refers to the MIMEContentType).

MIMEListVersionId represents the identification of the version of the list of codes (refers to the MIMEContentType).

Filename defines the recommended file name that can be used to store data. The file name is usually the name of the original data file that is represented in the Binary Object.

7 ISA-95 Base Information Model

7.1 Overview

Figure 19 illustrates overview of the ISA-95 Base Information Model.

7.2 Test Specification Information

The test specification is a definition of a test to ensure the requirements of the ISA95Objects. The test specification may be associated with a subtype of ISA95Class, ISA95ClassProperty, ISA95Object, or ISA95Property.

The test specification is represented as Object and doesn’t define elements that represent contents of the test specification. Thus, third party shall create a subtype of the test specification to describe particular test specification (see Figure 20).

For example, the subtype of test specification might have an Object of FileType (defined in OPC 10000-5) that indicates a file for the document that describes a test specification. If a test specification is stored as a file. This type is sub-typed as part of the individual data models to allow easy identification of the type of test specification being referenced, i.e. Equipment Test specification or Physical Asset test specification. It is envisioned that implementers of ISA-95 Models would create subtypes of the data model specific test specification.

7.3 Test Result Information

The test result is the result from an execution of a test specification. An ISA95Property may have a variable that provides the test result. These test results could be time series data that would be accessed by standard Attribute Services as defined in OPC UA Part4.

The test result is represented as DataVariable. The DataType of the VariableType is a structure that represents the various elements of the test result. (See Figure 21 for an example).

The test results listed in the figure are a minimum set of information that all test result shall include, but individual systems may provide their own structure that includes additional information. For example some systems may require the name of the person that conducted the test and the qualification that the person had. A new structure can be created that includes all of the original items along with a field for the person information and a field for the person’s qualifications. The new record can then be used for the test results.

7.4 DataTypes

7.4.1 ISA95EquipmentElementLevelEnum

This DataType is an enumeration that defines the equipment element levels defined in ISA-95. Its values are defined in a below table.

Its representation in the OPC UA AddressSpace is defined in a below table.

7.4.2 ISA95TestResultMeasurementDataType

This structure contains elements that records the result from the execution of a test identified in a Test Specification.

Its representation in the AddressSpace is defined in a below table.

7.4.3 ISA95TestResultDataType

This structure contains elements that records the result from the execution of a test identified in a Test Specification. This data type shall be the default DataType for test results.

Its representation in the AddressSpace is defined in a below table.

7.5 VariableTypes

7.5.1 Overview

The section defines common variable types that are used by multiple section of the ISA specification (i.e. equipment and physical assets etc.) In some cases these types define a generic version of the variable that will be further customized in the specific section, i.e. equipment or physical asset variable section.

The variable types defined in the following sections make use of reference types that are defined in section 0. These reference types provide specific semantic information. To fully understand the Variable or Object models it may be required to review these reference descriptions.

7.5.2 ISA95ClassPropertyType

The ISA95ClassPropertyType is an abstract VariableType that cannot be used directly. It must be subtyped to be used. It is a subtype of BaseDataVariableType defined in OPC 10000-5.

This VariableType is used to define an ISA95ClassProperty for an ISA95Class.

The Key defines an Id to differentiate between the different values. When multiple values are stored to the Value attribute this ISA95Attribute is used. For example a value may be a series of numbers, such as a series of peak values from a spectrometer.

7.5.3 ISA95PropertyType

The ISA95PropertyType is an abstract VariableType that cannot be used directly. It must be subtyped to be used. It is a subtype of BaseDataVariableType defined in OPC 10000-5.

This VariableType is used to define an ISA95Property for an ISA95Object.

Key defines an Id to differentiate between the different values. When multiple values are stored to Value attribute this ISA95Attribute is used. For example a value may be a series of numbers, such as a series of peak values from spectrometer.

7.5.4 ISA95TestResultType

The ISA95TestResultdType is a concrete VariableType that can be used directly. It is a subtype of BaseDataVariableType defined in OPC 10000-5.

This VariableType indicates the test results. Value attribute of this DataVariable is structured data. However, each element of the structure can be accessed via Properties.

Note: The Variable has a DataType of Structure which is generic and must be assigned to a defined sub-type before it is transmitted on the wire. The generic Structure DataType results in an ExtensionObject being placed on the wire. The default defined sub-type is either ISA95TestResultDataType or ISA95TestResultMeasurementDataType depending on the nature of the data. If a different structure is used, it shall include all of the fields defined in this structure and the defined sub-type of this variable type shall also include any additional fields that are in the structure as separate variables.

Id is an identifier of the Test Result. This field can be used to reference the actual result.

ResultDescription is an additional information or description of the test result.

TestDate is the date and time of the test. This Time is used to determine when a test expires, it is server specific as to whether it is a test start time or end time, but it should be consistent in all cases.

Result is the result of the test (further defined in subtypes).

ResultUnitOfMeasure is the unit of measure of the associated test result. It is defined as a structure to allow either a EUInformation or a measurement code (clause 6.3.8) to be reported.

Expiration is the date of the expiration of the test result.

7.6 ObjectType

7.6.1 Overview

The section defines common object types that are used by multiple section of the ISA specification (i.e. equipment and physical assets etc.) In some cases these types define a generic version of the object that will be further customized in the specific section, i.e. equipment or physical asset variable section.

The object types defined in the following sections make use of reference types that are defined in section 0. These reference types provide specific semantic information. To fully understand the Object models it may be required to review these reference descriptions.

7.6.2 ISA95ClassType

The ISA95ClassType is an abstract ObjectType that cannot be used directly. It is a subtype of BaseObjectType defined in OPC 10000-5.

This abstract ObjectType is used to define groupings of functionality that is associated with an ISA95Object. AnyISA95Object may be associated with zero or more ISA95Classes.

Objects of this ObjectType or its subtypes may be associated to ISA95TestSpecifications or their subtypes.

7.6.3 ISA95ObjectType

The ISA95ObjectType is an abstract ObjectType that cannot be used directly. It is a subtype of BaseObjectType defined in OPC 10000-5.

7.6.4 ISA95TestSpecificationType

The ISA95TestSpecificationType is an abstract ObjectType that cannot be used directly. It is a subtype of BaseObjectType defined in OPC 10000-5.

This ObjectType is a base ObjectType that has no elements that describe the test specification, it is expected that sub types of this ObjectType will be created by implementers of this standard and will define the details associated with a test specification. This ObjectType indicates the existence of a test specification. This is typically used where a test is required to ensure capability of a modelling target such as ISA95Person.

Version is a version of the test specification.

8 ISA-95 Common Object Model

8.1 Personnel Information

8.1.1 Overview

The personnel model in ISA-95 is an abstract model that allows the definition of person and roles that individual persons can be assigned to PersonnelClasses (see Figure 22). The requirements associated with a given role may include specific training or certification. It may be related to Job Titles or skills. A single person may be associated with multiple roles. Persons may be grouped into a type of Person, to allow properties to be associated with all persons that fall into the given type. For example a Person Type of Operator type may allow, multiple operators to have the same defined qualification tests, some of which are defined by the operator role, others may be defined by safety role or a role for a specific type of equipment.

Figure 23 illustrates personnel model which consists of specific person, ISA95Classes of personnel, and qualification of personnel. It includes an example subtype that illustrates creating customized sub type of PersonnelClass. The illustration further illustrates creating actual instance of the individual types and how multiple classes can be combined into a single instance. This figure does not illustrate how a subtype of PersonType can be created and used to classify multiple persons as being of the same type. The concept of a sub type of PersonType is allowed, but since most persons would have unique training and classification in many cases subtypes of PersonType would not exist.

8.1.2 VariableTypes

8.1.2.1 QualificationTestResultType

The QualificationTestResultType is a concrete VariableType that can be used directly. It is a subtype of ISA95TestResultType VariableType defined in 7.5.4.

This VariableType indicates the results from a qualification test for a specific person.

This variable type according to ISA-95 shall have prior and or multiple results available depending on the vendor specific model. To accommodate this requirement, vendors will be required to support historical storage of instances of QualificationTestResultType.

8.1.2.2 PersonnelClassPropertyType

The PersonnelClassPropertyType is a concrete VariableType that can be used directly. It is a subtype of ISA95ClassPropertyType defined in 7.5.4.

This VariableType indicates ISA95ClassProperties for ISA95PersonnelClass. Variables of this VariableType may be associated to the qualification test specification defined in 8.1.3.1.

<PropertyName> is a placeholder for possible additional nested instances of PersonnelClassPropertyType. These properties can have any name but shall be referenced using the HasISA95ClassProperty reference and shall be of type PersonnelClassPropertyType or a subtype of it.

<TestSpecification> is a placeholder for any test specification that this instance of a PersonnelClassPropertyType conforms to. These test specifications can have any name but shall be referenced using the TestedByQualificationTest Reference and shall be of type QualificationTestSpecificationType or a subtype of it.

8.1.2.3 PersonPropertyType

The PersonPropertyType is a concrete VariableType that can be used directly. It is a subtype of ISA95PropertyType defined in7.5.3.

This VariableType indicates ISA95Properties of a person. Person ISA95Property may be related to the qualification test specification defined in 8.1.3.1 and may be tested by the execution of the qualification test specification.

<TestResult> is the results associated with qualification tests for this PersonPropertyType. These test results can have any name but shall be referenced using the HasTestResult Reference and shall be of type QualificationTestResultType or a subtype of it. In addition each <TestResult> shall have a ResultsForSpecification Reference to the instance of a QualificationTestSpecificationType that is associated to the given test result record. It is recommended that the names assigned to the object of QualificationTestSpecificationType and the <TestResult> variable follow some naming convention, to allow operators to more easily match test results to the test specification that they are for.

<PropertyName> is a placeholder for possible additional nested instances of PersonPropertyType. These instances of PersonPropertyType can have any name but shall be referenced using the HasISA95Property reference and shall be of type PersonPropertyType or a subtype of it.

<TestSpecification> is a placeholder for any test specification that this PersonPropertyType conforms to. These test specifications can have any name but shall be referenced using the TestedByQualificationTest Reference and shall be of type QualificationTestSpecificationType or a subtype of it.

8.1.3 ObjectTypes

8.1.3.1 QualificationTestSpecificationType

The QualificationTestSpecificationType is a concrete ObjectType that can be used directly. It is a subtype of ISA95TestSpecificationType defined in7.6.4.

This ObjectType indicates a qualification test specification. A qualification test specification may be associated with an ISA95PersonnelClass, an ISA95PersonnelClassProperty, an ISA95Person, or ISA95Person Property. This is typically used where a qualification test or ISA95Properly demonstrated competency is required to ensure that an ISA95Person has the correct training and/or experience for specific operations. A qualification test specification may test for one or more ISA95Properties.

8.1.3.2 PersonnelClassType

The PersonnelClassType is a concrete ObjectType that can be used directly. It is a subtype of ISA95ClassType defined in7.6.2.

This ObjectType indicates a grouping of persons with similar characteristics for a definite purpose such as manufacturing operations definition, scheduling, capability and performance. A subtype of PersonnelClassType may be associated to qualification test specification(s).

<PropertyName> is a placeholder for possible additional nested PersonnelClasses. These properties can have any name but shall be referenced using the HasISA95ClassProperty reference and shall be of type PersonnelClassPropertyType or a sub type of it

<TestSpecification> is a placeholder for any test specification that this PersonnelClass conforms to. These test specifications can have any name but shall be referenced using the TestedByQualificationTest Reference and shall be of type QualificationTestSpecificationType or a subtype of it

8.1.3.3 PersonType

The PersonType ObjectType is a concrete ObjectType that can be used directly. It is a subtype of ISA95ObjectType ObjectType defined in7.6.3.

This ObjectType indicates a specifically identified individual. A person may be tested by the execution of a qualification test specification.

<PropertyName> is a placeholder for variable of PersonPropertyType. These Variables can have any name but shall be referenced using the HasISA95ClassProperty reference and shall be of type PersonPropertyType or a sub type of it

<PersonnelClass> is a placeholder for Object classifications that are used to define this person. These classifications can have any browse name but they shall be of PersonnelClassType and shall be referenced by DefinedByPersonnelClass ReferenceType

<TestSpecification> is a placeholder for any test specification that this Person conforms to. These test specifications can have any name but shall be referenced using the TestedByQualificationTest Reference and shall be of type QualificationTestSpecificationType or a subtype of it

8.2 Role based Equipment Information

8.2.1 Overview

The ISA-95 Equipment Model is an abstract model that describes classes of logical equipment. The physical equipment is defined by physical assets. In the ISA-95 model, a logical device (equipment) usually does not change, but a physical device may change over time. For example a meter is being used, but it requires service, thus it is replaced by an identical meter. The Physical device gets changed, but in the logic of the system the equipment has not changed. The ISA-95 model further defines classes of equipment that define general functionality or features of a logical piece of equipment. These classes of equipment (EquipmentClassType) would be defined by an EquipmentClassType. Instances of these classes of Equipment are referenced by an EquipmentType, which is a definition of a logical piece of equipment. In a running system there would be multiple instances of the EquipmentType. There would also be multiple EquipmentClassTypes. Figure 24 provides an illustration of this concept. It is also acceptable to define subtypes of EquipmentType, where the associated EquipmentClassType never change and multiple instances of the subtype of EquipmentType exist.

Figure 23 illustrates the Equipment Information model which consists of Equipment Types and EquipmentClassTypes. The illustration includes the definition of subtypes of EquipmentClassType, an instance of Equipment, and a subtype of EquipmentType. Any subtype of EquipmentType includes additional restrictions on Instance of the subtype such as the instance can never remove an associated EquipmentClassType.

The role based equipment model contains information about specific equipment, equipment classes, equipment capability tests, and maintenance information associated with equipment. It can also contain information about related Physical Assets. The information about the related Physical Asset is represented as asset assignment information

The asset assignment information would be part of the Equipment model as well as part of the Physical Asset model. The asset assignment information could be time series data and is accessed by standard Attribute Services as defined in OPC 10000-4.

The asset assignment information is represented as DataVariable that is part of the Equipment or Physical Asset. The DataType of the asset assignment VariableType is a structure that represents elements of the asset assignment information. This standard only defines basic information regarding the asset assignment. Third parties may create a subtype of this VariableType to represent third party specific information of an asset assignment. (See Figure 26)

8.2.2 DataTypes

8.2.2.1 ISA95AssetAssignmentDataType

This structure contains elements that record the asset assignment.

Its representation in the AddressSpace is defined in Table 55.

8.2.3 VariableTypes

8.2.3.1 ISA95AssetAssignmentType

The ISA95AssetAssignmentType is a concrete VariableType that can be used directly. It is a subtype of BaseDataVariableType defined in OPC 10000-5.

This VariableType is used to track the asset assignment, It is usually includes history. The Variables associated with VariableType provide the asset assignment information. The structure of asset assignment information can be extended. Therefore, third party may design particular structure for the asset assignment information. This standard defines the minimum information elements for the asset assignment.

This variable type according to ISA-95 shall maintain prior and/or support multiple results depending on the vendor specific information model. To accommodate this requirement, vendors will be required to support historical storage of the value for instances of ISA95AssetAssignmentType.

From history a user can determine all of the physical assets that were used to represent this logical piece of equipment. Also the history of all logical equipment a particular physical asset was assigned to can be reviewed, when this variable is used on a physical asset.

Id is an identifier of the asset assignment information. This id is the NodeId of the instance of PhysicalAssetType that is currently assigned to this piece of equipment (if this variable is part of an Equipment object). This VariableType is also used for PhysicalAssetType objects, in which case this id would be the NodeId of the instance of the EquipmentType that the physical asset is assigned to.

AssignmentDescription is an additional information or description of the assignment.

StartTime is the time at which the asset assignment was made.

StopTime is the time at which the asset assignment was change / ended.

This standard defines ISA95AssetAssignmentDataType as the default DataType. Third parties may define their own structure that contains additional elements, but it must still contain all the elements defined in the ISA95AssetAssignmentDataType. It is also recommended that any new items that are added to the new ISA95AssetAssignmentDataType also be added to the new subtype of the ISA95AssetAssignmentType variable type.

8.2.3.2 EquipmentCapabilityTestResultType

The EquipmentCapabilityTestResultType is a concrete VariableType that can be used directly. It is a subtype of ISA95TestResultType VariableType defined in 7.5.4.

This VariableType indicates the results from an Equipment test.

This variable type according to ISA-95 shall have prior and or multiple results available depending on the vendor specific model. To accommodate this requirement, vendors will be required to support historical storage of instances of EquipmentCapabilityTestResultType

8.2.3.3 EquipmentClassPropertyType

The EquipmentClassPropertyType is a concrete VariableType that can be used directly. It is a subtype of ISA95ClassPropertyType defined in 7.5.4.

This VariableType indicates ISA95ClassProperties for an EquipmentClassType. Variables of this VariableType may be associated to an instance of an EquipmentCapabilityTestSpecificationType defined in 8.1.3.1.

<PropertyName> is a placeholder for possible nested instances of EquipmentClassPropertyType. These properties can have any name but shall be referenced using the HasISA95ClassProperty reference and shall be of type EquipmentClassPropertyType or a subtype of it

<TestSpecification> is a placeholder for any test specification that this EquipmentClassPropertyType is tested by. These test specifications can have any name but shall be referenced using the TestedByEquipmentTest Reference and shall be of type EquipmentCapabilityTestSpecificationType or a subtype of it.

8.2.3.4 EquipmentPropertyType

The EquipmentPropertyType is a concrete VariableType that can be used directly. It is a subtype of ISA95PropertyType defined in 7.5.3.

This VariableType indicates ISA95Properties of a role based equipment. An instance of an EquipmentPropertyType may be related to instances of EquipmentCapabilityTestSpecificationType defined in 8.1.3.1 and may be tested by the execution of the equipment test specification with results exchanged in an equipment test result.

<TestResult> is the optional results associated with an EquipmentCapabilityTestSpecificationType. These test results can have any name but shall be referenced using the HasTestResult Reference and shall be of type EquipmentCapabilityTestResultType or a subtype of it. In addition each <TestResult> shall have a ResultsForSpecification Reference to the instance of EquipmentCapabilityTestSpecificationType that it is associated with. It is recommended that the names assigned to the instance of the EquipmentCapabilityTestSpecificationType object and the <TestResult> variable follow some naming convention, to allow operators to more easily match test results to the test specification that they are for.

<PropertyName> is a placeholder for possible additional nested instances of EquipmentPropertyTypes. These properties can have any name but shall be referenced using the HasISA95Property reference and shall be of type EquipmentPropertyType or a subtype of it

<TestSpecification> is a placeholder for any capability test specification that an instance of this EquipmentPropertyType conforms to. These test specifications can have any name but shall be referenced using the TestedByEquipmentTest Reference and shall be of type EquipmentCapabilityTestSpecificationType or a subtype of it

8.2.4 ObjectTypes

8.2.4.1 EquipmentCapabilityTestSpecificationType

The EquipmentCapabilityTestSpecificationType is a concrete ObjectType that can be used directly. It is a subtype of ISA95TestSpecificationType defined in 7.6.4.

This ObjectType indicates an equipment capability test. An equipment capability test may be associated with an EquipmentClassType and an instance of an EquipmentClassPropertyType, an instance of EquipmentType or an instance of EquipmentPropertyType. This is typically used where a test is required to ensure that the equipment has the necessary capability and capacity. An instance of an EquipmentCapabilityTestSpecificationType may be associated with more than one EquipmentClassType and also to more than one instance of an EquipmentType and also to more than one subtype of an EquipmentType.

8.2.4.2 EquipmentClassType

The EquipmentClassType is an abstract ObjectType; it is expected to be subtyped. It is a subtype of ISA95ClassType defined in 7.6.2.

This ObjectType indicates a grouping of equipment with similar characteristics for a definite purpose such as manufacturing operations definition, scheduling, capability and performance. The EquipmentClassType may be associated to objects of an EquipmentCapabilityTestSpecificationType. It is expected that subtypes of the EquipmentClassType will be created that represent a particular class of equipment. These subtypes will have their own set of instance of EquipmentClassPropertyType and EquipmentCapabilityTestSpecificationType.

<PropertyName> is a placeholder for possible additional nested instances of EquipmentClassPropertyType. These properties can have any name but shall be referenced using the HasISA95ClassProperty reference and shall be of type EquipmentClassPropertyType or a subtype of it

<TestSpecification> is a placeholder for any capability test specification that this EquipmentClassType conforms to. These capability test specifications can have any name but shall be referenced using the TestedByEquipmentTest Reference and shall be of type EquipmentCapabilityTestSpecificationType or a subtype of it

EquipmentLevel is an identification of the level in the role based equipment hierarchy.

8.2.4.3 EquipmentType

The EquipmentType is a concrete ObjectType that can be used directly. It is a subtype of ISA95ObjectType defined in 6.7.2.

This ObjectType defines a piece of equipment. Equipment may be tested by the execution of one or more tests defined by EquipmentCapabilityTestSpecificationType. Individual instance of this EquipmentType would have one or more reference(s) to EquipmentClassType(s) that the instance of the EquipmentType is defined by. A subtype of EquipmentType may also be defined for a fixed set of referenced EquipmentClassTypes. By definition of the ISA-95 model, when an Equipment instance or a sub type of EquipmentType references an EquipmentClassType, the addition of said reference results in the addition of all instances of EquipmentClassPropertyType defined for the referenced EquipmentClassType to the Equipment instance (or EquipmentType subtype) as instances of EquipmentPropertyType. These instances of EquipmentPropertyType will have all the same Attributes and Properties as the corresponding EquipmentClassPropertyType instance. This includes the same value for the BrowseName, DisplayName, Description and any other properties.

This ObjectType may be further subtyped. The subtypes create some additional restrictions. Any EquipmentClassType references that are added to a subtype of an EquipmentType cannot be removed from an instance of the subtype. If the EquipmentType subtype is updated then all instance of the EquipmentType subtype must also be updated. For example if an additional EquipmentClassType is added to the EquipmentType subtype that that EquipmentClassType must be added to all instances of the EquipmentType subtype. This allows for creating a single EquipmentType that is used for multiple EquipmentType instances.

Equipment may be made of other equipment.

<PropertyName> is a placeholder for possible additional instances of EquipmentPropertyType. These properties can have any name but shall be referenced using the HasISA95Property reference and shall be of type EquipmentPropertyType or a subtype of it

<EquipmentClass> is a placeholder for possible related EquipmentClassTypes These EquipmentClassTypes can have any name but shall be referenced using the DefinedByEquipmentClass reference and shall be an EquipmentClassType or a subtype of it

<TestSpecification> is a placeholder for any capability test specification that instances of this EquipmentType conform to. These test specifications can have any name but shall be referenced using the TestedByEquipmentTest Reference and shall be of type EquipmentCapabilityTestSpecificationType or a subtype of it

<Equipment> is a placeholder for sub instances of EquipmentType. These instances of EquipmentType can have any name but shall be referenced using the MadeUpOfEquipment reference and shall be an instance of EquipmentType or a subtype of it

EquipmentLevel is an identification of the level in the role based equipment hierarchy.

PhysicalAsset is an instance of a PhysicalAssetType that is assigned to this instance of an EquipmentType.

AssetAssignment – Is used to track the history of the physical assets assigned to this logical equipment.

8.3 Physical Asset information

8.3.1 Overview

The ISA-95 Physical Asset Model includes defining the class of physical devices that exist in a system as well as the actual physical devices. These definitions include manufacturing related information for classes of devices and actual vendor related information for instances of physical devices. Figure 27 illustrate this abstract model and the relationships that are modelled in the OPC UA Information model. For a description of the relationship between physical assets and equipment see section 8.2.1.

Physical Assets can be composed of other Physical Assets. Physical Asset classes describe a general classification of an asset, which may be supplied by multiple vendors, each with unique model numbers. Vendors may have additional information associated with them. Individual instance of a particular Physical Asset would have a serial number that is provided by the vendor that supplied the device.

Figure 28 illustrates Physical Asset Information Model in terms of the OPC UA Information Model. This model illustrates the base Physical Asset model. It further provides an example set of possible subtypes of PhysicalAssetClassTypes and instances of Physical Assets.

8.3.2 VariableTypes

8.3.2.1 CompanyType

The CompanyType is a concrete VariableType that can be used directly. It is a subtype of BaseDataVariableType defined in OPC 10000-5

This VariableType is used to provide details regarding company information for PhysicalAssetClassTypes or for instances of PhysicalAssetType. In most instances this type will be further subtyped to provide additional information regarding the company. The ISA-95 specification does not define a structure or set of fields for company information. Some systems will provide a list of additional information, such as address, contact and other details. Other system may simply provide a link or reference to some other system that provides the detailed company information. In later sections, this specification will provide a TypicalCompanyType (see D.3) that can be used as a default if no other linked system exists. This type could also be further subtyped as needed.

8.3.2.2 GeoSpatialLocationType

The GeoSpatialLocationType is a concrete VariableType that can be used directly. It is a subtype of PropertyType defined in OPC 10000-3

This VariableType is used to provide details regarding Physical Location information for PhysicalAssetClassType

8.3.2.3 PhysicalAssetCapabilityTestResultType

The PhysicalAssetCapabilityTestResultType is a concrete VariableType that can be used directly. It is a subtype of ISA95TestResultType defined in 7.5.4.

This VariableType indicates the results from a physical asset capability test for a specific physical asset.

This variable type according to ISA-95 shall have prior and or multiple results available depending on the vendor specific model. To accommodate this requirement, vendors will be required to support historical storage of instances of PhysicalAssetCapabilityTestResultType.

8.3.2.4 PhysicalAssetClassPropertyType

The PhysicalAssetClassPropertyType is a concrete VariableType that can be used directly. It is a subtype of ISA95ClassPropertyType defined in 7.5.4.

This VariableType indicates ISA95ClassProperties for a PhysicalAssetClassType. Variables of this VariableType may be associated with tests defined by PhysicalAssetCapabilityTestSpecificationType defined in 8.3.3.1.

<PropertyName> is a placeholder for possible additional nested instances of PhysicalAssetClassPropertyType. These properties can have any name but shall be referenced using the HasISA95ClassProperty reference and shall be of type PhysicalAssetClassPropertyType or a subtype of it

<TestSpecification> is a placeholder for any test specification that an instance of this PhysicalAssetClassPropertyType conforms to. These test specifications can have any name but shall be referenced using the TestedByPhysicalAssetTest Reference and shall be of type PhysicalAssetCapabilityTestSpecificationType or a subtype of it.

8.3.2.5 PhysicalAssetPropertyType

The PhysicalAssetPropertyType is a concrete VariableType that can be used directly. It is a subtype of ISA95PropertyType defined in7.5.3.

This VariableType indicates ISA95Properties of a role based equipment. Variables of this type may be related to tests defined by PhysicalAssetCapabilityTestSpecificationType defined in 8.3.3.1 and have Test results associated with them.

<TestResult> is the optional results associated with an instance of PhysicalAssetCapability-TestSpecificationType These test results can have any name but shall be referenced using the HasTestResult Reference and shall be of type PhysicalAssetCapabilityTestResultType or a subtype of it. In addition each <TestResult> shall have a ResultsForSpecification Reference to the instance of the PhysicalAssetCapabilityTestSpecificationType that is associated to the given test result record. It is recommended that the names assigned to the <TestSpecification> and the <TestResult> variable follow some naming convention, to allow operators to more easily match test results to the test specification that they are for.

<PropertyName> is a placeholder for possible additional instances of PhysicalAssetPropertyTypes. These properties can have any name but shall be referenced using the HasISA95Property reference and shall be of type PhysicalAssetPropertyType or a sub type of it

<TestSpecification> is a placeholder for any capability test specification that an instance of this PhysicalAssetPropertyType conforms to. These test specifications can have any name but shall be referenced using the TestedByPhysicalAssetTest Reference and shall be of type PhysicalAssetCapabilityTestSpecificationType or a sub type of it

8.3.3 ObjectTypes

8.3.3.1 PhysicalAssetCapabilityTestSpecificationType

The PhysicalAssetCapabilityTestSpecificationType is a concrete ObjectType that can be used directly. It is a subtype of ISA95TestSpecificationType defined in 6.7.3.

This ObjectType indicates a test for a physical asset. An instance of a PhysicalAssetCapabilityTestSpecificationType may be associated with a PhysicalAssetClassType, instances of PhysicalAssetClassPropertyType, instance of PhysicalAssetType or instances of PhysicalAssetPropertyType. This is typically used where a test is required to ensure that the Physical Asset has the necessary capability and capacity. An instance of a PhysicalAssetCapabilityTestSpecificationType may be associated with multiple instances of Physical Assets and/or multiple PhysicalAssetClassTypes.

8.3.3.2 PhysicalAssetClassType

The PhysicalAssetClassType is a concrete ObjectType that can be used directly. It is a subtype of ISA95ClassType defined in 6.7.1.

This ObjectType indicates a grouping of Physical Assets with similar characteristics for a definite purpose such as manufacturing operations definition, scheduling, capability and performance. An Object of PhysicalAssetClassType may be associated with an instance of a PhysicalAssetCapabilityTestSpecificationType. It is expected that subtypes of the PhysicalAssetClassType will be created that represent a particular class of physical asset. These subtypes will have their own set of instances of PhysicalAssetClassPropertyTypes and PhysicalAssetCapabilityTestSpecificationTypes

<PropertyName> is a placeholder for possible additional instances of PhysicalAssetClass-PropertyType. These properties can have any name but shall be referenced using the HasISA95Property reference and shall be of type PhysicalAssetClassPropertyType or a sub type of it.

Manufacturer is the Manufacturer of this PhysicalAssetClassType. The Manufacture shall be referenced using the HasISA95Attribute reference and shall be of type CompanyType or a sub type of it.

ModelNumber is the Manufacture’s ModelNumber that could be associated with this PhysicalAssetClassType. The ModelNumber is referenced using the HasISA95Attribute reference type and shall be a string of type BaseDataVariableType or a sub type of it.

<TestSpecification> is a placeholder for any capability test specification that this PhysicalAssetClassType conforms to. These test specifications can have any name but shall be referenced using the TestedByPhysicalAssetTest Reference and shall be of type PhysicalAssetCapabilityTestSpecificationType or a sub type of it

8.3.3.3 PhysicalAssetType

The PhysicalAssetType ObjectType is a concrete ObjectType that can be used directly. It is a subtype of ISA95ObjectType defined in 6.7.2. Individual instance of this PhysicalAssetType would have reference to PhysicalAssetClassType that the instance of the PhysicalAssetType supports. By definition of the ISA-95 model, when a Physical Asset instance or PhysicalAssetType references a PhysicalAssetClassType, the addition of said reference results in the addition of all instance of PhysicalAssetClassPropertyType defined for the referenced PhysicalAssetClassType to be added to the Physical Asset instance (or PhysicalAssetType subtype) as instances of PhysicalAssetPropertyType. These ISA95Properties will have all the same Attributes and Properties as the corresponding PhysicalAssetClassPropertyType instance.

This ObjectType may be further subtyped. The subtypes create some additional restrictions. Any PhysicalAssetClassType references that are added to a subtype of a PhysicalAssetType cannot be removed from instance of the subtype. If the PhysicalAssetType subtype is updated than all instance of the PhysicalAssetType must also be updated. For example if an additional PhysicalAssetClassType is added to the PhysicalAssetType subtype than that PhysicalAssetClassType must be added to all instances of the PhysicalAssetType subtype. This allows for creating a single PhysicalAssetType that is used for multiple physical asset instances.

This ObjectType indicates a specific physical asset. A physical asset may be tested by the execution of an instance of a PhysicalAssetCapabilityTestSpecificationType.

A PhysicalAssetType may be made of instances of PhysicalAssetType.

<PropertyName> is a placeholder for possible instances of PhysicalAssetPropertyType. These properties can have any name but shall be referenced using the HasISA95ClassProperty reference and shall be of type PhysicalAssetPropertyType or a subtype of it

<PhysicalAsset> is a placeholder for instance of PhysicalAssetType that this instance of PhysicalAssetType may be made up of. .These Objects can have any name but shall be referenced using the MadeUpOfPhysicalAsset reference and shall be to PhysicalAssetType or a subtype of it

PhysicalAssetClass defines the functionality of an instance of this PhysicalAssetType. .This Object shall be referenced using the DefinedByPhysicalAssetClass reference and shall be to PhysicalAssetClassType or a subtype of it

PhysicalLocation is the actual location associated with the instance of this PhysicalAssetType

FixedAssetId is the vendor provided identification number provided with the instance of the PhysicalAssetType. For Example it maybe the serial number associated with device.

VendorId is the vendor that provides the instance of this PhysicalAssetType. This may be the same as the manufacturer associated with the related class, but it may also be different. For example a system integrator maybe the vendor that provides the PhysicalAssetType, even though it is manufactured by another company.

<TestSpecification> is a placeholder for any capability test specification that an instance of this PhysicalAssetType conforms to. These test specifications can have any name but shall be referenced using the TestedByPhysicalAssetTest Reference and shall be of type PhysicalAssetCapabilityTestSpecificationType or a subtype of it

Equipment is the Equipment assigned to the instance of the PhysicalAssetType.

AssetAssignment – Is used to track the history of the logical Equipment to which this Physical Asset was assigned.

8.4 Material information

8.4.1 Overview

Figure 29 provides an overview of the ISA-95 Material handling information model

Material handling includes the definition of a class of material; this class can include material definitions that further define what the material is. These classes of materials are applied to groupings of the actual materials (lots). In many cases these groupings are further broken down into sub-groupings (sub-lots).

Figure 23 illustrates the material model which consists of material lots, material sub-lots, material classes, material definitions, and material test specifications.

Typically a class of materials is created and further subtyped into MaterialDefinitionType. These MaterialDefinitionTypes are usually vendor specific versions of the MaterialClassType. From these MaterialDefinitionTypes instances of MaterialLotType or subtypes of MaterialLotType are dynamically created. These instances of a MaterialLotType are maintained in the system for some period of time and then they are removed. For example, a technician may scan a barcode on a just delivered pallet of chemicals; this would cause an instance of the MaterialLotType to be created. This instance of a MaterialLotType may be composed of instances of MaterialSublotType (individual drums of that make up the pallet). When the last drum of chemical used up and all products that were created using the chemicals have been delivered, the system may delete the instance of the MaterialLotType that had automatically been created. In some cases sub types of MaterialLotType may be created, allowing for easier dynamic creation of an instance of a MaterialLotType that is assembled from specific MaterialSublotType(s)

A MaterialDefinitionType defines a specific type of material from a specific supplier. This corresponds to an entry in a corporate Material Master database. For example, it may be stainless steel wire from supplier Ajax Steel, with certain properties, such as hardness and carbon content. A MaterialClassType is a specific type of material without specifying the source of the material. For example, it may be stainless steel wire, with a range of hardness and range of carbon content. The MaterialClassType is used when you don’t care where the material comes from, such as “use any old stainless steel wire”. The MaterialDefinitionType is used when you do care where the material comes from, such as “Ajax Steel stainless steel wire”. Both types are often used in data exchanges.

In many systems the actual instances of MaterialLotType may exist in a database and be referenced by the OPC UA Server (i.e. they may not exist in memory in the OPC UA Server, but the Server would know how to access them and know what instances are available). If a client needs to modify an instance of a MaterialLotType (i.e. change the quantity or some other setting), the Server would handle the update to the underlining database.

8.4.2 VariableTypes

8.4.2.1 MaterialTestResultType

The MaterialTestResultType is a concrete VariableType that can be used directly. It is a subtype of ISA95TestResultType defined in 7.5.4.This VariableType indicates the results from executing an instance of a MaterialTestSpecificationType for a specific MaterialLotType.

This variable type according to ISA-95 shall have prior and or multiple results available depending on the vendor specific model. To accommodate this requirement, vendors will be required to support historical storage of instances of MaterialTestResultType.

8.4.2.2 MaterialDefinitionPropertyType

The MaterialDefinitionPropertyType is a concrete VariableType that can be used directly. It is a subtype of ISA95ClassPropertyType defined in 7.5.4.

This VariableType indicates ISA95ClassProperties for MaterialDefinitionTypes. Variables of this VariableType may be associated to an instance of a MaterialTestSpecificationType defined in 8.4.3.1.

<PropertyName> is a placeholder for possible instances of MaterialDefinitionPropertyType. These properties can have any name but shall be referenced using the HasISA95ClassProperty reference and shall be of type MaterialDefinitionPropertyType or a sub type of it

<TestSpecification> is a placeholder for any test specification that this MaterialDefinitionPropertyType conforms to. These test specifications can have any name but shall be referenced using the TestedByMaterialTest Reference and shall be of type MaterialTestSpecificationType or a sub type of it.

8.4.2.3 MaterialClassPropertyType

The MaterialClassPropertyType is a concrete VariableType that can be used directly. It is a subtype of ISA95ClassPropertyType defined in 7.5.4.

This VariableType indicates ISA95ClassProperties for MaterialClassTypes. Variables of this VariableType may be associated to an instance of a MaterialTestSpecificationType defined in 8.4.3.1

<PropertyName> is a placeholder for possible instances of MaterialClassPropertyType. These properties can have any name but shall be referenced using the HasISA95ClassProperty reference and shall be of type MaterialClassPropertyType or a sub type of it

<TestSpecification> is a placeholder for any test specifications that this MaterialClassPropertyType conforms to. These test specifications can have any name but shall be referenced using the TestedByMaterialTest Reference and shall be of type MaterialTestSpecificationType or a sub type of it.

8.4.2.4 MaterialLotPropertyType