Object Naming, Description and Usage Standards

The standards provided in this chapter are binding to the exact single character level including upper and lower character. Any deviation or even an unchecked typo is considered a rule violation. The correct case for object names and object descriptions is required (for readability, integrity and consistency reasons, not for system functionality).

Objects violating the given rules are considered to be removed by the System-Administrators at any time and without notice.

In a later stage, integrity scripts will be implemented which monitor the guideline adherence, compiling reports with detected deviations.

For any (perceived) need of an engineering or DevOps team member to deviate from the given guidelines, we suggest to install a complete sandbox (playground) system on a personal computer not being part of either the D, Q or P instance. The D system instance is expressively included with the guidelines given here.

I/O Model

This section defines the standards in terms of usage and naming of the top-level objects in the inmation I/O Model.

Root Object

No special naming/description consideration is applied. The Root object cannot be renamed.

System Object

The following names and descriptions are binding:

Table 1. System Object Naming Conventions
Role Object Name Object Description

D

System

GXPC Development System

Q

System

GXPC Qualification System

P

System

GXPC Production System

The Role is provided as instance name for component installations. Scripts can read the Role with the property inmationComponent.inmationInstance.

Core Object (Master)

Table 2. Core Object Naming Conventions
Role Object Name Object Description

D

Core

GXPC Development System Master Core Component

Q

Core

GXPC Qualification System Master Core Component

P

Core

GXPC Production System Master Core Component

Core Object (Local)

Table 3. Local Core Object Naming Conventions
Role Object Name Object Description

D

<SiteCode>

GXPC Development System Local Core Component located in <SiteName>, <SiteCountry>

Q

<SiteCode>

GXPC Qualification System Local Core Component located in <SiteName>, <SiteCountry>

P

<SiteCode>

GXPC Production System Local Core Component located in <SiteName>, <SiteCountry>

Connector Object

All Connector objects are to be named and descriptions are to be set according to the following table. The Connector instance name installed on the host machines shall match the object name exactly.

Connector objects are suffixed with a maximum of two extensions, separated by dashes. The first extension should be used to identify the local network segment (VLAN), or the Connector component’s host computer, the second extension to determine a special area or system, that this particular Connector covers.

The second extension can have multiple parts in itself, sometimes it makes sense to reflect a production area like a packaging line, sometimes machine vendor or type should be determined by the Connector name. This is important for Connector components which are deployed to connect a single distinct system. In such a scenario, it could be that in the same production area (and the same VLAN) one Connector component is used to integrate multiple OPC UA servers on remote machines, but in addition there is one (or multiple) Connector components installed directly on a computer belonging to one distinct automation system.

It is up to the members of the engineering teams to ensure consistency of the <Ext2> part, but as a general rule, different name parts of <Ext2> shall be separated by underscore ("_") instead of dash ("-") characters.

Table 4. Connector Object Naming Conventions
Role Object Name Object Description

D

<SiteCode>-<Ext1>[-<Ext2>]

GXPC Development System Connector Component, located in <SiteName>, <SiteCountry>, network segment <Ext1>, covering <Ext2>

Q

<SiteCode>-<Ext1>[-<Ext2>]

GXPC Qualification System Connector Component, located in <SiteName>, <SiteCountry>, network segment <Ext1>, covering <Ext2>

P

<SiteCode>-<Ext1>[-<Ext2>]

GXPC Production System Connector Component, located in <SiteName>, <SiteCountry>, network segment <Ext1>, covering <Ext2>

Server Object (Master)

All Server objects are to be named and descriptions are to be set according to the following table. The Server instance name installed on the host machines shall match the object name exactly.

Table 5. Server Object Naming Conventions (Master)
Role Object Name Object Description

D

OPCServer-Global-<Ext1>[-<Ext2>]

GXPC Development System Server Component for Master Core, network segment <Ext1>, covering <Ext2>

Q

OPCServer-Global-<Ext1>[-<Ext2>]

GXPC Qualification System Server Component for Master Core network segment <Ext1>, covering <Ext2>

P

OPCServer-Global-<Ext1>[-<Ext2>]

GXPC Production System Server Component for Master Core, network segment <Ext1>, covering <Ext2>

Assignment of the <Ext1> and the <Ext2> extensions follows the same principles as for the Connector component.

Server Object (Local Core)

All Server objects are to be named and descriptions are to be set according to the following table. The Server instance name installed on the host machines shall match the object name exactly.

Table 6. Server Object Naming Conventions (Local)
Role Object Name Object Description

D

