10 ObjectTypes

10.1 WireHarnessMachineIdentificationType Type definition

10.1.1 Overview

The WireHarnessMachineIdentificationType provides information about the MachineryItem and is formally defined in Table 29. This is a subtype of the 3:MachineryIdentificationType; the ModellingRule for 2:AssetID has changed.

10.1.2 ObjectType definition

10.2 PartManagementType Type definition

10.2.1 Overview

The PartManagementType contains a list of parts, as well as methods to add and remove parts from the Server. It is formally defined in Table 30.

The system must also be capable of managing local deletions, assuming that parts and articles can be removed from the local database while still existing in a central repository.

In cases of incorrect referencing (e.g., a missing part or article), the server must throw an error.

10.2.2 ObjectType definition

Each Part represents an 3:ISA95MaterialDataType with the Properties shown in Table 15 (VECPartVersion and VECDocumentVersion).

Both Properties (VECPartVersion and VECDocumentVersion) must not provide by the server in the part Lists (Terminals, Seals, Sleeves, Wires) but need to be sent from the client to the server (in the method calls).

The Fields especially of the VECDocumentVersion structure depend on the kind of process and the Part. Table 31 - Table 33 show which fields need to be filled for each Part. The table has four columns. The first column displays the VEC attribute, the second provides an additional commonly used name, followed by a description and an indication of whether the parameter is always required or optional. The VEC attribute can be a direct child of the specification or a child of a subelement; in the latter case, it is separated by a "/".

Wires contain Part information for all wires. Table 31 contains the fields that must be given for this Parameter.

Terminals contain Part information for all terminals. Table 32 contains the fields that must be given for this Parameter.

Seals contain Part information for all seals. Table 33 contains the fields that must be given for this Parameter.

10.2.3 StorePart Method

This method is used to add a new Part to a list.

The signature of this Method is specified below. Table 34 and Table 35 specify the Arguments and AddressSpace representation, respectively.

Signature

	StorePart(
	[in]	3:ISA95MaterialDataType	Part);

10.2.4 FindPartsByType Method

This method returns all Parts of a Type.

The signature of this Method is specified below. Table 36 and Table 37 specify the Arguments and AddressSpace representation, respectively.

Signature

	FindPartsByType (
	  [in]	0:NodeId				TypeNodeId,
	  [out]	3:ISA95MaterialDataType[]	Parts);

10.2.5 ClearPart Method

Theis method is used to remove a Part from the S.

The signature of this Method is specified below. Table 38 and Table 39 specify the Arguments and AddressSpace representation, respectively.

Note: The Data Integrity described in 4.1.3 must be considered.

Signature

	ClearPart (
	  [in]  3:ISA95MaterialDataType Part);

10.3 ArticleSpecManagementType Type definition

10.3.1 Overview

The ArticleSpecManagementType contains a list of articles and methods to add and remove article specs from the server. It is formally defined in Table 43.

Each Article Spec represents to a 3:ISA95MaterialDataType with the Properties shown in Table 18 (VECPartVersion, VECDocumentVersion and Processes). The table has four columns. The first column displays the VEC attribute, the second provides an additional commonly used name, followed by a description and an indication of whether the parameter is always required or optional. The VEC attribute can be a direct child of the specification or a child of a subelement; in the latter case, it is separated by a "/".

The properties VECPartVersion, VECDocumentVersion and Processes may not be provided by the server in the ArticleList but need to be send from the client to the server (in the method calls). The Values depend on the kind of process and the Part. Table 40 - Table 42 show which fields need to be filled for each process the article spec should describe.

10.3.2 ObjectType definition

ArticleSpecList contains a list of all article specs known by the Server.

10.3.3 StoreArticleSpec Method

This method is used to add a new article to a list.

The signature of this Method is specified below. Table 44 and Table 45 specify the Arguments and AddressSpace representation, respectively.

Note: The data integrity described in 4.1.3 must be considered.

Signature

	StoreArticleSpec(
	  [in]  3:ISA95MaterialDataType ArticleSpec);

10.3.4 ClearArticle Method

The method is used remove an article from the server.

The signature of this Method is specified below. Table 46 and Table 47 specify the Arguments and AddressSpace representation, respectively.

Note: The Data Integrity described in 4.1.3 must be considered.

Signature

	ClearArticleSpec (
	[in]	3:ISA95MaterialDataType	ArticleSpec);

10.4 WireHarnessMachineType Type definition

10.4.1 Overview

The WireHarnessMachineType represents the entire wire harness machine interface of the information model. It is the entry point to the OPC UA interface of a wire harness machine. It gives a basic structure to the interface. An instance of this type aggregates all information related to one wire harness machine. The WireHarnessMachineType is formally defined in Table 48.

10.4.2 ObjectType definition

4:Identification provides properties to identify a Device.

4:Components contains the details of all components of the machine. See OPC 40001-1 for more information.

PartManagement contains the part list and the method to manage this list.

ArticleSpecManagement contains the article list and the method to manage this list.

MachineryBuildingBlocks are used as described in OPC 40001-1. This Companion Specification uses the following building blocks:

JobManagement

MachineryItemState

MachineryOperationMode

Components

ResultManagement

The components of the WireHarnessMachineType have additional subcomponents, which are defined in Table 49. The methods 5:Store, 5:Start, 5:Clear, 5:Abort are mandatory.

Note: The data integrity described in 4.1.3 must be considered, especially with the 5:Store method.