1 Scope

For the communication between different machines, manufacturer independent information models are required. For plastics and rubber machinery, these information models are based on OPC UA, a communication framework developed and provided by the OPC Foundation. While OPC UA provides the technology for the transfer of information, the definition which information is transferred in which form is fixed in Companion Specifications.

This recommendation defines common ObjectTypes for plastics and rubber machines. The intention is that ObjectTypes which can be used for several machines and applications are defined only once. For specific applications (e.g. connection of injection moulding machines to MES), these ObjectTypes are used by specific Companion Specifications (e.g. OPC 40077).

NOTE: Not all machines will support all ObjectTypes, e.g. TemperatureZoneType, MouldType.

2 Normative references

The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. 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

OPC 10000-1

OPC 10000-2, OPC Unified Architecture - Part 2: Security Model

OPC 10000-2

OPC 10000-3, OPC Unified Architecture - Part 3: Address Space Model

OPC 10000-3

OPC 10000-4, OPC Unified Architecture - Part 4: Services

OPC 10000-4

OPC 10000-5, OPC Unified Architecture - Part 5: Information Model

OPC 10000-5

OPC 10000-6, OPC Unified Architecture - Part 6: Mappings

OPC 10000-6

OPC 10000-7, OPC Unified Architecture - Part 7: Profiles

OPC 10000-7

OPC 10000-8, OPC Unified Architecture - Part 8: Data Access

OPC 10000-8

OPC 10000-9, OPC Unified Architecture - Part 9: Alarms and Conditions

OPC 10000-9

OPC 10000-11, OPC Unified Architecture - Part 11: Historical Access

OPC 10000-11

OPC 10001-1, OPC Unified Architecture V1.04 - Amendment 1: AnalogItem Types

http://www.opcfoundation.org/UA/Amendment1/

OPC 10001-3, OPC Unified Architecture V1.04 - Amendment 3: Method Metadata

http://www.opcfoundation.org/UA/Amendment3/

OPC 10000-100, OPC Unified Architecture - Part 100: Devices

OPC 10000-100

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 OPC 40083 Information Model. For the purposes of this document, the terms and definitions given in the documents referenced in Clause 2 apply.

Note that OPC UA terms and terms defined in this specification are italicized in the specification.

3.2 Conventions used in this document

3.2.1 Conventions for Node descriptions

Node definitions are specified using tables (see Table 2 ).

Attributes are defined by providing the Attribute name and a value, or a description of the value.

References are defined by providing the ReferenceType name, the BrowseName of the TargetNode and its NodeClass.

If the TargetNode is a component of the Node being defined in the table the Attributes of the composed Node are defined in the same row of the table.

The DataType is only specified for Variables; “[<number>]” indicates a single-dimensional array, for multi-dimensional arrays the expression is repeated for each dimension (e.g. [2][3] for a two-dimensional array). For all arrays the ArrayDimensions is set as identified by <number> values. If no <number> is set, the corresponding dimension is set to 0, indicating an unknown size. If no number is provided at all the ArrayDimensions can be omitted. If no brackets are provided, it identifies a scalar DataType and the ValueRank is set to the corresponding value (see OPC 10000-3). In addition, ArrayDimensions is set to null or is omitted. If it can be Any or ScalarOrOneDimension, the value is put into “{<value>}”, so either “{Any}” or “{ScalarOrOneDimension}” and the ValueRank is set to the corresponding value (see OPC 10000-3) and the ArrayDimensions is set to null or is omitted. Examples are given in Table 1 .

The TypeDefinition is specified for Objects and Variables.

The TypeDefinition column specifies a symbolic name for a NodeId, i.e. the specified Node points with a HasTypeDefinition Reference to the corresponding Node.

The ModellingRule of the referenced component is provided by specifying the symbolic name of the rule in the ModellingRule column. In the AddressSpace, the Node shall use a HasModellingRule Reference to point to the corresponding ModellingRule Object.

If the NodeId of a DataType is provided, the symbolic name of the Node representing the DataType shall be used.

Note that if a symbolic name of a different namespace is used, it is prefixed by the NamespaceIndex (see 3.2.2.2).

Nodes of all other NodeClasses cannot be defined in the same table; therefore only the used ReferenceType, their NodeClass and their BrowseName are specified. A reference to another part of this document points to their definition.

Table 2 illustrates the table. If no components are provided, the DataType, TypeDefinition and ModellingRule columns may be omitted and only a Comment column is introduced to point to the Node definition.

Components of Nodes can be complex that is containing components by themselves. The TypeDefinition, NodeClass and DataType can be derived from the type definitions, and the symbolic name can be created as defined in 3.2.3.1. Therefore, those containing components are not explicitly specified; they are implicitly specified by the type definitions.

