When a CompositeBuilder or Integrator receives a shipment of Devices it needs to connect them to their network and verify their authenticity. This process is automated by the use of a Registrar that detects new Devices added to the network, inspects their DeviceIdentity Certificates and finds the corresponding DeviceIdentityTicket. If a match was found the Device is accepted and can be provisioned for use on the network. See 7 for a complete description of this process.

There are two modes of operation that a Device can use depending on whether it is a Client or a Server. Clients use PullManagement which is defined in 7.2. Servers use PushManagement which is described in 7.3. Devices which are a Client and a Server may use either model.

The authentication process requires secure communication using OPC UA. A Device shall have a Client or Server installed on the Device which is used for Device Onboarding, application setup and configuration. This Application is called the “Device Configuration Application” or DCA. When a Device is first connected the DCA is configured to use any of its DeviceIdentity Certificates as its Application Instance Certificate. Note that DeviceIdentity Certificates will not have a DNS name or IP address because these values are not known when the DeviceIdentity Certificate is created. Therefore, the Registrar shall suppress host name validation errors when communicating with a DCA. The Registrar should verify that the DCA is running on a network designated by the RegistrarAdmin as a source for new Devices.

Once the Device has been authenticated by the Registrar, it is provided with an Application Instance Certificate, called a DCA Certificate, that is used for any subsequent communication. The DCA Certificate will have a shorter lifespan and a CA which is managed by the OwnerOperator. This Certificate allows all Applications running on the Device to automatically be onboarded and configured without human intervention.

When a Device is first deployed it may have out of date firmware that needs to be upgraded before it can participate in the network. The SoftwareUpdateManager may use the software update model (PushManagement only) in OPC 10000-100 or it may rely on proprietary mechanisms that are specific to the Device. The Device will not get access to the network until the SoftwareUpdateManager indicates that the Device is up to date and whether a software update was applied. Once the firmware is updated, the Registrar can issue an Application Instance Certificate to the DCA.

Application Instance Certificates issued to a DCA shall not be used for communication with any application other than the Registrar, SoftwareUpdateManager, CertificateManager or a configuration application that acts on behalf of those agents. The CertificateManager shall restrict the Applications that a DCA is permitted to manage. A simple restriction would limit Certificate Requests to the host names/IP addresses that appear in the DCA Certificates. More complex rules could exist for complex Devices. OwnerOperators may choose to create a special VLAN (Virtual LAN) that is only used for communication using the DCA Certificates.

The registration process here also applies to externally visible Devices that are contained in a Composite. In these cases, the CompositeBuilder provides the list of Devices.

When a Device is first connected to the network it may not have a properly synchronized clock (e.g., a battery backed clock set by the manufacturer). This means it will not be possible for the Device to check the validity period of the Certificates used to establish secure communication with the Registrar. In these situations, the Device should use a time synchronization protocol such as NTP to update the system clock at boot. If a time synchronization server is not available the Device may ignore the validity period for the Certificates provided by the Registrar.