WO2022106885A1 - Industrial control system - Google Patents

Abstract

A distributed industrial control system includes a core industrial management site having one or more components for remotely managing components of the industrial control system through a network and a plurality of industrial control sites that communicate with the core industrial management site, each of the industrial control sites including at least one control device that provides communication with the core industrial management site via the network only through the at least one control device, each of the control devices including a security module that facilitates secure communication by the at least one control device using data stored in the security module. The security module may have embedded therein one or more private credentials that are inaccessible from outside the security module. The private credentials may be used to exchange symmetric encryption keys with the core industrial management site to facilitate encrypted communication with the core industrial management site.

Description

INDUSTRIAL CONTROL SYSTEM

CROSS-REFERENCE TO RELATED APPLICATION

This application claims priority to U.S. provisional patent application no. 63/115,228 filed on November 18, 2020 titled "SECURE CLOUD OPERATIONS" and U.S. provisional patent application no. 63/135,909 filed on January 11, 2021 titled "SECURE CLOUD OPERATIONS", both of which are incorporated by reference herein.

TECHNICAL FIELD

This application is directed to the field of operational technology and industrial control systems and networks, and more particularly to the field of secure monitoring and management of industrial control systems and networks.

BACKGROUND OF THE INVENTION

Operational Technology (OT) refers to computer technology employed to monitor, control and automate the physical state of a system, for example, the control system of an industrial site, power plant, power grid, communication network, factory, laboratory, transportation system, etc. Such a control system may be referred to herein as an industrial control system (ICS). An ICS may employ any of a variety of OT, including, for example, programmable logic controllers (PLCs), supervisory control and data acquisition (SCADA) technology, and any of a variety of known protocols, including, for example, PROFINET (Process Field Net), PROFIBUS (Process Field Bus), Ethernet/IP (Industrial Protocol) and OPC UA (Unified Architecture). An ICS would also include I/O capabilities.

An ICS may be part of, or locally connected to, a proprietary network of an entity, where the proprietary network employs information technology (IT) to provide organizational (e.g., corporate, governmental, academic) management of the ICS on behalf of the entity and/or affiliates thereof. Such a proprietary network may be referred to herein as an organizational management network (OMN). FIG. 1A illustrates an example of an OMN 50. The OMN 50 may include an ICS 52 having a plurality of ICS devices 54-56, such as PLCs, connected to, and monitoring and/or controlling, a plurality of connected devices 62-64, such as valves, actuators, pumps, tanks, switches, etc. As used herein, an "ICS device" or "control device" is a device on an ICS configured to control one or more connected devices and communicate with one or more other devices on the ICS in accordance with one or more OT and/or ICS protocols, including protocols described herein. Although only three ICS devices and other connected devices are shown in FIG. 1A, it should be appreciated that an ICS may include more or less than three ICS devices connected to more or less than three connected devices. It should further be appreciated that each ICS device may be connected to, monitor and/or control multiple connected devices. The ICS device 55 may be an ICS controller, which may be configured (e.g., in accordance with PROFINET) to serve the additional role of monitoring and controlling other ICS devices on the ICS, such as the ICS devices 54, 56.

The ICS controller 55 may be communicatively coupled to an ICS supervisor 66 (e.g., a PROFINET supervisor), where the ICS supervisor 66 may be, or may include, software running on a computer (e.g., a non-PLC computer such as, for example, a laptop or desktop computer). The ICS supervisor 66 may be used by a system administrator to manage aspects of the ICS 52 by, for example, setting parameters on and monitoring information produced from the ICS devices 54-56. The ICS supervisor 66 may be configured in accordance with one or more protocols to perform SCADA (supervisory control and data acquisition) functionality for the ICS 52. The ICS supervisor 66 may serve as an interface between an information technology network (ITN) 68 of the OMN 50 and the ICS 52. For example, the ITN 68 may be an office network of the organization associated with the OMN 50. The ITN 68, via the ICS supervisor 66, may provide manufacturing executive-level functionality, enterprise resource-level functionality and other functionality for the ICS 52.

In some cases, the ICS supervisor 66 may be implemented on a relatively insecure system (e.g., compared to a PLC designed for an ICS), for example, a desktop (e.g., PC) or laptop computer. Because of security concerns, the ICS supervisor 66 may not be left continuously connected to the ICS 52, but rather, may be connected and employed as needed, for example, in response to an event or per a predefined schedule. Similarly, the ITN 68 and components thereof may not be as secure as the ICS 52 and the ICS devices 54-56. Furthermore, the ICS supervisor 66 (e.g., the SCADA functionality thereof) may be implemented with software from a vendor different from a vendor that provides other components, such as software on the ICS 52, manufacturing executive software, enterprise resource software, and/or other software on the ITN 68. Accordingly, much coordination may be required to implement workflow and business functionality between the ICS devices 54-56, the ICS supervisor 66 and components on the ITN 68, thus potentially causing inefficiencies, delays, and insecurities on the OMN 50.

Furthermore, the ICS 52 may be connected to public and private network clouds according to any of a variety of known architectures. Networks including a network cloud (public or private) connected to one or more ICSs, and which may include at least a portion of an OMN to which the ICS belongs, may be referred to herein as an ICS-cloud network (ICN). Connecting an ICS to a cloud network (as part of an ICN or otherwise) introduces further cybersecurity vulnerabilities. Some sources estimate that cyber-security breaches have resulted in at least ten major electrical outages, sixty nuclear power plant cyber incidents with more than fifteen resulting in reactor shutdowns, fifty cases involving significant environmental releases, one hundred cases involving physical equipment damage (excluding servers or other IT equipment), and more than thirty billion dollars in damages, including electric outages, pipeline failures, dam failures, and bankruptcy of several companies as a result. Specific examples of cyber-security breaches of ICSs include the Stuxnet computer worm attack on uranium enrichment centrifuges in Iran, the Prykarpattya Oblenergo cyberattack on a Ukraine power grid, the DragonFly malware attack on ICSs in the US and Europe, and the 2016 cyberattack at ThyssenKrupp AG.

Existing ICNs offer limited cyber-security for the components of the ICS and the OT data generated thereby to protect against cyber threats. Some solutions encrypt OT data during transmission from an ICS to a public cloud, for example, using VPN tunnels and/or TLS communication, and rely on whatever protection is afforded by the cloud provider for the data at rest, such as encryption. Other security solutions include so-called demilitarized zones (DMZs), which are physically discrete sub-networks that serve as security buffers between an ICS and a remainder of an ICN, and which can provide firewalls and latency between the ICS and the remainder of the ICN.

However, existing security solutions for ICNs are lacking. None of the conventional solutions adequately provide CC-EAL3 (Common Criteria — Evaluation Assurance Level 3) or better security protection. Furthermore, none of the ICN security solutions on the market today provide end-to-end encryption of OT data from an ICS (e.g., a PLC of the ICS) to the storage of the OT data on the cloud (e.g., on a server in the cloud). In addition, ICSs may not adequately protect the integrity of software running on ICS devices of an ICS.

In view of the known security shortcomings of systems for managing industrial resources, including ICNs, the International Society of Automation (ISA) developed, and the International Electrotechnical Commission (IEC) adopted, the ISA/IEC 62443 series of international standards for the secure management, including automation and control, of industrial systems (hereinafter referred to as "IEC 62443"). IEC 62443 includes several different sections describing both technical and process-related aspects of industrial cybersecurity. However, existing industrial management systems lack in implementing various aspects of IEC 62443.

Another potential drawback of known industrial management systems is that individual devices may have to be configured individually, in some cases manually on site. In this known industrial management systems, the secure operation of the devices might then depend on the specific configuration of the devices. Furthermore, even if the configuration settings of a device are stored, there may not be an audit trail of the history of changes made to the configuration settings; and if there is an audit trail, the information therein may not be reliably secured to prevent information in the audit trail from being later altered or deleted inadvertently or intentionally. Referring to FIG. IB, a conventional industrial control system 70 may include a local corporate zone (IT) that is implemented using a cloud and separated by a firewall from a plant information zone (PIZ) office zone. The PIZ may be used for enterprise users for enterprise resource planning, domain servers, file servers and application servers. This PIZ office zone may also be protected by a firewall that interacts with a de-militarized zone, where a server with web applications is running. On a next lower level, the PIZ plant zone is secured by a firewall and may be used for typical processes for operational technology management and supervisory tasks such as manufacturing execution systems, process control, asset management and archiving log data. This level may also have servers for web applications, which may be located in a de-militarized zone. An industrial ethernet trusted zone is provided at a lower level where PCs are used for tasks such as collecting and visualizing data of a weighbridge or a reception. Data at this level may be coming from the basic process control system zone (BPCS), where e.g., a PLC is connected with a tank fill level sensor.

An issue with systems like those shown in FIG. IB is that installation of new state-of-the- art (SOA) devices into an already existing system (referred to as "brownfield operations") causes potential vulnerabilities to the cybersecurity of the existing system so that the existing system loses the security capabilities/certification. In such a case, a cyber risk analysis taking into account the new SOA device may need to be performed and recertification(s) of the system might be necessary. Furthermore, maintenance work executed manually at field devices may create cybersecurity vulnerabilities because, for example, service personnel create physical access to devices to maintain the SOA devices and the related software. For asset owners of complex industrial structures, it is difficult to keep inventories of devices and software states, in particular the cybersecurity state and the correlated risks of the operating devices at the field level and thus it is difficult to ensure that a system like that illustrated in FIG. IB is certified with respect to cybersecurity vulnerabilities.

In addition, it may be desirable to define business processes associated with the management of an industrial system, for example, using a business process modeling tool. However, there may not be any integration between the business processing modeling tool and the other components that manage the industrial control system, or the integration may be limited and/or cumbersome to implement.

What is desired is an ICN with improved cybersecurity, including end-to-end protection of OT data, and communications thereof, from an ICS to cloud storage, for example, providing CC-EAL3 protection and meeting the requirements of IEC 62443 or better. What is also desired is a more efficient and reliable way to communicate OT data from an ICS to a cloud and to record the OT data on the cloud. What is also desired is a more efficient, scalable way to configure and control and securely operate multiple ICS components. What is also desired is a way to better integrate the monitoring, automation and control of an ICS with business logic (e.g., business process modeling software) concerning the monitoring, automation and control of an ICS.

SUMMARY OF THE INVENTION

According to the system described herein, a distributed industrial control system includes a core industrial management site having one or more components for remotely managing components of the industrial control system through a network and a plurality of industrial control sites that communicate with the core industrial management site, each of the industrial control sites including at least one control device that provides communication with the core industrial management site via the network only through the at least one control device, each of the control devices including a security module that facilitates secure communication by the at least one control device using data stored in the security module. The security module may have embedded therein one or more private credentials that are inaccessible from outside the security module. The one or more private credentials may be used to exchange symmetric encryption keys with the core industrial management site to facilitate encrypted communication with the core industrial management site. The one or more private credentials may validate a source of data that is transmitted to the core industrial management site. Data transmitted to the core industrial management site may include blockchain data that is generated using the one or more private credentials. The security module may be a trusted platform module. The network may be a non-proprietary network, such as the Internet. The core industrial management site may be at a first physical site, and the at least one of the industrial control sites may be at a second physical site that is geographically separated from the first physical site. The at least one industrial control site may provide all cyber security relevant functions of the industrial control zone site. The at least one industrial control site may include a secure industrial control system interface device, an industrial control system controller, an industrial control system device, an industrial control system supervisor, a gateway, a sensor devices, and/or a monitoring device. The at least one industrial control site may provide an alarm in response to attempted intrusion. The attempted intrusion may be a physical intrusion that is detected using an ambient light sensor and/or a movement sensor. The attempted intrusion may be detected based on detecting improper protocols and/or improper parameters being provided to the at least one industrial control site. The improper protocols and/or improper parameters may be provided by an unauthorized device added by a wired interface of the at least one industrial control site. The improper protocols and/or improper parameters may be provided by an unauthorized device accessing a wireless interface of the at least one industrial control site. The wireless interface of the at least one industrial control site may be subject to a denial of service attack and/or a collision attack. At least some components of the at least one industrial control site may include machine readable QRC labels and/or RFID UHF labels. The labels may be used for automation and/or installation for the at least one industrial control site. Components of the at least one industrial control site my be monitored at the core industrial management site using widgets on a configurable dashboard. Components of the at least one industrial control site may be specified using a workflow that includes tasks that actuate components of and/or use data from the at least one industrial control site. The workflow may include risks, threats and vulnerabilities related to the components of the at least one industrial control site. The workflow may include alarms and messages related to the components of the at least one industrial control site. Integrating a plurality of industrial control sites into a distributed industrial control system may include each of the industrial control sites automatically registering with the distributed industrial control system upon being powered up. A data processing apparatus may include means for carrying out the steps of the method of claim 24. According further to the system described herein, configuring an industrial control site that communicates with a core industrial management site via a network only through at least one control device having a security module that facilitates secure communication by the control device using data stored in the security module includes configuring an interoperability lab having components that correspond to components of the industrial control site and the core industrial management site, testing the interoperability lab to detect cyber risks and vulnerabilities, adjusting components and/or software of the interoperability lab to address the cyber risks and vulnerabilities, and adjusting components and/or software of the industrial control site that correspond to the components and/or software of the interoperability lab that were adjusted to address the cyber risks and vulnerabilities. Adjusting components may include flashing software, personalization of devices, secure download of keys and credentials for the security module, and creating security objects for the security module. Detecting cyber risks and vulnerabilities may include production tests of printed circuit board assemblies, production tests of components of the interoperability lab, and examining production data. The industrial control site may automatically register with the core industrial management site in connection with installation of the industrial control site. Following automatic registration, the core industrial management site may validate if elements of a configurable dashboard of the core industrial management site correspond to components of the industrial control site. Alarms may be provided in response to a component of the industrial control site not having corresponding one of the elements of the configurable dashboard. Adjusting components of the industrial control site may include downloading software to at least one of the components from the core industrial management site and, prior to downloading, the core industrial management site may confirm that the software is provided by an authorized design center. The software may be provided as part of an electronic inventory at the core industrial management site. The software may be digitally signed by an entity of the core industrial management site. The core industrial management site may include a public key infrastructure to manage a public/private key pair used to digitally sign the software. The software may be downloaded using a wireless interface of the industrial control site. At least some configuration changes may require approval of two users. At least some configuration changes may be logged using a blockchain. The interoperability lab may include a cloud, a transformation layer, and a core services layer that provide simulation of the core industrial management site. The interoperability lab may include a simulation of a mobile network. The cyber risks and vulnerabilities may be provided by test cases that are developed according to industry standards. Test results may logged using blockchain technology. A data processing apparatus may include means for carrying out the steps of the method of any of claims 26-42.

According further to the system described herein, configuring a dashboard for an industrial control system includes obtaining a listing of one or more dashboard templates that define, for each industrial control device type, a plurality of configuration parameters and, for each configuration parameter, one or more potential values thereof, selecting a particular one of the dashboard templates, defining a dashboard of the industrial control system by selecting, for each control device of the particular one of the dashboard templates, values for corresponding ones of the configuration parameters, generating configuration data that corresponds to the particular one of the dashboard templates and selected values for the corresponding ones of the configuration parameters, and storing the configuration data along with a value that confirms the configuration data as part of a secure audit trail for configuration of the dashboard. The secure audit trail may be implemented as a blockchain and the configuration data may be recorded as a first transaction block of the blockchain. Configuring a dashboard for an industrial control system may also include changing a value of one of the configurations parameters of the dashboard to produce revised configuration data and storing the revised configuration data as a second transaction block of the blockchain that is based on the first transaction block of the blockchain. Configuring a dashboard for an industrial control system may also include, after defining the dashboard, receiving a heartbeat communication corresponding to the one of the industrial control devices of the dashboard and automatically deploying the dashboard in response to the heartbeat communication. Configuring a dashboard for an industrial control system may also include updating a virtual representation of at least one of the industrial control devices of the particular one of the dashboard templates. A first user may define the dashboard and a second user, different from the first user, may be required to approve the dashboard prior to storing the configuration data. Configuring a dashboard for an industrial control system may also include creating dashboard templates by defining particular ones of the industrial control devices thereon including corresponding configuration parameters and the one or more potential values thereof. A first user may create the dashboard templates and a second user, different from the first user, may be required to approve the dashboard templates prior to the dashboard templates being used to create dashboards. A data processing apparatus may include means for carrying out the steps of the method of any of claims 44-51.

According further to the system described herein, controlling a managed device of an industrial control system includes receiving an input from a user via a graphical control element that controls one or more behaviors of the managed device, where the input specifies a change to a parameter value for the managed device that modifies a behavior of the managed device, sending a secure communication to the managed device to change the parameter value, and storing a record of the secure communication and the parameter value along with a value that confirms the record as part of a secure audit trail for configuration of the managed device. The audit trail may be implemented as a blockchain and the record may be part of a first transaction block of the blockchain. Controlling a managed device of an industrial control system may also include receiving an acknowledgement communication including acknowledgement information about the parameter value having been changed and storing the acknowledgement information as a second transaction block of the blockchain that is based on the first transaction block of the blockchain. Controlling a managed device of an industrial control system may also include authenticating the user based on a first form of authentication, determining that the change in the parameter value will modify the behavior of the managed device and, in response to the change in the parameter value modifying the behavior of the managed device, requiring the user to provide a second form of authentication different from the first form. Controlling a managed device of an industrial control system may also include requiring approval of an additional user before allowing the change in parameter value to be applied to the managed device. The input may be entered on a second device that is remotely coupled to the managed device. The graphical control element may be part of a graphical dashboard, displayed on the second device, for controlling the first device. The graphical dashboard may control behavior of the first device in real-time. A data processing apparatus may include means for carrying out the steps of the method of any of claims 53-60.

According further to the system described herein, applying business logic to an industrial control system includes defining a workflow that includes a first subset of tasks that actuate components of and/or use data from the industrial control system and a second subset of tasks that are independent of the industrial control system, storing the workflow definition in a secure workflow register, initiating execution of the workflow, determining a next task of the workflow to execute, if the next task is from the first subset, performing a validation associated with the next task based on the workflow definition, including accessing the workflow definition in the workflow register, and completing performance of the next task if the validation is successful. The first subset of tasks may include a first type of task that requires interaction with a managed device of the industrial control system and a second type of task that requires interaction with a user device that interacts with the industrial control system. In response to the next task being the first type of task, transaction validation logic may be applied to a transaction record associated with the next task. Completing the performance of the next task may include storing a transaction record associated with performance of the next task in a secure transaction register. The workflow register may be a first blockchain and the secure transaction register may be a second blockchain different from the first blockchain. Performing the validation may include verifying that the next task is registered as part of the workflow definition. A business modeling component may define the workflow and an industrial system management component may communicate with the business modeling component to initiate execution of the workflow and to determine the next task of the workflow. Applying business logic to an industrial control system may also include the industrial system management component communicating to the business modeling component when performance of the next task is complete. The business modeling component may include software that graphically represents the workflow. The software may define and graphically represent the workflow in accordance with Business Process Model and Notation (BPMN) technology. The workflow definition may be stored in a secure workflow register as a smart contract. The secure business process register may be a blockchain and the workflow definition may be stored as a transaction block of the blockchain. A data processing apparatus may include means for carrying out the steps of the method of any of claims 62-73.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A is a block diagram showing a conventional organizational management network.

FIG. IB is a block diagram illustrating a conventional industrial control system.

FIG. 2A is a block diagram illustrating a thing management network including an industrial control system, according to embodiments of the system described herein.

FIGs. 2B, 2C and 2D are block diagrams illustrating secure industrial control systems, according to embodiments of the system described herein.

FIG. 3 is a block diagram illustrating a secure ICS interface device, according to embodiments of the system described herein.

FIG. 4A is a block diagram illustrating a sequence of communications between secure ICS interface devices, gateways and a server, according to embodiments of the system described herein.

FIG. 4B is a block diagram illustrating using a secure transaction record to communicate and store information on a thing management network, according to embodiments of the system described herein.

FIG. 5 is a block diagram illustrating a security module of a device, according to embodiments of the system described herein.

FIG. 6A is a block diagram illustrating a data object used in connection with managing a thing management network, according to embodiments of the system described herein. FIG. 6B is a block diagram illustrating a data structure of a data object used in connection with managing a thing management network, according to embodiments of the system described herein.

FIGs. 7A-7H illustrate examples of data objects, according to embodiments of the system described herein.

FIG. 8 is a flowchart illustrating configuring an ICS device for secure operation, according to embodiments of the system described herein.

FIG. 9A is a flowchart illustrating securely installing a software module on an ICS device, according to embodiments of the system described herein.

FIG. 9B is a flowchart illustrating securely executing a software module on an ICS device, according to embodiments of the system described herein.

FIGs. 10A and 10B are flowcharts illustrating securely communicating information between an ICS and a cloud on a thing management network, according to embodiments of the system described herein.

FIG. 11 is a timing diagram illustrating a sequence of communications involving an ICS on a thing management network, according to embodiments of the system described herein.

FIG. 12 is a flowchart illustrating an ICS device communicating information, according to embodiments of the system described herein.

FIG. 13 is a schematic diagram showing an industry park and a plurality of cellular base stations for a dedicated cellular network according to embodiments of the system described herein.

FIG. 14 is a schematic diagram showing a dedicated cellular network, a cloud, and other networks according to embodiments of the system described herein.

FIG. 15 is a flowchart illustrating a user device changing modes to access a dedicated cellular network according to embodiments of the system described herein.

FIG. 16 is a block diagram illustrating a management network, according to embodiments of the system described herein.

FIG. 17A is a block diagram illustrating an industrial system, according to embodiments of the system described herein.

FIG. 17B is a block diagram illustrating features of the industrial system of FIG. 17 A, according to embodiments of the system described herein.

FIG. 18 is a flowchart illustrating configuring an industrial system using an interoperability lab, according to embodiments of the system described herein.

FIG. 19 is a screenshot of a configurable dashboard, according to embodiments of the system described herein.

FIG. 20 is a is a flowchart illustrating creating or modifying a dashboard template for a managed device of an industrial system, according to embodiments of the system described herein.

FIG. 21 is a flowchart illustrating creating a dashboard for a managed device of an industrial system, according to embodiments of the system described herein.

FIG. 22 is a flowchart illustrating remotely configuring a device of an industrial system, according to embodiments of the system described herein.

FIG. 23 illustrates active control widgets, according to embodiments of the system described herein.

FIG. 24 is a flow chart illustrating remotely controlling a device of an industrial system, according to embodiments of the system described herein.

FIG. 25 is a block diagram illustrating managing a workflow on an industrial management system, according to embodiments of the system described herein.

FIG. 26 is a block diagram illustrating a workflow engine, according to embodiments of the system described herein.

FIG. 27 is a flow chart illustrating managing a workflow on an industrial management system, according to embodiments of the system described herein.

DETAILED DESCRIPTION OF VARIOUS EMBODIMENTS

Embodiments of the system described herein manage an industrial system distributed across multiple networks, for example by securely segmenting the industrial resources into a plurality of zones (sites), for example, in accordance with segmenting requirements specified by IEC 62443. The zones may include a core industrial management zone (CIMZ) to provide centralized management of the industrial system including, for example, implementation of a thing management network (TMN). The CIMZ may be communicatively coupled to a local corporate zone (LCZ) that may include an information technology network (ITN) providing manufacturing executive-level functionality, enterprise resource-level functionality and other functionality. The CIMZ and LCZ may be remotely coupled across one or more non-proprietary networks (e.g., a public network, such as the Internet) to one or more remote corporate zones (RCZs) and industrial control zones (ICZs). The managed devices of the ICZs may collectively represent the industrial resources of the industrial system being managed.

Each ICZ may include a secure control device having a security module that can enable the secure communication of state and control information between managed devices of the ICZ and the CIMZ. Each ICZ may be secure in that software and firmware thereof may only be modified and/or booted (i.e., securely booted) using private credentials embedded within a tamper-proof secure component (e.g., a hardware based TPM) of the security module. The control device may be configured to use private credentials of the security component to facilitate secure communication and control information of managed devices with the CIMZ, for example, over the one or more non-proprietary networks. The control device may be configured to control the secure transmission of all control and/or state information of managed devices between the ICZ and the CIMZ.

Embodiments of the system described herein may provide a secure, automated technique for configuring and controlling and operating managed devices of an industrial system. A graphical control interface (GCI) for controlling a managed device, which may be referred to herein as a "dashboard," may be configured, including the selection and configuration of one or more graphical control elements (GCEs), which may be referred to herein as "widgets." One or more dashboard templates may be created and later modified, and the creation and any modifications of the dashboard templates may be recorded in a secure audit trail, for example, as a block of a blockchain. Creating and/or changing a dashboard template by a first user may require approval by a second person, for example, in accordance with the dual approval requirements of IEC 62443.

The dashboard templates may be used to create dashboards for managed devices. One or more dashboards may be created and later modified, and the creation and any modifications of the dashboards may be recorded in a secure audit trail, for example, as a block of a blockchain. Creating and/or changing a dashboard by a first user may require approval by a second person, for example, in accordance with the dual approval requirements of IEC 62443.

In embodiments of the system described herein, one or more widgets of a dashboard may be configured to allow a user to control the behavior of an industrial device, for example, remotely and in real time. A widget that enables a user to control a device— industrial or otherwise— remotely and in real-time, may be referred to herein an "active control widget." For example, by changing device parameter values using an active control widget, e.g., from a device within a CIMZ of an industrial system, a user may remotely control a device of an ICZ in real-time. In some embodiments, modifying a parameter value that controls a managed device, i.e., altering behavior of a device, may require an additional authentication of the user, for example, using multi-factor authentication, e.g., in accordance with IEC 62443. In some embodiments, additional verification may only be required for certain parameters, for example, parameters for which the values thereof have safety implications.

Embodiments of the system described herein may enable flexible integration between the creation and execution of workflows, and the management of managed devices of a TMN, for example, in the management of an industrial system. A workflow engine may enable the definition of workflows that include tasks, where one or more of the tasks may be industrial task objects (ITOs) specific to the management of an industrial system, and one or more of the tasks may be non-ITOs specifying tasks not specific to the management of the management of the industrial system. A TMN of the industrial system may include a workflow manager that controls the execution of the processes and may control the execution of ITOs. The ITOs may include different types, including ITOs that require interaction with managed devices, ITOs that require interaction with user devices and ITOs that do not require interaction with devices of the TMN. The workflow manager of the TMN may be configured to handle each ITO according to its type.

The creation of workflow definitions, and any changes to the workflow definitions, may be registered in a secure record, for example, as a block of a workflow blockchain. The secure record of a workflow definition may be used to verify ITOs during execution.

Embodiments of the system described herein provide improved cybersecurity for an industrial control system (ICS) that is part of an ICS-cloud network (ICN) or that is independent of a cloud. The system may include a device configured to serve as a secure interface between an ICS and a network cloud, where the ICS and the network cloud may be part of an ICN and/or between an ICS and other components that may not include a cloud. Such a device may be referred to herein as a secure ICS interface device (SI I D). The ICN may be a network for managing connected devices, referred to herein as a thing management network (TMN), where the TMN or a portion thereof may be considered part of the Internet of Things (loT).

An SIID may serve any of a variety of roles in an ICS, including an ICN controller or a security module, and may be part of, or serve in place of, a programmable logic controller (PLC). In some embodiments, the SIID may be, or may include, an MYNXG® Edge and/or MYNXG® Sense device provided by MyOmega Systems GmbH having offices in Nuremberg, Germany (hereinafter "MyOmega") and/or its affiliates or may include one or more components and/or functionality thereof. In some embodiments, the SIID may act as a security module. Alternatively, the SIID may include or be locally coupled to a security module and/or a secure component (described in more detail elsewhere herein), which may include a trusted platform module (TPM) or secure element (SE), that provides a secure platform having stored therein at least one blockchain credential enabling the SIID to implement blockchain transactions that may be authenticated by other components of a TMN. Components/devices may be locally coupled by either being directly physically connected to (e.g., plugged into) each other or by being within a distance that enables wireless communication using Bluetooth (BT) and/or near field communication (NFC) technology. For example, the security module and/or secure component may be contained within a portable component (e.g., dongle, stick, card) that is locally coupled to the mobile user device or the security module may be a combination out of two or more TPMs distributed in two or more ICS devices.

The SIID also may include a private communication credential stored within the security module, where the private communication credential enables the establishment of secure communication channels with other components of a TMN, including other devices on an ICS. The SIID also may include other credentials stored within the security module or derived from and/or encrypted with credentials stored within the security module, which may be used to validate software (including firmware) before deploying the software and/or executing the software on the SIID. The SIID may be configured to enable communication with a gateway or cloud server independent of an ICS supervisor and/or other components of an organizational management network (OMN) of an entity. An ICS may be monitored and/or controlled by TMN cloud components independent of the ICS supervisor and/or other components of the OMN of the entity. Such independent monitoring and/or control may avoid security vulnerabilities and inefficiencies associated with the ICS supervisor and the OMN.

The system described herein may include one or more management components remotely located from the SIID and communicatively coupled to communicate via blockchain transactions (blocks of a blockchain) with the SIID. For example, the one or more management components may be, or may be included within, one or more centralized servers, and/or gateways (i.e., edge devices/servers) serving as intermediaries between the centralized server(s) and the SIID, where the gateways may provide edge computing and other functionality. The one or more management components may include one or more data structures that define a plurality of entities associated with ICSs, for example, a person, a site, a company, a process, connected devices, or correlated data, and may associate one or more attributes with the one or more entities corresponding to management of the ICS. Management of the ICS may be based on the one or more data structures defining entities and attributes thereof, and information communicated by the SIID to the one or more management components. Such information may be communicated in one or more blocks of a blockchain that is authenticated using the at least one blockchain credential stored in the secure component.

One or more contractual relationships between parties (e.g., companies, a company and a person) may be defined using blocks of a blockchain as records of smart contracts, which are described in more detail elsewhere herein. Furthermore, one or more contractual transactions between parties per the contractual relationships may be recorded as smart contracts. For example, the acceptance of terms and conditions by an entity with respect to a TMN, OMN or ICS may be recorded as a smart contract. Furthermore, one or more rules (e.g., with respect to a person, company, site, connected device, ICS, TMN, OMN, process or other object) may be recorded as part of a smart contract.