The Other column defines additional characteristics of the Node. Examples of characteristics that can appear in this column are show in Table 3.

If multiple characteristics are defined they are separated by commas. The name or the short name may be used.

3.2.2 NodeIds and BrowseNames

3.2.2.1 NodeIds

The NodeIds of all Nodes described in this standard are only symbolic names. Annex A defines the actual NodeIds.

The symbolic name of each Node defined in this document is its BrowseName, or, when it is part of another Node, the BrowseName of the other Node, a “.”, and the BrowseName of itself. In this case “part of” means that the whole has a HasProperty or HasComponent Reference to its part. Since all Nodes not being part of another Node have a unique name in this document, the symbolic name is unique.

The NamespaceUri for all NodeIds defined in this document is defined in Annex A. The NamespaceIndex for this NamespaceUri is vendor-specific and depends on the position of the NamespaceUri in the server namespace table.

Note that this document not only defines concrete Nodes, but also requires that some Nodes shall be generated, for example one for each Session running on the Server. The NodeIds of those Nodes are Server-specific, including the namespace. But the NamespaceIndex of those Nodes cannot be the NamespaceIndex used for the Nodes defined in this document, because they are not defined by this document but generated by the Server.

3.2.2.2 BrowseNames

The text part of the BrowseNames for all Nodes defined in this document is specified in the tables defining the Nodes. The NamespaceUri for all BrowseNames defined in this document is defined in Annex A.

If the BrowseName is not defined by this document, a namespace index prefix like ‘0:EngineeringUnits’ or ‘2:DeviceRevision’ is added to the BrowseName. This is typically necessary if a Property of another specification is overwritten or used in the OPC UA types defined in this document. Table 167 provides a list of namespaces and their indexes as used in this document.

3.2.3 Common Attributes

3.2.3.1 General

The Attributes of Nodes, their DataTypes and descriptions are defined in OPC 10000-3. Attributes not marked as optional are mandatory and shall be provided by a Server. The following tables define if the Attribute value is defined by this specification or if it is server-specific.

For all Nodes specified in this specification, the Attributes named in Table 4 shall be set as specified in the table.

3.2.3.2 Objects

For all Objects specified in this specification, the Attributes named in Table 5 shall be set as specified in the table. The definitions for the Attributes can be found in OPC 10000-3.

3.2.3.3 Variables

For all Variables specified in this specification, the Attributes named in Table 6 shall be set as specified in the table. The definitions for the Attributes can be found in OPC 10000-3.

3.2.3.4 VariableTypes

For all VariableTypes specified in this specification, the Attributes named in Table 7 shall be set as specified in the table. The definitions for the Attributes can be found in OPC 10000-3.

3.2.3.5 Methods

For all Methods specified in this specification, the Attributes named in Table 8 shall be set as specified in the table. The definitions for the Attributes can be found in OPC 10000-3.

4 General information to OPC UA interfaces for plastics and rubber machinery and OPC UA

4.1 Introduction to OPC UA interfaces for plastics and rubber machinery

Industry 4.0 means exchange of data/information between machines for increasing the quality and efficiency of the production. This is only possible with standardised interfaces. Plastics and rubber machines are usually integrated in a production line and/or connected to superordinate systems like Manufacturing Execution Systems (MES). This is why, the joint working group OPC UA Plastics and Rubber Machinery develops Companion Specifications for both horizontal and vertical communication.

4.2 Introduction to OPC Unified Architecture

4.2.1 What is OPC UA?

OPC UA is an open and royalty free set of standards designed as a universal communication protocol. While there are numerous communication solutions available, OPC UA has key 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 semantic models such as OPC UA interfaces for plastics and rubber machinery, OPC UA makes it easier for end users to access data via generic commercial applications.

The OPC UA model is scalable from small devices to ERP systems. OPC UA Servers 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.2.2 Basics of OPC UA

As an open standard, OPC UA is based on standard internet technologies, like TCP/IP, HTTP, Web Sockets.

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 is shown in Figure 1.

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.2.3 Information modelling in OPC UA

4.2.3.1 Concepts

OPC UA provides a framework that can be used to represent complex information as Objects in an AddressSpace which can be accessed with standard 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 2.

Object and Variable Nodes represent instances and they always reference a TypeDefinition (ObjectType or VariableType) Node which describes their semantics and structure. illustrates the relationship between an instance and its TypeDefinition.

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 3 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 children. 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 Servers 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 ObjectType 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. Regarding DataTypes, subtypes can only restrict. If a Variable is defined to have a numeric value, a sub type could restrict it to a float.

