It is recommended to harden the Cognex application’s host operating system to best protect the availability, confidentiality, and integrity of the data used by Cognex solutions. As an example, user access to Cognex applications is controlled by the operating system, so it is important to follow industry best practices in configuring how users authenticate to the operating system (for example, this can be done through integration with an Active Directory server). Other important considerations include auditing user actions on the host operating system to help create an audit trail of events and help enforce accountability of what occurs on the system. Finally, consider encrypting the host OS drives and using encryption mechanism when sending data to or from the Cognex host operating system to protect confidentiality. For more in-depth guidance on OS hardening, see OS hardening.

The latest release of VisionPro and Cognex Designer requires the latest VisionPro drivers and the latest supported VisionPro dongles, made by Wibu-Systems.

The VisionPro, Designer, and ViDi software require that a valid Cognex Security Dongle be installed directly to PCs running the software during all phases of operation (programming, processing, training, testing, and so on). Any attempts to temporarily remove, substitute, or share a Cognex Security Dongle may cause your system to operate incorrectly, and may result in the loss of data.

Cognex ViDi Licenses —The type of license on the Cognex Security Dongle determines the functionality and performance level of the ViDi tools in both runtime and training operation.

• Base—The base-level license is not optimized for fast performance. This option works only with a CPU (and is not compatible a GPU). With this option, the tools will only operate in inference mode, and cannot be retrained while the application is deployed.
• Standard—The standard-level license supports a single GPU (and is not compatible with multiple GPUs), and includes the Parameter Search utility. It is broken into the following options:
  • A 1-year Training license, which is used for application development.
  • A runtime license, with training capability, for deployed applications. With this option, the tools can operate in inference mode, and can also be retrained while the application is deployed.
  • A runtime-only license, without access to the training capability. With this option, the tools can only operate in inference mode.
• Advanced—The advanced-level license is for high-speed and/or high-resolution inspection applications. It includes the Parameter Search utility and the ViDi Client/Server Functionality. It is available in the following configuration options:
  • A 1-year Training license, which is used for application development, and supports up to four GPUs.
  • A runtime license, with training capability, for deployed applications. With this option, the tools can operate in inference mode, and can also be retrained while the application is deployed. This option supports up to two GPUs during inference operation.
  • A runtime-only license, without access to the training capability. With this option, the tools can only operate in inference mode. This option supports up to two GPUs during inference operation. For more information, see Cognex ViDi Licenses on the Cognex website.

It is recommended to deploy Cognex where the data resides and is used and processed. For example, keeping Cognex applications only on OT hosts is recommended to keep the OT data separated from other networks for protection purposes. In other examples, Cognex may be hosted on an IT network. In that example, it is recommended that Cognex pulls processed images or data from an IT database or asset where the data has already been securely moved from one network to another.

This is a recommended use case for transferring Cognex VisionPro runtime images and inference data to an SDP instance that is hosted on an IT network. This can be relevant when SDP is an aggregator of storage for different sites/OT networks and SDP can be routed to from the separate OT networks. An IDMZ is implemented as a buffer zone between Cognex and SDP so that files are transferred securely between the two networks (no direct traffic between IT/OT). The validated firewall rules below assume that there is a script that runs from the IDMZ network, that mounts to Cognex’s file share where the images and data are stored. This script then converts and posts these images to SDP on the IT network. For more information, see the Pravega Python-based image ingest section.