Shoplogix Collector Software and 3^rd Party Solutions System Requirements

SLX Data Collector Software/Service

Company: Shoplogix Inc.

Author: Austin Kwok, C.E.T.

Revision: 1.01

Date: 2023/04/24

Table of Contents

Summary

The Shoplogix Data Collector software is designed to work in conjunction with an Open Platform Communication (OPC) server (ex. Kepware’s KEPServerEX) on the same local system to extract data from manufacturing production equipment including but not limited to Programmable Logic Controllers (PLC), Robotic Logic Controllers (RLC), Process Automation Controllers (PAC), and other I/O devices and sensors on an existing ethernet-based machine network. Machine data is aggregated and encrypted by the Shoplogix Data Collector software before pushed up to Shoplogix’s Amazon Web Service (AWS) Elastic Compute Cloud (EC2) web host, where it is decrypted and parsed for analytics and metric calculations. Although rare, any configuration change to the interaction between the web host and the Shoplogix Data Collector software are pulled down. Metrics are then retrievable by accessing the Shoplogix web portal. As the Shoplogix interface is a hosted web-based system, per-station external network accessible web-browsing is required.

This document will outline the system minimum and recommended requirements of each software component and their respective services, network topology, and data flow diagrams. Furthermore, the document will outline best practices with regards to ancillary hardware.

Shoplogix System Requirements

Local Collector System

Shoplogix requires a dedicated Windows-based system to operate. It is recommended that the system be either a virtual machine (VM) hosted on the customer’s server-farm, or that it be hosted on a physical desktop PC. All software components, required or optional, listed in this document must be installed on the same system. The system must also have network access, whether through virtual or physical Network Interface Cards (NICs), to the internal machine network where the production equipment to be monitored resides and to the external Internet network to push/pull data from the web portal hosted by Shoplogix.

Note: The necessary tasks of sourcing, installing, configuring, and maintaining a local collector PC, and ensuring the requisite features and services are available are the sole responsibility of customer. Maintaining a persistent routine backup of the local collector PC is highly recommended as the Shoplogix Data Collector software and other component software as outlined in this document require applied licensing, and the loss of the license will result in billable work to reinstall and configure said software.

Below are the minimum and recommended system requirements for the local PC taking into consideration the subsequent section outlines of individual software component system requirements to run efficiently:

Table 1: Recommended System Requirements

*Note: be aware that any IT policy required software including but not limited to security and intrusion detection software may affect the system requirements listed above.

Operating Requirements

Shoplogix Data Collector

Table 2: Operating Requirements for Shoplogix Software

*Note: growth rate storage scales against scan rate of tags, the number of associated machine connections, and associated job transactions; average growth rate for ten (10) machines with cycle count and sparse jobs is approximately 10 MB/day.

Kepware KEPServerEX V6 OPC Server

Table 3: Operating Requirements for KEPServerEX

Note: The KEPServerEX installation and licensing are tethered to the host MAC address.

IT Security and Policies

Port Exceptions

Depending on the IT policy, exceptions may need to be made to allow for applications to communicate inside/outside the network. Below is the list of port exceptions required by the Shoplogix system:

Table 4: Port Exceptions List

*Note: the list consists of common protocols used; only the ports defined by the technical discovery process and/or otherwise stated during implementation will be required.

Application Exceptions

Depending on the IT policy, exceptions may need to be made to allow for applications to communicate inside/outside the network. Below is the list of applications and their respective file paths:

Table 5: Application Exceptions List

Directory Whitelisting

Depending on the IT policy, exceptions may need to be made to allow for files and directories to be whitelisted from intrusion detect and/or malware software. Below is the list of file paths to be whitelisted:

Table 6: Directory Whitelist

Service and User Permissions

Depending on the IT policy, exceptions may need to be made with regards to service accounts and/or user access levels. During implementation, a local administrator with network access (ex. Active Directory domain user with local administrator rights) will be required to properly install the necessary component software for the Shoplogix system.

Below are the user access requirements list per service post-implementation:

Table 7: Service and User Permission List

System and Network Architecture

The Shoplogix system requires persisted communication between the data collector and the web host as well as between the data collector and the machine network. For the purposes of simplifying the explanation, the system is broken down into three (3) main components:

1. Data Collection Device(s) [internal machine network] – Plant Floor Machine Data

2. Data Collector PC [internal public network] – On-Site Collector PC

3. Web Host [external public network] – AWS Cloud

Below is a diagram outlining the system architecture for the Smart Factory Suite (Core), with visible segmentation between the Plant Floor Machine Data and the AWS Cloud by the On-Site Collector PC:

Figure 1: Shoplogix System Architecture