References allow Nodes to be connected 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 an existing ReferenceType. Subtypes inherit the semantics of the parent but may add additional restrictions. Figure 4 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 5. 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 AddressSpace of an OPC UA Server.

Figure 5 – The OPC UA Information Model Notation

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

OPC UA specification defines a very wide range of functionality in its basic information model. It is not required 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 definition of functional subsets (that are expected to be implemented) within a companion specification. The Profiles do not restrict functionality, but generate requirements for a minimum set of functionality (see OPC 10000-7)

4.2.3.2 Namespaces

OPC UA allows information from many different sources to be combined into a single coherent AddressSpace. Namespaces are used to make this possible by eliminating naming and id conflicts between information from different sources. Each namespace in OPC UA has a globally unique string called a NamespaceUri which identifies a naming authority and a locally unique integer called a NamespaceIndex, which is an index into the Server's table of NamespaceUris. The NamespaceIndex is unique only within the context of a Session between an OPC UA Client and an OPC UA Server- the NamespaceIndex can change between Sessions and still identify the same item even though the NamespaceUri's location in the table has changed. The Services defined for OPC UA use the NamespaceIndex to specify the Namespace for qualified values.

There are two types of structured values in OPC UA that are qualified with NamespaceIndexes: NodeIds and QualifiedNames. NodeIds are locally unique (and sometimes globally unique) identifiers for Nodes. The same globally unique NodeId can be used as the identifier in a node in many Servers – the node's instance data may vary but its semantic meaning is the same regardless of the Server it appears in. This means Clients can have built-in knowledge of of what the data means in these 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. TypeDefinitions are not allowed to have children with duplicate BrowseNames; however, instances do not have that restriction.

4.2.3.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, and potentially also well-defined Objects as entry points into the AddressSpace.

5 Use cases

OPC 40083 provides Object, Data and Variable Type definitions to be used by specific companion specifications for plastics and rubber machinery. The intention is to create an interoperability between the different machines.

6 General requirements

6.1 NodeIds

The NodeIds of the Types defined in this specification are mandatory and fixed in the provided XML-file. This applies only to the Types themselves and not to the child elements. NodeIds of generated instances are not fixed and assigned by the individual OPC UA server. Therefore, the namespace of the NodeIds is the Local Server URI with namespace index 1 or a vendor specific namespace with vendor specific index. However, a Server shall persist the NodeIds of the generated Nodes, that is, it shall not generate new NodeIds when rebooting.

NOTE: It is not mandatory that the servers of all machines from one manufacturer use the same NodeIds for the individual instances, so a client cannot expect this. Also, a software update of a machine may lead to new NodeIds.

6.2 AnalogItemType

For this specification, wherever AnalogItemType is used, the property EngineeringUnits is mandatory. The unit system described in OPC UA Part 8 (“Codes for Units of Measurement (Recommendation N°. 20)” published by the “United Nations Centre for Trade Facilitation and Electronic Business” (see UN/CEFACT)) shall be used.

6.3 EventNotifier

If events are supported, the root node of the specific interface (e.g. IMM_MES_Interface for OPC 40077) shall set the SubscribeToEvents flag in the EventNotifier attribute.

If event history is supported, the root node of the specific interface (e.g. IMM_MES_Interface for OPC 40077) shall set the HistoryRead flag in the EventNotifier attribute.

6.4 Severity of events

Wherever a Severity property is used (e.g. in MESMessage in 14.4, all events based on BaseEventType), the following classification shall be used:

7 Container concept

Several objects can occur several times in the parent object (e.g. several moulds in one machine). For these, container objects are modelled. The benefit is that all instances are collected in one object so that changes can be easily recognized by using a Property NodeVersion which can be subscribed by clients. According to OPC UA, Part 3, the instances of the container objects shall also trigger a GeneralModelChangeEvent.

The following container types are defined:

Within these containers, the child elements have the modelling rule OptionalPlaceholder which allows to add and remove instances of the objects dynamically.

The BrowseNames of the child elements are created with numbers as suffixes starting with 1 (e.g. “Mould_1”, “Mould_2” …). It is allowed to use numbers with leading zeros, e.g. “Mould_001” for better sorting. It is not mandatory to use successive numbers. That means there can be gaps and it is also allowed to have e.g. two instances with BrowseNames “Mould_042” and “Mould_099”.

The objects have an IsPresent-flag. This allows to have a fixed number of instances prepared (e.g. if the maximum number of child components is limited by the design of the machine) and to indicate if the component is physically present. With this there are two possibilities: Dynamic creation of instances or fixed number of instances. However, a client which is interested in the contents of the container shall always subscribe the NodeVersion and/or ModelChangeEvents of the container object to get informed about changes.