Illustrative embodiments of the system described herein will now be explained in relation to the drawings. It should be appreciated that the invention described herein is not limited to the following illustrative embodiments, as other embodiments, including variations and combinations of the following illustrative embodiments, are possible and intended to fall within the scope of the invention.

FIG. 2A is a block diagram illustrating a TMN 100, according to embodiments of the system described herein. Other embodiments of a TMN, including variations of the TMN 100, are possible and are intended to fall within the scope of the invention. The TMN 100 may manage any of a variety of connected devices, including tangible (i.e., physical) and/or intangible items and connected devices commonly controlled by an ICS, as described in more detail elsewhere herein. The TMN 100 may include secure ICSs 133-135 which may include SI I Ds 123-125 and be part of OMNs 143-145, one or more gateways (i.e., edge devices/servers) 119-121, one or more user devices 140-142, a transformation layer 102, a core services layer 110 and other components in a cloud 101, other components, or any suitable combination of the foregoing. In some embodiments, only portions (e.g., the ICSs 133-135) of the OMNs 143- 145 are part of the TMN 100, whereas other portions of the OMNs may be independent of the TMN 100, such as being part of a proprietary network of an organization. It should be appreciated that, while only three gateways, three user devices, three ICSs, three OMNs and three SI I Ds are shown in FIG. 2A, the invention is not so limited, as any number of gateways, user devices, ICSs, OMNs, and SIIDs may be used, taking into consideration feasibility based on the fiscal and management costs of network, compute and storage resources, etc.

Each of the gateways 119-121 may communicate directly with the cloud 101 and to a plurality of SIIDs. For example, the gateway 120 may communicate directly with the SIIDs 124, 125. Each of the gateways 119-121 may couple one or more SIIDs to the cloud 101, which may include one or more servers. In some embodiments, one or more SIIDs, e.g., the SI I D 123, may communicate with the cloud 101. In such embodiments, the SI ID 123 may be configured with any of the gateway functionality and components described herein, and may be handled like a gateway, at least in some respects, by the cloud 101.

In some embodiments, one or more gateways, such as the gateways 120, 121, may couple one or more user devices, such as the user devices 142, 141, to the cloud 101. In some embodiments, one or more user devices, such as the user device 140, may communicate directly with the cloud 101. In such embodiments, the user device 140 may be configured with any of the gateway functionality and components described herein, and handled like a gateway, at least in some respects, by the cloud 101.

