This disclosure relates generally to Programmable Logic Controllers
(PLCs), and more particularly to method and system for dynamically managing access
to PLCs.
Background
[002] Programmable Logic controllers (PLCs) are computing devices used
primarily for automating and optimizing industrial processes. Conventionally,
accessing and modifying a programming code of a PLC may require connecting a
programming device (such as a laptop or a desktop computer) with the PLC. In the
present state of art, to prevent unauthorized or undesirable modifications to the
programming code, PLC manufacturers provide a physical key on front panel of the
PLC as well as a user-defined password that can be enabled or disabled through a
programming software to lock or unlock the PLC, respectively.
[003] However, the physical key may be common across all PLC devices of
a model and the user-defined password is shared among a group within an
organization. There is, therefore, a risk of an intruder gaining access to a locked PLC
and modify PLC operations. Additional security risks may include hacking attempts
and downloading malware to the PLC to reduce downtime and processing speed.
Thus, a breach of security may lead to significant industrial losses.
[004] The conventional technqiues fail to provide protection to PLCs from
hacking attempts and malware. There is, therefore, a need in the present state of art
for techniques to enhance security of the PLCs and prevent unauthorzied access
attempts.
SUMMARY
[005] In one embodiment, a method for dynamically managing access to
Programmable Logic Controllers (PLCs) is disclosed. In one example, the method may
include determining a second level access status assigned to a user for accessing a
PLC in response to receiving a PLC access request associated with the user. The PLC
is inaccessible to the user when the second level access status corresponds to locked
Docket No.: IIP-HCL-P0030
3
and the PLC is accessible to the user when the second level access status
corresponds to unlocked. The method may further include sending an access grant
signal to a gateway communicatively coupled to the PLC. The access grant signal is
generated based on the second level access status of the user. It may be noted that
the access grant signal activates an access tag when the second level access status
corresponds to unlocked. Upon activation the access tag is configured to unlock the
PLC. It may also be noted that the access grant signal deactivates the access tag
when the second level access status corresponds to locked. Upon deactivation the
access tag is configured to lock the PLC.
[006] In one embodiment, a method for dynamically managing access to
PLCs is disclosed. In one example, the method may include receiving, by a gateway,
details associated with a user in response to user credentials provided by the user
being validated. The user credentials correspond to a first level access to a PLC. The
method may further include sending, by the gateway, a request to determine a second
level access status assigned to the user for accessing the PLC. The PLC is
inaccessible to the user when the second level access status corresponds to locked
and the PLC is accessible to the user when the second level access status
corresponds to unlocked. The method may further include receiving, by the gateway,
an access grant signal generated based on the second level access status of the user.
The method may further include managing, by the gateway, an access tag based on
the access grant signal. It may be noted that the access tag is activated, when the
second level access status corresponds to unlocked. Upon activation the access tag
is configured to unlock the PLC. It may also be noted that the access tag is
deactivated, when the second level access status corresponds to locked. Upon
deactivation the access tag is configured to lock the PLC.
[007] In one embodiment, a system for dynamically managing access to
Programmable Logic Controllers (PLCs) is disclosed. In one example, the system may
include a processor and a computer-readable medium communicatively coupled to the
processor. The computer-readable medium may store processor-executable
instructions, which, on execution, may cause the processor to determine a second
level access status assigned to a user for accessing a PLC in response to receiving a
PLC access request associated with the user. The PLC is inaccessible to the user
when the second level access status corresponds to locked and the PLC is accessible
to the user when the second level access status corresponds to unlocked. The
Docket No.: IIP-HCL-P0030
4
processor-executable instructions, on execution, may further cause the processor to
send an access grant signal to a gateway communicatively coupled to the PLC. The
access grant signal is generated based on the second level access status of the user.
It may be noted that the access grant signal activates an access tag when the second
level access status corresponds to unlocked. Upon activation the access tag is
configured to unlock the PLC. It may also be noted that the access grant signal
deactivates the access tag when the second level access status corresponds to
locked. Upon deactivation the access tag is configured to lock the PLC.
[008] In on embodiment, a Programmable Logic Controller (PLC)
management device for dynamically managing access to PLCs is disclosed. In one
example, the PLC management device may include a processor and a computerreadable medium communicatively coupled to the processor. The computer-readable
medium may store processor-executable instructions, which, on execution, may cause
the processor to receive details associated with a user in response to user credentials
provided by the user being validated. The user credentials correspond to a first level
access to a PLC. The processor-executable instructions, on execution, may further
cause the processor to send a request to determine a second level access status
assigned to the user for accessing the PLC. The PLC is inaccessible to the user when
the second level access status corresponds to locked and the PLC is accessible to the
user when the second level access status corresponds to unlocked. The processorexecutable instructions, on execution, may further cause the processor to receive an
access grant signal generated based on the second level access status of the user.
The processor-executable instructions, on execution, may further cause the processor
to manage an access tag based on the access grant signal. It may be noted that the
access tag is activated, when the second level access status corresponds to unlocked.
Upon activation the access tag is configured to unlock the PLC. It may also be noted
that the access tag is deactivated, when the second level access status corresponds
to locked. Upon deactivation the access tag is configured to lock the PLC.
[009] It is to be understood that both the foregoing general description and
the following detailed description are exemplary and explanatory only and are not
restrictive of the invention, as claimed.
Docket No.: IIP-HCL-P0030
5
BRIEF DESCRIPTION OF THE DRAWINGS
[010] The accompanying drawings, which are incorporated in and constitute
a part of this disclosure, illustrate exemplary embodiments and, together with the
description, serve to explain the disclosed principles.
[011] FIG. 1 is a block diagram of an exemplary system for dynamically
managing access to Programmable Logic Controllers (PLCs), in accordance with
some embodiments.
[012] FIG. 2 illustrates a functional block diagram of a PLC management
device implemented by the exemplary system of FIG. 1, in accordance with some
embodiments.
[013] FIG. 3 illustrates a flow diagram of an exemplary process for
dynamically managing access to PLCs, in accordance with some embodiments.
[014] FIG. 4 illustrates a flow diagram of an exemplary process for
dynamically managing access to PLCs, in accordance with some embodiments.
[015] FIG. 5 is a block diagram of an exemplary computer system for
implementing embodiments consistent with the present disclosure.
DETAILED DESCRIPTION
[016] Exemplary embodiments are described with reference to the
accompanying drawings. Wherever convenient, the same reference numbers are
used throughout the drawings to refer to the same or like parts. While examples and
features of disclosed principles are described herein, modifications, adaptations, and
other implementations are possible without departing from the spirit and scope of the
disclosed embodiments. It is intended that the following detailed description be
considered as exemplary only, with the true scope and spirit being indicated by the
following claims.
[017] Referring now to FIG. 1, an exemplary system 100 for dynamically
managing access to Programmable Logic Controllers (PLCs) is illustrated, in
accordance with some embodiments of the present disclosure. The system 100 may
include a plurality of PLCs 102a, 102b, 102c, and 102d. Each of the plurality of PLCs
102a, 102b, 102c, and 102d may be communicatively coupled with a user device 104
(for example, server, desktop, laptop, notebook, netbook, tablet, smartphone, mobile
phone, or any other computing device) through an ethernet device 106. The user
Docket No.: IIP-HCL-P0030
6
device 104 may be operated by a user to access at least one of the plurality of PLCs
102a, 102b, 102c, and 102d. It may be noted that the user may be required to pass a
first level access associated with the least one of the plurality of PLCs 102a, 102b,
102c, and 102d. Passing the first level access may include receiving user credentials
of a user account associated with the user and granting the user access to the user
account upon successful validation of the user credentials. In an exemplary scenario,
the user may pass the first level access associated with the PLC 102a by successfully
providing the user credentials. However, the PLC 102a may be vulnerable to
unauthorized access. The unauthorized access may include accessing the PLC 102a
against will of a higher management (for example, an admin user), which may be a
security risk.
[018] Further, the ethernet device 106 may communicatively couple the
plurality of PLCs 102a, 102b, 102c, and 102d with a gateway 108 through a machine
to machine communication protocol (for example, OPC Unified Architecture (UA)
protocol). By way of an example, 1 Byte of data exchanged between the gateway 108
and the ethernet device 106 through the OPC UA protocol may be distributed as 1 Bit
for “Control”, 1 Bit for “Status”, and 6 Bits Reserved. The gateway 108 may include
one or more processors 110 and a computer-readable medium (for example, a
memory 112). The memory 112 may include second level access status assigned to
a user for accessing a PLC. Further, the memory 112 may store instructions that, when
executed by the one or more processors 110, cause the one or more processors 110
to dynamically manage access to the PLC, in accordance with aspects of the present
disclosure. The memory 112 may also store various data (for example, PLC data, user
credentials data, second level access statuses assigned to users, access report
corresponding to users accessing the PLC, and the like) that may be captured,
processed, and/or required by the system 100. Alternatively, the memory 112 may be
within a cloud 114.
[019] Further, the system 100 may include an admin user device 116 (for
example, server, desktop, laptop, notebook, netbook, tablet, smartphone, mobile
phone, or any other computing device) communicatively coupled with the gateway 108
via a cloud 114, in accordance with some embodiments of the present disclosure. The
cloud 114 may be supported by a cloud platform such as Microsoft® Azure, Google®
Cloud, Amazon® AWS, and the like. The cloud 114 may be communicatively coupled
to the user device 116 through an Application Programming Interface (API) and
Docket No.: IIP-HCL-P0030
7
communicatively coupled to the gateway 108 through a Client Server messaging
transport protocol (for example, MQTT protocol). By way of an example, 1 Byte of data
exchanged between the gateway 108 and the cloud 114 through the MQTT protocol
may be distributed as 1 Bit for “Control”, 1 Bit for “Status”, and 6 Bits Reserved. In an
embodiment, the admin user device 116 may receive changes made to programming
code of the PLC by the user in form of comments. Further, the changes may be
approved by the admin user. Historical data of changes may be stored in the cloud
114 for auditing.
[020] The admin user device 116 may include a display 118 and a User
Interface (UI) (not shown in figure) accessible via the display 118. It should be noted
that the admin user device 116 may be accessed by the admin user to manage the
second level access status assigned to the user for accessing one or more of the
plurality of PLCs 102a, 102b, 102c, and 102d. The admin user device 116 may receive
a PLC access request from the user through the gateway 108. In response to the PLC
access request, the admin user may determine a second level access status for the
user and send an access grant signal to the gateway 108 through the cloud 114. In
some embodiments, the admin user device 116 may interact with one or more external
devices (not shown in figure) over a communication network for sending or receiving
various data. The one or more external devices may include, but may not be limited
to, a remote server, a digital device, or another computing system.
[021] As will be described in greater detail in conjunction with FIGS. 2 – 4,
the gateway may receive details associated with a user in response to user credentials
provided by the user being validated. It should be noted that the user credentials may
correspond to a first level access to a PLC. The gateway may further send a request
to determine a second level access status assigned to the user for accessing the PLC.
it should be noted that the PLC may be inaccessible to the user when the second level
access status corresponds to locked and the PLC may be accessible to the user when
the second level access status corresponds to unlocked. The gateway may further
receive an access grant signal generated based on the second level access status of
the user. The gateway may further manage an access tag based on the access grant
signal. It should be noted that the access tag may be activated, when the second level
access status corresponds to unlocked. Upon activation, the access tag may be
configured to unlock the PLC. It should also be noted that the access tag may be
Docket No.: IIP-HCL-P0030
8
deactivated, when the second level access status corresponds to locked. Upon
deactivation, the access tag may be configured to lock the PLC.
[022] Referring now to FIG. 2, a functional block diagram of a PLC
management device 202 is illustrated, in accordance with some embodiments. In an
embodiment, the PLC management device 202 may include a receiver 204, a memory
206, and a transmitter 208. In such an embodiment, the PLC management device 202
may be analogous to the gateway 108 of the system 100. The memory 206 may
include an access management module 210, a user authentication module 212, and
a report generation module 214. The receiver 204 may receive an input signal 216.
[023] In an exemplary scenario, the input signal 216 may be user credentials
of a user account associated with the user. In an embodiment, the receiver 204 may
receive the user credentials of the user account from the user device 104 of the system
100 via the ethernet device 106. The receiver 204 may send the input signal 216 to
the memory 206. The input signal 216 may be received by the user authentication
module 212 of the memory 206. The user authentication module 212 may validate the
user credentials with a user database. In an embodiment, the user database may be
within the cloud 114 of the system 100. Further, the access management module 210
may receive the validation from the user authentication module 212. It may be noted
that the validation may include a Multi-Factor Authentication (MFA) technique. By way
of an example, the at least two authentication factors may include a user account
password, a One Time Password (OTP), biometrics (such as fingerprint scan, facial
recognition, iris scan, etc.), date of birth of the user and the like. It may be noted that
upon successful validation of the user credentials, a first level access associated with
a PLC (for example, the PLC 102a) may be passed for the user. Upon successful
validation of the user credentials by the user authentication module 212, the access
management module 210 may grant the user access to the user account through the
transmitter 208. The transmitter 208 may communicate the access to the user account
in form of an output signal 218. In an embodiment, the output signal 218 may be sent
to the ethernet device 106.
[024] In another exemplary scenario, the input signal 216 may be a PLC
access request associated with the user. It may be noted that the PLC access request
associated with the user is generated in response to the user passing the first level
access associated with the PLC. In an embodiment, the receiver 204 may receive the
PLC access request from the user device 104 of the system 100. The receiver 204
Docket No.: IIP-HCL-P0030
9
may send the input signal 216 to the memory 206. Further, the input signal 216 may
be received by the access management module 210. The access management
module 210 may determine a second level access status assigned to the user for
accessing the PLC. The second level access status of the user may be assigned by
the admin user through a user command. By way of an example, the user command
may include assigning a new second level access status of the user or modifying a
current second level access status of the user. It may be noted that the PLC is
inaccessible to the user when the second level access status corresponds to locked
and the PLC is accessible to the user when the second level access status
corresponds to unlocked. In an embodiment, the admin user may predefine the second
level access status of a user for future access to the PLC.
[025] Additionally, based on the user command of the admin user, the access
management module 210 may modify the second level access status assigned to the
user for accessing the PLC. The modification is initiated by the admin user through the
admin user device (for example, the admin user device 116). Upon initiating the
modifying with the access management module 210, the user authentication module
212 may be activated to authenticate the admin user. The user authentication module
212 may generate an OTP for the admin user. Further, the user authentication module
212 may validate the OTP provided by the admin user. Further, the user authentication
module 212 may authorize the admin user to modify the second level access status
assigned to the user, in response to validating the OTP.
[026] A successful authentication of the admin user by the user
authentication module 212 may activate the access management module 210 to send
an access grant signal to the transmitter 208 based on the user command of the admin
user. Further, the access grant signal may activate an access tag when the second
level access status corresponds to unlocked. Upon activation the access tag is
configured to unlock the PLC. Additionally, the access grant signal may deactivate the
access tag when the second level access status corresponds to locked. Upon
deactivation the access tag is configured to lock the PLC. The transmitter 208 may
communicate the access grant signal in form of the output signal 218. In an
embodiment, the output signal 218 may be sent to the ethernet device 106. When the
second level access status corresponds to unlocked, the user may access the PLC
through the user device 104.
Docket No.: IIP-HCL-P0030
10
[027] In another exemplary scenario, the input signal 216 may be an access
grant signal received from the admin user. In an embodiment, the input signal 216 may
be received from the admin user device 116 of the system 100. Further, the receiver
204 may send the input signal 216 to the memory 206. The input signal 216 may be
received by the access management module 210. Further, the access management
module 210 may manage the access tag based on the access grant signal. It may be
noted that the access tag may be activated, when the second level access status
corresponds to unlocked. Upon activation the access tag is configured to unlock the
PLC. Further, the access management module 210 may transmit an unlock instruction
to the PLC as the output signal 218 in response to activating the access tag via the
transmitter 208. Alternatively, the access tag may be deactivated, when the second
level access status corresponds to locked. Upon deactivation the access tag is
configured to lock the PLC.
[028] Further, the access management module 210 may transmit a lock
instruction to the PLC as the output signal 218 in response to deactivating the access
tag via the transmitter 208. In an embodiment, the PLC management device 202 may
include the access tag. Further, the access tag, upon activation, may activate an
unlock bit within the PLC and upon deactivation, the access tag may deactivate the
unlock bit within the PLC. Activation or deactivation of the access tag in the PLC
management device 202 may be communicated to the PLC through a machine to
machine communication protocol (for example, OPC UA protocol). By way of an
example, 1 Byte of data exchanged between the PLC management device 202 and
the PLC through the OPC UA protocol may be distributed as 1 Bit for “Control”, 1 Bit
for “Status”, and 6 Bits Reserved.
[029] It may be noted that the report generation module 214 may generate
an access report corresponding to a plurality of users accessing the PLC. The access
report may include data associated with at least one of account details of each of the
plurality of users, duration of accessing the PLC by each of the plurality of users, time
of accessing the PLC by each of the plurality of users, or operation performed on the
PLC by each of the plurality of users. Further, the report generation module 214 may
send a notification to the admin user in response to detecting an unauthorized access
attempt to the PLC. By way of an example, an unauthorized access attempt to the
PLC may include an access attempt to a PLC for which the second level access status
Docket No.: IIP-HCL-P0030
11
of the user corresponds to locked. The notification may include details of users
attempting the unauthorized access.
[030] In an alternate embodiment, the PLC management device 202 may
include, within the memory 206, the access management module 210, the user
authentication module 212, and the report generation module 214. In such an
embodiment, the PLC management device 202 may be analogous to the admin user
device 116 of the system 100. The user authentication module 212 may receive user
credentials of a user account associated with the user. Further, the user authentication
module 212 may validate the user credentials with a user database. In an embodiment,
the user database may be within the cloud 114 of the system 100. Further, the access
management module 210 may receive the validation from the user authentication
module 212. It may be noted that the validation may include an MFA technique. By
way of an example, the at least two authentication factors may include user account
password, OTP, biometrics (such as fingerprint scan, facial recognition, iris scan, etc.),
date of birth of the user and the like. It may be noted that upon successful validation
of the user credentials, the first level access associated with a PLC (for example, the
PLC 102a) may be passed for the user. Upon successful validation of the user
credentials by the user authentication module 212, the access management module
210 may grant the user access to the user account.
[031] Further, the user may send a PLC access request to the PLC
management device 202. The access management module 210 may receive the PLC
access request associated with the user. The access management module 210 may
determine the second level access status assigned to a user for accessing a PLC (for
example, the PLC 102a). The PLC is inaccessible to the user when the second level
access status corresponds to locked and the PLC is accessible to the user when the
second level access status corresponds to unlocked. It may be noted that the second
level access status may be assigned for first time to the user by the admin user through
the PLC management device 202. The access management module 210 may send
an access grant signal to a gateway (for example, the gateway 108) communicatively
coupled to the PLC. The access grant signal may be generated based on the second
level access status of the user. It may be noted that the access grant signal may
activate an access tag when the second level access status corresponds to unlocked.
Upon activation the access tag is configured to unlock the PLC. It may also be noted
that the access grant signal may deactivate the access tag when the second level
Docket No.: IIP-HCL-P0030
12
access status corresponds to locked. Upon deactivation the access tag is configured
to lock the PLC.
[032] Further, once assigned, the second level access status may be
modified by the admin user through the PLC management device 202. The access
management module 210 may modify the second level access status assigned to the
user for accessing the PLC. Modification of the second level access status assigned
to the user may be initiated by the admin user. Upon initiating the modifying with the
access management module 210, the user authentication module 212 may be
activated to authenticate the admin user. The user authentication module 212 may
generate an OTP for the admin user. Further, the user authentication module 212 may
validate the OTP provided by the admin user. Further, the user authentication module
212 may authorize the admin user to modify the second level access status assigned
to the user, in response to validating the OTP. A successful authentication of the admin
user by the user authentication module 212 may activate the access management
module 210 to send an access grant signal to the gateway based on the user
command of the admin user.
[033] It should be noted that all such aforementioned modules 202 – 214 may
be represented as a single module or a combination of different modules. Further, as
will be appreciated by those skilled in the art, each of the modules 202 – 214 may
reside, in whole or in parts, on one device or multiple devices in communication with
each other. In some embodiments, each of the modules 202 – 214 may be
implemented as dedicated hardware circuit comprising custom application-specific
integrated circuit (ASIC) or gate arrays, off-the-shelf semiconductors such as logic
chips, transistors, or other discrete components. Each of the modules 202 – 214 may
also be implemented in a programmable hardware device such as a field
programmable gate array (FPGA), programmable array logic, programmable logic
device, and so forth. Alternatively, each of the modules 202 – 214 may be implemented
in software for execution by various types of processors (e.g., processor 110). An
identified module of executable code may, for instance, include one or more physical
or logical blocks of computer instructions, which may, for instance, be organized as an
object, procedure, function, or other construct. Nevertheless, the executables of an
identified module or component need not be physically located together, but may
include disparate instructions stored in different locations which, when joined logically
together, include the module and achieve the stated purpose of the module. Indeed,
Docket No.: IIP-HCL-P0030
13
a module of executable code could be a single instruction, or many instructions, and
may even be distributed over several different code segments, among different
applications, and across several memory devices.
[034] As will be appreciated by one skilled in the art, a variety of processes
may be employed for dynamically managing access to PLCs. For example, the
exemplary system 100 and the associated PLC management device 202 may
dynamically manage access to PLCs by the processes discussed herein. In particular,
as will be appreciated by those of ordinary skill in the art, control logic and/or
automated routines for performing the techniques and steps described herein may be
implemented by the system 100 and the associated PLC management device 202
either by hardware, software, or combinations of hardware and software. For example,
suitable code may be accessed and executed by the one or more processors on the
system 100 to perform some or all of the techniques described herein. Similarly,
application specific integrated circuits (ASICs) configured to perform some or all of the
processes described herein may be included in the one or more processors on the
system 100.
[035] Referring now to FIG. 3, an exemplary process 300 for dynamically
managing access to PLCs (for example, the PLC 102a, the PLC 102b, the PLC 102c,
and the PLC 102d) is depicted via a flowchart, in accordance with some embodiments.
The process 300 may be implemented by the PLC management device 202 of the
system 200. The PLC management device 202 may receive a PLC access request
associated with the user. It may be noted that the PLC access request may be
generated in response to the user passing a first level access associated with the PLC.
The process 300 may include receiving user credentials of a user account associated
with the user, at step 302. Further, the process 300 may include granting the user
access to the user account upon successful validation of the user credentials, at step
304. The validation includes an MFA technique. As will be appreciated, the MFA
technique may require at least two authentication factors from the user. For example,
the at least two authentication factors may include a user account password, an OTP,
biometrics (such as fingerprint scan, facial recognition, iris scan, etc.), date of birth of
the user and the like. It may be noted that passing the first level access may include
the steps 302 and 304. By way of an example, the PLC management device 202 may
receive the user credentials of a user account associated with the user from the user
device 104 through the ethernet device 106. The user authentication module 212 may
Docket No.: IIP-HCL-P0030
14
grant the user access to the user account upon successful validation of the user
credentials.
[036] Further, the process 300 may include determining a second level
access status assigned to the user for accessing the PLC in response to receiving a
PLC access request associated with the user, at step 306. The PLC is inaccessible to
the user when the second level access status corresponds to locked and the PLC is
accessible to the user when the second level access status corresponds to unlocked.
Further, the process 300 may include sending an access grant signal to a gateway
(such as the gateway 108) communicatively coupled to the PLC, at step 308. The
access grant signal is generated based on the second level access status of the user.
The access grant signal activates an access tag when the second level access status
corresponds to unlocked. Upon activation the access tag is configured to unlock the
PLC. Additionally, the access grant signal deactivates the access tag when the second
level access status corresponds to locked. Upon deactivation the access tag is
configured to lock the PLC. In continuation of the example above, the PLC
management device 202 may receive a PLC access request for accessing the PLC
102a from the user through the user device 104. The access management module
210 may determine second level access status assigned to the user for accessing the
PLC 102a. Based on the second level access status of the user, the access
management module 210 may send an access grant signal to the gateway 108. In
some embodiments, the gateway includes the access tag. In such embodiments, the
access tag, upon activation, activates an unlock bit within the PLC and upon
deactivation, the access tag deactivates the unlock bit within the PLC. Further,
activation or deactivation of the access tag in the gateway is communicated to the PLC
through a machine to machine communication protocol (for example, the OPC UA
protocol).
[037] Further, the process 300 may include modifying the second level
access status assigned to the user for accessing the PLC, at step 310. It may be noted
that the modification of the second level access status assigned to the user is initiated
by an admin user. Further, the step 310 may include generating an OTP for the admin
user, at step 312. Further, the step 310 may include validating the OTP provided by
the admin user, at step 314. Further, the step 310 may include authorizing the admin
user to modify the second level access status assigned to the user, in response to
validating the OTP, at step 316. In continuation of the example above, the admin user
Docket No.: IIP-HCL-P0030
15
may modify the second level access status assigned to the user. The user
authentication module 212 may receive a modification request from the admin user
device 116. Further, the user authentication module 212 may generate an OTP for the
admin user. The user authentication module 212 may authorize the admin user to
modify the second level access status assigned to the user upon successful validation
of the OTP.
[038] Further, the process 300 may include sending a notification to the
admin user in response to detecting an unauthorized access attempt to the PLC, at
step 318. The notification includes details of users attempting the unauthorized
access. Further, the process 300 may include generating an access report
corresponding to a plurality of users accessing the PLC, at step 320. The access report
includes data associated with at least one of: account details of each of the plurality of
users, duration of accessing the PLC by each of the plurality of users, time of
accessing the PLC by each of the plurality of users, or operation performed on the
PLC by each of the plurality of users. The steps 318 and 320 may be performed by
the report generation module 214 of the PLC management device 202.
[039] Referring now to FIG. 4, an exemplary process 400 for dynamically
managing access to PLCs (for example, the PLC 102a, the PLC 102b, the PLC 102c,
and the PLC 102d) is depicted via a flow chart, in accordance with some embodiments.
The process 400 may be implemented by the PLC management device 202 of the
system 200. The process 400 may include receiving, by a gateway (such as the
gateway 108), details associated with a user in response to user credentials provided
by the user being validated, at step 402. The user credentials correspond to a first
level access to a PLC. By way of an example, the gateway 108 may receive user
credentials of the user from the user device 104 via the ethernet device 106. Upon
successful validation of the user credentials, the gateway 108 may receive details
associated with the user from the cloud 114. Further, the process 400 may include
sending, by the gateway, a request to determine a second level access status
assigned to the user for accessing the PLC, at step 404. The PLC is inaccessible to
the user when the second level access status corresponds to locked and the PLC is
accessible to the user when the second level access status corresponds to unlocked.
In continuation of the example above, upon validation of the first level access of the
user, the gateway 108 may send a request to the admin user device 114 to determine
the second level access status assigned to the user for accessing the PLC 102a.
Docket No.: IIP-HCL-P0030
16
[040] Further, the process 400 may include receiving, by the gateway, an
access grant signal generated based on the second level access status of the user, at
step 406. Further, the process 400 may include managing, by the gateway, an access
tag based on the access grant signal, at step 408. It may be noted that the access tag
is activated, when the second level access status corresponds to unlocked. Upon
activation the access tag is configured to unlock the PLC. It may also be noted that
the access tag is deactivated, when the second level access status corresponds to
locked. Upon deactivation the access tag is configured to lock the PLC. Further, the
process 400 may include transmitting an unlock instruction to the PLC in response to
activating the access tag, at step 410. Further, the process 400 may include
transmitting a lock instruction to the PLC in response to deactivating the access tag,
at step 412. In continuation of the example above, the gateway 108 may receive an
access grant signal from the admin user device 114. The gateway 108 may include an
access tag. When the access tag is activated, the gateway 108 may transmit an unlock
instruction to the PLC 102a and when the access tag is deactivated, the gateway 108
may transmit a lock instruction to the PLC 102a.
[041] As will be also appreciated, the above described techniques may take
the form of computer or controller implemented processes and apparatuses for
practicing those processes. The disclosure can also be embodied in the form of
computer program code containing instructions embodied in tangible media, such as
floppy diskettes, solid state drives, CD-ROMs, hard drives, or any other computerreadable storage medium, wherein, when the computer program code is loaded into
and executed by a computer or controller, the computer becomes an apparatus for
practicing the invention. The disclosure may also be embodied in the form of computer
program code or signal, for example, whether stored in a storage medium, loaded into
and/or executed by a computer or controller, or transmitted over some transmission
medium, such as over electrical wiring or cabling, through fiber optics, or via
electromagnetic radiation, wherein, when the computer program code is loaded into
and executed by a computer, the computer becomes an apparatus for practicing the
invention. When implemented on a general-purpose microprocessor, the computer
program code segments configure the microprocessor to create specific logic circuits.
[042] The disclosed methods and systems may be implemented on a
conventional or a general-purpose computer system, such as a personal computer
(PC) or server computer. Referring now to FIG. 5, an exemplary computing system
Docket No.: IIP-HCL-P0030
17
500 that may be employed to implement processing functionality for various
embodiments (e.g., as a SIMD device, client device, server device, one or more
processors, or the like) is illustrated. Those skilled in the relevant art will also recognize
how to implement the invention using other computer systems or architectures. The
computing system 500 may represent, for example, a user device such as a desktop,
a laptop, a mobile phone, personal entertainment device, DVR, and so on, or any other
type of special or general-purpose computing device as may be desirable or
appropriate for a given application or environment. The computing system 500 may
include one or more processors, such as a processor 502 that may be implemented
using a general or special purpose processing engine such as, for example, a
microprocessor, microcontroller or other control logic. In this example, the processor
502 is connected to a bus 504 or other communication medium. In some
embodiments, the processor 502 may be an Artificial Intelligence (AI) processor, which
may be implemented as a Tensor Processing Unit (TPU), or a graphical processor
unit, or a custom programmable solution Field-Programmable Gate Array (FPGA).
[043] The computing system 500 may also include a memory 506 (main
memory), for example, Random Access Memory (RAM) or other dynamic memory, for
storing information and instructions to be executed by the processor 502. The memory
506 also may be used for storing temporary variables or other intermediate information
during execution of instructions to be executed by the processor 502. The computing
system 500 may likewise include a read only memory (“ROM”) or other static storage
device coupled to bus 504 for storing static information and instructions for the
processor 502.
[044] The computing system 500 may also include a storage devices 508,
which may include, for example, a media drive 510 and a removable storage interface.
The media drive 510 may include a drive or other mechanism to support fixed or
removable storage media, such as a hard disk drive, a floppy disk drive, a magnetic
tape drive, an SD card port, a USB port, a micro USB, an optical disk drive, a CD or
DVD drive (R or RW), or other removable or fixed media drive. A storage media 512
may include, for example, a hard disk, magnetic tape, flash drive, or other fixed or
removable medium that is read by and written to by the media drive 510. As these
examples illustrate, the storage media 512 may include a computer-readable storage
medium having stored therein particular computer software or data.
Docket No.: IIP-HCL-P0030
18
[045] In alternative embodiments, the storage devices 508 may include other
similar instrumentalities for allowing computer programs or other instructions or data
to be loaded into the computing system 500. Such instrumentalities may include, for
example, a removable storage unit 514 and a storage unit interface 516, such as a
program cartridge and cartridge interface, a removable memory (for example, a flash
memory or other removable memory module) and memory slot, and other removable
storage units and interfaces that allow software and data to be transferred from the
removable storage unit 514 to the computing system 500.
[046] The computing system 500 may also include a communications interface
518. The communications interface 518 may be used to allow software and data to be
transferred between the computing system 500 and external devices. Examples of the
communications interface 518 may include a network interface (such as an Ethernet
or other NIC card), a communications port (such as for example, a USB port, a micro
USB port), Near field Communication (NFC), etc. Software and data transferred via
the communications interface 518 are in the form of signals which may be electronic,
electromagnetic, optical, or other signals capable of being received by the
communications interface 518. These signals are provided to the communications
interface 518 via a channel 520. The channel 520 may carry signals and may be
implemented using a wireless medium, wire or cable, fiber optics, or other
communications medium. Some examples of the channel 520 may include a phone
line, a cellular phone link, an RF link, a Bluetooth link, a network interface, a local or
wide area network, and other communications channels.
[047] The computing system 500 may further include Input/Output (I/O)
devices 522. Examples may include, but are not limited to a display, keypad,
microphone, audio speakers, vibrating motor, LED lights, etc. The I/O devices 522
may receive input from a user and also display an output of the computation performed
by the processor 502. In this document, the terms “computer program product” and
“computer-readable medium” may be used generally to refer to media such as, for
example, the memory 506, the storage devices 508, the removable storage unit 514,
or signal(s) on the channel 520 . These and other forms of computer-readable media
may be involved in providing one or more sequences of one or more instructions to
the processor 502 for execution. Such instructions, generally referred to as “computer
program code” (which may be grouped in the form of computer programs or other
Docket No.: IIP-HCL-P0030
19
groupings), when executed, enable the computing system 500 to perform features or
functions of embodiments of the present invention.
[048] In an embodiment where the elements are implemented using
software, the software may be stored in a computer-readable medium and loaded into
the computing system 500 using, for example, the removable storage unit 514, the
media drive 510 or the communications interface 518. The control logic (in this
example, software instructions or computer program code), when executed by the
processor 502, causes the processor 502 to perform the functions of the invention as
described herein.
[049] Thus, the disclosed method and system try to overcome the technical
problem of dynamically managing access to PLCs. The method and system provide a
second level of security to protect a PLC from unauthorized use. When the user may
forget user credentials of the user account, a need to factory reset the PLC may be
avoided. Further, leaking of user credentials to a third party may not guarantee
successful hacking of the PLC due to the second level of access. Changes made to
code of the PLC may be closely monitored. Further, undesirable changes to
programming of the PLCs may be prevented. Access to the PLC may be assigned to
the user for a predefined time. Additionally, hacking of PLCs may be avoided by
dynamically managing access to the PLCs. The PLCs may further be protected from
malware. Further, the admin user may be notified of unauthorized access attempts.
The admin user may be provided with detailed usage reports which may include time
of access, duration of access, and PLCs access by the user. The access to the PLCs
may be centrally regulated. Automatic capture of diagnostic data with respect to
security of the PLC may be recorded and reported to the admin user.
[050] As will be appreciated by those skilled in the art, the techniques
described in the various embodiments discussed above are not routine, or
conventional, or well understood in the art. The techniques discussed above provide
for dynamically managing access to PLCs. The techniques first determining a second
level access status assigned to a user for accessing a PLC in response to receiving a
PLC access request associated with the user. The PLC is inaccessible to the user
when the second level access status corresponds to locked and the PLC is accessible
to the user when the second level access status corresponds to unlocked. The
techniques may then send an access grant signal to a gateway communicatively
coupled to the PLC. The access grant signal is generated based on the second level
Docket No.: IIP-HCL-P0030
20
access status of the user. The access grant signal activates an access tag when the
second level access status corresponds to unlocked. Upon activation the access tag
is configured to unlock the PLC. The access grant signal deactivates the access tag
when the second level access status corresponds to locked. Upon deactivation the
access tag is configured to lock the PLC.
[051] In light of the above mentioned advantages and the technical
advancements provided by the disclosed method and system, the claimed steps as
discussed above are not routine, conventional, or well understood in the art, as the
claimed steps enable the following solutions to the existing problems in conventional
technologies. Further, the claimed steps clearly bring an improvement in the
functioning of the device itself as the claimed steps provide a technical solution to a
technical problem.
[052] The specification has described method and system for dynamically
managing access to PLCs. The illustrated steps are set out to explain the exemplary
embodiments shown, and it should be anticipated that ongoing technological
development will change the manner in which particular functions are performed.
These examples are presented herein for purposes of illustration, and not limitation.
Further, the boundaries of the functional building blocks have been arbitrarily defined
herein for the convenience of the description. Alternative boundaries can be defined
so long as the specified functions and relationships thereof are appropriately
performed. Alternatives (including equivalents, extensions, variations, deviations, etc.,
of those described herein) will be apparent to persons skilled in the relevant art(s)
based on the teachings contained herein. Such alternatives fall within the scope and
spirit of the disclosed embodiments.
[053] Furthermore, one or more computer-readable storage media may be
utilized in implementing embodiments consistent with the present disclosure. A
computer-readable storage medium refers to any type of physical memory on which
information or data readable by a processor may be stored. Thus, a computerreadable storage medium may store instructions for execution by one or more
processors, including instructions for causing the processor(s) to perform steps or
stages consistent with the embodiments described herein. The term “computerreadable medium” should be understood to include tangible items and exclude carrier
waves and transient signals, i.e., be non-transitory. Examples include random access
memory (RAM), read-only memory (ROM), volatile memory, nonvolatile memory, hard
Docket No.: IIP-HCL-P0030
21
drives, CD ROMs, DVDs, flash drives, disks, and any other known physical storage
media.
[054] It is intended that the disclosure and examples be considered as
exemplary only, with a true scope and spirit of disclosed embodiments being indicated
by the following claims.