NOTE: As the child elements are created by the server, the namespace of the BrowseNames is the Local Server URI with namespace index 1 or a vendor specific namespace with vendor specific index.

8 MachineInformationType

8.1 MachineInformationType Definition

This ObjectType represents the general description of a machine. The information is fixed by the manufacturer and not changeable by the user. It is formally defined in Table 10.

8.2 Properties included in ComponentType

The following parameters are already included in the ComponentType (defined in OPC UA Part 100).

8.3 DeviceClass

The DeviceClass Property indicates in which domain or for what purpose a certain Device is used. The Property is optional in OPC UA DI. Here it is overridden and made mandatory. The value is specified in the specific Companion Specification (e.g. "Injection Moulding Machine" for OPC 40077).

8.3.1 Manufacturer

The Manufacturer Property provides the name of the manufacturer of the machine (e.g. "Negri Bossi"). The Property is optional in OPC UA DI. Here it is overridden and made mandatory.

8.3.2 DeviceManual

The DeviceManual Property allows specifying an address of the user manual for the Device. It may be a pathname in the file system or a URL (Web address). If the manual is not directly accessible, it may also be a general web address (e.g. “netstal.com”).

8.3.3 Model

The Model Property represents the name of the machine type (e.g. "KM 1000-2500", "Allrounder"). The Property is optional in OPC UA DI. Here it is overridden and made mandatory.

8.3.4 SoftwareRevision

The SoftwareRevision Property represents the software version used in the control unit (e.g. "nb2001v11B030").

8.3.5 SerialNumber

The SerialNumber Property represents the serial number of the machine (unique ID given by the manufacturer, e.g. "1240114"). The Property is optional in OPC UA DI. Here it is overridden and made mandatory.

8.3.6 DeviceRevision

The DeviceRevision Property provides the overall revision level of the Device.

8.3.7 HardwareRevision

The HardwareRevision Property provides the revision level of the hardware of the Device.

8.3.8 RevisionCounter

The RevisionCounter Property is an incremental counter indicating the number of times the static data within the Device has been modified.

8.4 Additional properties

The following parameters are defined to extend the ComponentType.

8.4.1 ControllerName

The ControllerName Property represents the name of the machine controller (e.g. "MC5").

8.4.2 SupportedLogbookEvents

This list of LogbookEventsEnumeration gives information which LogbookEvents (see 9) are supported by the machine.

The LogbookEventsEnumeration is defined in Table 11.

9 LogbookEvent

9.1 LogbookEvent Definition

Logbook events are fired by the machine for the documentation of relevant changes in the machine configuration/status. The LogbookEventType is formally defined in Table 12.

The LogbookEventType is abstract. There will be no instances of a LogbookEventType itself, but there will be instances of its subtypes which provide detailed information.

The EventSource is the root node of the interface (e.g. instance of IMM_MES_InterfaceType for OPC 40077).

NOTE: The EventSource, Time and a Message are already included in the BaseEventType of OPC UA.

There shall be a buffer to be accessible via the OPC UA service history read (even when the machine has been switched off in the meantime). The minimum size is 100 LogbookEvents to be stored in a (persistent) ring buffer containing the recent 100 events (over all LogbookEvents).

9.2 User

This Object indicates the user who is responsible for the change that leads to the event. The fields of UserType (see 13.2) shall be null or emtpy if no user is directly responsible (e.g. for messages coming from the machine control system).

9.3 EventOriginator

This Property represents the originator of a logbook event. The EventOriginatorEnumeration is defined in Table 13.

9.4 JobCycleCounter

This Property represents the current value of JobCycleCounter in the ActiveJobValues Object when the event is fired (see 18.4.7.1). Only to be used for cyclic production (e.g. injection moulding).

9.5 ParameterChangeLogType

The ParameterChangeLogType is used for the logging of relevant changes in production parameters.

The decision which parameter is relevant for the production is done by the machine.

The ParameterId Property represents the Id of the changed parameter.

The OldValue Property represents the old value of the changed parameter.

The NewValue Property represents the new value of the changed parameter.

Depending on the changed parameter, the Datatype of OldValue and NewValue are subtypes of 0:BaseDataType (0:String, Number, …). Where the unit is important (e.g. temperatures, lengths…), also OldValueUnit and NewValueUnit shall be used (see OPC UA Part 5 for the definition of EUInformation).

9.6 UserLogType

The UserLogType is used for logging which users are logged in to the machine.

The UserChangeEnumeration is defined in Table 16.

9.7 RemoteAccessLogType

The RemoteAccessLogType is used for logging access from outside to the machine (e.g. remote service).

RemoteUserName: Name of the remote user (e.g. name of the service employee doing remote service)