As the system was designed for signal edge detection with higher-level caching of stored events, it does not currently have the capability to pull cached data from data collection devices. What the system can do is cache data already collected from a data collection device if there is communication loss between the data collector PC and the cloud service. In other words,

• [internal machine network to internal public network] if the data collection device (ex. ADAM-6251) is disconnected from the data collector PC, any data missed during the communication outage will be lost; this is equally true for historian-styled data sources, such as DCS.

• [internal public network to external public network] If the data collector PC is disconnected from the cloud service, any data missed during the communication outage will batch upload when re-establishing communication. Note: keep in mind that there is a physical disk limitation with how much cached data can be stored equalling roughly 7 days of data.

To mitigate the above problem, it is recommended that a robust communication channel be maintained between the data collection devices and the data collector PC. Therefore, wired communication networking is the preferred method of communication between data collection devices and the data collector PC while it is strongly recommended that wireless devices and communication not be used due to the potential for disconnects and attenuation in industrial and manufacturing environments. If opting to continue with wireless networking, your mileage may vary, and it will be up to the customer to diagnose any potential networking and data loss issues as the first step in any troubleshooting process.

Data Encryption and Security

All external communication between the Shoplogix system and the AWS EC2 web host is authenticated and encrypted using Transport Layer Security (TLS) 1.2. Machine data is aggregated by the Shoplogix Data Collector software before being pushed up to the AWS EC2 instance for processing [internal > external]. When required, system configuration changes and updates are pushed from the AWS EC2 instance down to the Shoplogix system [external > internal].

Time Synchronization

It is strongly recommended that the system be synchronized with a corporate NTP server as transactions and message payloads are timestamped using the system’s clock. Asynchronous transactions and message payloads can cause data discrepancies, including but not limited to incorrect metric calculations and data loss.

System Maintenance and Updates

It is the customer’s responsibility that the system be routinely maintained as the expectation is to have reasonably high uptime for persistent data collection. As such, it is strongly recommended that the system be included in the maintenance plan managed by IT, whether local or corporate, including but not limited to scheduling Windows updates, scheduled system reboot cycles, and routine system maintenance.

Remote Access and Virtual Private Network (VPN)

Remote access and VPN requirements are at the discretion of the customer’s IT policy; as far as Shoplogix is concerned, we are brand- and protocol-agnostic. However, there are different access levels of needs depending on the phase of the project, as outlined in the sections below.

Implementation Phase

Shoplogix considers the implementation phase of the project as the deployment phase or hyper-care phase, where system access will be in high demand. During this phase of the project, Shoplogix will require access to the system to install, configure, and/or validate data with the intent to convert the system to be production ready (go-live). It is strongly recommended that during this phase of the project Shoplogix is given unfettered remote access to the system to prevent administrative hold-up of the project schedule.

Support Phase

During the support phase of the project, Shoplogix’s demand for system access is low. A typical situation would include Shoplogix requesting access to the system to troubleshoot an issue or incident as identified by the customer, or if Shoplogix determines there to be a bug that needs to be addressed and will pro-actively need system access to triage. Although it is strongly recommended that access established during the Implementation Phase be upheld, Shoplogix understands that it is unreasonable to have a permanent “back door” into a customer’s system from an external contractor and believe it to be reasonable to downgrade system access to “upon request as necessary”.

Web Portal Access

Browsers

It is expected that each user will have browser access to the web portal. Shoplogix has performed extensive testing with Google Chrome, Microsoft Edge, and other Chromium-based browsers within our development and sandbox-QA environments. Limited-to-no compatibility testing was performed against Mozilla Firefox and other browsers which may display visual artifacts if used. Microsoft Internet Explorer has been deprecated and phased out of support, resulting in it being considered unfit for use. As such, the recommended browser are Google Chrome, Microsoft Edge, or other Chromium-based browsers. Note: caching is required for metric display when accessing the Shoplogix Whiteboard and Analytics Portal, therefore we recommend that Smart TV’s built-in browsers not be used as they have significant memory limitations.

IP Address/Uniform Resource Locator (URL) Whitelisting

Although elastic addresses are assigned to each AWS EC2 instance, there are circumstances where the IP address will need to be changed. For this reason, it is strongly recommended that URL whitelisting be used as it is fixed to entitlement. The web portal for the data collection, entry, and visualization is not pre-allocated and will need to be configured during entitlement at the implementation phase; an assigned URL will need to be conveyed from the Shoplogix team during the implementation phase. The URL homepage syntax will reflect the following structure: https://<company>.shoplogix.com/*, where * denotes any subsequent page during navigation. Additionally, the operational analytics web portal will also need to be whitelisted, where the structure is not tied to any entitlement: https://portal.shoplogix.com/*; and the authentication for user login: https://identity.shoplogix.com/*.

User Access