OPCServer-<SiteCode>-<Ext1>[-<Ext2>]

GXPC Development System Server Component, located in <SiteName>, <SiteCountry>, network segment <Ext1>, covering <Ext2>

Q

OPCServer-<SiteCode>-<Ext1>[-<Ext2>]

GXPC Qualification System Server Component, located in <SiteName>, <SiteCountry>, network segment <Ext1>, covering <Ext2>

P

OPCServer-<SiteCode>-<Ext1>[-<Ext2>]

GXPC Production System Server Component, located in <SiteName>, <SiteCountry>, network segment <Ext1>, covering <Ext2>

Assignment of the <Ext1> and the <Ext2> extensions follows the same principles as for the Connector component.

WebAPI Server Object (Master)

All WebAPI Server Objects are to be named and descriptions are to be set according to the following table. The WebAPI Server instance name installed on the host machines shall match the object name conventions.

Table 7. WebAPI Server Object Naming Conventions (Master)
Role Object Name Object Description

D

WebAPIServer-Global-<Ext1>[-<Ext2>]

GXPC Development System WebAPI Component for Master Core, network segment <Ext1>, covering <Ext2>

Q

WebAPIServer-Global-<Ext1>[-<Ext2>]

GXPC Qualification System WebAPI Component for Master Core network segment <Ext1>, covering <Ext2>

P

WebAPIServer-Global-<Ext1>[-<Ext2>]

GXPC Production System WebAPI Component for Master Core, network segment <Ext1>, covering <Ext2>

Assignment of the <Ext1> and the <Ext2> extensions follows the same principles as for the Connector component.

WebAPI Server Object (Local Core)

All WebAPI Server Objects are to be named and descriptions are to be set according to the following table. The WebAPI instance name installed on the host machines shall match the object name conventions.

Table 8. WebAPI Server Object Naming Conventions (Local)
Role Object Name Object Description

D

WebAPIServer-<SiteCode>-<Ext1>[-<Ext2>]

GXPC Development System WebAPI Component, located in <SiteName>, <SiteCountry>, network segment <Ext1>, covering <Ext2>

Q

WebAPIServer-<SiteCode>-<Ext1>[-<Ext2>]

GXPC Qualification System WebAPI Component, located in <SiteName>, <SiteCountry>, network segment <Ext1>, covering <Ext2>

P

WebAPIServer-<SiteCode>-<Ext1>[-<Ext2>]

GXPC Production System WebAPI Component, located in <SiteName>, <SiteCountry>, network segment <Ext1>, covering <Ext2>

Assignment of the <Ext1> and the <Ext2> extensions follows the same principles as for the Connector component.

Intermediate (non-Productive) Model Entries

It shall be possible to extend the enterprise:inmation information model with temporary entries according to the following rules.

Three model node names are considered to be Reserved Names, as shown in the table below. Note that an ObjectDescription must not be provided for the three reserved names.

Table 9. Model Naming Conventions
Object Name Usage Description

__debug

debug folders start with a double underscore in order to distinguish them from in-built functions creating _debug folders automatically.

debug folders can be created by any engineering team member or DevOps team member with the restrictions and duties described here.

Objects hosted in an object with this name are considered tests with the responsibility of teams and individuals to remove substructures which are not needed anymore.

The debug folder should only be used for troubleshooting. As such, the debug logic should be hosted in a subfolder indicating the problem, such as __debug/PerformanceHit where "PerformanceHit" would describe the problem which is to be addressed with the logic contained in the subfolder.

Once the problem has been addressed and the logic is not required anymore it should be removed from the model. The user removing the last __debug/<Problem> from the debug folder should also remove the debug folder itself.

The usage of debug folders in the P instance requires acknowledgement from the System-Administrators.

_sandbox

_sandbox folders can be created by any engineering team member or DevOps team member with the restrictions and duties described here, and only in D instances of the system.

Objects hosted in an object with this name are considered tests with the responsibility of teams and individuals to remove substructures which are not needed anymore. The first team member creating a _sandbox folder shall create two more folders beneath the _sandbox folder indicating the team and the individual, e.g. _sandbox/inmation/HeikoL

The usage of _sandbox folders in the Q or P instance is not permitted.

_temp

Objects hosted in an object with this name have very short lifetime. The temp object is supposed to be emptied on regular scheduled basis (e.g. midnight). The creator should create another folder beneath the _temp folder, in case there should be parallel use on a given day (such as _temp/TimoK)

The usage of _temp folders in the P instance requires acknowledgement from System-Administrators.