The CSP+ for machine is a data set that visualizes machine information to simplify development by application vendors of application software that manages, monitors, and controls the machine, and settings by the machine users. The CSP+ file for machine is CSP+ for machine described in the XML format. The CSP+ for machine contains the following information related to the machine.

  • Information related to the machine specifications
  • Machine information to be released for application software (machine information)
  • Information related to data to be acquired from the machine and its acquisition method (machine data)
  • Linked information between machine information and machine data

The CSP+ for machine consists of four type CSPP sections: FILE section, DEVICE section, COMM_IF section, and BLOCK section. Overview of the CSPP sections is shown in Table 51.

Table 5 1 – Overview of Sections in CSP+ for Machine

CSPP section name

Overview

Number of sections

FILE

Describes management information for CSP+ file for machine.

1 section

DEVICE

Describes information such as machine name, identification information, and machine specifications.

1 section

COMM_IF

Describes definition information for the machine information.

1 or more sections

BLOCK

Describes definition information for the machine data.

1 or more sections

Figure 51 shows the structure image of the CSP+ for machine.

image007.png

Figure 5 1 – Structure Image of CSP+ File for Machine

The CSPP sections consist of one or more CSPP parts. Figure 52 shows the structure image in a CSPP section.

image008.png

Figure 5 2 – Image of CSPP Section Structure

Type of CSPP parts included in the CSPP sections varies depending on the CSPP sections. Type of CSPP parts included in the FILE section is shown in Table 52, type of CSPP parts included in the DEVICE section is shown in Table 53, type of CSPP parts included in the COMM_IF section is shown in Table 54, and type of CSPP parts included in the BLOCK section is shown in Table 55.

Table 5 2 – CSPP Parts Included in FILE Section

CSPP part type

Information to be described

Number of parts

FILE_INFO

- Management information for CSP+ file for machine

(e.g. Date of file created, language information, file version)

1 part

Table 5 3 – CSPP Parts Included in DEVICE Section

CSPP part type

Information to be described

Number of parts

DEVICE_INFO

- Machine identification information

(e.g. Vendor name, model name)

- Machine's product information

(e.g. Specifications, image file name)

1 part

DEVICE_IF

- Information related to communications with the machine

(e.g. Communications protocol type)

1 or more parts

Table 5 4 – CSPP Parts Included in COMM_IF Section

CSPP part type

Information to be described

Number of parts

COMM_IF_INFO

- Machine identification information

1 part

COMM_IF_VARIABLE

- Machine information for realtime monitor

(e.g. Current value)

0 or more parts

COMM_IF_CONFIGURATION

- Machine information for general purpose

(e.g. Power consumption for 30 minutes)

0 or more parts

ENUM

- Options for setting range

0 or more parts

Table 5 5 – CSPP Parts Included in BLOCK Section

CSPP part type

Information to be described

Number of parts

BLOCK_INFO

- Machine data identification

1 part

BLOCK_MEMORY

- Variable machine data acquired from the machine

(e.g. Current value, measurement time)

0 or more parts

BLOCK_PARAM

- Machine-specific machine data not acquired from the machine

(e.g. Accuracy, collection cycle)

0 or more parts

ENUM

- Options for setting range

0 or more parts

There are COMM_IF_VARIABLE part and COMM_IF_CONFIGURATION part as CSPP parts managing the machine information. Machine information for realtime monitor is described in the COMM_IF_VARIABLE part and machine information for general purpose is described in the COMM_IF_CONFIGURATION part. As the information allowed for the COMM_IF_VARIABLE part is limited for realtime monitor, description is easy but the application is limited. On the other hand, there is less restrictions on the description for the COMM_IF_CONFIGURATION part where the machine information for the general purpose applications can be described. For example, a window display layout includes a monitoring window for machine information in the COMM_IF_VARIABLE part and a machine parameter read/write window for machine information in the COMM_IF_CONFIGURATION part.

The CSPP parts consist of one or more CSPP elements. The CSPP elements consist of one or more CSPP items. Figure 53 shows the image of the CSPP part structure.

image009.png

Figure 5 3 – Image of CSPP Part Structure

CSPP elements included in the CSPP parts consist of CSPP elements specified as specifications of CSP+ for machine and CSPP elements that can be flexibly specified by the machine vendors. In contrast, all the CSPP items included in the CSPP elements are specified by specifications of the CSP+ for machine.

Association information is set from one CSPP element in the COMM_IF_CONFIGURATION part managing machine information to one or more machine data in the BLOCK_MEMORY part or BLOCK_PARAM part. This means that aggregation of more than one machine data creates one machine information. The reason why this structure is required is that the information required by application software needs not only a simple measured value (current value) but also the accompanying information such as the time when the value is measured and accuracy of the value.

In contrast, setting association information from the CSPP element in the COMM_IF_VARIABLE part as the machine information to the machine data in the BLOCK_MEMORY part or BLOCK_PARAM part is not allowed. This is because the application is for realtime monitor and all the information required in the machine information can be described. Association between the machine information and machine data is illustrated in Figure 54.

image010.png

Figure 5 4 – Structure Image of CSP+ for Machine (Association between Machine Information and Machine Data)