UserChange: The UserChangeEnumeration is the same used in UserLogType and is defined in Table 16.

Origin: Information about the origin of the remote access (e.g. "Headquarters").

9.8 SequenceChangeLogType

The SequenceChangeLogType is used for the logging changes in the production sequence.

The SequenceChange Property allows classifying the changes. (A description of the changes is included in the Message Property of the LogBookEventType)

9.9 MachineModeChangeLogType

The MachineModeChangeLogType is used for logging changes of the machine mode.

The MachineModeEnumeration is defined in 12.4.

9.10 ProductionStatusChangeLogType

The ProductionStatusChangeLogType is used for logging changes of the production status.

The ProductionStatusEnumeration is defined in 14.7.1.

9.11 ProductionDatasetChangeLogType

The ProductionDatasetChangeLogType is used when a new production dataset is loaded and activated in the control system of the machine.

9.12 ProductionDatasetFrozenLogType

The ProductionDatasetFrozenLogType is used when a production dataset is locked or unlocked (see 20.3.4).

9.13 StandstillReasonLogType

The StandstillReasonLogType is used for logging StandstillReasons.

9.14 MessageLogType

The MessageLogType is used for logging MessageConditions (see 14.8).

Classification: Classification of the message. The valid values of the Enumeration are specified in the specific Companion Specification (e.g. IMMMessageClassificationEnumeration in OPC 40077).

9.15 UserFeedbackLogType

The UserFeedbackLogType is used for logging text messages entered by the user into the machine control system.

Classification: Classification of the message. The valid values of the Enumeration are specified in the specific Companion Specification (e.g. IMMMessageClassificationEnumeration in OPC 40077).

NOTE: The Message itself is included in the BaseEventType

10 MachineConfigurationType

10.1 MachineConfigurationType Definition

This OPC UA ObjectType represents the current configuration of a machine. It is formally defined in Table 27.

10.2 UserMachineName

The UserMachineName Property represents the description of the machine given by the machine operator or OPC client (e.g. "machine 42").

10.3 LocationName

The LocationName Property represents the description of the location of the machine given by the machine operator or OPC client (e.g. "plant 2, hall C").

10.4 TimeZoneOffset

The TimeZoneOffset Property represents the difference of the local time to Coordinated Universal Time (UTC) given by the machine operator or OPC client.

Information: TimeZoneDataType (as defined in OPC UA Part 3) is a structure with two components:

offset (0:UInt16): Time difference from UTC in minutes (e.g. 120 for daylight saving time in Berlin)

daylightSavingInOffset (0:Boolean): If TRUE, then daylight saving time (DST) is in effect and offset includes the DST correction. If FALSE, then the offset does not include DST correction and DST may or may not have been in effect.

NOTE: The UTC time itself is part of OPC UA Part 5: ServerStatus CurrentTime.

10.5 SetMachineTime

The SetMachineTime Method allows setting the server time together with TimeZoneOffset.

Signature

	SetMachineTime (
		[in]	0:DateTime	DateTime
		[in]	0:TimeZoneDataType	TimeZoneOffset);

Example: A call with DateTime = "2021-04-30 12:00" (UTC time) and TimeZoneOffset = {120; true}, sets the (local) machine time to "30-04-2021 14:00" and the time zone to "UTC+2" with active daylight saving time.

10.6 PageDirectory

The PageDirectory Property is an array and represents a list of the pages that are implemented in the machine control system and are shown on the screen of the machine. The used PageEntryDataType is defined in Table 30.

10.7 GetPage

Method for retrieving the image of a page of the control system.

Signature

	GetPage (
		[in]	0:String	Id
		[out]	0:Image	Page);

10.8 GetCurrentPage

Method for retrieving a screenshot of the control system with the currently shown contents.

Signature

	GetCurrentPage (
		[in]	0:UInt32	VisualisationUnit
		[out]	0:Image	Page);

11 MachineMESConfigurationType

11.1 MachineMESConfigurationType Definition

This OPC UA ObjectType represents the current configuration of a machine related to a Manufacturing Execution System (MES). It is formally defined in Table 35.

11.2 StandstillReasons

The StandstillReasons Property represents an array with a list of the standstill reasons from which one is selected by the operator in the case of a standstill. The used StandstillReasonType is defined in Table 36.

StandstillReasons shall support at least 10 entries.

The MES shall be prepared, that the list includes standstill reasons not defined by the MES (e.g. added by the operator on the machine). The user of the interface shall ensure unique Ids among all standstill reasons. To ensure consistent statistics, a change of the meaning of already assigned standstill reasons should be avoided.

11.3 StandstillReasonsLockedByMES

The StandstillReasonsLockedByMES Property indicates if the list StandstillReasons has been modified by the MES and may not be changed by the machine.