CLAIMS
WHAT IS CLAIMED IS:
1. A method (300) for dynamically managing access to Programmable Logic
Controllers (PLCs), the method (300) comprising:
determining (306), by a PLC management device (202), a second level
access status assigned to a user for accessing a PLC (102a) in response to
receiving a PLC access request associated with the user, wherein the PLC (102a) is
inaccessible to the user when the second level access status corresponds to locked
and the PLC (102a) is accessible to the user when the second level access status
corresponds to unlocked; and
sending (308), by the PLC management device (202), an access grant signal
to a gateway (108) communicatively coupled to the PLC (102a), wherein the access
grant signal is generated based on the second level access status of the user, and
wherein:
the access grant signal activates an access tag when the second level access
status corresponds to unlocked, and wherein upon activation the access tag is
configured to unlock the PLC (102a); and
the access grant signal deactivates the access tag when the second level
access status corresponds to locked, and wherein upon deactivation the access tag
is configured to lock the PLC(102a).
2. The method of claim 1, further comprising modifying (310) the second level
access status assigned to the user for accessing the PLC (102a), wherein
modification of the second level access status assigned to the user is initiated by an
admin user, and wherein modifying comprises:
generating (312) a One Time Password (OTP) for the admin user;
validating (314) the OTP provided by the admin user; and
authorizing (316) the admin user to modify the second level access status
assigned to the user, in response to validating the OTP.
3. The method of claim 1, wherein the PLC access request associated with the user
is generated in response to the user passing a first level access associated with the
PLC (102a), and wherein passing the first level access comprises:
Docket No.: IIP-HCL-P0030
23
receiving (302) user credentials of a user account associated with the user;
and
granting (304) the user access to the user account upon successful validation
of the user credentials, wherein the validation comprises a Multi-Factor
Authentication (MFA) technique.
4. The method of claim 1, wherein the gateway (108) comprises the access tag, and
wherein the access tag, upon activation, activates an unlock bit within the PLC
(102a) and upon deactivation, the access tag deactivates the unlock bit within the
PLC (102a), and wherein activation or deactivation of the access tag in the gateway
(108) is communicated to the PLC (102a) through a machine to machine
communication protocol.
5. The method of claim 1, further comprising sending (318) a notification to the
admin user in response to detecting an unauthorized access attempt to the PLC
(102a), wherein the notification comprises details of users attempting the
unauthorized access.
6. The method of claim 1, further comprising generating (320) an access report
corresponding to a plurality of users accessing the PLC (102a), wherein the access
report comprises data associated with at least one of: account details of each of the
plurality of users, duration of accessing the PLC (102a) by each of the plurality of
users, time of accessing the PLC (102a) by each of the plurality of users, or
operation performed on the PLC (102a) by each of the plurality of users.
7. A method (400) for dynamically managing access to Programmable Logic
Controllers (PLCs), the method (400) comprising:
receiving (402), by a gateway (108), details associated with a user in
response to user credentials provided by the user being validated, wherein the user
credentials correspond to a first level access to a PLC (102a);
sending (404), by the gateway (108), a request to determine a second level
access status assigned to the user for accessing the PLC (102a), wherein the PLC
(102a) is inaccessible to the user when the second level access status corresponds
Docket No.: IIP-HCL-P0030
24
to locked and the PLC (102a) is accessible to the user when the second level access
status corresponds to unlocked;
receiving (406), by the gateway (108), an access grant signal generated
based on the second level access status of the user; and
managing (408), by the gateway (108), an access tag based on the access
grant signal, wherein:
the access tag is activated, when the second level access status corresponds
to unlocked, wherein upon activation the access tag is configured to unlock the PLC
(102a); and
the access tag is deactivated, when the second level access status
corresponds to locked, wherein upon deactivation the access tag is configured to
lock the PLC (102a).