The main use case for OPC classic specifications is the online data exchange between devices and HMI or SCADA systems using Data Access functionality. In this use case the device data is provided by an OPC server and is consumed by an OPC client integrated into the HMI or SCADA system. OPC DA provides functionality to browse through a hierarchical namespaces containing data items and to read, write and to monitor these items for data changes. The classic OPC standards are based on Microsoft COM/DCOM technology for the communication between software components from different vendors. Therefore classic OPC server and clients are restricted to Windows PC based automation systems.

OPC UA incorporates all features of classic OPC standards like OPC DA, A&E and HDA but defines platform independent and secure communication mechanisms and generic, extensible and object-oriented modelling capabilities for the information a system wants to expose. OPC UA is directly integrated into devices and is used for configuration, diagnostic and maintenance use cases in addition to online data exchange. OPC UA is an integrated communication interface used from sensor level devices up to enterprise applications.

OPC 10000-6 defines different mechanisms optimized for different use cases. The first version of OPC UA is defining an optimized binary TCP protocol for high performance intranet communication as well as a mapping to accepted internet standards like Web Services. The abstract communication model does not depend on a specific protocol mapping and allows adding new protocols in the future. Features like security and reliability are directly built into the transport mechanisms. Based on the platform independence of the protocols, OPC UA servers and clients can be directly integrated into devices and controllers.

The OPC UA Information Model provides a standard way for Servers to expose Objects to Clients. Objects in OPC UA terms are composed of other Objects, Variables and Methods. OPC UA also allows relationships to other Objects to be expressed.

The set of Objects and related information that an OPC UA Server makes available to Clients is referred to as its AddressSpace. The elements of the OPC UA Object Model are represented in the AddressSpace as a set of Nodes described by Attributes and interconnected by References. OPC UA defines eight classes of Nodes to represent AddressSpace components. The classes are Object, Variable, Method, ObjectType, DataType, ReferenceType and View. Each NodeClass has a defined set of Attributes.

This specification defines Nodes of the OPC UA NodeClasses Object, Method, Variable, ObjectType and DataType.

Objects are used to represent components of a system. An Object is associated to a corresponding ObjectType that provides definitions for that Object.

Methods are used to represent commands or services of a system.

Variables are used to represent values. Two categories of Variables are defined, Properties and DataVariables.

Properties are Server-defined characteristics of Objects, DataVariables and other Nodes. Properties are not allowed to have Properties defined for them.

DataVariables represent the data contents of an Object.

OPC UA defines a graphical notation for an OPC UA AddressSpace. It defines graphical symbols for all NodeClasses and how different types of References between Nodes can be visualized. Figure shows the symbols for the six NodeClasses used in this specification. NodeClasses representing types always have a shadow.

image011.png

Figure 5 5 – OPC UA Graphical Notation for NodeClasses

Figure shows the symbols for the ReferenceTypes used in this specification. The Reference symbol is normally pointing from the source Node to the target Node. The only exception is the HasSubType Reference. The most important References like HasComponent, HasProperty, HasTypeDefinition and HasSubType have special symbols avoiding the name of the Reference. For other ReferenceTypes or derived ReferenceTypes the name of the ReferenceType is used together with the symbol.

image012.png

Figure 5 6 – OPC UA Graphical Notation for References

Figure shows a typical example for the use of the graphical notation. Object_A and Object_B are instances of the ObjectType_Y indicated by the HasTypeDefinition References. The ObjectType_Y is derived from ObjectType_X indicated by the HasSubType Reference. The Object_A has the components Variable_1, Variable_2 and Method_1.

To describe the components of an Object on the ObjectType the same NodeClasses and References are used on the Object and on the ObjectType like for ObjectType_Y in the example. The instance Nodes used to describe an ObjectType are instance declaration Nodes.

To provide more detailed information for a Node, a subset or all Attributes and their values can be added to a graphical symbol.

image013.png

Figure 5 7 – OPC UA Graphical Notation Example

This section describes an example of the OPC UA server according to Figure 58, as an application example of the application software using the CSP+ for machine.

This example shows that the OPC UA server itself as the application software using the CSP+ for machine does not provide the function for the machine users and other application software such as SCADA and MES provides the monitoring and management functions for the machine users. When the application software using the CSP+ for machine is an OPC UA server, the address space that the OPC UA server discloses to the OPC UA clients is created from the CSP+ for machine based on the specifications specified in this document.

image014.png

Figure 5 8 – Operation Image of OPC UA Server Supporting CSP+ for Machine

Since this system configuration is achievable, vendors of application software such as SCADA and MES have the following advantage.

  • Since not a machine's own communications protocol but the standard OPC UA can be used for communications with machines, the development volume for the communication function can be reduced.

Vendors of OPC UA server application software have the following advantage.

  • Supporting the CSP+ for machine allows handling many machines supporting the CSP+ for machine as communication partners.

Machine vendors have the following advantages.

  • Since there is no need to request an application vendor to support the machine's own protocol when requesting the application vendor to develop application software dedicated to the machine, the development cost can be reduced.
  • Since information to be disclosed to the application software such as process statuses and operation histories of the machine can be limited to the range described in the CSP+ for machine, information related to know-how of the machine can be set to confidential.