NOTE: The parameter LockedByMES in an item only locks this StandstillReason whereas StandstillReasonsLockedByMES locks the complete array (that means also that no items can be added by the machine).

11.4 MESUrl

The MESUrl Property represents a URL to display a webpage generated by the MES in a web browser integrated in the machine.

12 MachineStatusType

12.1 MachineStatusType Definition

This ObjectType represents the current status of a machine. It is formally defined in Table 37.

12.2 IsPresent

This Property informs the client if the machine is physically present and connected. May be FALSE e.g. when an aggregation server is configured to provide data for several machines.

12.3 Users

This Object is a container for the user(s) of the machine. The UsersType itself is defined in chapter 13.1.

12.4 MachineMode

The MachineMode Property represents the current machine mode (as defined by mode selector on the machine). The MachineModeEnumeration is defined in Table 38:

12.5 ActivateSleepMode, DeactivateSleepMode

These two Methods allow the client (e.g. MES) to activate or deactivate the sleep mode of the machine if provided.

Activation of sleep mode sets the MachineMode (see 12.4) to SLEEP_5.

Signatures

	ActivateSleepMode ();
	DeactivateSleepMode ();

The methods have no Input- or OutputArguments.

13 Users

13.1 UsersType

This ObjectType is a container for the user(s). It is formally defined in Table 41.

When instances for users are created, the BrowseNames shall be "User_<Nr>” (starting with 1).

13.2 UserType

The UserType represents information on the operator(s) of the machine. It is formally defined in Table 42.

All fields may contain empty 0:Strings if not supported.

NOTE: The information provided via the UserType (especially Id and Name) might affect data protection laws and agreements with the employees might be necessary before usage. In case of doubt anonymized information should be provided.

13.2.1 Id

The Id Property represent the Id of the user.

13.2.2 Name

The Name Property represent the Name of the user.

13.2.3 IsPresent

The machine can have instances for the maximum number of users that can be simultaneously logged in. TRUE if the instance of UserType represents a user that is currently logged in.

13.2.4 CardUid

This Property represents the Uid of the identification card used by the operator for logging in to the machine.

NOTE: The Variables Name, Id and CardUid are in accordance with the user identification as described in EUROMAP 65.

13.2.5 UserLevel

The UserLevel Property represent the level of the user (e.g. "1", "2"). The possible values are defined by the manufacturer of the machine.

NOTE: In this Property, the Access rights as described in EUROMAP 65 can be stored.

13.2.6 UserRole

The UserRole Property represents the role of the user (e.g. "Administrator"). The possible values are defined by the manufacturer of the machine.

13.2.7 Language

The Language Property represents the currently selected language on the machine control unit. Indication of language with Language code = Alpha-3 (three-letter) code according to ISO 639-2/B and Country code = Alpha-2 (two-letter) code according to ISO 3166-1 (e.g. "eng-US")

14 MachineMESStatusType

14.1 MachineMESStatusType Definition

This ObjectType represents the current status of a machine related to the MES. It is formally defined in Table 43.

14.2 StandstillReasonId

The StandstillReasonId Property represents the Id of the StandstillReason (see MachineConfiguration) set by the operator after a standstill occurs.

Default value: empty String (= no active standstill reason).

Set to an empty String by machine with starting of production.

14.3 StandstillMessage

The StandstillMessage Object represents the fault which causes standstill. This is set by machine control.

The StandstillMessageType is formally defined in Table 44.

Classification: Classification of the message. The valid values of the Enumeration are specified in the specific Companion Specification (e.g. IMMMessageClassificationEnumeration in OPC 40077).

NOTE: When creating an instance of the StandstillMessage object, the DataType of Classification shall be set to the specific Enumeration subtype (e.g. IMMMessageClassificationEnumeration).

If the machine is not in a standstill state, the values of the Properties shall be 0 or empty string.

14.4 MESMessage

The MESMessage Object represents a text message sent from the MES to be shown on the machine. The Properties of this Object shall only be set/changed by the MES OPC UA Client.

NOTE: This Property shall not be writeable directly. The method SetMESMessage is used for the modification.

14.5 SetMESMessage

Method for setting the MESMessage.

Signature

	SetMESMessage (
		[in]	0:String	Id
		[in]	0:String	Message
		[in]	0:UInt16	Severity);

14.6 ClearMESMessage

Method for clearing the MESMessage. Calling this method sets the Properties Id and Message in MESMessage to empty string and Severity to 0.

Signature

	ClearMESMessage ();

The method has no Input- or OutputArguments.

14.7 ProductionControlType

The ProductionControl Object allows the MES to control the production of the machine. It is formally defined in Table 49.