8. The method of claim 7, further comprising, at least one of:
transmitting (410) an unlock instruction to the PLC (102a) in response to
activating the access tag; and
transmitting (412) a lock instruction to the PLC (102a) in response to
deactivating the access tag.
9. A system (100) for dynamically managing access to Programmable Logic
Controllers (PLCs), the system (100) comprising:
a processor (110); and
a memory (112) communicatively coupled to the processor (110), wherein the
memory (112) stores processor instructions, which when executed by the processor
(110), cause the processor (110) to:
determine (306) a second level access status assigned to a user for
accessing a PLC (102a) in response to receiving a PLC access request associated
with the user, wherein the PLC (102a) is inaccessible to the user when the second
level access status corresponds to locked and the PLC (102a) is accessible to the
user when the second level access status corresponds to unlocked; and
send (308) an access grant signal to a gateway (108) communicatively
coupled to the PLC (102a), wherein the access grant signal is generated based on
the second level access status of the user, and wherein:
Docket No.: IIP-HCL-P0030
25
the access grant signal activates an access tag when the second level access
status corresponds to unlocked, and wherein upon activation the access tag is
configured to unlock the PLC (102a); and
the access grant signal deactivates the access tag when the second level
access status corresponds to locked, and wherein upon deactivation the access tag
is configured to lock the PLC (102a).
10. A Programmable Logic Controller (PLC) management device (202) for
dynamically managing access to PLCs, the PLC management device (202)
comprising:
a processor (110); and
a memory (112) communicatively coupled to the processor (110), wherein the
memory (112) stores processor instructions, which when executed by the processor
(110), cause the processor (110) to:
receive (402) details associated with a user in response to user credentials
provided by the user being validated, wherein the user credentials correspond to a
first level access to a PLC (102a);
send (404) a request to determine a second level access status assigned to
the user for accessing the PLC (102a), wherein the PLC is inaccessible to the user
when the second level access status corresponds to locked and the PLC is
accessible to the user when the second level access status corresponds to
unlocked;
receive (406) an access grant signal generated based on the second level
access status of the user; and
manage (408) an access tag based on the access grant signal, wherein:
the access tag is activated, when the second level access status corresponds
to unlocked, wherein upon activation the access tag is configured to unlock the PLC
(102a); and
the access tag is deactivated, when the second level access status
corresponds to locked, wherein upon deactivation the access tag is configured to
lock the PLC (102a).
Docket No.: IIP-HCL-P0030
26
ABSTR