This disclosure relates to communication in an industrial environment. This disclosure also relates to security feature provisioning in an industrial environment.
Rapid advances in sensors, control systems, and manufacturing techniques have led to the worldwide adoption of automated manufacturing techniques for every imaginable product. The manufacturing techniques include automation and process control, and operate in a variety of settings. Personnel, security, and resource availability may vary from site to site.
Communication within and across manufacturing or industrial environments can be difficult due to extreme temperatures, variant levels of dust, moisture, machine noise, chemical hazards, and more. Injected noise in an industrial environment may adversely impact communication reliability and quality in the environment.
An environment 100 may include any number of nodes. The exemplary industrial environment 100 in
The manufacturing nodes 111-117 are positioned along the manufacturing line 110. The manufacturing nodes 111-117 may be implemented as any machinery, robotics, actuators, tooling, or other electronics that participate in an assembly (or de-assembly) process along the manufacturing line 110. The manufacturing nodes 111-117 are communicatively linked to control nodes, through which the manufacturing nodes 111-117 receive control signals that monitor, guide, or control the manufacturing nodes 111-117. In
The sensors 141-151 may monitor various locations in the industrial environment 100. In
The industrial environment 100 supports multiple communication links between any of the nodes within and/or outside the industrial environment 100. The multiple communication links may provide redundancy or failover capabilities between the communicating nodes. As one such example shown in
A node in the industrial environment 100 may include a communication interface that supports multiple communication links with other nodes within or outside of the industrial environment 100. A communication interface may be configured to communicate according to one or more communication modes, e.g., according to various communication techniques, standards, protocols, or across various networks or topologies. The communication interface may support communication according to particular quality-of-service (QoS) techniques, encoding formats, through various physical (PHY) interfaces, and more. For example, a communication interface may communicate according to any of the following network technologies, topologies, mediums, protocols, or standards: Ethernet including Industrial Ethernet, any open or proprietary industrial communication protocols, cable (e.g. DOCSIS), DSL, Multimedia over Coax Alliance (MoCA), power line (e.g. HomePlug AV), Ethernet Passive Optical Network (EPON), Gigabit Passive Optical Network (GPON), any number of cellular standards (e.g., 2G, 3G, Universal Mobile Telecommunications System (UMTS), GSM (R) Association, Long Term Evolution (LTE) (TM), or more), WiFi (including 802.11 a/b/g/n/ac), WiMAX, Bluetooth, WiGig (e.g., 802.11 ad), and any other wired or wireless technology or protocol. The control node 121, as one example, includes the communication interface 160.
The control node 121 may include security logic 161 for security feature provisioning and/or assignment within the environment 100. The security logic 161 may include one or more processors 164 and memory 166. Memory 166 may include security parameters 167 for implementation of security features. Memory 166 may include topology data 168 for determination of topological regions and hardware profiles 169 for determination of applicable security features for given hardware functions. Additionally or alternatively, memory 166 may include a security feature decision (SFD) matrix 170, which may be used to make security feature implementation decisions based on factors, such as, topological region, function, and/or other factors as described below. The security logic may determine features that may be used to implement security at a desired level. The features implemented may vary among nodes at a given security level. For example, various node functions may use different security features to achieve a specified security level. In some cases, a sensor may lack a user interface. The sensor may not implement security features related to securing human interface devices (HIDs).
In some implementations, security level 269 may be dependent on level 259 and the security feature 252. Similarly, level 279 may be dependent on level 269 and transitively dependent on security level 259. Level 299 may be dependent on 289, which may depend on 279. Some levels may be independent of other levels. For example, security level 249 may be independent of security levels 259, 269, 279, and 289. For example, security features 242, 244, 246, 248 may include physical security features such as tamper evident chassis, tamper resistant components, sealed compartments, self-destruct modules, and/or other physical security features. Security level 289 may include features such as software or hardware interfaces that may not rely on physical security features. Security level 299 may depend on security levels 249 and 289. For example, security level 299 may include a feature that is complaint with a standard that depends on physical security feature (e.g. from security level 249) and software and hardware interface security features (e.g. from security level 289).
Various security features may be implemented. For example, a security feature may include encryption at L2 or L3 for nodes associated with a given controller or function. Another example may include locational security such as providing a power-over-ethernet (PoE) trickle such that nodes may detect being unplugged from a network when powered down and/or in various power modes. Additionally or alternatively, authentication schemes may be implemented as a security feature. For example, nodes may store a signature (e.g. media access control (MAC) address), pass key, or other data that may be mirrored on local databases. This signature and local storage pair may be used to ensure unauthorized nodes (e.g. cloned or counterfeit nodes) are not given access to the environment 100. In some cases, nodes may be provided keys via one-time-provisioning (OTP). For example, in a closed-loop security scheme for a video monitoring system OTP key provision may ensure data collected by the system is not intercepted by an unauthorized node.
Security features and security levels may be implemented in various nodes of the environment 100. The topology of the environment 100 may be mapped. For example, the locations and/or connectivity of the nodes may be monitored or recorded.
Additionally or alternatively, the connectivity map of the network may be used as a topology map. For example, nodes associated with a control node, network switch, access point, or other node may be associated with a topological region. In some cases, internet protocol (IP) address networks and subnets may be used to establish topology.
In some cases, the network topology may be determined based on collected location data. For example, connectivity to a specific access point may establish a physical location. Relative signal strengths from multiple access points or other transmitters may also be used to determine location. In some cases, connectivity to a physical port with a known location may be used to determine location. In some cases, a node, may broadcast a signal and relative received signal strengths at multiple known locations may be used to determine the position of the node. Geolocation systems, such as global positioning system (GPS), Galileo, or other geolocation systems, may be used to determine location.
Based on the network topology, security levels and features may be applied to nodes. Differing topological regions may have different associated security preferences. For example, for an assembly line within a manufacturing plant, multiple security regions may be defined. A first security level may be implemented for the beginning of the assembly line, and a second security level may be implemented for at positions performing sensitive operations. For example, a second security level may be implemented on a computer controlled machining station stores customer product designs to help reduce the chances of theft of the designs.
In some cases, the network topology may determine a maximum security level for a given topological region. For example, to communicate over encrypted data channels, a node may include security keys and/or certificates. In some cases, nodes may be lost or stolen and may compromise the encryption of some data channels. In some cases, nodes in unsecure areas (e.g. areas of unrestricted access, third-party traffic, and/or other unsecure areas) may have increased vulnerability to theft. In response, nodes in unsecure areas may not include some security keys and/or certificates. The nodes may not be able to support certain encryption schemes without the associated security keys and/or certificates. Lacking support of some security features may cap the security levels that can be met by the node. In some cases, the network topology may determine a minimum security level for a given topological region. In some cases, nodes in a given topological region may handle sensitive information and/or materials, minimum security levels for these nodes may reduce the chance of data breaches.
The differing preferences may be used to determine security features for nodes.
As another example dimension of the SFD matrix 170 is the function dimension 330. A node may execute one or more functions, examples of which are labeled 331-339. For example, the functions 331-339 may include monitoring, manufacturing, control, transport, sensing, sampling, data communication, and/or other functions.
The example SFD matrix 170 shows 7 possible regions and 9 possible functions. However, other numbers of possible functions and topological regions are possible. The number of possibilities may be determined by the network and the operational environment of the network. The axis 350 shows the security feature 351-358 for which an implementation decision is made using the SFD matrix 170. For the security feature 351-358 and the topological 310 and functional 330 inputs, the grid point may include an implementation decision. For example, the grid point 370 corresponds to the topological region 314, the function 335, and the security feature 353. For example, topological region 314 may implement security feature 353 and the security feature 353 may be applicable to function 335. In this case, grid point 370 may indicate implementation of security feature 353. In another example, topological region 314 may implement security feature 353 and security feature 353 may not apply to function 335. In this case, grid point 370 may indicate that security feature 353 is not implemented. In yet another example, security feature 353 may not be implemented for topological region 314. In this case, grid point 370 may indicate that security feature 353 is not implemented. Additionally or alternatively robustness and redundancy features and preferences may be considered via the SFD matrix 170.
In an example case 380, gird point 381 may correspond to a positive implementation decision for security feature 382, e.g. advanced encryption standard (AES) 256-bit encryption at topological region 383 and for a given function 399 (e.g., video streaming). Grid point 384 may correspond to the same security feature 382, but may correspond to a different topological region 385. Grid point 384 may indication a negative implementation decision for AES 256-bit encryption. Grid points 387 and 388 may correspond to security feature 386, AES 64-bit encryption, at topological regions 383 and 385, respectively. Conversely, 387 and 388 may indicate negative and positive decisions. This may correspond to AES 256-bit encryption being used in topological region 383, e.g., a physically unsecure location, and 64-bit encryption being used in topological region 385, e.g., a physically secure region.
Additionally or alternatively, the security features implemented may depend on network layers. For example, in an industrial environment, a node may access and/or transmit data encapsulated a various network layers (e.g., MAC layer, transport layer, application layer, PHY layer, or other layer. Network security feature virtualization may be mapped to the different layers. In some implementations, the network layers, may be mapped to positions on an axis (e.g., an existing or additional axis) of the grid of SFD matrix 170.
Additionally or alternatively, the size of a node may be considered in security provisioning. For example, nodes of small physical size may be more easily stolen. Thus, sensitive data, such as network encryption keys, may not be preferably stored on small nodes, which could potentially be concealed in a pocket, bag, or other container. In some cases, some nodes may not support a given security feature because the data and of logic to support that feature may not be preferred for nodes of a given size. Size considerations may be mapped to dimensions of the SFD matrix 170. For example, classification along the size axis may correspond to equipment involved in moving the node. For example, a low classification may be given to nodes that may be carried by a person. Higher classifications may be given to nodes that can be moved via forklift and/or are immobile. Other features such as mobility, value, criticality (e.g. an element needed for proper operation of an assembly line) may be used.
Additionally or alternatively, matrix dimensions, e.g. topology and function, may be added or eliminated in some implementations. In some cases, the SFD matrix 170 may take a 2-dimensional, 3-dimensional, and/or n-dimensional form. The dimensions may represent the inputs to the matrix (e.g., topology, function, size, and/or other factors) and the security features for which implementation decisions are being made. The grid points indicate, or in some cases mandate, positive or negative implementation decisions for the security feature.
In various implementations, the SFD logic 400 may apply SFD matrix 170 in making implementation determinations for security features.
The SFD logic 400 may then direct the node to implement the determined security features (410). In some cases, the SFD logic 400 may support the implementation of the features at the node. For example, the SFD logic 400 may provide (or direct the provision of) software to the node to support a feature. In various cases, a hardware module (e.g. a security co-processor, a storage expansion, secure memory, sensors, and/or other hardware module) may be added to the node to support a feature. This hardware addition may be performed by an operator or an automated hardware provisioning node (e.g. a robot capable of pugging a module into a slot). For example, a node lacking software for an encryption feature may be provided such software so that the node may implement the encryption feature. Additionally or alternatively, the SFD logic 400 may direct the node to remove one or more security features active on the node (412). For example, the node may be transitioning from a security level above the maximum level for the determined topology. The SFD logic may direct the node to removal security features associated with levels above the maximum security level. The SFD logic 400 may support the removal of security features. For example, the SFD logic 400 may direct the node to delete locally stored network keys, uninstall software, or to delete sensitive data that may be at risk within the determined topology. Similarly, hardware modules may be removed from the node to reduce security feature capabilities.
In some implementations, nodes may be provisioned based on tasks to be completed. For example, an automated manufacturing facility may receive an order for a number of units of a given product. To meet the order specifications, one or more nodes may be added to a manufacturing line. Other nodes currently requisitioned for the manufacturing line may be left unused in the new manufacturing process. Such unused nodes may be reassigned to other tasks. In another example, nodes involved in environmental monitoring and/or closed loop security systems may be associated with a determined task. Additionally or alternatively, a task may also serve as an input for determining security levels and/or security features.
In some cases, the logic 600 may react to a status change of a node. For example, a previously requisitioned node may fail and a functional replacement may be sought from the inventory. In another example, an active node may be reassigned to a priority task. Another node may be sought to replace the reassigned node and/or load re-balancing may be applied.
In some implementations, the logic 600 may react to a status change in an environmental parameter or condition. For example, a sensor may detect a rise in the level of oxygen in a given area. The logic 600 may receive an indicator from the sensor. In response, the logic 600 may generate a task to address the oxygen level increase. The logic 600 may requisition nodes to execute the task.
Additionally or alternatively, the logic 600 may generate tasks which are independent of topology. For example, a data processing task may be distributed to nodes in differing topologies which meet the security preferences for the task. In some cases, the logic 600 may be unaware of the topology of the nodes to which the task is distributed. In such cases, the logic 600 may base task requisition on functionality and implemented security features.
In some implementations, nodes may cooperatively act to complete provisioning. For example, nodes may be equipped with radio access technologies (RATs) and may provide security feature support to other commonly assigned nodes via ad hoc networking. For example, a node may be equipped with near field communications (NFC) or the radio frequency identification (RFID) technology, Bluetooth, or WIFI. The node may pass security feature parameters or other data from an origin node to a destination node using the ad hoc networking (e.g. in a chain). In some implementations, to secure the ad hoc bridging between nodes, a multiple-stage key exchange may be used. Additionally or alternatively, end-to-end encryption may be applied to the transmitted parameters or data. For example, chained nodes may not be commonly assigned to tasks or present in the same topology. End-to-end security may allow passage of data over chained nodes where one or more of the intermediate nodes are not authorized to receive the transmitted data.
Additionally or alternatively, ad hoc networking may be used to in location determination of nodes. For example, nodes within the range of NFC communications with a determined node may be determined to be in the same topology. For example, a central node may be in NFC proximity to one or more satellite nodes. The topology of the satellite nodes may then be determined based on the topology of the central node.
Reprovisioning of security features in an industrial environment may be particularly useful in ensuring security preference compliance for non-stationary nodes. Examples of non-stationary nodes include mobile nodes, such as tablets, laptops, smartphones, other mobile computing devices, the nomadic robotic node 702 shown in
In
Additionally or alternatively, redundancy and/or robustness preferences may be determined based on topology. The robustness and redundancy preferences may be treated as security feature for implementation. For example for a particular location or task a determined number of available unassigned manufacture nodes may be kept in reserve for statistically predictable failures. For example, the failure rate for a determined manufacturing node may be 1 failure per 100 nodes per year for a given climate. For a task using 36,500 nodes, failures may occur nearly daily. If the mean downtime is 24 hours per failure, a reserve of one or more nodes may be preferable. Robustness and redundancy considerations may be applied to other nodes in the industrial environment 100.
The methods, devices, nodes, and logic described above may be implemented in many different ways in many different combinations of hardware, software or both hardware and software. For example, all or parts of the system may include circuitry in a controller, a microprocessor, or an application specific integrated circuit (ASIC), or may be implemented with discrete logic or components, or a combination of other types of analog or digital circuitry, combined on a single integrated circuit or distributed among multiple integrated circuits. All or part of the logic described above may be implemented as instructions for execution by a processor, controller, or other processing device and may be stored in a tangible or non-transitory machine-readable or computer-readable medium such as flash memory, random access memory (RAM) or read only memory (ROM), erasable programmable read only memory (EPROM) or other machine-readable medium such as a compact disc read only memory (CDROM), or magnetic or optical disk. Thus, a product, such as a computer program product, may include a storage medium and computer readable instructions stored on the medium, which when executed in an endpoint, computer system, or other device, cause the device to perform operations according to any of the description above.
The processing capability of the system may be distributed among multiple system components, such as among multiple processors and memories, optionally including multiple distributed processing systems. Parameters, databases, and other data structures may be separately stored and managed, may be incorporated into a single memory or database, may be logically and physically organized in many different ways, and may implemented in many ways, including data structures such as linked lists, hash tables, or implicit storage mechanisms. Programs may be parts (e.g., subroutines) of a single program, separate programs, distributed across several memories and processors, or implemented in many different ways, such as in a library, such as a shared library (e.g., a dynamic link library (DLL)). The DLL, for example, may store code that performs any of the system processing described above.
Various implementations have been described. However, many other implementations are also possible.
This application claims the benefit of priority from U.S. Provisional patent application Ser. No. 61/885,303 filed on Oct. 1, 2013 and U.S. Provisional patent application Ser. No. 61/924,372 filed on Jan. 7, 2014, both of which are incorporated by reference herein in their entirety.
Number | Date | Country | |
---|---|---|---|
61885303 | Oct 2013 | US | |
61924372 | Jan 2014 | US |