14.7.1 ProductionStatus

The ProductionStatus Property of DataType ProductionStatusEnumeration represents the production status when the machine is in automatic or semi-automatic mode. When the machine is in another mode, the value is not relevant (no production). The ProductionStatusEnumeration is formally defined in Table 50.

NOTE: This is a list of a possible status and not a sequence. The support of the values NO_PRODUCTION_1 and PRODUCTION_4 is mandatory. The use of the other values is optional.

The ProductionStatus is set by the machine/operator. The selection of the value PRODUCTION_4 can be prevented by the MES OPC UA client by setting ProductionReleasedByMES to FALSE.

14.7.2 ProductionReleasedByMES

The ProductionReleasedByMES Property indicates if ProductionStatus may have the value PRODUCTION_4. Default value is TRUE. If ProductionReleased is FALSE it also prevents that JobStatus (see 18.4.1) has the value JOB_IN_PRODUCTION_6.

If ProductionReleased is set from TRUE to FALSE when ProductionStatus has the value PRODUCTION_4, the value shall change to READY_FOR_PRODUCTION_3. If JobStatus has the value JOB_IN_PRODUCTION_6 it shall change to JOB_INTERRUPTED_7.

14.7.3 AutomaticRunEnabled, EnableAutomaticRun, DisableAutomaticRun

The AutomaticRunEnabled Property indicates if semi-automatic and automatic run of the machine is allowed by MES. If FALSE, the machine cannot start in semi-automatic or automatic mode.

The value is set to TRUE by the Method EnableAutomaticRun and to FALSE by the Method DisableAutomaticRun. The default value is TRUE.

Can e.g. be used if wrong mould is installed or to force the operator to enter a StandstillReason after machine stop.

If the machine is running in (semi-)automatic, a call of DisableAutomaticRun will stop the machine (if applicable at the end of the cycle). The machine should show a message to the operator why the machine has stopped.

Signatures

	EnableAutomaticRun ();
	DisableAutomaticRun ();

The methods have no Input- or OutputArguments.

14.7.4 ProductionOnlyWithMES

The optional Property ProductionOnlyWithMES indicates if production with the machine is only allowed when the MES is active. When ProductionOnlyWithMES is TRUE and the connection to the MES is lost, the machine may not have the ProductionStatus PRODUCTION_4 and not the JobStatus JOB_IN_PRODUCTION_6 (see 18.4.1).

NOTE: It is not fixed by this specification if the machine stops or continues running.

The default value is FALSE.

Only one MES client shall write this Property.

14.7.5 SetWatchDogTime, ResetWatchDog

Some production jobs need 100% documentation of the production parameters. To ensure this, a WatchDog can be used. By setting the WatchDog time with the Method SetWatchDogTime the production is only released for the given time. The Method ResetWatchDog sets the timer to the value set by the last calling of SetWatchDogTime. This indicates to the machine that the MES is still connected and able to store the production parameters.

Only one MES client shall call these Methods to avoid overlapping.

When the defined time is exceeded without reset, the machine may not have the ProductionStatus PRODUCTION_4 and not the JobStatus JOB_IN_PRODUCTION_6 (see 18.4.1).

NOTE: It is not fixed by this specification if the machine stops or continues running.

Signature

	SetWatchDogTime (
		[in] 0:Int32	WatchDogTime);

Calling the method with WatchDogTime = -1 disables the watch dog and the machine can stay in production.

Signature

	ResetWatchDog ();

The method has no Input- or OutputArguments.

14.7.6 RequestTestSample

The machine shall separate a test sample (e.g. for quality check). The size of the test sample depends on the product/machine configuration.

Signature

	RequestTestSample ();

The method has no Input- or OutputArguments.

14.8 MessageConditionType

The MessageConditions represent text messages (incl. error messages) of the control system currently shown on the screen of the machine. The MessageConditionType is formally defined in Table 57.

Id: Id of the message

Classification: Classification of the message. The valid values of the Enumeration are specified in the specific Companion Specification (e.g. IMMMessageClassificationEnumeration in OPC 40077).

IsStandstillMessage: Indication if the message has led to a standstill.

NOTE: The AlarmConditionType is a subtype of BaseEventType and therefore includes the Properties Severity and Message (= text).

15 Moulds

15.1 MouldsType

This ObjectType is a container for the mould(s). It is formally defined in Table 58.

When instances for moulds are created, the BrowseNames shall be "Mould_<Nr>” (starting with 1).

15.2 MouldType

15.2.1 MouldType Definition

This ObjectType represents the description and status of a mould (e.g. used in injection or blow moulding machines). It is formally defined in Table 59.

15.2.2 Index

The Index Property gives the number of the mould.