Basic Authentication

Basic authentication is used for local communication between services, API calls, and job upload templating. This authentication method is only used locally – users will not be able access to the local collector system or AWS EC2 instance with this authentication.

OAuth Authentication

During implementation, the customer will need to supply a list of names and associated email addresses for proper OAuth registration and authentication to access the AWS EC2 web portal (whiteboard and analytics portal) hosted by Shoplogix. Once registered, an email will be sent to the associated email addresses for password creation. Once done, users will be able to log into the web portal using their email/password. Note: if required, Shoplogix can issue a reset password creation email to users who require assistance.

Active Directory Authentication

AD authentication can be configured for web portal access, upon request.

Ancillary Hardware

Two of the three core functions of the Shoplogix system are qualified data entry and quantified data visualization. It requires operations to have the necessary tools to both manually enter qualifying reasons or comments and see the changes made for actionable information. This is accomplished by deploying a mix of workstations, monitors, TVs and peripheral equipment including barcode scanners. However, due to each customer’s facilities having their own environmental factors to consider, there is no single recommendation that will adhere to all variables present. Below is a general list of considerations:

Table 8: Display Considerations

The following sections are based on options that Shoplogix has historically seen deployed at customer facilities and should not be considered as either exhaustive or prohibitive of alternate solutions, including reallocation of existing resources for this project. It is the sole responsibility of the customer to source, requisition, purchase (or repurpose), and maintain hardware while ensuring conformance to their facility’s environmental, operational, and IT policies and needs.

Operator Data Entry

Workstations

Workstations are typically used in fixed areas of operations, where there is little necessary movement from the operator to get to and from the production area. As far as Shoplogix is concerned, workstations can either be thin or fat clients at the discretion of the customer, so long as the workstation can perform data entry, data visualization, or both functions as required. Keep in mind that the Shoplogix web portal requires internet access, through a URL by whitelisting or not, so the system specifications are based on a web browser’s minimal requirements while the environmental factors to consider as substantial. Depending on whether the purpose is for data entry or visualization, some items on the list below of historically used workstations by our customer-base may be more relevant than others – the list is neither exhaustive nor prohibitive:

Table 9: Workstations

Note: workstations require an associated monitor for display, network access, and peripheral equipment including keyboard and mouse if not touchscreen capable.

Tablets

Tablets are a great tool for operators to interact with the Shoplogix system for data entry and data visualization while being able to freely remove around their production area. In general, so long as the tablet can run a web browser and can access the Shoplogix web portal, whitelisted or not, it is sufficient. Below is a list of historically used hardware by our customer-base – the list is neither exhaustive nor prohibitive:

Table 10: Tablets

Facilities Data Visualization

Televisions

There are dozens of brands and hundreds of models of deployed televisions across our customer-base with the common restriction being not using Smart TV in-built web browsers due to their limited CPU, memory, and security updates that causes poor performance when accessing the Shoplogix web portal for extended periods of time. Environmental, operational, and IT policies and needs will dictate which TVs should be used.

Barcode Scanners

Some processes can be augmented with a manual barcode scanner to work inline with manual entry on a workstation for the Shoplogix system. Shoplogix leverages the wedge-scanner functionality of 1D/2D barcode scanners to inject delimited string values. Below is a list of historically used scanners by our customer-base – the list is neither exhaustive nor prohibitive:

Table 11: Barcode Scanners

Note: As scanner functionality is not configured for the core product, service time will need to be allocated to work with local customer resources to implement; if required, consult your implementation manager for further information.

Note 2: IP scanners have not been tested for production.

Ancillary Software

Shoplogix uses various software tools during the implementation and support phases of projects to assist with deployment and troubleshooting respectively. Below is a list of applications that historically have been used during a project life cycle – although neither exhaustive nor prohibitive, the listed software are grouped into assumed risk-levels as related to vendor trusted status or to atypical data payload and/or network traffic access:

Table 12: Ancillary Software List

iNTERFACEWARE Iguana

iNTERFACEWARE’s Iguana is an optional add-on that requires additional subscription and services per quotation and purchase order independent of the core implementation services and subscription costs due to the application engineering time required per use-case. The Shoplogix Data Collector software can leverage Iguana solution to Extract, Transform, and Load (ETL) parsed ERP job standards and other non-OPC-centric data. Iguana has two standard deployment topologies, depending on use-case: cloud-hosted solution and on-premise solution.

Operating Requirements

Table 13: Operating Requirements for Iguana

Port Exceptions

Table 14: Port Exceptions for Iguana

Application Exceptions

Table 15: Application Exceptions for Iguana

Directory Whitelisting

Table 16: Directory Whitelist for Iguana

Service and User Permissions

Table 17: Services and User Permissions for Iguana