Each of the gateways 119-121 may be configured with one or more capabilities of a gateway and/or a controller as described in U.S. Patent No. 9,509,628, titled "Managing Devices in a Heterogeneous Network," issued November 29, 2016, to Bernd Moeller (hereinafter the '628 patent), which is incorporated by reference herein, including capabilities described in relation to FIGs. 1 and 2 (and elsewhere) of the '628 patent. Each of the gateways 119-121 may be any of a plurality of types of devices configured to perform the gateway functions defined herein, such as, for example, a general-purpose computer, a more specialized device such as an MYNXG® gateway or controller available from MyOmega and its MYNXG® affiliates (e.g., MYNXG® Edge devices provided by MyOmega and the MYNXG® affiliates), any of variety of other devices, or any suitable combination of the foregoing.

Each gateway may include a security module (e.g., in a hardware layer of a controller described in the '628 patent), which may be used to perform any of a variety of data security operations, including encrypting portions of communications from/to SI IDs or other devices to/from gateways, encrypting portions of such information received at a gateway in an unencrypted form, or any of a variety of other functions described herein. For example, the gateway 120 may include a security module 127 having a trusted platform module (TPM) or secure element (SE) and/or other components, as described in more detail elsewhere herein. The security module 127 also may be employed for other data security operations used in various embodiments of the system described herein, including generating a one-way hash (or another type of hash) of a transaction record, or providing secure communications between components of the TMN 100, e.g., between the cloud 101, gateways, SI I Ds and/or end user devices. For example, the security module 127 and/or other components of the TMN 100, may be configured to implement Transport Layer Security (TLS) for HTTPS communications and/or Datagram Transport Layer Security (DTLS) for Constrained Application Protocol (CoAP) communications, as described, for example, in the '628 patent. Furthermore, one or more security credentials associated with any of the foregoing data security operations may be stored on the security module 127.

Each of the gateways 119-121 may be configured to process device status information received from one or more SI I Ds, as well as other sensors, monitoring devices and user devices of the TMN 100. Such processing may include analyzing detected physical properties and other information that may have been generated by an SI I D or another device of an ICS and providing instructions to the SI ID for the SI ID itself and/or another device of the ICS, as described in more detail elsewhere herein. For example, each of the gateways 119-121 may be configured with one or more connected device management applications 122 encapsulating such capability. Furthermore, each of the gateways 119-121 may include one or more edge applications 132 that may provide additional functionality to that of the one or more connected device management applications 122, where such additional functionality may be primarily directed to edge computing aspects of a gateway. It should be appreciated that certain connected device management functions may be shared between one or more connected device management applications 122 and edge applications 132. Each of the gateways 119-121 may include one or more components for implementing the one or more connected device management applications 122, the one or more edge applications 132, or combinations thereof. The one or more connected device management applications 122 and/or edge applications 132 may be configured to perform some or all of the analysis and/or control some or all of the actions described herein, for example, in implementing one or more defined states of a connected device lifecycle. Each gateway may be configured to implement any of the network communication technologies described herein, e.g., in relation to SI I Ds, so that the gateway may remotely communicate with, monitor and manage SI I Ds and other devices of an ICS.

Each of the SI I Ds 123-125 may also include one or more connected device management applications (not shown), having some or all of the same capabilities of the one or more connected device management applications 122. Each of the SIIDs 123-125 may include one or more components for implementing the one or more connected device management applications 122. By performing such processing at one or more gateways, and/or at the SIIDs themselves, as opposed to in a more centralized fashion on one or more servers in the cloud 101, the TNM 100 may implement and enjoy the benefits of more distributed edge-computing techniques.

The user devices 140-142 may be any of a plurality of devices (e.g., desktop computers, laptop computers, tablets, personal digital assistants (PDAs), cellular (e.g., smart) phones, other devices, or any suitable combination of the foregoing that enable a user to interact with other components (e.g., gateways, servers, SIIDs) of the TMN 100. Each of the user devices 140-142 may be configured with any of the functionality described in the '628 patent with respect to the UEs 54-56 of the '628 patent, including any user equipment functionality described in relation to FIG.s 2 and 3 of the '628 patent.

Each of the user devices 140-142 may be configured with any of the functionality described in the '628 patent with respect to the UEs 54-56 of the '628 patent, including any user equipment functionality described in relation to FIG.s 2 and 3 of the '628 patent.

In some embodiments, one or more gateways may be configured with user device functionality and/or one or more user devices may be configured with gateway functionality. Functionality described herein may be provided using software provided by MyOmega and the MYNXG® affiliates, including software provided under the name MYNXG® SMART.

In some embodiments, each of one or more user devices (e.g., the user devices 140- 142) may include a security module having the same or similar capabilities as the security module 127 of the gateway 120. A TPM may be used and may be integrated inside a user device, or the TPM functionality may reside inside a chip (system on chip) or the TPM may be coupled temporarily as a dongle or another device to the user device. Furthermore, one or more user devices may include one or more connected device management applications, or portions thereof, as described in more detail elsewhere herein.

The performance and security of the system described herein, including SI I Ds, user devices, gateways and servers in the cloud 101, may be improved using security modules like the security module 127 and/or other security modules described herein. A security module may be implemented within any of the gateways (e.g., MYNXG® Edge devices provided by MyOmega and the MYNXG® affiliates), SI I Ds (e.g., MYNXG® Sense devices or SI I C² PLC connectors provided by MyOmega and the MYNXG® affiliates), monitoring devices (e.g., MYNXG® Sense or SI I C² PLC connectors devices provided by MyOmega and the MYNXG® affiliates), user devices (e.g., UE devices with MYNXG® SMART functionality provided by MyOmega and the MYNXG® affiliates) or servers (e.g., MYNXG® Flow and MYNXG® Core provided by MyOmega and the MYNXG® affiliates) in the cloud 101, for example, during production, and may be used to personalize any such components. The personalization that occurs during production may include the creation of various secure credentials described herein. One or more of the security modules 127 and/or other security modules described herein may be integrated into an SI I D . Such gateways, user devices, SI I Ds and/or servers may be configured (e.g., during manufacturing or later) to implement a Public Key Infrastructure (PKI) for the management of keys and credentials. Other cryptographic technologies, including symmetric keys, private hash keys, public hash ledgers, etc., may be used. Security modules are described in more detail elsewhere herein.

The core services layer 110 may provide one or more services, which may be consumed by applications in the transformation layer 102 (which also may be referred to as an application layer or flow layer). The services may include services for managing ICSs, ICS devices and/or connected devices. For example, the services may include transaction services 112, connected device management services 116, ICS management services 118, security services 113, secure credential services 117, other services corresponding to connected devices, one or more databases and/or database management systems corresponding to any of the foregoing, and/or any suitable combination of the foregoing. The core services layer 110 also may include a REST API 111 that provides programmatic interoperability, including network communications, between the core services layer 110 and other components of the TMN 100, including the transformation layer 102, gateways, SI I Ds, user devices, monitoring devices and other components of the TMN 100. One or more services of the core services layer 110 may provide one or more data structures of objects, as described in more detail elsewhere herein.

The connected device management services 116 may include data about connected devices managed by the TMN 100. Any of the data included in any of the transaction service 112, the connected device management service 116 and the ICS management service 118 may include information also stored on an SI I D (e.g., SI I Ds 123-125) and/or a user device.

The transaction services 112 may include one or more transaction records, for example transaction blocks of a blockchain, involving ICS and/or connected devices managed by the TMN 100. The blockchain may serve as a secure transaction register (e.g., a distributed ledger) for the TMN 100 or one or more defined subsystems thereof and may be used to provide secure auditing/logging, as described in more detail elsewhere herein. Transactions may include smart contracts or any other commercial transaction involving one of the managed ICSs or connected devices, and also may include information, for example status information, relating to one or more ICSs or connected devices, that is not associated with a commercial transaction, as described in more detail elsewhere herein. Furthermore, the data stored within each of the other services, including the services 116, 118 within the core services layer 110, may be stored as one or more transaction records (e.g., transaction blocks of a blockchain), and may be part of the transaction register for the TMN 100 or one or more defined subsystems thereof. The core services layer 110 may be implemented using one or more servers in the cloud 101 (i.e., "cloud servers" or "TMN cloud servers").

The secure credential service 117 may serve as a certificate authority and may generate and store one or more secure credentials to be used in accordance with embodiments of the system described herein. These secure credentials may include a secure validation credential (SVC) 119, which may be used to validate software downloaded to SI I Ds, connected devices, user devices, monitor devices or other components on the TMN 100. For example, the SVC 119 may be a private encryption key generated by the secure credential service 117 to sign software downloaded to SI I Ds and other components. The secure credential service 117 may include a hardware security module (HSM) and may provide a highly secure environment in which keys are created, credentials are derived and/or signatures/hashes of software may be generated from the SVC 119 or a multiple of such keys from the SVC 119 or other sources or some combination thereof, for example, an environment meeting the requirements of the ISO/IEC 27001 and or the ISA/IEC 62443 information security standard. In some embodiments, all software downloaded to SI I Ds and other components on the TMN 100 may be digitally signed and/or encrypted and/or hashed using the SVC 119 or a multiple of such keys from the SVC 119 or other sources or some combination thereof.

As described elsewhere herein, an SI I D and/or other device may be configured with a credential (e.g., a public key) corresponding to keys created, credentials derived and/or signatures/hashes of software generated from the SVC 119 or a multiple of such keys from the SVC 119 or other sources or some combination thereof, which can be used to validate software received from the cloud 101 (e.g., directly from a server or through a gateway). That is, the credential may be used to verify that the software came from a trusted server of the TMN 100. Furthermore, the secure credential service 117 may serve as a certificate authority to verify the owner of a credential used by the SI I D or other component to validate the downloaded software, and the secure credential service 117 may issue digital certificates accordingly. For example, the secure credential service 117 may issue digital certificates in accordance with one of more standards and/or protocols, e.g., an X.509 standard. In some embodiments, the secure credential service 117 implements an HSM and/or the SafeNet KeySecure key management platform made available from Gemalto, having offices in Amsterdam, Netherlands or from Thales, having offices in Paris/France, or any comparable source. The secure credential service 117 creates a Private blockchain credential 422 which is, during production of the PLC, within the production step "personalization" loaded into the TPM while the last step of the production is the locking of the TPM. The Secure credential service 117 creates a certificate (blockchain certification credential, PUBLICK BLOCKCHAIN CERT) which includes the Public blockchain credential corresponding to the Private blockchain credential 422. The TPM inside the SI I D signs the data with the Private blockchain credential 422. The secure credential service 117 (Blockchain controller) validates the authenticity (PoA) with the blockchain certification credential.

The security service 113 may be configured to validate data received from an ICS, for example, originating from an SI I D and sent directly to a cloud server or through a gateway (as, for example, a block of a blockchain). For example, for a transaction record that originated from an SI I D, the security service may use a blockchain certification credential (PUBLIC_BLOCKCHAIN_CERT) corresponding to a private blockchain credential of the SI I D to verify the transaction record was indeed produced by the SI I D .

The security service 113 also may be configured to decrypt and encrypt data stored and/or transferred within the core services layer 110. The data may have been received from the transaction service 112 in response to the transaction service receiving data (e.g., in the form of blockchain records as described in detail elsewhere herein) from gateways, SI I Ds, connected devices, or user devices, as well as data generated in the cloud 101 itself, e.g., in the core services layer 110 or the transformation layer 102. The security service 113 may unpackage data received from gateways, SI I Ds, connected devices and user devices, decrypt the received data, and then repackage the data (e.g. to larger blocks) and encrypt the re-packaged data if the received data had been decrypted. Data may be repackaged to present the data to applications in the transformation layer in a format that reduces (e.g., minimizes) accessing and processing times of the data by the applications. Thus, in some embodiments, the security service 113 may be configured to decrypt data (e.g., received from a gateway, an SI I D, connected device or user device), process the decrypted data (e.g., including repacking the data), and encrypt the processed data. The encrypted data then may be provided by the security service 113 to the transactions service 112 and/or other components of the core services layer 110.

The transformation layer 102 may be implemented using one or more cloud servers. The transformation layer 102 may include one more application, such as cloud- or web-based applications, that utilize information and services related to ICSs and/or connected device management, including any of the information and services made available from the core services layer 110. For example, the transformation layer 102 may include one or more transaction data management applications 106, one or more ICS-related applications, including, for example, one or more SI I D management applications 107, one or more ICS management applications 108, an ICS digital twin 109, digital twins of connected devices (not shown), an inventory application (not shown), an order management application (not shown), one or more other applications or any suitable combination of the foregoing.

The one or more transaction data management applications 106 may be configured to provide access to any transaction data (e.g., smart contracts, connected device status, visitor status) described herein, for example, within a secure transaction register. One or more of these applications also may be involved in processing (e.g., generating and storing) blockchain transaction records (blocks of a blockchain), and participating in blockchain communications with other components of the TMN 100, as described in more detail elsewhere herein. For example, one or more transaction data management applications 106 may be configured to participate in a streamlined blockchain communication sequence, as described in more detail elsewhere herein.

One or more Sil D management applications 107 may be configured to provide functionality to manage and control SI I Ds remotely, including, for example, defining what data is reported by SI I Ds, and how (e.g., the format) and when (e.g., periodically, in response to certain events, etc.) such data is reported. One or more ICS management applications 108 may be configured to manage ICSs, including monitoring data generated thereby, collecting, and presenting information to users (e.g., via a dashboard or the like), providing controls to users of the dashboard to manage aspects of ICSs, translating user input received through the dashboard (or other GUI) into control information, and initiating the sending of control information to the ICS to implement the specified control.

In some embodiments, for one or more ICSs on the system, a significant amount of information corresponding to the ICS, or components thereof (e.g., an SI I D, ICS device or connected device being monitored or controlled), may be maintained in the transformation layer 102 (or in the core services layer 110). In some embodiments, the information maintained for an ICS or component thereof may present such a complete state of the ICS or component thereof that the information may be considered a virtual representation thereof, e.g., a digital twin such as, for example, the ICS twin 109. The state of the ICS or component thereof reflected in the ICS twin 109 or component twin (e.g., an SI ID twin) may be updated at such a frequency as to be considered a real-time digital virtualization of the ICS or the component.

The inventory application may provide an inventory of connected devices managed within the system (e.g., the TMN 100 or a defined subsystem thereof), including properties (e.g., characteristics) about each connected device in the system and collective information about connected devices in the system, including, for example, the current state of a connected device (e.g., within a connected device lifecycle as described in further detail elsewhere herein), various numbers of connected devices (e.g., number of connected devices purchased, numbers of connected devices in a particular state, number of connected devices at a particular locations, etc.), physical properties of the connected device (e.g., dimensions, weight), age of a connected device, current location of a connected device (e.g., one or more network identifiers for a mobile telephony network, Wi-Fi network, ISM network or other), operational status of the connected device, and any other properties corresponding to a connected device described herein. The inventory of connected devices may be a group (e.g., "fleet") of connected devices owned, leased, controlled, managed, and/or used by an entity, for example, a connected device producer, OEM, transporter or consumer, another type of entity, or any suitable combination of the foregoing. The order management application may manage connected device orders of customers, for example, all customers of an entity, e.g., an OEM. The order management application may maintain information about all past and current connected device orders for customers of an entity and may process the orders. The order management application may be configured to automatically order connected devices for an entity (e.g., a customer or OEM) based on connected device status information received from SI I Ds coupled to connected devices (e.g., via one or more gateways or directly from the SI I D itself), or information received from a user device about the connected device. For example, the order management application may have one or more predefined thresholds, e.g., of number of connected devices currently in use, number of damaged connected devices, etc., for which, upon being reached or surpassed, additional connected devices should be ordered. It should be appreciated that the inventory application and the order management application are described for illustrative purposes, and the transformation layer 102 may include one or more other applications 108 of any of a variety of types, for example, a value-add and/or business application, related to the management of connected devices. The one or more transaction data management applications 106, the one or more SI I D management applications 107, the one or more ICS management applications 108, the inventory application, order management application and one or more other application may be configured (e.g., via one or more APIs or other interfaces) to interact with other applications within the transformation layer 102, including each other. The applications or portions thereof may be programmed into gateways, Web browsers, SI I Ds, user devices and/or SIIDs of the TMN 100 as well. One or more applications of the transformation layer 102 may be provided as all or part of a Web client browser app, as a hybrid of a Web client browser app and native device applications or as native device applications. The applications may reside, or be programmed or downloaded into gateways (e.g., the MYNXG® Edge devices), SIIDs (e.g., the MYNXG® Sense devices or MYNXG® SIIC² PLC Connectors); monitoring devices (e.g., the MYNXG® Sense devices) or user devices (e.g., user devices with MYNXG® SMART functionality provided by MyOmega and the MYNXG® affiliates).

FIG. 2B illustrates in more detail the secure ICS 133 described elsewhere herein. Other embodiments of a secure ICS, including variations of the secure ICS 133, are possible and are intended to fall within the scope of the invention. The ICS 133 may include an ICS controller 208, the SIID 123, described above, and an ICS device 209, each of which may be directly physically connected or wirelessly coupled to connected devices 204, 206, 210. While FIG. 2B illustrates only three devices included in the ICS 133, each coupled to a connected device, it should be appreciated that the invention is not so limited. More or less than three devices may be included in the ICS 133, and more or less than three connected devices may be included. Furthermore, it should be appreciated that there also may be a one-to-many relationship between a component of the ICS 133 (e.g., an SIID, ICS controller and/or ICS device) and a connected device (i.e., one device directly coupled to multiple connected devices) or a many- to-one relationship between a component of the ICS 133 and a connected device (i.e., multiple devices coupled to one connected device). It should also be appreciated that a connected device may be any type of connected device that may be managed by a TMN, including, but not limited to, any type of connected device described herein.

The ICS 133 may be a part of a TMN 100' that also includes the gateway 120 and the cloud 101, through which the devices within the ICS 133 and the connected devices coupled thereto may be monitored and/or managed, as described in more detail elsewhere herein. For example, the SIID 123 may be configured to serve as an interface between the ICS 133 and the cloud 101, either through the gateway 120 or directly communicating with a server, as described in more detail elsewhere herein.

The ICS controller 208 and the ICS device 209 may each be a PLC and may be configured to implement one or more ICS protocols, for example, PROFINET IO. The SIID 123 may, in this case, also be configured as an ICS device and may be configured to implement one or more ICS protocols, for example, PROFINET IO, e.g., offering full PROFINET RT (real-time)/IRT (isochronous real-time) capabilities in accordance with at least PROFINET conformance classes A, B and C, as well as providing non-real-time (NRT) (e.g., TCP/IP) capabilities. NRT communication may be sufficient for non-time-critical information with transmission times in the range of 100 ms. RT communications may be required to have cycle times of ten ms or less, whereas IRT communications may be required to have cycle times of one ms or less. In the embodiment of FIG. 2B, the SI I D 123 also may be configured to implement one or more ICS protocols. The ICS controller 208 may be configured (e.g., in accordance with PROFINET) to serve the additional role of monitoring and controlling the ICS device 209 and the ICS-specific aspects of the SI I D 123, which, in the embodiment of FIG. 2B, does not serve the role of an ICS controller. The ICS controller 208 may be communicatively coupled to an ICS supervisor 202, e.g., outside of the TMN 100' but part of an OMN, where the ICS supervisor 202 may include software running on a non-PLC computer (e.g., a laptop or desktop computer), and may be used by a system administrator to manage aspects of the ICS, e.g., set parameters on and monitor information produced from one or more devices of the ICS, for example, in accordance with one or more SCADA technologies.

As described above, in FIG. 2B, the SI I D 123 may serve as an interface between the ICS 133 and the cloud 101, but may not serve the role of an ICS supervisor. Even though the SIID 123 is not serving as an ICS supervisor, and thus does not control or manage ICS-specific communications (e.g., in accordance with PROFINET or PROFIBUS) with other devices on the ICS 133, the SIID 123 may still monitor some or all such communications as part of fulfillment of a role of the SIID 123 as an interface between the ICS 133 and the cloud 101. That is, the SIID 123 may monitor such communications, and communicate information obtained or derived therefrom to the cloud 101, for example, using blockchain communications (blocks of a blockchain) as described herein and/or using other secure mechanisms.

In some embodiments, an SIID may serve both as such an interface to a TMN cloud and as an ICS controller interfacing to an ICS supervisor, or the ICS supervisor function may be implemented as part of the core services layer 110, for example, as illustrated in Fig. 2C. An SIID serving as an ICS controller may be referred to herein as a controller SIID. FIG. 2C shows in more detail the secure ICS 134 according to an embodiment of the system described herein. Other embodiments of a secure ICS, including variations of the secure ICS 134, are possible and are intended to fall within the scope of the invention. In contrast to the SIID 123 of FIG. 2B, the SIID 124 of the ICS 134 may be a controller SIID that, in addition to being an interface to the cloud 101, serves as an ICS controller having controller capabilities described in relation to the ICS controller 208. In such an embodiment, rather than using the ICS controller 208 (e.g., a PLC configured with PROFINET IO Controller capabilities), the SI I D 124 provides controller functionality. For example, in place of the ICS controller 208, the ICS 134 may have an ICS device 212 configured with the same or similar ICS capabilities as the ICS device 209, described above.

FIG. 2D shows an embodiment in which a corporate LAN 242 (IT network) is coupled to the cloud 101. The cloud 101 may be coupled to a gateway 120" (or other edge device) to exchange data therewith, including data for controlling an ICS and receiving information from an ICS. The gateway 120" provides similar functionality to the gateway 120, as described elsewhere herein. The corporate LAN 242 may also be coupled to a network 244, such as the Internet or possibly another network, including a cellular network, a private corporate network, or a combination of different types of networks. Another corporate LAN 246 (IT network) may also be coupled to the network 244. The corporate LANs 242, 246 may be coupled to the cloud 101 to exchange data therewith, including data for controlling an ICS and receiving information from an ICS. The corporate LANs 242, 246 may communicate via the network 244. In an embodiment herein, the corporate LANs 242, 246 may be geographically disperse, although in other embodiments the corporate LANs 242, 246 may be logically separated LANs (or VLANs) in the same geographic location. The corporate LANs 242, 246 may be part of different organizational management networks.

In some embodiments, it is possible for a component of the corporate LAN 246 to securely communicate with the ICS 134 to provide ICS commands thereto and to receive relevant information. The component may be a user device, such as a desktop or laptop computer. The communication would be through the cloud 101 and may use any appropriate protocol, such as SSL, TLS, or similar. Alternatively, the component may communicate using an Edge device (not shown) that is part of the corporate LAN 246 and through the cloud 101. The ICS 134 and/or the cloud 101 may include a secure component having a private communication credential that allows secure communication therewith, as described in more detail elsewhere herein. It is also possible for a component of the corporate LAN 242, such as a desktop or laptop computer, to exchange data and control information with the ICS 134. The communication between the corporate LAN 242 and the ICS 134 could be through the cloud 101 and the gateway 120" (edge device) and may use SSL, TLS, or similar and a private communication credential that enables secure communication.

It should be appreciated that, regardless of whether a controller SI I D is employed, an ICS may be monitored and/or controlled by a combination of an OMN and a TMN. For example, in some embodiments, the OMN may control the ICS (e.g., through an ICS supervisor independent of the TMN) and the TMN may simply monitor and record information (e.g., blockchain transactions in the form of blocks of a blockchain). In other embodiments, the TMN may control the ICS (e.g., through a gateway configured to serve as an ICS supervisor) and the OMN may simply monitor and record information. In yet other embodiments, both the TMN and the OMN may control certain aspects of an ICS, which may require coordination between administrators affiliated with the TMN and OMN to ensure complimentary control and avoid conflicting control.

In some embodiments, rather than the ICS supervisor 202 communicating with a separate ICS controller of the ICS 134, a gateway 120' may be configured to provide the same or similar ICS supervisor capabilities as described in relation to the ICS Supervisor 202. In such embodiments, the SI I D 124 may serve not only as an interface to the cloud 101 with respect to the connected device management aspect of a TMN 100", but also as an interface between the gateway 120', in a role of the gateway 120' as an ICS supervisor, and a network of the ICS 134. The SI I D 124 may communicate directly with the cloud 101 as the interface between the cloud 101 and the ICS 134 and/or through the gateway 120'.

FIG. 3 is a block diagram illustrating in more detail the SI I D 123, described elsewhere herein. Other embodiments of an SI I D, including variations of the SI I D 123 and the SI I D 124, are possible and are intended to fall within the scope of the invention. For example, a sensor device not having the ICS-related components and functionality described herein, which may be locally coupled to a connected device, may be configured with some or all of the non-ICS- related functionality and/or components as described herein for the SIID 123.

The SIID 123 may include a CPU core 311, a security module 313, sensor components 393, a network interfaces 303, an application framework 329, management components 397 and ICS components 399. The SIID 123 also may include one or more operating systems (not shown), one or more of which may be implemented as part of the security module 313 in some embodiments, as described in more detail elsewhere herein. The sensor components 393 may include a plurality of components primarily directed to sensor functions or basic operational functions of the SIID 123, and may include a timer 305, an integrated ambient light sensor 319, a movement sensor 309, other sensor components 305 (e.g., climate sensors), or any suitable combination of the foregoing.

One or more components of the SIID 123, such as the CPU 311, the one or more network interfaces (i/f) 303, the integrated ambient light sensor 319, the movement sensor 309, one or more other sensor components 335, the security module 313 and the timer component 305, may be implemented as part of an intelligent processing unit (IPU) which may be implemented using one or more software components, including an operating system of an MYNXG® Edge sensor platform made available by MyOmega and the MYNXG® affiliates. The SIID 123 may be implemented as part of, or include a connected device of, an MYNXG® Sense product made available from MyOmega and MYNXG® affiliates.

The CPU core 311 may include one or more CPUs, including, for example, an ARM CPU or other type of CPU, and may be configured with one or more of the following: required processing capabilities and interfaces for the other components of the SIID 302 described herein, an ability to be interrupted by the timer component 305 and by the movement sensor 309, random access memory, and nonvolatile memory (e.g., FLASH) for storage. In some embodiments, the CPU 311 may be implemented using an Arm Cortex M7 core like STM32F767/777-line CPU or a similar CPU made available by ST Microelectronics or another manufacturer. The timer component 305 may provide a clock for the CPU core 311 and for other components of the SIID 123. The timer component 305 may be configured to provide the clock at any of a variety of frequencies, for example, at 32KHz or lower. The frequency of the clock may be selected to balance a variety of factors, including, for example, cost, resource consumption (including power consumption) and highest desired frequency of operation.

The one or more network interfaces 303 may include a plurality of types of network interfaces, each interface configured to implement one or more particular technologies to enable communications with one or more types of networks. For example, the one or more network interfaces 303 may include one or more cellular communication interfaces enabling communications with cellular networks, and may be configured with technologies such as, for example, Long-term Evolution (LTE) and derivatives thereof like LTE narrowband (5G) and 5G capabilities including the capability to provide dedicated QoS channels and network resources and/or LTE FDD/TDD (4G), HSPA (UMTS, 3G), EDGE/GSM (2G) or CDMA technologies. Cellular communications may be used as one possible form of communication to enable an SI I D to communicate with one or more other devices of a TMN, such as systems described elsewhere herein, to perform any of a variety of functions. Such functions may include detection of geographic location of a connected device (e.g., to which a SI I D is affixed or otherwise coupled), including detecting a change in location from one cell of a cellular network to another cell, and a relative location of a connected device within a cell, for example, a radial distance from the cell phone base station. The connected device may be any of a variety of types of connected devices in any form, including, for example, an actuator, a switch, a latch, a door, a centrifuge, a turbine, an engine, a motor, a transmission, a valve, a heating element, a pallet, a container (e.g., an IBC), a tank, a c-level management container or fixed assets such as locks for pipes and doors within a cell, other connected devices, and suitable combinations of any of the foregoing. The one or more cellular communication interfaces may be, or may include or be part of, a cellular modem.

The one or more network interfaces 303 providing cellular communication in accordance with 5G may enable the SI I D 123 to create local networks, for example, an industry campus as defined by the Bundesnetzagentur for Germany, which is a private network that allows the reservation of bandwidth through dedicated bandwidth and system resources, including non-shared spectrum resources, and allows the provisioning of dedicated, highly reliable real-time services as may be required by an ICS network. The one or more network interfaces 303 may be configured to implement GPS technology, which in some embodiments may be integrated with cellular technology as part of a cellular modem. The network interfaces 303 also may be configured to implement UWB technology if accuracy of indoor location on the order of centimeters is desired, for example using one or more MYNXG® gateways (e.g., the MYNXG® Edge FCR Industrial or the MYNXG® Edge FCO Eco) available from MyOmega and MYNXG® affiliates. The network interfaces 303 further may be configured to implement Wi-Fi technology, e.g., in accordance with one or more 802.11 standards, which may save communication cost. The cost savings may be more desirable for larger fleets of connected devices. The Wi-Fi technology may be used to connect with hotspots at various locations and during various states of a lifecycle of a connected device, described in more detail elsewhere herein, and may serve as an option for establishing a communication path within a TMN, for example, as an alternative, or in addition to, a cellular communication path.

The one or more network interfaces 303 may be configured to implement Industrial, Scientific and Medical (ISM) band technology (also known as EU Sub 1 GHz Bands), e.g., 6L0WPAN, ZigBee, Lora and or Sigfox, to establish Wide Area Low Power links, having a range of, for example, 3000 meters, or perhaps more or less. In some embodiments, an ISM technology may be employed with 802.15.4 PHY, 6L0WPAN Layer 2 and MAC and CoAP protocol via ISM band.

The movement sensor 309 (e.g., an accelerometer) may be configured to detect and measure three-dimensional (e.g., relative to three axes) acceleration movement, and may use an optional gyroscope or artificial horizon, to detect the movement of a connected device and/or the SI I D itself. That is, the movement sensor 309 may be configured to detect relatively abrupt movement, e.g., as a result of a sudden acceleration, in contrast to a more general change in geographic location. Such a movement may occur, for example, as a result of a sudden stop, an accident, falling from a shelf, installation or deinstallation of devices in electrical cabinets, tipping over, being manually jostled, a hole in a road, a deformation of a railroad rail, wind turbulence impacting an airplane, stormy seas, etc. The movement sensor 309 may be used in combination with interrupt functionality of the CPU 311 to implement a deep sleep mode of operation, as described in U.S. Published Patent Application No. 2019/0272495, titled "Intelligent Container Management" by Bernd Moeller, published on September 5, 2019 (the '495 application), the contents of which are incorporate by reference herein. The movement sensor may be especially be realized to, together with the ambient light sensor, create a minimum tamper evidence.

The one or more other sensor components 315 may include climate sensors, which may be configured to measure any of a variety of climate conditions of the SI I D 123, e.g., inside a cavity of the SIID or inside a housing containing one or more components (e.g., an IPU) of the SI I D 123. Such climate conditions may include temperature, air humidity, air pressure, other climate conditions and/or any suitable combination thereof. While climate conditions may be measured inside a housing or cavity within the SIID 123, in some embodiments the SIID 123 may include a pressure compensation membrane (e.g., a climate pressure equalization gasket), and measurement cycles may be ultra-short such that the measured climate conditions are valid for an environment in an immediate vicinity of (e.g., surroundings) the SIID 123 as well. Climate sensors may be linked to an IPU of the SIID 123 through one or more M12.8 connectorbased digital and/or analog interfaces, and may measure any of a variety of climate conditions, including but not limited to: temperature, humidity and pressure or other climate conditions of a connected device, the contents or loads carried thereon (e.g., liquid, solid, air) and/or ambient air external to the connected device.

The integrated ambient light sensor 319 may serve to ensure the integrity of a cavity, housing and/or electronics of the SIID 123, including providing mechanical dust and water detection. The sensor 319 may enable detection of evidence of tampering and potential damage, and thus provide damage control to protect electronics of the SIID 123. The security module 313 may include at least one TPM (or SE), and may be implemented as, or include one or more components and/or functionality of, the security module 127 described in relation to FIG. 2A and/or other security modules described elsewhere herein. Middleware 329 may serve as middleware between the connected device management applications 321 and ICS management applications 323 on the one hand and the connected device control logic 306 and ICS management logic 307, respectively, on the other hand. The middleware 329 may provide an application framework that includes an API that exposes functionality of the connected device control logic 306 and ICS management logic 307 to the connected device management applications 321 and ICS management components 323, respectively. This functionality may include functionality to configure and manage connected devices, ICSs, the SI I D 123 itself and components thereof, security (e.g., blockchain communication, software validation), communications, other items, or any suitable combination of the foregoing. The management components 397 may include connected device management applications 321, connected device control logic 306, connected device interfaces 308, other components, or any suitable combination of the foregoing. The connected device interfaces 308 may include a variety of hardware components, in some cases configured with software, to implement physical interfaces between the SI I D 123 and connected devices 316 that are connected to, and managed by, the SI I D 123, for example, any of the types of connections described herein.

The connected device control logic 306 may include logic implementing core control elements of connected device management (e.g., independent of ICS aspects of such management) including any of the connected device management functionality described herein. In some embodiments, connected device management may include implementing state machines for one or more connected devices being managed by the SI I D 123, for example, based on predefined states of a connected device lifecycle and current status information of the connected device, e.g., as described in the '495 application.

The connected device management applications 321 may implement any of a variety of aspects of connected device management, e.g., any of the aspects described herein. The connected device management applications 321 may use executable relatively high-level language code (e.g., Java, C++ or C) that utilizes the middleware 329 to access elements of the connected device control logic 306. The connected device management applications 321 and/or connected device control logic 306 may include software components and functionality provided by one or more applications and/or services of the transformation layer 102 and/or core services layer 110, for example, connected device management services 116. Such components and functionality may have been installed during production of the SIID 123 or after production, for example, after the SIID 123 is installed in an ICS, in which case, the secure communication and software validation techniques described in more detail elsewhere herein may be employed. Furthermore, updates to such components and functionality may be received after production using such secure communication and software validation techniques.

The ICS components 399 may include ICS device interfaces 310, IC control logic 307, ICS management applications 323, other components, or any suitable combination of the foregoing. The ICS device interfaces 310 may include any of a variety of hardware and software for providing a physical ICS interface between the SIID 123 on the one hand and ICS devices 317 and/or connected devices 318 on the other hand. For example, the other ICS devices 317 may be other devices on a same ICS network as the SIID 123. The ICS device interfaces 310 may be configured in accordance with PROFINET and or PROFIBUS protocols, and may include one or more ethernet ports, slots, modules and/or submodules. It should be appreciated that ICS interfaces 310 may be integrated with and/or share physical connections and other hardware with the connected device interfaces 308.

The ICS control logic 307 may include lower layer ICS control logic and upper layer ICS control logic. The lower layer ICS control logic may include fieldbus hardware and firmware for synchronization and jitter control for communications with connected devices and/or other ICS devices, for example, for RT, IRT and NRT (e.g., TCP/IP) communications in accordance with PROFINET and/or PROFIBUS protocols. The upper layer ICS control logic may be a software stack for supporting one or more ICS protocols, for example, a PROFINET stack implementing one or more conformance classes of PROFINET (e.g., PROFINET CC-A, CC-B, CC-C or CC-D). The ICS Control Logic may also cover such protocols as EtherNet/IP and or Modbus TCP over Ethernet and or other versions of IP communications and the variations thereof which are utilized for automation purposes.

The ICS management applications 323 may include applications for implementing functionality to manage aspects of an ICS and/or a role of the SIID 123 as an interface between the ICS and a cloud of a TMN. The functionality may include validating messages received on the SIID 123, for example, from other components of the TMN (e.g., gateway, user device or cloud server), another device on the ICS of the SIID 123 or a device directly connected to the SIID 123, validating the data included in such messages, selecting information received in communications from connected devices and other devices on the ICS for transmission (e.g., as a record in the form of a block of a blockchain, as described in more detail elsewhere herein) to the TMN cloud, controlling how the selected information is formatted, packaged and transmitted, controlling when the information is transmitted, other functionality, or any suitable combination of the foregoing. Selecting the information to be transmitted may be done on a device-by-device (on the ICS) basis, and may include selecting RT, IRT and NRT communication elements, and selecting the protocol elements and messaging, including, for example, diagnostic data (e.g., associated with an IO path on the ICS), logbook entries, including records of alarms and diagnostic information for devices and/or connected devices on the ICS, and information to identify devices and aspects thereof. In some embodiments, the ICS management applications include an ICS communication selection application (not shown) that selects and controls how and when information received from devices on an ICS are formatted, packaged and transmitted to a cloud of a TMN.

The ICS management applications 323 and/or the ICS control logic 307 may include software components and functionality provided by one or more applications and/or services of the transformation layer 102 and/or core services layer 110, for example, the SIID management applications 107, ICS management applications, and ICS management services 118. Such components and functionality may have been installed during production of the SIID 123 or after production, for example, after the SIID 123 is installed in an ICS, in which case, the secure communication and software validation techniques described in more detail elsewhere herein may be employed. Furthermore, updates to such components and functionality may be received after production using such secure communication and software validation techniques.

The SIID 123 or an IPU included in the SI I D 123 may include digital and/or analog interfaces, which may utilize an M12.8 connector to communicate with the one or more sensors, for example, external to the SIID 123 or internal thereto (e.g., one or more of the other sensor components 315). Such interfaces also may utilize l²C busses as well. Such interfaces may include ModBus and/or FieldComm HART Bus and may use plug-and-play connectors of any of a variety or types, for example, PCB terminal blocks and PCB connectors e.g., a Phoenix contact. The one or more other sensor components 315 may include pressure sensors that are used to detect pressure imposed on a connected device (e.g., by a load of goods borne by the connected device or liquid/solid contents of the connected device), temperature array sensors to identify temperature profiles (e.g., the Melexis MLX 90621 Infrared sensor array made available from Melexis of Belgium, which provides 16x4 pixels), strain gauge sensors to identify forces imposed on a connected device (e.g., by measuring the strain imposed by a load on the monitoring device affixed atop the connected device, between the load and the connected device), for example, to determine a weight of contents of a connected device or a load borne by a connected device, RFID readers to read signals transmitted by RFID tags/transponders on a connected device or a load or contents (e.g., packaged goods) of a connected device, optical code readers to read one- or two-dimensional bar codes (e.g., Quick Response Codes (QRCs) or the like) labeling a connected device or contents or load of a connected device, other types of sensors, or any suitable combination of the foregoing. For simplicity of reference, the term "RFID/QRC reader" or "reader" may be used herein to mean an RFID reader and/or an optical reader, which could be a QRC reader. That is, an RFID/QRC reader may include an RFID reader, a QRC reader, another type of optical code reader, or any combination of the foregoing. In some embodiments, the QRC/RFID labels on connected devices and/or load items include a QRC code and/or serial numbers. In some embodiments, one or more RFID (UHF and NFC) readers may be implemented using an integrated circuit (IC) made available from NXP semiconductors, for example, the SLS3S4011_4021 model for RFID (UHF). The coding and communication of RFID/QRC information can be done in many forms, including, for example, using one or more of: ISO 18.000 part 6-compliant RFID tags, UHF EPC Global Generation- compliant communications, GSl-compliant bar codes, and GSl-compliant QRC codes.

In some embodiments, the SIID 123 or an IPU included therein may be extended with RFID (NFC) technology that may be connected via l²C interfaces or any other interface to connect the one or more sensor components 315, which might be an RFID (NFC) reader IC, for example, the NXP semiconductors PN7462 family, to provide access technology implementations. Such implementations may read and exchange data with NFC Access Cards like Mifare /Mifare DES and/or exchange information with User Devices (User Equipment) like smartphones and use the smartphone-based NFC technology for access purposes. In some embodiments, a component of the SIID 123 (e.g., included in an IPU) may be configured to correct interference, for example, g-forces, caused by movement, and thereby avoid taking unnecessary action (e.g., waking up from an idle state, as described in more detail elsewhere herein).

In some embodiments, the CPU core 311 may communicate through the connected device interface 308 with connected devices 316. Such a communication may be done via RS485 Modbus and/or RS485 OSDP Protocols with RFID NFC Readers and the readers may communicate with user equipment via RFID NFC interfaces. In particular, such RFID NFC readers may be provided by Deister Electronic GmbH. In such a combination, the RFID NFC technology may be used to grant access to electrical cabinets in which the SIID and/or the ICS devices are installed. In particular such RS485 Modbus may be used to communicate with fans such as devices provided by ebm-papst to climatize electrical cabinets in which the SIID and/or the ICS devices are installed.

Although not illustrated in FIG. 3, the SIID 123 or an IPU therein also may include one or more mobile phone vibrators or the like and microphones, which may be used for detection of damage to a connected device to which the SIID 123 is connected or to the SIID 123 itself, and, in combination with logic (e.g., hardware, firmware and/or software) within the SIID 123, to determine system health of the connected device and/or SIID 123 by analyzing resonances and frequencies of impact sound on the connected device using, for example. Detailed Sampling Mode (DSM) techniques available from MyOmega and the MYNXG® affiliates or any other appropriate technique, including conventional techniques for analyzing resonances and frequencies of impact sound. For example, a microphone may be connected via digita l/a na log M12.8 connectors to the SIID 123 and/or integrated within the SI ID 123 (e.g., within the IPU therein). Sound waves may be caused by acoustic stimulation of the connected device, and DSM techniques may be employed to sample and analyze the sound waves.

Although not illustrated in FIG. 3, the SIID 123 also may include one or more cameras, which may be used to monitor and record the current load or contents of a connected device to which the SIID 123 is connected, where such information may be used by image-processing logic, e.g., within an IPU therein and/or a gateway, server or other elements of a TMN described herein to control the loading or unloading of items onto/from the connected device, and/or the filling or emptying of the connected device. The SIID 123 may include, within an IPU or otherwise, one or more batteries or accumulators, for example, a Lithium ion battery, and/or interfaces thereto and may be energy buffered using, for example, a gold cap capacitor and/or a battery, powered to store status transitions if the supply voltage is off for a time period. The SIID 123 may also include one or more interfaces that enable the battery or accumulator to be charged, and/or other interfaces, for example, one or more interfaces for display devices, e.g., an e-Paper interface.

One or more components of the SIID 123 may be implemented in hardware, firmware, software or a combination thereof, for example, on a printed circuit board (PCB). In such embodiments, the PCB may be affixed to one or more M12.8 connectors, for example, a male and female M12.8 connector. A battery or accumulator of the SIID 123 may be charged via an M12.8 connector, and external components may communicate with components of the SIID 123 via one or more M12.8 connectors as described elsewhere herein. The SIID 123 may include one or more antennas corresponding to the one or more communication technologies that may be included in the SIID 123 as described elsewhere herein. Each antenna may be integrated, if suitable, within a PCB in embodiment including a PCB, for example, in an IPU, or may be physically connected to the PCB and/or a housing thereof. For example, one or more antennas may be implemented as an integrated foil antenna, glued to the PCB or a housing of one or more components of the SIID 123.

Returning to FIG. 2A, connected device information may be communicated between components of the TMN 100, including SIIDs, other ICS devices, monitoring devices, user devices, gateways and components of the cloud 101, in any of a variety of ways. Such techniques may involve the transmission of connected device information in transaction records (e.g., blocks) of a blockchain or the like (e.g., using cryptographic techniques), and/or the storage of such records or information therein as part of blockchains or the like, for example, as part of a transaction register/ledger, as described in more detail elsewhere herein. Such transaction records may include public information and private information, where public information may be made more generally available to parties, and more sensitive information may be treated as private information made available more selectively, for example, only to certain connected device producers, OEMs and/or particular customers. For example, the information in the transaction record may include private data that may be encrypted and/or an SIID and may include public data that is not encrypted. For example, the private data may be encrypted using a private symmetric key or similar of the security module 313 or by a public key of an asymmetric key pair where the private key is provided by the security module 313.

The public data also may be encrypted to protect the value of the data and to enable trading of the data, for example, as part of a smart contract. The distinction between public data and private data may be a matter of degree. For example, both public data and private data may be proprietary to a party, but the private data may be deemed more sensitive, e.g., more of a secret, and thus protected as such. For example, the public data may be basic specifications associated with a connected device or a load or contents thereof, which a party is willing to share with any customer or potential customer, whereas the private data may be data the party is only willing to share with a technology or business partner, for example, for a payment or license fee. Accordingly, public data may not be encrypted at all, enabling any party given access to the transaction record access to the public data, or may be encrypted using a different credential (e.g., key) than the private data, so that a party may be more selective in enabling access to the private data; i.e., only give credentials associated with the private data to parties of certain contracts. Encrypted data, whether public or private, may be accessible only to those parties having a key corresponding to the key used for encryption, for example, the private key itself in a case in which symmetric cryptography is employed, or a corresponding asymmetric key in a case in which asymmetric public key cryptography is employed. In this manner, parties owning information corresponding to a connected device, SI I D or other device may make some portions of the information public and other portions private to only select parties, for example, according to a smart contract, as described in more detail elsewhere herein.

In some embodiments, information may be collected from one or more of the SIIDs 123- 125 over a predetermined period of time and may be grouped into a single secure transaction record. The secure transaction record may be sent from one or more of the gateways 119-121 to a server, possibly residing within the cloud 101. Furthermore, in embodiments in which an SI I D communicates directly with one or more servers in the cloud, the SI I D itself may group information that the SI ID has detected or determined over time about one or more connected devices, and/or received from one or more other devices on an ICS into a single secure transaction record that the SI I D transmits to the server. In some embodiments, user devices may transmit one or more secure transaction records to gateways and/or directly to one or more servers in the cloud.

Each secure transaction record may include a one-way hash of, and a reference (e.g., link or pointer) to an immediately preceding secure transaction record for the overall system (e.g., ICS or other network) for which information is being tracked. A hash of a secure transaction record is an output of a mathematical function, algorithm or transformation (hereinafter "hash function") applied to the secure transaction record. The hash function may be configured to produce a hash value that can be represented by a data structure (e.g., a string) of uniform size or range of sizes. In some embodiments of the system described herein, the hash is a one-way hash in that the hash function that produced the hash value is infeasible to invert (e.g., a cryptographic hash function). By including the one-way hash as part of the next (i.e., current) secure transaction record, it can be determined if an immediately preceding record has been altered by determining if the one-way hash generated from the altered secure transaction matches what is stored in the next transaction in the chain.

Furthermore, in embodiments of the system described herein, each secure transaction record includes a one-way hash of, and a reference (e.g., link or pointer) to an immediately preceding secure transaction record, forming a continuingly growing temporal list of records referred to herein as a record chain (e.g., a blockchain). Altering any secure transaction record in the record chain will have a cascading effect of changing the expected one-way hash of every future secure transaction record, such that the source altered record can be determined. Thus, using a one-way hash function (or mathematical asymmetric hash function) enables, along with other features described herein, reliable tracking of connected device information in a system. Any of a variety of cryptographic one-way hash functions may be used, for example, MD4, MD5, SHA-1, SHA-2 and SHA-256.

In some embodiments, a record chain or audit trail may be implemented using a blockchain, each secure transaction record of the record chain being implemented using a transaction block of the blockchain (also known as a block-chain or block chain). A blockchain is a continuously growing list of records, called blocks, which are linked and secured using cryptography. Each block contains transaction data or information and may contain a hash pointer as a link to a previous block (i.e., an immediately preceding block in the chain), and a time stamp. By design, blockchains are inherently resistant to modification of the data. Blockchains may be considered an open, distributed ledger that can record transactions between two parties efficiently and in a verifiable and permanent way. For use as a distributed ledger, a blockchain may be managed by a peer-to-peer network collectively adhering to a protocol for validating new blocks. Once recorded, the data in any given block cannot be altered retroactively without the alteration of all subsequent blocks, which requires collusion of a network majority. Blockchains are considered secure by design and may be considered an example of a distributed computing system with high Byzantine fault tolerance. Although various embodiments of the system described herein use blockchains, the invention is not so limited. Other appropriate technologies may be employed to record transactions herein or to implement a record chain, where such technologies are inherently resistant to modification of the data and can record data in a verifiable and permanent way that preserves temporal relationships between the data blocks so that, for example, deletion/removal/modification of any block(s) in the chain may be detected. Once the data is recorded in any block, such data cannot be altered retroactively without the alteration of all subsequent blocks in the block-chain.

It may be desirable to engage in commercial transactions involving connected devices, for example, purchases, leases, licenses and other types of transactions, and blockchains may be used as part of contractual transaction between transacting parties. For example, the purchase or lease may include the seller providing the buyer access to and/or control of a transaction register of one or more connected devices, e.g., in the form of a blockchain. Going forward from the time of the transaction, the buyer may continue to add blocks to grow the blockchain, and at later date provide access to or control of the blockchain to a future buyer or other transacting party. In some embodiments, the contractual transaction itself is implemented using blockchains or the like. That is, a blockchain may be used to implement a "smart contract" between parties, for example, by defining the rules (i.e., terms) of the contract (including payment terms, access to information, timing, etc.), enforcing the rules of the contract, and recording the execution of the contract and/or transactions under the contract as transaction blocks of a blockchain. For example, a blockchain may define a license scheme (e.g., one-time fee, installment payments, pay-per-use, etc.) involving a fleet of connected devices or subcomponents (e.g., parts) thereof as described herein, and record transactions under such a contract as transaction blocks of a blockchain. In some cases, the smart contract may define the rules for the exchange of information related to a fleet of connected devices or parts thereof, or a subset thereof.

Such smart contracts may define rules governing the exchange of public and private data/information as described herein and record the results of a transaction in relation to the same. For example, a smart contract may define the rules by which a first party, e.g., a customer, is allowed access to public or private information of an OEM, e.g., the proprietary specification for a connected device, user device, SI I D or combination thereof, in exchange for public or private information of the customer for the connected device, user device, SIID or combination thereof, or perhaps in exchange for currency, e.g., bitcoins, or another asset. Proprietary information may include, for example, internal designs, proprietary interfaces, benchmarking results, other test data, manufacturing reliability data, customer lists, price lists, source code, etc. A smart contract may be defined to provide a party to the contract one or more keys (e.g., a private and/or public encryption keys) or other credential(s) that provides access to encrypted public or private information, for example, in response to a payment made by the party, performance of an action, or in exchange for some other form of consideration. The use of smart contracts may be applied to the management of a connected device lifecycles as described herein and commercial transactions in relation thereto.

Components of the TMN 100 may be configured to reduce (e.g., minimize) the number of communications therebetween, which in some embodiments may include communicating transactions (e.g., connected device status information) to servers within the cloud 101 according to a predefined schedule, in which gateways are allotted slots within a temporal cycle during which to transmit transactions (e.g., report connected device status information) to one or more servers. Each transaction transmitted from a gateway to a server may include connected device information received from one more SI I Ds, user devices and/or other device in one or more communications (e.g., status reports) sent from the SI I Ds and/or user devices since a last such transaction was sent to the server and may in some embodiments include only changes to information since a last transaction. Connected device information may be collected, stored and managed in a computationally efficient and secure manner that ensures the integrity of the connected device to a high degree of certainty.

FIG. 4A is a sequence diagram illustrating a sequence of communications between SI IDs, gateways and a server to efficiently and reliably track device information on a network according to embodiments of the system described herein. Other embodiments of a sequence of communications between SI I Ds, gateways and a network cloud to efficiently and reliably tracking device information on a network, including variations of the sequence shown in the diagram, are possible and are intended to fall within the scope of the invention. The sequence may be implemented using components of the system described herein, including, for example, components of the TMN 100 and a security module. Although the sequence is illustrated with communications between gateways and SI I Ds, it should be appreciated that, in some embodiments, the same or similar communications may be made between one or more user devices and monitoring devices on the one hand (e.g., the user device 142) and a gateway on the other hand. The same or similar communications are also possible between an SI I D and a server.

A communication 324, including public data "1" and private data "(fl)" may be transmitted from SI I D n to Gateway 1, and then a communication 326, including public data "2" and private data "(f2)" may transmitted from SI I D 1 to Gateway 1. At some later point in time, such as during an allotted time slot, Gateway 1 may transmit a transaction transmission request 328, e.g., a Data Heartbeat (Data HB) Request, to the Server. In response, the Server may send a one-way hash 330 of an immediately preceding transaction record, n-1, e.g., from a header of a transaction block n-1, to Gateway 1. Gateway 1 then may send a transaction record 332, e.g., Data HB transaction n, including the public and private information from the communications 324, 326, and the Server may respond with an acknowledgment (ACK) 334. Gateway 2 then may transmit a transaction transmission request 336, e.g., a Data HB Request, to the Server, for example, during an allotted time slot for Gateway 2. In response, the Server may send a oneway hash 338 of an immediately preceding transaction record, n (i.e., the transaction record 332) from a header of a transaction block n, to Gateway 2. Gateway 2 then may send a transaction record 340, e.g., Data HB transaction n+1, including public information "3" and "4" and private information "(f3)" and "(f4)" received, for example, in communications from one or more user devices coupled to Gateway 2, and the Server may respond with an acknowledgment (ACK) 342.

It should be appreciated that the sequence includes two sub-sequences of communications between a gateway and a server including a sequence 327, which includes the four communications 328, 330, 332, 334, and a sequence 335, which includes the four communications 336, 338, 340, 342. Each of the sequences 327, 335 may be considered a streamlined blockchain communication sequence. A streamlined blockchain communication sequence makes efficient use of network resources and may be considered to create a minimum amount of communication overhead necessary to properly implement a transaction chain (e.g., blockchain). In alternative, non-streamlined embodiments, every gateway may receive a blockchain update every time a gateway submits a transaction record to the server. In contrast, using the streamlined blockchain communication sequence, a gateway only receives an update to the blockchain in response to making a data heartbeat request (e.g., the request 328 or the request 336), thus making more efficient use of network resources. Considering that the device information of the transaction record may be transmitted, and an acknowledgement received, in any scheme in which transaction information is recorded, the only additional communication overhead included in a streamlined blockchain communication sequence is the sending of the transaction transmission request, the receipt of the one-way hash of the previous transaction, and the inclusion of the one-way hash of the transaction in the transaction record. That is, for n transactions between gateways and a server of a system, the message overhead (compared to a system not using a transaction chain) is only 2*n messages.

For example, assume a thing management system in which 30 SI I Ds, user devices and/or other devices report transactions through a given gateway. In such an example, twelve bytes of information may be produced per such device, a one-way hash of a transaction may have a length of 256 bits (32 bytes), and a communication header for any transaction communication may have a length of 64 bytes. With these assumptions, the number of bytes consumed for each submission of a transaction record from a gateway, and the communication overhead associated therewith, may be calculated as follows:

Transaction transmission request = communication header = 64 Bytes

Response from server = communication header + one-way hash = 64 + 32 = 96 Bytes

• Transaction record - communication header + one-way hash + device information = 64 + 32 + 12*30 = 456 Bytes.

• ACK message = communication header = 64 Byte.

• Total transaction record bytes = 64 + 96 + 456 +64 = 680 Bytes

• Total transaction record overhead = transaction transmission request + response from server + one-way hash of the transaction record = 192 Bytes, which is approximately 25% of the total transaction record bytes.

The percentage of overhead decreases as a number of SI I Ds, user devices and/or other devices reporting to a gateway increase. For example, if there are 500 such devices, the overhead percentage may be smaller than 3%.

Although the streamlined blockchain communication sequence is described in relation to communications between a gateway and a server, it should be appreciated that the invention is not so limited. The streamlined blockchain communication sequence may be used to communicate transaction records between any two components of a TMN, including any of the components described herein. It should further be appreciated that, in some embodiments, an SI I D, user device and/or other device may communicate directly with a server without use of a gateway, and in such embodiments such a device may communicate information to one or more servers using the streamlined blockchain communication sequence. In some embodiments, an SI I D may initiate a sequence directly with the cloud 101. In such cases, the SI I D may contain one or more security modules such as the security modules described in more detail elsewhere herein. Furthermore, in some embodiments, an SIID itself may serve the role of a gateway in the communication sequence, and one more of the SI I Ds may not be SIIDs, but rather ICS devices (e.g., PLCs) that are not SI I Ds, including ICS controllers and other ICS devices.

FIG. 4B is a block diagram illustrating using a secure transaction record 362, such as a transaction block of a blockchain, to communicate and store connected device-related information on a TMN according to embodiments of the system described herein. Other secure transaction record formats, including variations of the secure transaction record 362, are possible and are intended to fall within the scope of the invention. While the illustrative embodiment of FIG. 4B describes communicating secure transaction records between SI I Ds and gateways, or directly from SI I Ds to servers, it should be appreciated that the invention is not so limited. Secure transaction records, as described in relation to FIG. 4B and elsewhere herein, also may be communicated between user devices or other devices (e.g., the user device 141) and gateways or directly from user devices or other devices (e.g., the user device 140) to a server. Furthermore, such secure transaction records may be transmitted between ICS devices of an ICS, including ICS controllers to an SI I D serving as an interface to one or more components of a TMN, such as a gateway or TMN server.

A plurality of SI IDs 382, 384, 386 may send (e.g., transmit) communications 388, 394, 395, respectively, to a gateway 360 concurrently or at different times, for example, in accordance with a predefined schedule, in response to an event (e.g., a determined change in property and/or state of a connected device) or in response to user input (e.g., a data request). Each of the communications 388, 394, 395 may include public information elements 390, 396, 397, respectively, and private information elements 392, 398, 399, respectively, described in more detail elsewhere herein. It should be appreciated that one or more of the communications received by the gateway 360 may have been transmitted by one or more SI I Ds in accordance with a predefined schedule, in response to an event or in response to user input.

The gateway 360 may generate the secure transaction record 362 and may send the secure transaction record 362 to a server 356 that is possibly in the cloud 101. The secure transaction record 362 may include a transaction header 364 and a transaction body 366. The transaction body 366 may include public information elements 368, 372, 376 corresponding to the public information elements 390, 396, 397, respectively, and private information elements 370, 374, 378 corresponding to the private information elements 392, 398, 399, respectively.

The transaction header 362 may include a one-way hash 350 of an immediately preceding secure transaction record, t_n-i, a reference 355 (e.g., link or pointer) to the immediately preceding secure transaction record, t_n-i, a one-way hash 352 of a current secure transaction record, t_n, and schedule information 354. The one-way hash of t_n-i may have been obtained from the server 356 in response to a request, or, in another embodiment, in an update from the server 356 in response to submission of another secure transaction record to the server 356. In some embodiments, information included in the record transaction body 366 may include only information corresponding to a connected device that has changed since a last transaction. In some embodiments, information unchanged since a last transaction is included in the transaction record body 366, and there is a mechanism for indicating which information has changed. The transmission of secure transaction records from gateways to a server (or directly from an SI I D or other device to a server) may be scheduled using predetermined time slots within a cycle. The transmission schedule may be defined, stored and/or under control of the server to which record transactions are transmitted, and may be implemented using any of a variety of technologies, including a cloud-based scheduler. The schedule information 354 may specify a predetermined time slot within a cycle for transmission of the secure transaction record 362 to one or more servers in the cloud 101.

The secure transaction records transmitted from gateways to servers (e.g., the secure transaction record 362) may be stored on the server as part of a transaction chain for the gateway, i.e., a transaction chain corresponding to a thing management system associated with (i.e., specific to) the gateway. The server also may store the transaction record as part of a transaction chain corresponding to a thing management system at the server/cloud level, for example, for which thing management systems at the gateway level are subsystems. For example, one or more servers in the cloud 101 may store a transaction chain that includes transaction records corresponding to the gateways 119-121, as well as transaction chains corresponding to SI I Ds or other devices directly connected to one or more servers in the cloud 101 or to user devices. While FIG. 4B has been described primarily in relation to communicating information from SI I Ds through gateways to servers in the cloud, it should be appreciated that the invention is not so limited. In some embodiments of the system described herein, an Sil D may collect connected device information over time (e.g., from connected devices coupled thereto and/or other from devices on an ICS) and transmit a secure transaction record like that described herein directly to one or more servers in the cloud without use of a gateway.

FIG. 5 is a block diagram that illustrates in more detail the security module 313 that contains a secure component 418 which could be a TPM. The security module 313 includes a subset of the functions of the SI I D 123, described elsewhere herein. The security module 313 may also be used for a gateway or a user device, according to embodiments of the system described herein. Other security modules, including variations of the security module 313 or the security module 127, are possible and are intended to fall within the scope of the invention. It should be appreciated that the security module 313 may build upon or extend existing security platforms. For example, the security module may be implemented as a trusted compute base of a PLC including all security relevant functions. It is possible that such a security module is a TPM 1.2 or TPM 2.0 within a PLC system.

In another case, the security module 313 may be a subset of a PLC extension implemented with MYNXG® technology, as shown in the SI I D 123 in Fig. 3. It is possible that such a PLC extension that contains the security module 313 and further functionalities of the SI I D 123, as described elsewhere herein, may serve as a security master for systems with older/outdated security technology and/or a PLC system with limited security capabilities acting as a security slave. The security master and slave relation may be established and validated via cryptographic principles such as mutual authentication and/orTLS handshakes.

The security module 313 may include hardware 410, firmware 406, an operating system (OS) 404, certification, integrity and authentication (CIA) logic 416, the secure component 418, a non-volatile memory (NVM) 424, other applications and/or logic 402, other components, or any suitable combination of the foregoing. The security module 313 may implement a root of trust (RoT), serving as a trusted computing base (TCB), including providing hardware and firmware-based security including cryptography for a corresponding device (e.g., SI I D, gateway, user device or monitoring device) in which the RoT is embedded. The security module 313 may provide compute resources that are dedicated exclusively for such security and may be physically secure against access by external components and processes.

In some embodiments, the RoT may be implemented by the security module 313 as follows. The hardware 410 may include hardware boot code 412, such as an Intel Atom-based hardware start-up code and/or boot loaders of ARM CPU families, which, when triggered, may implement a ROM-based boot sequence. The sequence may verify (e.g., using a boot partition key pair) the firmware (FW) boot code 408 (including external firmware interface (EFI) code inside the basic input-out system (BIOS)) of the firmware 406. An initial version of the firmware boot code 408 may be initially provided to the security module 313 and/or the secure component 418 during manufacture within a secure production environment. The initial firmware boot code 408 may ensure that an initial boot of the system is secure. Subsequent versions of the boot code 408 may rely on the initial version as a basis for validation. After being verified as part of implementing the RoT, the FW boot code 408 then may verify software modules within the OS 404, for example, kernel and kernel objects of the OS 404, e.g., a Linux OS, a C/C++ Kernel, a JAVA implementation on top or in combination with a Linux OS, etc. After being verified, the OS 404 may call the secure component 418, which may be (or may include) a TPM and/or an SE. The secure component 418 may be implemented on a single chip using hardware and firmware, and in some cases may include additional software.

The secure component 418 may be configured to validate the CIA logic 416, which may be implemented in software, firmware and/or hardware. In some embodiments, the CIA logic 416 may be, or may include, the MYNXG® Cipher Suite™ made available from MyOmega and/or MYNXG® affiliates. Validating the CIA logic 416 may include use of one or more private credentials, for example, a private communication credential 420 and a private blockchain credential 422, each of which may be a cryptographic key having, for example, a length of 256 bytes, stored within the secure component 418. In an embodiment herein, a private key may be created by and used at the secure credential service 117 and a corresponding public key may be provided in the SI I D 124/123 and used to validate downloaded software. A different private key may be used for the setup of TLS communication and the mutual authentication with the cloud 101. After successful mutual authentication, any software download can take place, hence the existence of the private key is a security condition that is fulfilled before any software download because software is downloaded using TLS communication.

In addition to the private communication credential 420 and private blockchain credential 422, the secure component 418 may include one or more master security credentials 423. Master security credentials are additional keys stored inside the secure component 418 (e.g., a TPM), tamper evident non-volatile memory inside the secure component. The secure component 418 may create a secure ICS credential 431 which may be stored in NVM 424 to provide the secure objects 425 and the secure credential 427. The principle of such objects is that a key is used to encrypt the objects and only the secure component 418 is able to decrypt the objects and to use the objects for communication. The NVM 424 may be any flash memory without any specific security features. Using the NVM 424 may be done to save a high-cost memory and capacity inside the secure component 418.

An additional master security credential may be a private key which is used to generate software verification after each reset using mutual Authentication between the security master implemented with MYNXG® technology and a security slave implemented with existing PLC technology. The security slave PLC may be a legacy PLC and may contain a private key that must be programmed/changed within the legacy PLC. Communication may be provided between a security master and a security slave by using a public key of the master to encrypt data transmitted from the master to the slave and using a public key of the slave to encrypt data transmitted from the slave to the master. Each of the master and slave would have a private key for a corresponding one of the public keys for decrypting and the private keys would not be shared.

In an embodiment herein, the private communication credential 420, the private blockchain credential 422 and the one or more master security credentials 423 are embedded in the secure component 418 at the time of manufacture (i.e., production) and are never transmitted outside of the secure component 418. In some embodiments, one or more of the credentials 420, 422, 423 may be initially generated inside the cloud 101 using, for example, a hardware security module (HSM) in the cloud 101, e.g., an HSM within the secure credential service 117 of the core services layer 110. The private communication credential 420 may be used, for example, by the CIA logic 416 to establish a secure channel for uplink communications, e.g., from an SI I D to a gateway or directly to a cloud server. For example, the private communication credential 420 may be used to establish a TLS communication channel, including initiating a symmetric key exchange (e.g., as part of a TLS handshake) and employing elliptic curve and/or RSA based mutual authentication to facilitate encrypted communication between an SI I D (or another device) and another device.

The private blockchain credential 422 may be used for creating and verifying blockchain hash values, and to implement secure transaction records, for example, as described in more detail elsewhere herein, e.g., in relation to FIG. 2A and FIG 4. The one or more master security credentials 423 may be used to encrypt secure objects 425, such as TPM objects, at the time of manufacture of the SI ID (or other time), and to decrypt as necessary, as described in more detail elsewhere herein. The master security credential(s) 423 may have been generated via random generators and/or hardware inside the secure component 418 during production.

The secure component 418 may be configured to protect against a possibility of reading data therefrom when locked. Such locking may occur as a last step of producing (i.e., manufacturing) the secure component 418, the security module 313 and/or a device (e.g., SI I D) in which the secure component 418 is embedded. The secure component 418 may be certified by the German Bundesamt fur Sicherheit in der Information Technik (BSI) and may provide Common Criteria (CC) Evaluation Assurance Level 5, i.e., CC_EAL5 security or possibly Common Criteria (CC) Evaluation Assurance Level 4+, i.e., CC_EAL4+ security.

Validating the CIA logic 416 also may include utilizing one or more of the secure objects 425, including secure credentials 427 (e.g., secrets) and a secure whitelist 434, which may be stored in encrypted form in the NVM 424, which may be flash memory. Each secure object 425 may be created during production of the security module 313 and/or the secure component 418 and encrypted using one of the one or more master security credentials 423. The secure credentials 427 may include, for example, a secure service provisioning credential 426, a secure validation credential 428, a secure communication credential 430, a secure ICS credential 432, and perhaps other secure credentials 432. The secure validation credential 428 may be created, encrypted and stored within the security module 313 during production, as described in more detail elsewhere herein.

The secure service provisioning credential 426 may be used for service provisioning on a gateway, monitoring device, user device or other device of a TMN. The secure communication credential 430 may be used to establish secure communication channels with other components of a TMN (e.g., a gateway or cloud server), for example, in accordance with TLS. The secure communication credential 430 may be derived from and/or correspond to the private communication credential 420. For example, the secure communication credential 430 may be a symmetric key corresponding to (possibly equal to) the private communication credential 420.

In an embodiment herein, a service layer private key is stored at the secure credential service 117 and a service layer public key (and possibly corresponding certificate) are stored in a component of a TMN (e.g., an MYNXG® Edge or Sense device or SI IC^Z PLC connector provided by MyOmega and the MYNXG® affiliates). The service layer private key and the service layer public key may be used for communication to components of the TMN. A controller private key (e.g., the private communication credential 420) may be stored inside the component of the TMN and a controller public key (and possibly corresponding certificate) may be stored in the cloud 101 (or other communication endpoint). The controller private key (e.g., the private communication credential 420) and the controller public key may be used for communication from components of the TMN. A mutual TLS authentication may take place using the keys to establish a TLS session.

The CIA logic 416, after being validated (e.g., utilizing the implemented RoT based on the production methods (initial boot) and the credentials stored inside the secure component), may use the secure validation credential 428 to validate signatures (or possibly hashes) of one or more software modules on a device (e.g., an SI ID), including, for example, one or more modules of the OS 404 (e.g., a virtual machine (VM) and/or activity manager thereof), the binary code of the CIA logic 416, the binary code of loadable user space modules of the OS 404, the binary code of one or more other applications and/or logic 402, any software modules in the SI I D 123, and other software modules. For example, the secure validation credential 428 may be used to validate a digital signature of one or more of the foregoing software modules. In some instances, a digital signature may be provided by using a private key of a public/private cryptographic key pair where the digital signature may be validated using the secure validation credential 428 (or similar) to confirm a corresponding public key used for validation. In some cases, a digital signature may be provided using a one-way hash and the secure validation credential 428 (or similar) may be used in connection with validating the one-way hash.

The software modules may be signed by private keys within a secure part of the cloud 101, for example, an HSM of the secure credential service 117. The software modules may have been signed using the SVC 119, which may use a credential that together with the secure validation credential 428 constitutes a credential pair (e.g., key pair) of a cryptography scheme. For example, one or more of the software modules may have been produced by MyOmega and/or MYNXG® affiliates and signed according to the MYNXG® Public Key Infrastructure made available by MyOmega, e.g., in a highly secure environment in accordance with an ISO 27.001 and/or ISA /I EC 62443 certified set of rules of the MYNXG® Public Key Infrastructure. The digital signature(s) generated by the producer for one or more software modules may be included in the one or more software modules and accessed by the CIA logic 416 to perform the validation using the secure validation credential 428

The CIA logic 416 also may use the secure validation credential 428 (e.g., as part of implementing an RoT) to determine whether one or more software modules (e.g., any of those described above in relation to verifying signatures) installed on a device (e.g., an SI I D, ICS device, gateway, user device, or monitoring device) are members of a whitelist of software modules (e.g., applications and other types of software modules) that are permitted to be installed on the device. For example, the producer of an SIID or other device may store an encrypted list of permitted software modules, the secure whitelist 434, within the NVM 424. The CIA logic 416 may be configured to determine whether one or more of the software modules on the device are also included on the secure whitelist 434 by decrypting the secure whitelist 434 using the corresponding master security credential 423, and comparing the name (or other identifier, e.g., a hash) of the software module to the decrypted names or other identifiers of the software modules included in the secure whitelist 434. If the software module matches one of the names on the secure whitelist, the software module may be allowed to be installed and/or executed on the device. If the software module does not match any of the names on the whitelist, the software module may not be allowed to be installed and/or executed on the device. Furthermore, an alarm or other notification may be issued, for example, by sending communications to one or more other devices (e.g., user devices) on the TMN 100 and/or aurally, visually or physically on the device itself (e.g., using sound, light, text and/or vibration) or to a connected device attached to the device.

In some embodiments, a secure blacklist (not shown) of software modules that are not permitted to be installed on the device may be included in the secure objects 425. For example, the producer of an SIID or other device may store a digitally signed and/or hashed list of unauthorized software modules within the NVM 424, possibly in encrypted form. The CIA logic 416 may be configured to determine whether any software modules on the device are also included on the blacklist, for example, by decrypting and/or verifying the blacklist using the corresponding master security credential 423 (or similar) and comparing the name (or other identifier) of the software module to the names or other identifiers of the software modules included in the blacklist. If a software module matches one of the names on the blacklist, the software module may not be allowed to be installed and/or executed on the device. Furthermore, an alarm or other notification may be issued, for example, as described in more detail elsewhere herein.

The secure ICS credential 431 may be used to establish a secure communication channel between an SIID and other devices of an ICS, for example, in accordance with a datagram transport layer security (DTLS) protocol, over which RT and IRT data may be securely exchanged in encrypted form. The private shared key (PSK) may be generated as a TPM object and/or generated by the secure credential service 117. It is advantageous to store the PSK securely inside the PLC without public exchange of the PSK. This may be provided by downloading the PSK into the PLC during personalization. In such a case, the HSM will create the PSK.

One or more other secure credentials 432 may be included in the NVM 424 and used as part of validating one or more software modules, establishing secure communications or performing one or more other security-related functions.

In some embodiments, one or more components of the security module 313, for example, the CIA logic 416, the secure component 418 and/or the NVM 424, and/or subcomponents thereof, may be implemented as part of a portable component 414, such as an insertable card, stick, dongle or other relatively small, portable piece of computer hardware connectable to (e.g., a port of) an SI I D, ICS device, user device, gateway or other device of a TMN. Use of the portable component 414 or the like may be desirable on a device, for example, if the device (e.g., PLC) is produced by a different entity (e.g., Siemens, Rockwell Automation, Phoenix Contact, Schneider Electric, ABB) than the entity (e.g., MyOmega and MYNXG® Affiliates) that provides one or more of the secure components described herein.

The portable component 414 may be configured with one or more communication interfaces to enable physical and/or wireless interconnection with a remainder of the security module 313 and a device on which the security module 313 resides, e.g., an SI I D . For example, the portable component 414 may be configured with a USB port and/or NFC, BT, BT LE or other technologies that enable such communications. The portable component 414 may be locally coupled to the device for which the portable component 414 will be used, the device including the remainder of the security module components.

In some embodiments, functionality of the portable component 414 and in particular the secure component 418 may be integrated within one or more devices on a TMN (e.g., the user devices 141, 140) and the functionality described may reside as an integrated part of such devices. The software services provided by the security module 313 then may be implemented as part of the firmware, operating system, application framework and/or application software of the device in which the portable component is connected.

In some embodiments of the system described herein, a data model for managing connected devices in a TMN may be provided. The data model may include a plurality of object types and attribute types that may be used to design and represent objects for managing connected devices in a TMN. An object may be considered an instance of an object type, and may be defined by an ID (e.g., name) and one or more constituent objects and attributes. The constituent objects and attributes enable a user to associate information defined by the objects and attributes to the object of which the objects and attributes are a member. An attribute may be considered an instance of an attribute type, and be defined by an ID (e.g., name) and a value for the attribute type.

FIG. 6A is a block diagram illustrating an example of a data object 502 for managing connected devices in a TMN, according to embodiments of the system described herein. Other data objects (often referred to herein as simply "objects") for managing connected devices in a TMN, including variations of the data object 502, are possible and are intended to fall within the scope of the invention. It should be appreciated that any number of data objects may be defined and used to managing connected devices in a TMN. The data object 502 may include attributes 504, 506, 508, another object 510, and/or one or more additional other objects and/or attributes. The object 510 may include an attribute 512, another object 514, and one or more other objects and/or attributes. Similarly, the object 514 may include attributes 516, 518 and one or more other objects and/or attributes.

It should be appreciated that the various embodiments of a data model described herein, including one or more data objects (e.g., the data object 502 and other objects defined herein) may be shared and used among multiple entities (e.g., companies), as opposed to being exclusive (e.g., proprietary) to a single entity. As described herein, blockchain technology may be used to ensure the integrity of data objects shared among multiple entities. For example, blockchain technology may be used to implement one or more data objects (e.g., for managing connected devices in a TMN) as part of a secure transaction register (e.g., a distributed ledger).

FIG. 6B is a block diagram illustrating an example of a data structure 524 of a data object (e.g., the data object 502) for managing connected devices in a TMN, according to embodiments of the system described herein. Other data structures of a data object for managing connected devices in a TMN, including variations of the data structure 524, are possible and are intended to fall within the scope of the invention.

The data structure 524 may be for an object 522, which may correspond to the object 502. The object 522 may include and be defined by an object ID (e.g., name) 522a and an object type value 522b, which may be a value representing any of the object types described herein. The object 522 may include and be defined by attributes 524, 526, 528, which may correspond to the attributes 504, 506, 508, respectively. The attributes 524, 526, 528 may include and be defined by attribute IDs 524a, 526a, 528a, respectively, and attribute values 524b, 526b, 528b, respectively. The object 522 also may include and be defined by an object 530 (e.g., the object 510), which may be defined by an object ID 530a and an object type value 530b (which may be a value representing any of the object types described herein), an attribute 532 (e.g., the attribute 512), and an object 534 (e.g., the object 514). The attribute 532 may include and be defined by an attribute ID 532a and an attribute value 532b. The object 534 may include and be defined by an object ID 534a and an object type value 534b (which may be a value representing any of the object types described herein), an attribute 536 (e.g., the attribute 516), and an attribute 538 (e.g., the attribute 518). The attribute 536 may include and be defined by an attribute ID 536a and an attribute value 536b, and the attribute 538 may include and be defined by an attribute ID 538a and an attribute value 538b.

Types of objects may include, but are not limited to, a product, a company, a site, a connected device, a system, a rule, a process and a person. In some embodiments, other types of objects may be defined. A product object type represents a product, which may be a physical product (e.g., a package of goods), a virtual product (e.g., software application) or even a service (e.g., delivery service). A company object type may represent a business entity (e.g., a legal entity), which may serve in different roles (e.g., OEM, supplier, consumer, etc.) in different contexts, which may be reflected in values of attributes defined for the company. A site object type may be used to define and represent a physical place defined by a geographical location (i.e., area), for example, a site at which an ICS is deployed. A connected device object type may be used to define and represent any connected device that may be managed by a TMN and/or controlled by an ICS, including any type of connected device described herein. It should be appreciated that a connected device object type may be used to define and represent not only connected devices monitored or controlled by a sensor, monitoring device and/or ICS device (e.g., an SI I D and/or PLC), but also the sensor, monitoring device and/or ICS device itself.

A system object type may be used to define and represent a system with the ability to maintain records such as, for example, a traditional enterprise resource planning (ERP) system to manage financial information and other information of a company, e.g., an ERP system made available from SAP or Oracle, a customer relationship management (CRM) system, e.g., a CRM system made available from salesforce.com, a produce lifecycle management (PLM) system and/or energy management system (EMS) to control production and manufacturing processes, e.g., those made available from Siemens, or any suitable combination of the foregoing. In some embodiments of a data model as described herein, the data model may be configured to enable interfacing with one or more such systems, i.e., to be able to map and exchange objects and/or data thereof between systems.

A rule object type may be used to define and represent a rule, which may define conditions and actions corresponding to the conditions, i.e., actions to take if the conditions are met. Rules may be used to define smart contracts as described herein. A process object type may be used to define and represent a process, for example, a structured and repeatable workflow. A person object type may be used to define and represent a human being. In some embodiments of the system described herein, a data model includes one or more attribute types for defining attributes for an object. Attribute types may include, for example, a group attribute type, a role attribute type, a state attribute type, a safety attribute type, a security attribute type, a quality attribute type, a supply attribute type, a finance attribute type, a technical attribute type, and a basic attribute type. In some embodiments, other attribute types are included.

A relation group attribute type is an attribute linking master data and data structures to each other. For example, a relation could be something like X belongs to Y. Possible relations are: Assignment, Commissioning, Installation, Hierarchy, Classification and Successor. Assignment is a virtual process that assigns a TMN field component such as, for example, a gateway (e.g., an MYNXG® Edge device provided by MyOmega and the MYNXG® affiliates), SI I D, sensor or monitoring device (e.g., an MYNXG® Sense device or MYNXG® SIIC² PLC Connector provided by MyOmega and the MYNXG® affiliates), to something, such as, for example, a customer, partner, user, and/or blockchain. Commissioning is a physical process that links product information, a transportation unit, a TMN field component and customer information and allows the monitoring of supply chain processes. Commissioning does not change elements involved, but instead, combines the elements. Commissioning is a relation that is temporary, for example, a product being filled into a connected device. Installation is a physical process where TMN field components are installed at products/connected devices and where additional products/connected devices are integrated. The involved TMN field components connected devices and/or products may create a new TMN (e.g., loT) subsystem that is further monitored. Hierarchy is a relation where one is part of another; for example, something is packed and is part of loading a product on a pallet. Classification is a relation where connected devices are grouped. For example, a classification might be that particular products are hazardous and belong to a classified group of connected devices, such as, for example, explosive gasses. Successor is a relation where one is replaced by another. For example, all products with product number Y are replaced on a given date by the product with product number Z.

The role attribute type may be used to define a role for a person, including, for example, the capabilities and/or responsibilities of a person for an object. For example, the role attribute may be used to define a role with respect to (i.e., in association with) a particular process at a company site. The state attribute type may be used to define a state attributes for an object to manage connected devices in a TMN. The safety attribute type may be used to define one or more safety attributes for an object to manage connected devices in a TMN. The security attribute type may be used to define one or more security attributes for an object to manage connected devices in a TMN. For example, the security attribute may be used to specify confidentiality, integrity and availability (CIA) attributes for such objects.

The quality attribute type may be used to define one or more quality attributes for an object to manage connected devices in a TMN. For example, the quality attribute type may be used to specify attributes of products and processes. The supply attribute type may be used to define one or more supply attributes for an object (e.g., a good) to manage connected devices in a TMN. The supply attribute may be particularly useful in managing a supply chain. The finance attribute type may be used to define one or more finance attributes for an object to manage connected devices in a TMN. For example, finance attributes may include any attributes having to do with finance or trade. The technical attribute type may be used to define one or more technical attributes for an object to manage connected devices in a TMN. For example, technical attributes may include a private email address or phone number of a person. The basic attribute type may be used to define one or more basic attributes for an object to manage connected devices in a TMN. Basic attributes may include, for example, basic biographical information about a person, e.g., name, address, city, state, ZIP code.

A plurality of different complex data objects may be defined using various combinations of the object types and attribute types described herein, which then may be used by one or more components of a TMN to manage connected devices, as described in more detail elsewhere herein. For example, as an illustrative embodiment, a person object (i.e., an instance of a person object type) may be defined for a TMN using one or more different attribute types and/or object types as follows:

• One or more basic attributes may be defined, including, for example: first name; given (i.e., family) name, address information (e.g., ZIP code, city/town, street name, street number);

• One or more technical attributes may be defined, including, for example, personal (i.e., private) email address(es), business (i.e., company) email address(es); personal cell phone number; and business cell phone number.

• One or more role attributes may be defined, including, for example: o Employer (e.g., company, government organization, education institution or individual) of the person, o Position (e.g., rank) within employer, o Competencies, e.g., for what processes or connected devices the person has competencies, o User access rights to information and/or processes within a TMN, e.g., as an MYNXG® user within am MYNXG® network made available by MyOmega or MYNXG® affiliates

• One or more security attributes may be defined for the person, for example: o a user password to gain access (which may be stored in encrypted mode) or might be provided by a user authentications service or software e.g., OAuth 2.0 which would provide tokens to grant access, o subscriber identity module (SIM) data and identifier, which may be used as attributes for other objects to associate the person with the other objects,

• One or more safety attributes may be defined for the person, for example: o an IMEI of a cell phone of the person; classifying the cell phone for usage in hazardous areas e.g., according to NEC 500 /505 or ATEX classifications.

• One or more site objects, and process objects for each site object, may be defined for a person.

As another illustrative embodiment, a company object (i.e., an instance of a company object type) may be defined for a TMN using one or more different attribute types and/or object types as follows:

One or more basic attributes may be defined including, for example, the country in which the company is incorporated.

• One or more finance attributes may be defined including, for example, a governmental (e.g., trade) registration number, or a tax ID (e.g., a VAT number).

• One or more site objects may be defined for sites of the company, where each site object may have one or more attributes defined including, for example: o One or more basic attributes, for example, site address information, e.g., ZIP code, town/city, street name, street number; and o One or more technical attributes, for example, GPS coordinates of the site, site maps, installation blueprints; WIFI networks on site, cells of wireless phone networks covering at least part of the site.

As another illustrative embodiment, a process object (i.e., an instance of a process object type) may be defined for a TMN using one or more different attribute types and/or object types as follows:

• One or more safety attributes specifying, for example, a safety classification of a process, e.g., for hazardous environments, which could be used, for example, in defining a rule object.

• One or more product objects specifying one or more products involved in the process, each of the one or more product objects including, for example: o One or more basic attributes including, for example, a unique product ID, e.g., according to the GS1 product naming conventions as specified as of the date of filing at https://www.gsl.org/ and/or in related documents. o One or more quality attributes, e.g., specifying values for one or more quality metrics of the product.

• One or more connected device objects specifying one or more connected devices involved in the process, each connected device object including, for example, one or more technical attributes, e.g., a unique ID of the connected device within the TMN, a product ID and/or serial number.

• One or more rule objects specifying one or more rules (e.g., conditions plus actions) for the process .

• One or more role attributes specifying one or more roles, including for example, the competences needed to execute the process (e.g., through competence profiles, the requirements of person may be specified.

A variety of different objects may be defined, including any of those depicted in relation to FIGs. 7A-7H. FIGs. 7A-7H illustrate examples of data objects, according to embodiments of the system described herein. Accordingly, the discussion of objects herein, including test, arrangement, manipulation, etc. generally refers to the objects illustrated in FIGs. 7A-7H and the corresponding discussion.

FIG. 7A illustrates a product object 603, for a product offered by a company represented by company object 602, the product being defined to have attributes 604.

FIG. 7B illustrates a person object 613 for a person associated with a company represented by a company object 612, and a process object 615 for a process for which the person has competencies at a site represented by a site object 614, the site associated with the company represented by the company object 612. The process object 615 has multiple attributes 616, including a role that may specify competencies of the person with respect to the process.

FIG. 7C illustrates an example of a person object 622 having basic and technical attributes 624. In some embodiments of the system described herein, the person object 622 has a minimum of attributes that may be required to be defined for a person object to be able to be used in a TMN, such as the TMN 100.

FIG. 7D illustrates an example of a company object 632 with attributes 634, including a role attribute indicating that the company represented by the company is a customer. A site object 633 defines a site associated with the company represented by the company object 632. The site object 633 includes basic and technical attributes 635. In some embodiments of the system described herein, the site object 633 has a minimum of attributes that may be required to be defined to be able to be used in a TMN, such as the TMN 100).

FIG. 7E illustrates an example of a person object 663, including an associated site object 665 having an associated process object 666. A plurality of attributes 664, 668 are defined for the person object 663. Some of the attributes 664 are for data related to the GPRS (General Data Protection Regulation) being adopted by European countries. The person object 663 may also be associated with a connected device object 667 having attributes 669 corresponding to mobile related data. In some embodiments of the system described herein, the objects and attributes illustrated for the person object 663 in FIG. 7E represent a minimum of object and attributes that are required to be defined for a person object to be able to be used to provide a threshold level of access control and security for a site on a TMN, such as the TMN 100.

FIG. 7F illustrates an example of a company object 642 representing a company A. The company object has a plurality of associated objects 644 including a site object and a relation process A and a relation process B, which indicate that Process A and Process B are carried out by the company. Process B is shown as having associated objects 646 including a product, a connected device, and a rule. The rule object has associated objects 648 corresponding to different required states and a required competency (role) of a person carrying out the process.

FIG. 7G illustrates an example of a person object 652 having associated object 654 corresponding to roles (competencies) of the person object 652. There may also be other objects 656 associated with the person object 652 including an associated site and an associated process.

FIG. 7H illustrates relation hierarchy and relationship assignments for a company object 662. The company has a corresponding object 664 for a site of the company and a corresponding object 666 for a particular process performed by the company at the particular site. Another object 668 for a person includes a plurality of associated objects for the person including name, address, etc. as well as various roles for the person and data for the mobile phone of the person. There are various relationships between the objects 664, 666, 668. For instance, there is a hierarchical relationship between the object 664 corresponding to the site and the object 666 corresponding to the process; the process is performed at the site. Also, there is an assignment relation between the object 664 corresponding to the site and the object 668 corresponding to the person; the person is assigned (allowed to) work at the site (or not). Similarly, there is an assignment relation between the object 666 corresponding to the process and the object 668 corresponding to the person; the person is assigned (allowed to) work with the process (or not).

As illustrated in FIG. 7H, the process represented by process object 666 is a CNC milling process involving an ICS that includes a controller SI I D, namely the MYNXG® IO Controller, represented by a product object 670; and two other SI I Ds, namely, the PROFINET IO devices represented by connected device objects 672, 674 (labeled "Thing" in FIG. 7H). The SI I D represented by the connected device object 672 includes a control module represented by a connected device object 673 (labeled "Thing" in FIG. 7H). The SIID represented by the connected device object 674 includes and/or is directly connected to an EH FMR sensor for a tank, which is represented by a connected device object 676 (labeled "Thing" in FIG. 7H). The EH FMR sensor is connected to, and may monitor and control, an IBC tank represented by a product object 678. The IBC tank may hold a cooling liquid for milling, represented by a product object 680.

As is described in more detail elsewhere herein, one or more applications or logic executing on one or more of the components of a TMN, such as the TMN 100, which may be provided by one or more applications and/or services in a TMN cloud (e.g., the transformation layer 102 on the TMN cloud 101), may use data objects created using the object types and/or attribute types of the data model described herein. For example, such data objects and one or more components of the security module 313, executing on an SI ID, user device, gateway, server and/or other device, may be used to manage, possibly remotely, one or more aspects of an ICS, including, for example, monitoring and controlling connected devices, managing communication flow between ICS devices and a TM cloud and between ICS devices themselves, for example, in accordance with SI I D management applications 107, ICS management applications 108 and other business processes and workflow applications defined in the transformation layer 102.

It should be appreciated that the data objects described herein may be created once and reused (and modified) by multiple different organizations (e.g., companies or other business entities, government organizations and educational organizations), for example different organizations controlling an OMN, TMN and/or ICS, of different organization on whose behalf such OMNs, TMNs and/or ICSs are provided. Such data objects may be communicated or shared between organizations through the use of blockchain technology as described herein, where such communication may be performed reliably and efficiently, for example, by employing the streamlined blockchain communication sequence as described herein.

FIG. 8 is a flowchart 800 illustrating configuring an ICS device for secure operation, according to embodiments of the system described herein. Other mechanisms for configuring an ICS device for secure operation, including variations of the processing illustrated by the flowchart 800, are possible and are intended to fall within the scope of the invention. The processing illustrated by the flowchart 800 may be performed during production (e.g., manufacturing) of the ICS device.

Processing begins at a step 802 where a private communication credential, such as the private communication credential 420 described elsewhere herein (controller private key), may be generated and stored within a secure component of an ICS device, such as the secure component 418 (e.g., a TPM) of the security module 313 of the Sil D 123. Following the step 802 is a step 804 where a private blockchain credential such as the private blockchain credential 422 described elsewhere herein, may be generated and stored within the secure component of the ICS device.

Following the step 804 is a step 806 where a private validation credential, such as the SVC 119 described elsewhere herein, may be generated, for example, by the secure credential service 117. Following the step 806 is a step 808 where the private validation credential is stored on a TMN cloud, such as the cloud 101, described elsewhere herein. Following the step 808 is a step 810 where a public validation credential may be derived from and/or generated based on the private validation credential. For example, the private validation credential may be a private key and the public validation credential may be a corresponding public key of an asymmetric cryptography scheme used in connection with a PKI.

Following the step 810 is a step 812 where an ICS communication credential may be generated, which may be used to establish a secure communication channel between an SI I D and other devices of an ICS, for example, in accordance with a datagram transport layer security (DTLS) protocol, as described in more detail elsewhere herein. Following the step 812 is a step 813 where a service provisioning credential may be generated, which may be used by gateways and other devices to securely deploy services, as described in more detail elsewhere herein. Following the step 813 is a step 814 where a whitelist and/or blacklist of software modules may be generated. The whitelist may be a list of software modules permitted to be executed on the ICS device, and the blacklist may be a list of software modules not permitted to be executed on the ICS device, as described in more detail elsewhere herein.

Following the step 814 is a step 816 where a communication credential may be obtained that corresponds to the private communication credential. For example, the communication credentials may be symmetric keys of a symmetric cryptography scheme and/or may use a symmetric/asymmetric key pair. Complementary for private shared key (PSK) based communication schemes a secure key for symmetric cryptography may be generated according to pre-defined schemes. Following the step 816 is a step 818 where one or more master security credentials, such as the master security credentials 423 discussed elsewhere herein, may be generated within the secure area of the ICS device, for example, using a random number generator and/or hardware inside of the secure area. Following the step 818 is a step 820 where the master security credential(s) may be used to create secure objects to be used to securely: deploy and execute software on the ICS device, communicate information to and from the ICS device, and store information on the ICS device. For example, the one or more master security credentials 423 may be used to encrypt and/or digitally sign and/or hash the service provisioning credential, public validation credential, communication credential and ICS communication credential and may produce the secure service provisioning credential 426, the secure the validation credential 428, the secure communication credential 430 and the secure ICS credential 431. Furthermore, the one or more master security credentials 423 may be used to encrypt and/or digitally sign and/or hash the generated whitelist to produce the secure whitelist 434 and a secure blacklist.

Following the step 820 is a step 822 where the secure objects may be stored on an ICS device, and may also be stored outside of a secure component. For example, the secure objects 425 may be stored in the NVM 424 of the security module 313 of the SI ID 123. Following the step 822 is a step 824 where the secure component of the ICS device may be locked so that the contents of the secure component, including, for example, the private communication credential, private blockchain credential and master security credential, are made unreadable outside of the secure component. Following the step 824 is a step 826 where the ICS device may be deployed, for example, to the ICS 134. Locking the secure area before deployment may prevent an entity, such as a malicious entity but also including, for example, an owner of the ICS device, from ascertaining contents of the secure area, including the aforementioned credentials, after deployment. While the secure objects on the ICS device, including the secure credentials and the encrypted/signed/hashed whitelist and/or blacklist, may be accessed and read, this may only be done by decrypting encrypted objects using the respective master security credential(s), which cannot be read but may be applied within the secure area to perform the decryption.

FIG. 9A is a flowchart 951 illustrating securely installing a software component on an ICS device, according to embodiments of the system described herein. Other mechanisms of securely installing a software component on an ICS device, including variations of what is illustrated by the flowchart 951, are possible and are intended to fall within the scope of the invention. The processing illustrated by the flowchart 951 may be performed after the ICS device is installed on an ICS, but prior to installing the software component on the ICS device.

Processing begins at a step 952 where a software component (e.g., as part of an installation package) may be accessed on the ICS device (e.g., the SIID 123), where the software component may be provided with a digital signature and/or hash value by, for example, appending the digital signature and/or hash value. The software component may have been provided on the ICS device when the ICS device was installed or may have been communicated (e.g., downloaded) to the ICS device, for example, in a secure fashion using any of the secure communication mechanisms described herein. Following the step 952 is a step 954 where a secure validation credential may be accessed on the ICS device. For example, the secure validation credential 428, described elsewhere herein, may be accessed from the NVM 424. The secure validation credential may be in an encrypted form and/or may be provided with a mechanism for verifying the validity/authenticity of the secure validation credential. Following the step 954 is a step 956 where a private credential may be applied within a secure area on the ICS device to decrypt and/or authenticate the secure validation credential. For example, the master security credential 423 may be applied within the secure component 418 to decrypt the secure validation credential 428. Alternatively, the master security credential 423 may be used to authenticate the secure validation credential 428.

Following the step 956 is a step 958 where the secure validation credential may be used to determine if the digital signature and/or hash value provided with the software is valid using any of a variety of known techniques. For example, the digital signature may be a portion of the software component (or another character string) that was derived using a private key (e.g., the SVC 119) of an asymmetric key pair to construct a digital signature based on the contents of the software. The validation credential may be the public key of the asymmetric key pair and may be used to verify the digital signature. In case that a public key of the asymmetric key pair is utilized, it may be that the validity of the certificate to be applied must be checked by the ICS device software via verification of a root case certificate that defines a lifetime validity of the asymmetric key pair. If the digital signature is valid, processing may proceed to a step 960 where the software component may be installed on the ICS device. Otherwise, if it is determined in the step 958 that the digital signature in not valid, then processing proceeds to a step 962 where the software component may not be installed, and one or more entities affiliated with the ICS and/or TMN may be notified.

FIG. 9B is a flowchart 971 illustrating securely executing a software module on an ICS device, according to embodiments of the system described herein. Other methods of securely executing a software module on an ICS device, including variations of the processing illustrated by the flowchart 971, are possible and are intended to fall within the scope of the invention. The processing illustrated by the flowchart 971 may be performed after the software component has been installed on the ICS device, but prior to executing the software component on the ICS device. In some embodiments, even though the software component may have been validated when installed, the processing illustrated by the flowchart 971 may be performed to ensure that the software component has not been tampered with since installation.

Processing for the flowchart 971 begins at a step 972 where an instruction may be received to execute a software component on the ICS device, for example, in response to an event (e.g., user input) or at a preschedule time (e.g., periodically) or possibly when the ICS is first powered on or reset. The software component may have a digital signature and/or a hash value associated therewith to verify the software component. Following the step 972 is a step 974 where a secure validation credential may be accessed on the ICS device. For example, the secure validation credential 428 may be accessed from the NVM 424. The secure validation credential may be in encrypted form. Following the step 974 is a step 976 where a private credential may be applied within a secure area on the ICS device to decrypt and/or authenticate the secure validation credential. For example, the master security credential 423 may be applied within the secure component 418 described elsewhere herein, to decrypt and/or authenticate the secure validation credential 428.

Following the step 976 is a step 978 where the secure validation credential may be used to determine if the digital signature and/or hash value for the software is valid using any of a variety of known techniques. For example, the digital signature may be a portion of the software component (or another character string) that was derived using a private key (e.g., the SVC 119) of an asymmetric key pair to construct a digital signature based on the contents of the software. The secure validation credential 428 may be the public key of the asymmetric key pair and may be used to validate the digital signature. In case that a public key of the asymmetric key pair is utilized, it may be that the validity of the certificate to be applied must be checked by the ICS device software via verification of a root case certificate that defines a lifetime validity of the asymmetric key pair. If it is determined at the step 978 that the digital signature is valid, then control transfers to a step 980, which causes (allows) the software component to be executed on the ICS device. Otherwise, if it is determined at the step 978 that the digital signature in not valid, then processing proceeds to a step 982, where the software component is prevented from being executed, and one or more entities affiliated with the ICS and/or TMN may be notified.

FIG. 10A is a flowchart 1000 illustrating securely communicating information between an ICS and a cloud on a thing management network, according to embodiments of the system described herein. Other methods of securely communicating information between an ICS and a cloud on a thing management network, including variations of the processing illustrated by the flowchart 1000, are possible and are intended to fall within the scope of the invention. The processing illustrated by the flowchart 1000 may be implemented for a controller SI I D that, in addition to serving as an interface to a TMN gateway or cloud server, also serves as an ICS controller. See, for example, the SIID 124 of the ICS 134 shown in FIG. 2C and FIG. 2D. Variations of processing illustrated by the flowchart 1000 may be performed by an SIID that does not serve as an ICS controller, for example, the SI ID 123 of the ICS 133, illustrated in FIG.

2B.

Processing begins at a step 1002 where a communication channel may be initiated between a controller SI I D and an ICS device of an ICS-cloud network (ICN), described elsewhere herein. The communication channel may be initiated in response to an event such as a request received from an ICS supervisor to read data from the ICS device, or by detecting a value of a property of a connected device by the ICS device. For example, the ICS device may initiate the communication channel to communicate a PROFINET alarm. The communication channel also may be initiated in response to a scheduled communication, for example, in accordance with a communication cycle. A communication resulting from such a schedule may be considered a cyclic communication, whereas a communication resulting from an event (e.g., a PROFINET alarm) may be considered an acyclic communication.

Following the step 1002 is a step 1004 where it is determined whether the ICS device is an SI I D, in which case the SI I D may have a secure ICS credential (e.g., an encrypted PSK) to enable establishment of a secure communication channel. Even in cases in which an ICS device is an SI I D, the ICS device may not be configured for communication. In such a configuration, the SI I D may communicate information to other TMN components through a controller SI I D . It should be appreciated that, even if an ICS device is not an SI I D, the ICS device still may be configured with the capability (e.g., with a PSK and necessary logic) to establish a secure communication channel with another ICS device.

If it is determined that the ICS device is an SIID, or that the ICS device otherwise has the capability to establish a secure communication channel, then processing proceeds to a step 1006 where the communication channel may be configured as a secure communication channel. For example, the secure ICS credentials (e.g., a shared private secret) of a controller SIID and another SIID may be used to establish a DTLS communication channel between the two SI I Ds. If it is determined that the ICS device is not an SIID, or that the ICS device does not have the capability to establish a secure communication channel, then it may be concluded that the ICS device is not capable of establishing a secure communication channel (even though the controller SI I D is so capable), and control transfers from the step 1004 to a step 1008. The step 1008 also may be reached directly from the step 1006.

At the step 1008, the controller SI I D may receive information from the ICS device, for example, over a communication channel (secure or not secure). Depending on the system being controlled by the ICS and the desired or needed performance of the system, and on the nature and purpose of the information being received in the step 1008, the information may be received as part of an NRT, RT or IRT communication and the communication channel established in steps 1002, 1004, 1006 may be configured for NRT, IRT and/or IRT communications.

In some embodiments, the ICS device may be configured to encrypt at least portions of the information that the ICS device sends to the controller SIID. For example, the ICS device may be configured to send, and thus the controller SIID may receive in the step 1008, the public information element 390 and the private information element 392, as described in more detail elsewhere herein. That is, ICS devices may be configured to send communications similar to or the same as the communications 388, 394, 395, described in more detail elsewhere herein, to the controller SIID.

The steps 1002, 1004, 1006, 1008 may be performed in response to an event (e.g., user input) or at a prescheduled time (e.g., periodically). Furthermore, the steps 1002, 1004, 1006, 1008 may be performed multiple times prior to performance of a next step 1010, where the controller SIID may send information to an ICS supervisor, for example, in response to an instruction from the ICS supervisor or at a prescheduled time. The information sent to the ICS supervisor may include all of the information that the SIID has received from the ICS device since the SIID last sent information to the ICS supervisor, or the information may include a predefined subset of such information, for example, in accordance with one or more ICS and/or SCADA protocols as described herein. It should be appreciated that the steps 1002, 1004, 1006, 1008 may be performed between the controller SIID and multiple ICS devices, and the information sent to the ICS supervisor in the step 1010 may be an aggregation of information received by the ICS supervisor or a subset thereof, for example, in accordance with one or more ICS and/or SCADA protocols. In some embodiments, the step 1008 may be performed multiple times for a single performance of the steps 1002, 1004, 1006. For example, after a communication channel is established, there may be several communications received by the controller SI I D from the ICS device while the communication channel remains active (i.e., before it is terminated).

In some embodiments, an SI I D serving as interface to a TMN gateway or server is not an ICS controller because the ICS controller is another device on the ICN, as illustrated in FIG. 2A. In such embodiments, the ICS devices may be instructed by the ICS controller (or another entity) to send information to the ICS controller. In such embodiments, the SI I D may be configured to monitor the information and receive the information from the ICS devices and/or the ICS controller, but not to control the ICS devices or ICS controller. In such embodiments, the step 1010 would not be performed by the SI I D, but rather by the ICS controller.

FIG. 10B is a flowchart 1000' illustrating a different embodiment of securely communicating information between an ICS and a cloud on a thing management network. The steps 1002, 1004, 1006, 1008 are described above and correspond to the steps 1002, 1004, 1006, 1008 in the flowchart 1000, described above in connection with FIG. 10A. In the flowchart 1000', following the step 1008 is a step 1012 where the SI I D may create a transaction record from the information that the SI I D has received from one or more ICS devices, e.g., since the last time the SI I D created a transaction record. For example, the SI I D may create a secure transaction record as described in more detail elsewhere herein, such as the transaction record 362.

Following the step 1012 is a step 1013 where a secure communication channel may be established between the SI I D and a gateway or cloud server of a TMN. For example, the SI I D may use the private communication credential 420, described elsewhere herein, to establish a TLS communication channel with a gateway or server. In some embodiments, a secure communication channel already may have been established between the SI I D and gateway or server, which remains active, in which case the step 1013 may not be performed. Following the step 1013 is a step 1014 where the SI I D may securely send the transaction record to a gateway or a server over the secure communication channel, such as a TLS communication channel.

It should be appreciated that, in some embodiments, the SI I D may not create a transaction record in the step 1012 that is similar to or the same as transaction record 362. That is, rather than aggregating information received from devices into a transaction record, the SI I D may simply pass along (i.e., forward) the information the SI I D receives from ICS devices to a gateway or server (which then may aggregate as described), for example, over the secure communication channel established in the step 1013. In such embodiments, if the information received from the ICS devices is not encrypted, the SI I D may encrypt the information, or portions thereof, and may forward along to a gateway both encrypted and non-encrypted information, for example, as the public information element 390 and the private information element 392, described in more detail elsewhere herein.

Following the step 1014 is a step 1016 where the secure communication channel between the SI ID and the server or gateway may be terminated. Furthermore, although not illustrated in FIG. 10B, at some point, the communication channel(s) between the controller SI I D (or non-SIID controller) and the ICS device(s) may be terminated, for example, after a last performance of the step 1008 for a given communication cycle.

Before, after, or concurrently to performance of the step 1016, it may be determined whether the transaction record is valid in a step 1015 using, for example, the security service 113, discussed elsewhere herein. For example, the security service 113 may apply a blockchain certification credential corresponding to a private blockchain credential of the SIID that created the transaction record to validate that the transaction record was indeed generated by the purported SIID. If the transaction is determined to be valid, control transfers from the step 1015 to a step 1017 where the transaction is stored. For example, the transaction record may be made part of a blockchain transaction register, e.g., a distributed ledger specific to the ICS. If it is determined at the step 1015 that the transaction record is not valid, then control transfers from the step 1015 to a step 1019 where the record is not stored and one or more entities affiliated with the ICS and/or TMN may be notified.

FIG. 11 is a timing diagram illustrating a sequence of communications 901 involving an ICS on a TMN, according to embodiments of the system described herein. Other sequences of communications involving an ICS on a TMN, including variations of sequence of communications 901, are possible and are intended to fall within the scope of the invention. In the embodiment of FIG. 11, the system components may correspond to a system similar to the system reflected in FIG. 2C, in which at least portions of an ICS are part of a TMN, an SI I D 906 is a controller SIID of an ICS, and an ICS supervisor is part of an OMN and not part of the TMN. It should be appreciated that in other embodiments, another ICS device may serve the role of ICS controller and the ICS supervisor may be part of the TMN, for example, as part of a gateway of the TMN.

The communications may include NRT transactions, including an NRT transaction 914, and RT transactions, including two RT transactions 924, 934, where the RT transaction 934 may be a secure transaction from end to end, and where the RT transaction 924 may not be a secure transaction from end to end, as is described in more detail below. The NRT transaction 914 may include multiple communications configured in accordance with an ICS protocol, for example, PROFINET. The NRT transaction 914 may use an ICS supervisor 904 to send a data request 916 (e.g., a Read IO Data Object instruction) to a controller SIID 906, which may instruct an SIID 910 to read data. In the embodiment illustrated in FIG. 11, the SIID 906 is a controller SIID; however, it should be appreciated that, in other embodiments, communications with an ICS supervisor 905 (e.g., as part of the NRT transaction 914) may be handled by another ICS device configured as an ICS controller.

In response to receiving the data request 916, the controller SIID 906 may send a data request 918 (e.g., a Read IO Data Object instruction) to the SIID 910. The SIID 910 may be configured to send, in response to the data request 918, data 920 to the controller SIID 906, where the data may include latest values of a predefined set of properties of one of more connected devices directly coupled to and controlled by the SI I D 910. The controller SI ID 906 then may send data 922, including at least the information provided in the data 920, to the ICS supervisor. In some embodiments, the data 920 transmitted from the SI I D 910 to the controller SI I D 906 may be formatted the same as, or similar to, one of the communications 388, 394, 395, and may include the public information elements 390, 396, 397, respectively, and the private information elements 392, 398, 399, respectively, described in more detail elsewhere herein.

In some embodiments, even though the controller SI ID 906 and the SI I D 910 are capable of establishing secure communication channels, the controller SI I D 906 and the SI I D 910 do not do so for the NRT transaction 914, for example, in accordance with an ICS protocol. In other embodiments, the controller SI I D 906 and the SI I D 910 may establish a secure communication channel over which the controller SI I D 906 and the SI I D 910 exchange the data request 918 and the data 920. Furthermore, in an embodiment in which the ICS supervisor is implemented as part of a TMN component, e.g., a gateway, or is otherwise configured to exchange secure communications, the controller SI I D 906 and the ICS supervisor 904 may establish a secure communication channel over which the controller SI I D 906 and the ICS supervisor 904 exchange the data request 916 and the data 922. The RT transaction 924 may include multiple communications. A communication channel may be established (or may already exist) between the ICS device 912 and the controller SI I D 906. If the ICS device 912 does not have the capability to establish a secure communication channel, because the ICS device 912 is not an SI I D, then the established communication channel may not be secure. The ICS device 912 may send information 926 to the controller SI I D 906 over the channel. The information 926 may be information sent according to a predefined schedule, or may be the result of an event, for example, the occurrence of a condition for a connected device, e.g., detection of a property value above or below a threshold, or the detection of the existence of a property value at all. For example, the information may be sent as part of an Alarm in accordance with PROFINET.

Alarms may be caused by a change of state of a channel and/or when a channel is disconnected. An alarm may be issued when diagnostic data is first created and/or when a last diagnostic data entry is released. An alarm may also signal when a module or submodule is plugged or pulled, when the wrong module or submodule is plugged, when a process limit is reached or for other possible events, such as when an alarm condition is cleared. In some embodiments, the communication including the information 926 transmitted from the ICS device 912 to the controller SI I D 906 may be formatted the same as, or similar to, one of communications 388, 394, 395, and include the public information elements 390, 396, 397, respectively, and the private information elements 392, 398, 399, respectively, described in more detail elsewhere herein.

In response to the information 926 being received (e.g., if the information is received in response to an Alarm or other event), or at a predetermined time, the controller SI I D 906 may engage in a transaction 928 to establish a communication channel with a TMN cloud server 902. For example, the transaction 928 may include the controller SI I D 906 using the private communication credential 420 to establish a TLS communication channel with the TMN cloud server 902, e.g., engaging in a TLS handshake using known techniques. Concurrently to (or after) the transaction 928, the ICS device 912 may send additional information 930 to the controller SI I D 906, for example, an indication that a condition no longer exists, e.g., an Alarm release message in accordance with PROFINET. Once a TLS connection is established, any activity which is selected may initiate a communication using the TLS connection.

After the secure communication channel has been established by the transaction 928, the controller SI I D 906 may engage in a secure transaction communication sequence 932 in order to transmit information to the TMN cloud server 902 that has been received at the controller SI I D 906 since the last time the controller SIID 906 transmitted information to the TMN cloud server 902 (e.g., the information 926, 930). For example, the sequence 932 may include using the private blockchain credential 422 to implement a streamlined blockchain communication sequence, as described in more detail elsewhere herein, with the TMN cloud server 902.

The RT transaction 934 also may include multiple communications. A communication channel may be established (or may already exist) between the SI I D 910 and the controller SI I D 906. A secure communication channel may be established between the SI I D 910 and the controller SI I D 906, for example, in accordance with DTLS. The secure communication channel may be established using the secure ICS credential 431 (e.g., an encrypted shared secret) on each of the controller SI I D 906 and the SI I D 910. The SI ID 910 may send the information 936 to the controller SI I D 906 over the channel. The information 936 may be information sent according to a predefined schedule, or may be the result of an event, for example, the occurrence of a condition for a connected device, e.g., detection of a property value above or below a threshold, or the detection of the existence of a property value at all. For example, the information may be sent as part of an Alarm in accordance with PROFINET. In some embodiments, the communication including the information 936 transmitted from the SI I D 910 to the controller SI I D 906 may be formatted the same as, or similar to, one of the communications 388, 394, 395, and include the public information elements 390, 396, 397, respectively, and the private information elements 392, 398, 399, respectively, described in more detail elsewhere herein.

For the RT transaction 934, the secure communication channel established in the transaction 928 may still be active. The controller SI I D 906 may engage in a secure transaction communication sequence 940 over the secure communication channel in order to transmit information to the TMN cloud server 902 that has been received at the controller SI I D 906 since the last time the controller SIID 906 transmitted information to the cloud server 902 (e.g., the information 936, 938). For example, the sequence 932 may include using the private blockchain credential 422 to implement a streamlined blockchain communication sequence, as described in more detail elsewhere herein, with the TM cloud server 902. At a sequence 942, the secure communication channel between the controller SIID 906 and the TMN cloud server 902 may be terminated.

FIG. 12 is a flowchart 1200 illustrating a method of an ICS device communicating information, according to embodiments of the system described herein. Other methods of an ICS device communicating information, including variations of the processing illustrated by the flowchart 1200, are possible and are intended to fall within the scope of the invention. The processing illustrated by the flowchart 1200 may be performed on an ICS (e.g., the ICS 133 or the ICS 134) for which at least a portion of the ICS is part of a TMN, such as the TMN 100' or the TMN 100", and connected thereto by an SIID, and at least a portion of the ICS is part of an OMN including components, such as the ICS supervisor 202, that are not part of the TMN.

Processing begins at a step 1202 where an ICS device may control at least a first connected device according to instructions received from a supervisory component of an OMN. For example, an ICS supervisor of an OMN may provide commands/data to an ICS device in accordance with a PROFINET protocol. In some embodiments, in addition to the ICS device controlling at least the first connected device according to instructions received from the supervisory component of an OMN, or as alternative thereto, the ICS device may control the at least first connected device according to instructions received from a TMN, independent of the OMN. That is, the ICS may be controlled exclusively by an OMN or by a TMN or may be controlled by both the OMN and TMN in a coordinated fashion. The ICS device may be an ICS controller and may be an SIID, as described in more detail elsewhere herein.

Following the step 1202 is a step 1204 where the ICS device may detect and/or receive from one or more other ICS devices information about one or more connected devices in the ICN. Following the step 1204 is a step 1206 where the ICS device may send (e.g., report) to a supervisory component of the OMN a first set of information based on the information detected and/or received. The first set of information may be all of the detected and/or received information or a subset thereof and may be selected and/or formatted in accordance with an ICS protocol, e.g., PROFINET. Furthermore, the first set of information may be sent in response to an event, for example, the detection of a certain property value on an ICS device or a request from the supervisory component or may be sent according to a predefined schedule. The first set of information may be sent directly to an ICS supervisor or other component of the OMN by the ICS device itself, for example, if the ICS device is an ICS controller, or may be sent indirectly to the supervisory component via another ICS device serving as an ICS controller for the ICS. Following the step 1206 is a step 1208 where the ICS device may send (e.g., report) to a component (e.g., gateway or cloud server) of a TMN a second set of information based on the information detected or received by the ICS device. The second set of information may be all of the detected and/or received information or a subset thereof and may be selected and/or formatted in accordance with techniques described herein, for example, using a streamlined blockchain communication sequence. The second set of information may be sent directly to a gateway or cloud component of the TMN by the ICS device itself, for example, if the ICS device is an SI I D configured to serve as an interface to the TMN cloud. The second set of information may be sent indirectly from the ICS device to a TMN gateway or cloud server via another SI I D on the ICS if the ICS device is not configured to serve as an interface to the TMN cloud.

FIG. 13 shows a private dedicated cellular network 1300 that provides cellular communication (e.g., 5G communication) for an industry campus 1302. The dedicated cellular network 1300 may be provided by four local/private cellular base stations 1304-1307, although, of course, any number of base stations may be used depending upon a variety of functional factors, such as area of coverage, desired redundancy and throughput, desired signal strength, etc. The industry campus 1302 may be an area that services a particular company, a particular industry, or a group of industries and possibly other businesses that may or may not be closely related. It is also possible for the industry park 1302 to include one or more private residences, possibly for people that work in the industry park 1302. The base stations 1304-1307 may be part of the private dedicated cellular network 1300 which may use 5G technology and may allow the reservation of bandwidth through, for example, a dedicated bandwidth (e.g., 3,700 - 3,800 MHz) and system resources, such as a private dedicated cellular network defined by the Bundesnetzagentur in Germany. In some embodiments, the dedicated cellular network 1300 uses TDD (Time Division Duplex) in contrast with a conventional public cellular network that uses FDD (Frequency Division Duplex). Using different communication mechanisms may minimize inference between the networks. Of course, other private cellular networks are also possible and even other types of networks with different configurations may be used. The dedicated cellular network 1300 may use security credentials that are similar (or identical) to security credentials used by conventional commercial cellular networks including an operator code, an operator code credential, a cryptographic authentication key, and/or SIM card data. The cryptographic authentication key may be used in a cellular mobile device that accesses the dedicated cellular network. The SIM card data may include an integrated circuit card ID, a mobile station international subscriber directory number, or an international mobile subscriber identity.

Each of the base stations 1304-1307 may provide cellular coverage to a particular portion of the industry campus 1302 so that all of the industry campus 1302 is covered by at least one of the base stations 1304-1307 and at least some portions of the industry campus 1302 are covered by two or more of the base stations 1304-1307. Devices located in the industry campus 1302 may communicate via the base stations 1304-1307 using the dedicated cellular network 1300. The devices may be the user devices 140-142 of FIG. 2A, which could include conventional cellular mobile phones or tablets. The devices could also be one or more of the ICS devices 133-135, one or more of the gateways 119-121, or any other appropriate devices, such as devices described elsewhere herein. The devices in the industry campus 1302 may communicate with each other, with the cloud 101, and with other devices via the dedicated cellular network 1300, possibly in combination with other networks either within or outside the industry campus 1302.

In some instances, the ability to communicate with more than one of the base stations 1304-1307 provides redundancy that protects against failure of a single component. Moreover, multiple communication paths allow optimization of communication bandwidth to support prioritizing data communication with components (e.g., control devices) within the industry campus 1302. Also, it is possible to use the dedicated cellular network 1300 to provide redundancy for a (possibly preexisting) wired network so that components within the industry campus 1302 may communicate either using the wired network or the dedicated cellular network 1300. Note that, in addition to communication path redundancy, additional redundancy may be provided by using redundant control devices to protect against failure and/or inadequate bandwidth (i.e., lack of resource capacity) of one of the control devices. The core services layer 110 of the cloud 101 may include components that provide control information to the devices in the industry campus 102 using the dedicated cellular network 1300. The data that is exchanged may be stored as one or more transaction records (e.g., blocks within a blockchain), and may be part of a transaction register, as described in more detail elsewhere herein. It is also possible to use a blockchain mechanism like that described elsewhere herein for one or more settings including redundancy, resource capacity, and quality of service (QoS) settings.

Referring to FIG. 14, the dedicated cellular network 1300 is shown as communicating directly with the cloud 101, described elsewhere herein. In some embodiments, the entire cloud 101 or a portion of the cloud 101 may be part of a dedicated cellular network 1300' that is like the dedicated cellular network 1300 but includes the cloud 101. It is also possible for the dedicated cellular network 1300 to communicate with one or more other networks 1400, such as a public non-dedicated cellular network, the Internet, a private or public non-cellular network, or some combination thereof. In such a case, the dedicated cellular network 1300 may communicate with the cloud 101 through the one or more other networks 1400. Note that the communication through the other network(s) 1400 may be in addition to, or instead of, direct communication between the dedicated cellular network 1300 and the cloud 101.

In an embodiment herein, the dedicated cellular network 1300 transmits data at a quality-of-service level comparable to quality of service provided for voice communication in a public commercial cellular network, which is a QoS Class Identifier (QCI) level of 6 (or similar). That is, sufficient resources (e.g., bandwidth, priority, latency, etc.) are provided to transmit data on the dedicated cellular network 1300 so that the data transmission (e.g., exchanging data with a PLC) is comparably in quality to voice transmission in a conventional, commercial, non-dedicated cellular network. Note that, since the dedicated cellular network 1300 is not used primarily for voice communications, then transmitting data at a QCI level of 6 does not interfere with or adversely impact any expected voice quality for the dedicated cellular network 1300. Generally, a scalable subset of resources of the dedicated cellular network 1300 are reserved for industrial control systems (e.g., control devices) in the industry campus 1302, including being reserved for communication between the industrial control systems and the cloud 101.

In embodiments where the other network(s) 1400 are used in connection with the dedicated cellular network 1300, the system described herein provides an overall quality of service by mapping cellular quality of service values (e.g., QCI = 6) to comparable IP network quality of service values (e.g., PCP = 4 or 5). The cellular network quality of service corresponds to the IP network quality of service. Thus, data travelling through the networks 1300, 1400 experiences comparable quality of service irrespective of the type of network (cellular or IP) that the data is traversing. The quality of service may be controlled, at least in part, by components of the ICS management service 118, which is described elsewhere herein.

Users may enter and leave the industry campus 1302 with user devices, such as mobile phones or tablets, that switch between a public cellular network and the dedicated cellular network 1300 depending on a location of the user device (e.g., in range of the dedicated cellular network 1300 or not) as well as possibly settings provided on the user devices. For example, on Android mobile phones, it is possible to set up multiple user profiles that operate somewhat independently (e.g., Enterprise Mobility Management (EMM capability to provide dedicated QoS channels and network resources and/or LTE) service). Thus, a user may have a first profile for accessing a public cellular network, such as the T-Mobile cellular network, and may have a second profile for accessing the dedicated cellular network 1300. A user may switch between the profiles by manually actuating controls on the cellular mobile phone. It is also possible to have the cellular mobile phone switch automatically in response to the user entering and leaving the industry park 1302.

Referring to FIG. 15, a flowchart 1500 illustrates processing performed in connection with a user device entering and leaving the industry park 1302. Processing begins at a first step 1502 where the user device enters the industry park 1302, which may be determined, for example, when the user device detects one or more of the base stations 1304-1307 of the dedicated cellular network. In some cases, it is possible for a user to present the user device to a reader, such as an NFC reader, to signify entering (and/or leaving) the industry park 1302. In some embodiments, the user device may be specifically tracked after entering the industry park 1302. Tracking may include using location monitoring and tracking with, for example, WIFI signals, mobile telephony signals, GPS signals and perhaps other technology. In some instances, BT (Bluetooth) communication may be activated to detect one or more BT beacons that collectively define one or more wireless perimeters that may be used for tracking. In addition, the user device may be configured with a digital site map on which locations may be marked to assist a user.

Following the step 1502 is a test step 1504 where it is determined if the user device that is entering the industry park 1302 is capable of operating in an alternative mode where the user device communicates using the dedicated cellular network 1300 in connection with controlling other devices and obtaining information from the other devices, as described in more detail elsewhere herein. In some cases, the user device may communicate exclusively using the dedicated cellular network 1300. In other instances, the user device may communicate using the dedicated cellular network 1300 in addition to using other networks, such as one or more of a local Wi-Fi network, a non-dedicated (public) cellular network, Bluetooth, etc.

If it is determined at the test step 1504 that the user device is not capable of operating in an alternative mode using the base stations 1304-1307, then processing is complete. Otherwise, control transfers from the test step 1504 to a step 1506 where the user device is transformed from an original mode to the alternative mode to communicate with other devices in the industry park 1302 using the base stations 1304-1307. In an embodiment herein, the user device may use an alternative profile, described elsewhere herein, in connection with changing modes. Thus, for example, the user device may be a cellular mobile phone or a tablet with cellular capabilities that may have a first (original mode) profile corresponding to conventional use (e.g., the user communicates using a conventional non-dedicated cellular network) and having a second (alternative mode) profile corresponding to communicating with other devices in the industry park 1302 using the base stations 1304-1307. In some cases, transitioning from the original mode to the alternative mode includes disabling one or more capabilities (e.g., features) of the user device while one or more other capabilities of the user device are allowed to remain enabled. For example, WIFI communication capabilities, the usage of cameras, the usage of interfaces such as (micro) USB and/or the usage of other interfaces to connect other devices or storage media may be disabled on the user device, whereas other capabilities, for example, mobile telephony, GPS, NFC and BT, may remain enabled on the user device. In some embodiments, the alternative mode may include controlling the user device so that the user device is not capable of being powered down and/or set to permanent idle modes. In some embodiments, the user device may be configured with an ability to read a QRC label and/or an RFID UHF tag on goods or other things while the user device is at the industry park 1302. The different modes may use different credentials or may share at least some credentials.

Following the step 1506 is a test step 1508 where it is determined if the user device is still in the area of the industry park 1302. Since the user device may be carried by a user that may move about, it is possible for the user device to leave the area (i.e., the industry park 1302). Note also that is possible for a user to actively check out of the area by, for example, actuating the user device, presenting the user device to a reader such as an NFC reader, etc. If it is determined at the test step 1508 that the user device is leaving (or has already left) the area of the industry park 1302, then control transfers from the test step 1508 to a step 1512 where the user device is switched from the alternative mode back to the original mode of the user device (e.g., switched to a conventional mobile phone accessing a conventional nondedicated cellular network). A transaction may have been recorded to indicate capabilities that were enabled or disabled upon arrival at the industry park 1302 and/or actions that were taken with respect to the same. The transaction record may be stored at a server and/or at a gateway and/or by exception (e.g. in case of power outage or service interruption states of the gateway/cloud) securely on the user device, for example, as one or more blockchain transaction records (blocks of a blockchain). The transaction record may be accessed as part of the step 1512 to determine how to restore capabilities of the user device to place the user device in the original mode. Following the step 1512, processing is complete. In some cases, the departure of the user device from the industry park 1302 may be recorded. For example, a gateway device located at the industry park 1302 may exchange one or more communications with a server (e.g., in accordance with the streamlined blockchain communication sequence) resulting in a transaction record of the user device departing the industry park 1302 being recorded in a secure transaction register. In some embodiments, in addition to the departure itself being recorded, information detected or determined (e.g., by the user device) during the visit of the user device, but not reported to a gateway and/or server during the visit, may be reported to the gateway and/or server and recorded, for example, in a same or similar manner as the reporting and recording of the departure of the user device.

In some embodiments, the user device may continue to be monitored after departure from the industry park 1302. For example, in some embodiments, the user of the user device may be involved in the transportation of goods or some other activity (e.g., which may be defined by a process object) for which it is desirable to continue to track the location of the user and/or the state of the goods, user device, monitoring or other thing involved in the transportation of the good (e.g., container, tank, pallet, packaging) even after the user device has left the industry park 1302. For example, the user device may be used by a truck driver who transports goods to/from the industry park 1302. Following the step 1512, processing is complete.

If it is determined at the test step 1508 that the user device is still in the area of the industry park 1302 (and thus should remain in the alternative mode), then control transfers from the test step 1508 to a step 1514 where the user device communicates with other devices of the industry park 1302. The communication may include any appropriate exchange of data, including using the user device to signify approval of component (e.g., a process or state of something) at the industry park 1302. The user device may also receive information, including state information, from one or more devices at the industry park 1302. The user device may also provide control information, including starting and stopping industrial processes, making adjustments, etc. Note also that GPS information from the user device may be used in connection with exchanging data so that, for example, the user device is required to be proximal to a location of an industrial component in order to provide related control of the component or adjustments or approvals for the component. Further, in some embodiments, the user device does not directly communicate with other devices of the industry park, but the communication flow is directed via a gateway and/or the cloud. Redirection of communication via gateways and/or the cloud is foreseen as some user devices might not reach security standards required for the industry park 1302. The gateways/cloud would then work as a "security master" adding security to the communication between the user device and other devices of the industry park.

In some embodiments, a status of a user device with respect to one or more of the other devices in the industry park 1302 may be determined. For example, one or more data objects associated with the user device and/or the industry park 1302 may be accessed, for example, from a gateway and/or server. A user (person) object may specify a site object for the industry park 1302, and one or more process objects associated with the user object, and specify one or more role attributes. The objects and attributes may collectively define one or more competencies of the user with respect to one or more processes in the industry park 1302. A separate company object may include one or more site objects, and one or more process objects, product objects, and rule objects for the company site, in relation to the one or more processes. The user object and the company object may be compared to determine the status of the user with respect to the one or more products and processes specified for the industry park 1302, for example, the permissions the user has with respect to places and other devices at the industry park 1302.

A status of the user and/or the user device with respect to the industry park 1302 or portions thereof may be determined, for example, by accessing one or more pertinent data objects (e.g., person/user object, site object, company object, etc.) and analyzing and comparing the attribute value of each, including, for example, safety and role attributes, to determine the status of the user and/or the user device with respect to a particular location. For example, pertinent data objects may define qualifications of a user for certain work with processes or corresponding other devices. The following are some examples: 1. A person/user object may specify qualifications of a person in detail using the following attributes and objects: a. Role attributes: Competent Process (specifying processes for which the person is competent), Safety Operations (e.g., according to Zones 0,1,2 of the hazardous environments as classified under NEC 500, NEC 505 and ATEX, which may be indicated to the user with Red, Yellow, Green Zones.); b. Safety attributes: I M El (International Mobile Equipment Identity), to specify the user device of the person/user according to Zones 0,1,2 of the hazardous environments as classified under NEC 500, NEC 505 and ATEX, which may be indicated to the user with Red, Yellow, or Green marked user devices. c. Site and Process objects to define the detailed access rights (e.g., via NFC codes, or via QRC labels) of the person/user.

2. A process object may specify process requirements in detail using the following attributes and objects: a. Safety attributes to provide process safety classifications; and b. Products, devices, and rules to be applied for the process.

3. A company object is used to specify the mobile telephony, WIFI and geo-fencing attributes for a site, including: a. Site objects specifying technical attributes of co-ordinations, one or more mobile cell IDs of the site, etc., Technical co-ordinations and Mobile Cell ID b. Site objects specifying a technical attribute of a WIFI ID c. Site objects specifying site maps, geofencing areas and BT barriers.

It should be appreciated that the determination of the status of the user and/or the user device with respect to the area may have been performed prior to the detection of proximity to the area.

In some embodiments, in response to detection of proximity, for example, to a restricted or hazardous area (via geo-fencing or a BT barrier), one or more alerts may be issued. This is described, for example, in U.S. Patent 10,891,208 to Bernd Moeller, which is incorporated by reference herein. The one or more alerts may include a written electronic communication to one or more entities, for example, a gateway and/or server, security personnel and/or administrators of the industry park 1302, or to the user device, for example, as an email message, text message or other notification that may pop-up on the screen of the user device. The one or more alerts may include playing a sound (e.g., a ringtone) on the user device or vibrating the user device. The one or more alerts may also include a sound external to the user device (e.g., of a horn, buzzer or siren) and/or a visual indication on the physical premises (e.g., a blinking light, or the closing or lowering of a door, gate or barrier). In some embodiments, a gateway may be installed near (e.g., just outside) of a hazardous or restricted area, and include or be coupled to one or more physical devices (e.g., lights, speakers, doors, gates) that are physically close to the gateway. The gateway may control an alert being issued using one of the physical devices in response to the above-described proximity detection.

Whether or not to issue an alert, and the type of alert to issue, may depend on a safety classification of the area and a status of the user and/or user device with respect to the classification. For example, a hazardous or restricted area may have a safety classification of "Yellow" or "Red" or have no safety classification. Furthermore, the user may have a safety attribute object defined with respect to the area (e.g., in a person object of the user associated with the area), for example, or "Red", "Yellow" or none. Similarly, the user device may have a safety attribute defined for the area as well, e.g., a mobile safety equipment rating of Zone 1 or Zone 2. If the safety classification of the user is sufficient (i.e., qualified for red and yellow access, and the area has a safety classification of yellow), then no alert may issue. However, if the user is only qualified (via a safety attribute) for yellow, and the area has a safety classification of red, an alert may issue. The type (e.g., severity, and whether a sound, visual indication and/or electronic notification) of the alert may depend on any one or more of: the safety classification of the area; the safety qualification of the user; the safety qualification of the user device, the difference (e.g., in priority/severity) between any two of these attributes, and perhaps other factors (e.g., time of day, day of week, etc.). The issuance of an alert may be communicated and stored as a blockchain transaction record (block of a blockchain) to/on one or more components of the TMN 100 per techniques described in more detail elsewhere herein.

In some embodiments, issuing alerts may be considered a first line of defense in preventing a user from access a restricted, perhaps dangerous, area of the industry park 1302. Other techniques and mechanisms for preventing such access, including locks and/or access codes, may serve as a second (or more) line of defense. In some embodiments, in response to the detection of proximity, one or more other devices in the area or that allow access to the area (e.g., a lock on a door or gate, or a vehicle, machine or device) may be locked or unlocked. Whether or not to lock or unlock a lock mechanism may depend on a safety classification of the area and a status of the user and/or the user device with respect to the classification, for example, in a manner similar to that described elsewhere herein.

In some cases, in response to detection of proximity of the user device, the user may be provided one or more access codes to access an area using the one or more codes, or not be provided the one or more access codes so that the user may not access the area. Whether or not to provide the access codes may depend on a safety classification of the area and a status of the user and/or user device with respect to the classification, for example, in a manner similar to that described elsewhere herein.

Following the step 1514 is a test step 1516 where it is determined if an emergency situation exists. In an embodiment herein, the system may release the user device from the alternative mode in response to an emergency situation (e.g., a user dials "911" or "112" on a mobile phone). If so, then control transfers from the test step 1516 to a step 1518 where emergency mode functionality is maintained. In some cases, an emergency situation may be detected by the mobile phone itself, e.g., in cases where a human may show symptoms of heart attacks and/or loss of consciousness due to a critical condition in the industry park or due to attacks on a person (e.g., guard). Such cases may be detected by a mobile phone operating in a trunked radio mode and utilizing movement sensors/ physical sensors (e.g., watches) connected with the mobile device to detect outage of pulsation, breathing and/or movement. At the step 1518, the user device operates in an alternative mode using the base stations 1304-1307 of the industry park 1302 to trigger an alarm to the cloud that provides the GPS data like trunked radio services with dead man's control. Following the step 1518, control transfer back to the test step 1516 to determine if the alternative/emergency mode should be maintained (i.e., the emergency situation still exists). If so, control transfers to the step 1518 where the device remains in alternate mode with emergency functions activated (e.g., GPS, Sensor functions, camera functions) considering the ATEX NEC certifications of the respective device (if applicable). In some embodiments, the step 1516 may only be performed if an emergency call itself does not trigger an unsafe/dangerous situation. Otherwise, if it is determined at the test step 1516 that there is no emergency, then control transfers from the test step 1516 back to the step 1508, discussed above, for another iteration.

It should be appreciated that any of the processing illustrated herein may be performed by an SI I D residing on an ICS of a TMN, in combination with logic executing on one or more other components and data structures of the TMN described herein. Also, in some embodiments, the security module 127 may be implemented as, or include one or more components or functionality of, the security module 313 described in relation to FIG. 3 and FIG. 5. The performance and security of the system described herein, including SI IDs, user devices, gateways and servers in the cloud 101, may be enhanced using security modules like the security module 127 or the security module 313 for data security operations. One or more of the security modules 127, 313 may be integrated into an SIID. The role of an SIID may be different in different ICSs. While several embodiments of the system described herein describe the use of thing management networks (TMNs) in connection with ICSs, the invention is not so limited. In some embodiments, industrial systems that do not include ICSs and/or SI I Ds may be managed. That is, certain devices of an industrial system may be managed using a TMN, without use of an ICS or SIID.

FIG. 16 is a block diagram illustrating a TMN 1600, according to embodiments of the system described herein. Other embodiments of a TMN, including variations of the TMN 1600, are possible and are intended to fall within the scope of the invention. The TMN 1600 may include any of the components of the TMN 100, described above, or variations thereof. The TMN 1600 also may include any of: one or more monitoring devices 1623, 1624, 1626, 1628 and a user device 1641, which may be a variation of the user device 141. It should be appreciated that, while only four monitoring devices are shown in FIG. 16, the invention is not so limited, as any number of monitoring devices may be used, taking into consideration the feasibility given the fiscal and management costs of equipment and network, compute and storage resources.

In some embodiments, one or more of the monitoring devices 1623, 1624, 1626, 1628 may be coupled (e.g., physically or wirelessly) to one or more respective things (IOT devices), for example, as illustrated by the monitoring devices 1623, 1624 in relation to things 1643, 1644, respectively. In some embodiments, one or more monitoring devices may be contained within (e.g., as a separate component or integrally) one or more respective things, for example, as illustrated by the monitoring devices 1626, 1628 within things 1646, 1648, respectively. It should be appreciated that there may be a one-to-one relationship between monitoring devices and things, as illustrated in FIG. 16, a one-to-many relationship (i.e., one monitoring device coupled to multiple things) or a many-to-one relationship (i.e., multiple monitoring devices coupled to one thing). It should also be appreciated that a thing may be any type of electronic device (IOT device) that may be managed by a thing management network.

The gateway 120 may be coupled to the monitoring devices 1624, 1626, 1628. Generally, a gateway may couple one or more monitoring devices to the cloud 101, which may include one or more servers. In some embodiments, one or more monitoring devices, e.g., the monitoring device 1623, may be connected directly to the cloud 101. In such embodiments, the monitoring device 1623 may be configured with any of the gateway functionality and components described herein, and treated like a gateway, at least in some respects, by the cloud 101. The gateway 120 may couple the user device 1641 to the cloud 101. In some embodiments, the user device 1641 may be connected directly to the cloud 101. In such embodiments, the user device 1641 may be configured with any of the gateway functionality and components described herein, and treated like a gateway, at least in some respects, by the cloud 101.

The gateway 120 may be configured to process thing status information received from one or more monitoring devices, which may include analyzing detected physical properties and other information that may have been generated or received by the monitoring device, and providing instructions to the monitoring device, as described in more detail elsewhere herein.

Each of the monitoring devices 1623, 1624, 1626, 1628 also may include one or more thing management applications 1633, 1634, 1636, 1638, respectively, having some or all of the same capabilities as other cloud applications described herein, and each of the monitoring devices 1623, 1624, 1626, 1628 may include one or more components (which may be referred to herein as thing management components) for implementing the one or more thing management applications 1633, 1634, 1636, 1638, respectively. By performing such processing at one or more gateways, and/or at the monitoring devices themselves, as opposed to in a more centralized fashion on one or more servers in the cloud 101, the system 1600 may implement and enjoy the benefits of more distributed edge-computing techniques.

The user device 1641 may be any of a plurality of devices (e.g., desktop computer, laptop computer, tablet, personal digital assistant (PDA), cellular (e.g., smart) phones, other devices, or any suitable combination of the foregoing that enable a user to interact with other components (e.g., gateways, servers, monitoring devices)) of the system 1600. Each user device may be configured with any of the functionality described in the '628 patent with respect to the UEs 54, 55, 56 shown in FIG. 1 of the '628 patent, including any user equipment functionality described in relation to FIG.s 2 and 3 of the '628 patent. In some embodiments, one or more gateways may be configured with user device functionality and/or one or more user devices may be configured with gateway functionality. In addition, the user device 1641 may be configured with one or more capabilities of a user device as described in PCT Patent Application No. PCT/IB2019/000943 (W02020084337A1) to Bernd Moeller, titled "Access System" and published on April 30, 2020, (hereinafter the '943 application), which is incorporated by reference herein. The '943 application corresponds to U.S. patent application 16/636,696 titled "ACCESS SYSTEM" and filed on February 5, 2020, which is incorporated by reference herein.

In some embodiments, the user device 1641 may include a security module having the same or similar capabilities as the security module 127 (e.g., the security module 313) of the gateway 120. For example, the user device 1641 may include a security module 1642, which may include a resident portion 1642a that is a permanent part of the user device and a separate and discrete transitory portion 1642b, which may be physically and/or wirelessly coupled and decoupled from the resident portion 1642a. For example, the transitory portion 1642b may be a dongle as described in more detail elsewhere herein. In some cases, all of the security functionalities may be provided by the resident portion 1642a so that the transitory portion 1642b is not present. A TPM may be used and may be integrated inside the user device 1641, or the TPM functionality may reside inside a chip (system on chip) or the TPM may be coupled temporary as a dongle or another device that is part of the transitory portion 1642b.

Note that TPM functionality may include an entire set of TPM and each subset functionality including mechanisms that are used to protect a TPM with respect to reverse engineering. Such reverse engineering mechanisms include reading of data, decrypting of signals, physical analysis of signals via radio, infrared, nuclear magnetic resonance, and other physical means, changing of data by electrical impulses and other intrusion attempts. Protection mechanisms with respect to reverse engineering may include multiplexing and randomization of signals inside the TPM, implementation of protection layers and additional metal layers within the chip layering structure of the TPM, insertion of randomized signals, creation of interference signals, sensors to detect intrusion, hardware fuses to lock circuits and/or memory areas creating one time executable/programmable circuits/memories, mechanisms to delete data in case of intrusion detection and other mechanisms to protect the TPM. Note that in some instances, such as where specific commercial considerations are taken into account, a manufacturer of a TPM chipset may want to save cost by implementing only subsets of the protection mechanisms in a TPM and risk compromising security by integrating such subsets as elements inside a chip (system on chip).

The user device 1641 may include one or more visitor access apps (e.g., a visitor access app 1647). Thing management applications or portions thereof that may be included in a user device are described in '943 application. In some embodiments, the visitor access app may consume approximately 40Mbyte of non-volatile memory of the user device 1641.

The core services layer 110 may provide one or more services, which may be consumed by applications in the transformation layer 102, which also may be referred to as an application layer. The services may include services for managing things, including the data, mobility and security (e.g., access) of things, and other services associated with things. For example, services may include thing management services 1616, mobile management services 1618, other services corresponding to things, one or more databases and/or database management systems corresponding to any of the foregoing, and/or any suitable combination of the foregoing. The thing management services 1616 may include data about things managed by the TMN 1600. Any of the data included in the thing management services 1616 and mobile management services 1618 may include information also stored in a monitoring device and/or user device. In some embodiments, the information corresponding to a thing may present such a complete state of the thing that it may be considered a virtual representation of the thing, e.g., a digital twin. The data stored within the services 1616, 1618 may be stored as one or more transaction records (e.g., transaction blocks within a blockchain), and may be part of a transaction register for the TMN 1600 or one or more defined subsystems thereof. The transformation layer 102 may include any of: one or more visitor access management applications 1604 and one or more safety management applications 1608, each of which is described in more detail in the '943 application. The one or more visitor access management applications 1604 may include one or more applications for managing a visitor's access to a site and to access and/or use one or more resources (e.g., places or things) as described in more detail the '943 application. For example, the applications may include applications configured to monitor a location of a user device of a visitor at or near a site (e.g., in a reception area or at a security gate) via one or more communication technologies, for example, any of those described herein, including but not limited to GPS, WiFi, mobile telephony, NFC, BT and BT LE. The applications may be configured to enable and/or disable capabilities of user devices while on site, and to restore such capabilities to a user device when the user device leaves the site. The applications may be configured to communicate with and and/or control the user device while the visitor is on-site using such communication technologies, although in some embodiments one or more of these communication technologies may be disabled on the user device while on the site, in which case the disabled technologies would not be used. The applications may be configured to control access to places and/or things on the site via locking mechanisms and access codes, and to issue alerts when it is detected that the user is within a predefined proximity to a certain area (e.g., a restricted or hazardous area) within the site. The foregoing functionality and other functionality that may be provided by visitor access management applications or other applications in the transformation layer are described in the '943 application.

The one or more safety management applications 1608 may be configured to determine one or more aspects concerning the safety of things and places on a site, for example, whether an item or place is hazardous and/or the extent to which it is hazardous, e.g., a safety classification promulgated by one or more safety standards organization. In some embodiments, an inventory application (or another application) of the transformation layer 102 may be configured to maintain an inventory of all visits by any person to any site managed by the TMN 1600. For example, as is described in more in the '943 application, a person object may be defined on the thing management system 1600 and each time the person visits, a record of the visit may be created and stored, for example, in an inventory database accessible by the inventory application. Each record may be a block of a blockchain record (e.g., a smart contract).

The one or more visitor access management applications 1604; one or more safety management applications 1608; the inventory application, order management application and one or more other application may be configured (e.g., via one or more APIs or other interfaces) to interact with other applications within the transformation layer 102, including each other. The applications or portions thereof may be programmed into gateways, Web browsers, user devices and/or monitoring devices of the thing management network as well. One or more applications of the transformation layer 102 may be provided as all or part of a Web client browser app, as a hybrid of a Web client browser app and native device applications or as native device applications. The applications may reside, or be programmed or downloaded into gateways (e.g., the MYNXG Edge devices), monitoring devices (e.g., the MYNXG Sense devices) or user devices.

FIG. 17A is a block diagram illustrating an industrial system 1700, according to embodiments of the system described herein. Other embodiments of an industrial system, including variations of the industrial system 1700, are possible and are intended to fall within the scope of the invention. The industrial system 1700 may include various elements of the TMNs 100, 100', 100", 1600 described in more detail elsewhere herein. The industrial system 1700 may be segmented into a plurality of zones (sites), including, for example, in accordance with the network segmenting requirements of IEC 62443. The plurality of zones may include, for example: a local corporate zone (LCZ) 1702 (local corporate site), a core industrial management zone (CIMZ) 1704 (core industrial management site), one or more remote corporate zones (RCZs) 1716a, 1716b (remote corporate sites) and one or more industrial control zones (ICZ) 1724a-c (industrial control site). The industrial system 1700 may include more or less than the three ICZs and two RCZs illustrated in FIG. 17A. The CIMZ 1702 and the ICZs 1724a-c may be considered to collectively define a TMN of the industrial system 1700. The LCZ 1702 may include an information technology network (ITN) 1703 (e.g., any of the ITNs described in more detail elsewhere herein), and perhaps other elements of an organization management network (OMN) described in more detail elsewhere herein, for example, components of an OMN not included in the CIMZ 1704. The CIMZ 1704 may include a firewall 1705 between the ITN 1703 and one or more non-proprietary networks 1712, i.e., one or more networks not under control by the same entity (e.g., organization, corporation, government agency, educational institution) that controls the LCZ 1702 and the CIMZ 1704 or on whose behalf the LCZ 1702 and the CIMZ 1704 are controlled. The one or more nonproprietary networks 1712 may include any of: a mobile network, a TCP/IP network, a satellite network, another type of network or any suitable combination of the foregoing. The one or more non-proprietary networks 1712 may be a public network, such as the Internet. Note that, with non-proprietary networks, such as the Internet, there may be no inherent protections against eavesdropping, manipulating data in transit, and even man-in-the-middle attacks. As discussed in more detail elsewhere herein, the system described herein provides secure communication that protects communication between authorized entities.

The LCZ 1702 may communicate with RCZs 1716a, 1716b and/or ICZs 1724a-c over the one or more non-proprietary networks 1712 to provide services for ICZs 1724a-c as described in more detail elsewhere herein. For example, the ITN 1703 may provide manufacturing executive-level functionality, enterprise resource-level functionality and other functionality for the ICZs 1724a-c. Each of the RCZs 1716a, 1716b may include an ITN that provides at least some of the same services as the ITN 1703 and may assist the ITN 1703 in providing such services. For example, the ITN 1718 may include one or more components, e.g., one or more laptops, desktops or servers, smartphones and or tablets, to provide and/or assist in providing such services.

The LCZ 1702 also may include a firewall 1706 between the LCZ 1702 and the CIMZ 1704, for example, to a firewall 1707 of the CIMZ 1704. The CIMZ 1704 may include the services cloud 101 or a variation thereof, which may include, among other components, the transformation layer 102 and the core services layer 110, or variations thereof. The transformation layer 102 and the core services layer 101 may provide the services described in more detail elsewhere herein, including the monitoring and control of devices within the ICZs 1724a-c.

The CIMZ 1704 may include the firewall 1707, and also may include a firewall 1709 between the CIMZ 1704 and the one or more non-proprietary network(s) 1712 and a proprietary wireless network 1714, for example, a private 5G cellular network that may be used to establish an industry campus as described in more detail elsewhere herein. Such an industry campus may include, for example, the CIMZ 1704 and the one or more of the ICZs 1724a-c, for which the components of the transformation layer 102 and the core services layer 110 may provide the services described in more detail elsewhere herein, including the monitoring and control of devices within the ICZs 1724a-c. The services of the transformation layer 102 and the core services layer 110 also may be provided to the devices within the ICZs 1724a-c over the one or more non-proprietary networks 1712, as described in more detail elsewhere herein.

Each of the ICZs 1724a, 1724b, 1724c may include a control device 1726a, 1726b, 1726c, respectively, and one or more managed devices 1728a, 1728b, 1728c, respectively. Each of the control devices 1726a, 1726b, 1726c may control secure transmission of state information and/or control information between the respective managed devices 1728a, 1728b, 1728c of a corresponding one of the respective ICZs 1724a, 1724b, 1724c and the CIMZ 1704. For example, each of the control devices 1726a, 1726b, 1726c may be a gateway, edge device or SI I D, and may provide the any of the functionality attributed to such components, as described in more detail herein, including for example, serving as a PLC controller of an ICS. Each of the one or more of the ICZs 1724a, 1724b, 1724c also may include one or more other components described in more detail elsewhere herein, including kiosks at a business (e.g., industrial) site or user devices, for example, the user devices 140, 141, 142, 1641, which may be a mobile phone, tablet or any of the other types of user devices described herein.

The managed devices 1728a, 1728b, 1728c may be any type of device of a TMN for which it is described herein that a gateway, SI I D or other device controls the secure transmission of state information and/or control information with cloud services of the TMN. For example, the managed devices 1728a, 1728b, 1728c may include any of the ICS devices 209, 212, the non-SIID ICS controller 208, the connected devices 204, 206, 210, and any of the things and monitoring devices described in relation to FIG. 16. It should be appreciated that a monitoring device (e.g., the monitoring device 1623) may be configured with gateway capabilities and serve as a control device. The control devices 1726a, 1726b, 1726c and the managed devices 1728a, 1728b, 1728c may collectively constitute an industrial resource 1730 of the industrial system 1700.

Each of the control devices 1726a-c may include a security module (SM) 1729a-c, respectively, that enables the secure communication transmission of state information and/or control information between the respective managed devices 1728a, 1728b, 1728c of a respective one of the ICZs 1724a, 1724b, 1724c and the CIMZ 1704. Each of the SMs 1729a-c may be or may include the security module 313, which may include the secure component 418, for example, a hardware-based TPM. For example, each of the SMs 1729a-c may have a secure component 418 that has embedded therein one or more private credentials that are inaccessible from outside the secure component 418. The one or more private credentials may be applied to securely transmit the state and/or control information. The one or more secure credentials may include a private device validation credential for which a public device validation credential is accessible by the CIMZ 1704, for example, by the security services 113 of the core services layer 110. Applying the one or more private credentials may include signing transmissions of the state and/or control information with a signature generated using the private device validation credential, where the signature may be validated by the CIMZ 1704 using the public device validation credential.

Each of the control devices 1726a-c may be configured to use a corresponding one of the SMs 1729a-c to generate blockchain transaction blocks of the state and/or control information using the private device validation credential, and to include the blockchain transaction blocks in the transmissions. The one or more private credentials also include a private communication credential (e.g., a cryptographic key). Securely transmitting the state and/or control information may include establishing a secure communication channel between the control device and the CIMZ 1704 using the private communication credential and transmitting the state and/or control information over the secure communication channel.

Each of the RCZs 1716a, 1716b may be communicatively coupled to one or more of the ICZs 1724a-c by a network 1720, for example, any of the type of networks described herein, including a public TCP/IP network, such as the Internet. Each of the RCZs 1716a, 1716b may include one or more firewalls between the RCZs 1716a, 1716b and the network 1712 and/or the network 1720.

In some embodiments of the system described herein, the LCZ 1702 and the CIMZ 1704 may reside in a same physical location 1740, for example, a room, floor, building, industrial campus, site, whereas in other embodiments the LCZ 1702 and the CIMZ 1704 may reside at separate physical locations. Similarly, each of the ICZs 1724a-c may reside in a same or different physical location as the CIMZ 1704; a same or different physical location as one or more of the other ones of the ICZs 1724a-c; and a same or different location than one of the RCZs 1716a, 1716b. For example, FIG. 17A illustrates an example where the ICZ 1724a and the ICZ 1724b and the RCZ 1716a reside in a same physical location 1742, and the ICZ 1724c and the RCZ 1716b reside in a same physical location 1744 that is different from the physical locations 1740, 1742.

Each of the ICZs 1724a-c may be provided as an indivisible unit that is characterized as a "zone" under ISA/ IEC 62443and the zone is certified as 62443, part 3-3 compliant, thus providing cybersecurity assurance and eliminating the need for a user to obtain a separate certification after deployment. Each of the ICZs 1724a-c may include at least some of the components described elsewhere herein, such as one or more SIIDs, one or more ICS controllers, one or more ICS devices, one or more ICS supervisors, one or more gateways, one or more sensor devices, and/or one or more monitoring devices.

In an embodiment herein, all outside communication with the ICZs 1724a-c is through the corresponding one of the control devices 1726a-1726c so that the managed devices 1728a- c only communicate outside the ICZs 1724a-c through the control devices 1726a-c, which may be characterized as "conduits" under ISA/IEC 62443. Moreover, all communication by the control devices 1726a-c may be secure (encrypted) to prevent eavesdropping, manipulation of data in transit, and man-in-the-middle attacks. In an embodiment herein, the security modules 1729a-c may contain one or more private credentials corresponding to a private key of an asymmetric public/private key pair. The private key(s) may be used to decrypt data that was encrypted using corresponding public key(s) and vice versa. In some instances, the public/private key pairs may be used to facilitate a symmetric encryption key exchange. Thus, an entity wishing to provide secure communication to one of the ICZs 1724a-c could initiate a symmetric communication key exchange using public/private key encryption in a conventional fashion. Similarly, each of the ICZs 1724a-c can provide assurance of identity as part of the exchange by digitally signing data from a communicating entity using a private key embedded in a corresponding one of the security modules 1729a-c.

In some embodiments, public keys of entities of the industrial system 1700, such as the LCZ 1702, the CIMZ 1704, the RCZs 1716a, 1716b and the ICZs 1724a-c may each have a public key and a corresponding private key used for communication and identity assurance. The association of the public keys with particular entities may be provided by digital certificates or by similar assurance from a trusted entity, that may be identified using a root of trust (RoT), which is described elsewhere herein. A remote server (e.g., a server in the cloud 101) or another appropriate authority may digitally sign a certificate (or similar) that binds a particular entity with a particular public key. Thus, when the ICZs 1724a-c communicates with another entity of the system 1700, the ICZs 1724a-c first obtain secure information indicating a binding of a public key with the entity (e.g., digitally signed information binding the public key of the entity with the entity) and then initiates secure communication using the public key of the entity. The secure information indicating the public key of the entity may be confirmed using the RoT, which may be stored in the security modules 1729a-c. Using secure communication, the industrial control system 1700 allows for exchanging data between authorized entities over non-proprietary networks in a way that avoids eavesdropping, manipulation of data in transit, and man-in-the-middle attacks. Moreover, if all communication for the ICZs 1724a-c (and other components) is restricted to only secure communication, then the ICZs 1724a-c (and other components) may be connected directly to non-proprietary networks, such as the Internet, without the need for any firewalls or similar cyber protection.

FIG. 17B is a block diagram 1700' illustrating an embodiment of the industrial system 1700 of FIG. 17A, according to embodiments of the system described herein. The block diagram 1700' illustrates that different components of the industrial system 1700 may be considered to align with different levels of industrial management hierarchy, including: Corporate Enterprise Levels 4 and 5 1750; OT Management Level 3 1752; OT Supervisory Level 2 1754; OT Control Level 1 1756; and OT Field Devices Level 0 1758. It should be appreciated that while only the ICZ 1724a is shown, the embodiment 1700' may apply to the ICZ 1724b and the ICZ 1724c as well.

The LCZ 1702 and the RCZ 1716a may be considered at the Corporate Enterprise Level 4 and 5 1750. The transformation layer 102 of the CIMZ 1704 and the proprietary wireless network 1714 may be considered at the OT Management Level 3 1752. The core services layer of the CIMZ 1704 and the control device 1724a may be considered at the OT supervisory level 2 1754.

As illustrated in the block diagram 1700', some of the managed devices 1728a may be considered at OT Control Level 1, for example, an access kiosk at reception at an industrial site or an ICS device that is not an ICS controller, and other managed devices 1728a may be considered at the Field Device Level 0, such as, for example, a sensor device, an NFC reader or RFID reader at an industrial site.

The system described herein implements a Smallest Possible Cell (SPC)/I ndustria I Control Cells (ICC) approach where a set of components is pre-configured and pre-certified to act as individual, independent "zone" (site), that is capable of providing data directly to the cloud 101 to take advantage of the functionality thereof. Operation of the cloud 101 is described in detail elsewhere herein. Each of the ICZs 1724a-1724c may be configured to perform as an SPC/ICC. The cloud 101 of the CIMZ 1704 may interact directly with the ICZs 1724a-1724c and may provide data for the CIMZ 1704 or directly to users in a secure manner using, for example, blockchain technology and encryption, as described in more detail elsewhere herein. Each SPC/ICC is implemented with Secure-By-Design-Devices (SBDD) and integrated automation devices that are fully automatically operated and maintained remotely, as described in more detail elsewhere herein. Manual interaction with the SPC/ICC (the ICZs 1724a-1724c) is limited to physical installation and the power-on of components of the ICC. This is achieved by mechanisms for ICC production described in more detail elsewhere herein.

In an embodiment herein, the ICCs are designed and produced by first creating one or more interoperability labs that simulate components and environment(s) in which the ICCs (ICZs 1724a-1724c) are expected to operate. Each of the interoperability labs may include a copy of the CIMZ 1704 along with all processes including the hosting capabilities of the cloud 101, the transformation layer 102 and the core services layer 110. The interoperability lab may also include a simulation or actual private mobile network (5G private campus network) deployed as a private campus network with capabilities similar to the proprietary wireless network 1714 described elsewhere herein. The interoperability lab may also include at least one version of each type of possible ICC, SBDD (i.e., each possible configuration of the ICZs 1724a-1724c) and possibly test automation devices connected to the ICC to facilitate testing.

The cybersecurity threats for the ICC and operation of the test automation devices may be stipulated in a digital representation in a form of testcases specified to test and validate the ICC. Predefined Security Functional Requirements (SFR) testcases may be executed as testcases using the REST API 111, which is described elsewhere herein in connection with FIG. 2A. The SFR testcases may be fully automated allowing a fast test execution and enabling continuous functional deployments. The result of the tests may be analyzed using the REST API 111 and automatically evaluated with test reports. Results of tests may be logged as blockchain transactions to the transactions service 112 of the core services layer 110. Each updated functionality of a system component (n+1) related to system components and corresponding connected automation devices is tested versus all existing releases of the existing system.

Following a successful test, updated software may be deployed in a secure manner as described elsewhere herein.

The ICCs are designed to operate in a non-secure environment (NSE) by assuming a worst case - that communication components of the ICC (the control devices 1726a-1726c of the ICZs 1724a-1724c) are not protected and must be able to detect any attempts at external attacks from the Internet. Such a design process must also include a security analysis for the control devices 1726a-1726c and the automation devices. To avoid testing all possible combination on the market, only certain configuration combinations which are frequently used may be tested. Such combinations of devices may be certified according to industry standards. During the lifecycle of the ICCs, reference systems may be created that can test and validate such ICC configurations fully automatically to address cybersecurity vulnerabilities and correlated software patches. The design process further requires timely execution of tests to ensure fast delivery of patches to counteract vulnerabilities. The system described herein facilitates creation of automated test cases for identified vulnerabilities by automating security functional requirement (SFR) specific test cases. Such automation creates together with the previously described mechanism a highly responsive, secure automation system. Note that using the interoperability lab to test specific configurations allows integration of the ICC into existing brownfield processes as such devices are risk analyzed and contain measures to counteract such risks for the worst case scenarios of device operation within an NSE. Any operational condition that adds physical limitations to access the device increases the security and reduces the cybersecurity attack profile.

Referring to FIG. 18, a flowchart 1800 illustrates using an interoperability lab to configure an ICC. Processing begins at a first step 1802 where automated tests are configured for the system. The automated tests may include conventional cybersecurity tests such as penetration tests and vulnerability scanning as well as tests to exercise various components of the system, including detecting cyber risks and vulnerabilities of printed circuit board assemblies, detecting cyber risks and vulnerabilities of components of the interoperability lab, and examining production data. Following the step 1802 is a step 1804 where the tests are run, as described elsewhere herein. Following the step 1804 is a test step 1806 where it is determined if any cybersecurity vulnerabilities have been detected based on the tests from the step 1804. If so, then control transfers from the step 1806 to a step 1808 where the system design and/or software is reconfigured to address whatever vulnerabilities are detected at the step 1806. Following the step 1808, control transfers back to the step 1804, discussed above, for another iteration of the tests.

If it is determined at the test step 1806 that no vulnerabilities are detected, then control transfers from the test step 1806 to a step 1812 where software used for the system is certified for distribution (i.e., is signed by private keys within a secure part of the cloud 101, as described in more detail elsewhere herein). Following the step 1812 is a step 1814 where the signed software modules are distributed to existing or new systems (the ICZs 1724a-1724c), as described in more detail elsewhere herein. The software module distribution may be triggered by a user (e.g., the asset owner) using, for example, electronic inventories, as described in more detail elsewhere herein. Systems that receive and use the software may be assured that the software has not been modified by a malicious user or otherwise altered because the software is signed, as described in more detail elsewhere herein. The received software may be flashed (stored in a flash drive to be subsequently executed) at each receiving system. Following the step 1814 is a step 1816 where the system design that was tested (i.e., the ICC of the interoperability lab) may be duplicated in the case of configuring a new system or revising components of an existing system. Following the step 1816, processing is complete.

In instances where only ICC units are used, network segmentation with significant demilitarized zones and firewalls (shown in FIG. IB, described above) may be avoided. The ICC may be designed redundantly and may contain edge computing capabilities that ensure continuous operation and availability of operation control systems in case of mobile network outages. Dependency on public mobile networks may be reduced by implementing private mobile networks, which are described elsewhere herein. The system described herein provides protection against i nstal lation/addition of unauthorized devices to the ICC that may be inserted by mistake or on purpose. A device being inserted is detected by a monitor that signals users by issuing alarms that may be received and analyzed at the core service layer 110 of the CIMZ 1704. Alarm information may be provided via processes defined by a Business Process Model and Notation (BPMN) as well as via conventional message media such as SMS, email, and other messenger services like WhatsApp, Telegram and others. Alarm information may be fully automated using, for example, SysLog mechanisms. As discussed elsewhere herein, the ICCs (ICZs 1724a-1724c) may not be controlled locally but, instead, are operated remotely via, for example, the CIMZ 1704 and the cloud 101.

Controlled production of ICCs includes flashing software to devices of the ICC, production test of the devices, personalization of devices, management of secure components of the ICC, secure download of keys as well as credentials, generation of TPM objects, reporting of production data and the locking of the secure components and of any OTP areas of a CPU. The ICCs may be shipped to an operational site as indivisible units. Installation of ICCs may support automated installation and registration of components of the ICC using the cloud 101 and components of the CIMZ 1704. Installation may include scanning QR code product labels and/or RFID UHF product labels placed on components of the ICCs. QRC RFID labels may contain at least the QRC information. It is also possible to provide half automated installation by scanning installed products after each installation step where the ICC is scanned, a component is installed, and the installation is reported.

Components within the ICC automatically register securely with the CIMZ 1704 after power on. All Field Bus Level 0 and Field Bus Control Level 1 devices connected to the ICC may be scanned and installed. The CIMZ 1704 checks the ICC configuration and validates if the connected automation devices are equal to the devices that are digitally represented in connection with data for the ICC. The ICC checks the configuration and submits alarms to the CIMZ 1704 in case of falsely connected devices. The ICC is fully remotely securely maintained after successful completion of installation, registration and validation at the CIMZ 1704. The automated operation of the system is designed to operate the ICC and components thereof and automation devices remotely via the CIMZ 1704. The system supports secure IOT administration using the CIMZ 1704 and the core service layer 110 and supports the transactions service 112 and the security services 113. Furthermore, administration functions may be implemented at the transformation layer 102 and may support the transaction data management applications 106, the SIID management applications 107, the ICS management applications 108, and the ICS twin 109.

The administration functions including electronic inventories may be designed with dual approvals and multifactor authentication. In addition, the administration functions may support the secure GMD (Data) assignments of Company, Site, Person, and Process according Figure 7H (see above) toward the ICC, components of the ICC, and automation devices. The administration functions may also support secure IOT assignments of things including the ICC, components of the ICC, and automation devices towards GMD Structures Company, Site, Person and Process. The administration functions may be logged using blockchain mechanisms for secure transactions.

In an embodiment herein, software deployment for the ICC, components of the ICC, and automation devices starts with an upload of the software by an authorized design center. The CIMZ 1704 checks if the software upload is provided by an authorized software design center and stores the software securely at the CIMZ 1704. The transformation layer 102 may contain an electronic inventory which informs the asset owner that the software is uploaded to the CIMZ 1704. The software may be signed by a PKI of the CIMZ 1704. The core service layer 110 of the CIMZ 1704 may contains the PKI and may use an HSM with credentials. The PKI signs uploaded software securely with the credentials and may store the software at a database of the CIMZ 1704. The transformation layer 102 may contain an electronic inventory which informs user(s) that the software is available for download to the ICC.

Downloading software to the ICC, components of the ICC, and automation devices may be fully automated. The transformation layer 102 may contain an electronic inventory where user(s) decide to start the download of the software over the air to the ICC. The core service layer 110 of the CIMZ 1704 may include functionality which executes and manages the over the air (OTA) download as described in more detail elsewhere herein (see, for example, FIG.s 9A and 9B and the corresponding text). The ICC may check the software signing with related keys and may submit alarms to the CIMZ 1704 in case the keys indicate that the software has been tampered with or is not otherwise authentic. The transformation layer 102 may contain an electronic inventory where user(s) are informed that the secure software download was successful and, if not, then the reason why the download failed.

Components of the ICC operate securely under possible threats of a nonsecure environment, meaning that anybody physically could access a component and electronically connect to the component. The ICC and components thereof may have a Trusted Compute Base (TCB) as described elsewhere herein. The TCB may be used to recognize any device software manipulation during establishment of a Root-of-Trust (described elsewhere herein). Any communication from a component of the ICC via Wide Area Networks (WAN) interfaces is encrypted by means of the TCB. A link between a communicating component of the ICC (control device) and the cloud 101 is secured by means of mutual authentication. Communication within the ICC is protected via mutual authentication and encryption if possible. Components of the ICC may have security monitoring capabilities and may detect physical intrusion via at least ambient light and/or movement sensors and other sensors. Software for components of the ICC may detect any manipulation and attack scenarios at the physical interfaces of the ICC and components of the ICC, including the CPU, via interfaces including detecting protocol and parameter variation.

Communication components of the ICC may detect any manipulation and attack scenarios at wired interfaces connecting the communication components and automation devices by identifying add on and/or removal of devices. Each component of the ICC is part of a security analysis that is performed following CC-EAL principles including analysis of security targets (threats), protection profile TOE (target of evaluation), and creating security functional requirements (SFR). Software of the ICC may detect any manipulation and attack scenarios at wireless interfaces including denial of service and collision management.

ICC integration includes integration of components of the ICC (automation devices/field level 1 and field level 0 devices). A limited list of ICC compliant field devices is integrated, validated and certified together with components of the ICC. In some cases, an integration may include industry certification, including a certification according to ISA/IEC 62443-3-3 and/or ISA/IEC 62443-4-2 and/or CTIA crypto cyber certification of IOT devices. Components of the ICC may support automated installation and identification; accordingly, the components and the ICC related automation devices may be marked and labelled with machine readable QRC and/or RFID UHF labels allowing machine reading for the automation of installation and maintenance services.

The ICC technology described herein be implemented across industries, for example in the automation-, chemistry-, power plant and energy distribution-, and all other industries, that manage critical infrastructures and operations, also in highly regulated markets. The ICC technology may be implemented inside a car, truck, bus, ship, train, drone. For example, a gateway-type of device may implement a secure control device communicating with Electronic Computing Units (ECU) for a car, which may be implemented as secure control device and/or upgraded by integrating the Trusted Compute Base (TCB). Note that the standard ISA/IEC 62443 may be more restrictive than the applied standards for the car/truck/bus vehicles, which is ISO/SAE 21434.

The ICC technology may also be used for controlling user equipment inside a building, where a gateway like the gateways 119-121 (described above) communicates with devices, sensors and actuators that may control the heating, devices, appliances, climate systems, and so on and so forth. Buildings that represent critical infrastructures may be hospitals, large administration buildings, and military buildings.

FIG. 19 shows a configurable dashboard creator 1900, according to embodiments of the system described herein. Other embodiments of a configurable dashboard creator, including variations of the configurable dashboard creator 1900, are possible and are intended to fall within the scope of the invention. The configurable dashboard creator 1900 may represent dashboard creation for a gateway device (e.g., and edge device), and may have been produced from a dashboard template configured with the widgets illustrated to create configurable dashboards and digital twins representing a corresponding gateway.

The configurable dashboard creator 1900 may include: a product widget 1902 for specifying a product and specific instance of the product that this the managed device; a device configuration widget 1904 for specifying certain device configuration parameters of the managed device; a thing widget 1906 for specifying a thing associated with the managed device, a WiFi widget 1908 for specifying WiFi parameter values for the managed device; a proxy widget 1912 for specifying third-party network parameter values for the managed device; a system widget 1914 for specifying TMN parameter values for the managed device; a template selection widget 1910 for selecting a dashboard template, which controls the other widgets available and displayed; a data point widget 1916 for specifying data points to be reported by the managed device; other widgets, or any suitable combination of the foregoing.

FIG. 20 is a flowchart 2000 illustrating creating or modifying a dashboard template for a managed device of an industrial system, according to embodiments of the system described herein. Other embodiments of a method of creating or modifying a dashboard template for a managed device of an industrial system, including variations of processing illustrated by the flowchart 2000, are possible and are intended to fall within the scope of the invention. The processing illustrated by the flowchart 2000 may be provided in an application executed in the transformation layer 102, described elsewhere herein.

In a first step 2002, a dashboard template may be created or modified for a type of managed device, for example, an SI I D, gateway, monitoring device or other type of managed device. The type of managed device may be a product or family of products offered by a vendor. The dashboard template may be created or modified by a user having extensive knowledge (expertise) with respect to the type of managed device for which the dashboard is being created, for example, an employee of the vendor of the device type. In some embodiments, it may be required that the user have a certain type of account, e.g., vendor administrator, customer administrator, developer, user, viewer, etc., for example, in accordance with IEC 62443 requirements. Such account types may be associated with a user using data objects described in more detail elsewhere herein.

Restricting the creation of dashboard templates for a device type to users of a certain user account class may ensure that only dashboards that enable valid configurations of the device type can be created using the dashboard template. For example, the user creating the dashboard template may ensure one or more of the following:

• The allowed dashboard configurations only enable valid configurations of the device type;

• Any parameters (i.e., data points) of the device type for which the setting of values may be required and/or desirable by a customer are made available by the dashboard template (e.g., by a widget or otherwise) for selection for inclusion in dashboards created from the dashboard template;

• Any potential devices (e.g., RFID readers, doorknobs, etc.) that a customer may want to use or control in connection with the managed device are available to be included in a dashboard; and

• Any widgets that a customer may want to include in a dashboard, including any of those described herein, are available for inclusion in a dashboard.

Creating a dashboard template may include specifying the widgets that may be included, and widgets that are required to be included, in a dashboard created from the dashboard template. Widgets may be maintained in a widget library in a database, and may include various types of widgets including, for example: product widgets for specifying a product and a specific instance of the product (e.g., by serial number), a specific managed device for which a dashboard is created; thing widgets for specifying things (e.g., devices) being controlled or otherwise affiliated with a managed device (e.g., an RFID reader, ICS devices, IBCs, fans, pumps, valves, etc.), active control widgets, report widgets, other types of widgets, or any suitable combination of the foregoing.

Following the step 2002 is a step 2004 where approval from a second user, for example, in accordance with IEC 62443 dual approval requirements, may be requested. For example, someone designated to approve all new and modified dashboard templates, may be requested to approve the created or modified dashboard template. Such a user may be required to have a user account of a certain type (e.g., supervisor) to be eligible to approve dashboard template creation. Such dual approval may be desirable to avoid human error and allow even greater expertise to be utilized to weigh-in on the dashboard template before it is finalized.

If approval is denied, processing may be terminated such that the created or modified template is not stored or otherwise persisted, or control may transfer from the step 2004 back to the step 2002 and the user may attempt again to create or modify a dashboard template and submit for approval.

If approval is granted, control transfers from the step 2004 to a step 2006 where the new or modified dashboard template may be stored, for example, in a database of dashboard templates provided by the core services layer 110 of the cloud services 101. Following the step 2006 is a step 2008 where the creation of the template or the one or more changes to the template may be stored in a transaction record as part of a secure audit trail maintained for device templates. For example, a template blockchain may be provided, where the transaction record of the creation of the template or the one or more changes to the template are store as transaction block of the template blockchain. Generally, a secure audit trail may include a value that confirms the data, such as a one-way hash or a digital signature of a known entity. Of course, a blockchain provides such a value because each block is based upon value(s) of previous block(s) and includes a one-way hash that confirms the current block and previous blocks. Note that transaction block utilized for an audit trail may contain at least one data element corresponding to a user that created a dashboard template, to provide a full audit trail, for example by using the user identity as part of the transaction data. FIG. 21 is a flowchart 2100 illustrating creating a dashboard for a managed device of an industrial system, according to embodiments of the system described herein. Other embodiments of creating a dashboard for a managed device of an industrial system, including variations of the processing illustrated by the flowchart 2100, are possible and are intended to fall within the scope of the invention. The processing illustrated by the flowchart 2100 may be provided in an application executed in the transformation layer 102, for example, as part of the same or different application as the application that provides the processing illustrated by the flowchart 2000.

Processing begins at a step 2101 where a managed device is selected for configuration, for example, from a list of managed devices that the user is authorized to configure, for example, based on the account type and the company of the user. For example, it may be required that the user have an account type of "customer dashboard administrator" or the like to configure dashboards for any managed device of a customer. In some embodiments, dashboards may be created only from dashboard templates, which may only be able to be created by a user having an account type authorizing creation of dashboard templates.

Following the step 2101 is a step 2102 where it is determined whether the selected device already has been configured with a dashboard. If not, control transfers from the step 2102 to a step 2104 where a dashboard template may be selected. For example, a list of available dashboard templates for the device type of the selected device may be displayed, and the user may select the dashboard template from the list. The dashboard template may include a plurality of default widgets to include in the dashboard, for example, as illustrated in FIG. 19 for a gateway device.

After performance of the step 2104, or if it is determined in the step 2102 that the selected device is already configured with a dashboard, control transfers to a step 2106 where the dashboard of the device may be modified or created from the selected dashboard template. Following the step 2106 is a test step 2108 where approval from a second person, for example, in accordance with IEC 62443 dual approval requirements, may be requested. For example, someone designated to approve all new and modified dashboards may be requested to approve the new or modified dashboard. If approval is denied, processing may end such that the new or modified profile is not stored or otherwise persisted, or control may return to the step 2106 where the user may attempt again to create or modify a dashboard. In some embodiments, if approval is denied at the step 2108, instead of control returning to the step 2106, the system may exit processing altogether and the user would need to start again at the step 2101.

If approval is obtained at the step 2108, control transfers to a step 2109 where a digital twin of the selected device (i.e., a virtual representation of the selected device as described in more detail elsewhere herein) may be updated, e.g., in the transformation layer 102. Following the step 2109 is a step 2110 where the new or modified dashboard may be stored, for example, in a database of dashboards provided by the core services layer 110 of the cloud services 101. Following the step 2110 is a step 2112 where the creation of the dashboard or the one or more changes to the dashboard may be stored in a secure transaction record as part of a secure audit trail maintained for device dashboards. For example, a template blockchain may be provided, where the transaction record of the creation of the template or the one or more changes to the template are stored as transaction block(s) of the dashboard blockchain using techniques described in more detail elsewhere herein. Generally, a secure audit trail may include a value that confirms the data, such as a one-way hash or a digital signature of a known entity. Of course, a blockchain provides such a value because each block is based upon value(s) of previous block(s) and includes a one-way hash that confirms the current block and previous blocks. Note that transaction block utilized for an audit trail may contain at least one data element corresponding to a user that created a dashboard template, to provide a full audit trail, for example by using the user identity as part of the transaction data. Following the step 2112 is a step 2114, where the dashboard may be deployed to the managed device, as described in more detail elsewhere herein.

FIG. 22 is a flowchart 2200 illustrating remotely configuring a managed device of an industrial system with a dashboard, according to embodiments of the system described herein. Other embodiments of a method of remotely configuring a managed device of an industrial system with a dashboard, including variations of the processing illustrated by the flowchart 2200, are possible and are intended to fall within the scope of the invention.

Processing begins at a first step 2219 where, rather than a user having to initiate deployment of an update to the managed device, the update may be automatically deployed to the manage device, for example in response to receiving a next status heartbeat from the managed device. The status heartbeat of a managed device may be a signal sent from the managed device to the service cloud of a TMN at predefined periodical intervals to inform the services cloud that the managed device is still functional (e.g., healthy, not failed) and communicatively coupled to the services cloud (e.g., "on-line"). Communication between the device and e.g., the services cloud 101 of the CIMZ 1704 may only be initiated by the device itself in instances where the device only wakes up for the heart beats (status, data) or for sending an alarm because otherwise the device is asleep and would not be ready to receive messages. In other instances, the device may wake up in response to receiving a message from the CIMZ 1704.

Following the step 2119 is a step 2220 where, in response to the reception of the status heartbeat, instructions to update the managed device according to the new or modified configuration profile may be transmitted to the device, for example, from the services cloud 101 of the CIMZ 1704 to the control device of the ICZ of which the managed device is a member, e.g., over one or more networks. The control device of the ICZ may transmit the update to the managed device if the managed device is not the control device itself. The foregoing transmission(s) of updates between the cloud services and the control device, and from the control device to the managed device being updated if necessary, may be transmitted securely as described in more detail elsewhere herein.

Following the step 2220 is a step 2221 where the update may be verified by the control device, for example, using the security module 313 of the control device as described in more detail elsewhere herein. If the verification is unsuccessful (not shown), appropriate measures may be taken. Otherwise, following the step 2221 is a step 2222 where the managed device may be updated, and the dashboard deployed. Following the step 2222 is a step 2224 where the control device corresponding to the managed device may securely transmit (e.g., using techniques described elsewhere herein) an acknowledgement of the update being made to the cloud services 101. Following the step 2224 is a step 2226 where a secure transaction record of the updating of the device may be stored, for example, as a transaction block of a blockchain. For example, a dashboard blockchain may be maintained for device dashboards, where each dashboard may be indexed by a dashboard ID, and updates for the dashboard may be securely recorded. The dashboard blockchain may serve as a secure audit trail for device dashboards.

One or more widgets of a dashboard may be configured to allow a user to control the behavior of an industrial device, for example, remotely and in real time using an active control widget. For example, by changing device parameter values using an active control widget, for example, from a device within the CIMZ 1704, a user may remotely control a device of an ICZ in real-time.

FIG. 23 illustrates examples of active control widgets, according to embodiments of the system described herein. Other embodiments of active control widgets, including variations of the examples illustrated in FIG. 23, are possible and are intended to fall within the scope of the invention. The examples of active control widgets include: an SIID widget 2302; a fill control widget 2304; a motor control knob widget 2306 for controlling a motor; and a DSM widget 2308 for setting up a detailed sampling mode (DSM). The fill control widget 2304 may be used to control the filling of containers (e.g., IBCs) of an industrial system.

FIG. 24 is a flowchart 2400 illustrating remotely controlling a managed device of an industrial system, according to embodiments of the system described herein. Other embodiments of remotely controlling a managed device of an industrial system, including variations of the processing illustrated by the flowchart 2400, are possible and are intended to fall within the scope of the invention. Processing begins at a step 2402 where a dashboard of the managed device may be accessed. Following the step 2402 is a step 2406 where one or more inputs to modify one or more parameters of the managed device via a widget of the dashboard may be made. Following the step 2406 is a test step 2407 where it is determined whether any device parameter being modified is a parameter for which additional verification of the user (e.g., a second authentication factor) is required to make a change. The test at the step 2407 may determine, for example, whether a modification will affect one or more predefined behaviors of the device. A list of one or more device parameters that impact system behavior (e.g., safety behavior) may be created, for example, by a qualified administrator during creation of the dashboard template from which the dashboard was created, and the step 2407 may include determining whether any of the parameter values have been modified by the user. In some embodiments, each parameter controllable by the widget may have a field (e.g., flag) indicating whether or not the parameter is a parameter that affects system behavior, and the step 2407 may include determining whether any of those parameter values have been modified.

A widget that includes a parameter whose value controls behavior of a managed device may be an active control widget. In some embodiments, the step 2407 may include determining whether the parameter is part of an active control widget, and requiring verification based on the determination. For example, active control widgets may include: an SI I D widget to control a SI I D of an ICS (described in detail elsewhere herein) to monitor and control other devices of the ICS; a DSM widget to control DSM techniques employed to collect sampling data from industrial equipment, e.g., for Fast Fourier Transformation of application of other mathematical models; a control knob widget for setting any of a variety of parameter values of managed devices; other active control widgets; or any suitable combination of the foregoing.

If it is determined in the step 2407 that one or more predefined device behaviors will be affected, then control transfers to a step 2409 where the user who modified the configuration profile may be verified, for example, using a form of multi-factor authentication, e.g., in accordance with IEC 62443 requirements. It may be desirable to apply multi-factor authentication for certain device behaviors to provide an additional level of security, given the safety issues inherent with some device behaviors, e.g., a response to a temperature or pressure thresholds of a device being reached. For example, the user may have logged into a computer with which the user is executing an application (e.g., from the transformation layer 102) to configure devices, or logged into a sub-system via the computer that allows access to the application. From a previous use of the application or sub-system, the user may have registered and specified a second factor for authentication. For example, during registration, the user may have been prompted to provide a mobile phone number or email address specific to the user. The step 2409 may access the user registration information and determine the second factor (e.g., mobile phone number or email address), and send the user an alphanumeric code (e.g., a one-time PIN) according to the second factor, or prompt the user for which second factor of multiple second factors to use and use the selected second factor. The user may be deemed authenticated if the user enters on the computer (or other device) currently being used the alphanumeric code sent to the user according to the second factor. Other types of multi-factor authentication may be used.

If the user is not verified in the step 2409, control transfers to a step 2411 where the user and/or other persons (e.g., a system administrator) may be notified and the user may not be permitted to apply the modified parameter values to the managed device. In some embodiments, verification attempts may be repeated one or more times to allow the user one or more additional opportunities to be verified before notifying the user and/or other persons and not permitting the user to apply the modified parameter value to the managed device.

If it is determined at the step 2409 that the user is verified, or if it is determined at the step 2407 that verification is not required, then control transfers to a step 2408 where a digital twin of the industrial device may be updated, e.g., in the transformation layer 102. In some embodiments, prior to allowing an updating of the digital twin, approval from a second person, for example, in accordance with IEC 62443 dual approval requirements, may be required (not shown) as described in more detail elsewhere herein. Following the step 2408 is a step 2410 where a secure transaction record of the widget update may be stored, for example, as a transaction block of a blockchain. Note that transaction block utilized for an audit trail may contain at least one data element corresponding to a user that executed the remote control, to provide a full audit trail, for example by using the user(s) identity as part of the transaction data. Following the step 2410 is a step 2412 where the updates of the digital twin may be transmitted to the device, for example, securely as described in detail elsewhere herein.

Following the step 2412 is a step 2418 where the contents of the update communication may be verified, for example, by a control device of the ICZ corresponding to the device being updated (which may be the control device itself), e.g., using the security module 313 of the control device as described in more detail elsewhere herein. If the verification is unsuccessful (not shown), appropriate measures may be taken. Otherwise, following the step 2418 is a step 2419 where the device may be updated. Following the step 2419 is a step 2420 where the control device corresponding to the updated device may securely transmit (e.g., using techniques described elsewhere herein) an acknowledgement of the update being made to the cloud services 101. Following the step 2420 is a step 2421 where a secure transaction record of the updating of the device may be stored, for example, as a transaction block of a blockchain.

It may be desirable to define workflows associated with the management of an industrial system using, for example, a business process modeling tool or similar. For example, it may be desirable to define a workflow that utilize a TMN. It further may be desirable to integrate the defined a workflow with the capabilities of the TMN.

FIG. 25 is a block diagram illustrating a system 2500 for managing a workflow using an industrial management system, according to embodiments of the system described herein. Other embodiments of a system for managing a workflow on an industrial management system, including variations of the system 2500, are possible and are intended to fall within the scope of the invention. The system 2500 may be configured to enable the integration between a workflow and management of an industrial system. The system 2500 may include a workflow engine 2502, a workflow manager 2510 and a workflow engine API 2508 that provides a programming interface to the workflow engine 2502 for the workflow manager 2510. The workflow engine 2502 may be implemented according to a variety of business modeling technologies, including graphical modeling technologies, e.g., Business Process Model and Notation (BPMN) technology promulgated by the Object Management Group (OMG). The workflow engine 2502 may be configured to enable the creation and execution of task objects, including industrial task objects (ITOs) 2504 and non- ITOs 2506, where ITOs define tasks specific to the management of an industrial system and non-ITOs define tasks not specific to the management of the management of the industrial system, for example, common or generic tasks of the workflow engine 2502, administrative tasks or other tasks that do not require execution by any elements of an industrial system. The ITOs may be considered the building blocks of integration between a workflow and a TMN of an industrial system, where the ITOs define tasks in the domain of the workflow engine 2502 that specify and cause execution of functionality in the TMN, for example, a TMN 100'.

The workflow manager 2510 may be implemented as a component of a core services layer 110' of the TMN 100', where the core services layer 110' may be a variation of the core services layer 110. The workflow manager 2510 may include task management logic (TML) 2512, communication logic 2514 and data management logic (DML) 2516. The TML 2512 may be configured to control the execution of ITOs 2504. The communication logic 2514 may be configured to control the handling and dispatch of events between the workflow manager 2510 and other components of the system 2500, and the DML 2516 may configured to control the storing and retrieval of management data 2518.

The core services layer 110' may include transaction services 112' and security services 113', which may be variations of transaction services 112 and security services 113, respectively. The transaction services 112' may include a TMN register 2520, a workflow register 2522 and a dashboard register 2524. The TMN register 2520 may be used to store secure records of TMN activity, including device activity on the TMN, such as, for example, information (e.g., status information) received from devices on the TMN 100', for example, as described in more detail herein. The TMN register also may store TMN transactions for TMN activity that is not specific to device activity, but still related to management of the TMN. The TMN register 2520 may serve as a secure audit trail for management of the TMN 100', where the audit trail may be implemented as a blockchain including blocks for activity on the TMN, including changes to device state and other activity described in more detail herein.

The workflow registers 2522 may be used to store secure records/data of workflows defined on the system 2500, e.g., using the workflow engine 2502, including ITOs and non-ITOs included therein, and any changes to the workflows. The workflow registers 2522 may serve as a secure audit trail for workflows, where the audit trail may be implemented as a blockchain including blocks for the creation and any changes to the workflows, as described in more detail elsewhere herein.

The dashboard registers 2524 may be used to store secure records of dashboards defined on the system 2500, and any changes to the dashboards. The dashboard registers 2524 may serve as a secure audit trail for dashboards, where the audit trail may be implemented as a blockchain including blocks for the creation and any changes to the dashboards, as described in more detail elsewhere herein.

The security services 113' may include managed device (MD) validation logic 2526 for validating transactions concerning managed device activity on the TMN 100', and workflow validation logic 2528 for validating activity that is not specific to managed device activity on the TMN 100', as described in more detail elsewhere herein. MD validation logic 2526 and the workflow validation logic 2528 may utilize the secure credential services 117 to perform validation, for example, as described in more detail elsewhere herein.

FIG. 26 is a block diagram illustrating a workflow 2600 defined using a workflow engine, according to embodiments of the system described herein. Other embodiments of a workflow defined using a workflow engine, including variations of the workflow 2600, are possible and are intended to fall within the scope of the invention. In the example of FIG. 26, the workflow 2600 is illustrated using BPMN, but other business modeling technologies may be employed. A key 2650 shows the meanings of the process model symbols. The workflow 2600 may be a process created for access management of a gate at a company (Hauler Company, Driver, HR Administration and Reception at the Gate) in the example of FIG. 26.

The workflow 2600 is illustrated using a BPMN pool 2602 including a plurality of lanes 2604, 2606, 2608, 2610, where each lane represents an entity involved in the process, e.g., Hauler Company., a driver, an HR Admin and Reception, respectively. Each entity may correspond to a data object of a TMN described in more detail elsewhere herein. A plurality of tasks 2601a-h are illustrated, each task corresponding to a lane of the entity associated with performance of the task. One or more of the tasks may be ITOs and one or more may be non- ITOs. The operation of the workflow 2600 is illustrated by arrowed lines connected to one or more tasks in combination with other symbols described in the key 2650.

Operation of the workflow 2600 starts with execution of the task 2601a associated with Hauler Company, and then proceeds to execution of the task 2601b, after which operation pauses. At some point after the task 2601b, if a condition 2616 is met, the task 2601c is executed, followed by execution of the task 2601d. After execution of the task 2601d, the process forks into two paths. On a first path, the task 2601e is executed. On a second path, the task 2601f is executed followed by execution of the task 2601h. At a point in time after execution of the task 2601e, but before execution of the task 2601h, the task 2601g is executed, and the two paths are re-joined, and operation completes.

In some embodiments, the workflow 2600 requires execution of one or more tasks, or portions thereof, by the workflow manager 2510, which is illustrated in FIG. 26 by the arrowed dashed lines. That is, each of the tasks 2601b-h, or a portion thereof, may require execution by the workflow manager 2510, as described in more detail elsewhere herein.

While not illustrated as tasks in FIG. 26, processing elements 2612a, 2612b, 2616, 2614a, 2614b, 2618a, 2618b may be considered tasks, for example, non-ITOs, that may be executed by the workflow engine 2502 independent of the workflow manager 2510.

FIG. TJ is a flowchart 2700 illustrating managing a workflow on an industrial management system, according to embodiments of the system described herein. Other embodiments of managing a workflow on an industrial management system, including variations of processing illustrated by the flowchart 2700, are possible and are intended to fall within the scope of the invention.

Processing begins at a step 2702 where a workflow may be defined, for example, using the workflow engine 2502. Defining the workflow may include defining the process to include a plurality of tasks, including one or more ITOs (e.g., the ITOs 2504) and one or more non-ITOs (e.g., the non-ITOs 2506). The ITOs may include a plurality of types of ITOs, including managed device (MD) ITOs, user device (UD) ITOs and logical ITOs. An MD ITO is an ITO that requires interaction with a managed device of an industrial system, for example, of a TMN of the industrial system. It should be appreciated that a control device as described herein may be a managed device. A UD ITO is an ITO that requires interaction with a user device of an industrial system. UD ITOs and MD ITOs each may be considered device ITOs, i.e., ITOs that require interaction with a device (e.g., user device or managed device) of an industrial system. A logical ITO is an ITO that does not require interaction with a specific device of the industrial system.

Following the step 2702 is a step 2704 where the workflow may be securely registered. For example, the workflow may be stored as a secure record in the workflow register 2522, for example, as a transaction block of a blockchain, as shown elsewhere herein. In some embodiments, the workflow may be stored as a smart contract, and the workflow may have a unique workflow ID, e.g., a smart contract Id (SCID). The secure record (e.g., smart contract) of the workflow may include each task of the workflow, including ITOs and non-ITOs. Each task may be specified by a workflow task ID, which may be included in the secure record. In addition to being securely registered, a data object of the workflow may be stored in the management database 2518, where the object may use the SCID to specify the workflow and the workflow task IDs of the tasks to specify the tasks. In some embodiments, in addition to having a workflow task ID, an MD ITO may include a thing ID (TID) specifying the managed device for which the ITO specifies interaction, which may be included in the secure record and data object of the workflow that includes the MD ITO. An MD ITO may be identified by a combination of a workflow task ID and TID.

A UD ITO may include a user device ID UDID, e.g., an international mobile equipment identity (IMEI), specifying the user device for which the ITO specifies interaction, which may be included in the secure record and data object of the workflow that includes the UD ITO. A UD ITO may be identified by a combination of a workflow task ID and UDID. As is described in more detail herein, TIDs and UDIDs may be used to distinguish between MD ITOs, UD ITOs and logical ITOs.

Following the step 2704 is a step 2706, which may be at a time independent of, and perhaps much later than, performance of the step 2704. At the step 2706, the workflow may be initiated. For example, the communication logic 2514 of the workflow manager 2510 may call the workflow engine 2502, specifying the SCID of the workflow. Following the step 2706 is a test step 2710 where a next task of the workflow is determined. On a first pass through step 2710, the next task is the first task of the workflow. The workflow engine 2502 may determine the next task. If there is no next task (all tasks have been processed), then processing is complete. Otherwise, control transfers from the test step 2710 to a test step 2712 where it may be determined, e.g., by the workflow engine 2502, whether the next task is an ITO or a non-ITO. If it is determined at the step 2712 that the next task is a non-ITO, the task may be executed by the workflow engine 2502 independently from the workflow manager 2510 at a step 2714.

If it is determined at the step 2712 that the task is an ITO, then control transfers to a test step 2716 where it may be determined (e.g., by the TML 2512) whether the ITO is an MD ITO, as opposed to a UD ITO or logical ITO. The test at the step 2716 may be performed by determining whether there is a TID specified by the task (i.e., by the ITO). If the ITO is an MD ITO (e.g., if the task includes a TID), then control transfers to a collection of steps 2718 to perform MD processing. Otherwise, if it is determined at the test step 2716 that the ITO is not an MD ITO, i.e., that the ITO is a UD ITO or logical ITO, then control transfers to a collection of steps 2720 to perform non-MD processing.

The MD processing collection of steps 2718 may include activating the MD transaction validation logic 2526 in a step 2728 so that the MD transaction validation logic 2526 may be applied when needed as described in more detail elsewhere herein. In some embodiments, depending on the task, an MD action may be initiated in a step 2730, for example, a secure communication may be sent from the core services layer 110' to the managed device as described in more detail herein. In some embodiments, depending on the task, no MD action may be initiated, but rather the processing waits for an event, for example, receiving a secure communication corresponding to the managed device, for example, from the managed device itself or from a control device corresponding to the managed device.

Following the step 2728 or the step 2730 is a step 2732 where a secure communication corresponding to the MD may be received, which may include a secure transaction record as described in more detail elsewhere, for example, a blockchain record of the status of the managed device. Following the step 2732 is a test step 2734 where the secure communication (e.g., secure transaction record) may be validated, for example, by the previously activated MD transaction validation logic 2526, e.g., based on security credentials corresponding to the TID of the managed device, using techniques described in more detail elsewhere herein.

If the secure communication is determined to be invalid, then control transfers to a step 2738 where invalid-transaction processing may be performed (e.g., notify user, notify administrator, etc.). Otherwise, control transfers from the step 2734 to a step 2736 where a secure transaction record of the transaction may be stored, for example, as a block of a blockchain in the TMN register 2520. Following the step 2736 is a step 2739 where one or more data objects resulting from the transaction may be stored, for example, as management data 2518 by the DML 2516. After performance of the step 2739, control transfers back to the step 2710, described above, where the workflow engine 2502 determines a next task. If it is determined that there is not a next task, performance of the workflow may be deemed complete and the workflow engine 2502 may report the completion of the task to the workflow manager 2510.

If it is determined at the test step 2716 that the task is a not an MD ITO, control transfers to a step 2724 of the non-MD processing 2720 where it is determined if the ITO is a valid ITO. For example, the workflow validation logic 2528 may be configured to determine whether the ITO is registered as part of a workflow corresponding to the processing illustrated by the flowchart 2700. The workflow task ID of the ITO may be compared to the workflow task IDs listed in the definition of the workflows securely stored in the workflow register 2522. If the workflow task ID is listed, then the ITO may be considered validated.

If it determined at the step 2724 that the ITO is invalid, then control transfers to a step 2722 where an inva lid-ITO process may be performed (e.g., notify user, notify administrator, etc.). Otherwise, control transfers to a step 2726 where the task is completed. If the ITO is a UD ITO, completing the task may include one or more communications with a user device. Following the step 2726 is the step 2739, described above, where one or more data objects resulting from the task being performed may be stored, for example, as management data by the DML 2516. After the performance of the step 2739, control transfers back to the step 2710, described above, for another iteration.

Various embodiments discussed herein may be combined with each other in appropriate combinations in connection with the system described herein. Additionally, in some instances, the order of steps in the flowcharts, flow diagrams and/or described flow processing may be modified, where appropriate. Further, various aspects of the system described herein may be implemented using software, firmware, hardware, a combination of software, firmware and/or hardware and/or other computer-implemented modules or devices having the described features and performing the described functions.

Software implementations of the system described herein may include executable code that is stored on one or more computer readable media and executed by one or more processors. Each of the one or more computer readable media may be non-transitory and include a computer hard drive, ROM, RAM, flash memory, portable computer storage media such as a CD-ROM, a DVD-ROM, a flash drive, an SD card and/or other drive with, for example, a universal serial bus (USB) interface, and/or any other appropriate tangible or non-transitory computer readable medium or computer memory on which executable code may be stored and executed by a processor. In some embodiments of the system described herein, one or more computer media may be, include, or be included within a security module (which may include a TPM or SE) of a server, gateway, monitoring device, user device or other component of a TMN, as described in more detail elsewhere herein, providing a secure environment for storing, executing and updating software implementations of the system described herein. The system described herein may be used in connection with any appropriate operating system.

Other embodiments of the system described herein will be apparent to those skilled in the art from a consideration of the specification or practice of the system disclosed herein. It is intended that the specification and examples be considered as exemplary only, with the true scope and spirit of the invention being indicated by the following claims.

Claims

What is claimed is:

1. A distributed industrial control system, comprising: a core industrial management site having one or more components for remotely managing components of the industrial control system through a network; and a plurality of industrial control sites that communicate with the core industrial management site, each of the industrial control sites including at least one control device that provides communication with the core industrial management site via the network only through the at least one control device, each of the control devices including a security module that facilitates secure communication by the at least one control device using data stored in the security module.

2. The distributed industrial control system of claim 1, wherein the security module has embedded therein one or more private credentials that are inaccessible from outside the security module.

3. The distributed industrial control system of claim 2, wherein the one or more private credentials are used to exchange symmetric encryption keys with the core industrial management site to facilitate encrypted communication with the core industrial management site.

4. The distributed industrial control system of claim 2, wherein the one or more private credentials validates a source of data that is transmitted to the core industrial management site.

5. The distributed industrial control system of claim 2, wherein data transmitted to the core industrial management site includes blockchain data that is generated using the one or more private credentials.

6. The distributed industrial control system of claim 1, wherein the security module is a trusted platform module.

7. The distributed industrial control system of claim 1, wherein the network is a non-proprietary network.

8. The distributed industrial control system of claim 7, wherein the network is the Internet.

9. The distributed industrial control system of claim 1, wherein the core industrial management site is at a first physical site, and the at least one of the industrial control sites is at a second physical site that is geographically separated from the first physical site.

10. The distributed industrial control system of claim 9, wherein the at least one industrial control site provides all cyber security relevant functions of the industrial control zone site.

11. The distributed industrial control system of claim 1, wherein the at least one industrial control site includes at least one of: a secure industrial control system interface device, an industrial control system controller, an industrial control system device, an industrial control system supervisor, a gateway, a sensor devices, and/or a monitoring device.

12. The distributed industrial control system of claim 1, wherein the at least one industrial control site provides an alarm in response to attempted intrusion.

13. The distributed industrial control system of claim 12, wherein the attempted intrusion is physical intrusion that is detected using at least one of: an ambient light sensor or a movement sensor.

14. The distributed industrial control system of claim 12, wherein the attempted intrusion is detected based on detecting improper protocols and/or improper parameters being provided to the at least one industrial control site.

15. The distributed industrial control system of claim 14, wherein the improper protocols and/or improper parameters are provided by an unauthorized device added by a wired interface of the at least one industrial control site.

16. The distributed industrial control system of claim 14, wherein the improper protocols and/or improper parameters are provided by an unauthorized device accessing a wireless interface of the at least one industrial control site.

17. The distributed industrial control system of claim 16, wherein the wireless interface of the at least one industrial control site is subject to at least one of: a denial of service attack or a collision attack.

18. The distributed industrial control system of claim 1, wherein at least some components of the at least one industrial control site include at least one of: machine readable QRC labels and RFID UHF labels.

19. The distributed industrial control system of claim 18, wherein the labels are used for at least one of: automation and installation for the at least one industrial control site.

20. The distributed industrial control system of claim 1, wherein components of the at least one industrial control site are monitored at the core industrial management site using widgets on a configurable dashboard.

21. The distributed industrial control system of claim 1, wherein components of the at least one industrial control site are specified using a workflow that includes tasks that actuate components of and/or use data from the at least one industrial control site.

22. The distributed industrial control system of claim 21, wherein the workflow includes risks, threats and vulnerabilities related to the components of the at least one industrial control site.

23. The distributed industrial control system of claim 22, wherein the workflow includes alarms and messages related to the components of the at least one industrial control site.

24. A method of integrating a plurality of industrial control sites into a distributed industrial control system according to any of the preceding claims, comprising: each of the industrial control sites automatically registering with the distributed industrial control system upon being powered up.

25. A data processing apparatus comprising means for carrying out the steps of the method of claim 24.

26. A method of configuring an industrial control site that communicates with a core industrial management site via a network only through at least one control device having a security module that facilitates secure communication by the control device using data stored in the security module, the method comprising: configuring an interoperability lab having components that correspond to components of the industrial control site and the core industrial management site; testing the interoperability lab to detect cyber risks and vulnerabilities; adjusting components and/or software of the interoperability lab to address the cyber risks and vulnerabilities; and adjusting components and/or software of the industrial control site that correspond to the components and/or software of the interoperability lab that were adjusted to address the cyber risks and vulnerabilities.

27. The method of claim 26, wherein adjusting components includes flashing software, personalization of devices, secure download of keys and credentials for the security module, and creating security objects for the security module.

28. The method of claim 26, wherein detecting cyber risks and vulnerabilities includes production tests of printed circuit board assemblies, production tests of components of the interoperability lab, and examining production data.

29. The method of claim 26, wherein the industrial control site automatically registers with the core industrial management site in connection with installation of the industrial control site.

30. The method of claim 29, wherein following automatic registration, the core industrial management site validates if elements of a configurable dashboard of the core industrial management site correspond to components of the industrial control site.

31. The method of claim 30, wherein alarms are provided in response to a component of the industrial control site not having corresponding one of the elements of the configurable dashboard.

32. The method of claim 26, wherein adjusting components of the industrial control site includes downloading software to at least one of the components from the core industrial management site and wherein, prior to downloading, the core industrial management site confirms that the software is provided by an authorized design center.

33. The method of claim 32, wherein the software is provided as part of an electronic inventory at the core industrial management site.

34. The method of claim 32, wherein the software is digitally signed by an entity of the core industrial management site.

35. The method of claim 34, wherein the core industrial management site includes a public key infrastructure to manage a public/private key pair used to digitally sign the software.

36. The method of claim 32, wherein the software is downloaded using a wireless interface of the industrial control site.

37. The method of claim 26, wherein at least some configuration changes require approval of two users.

38. The method of claim 26, wherein at least some configuration changes are logged using a blockchain.

39. The method of claim 26, wherein the interoperability lab includes a cloud, a transformation layer, and a core services layer that provide simulation of the core industrial management site.

40. The method of claim 26, wherein the interoperability lab includes a simulation of a mobile network.

41. The method of claim 26, wherein the cyber risks and vulnerabilities are provided by test cases that are developed according to industry standards.

42. The method of claim 41, wherein test results are logged using blockchain technology.

43. A data processing apparatus comprising means for carrying out the steps of the method of any of claims 26-42.

142

44. A method of configuring a dashboard for an industrial control system, comprising: obtaining a listing of one or more dashboard templates that define, for each industrial control device type, a plurality of configuration parameters and, for each configuration parameter, one or more potential values thereof; selecting a particular one of the dashboard templates; defining a dashboard of the industrial control system by selecting, for each control device of the particular one of the dashboard templates, values for corresponding ones of the configuration parameters; generating configuration data that corresponds to the particular one of the dashboard templates and selected values for the corresponding ones of the configuration parameters; and storing the configuration data along with a value that confirms the configuration data as part of a secure audit trail for configuration of the dashboard.

45. The method of claim 44, wherein the secure audit trail is implemented as a blockchain and the configuration data is recorded as a first transaction block of the blockchain.

46. The method of claim 45, further comprising: changing a value of one of the configurations parameters of the dashboard to produce revised configuration data; and storing the revised configuration data as a second transaction block of the blockchain that is based on the first transaction block of the blockchain.

47. The method of claim 44, further comprising: after defining the dashboard, receiving a heartbeat communication corresponding to the one of the industrial control devices of the dashboard; and automatically deploying the dashboard in response to the heartbeat communication.

143

48. The method of claim 44, further comprising: updating a virtual representation of at least one of the industrial control devices of the particular one of the dashboard templates.

49. The method of claim 44, wherein a first user defines the dashboard and a second user, different from the first user, is required to approve the dashboard prior to storing the configuration data.

50. The method of claim 44, further comprising: creating dashboard templates by defining particular ones of the industrial control devices thereon including corresponding configuration parameters and the one or more potential values thereof.

51. The method of claim 50, wherein a first user creates the dashboard templates and a second user, different from the first user, is required to approve the dashboard templates prior to the dashboard templates being used to create dashboards.

52. A data processing apparatus comprising means for carrying out the steps of the method of any of claims 44-51.

53. A method of controlling a managed device of an industrial control system, comprising: receiving an input from a user via a graphical control element that controls one or more behaviors of the managed device, wherein the input specifies a change to a parameter value for the managed device that modifies a behavior of the managed device; sending a secure communication to the managed device to change the parameter value; and storing a record of the secure communication and the parameter value along with a value that confirms the record as part of a secure audit trail for configuration of the managed device.

144

54. The method of claim 53, wherein the audit trail is implemented as a blockchain and the record is part of a first transaction block of the blockchain.

55. The method of claim 54, further comprising: receiving an acknowledgement communication including acknowledgement information about the parameter value having been changed; and storing the acknowledgement information as a second transaction block of the blockchain that is based on the first transaction block of the blockchain.

56. The method of claim 53, further comprising: authenticating the user based on a first form of authentication; determining that the change in the parameter value will modify the behavior of the managed device; and in response to the change in the parameter value modifying the behavior of the managed device, requiring the user to provide a second form of authentication different from the first form.

57. The method of claim 56, further comprising: requiring approval of an additional user before allowing the change in parameter value to be applied to the managed device.

58. The method of claim 53, wherein the input is entered on a second device that is remotely coupled to the managed device.

59. The method of claim 58, wherein the graphical control element is part of a graphical dashboard, displayed on the second device, for controlling the first device.

60. The method of claim 59, wherein the graphical dashboard controls behavior of the first device in real-time.

145

61. A data processing apparatus comprising means for carrying out the steps of the method of any of claims 53-60.

62. A method of applying business logic to an industrial control system, comprising: defining a workflow that includes a first subset of tasks that actuate components of and/or use data from the industrial control system and a second subset of tasks that are independent of the industrial control system; storing the workflow definition in a secure workflow register; initiating execution of the workflow; determining a next task of the workflow to execute; if the next task is from the first subset, performing a validation associated with the next task based on the workflow definition, including accessing the workflow definition in the workflow register; and completing performance of the next task if the validation is successful.

63. The method of claim 62, wherein the first subset of tasks includes a first type of task that requires interaction with a managed device of the industrial control system and a second type of task that requires interaction with a user device that interacts with the industrial control system.

64. The method of claim 63, wherein, in response to the next task being the first type of task, transaction validation logic is applied to a transaction record associated with the next task.

65. The method of claim 62, wherein completing the performance of the next task includes storing a transaction record associated with performance of the next task in a secure transaction register.

66. The method of claim 65, wherein the workflow register is a first blockchain and the secure transaction register is a second blockchain different from the first blockchain.

146

67. The method of claim 62, wherein performing the validation includes verifying that the next task is registered as part of the workflow definition.

68. The method of claim 62, wherein a business modeling component defines the workflow and wherein an industrial system management component communicates with the business modeling component to initiate execution of the workflow and to determine the next task of the workflow.

69. The method of claim 68, further comprising: the industrial system management component communicating to the business modeling component when performance of the next task is complete.

70. The method of claim 68, wherein the business modeling component includes software that graphically represents the workflow.

71. The method of claim 68, wherein the software defines and graphically represents the workflow in accordance with Business Process Model and Notation (BPMN) technology.

72. The system of claim 62, wherein the workflow definition is stored in a secure workflow register as a smart contract.

73. The system of claim 62, wherein the secure business process register is a blockchain and the workflow definition is stored as a transaction block of the blockchain.

74. A data processing apparatus comprising means for carrying out the steps of the method of any of claims 62-73.

147