15.2.3 Id

The Id Property represents the Id of the installed mould. It is valid for a complete configuration of a mould incl. frames/inserts. If an insert is changed or deactivated, the mould gets a new Id.

15.2.4 IsPresent

This Property informs the client if the mould is physically present and connected. May be FALSE e.g. when instances for possible moulds are created (depending on the capabilities/connectors of the machine) which are currently not used.

15.2.5 Description

The Description Property represents a description of the installed mould.

15.2.6 MouldStatus

The MouldStatusProperty represents the current (physical) status of the mould related to the object instance. The MouldStatusEnumeration is defined in Table 60:

15.2.7 TemperatureZones

This Object is a container for the temperature zones of the mould zones. The TemperatureZonesType is formally defined in 17.1. Inside the container the MouldTemperatureZoneType as defined in 17.2.10.2 shall be used.

16 PowerUnits

16.1 PowerUnitsType

This ObjectType is a container for the power unit(s). It is formally defined in Table 61.

When instances for power units are created, the BrowseNames shall be “PowerUnit_<Nr>” (starting with 1).

16.2 PowerUnitType

16.2.1 PowerUnitType Definition

This ObjectType represents information on the hydraulic units and electric drives. It is formally defined in Table 62.

16.2.2 Index

The Index Property gives the number of the power unit.

16.2.3 IsPresent

This Property informs the client if the power unit is physically present and connected. May be FALSE e.g. when instances for possible power units are created (depending on the capabilities/connectors of the machine) which are currently not used.

16.2.4 Id

The Id Property represents the Id of the PowerUnit.

16.2.5 PowerOn

The PowerOn Property indicates if the PowerUnit is switched on.

16.2.6 ActualTemperature

The ActualTemperature Variable represents the current temperature of the PowerUnit.

16.2.7 Subtypes of PowerUnitType

There are two subtypes: HydraulicUnitType and ElectricDriveType.

16.2.7.1 HydraulicUnitType

The ActualPressure Variable represents the current pressure of the hydraulic unit.

16.2.7.2 ElectricDriveType

This subtype has no additional child elements.

17 TemperatureZones

17.1 TemperatureZonesType

This ObjectType is a container for temperature zones. It is formally defined in Table 65.

When instances for temperature zones are created, the BrowseNames shall be “TemperatureZone_<Nr>” (starting with 1) or as specified for the subtypes of TemperatureZonesType (e.g. “BarrelTemperatureZone_<Nr>” for instances of BarrelTemperatureZoneType, see 17.2.10).

17.2 TemperatureZoneType

17.2.1 TemperatureZoneType Definition

This ObjectType represents a temperature zone e.g. on moulds and barrels. It is formally defined in Table 66.

17.2.2 Index

The Index Property gives the number of the zone.

NOTE: If the Property Classification is used, for each temperature zone type the Index may start with 1.

17.2.3 Name

The Name Property represents the name of the zone.

17.2.4 IsPresent

This Property informs the client if the temperature zone is physically present and connected. May be FALSE e.g. when instances for possible temperature zones are created (depending on the capabilities/connectors of the machine) which are currently not used.

17.2.5 Classification

This Property informs the client about the type of the temperature zone. The TemperatureZoneClassificationEnumeration is defined in Table 67.

17.2.6 ControlMode

The ControlMode Property indicates how the temperature is currently controlled. The ControlModeEnumeration is defined in Table 68.

17.2.7 Temperatures

The following five temperatures for monitoring and controlling are defined:

17.2.8 ActualTemperature

The ActualTemperature Property represents the current temperature of the Zone.

17.2.9 StandbyTemperature

The StandbyTemperature Property represents the standby temperature of the Zone.

17.2.10 Subtypes of TemperatureZoneType

The TemperatureZoneType has two subtypes to distinguish between temperature zones on barrels and in moulds.

17.2.10.1 BarrelTemperatureZoneType

The Position Property represents the location of the temperature zone on a barrel. Counting starts with 1 beginning from the feeding. The highest position is at the nozzle.

When instances are created the BrowseNames shall be “BarrelTemperatureZone_<Nr>” (starting with 1).

17.2.10.2 MouldTemperatureZoneType

The subtype has no additional child elements.

When instances are created the BrowseNames shall be “MouldTemperatureZone_<Nr>” (starting with 1).

NOTE: Each MouldTemperatureZone belongs to a Mould. Numbering starts with 1 for each Mould. That means Mould_1 has a MouldTemperatureZone_1 and Mould_2 has also a MouldTemperatureZone_1.

18 JobsType

This clause defines ObjectsTypes for managing production jobs on the machine and for information on their status including process parameters (temperatures, pressures…).

18.1 JobsType Definition