CN111682969A

CN111682969A - Distributed centerless equipment control mutual exclusion method, system and equipment

Info

Publication number: CN111682969A
Application number: CN202010488509.0A
Authority: CN
Inventors: 陈磊; 梁俊; 米绍臣
Original assignee: Guangzhou Institute Of Artificial Intelligence And Advanced Computing Institute Of Automation Chinese Academy Of Sciences; Institute of Automation of Chinese Academy of Science
Current assignee: Guangzhou Institute Of Artificial Intelligence And Advanced Computing Institute Of Automation Chinese Academy Of Sciences; Institute of Automation of Chinese Academy of Science
Priority date: 2020-06-02
Filing date: 2020-06-02
Publication date: 2020-09-18
Anticipated expiration: 2040-06-02
Also published as: CN111682969B

Abstract

The invention discloses a distributed centerless equipment control mutual exclusion method, a system and equipment, wherein the method comprises the following steps: receiving login information issued to a subscribed mutual exclusion group theme with static control permission by a user according to a session mutual exclusion table of the user during login, and determining the mutual exclusion permission of the user to the mutual exclusion group by a service currently managing the mutual exclusion group according to the login information and a service mutual exclusion table stored by the service currently; after a user determines a mutual exclusion group with mutual exclusion authority according to the session mutual exclusion table, the service of the corresponding mutual exclusion group receives a session identifier and a control command of the user, the session identifier and the service mutual exclusion table determine the mutual exclusion authority of the user to the mutual exclusion group, and the control command is executed after the user has the mutual exclusion authority of the mutual exclusion group.

Description

Distributed centerless equipment control mutual exclusion method, system and equipment

Technical Field

The invention relates to the technical field of computers, in particular to a distributed centerless equipment control mutual exclusion method, a system and equipment.

Background

In the field of industrial control, for remote control of some critical devices, mutual exclusivity of control must be ensured from a safety perspective, i.e., the same device can only be controlled by a single person at the same time.

In an actual production environment, since the equipment and the control personnel are dispersed in different physical spaces, a distributed requirement is put on a control system. Therefore, support for a distributed architecture must also be considered for managing the control mutex.

The existing mutual exclusion control scheme basically selects a server with a higher position as a central server under a distributed environment, and a mutual exclusion control management service is set on the central server to perform centralized management on the control mutual exclusion. In the prior art, a general method for a solution for controlling mutual exclusion specifically includes:

1. running a control mutual exclusion management service on a central server, wherein the service records a mutual exclusion table facing the whole system, namely the contrast relation between a series of session identifiers and mutual exclusion groups;

2. when a user logs in and logs out and the equipment management service is on line, the user client and the equipment actively communicate with the control mutual exclusion management service of the central server to inform the state change condition of the user client and the equipment;

3. the user client and the equipment management service regularly communicate with the control mutual exclusion management service, and know the online condition of the control mutual exclusion management service and the control mode (normal mode or degraded mode) of the current system.

4. When a user initiates control, the user firstly inquires whether the control mutual exclusion management service has mutual exclusion authority or not, and contacts the equipment management service to execute control operation after obtaining feedback of the control mutual exclusion management service.

5. Whether the mutual exclusion authority inquiry or the daily connection state monitoring is carried out, when the communication between the user and the control mutual exclusion management service fails, the user enters a degradation mode, at the moment, the user checks whether the user is a preset degradation designated user, and only the degradation designated user can carry out the control.

This current solution has the following problems:

problem 1, once the central server fails due to various reasons, such as network interruption, server hardware failure, control mutex management service software failure, etc., the control mutex of the whole system is disabled. Due to the security factor that must be guaranteed, the system will force to enter the downgrade mode when the central server fails, and in the downgrade mode, the right allocation that controls the mutual exclusion is forced to be assigned to the predetermined fixed user.

Problem 2, the degradation mode only considers the case of the failure of the central server, and when the network domain part fails, that is, the whole distributed environment is divided into two parts due to the network failure, no countermeasure is provided.

Problem 3, the control mutual exclusion management completely depends on the control mutual exclusion management service on the central server, if other external malicious programs exist, the control is carried out by bypassing the service and directly communicating with the equipment management service, and the equipment management service does not have any protection capability, so that the information safety problem can be caused, and larger property and even life safety hidden dangers are possibly caused.

Therefore, a completely decentralized method for mutual exclusion of device control is needed.

Disclosure of Invention

The invention aims to provide a distributed decentralized device control mutual exclusion method, a distributed decentralized device control mutual exclusion system and distributed decentralized device control mutual exclusion equipment, and aims to solve the problems in the prior art.

The invention provides a distributed centerless equipment control mutual exclusion method, which comprises the following steps:

receiving login information issued to a subscribed mutual exclusion group theme with static control authority by a user according to a session mutual exclusion table of the user during login, and determining the mutual exclusion authority of the user to the mutual exclusion group by a service for currently managing the mutual exclusion group according to the login information and a service mutual exclusion table stored by the service for currently managing the mutual exclusion group;

after the user determines the mutual exclusion group with the mutual exclusion authority according to the session mutual exclusion table, the service of the corresponding mutual exclusion group receives the self session identifier and the control command issued by the user, determines the mutual exclusion authority of the user to the mutual exclusion group according to the session identifier and the service mutual exclusion table, and executes the control command after the user has the mutual exclusion authority of the mutual exclusion group.

The invention provides a distributed non-centralized equipment control mutual exclusion system, which comprises:

the service unit comprises a plurality of distributed mutual exclusion groups, and the service unit of the mutual exclusion group specifically comprises:

the system comprises a user login module, a service mutual exclusion table and a service mutual exclusion table, wherein the user login module is used for receiving login information which is published to a mutual exclusion group theme with static control authority subscribed by a user according to the session mutual exclusion table of the user when the user logs in, and determining the mutual exclusion authority of the user to the mutual exclusion group according to the login information and the service mutual exclusion table stored by the user;

and the control command execution module is used for receiving the self session identifier and the control command issued by the user after the user determines the mutual exclusion group with the mutual exclusion authority according to the session mutual exclusion table, determining the mutual exclusion authority of the user to the mutual exclusion group according to the session identifier and the service mutual exclusion table, and executing the control command after the user has the mutual exclusion authority of the mutual exclusion group.

An embodiment of the present invention further provides a distributed centerless device-controlled mutex device, including: the device control mutual exclusion system comprises a memory, a processor and a computer program which is stored on the memory and can run on the processor, wherein the computer program realizes the steps of the distributed centerless device control mutual exclusion method when being executed by the processor.

The embodiment of the invention also provides a computer-readable storage medium, wherein an implementation program for information transfer is stored on the computer-readable storage medium, and when the implementation program is executed by a processor, the steps of the distributed centerless equipment control mutual exclusion method are implemented.

By adopting the embodiment of the invention, a completely decentralized mode is realized, so that a degradation mode does not need to be set any more, and any fault mode can ensure that only a single point of fault is adopted, namely, the influence of the fault is only restricted to the fault occurrence position, and the service stop or mode change of the whole system can not be caused. Problems 1 and 2 in the prior art are sufficiently solved. Secondly, by adopting the design of non-service, after the device management service receives the control instruction, the mutual exclusion authority verification is carried out on the control initiator, the control safety is ensured, and the problem 3 in the prior art is solved. In addition, the non-service mode of the embodiment of the invention realizes the local permission retrieval of the client and the server, does not need to carry out bidirectional network communication with the center to check the permission like the traditional scheme, saves the steps of controlling the execution process and also improves the real-time property of the control instruction issuing compared with the traditional scheme.

The foregoing description is only an overview of the technical solutions of the present invention, and the embodiments of the present invention are described below in order to make the technical means of the present invention more clearly understood and to make the above and other objects, features, and advantages of the present invention more clearly understandable.

Drawings

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, and it is obvious that the drawings in the following description are some embodiments of the present invention, and other drawings can be obtained by those skilled in the art without creative efforts.

FIG. 1 is a flow chart of a distributed decentralized device controlled mutual exclusion method according to an embodiment of the present invention;

FIG. 2 is a flow diagram of a user login scenario in accordance with an embodiment of the present invention;

FIG. 3 is a flow diagram of a user initiated control command scenario in accordance with an embodiment of the present invention;

FIG. 4 is a flowchart of a service unsolicited initiation permission handover scenario in accordance with an embodiment of the present invention;

FIG. 5 is a diagram of a distributed decentralized device control mutual exclusion device, according to an embodiment of the present invention.

Detailed Description

The technical solutions of the present invention will be described clearly and completely with reference to the following embodiments, and it should be understood that the described embodiments are some, but not all, embodiments of the present invention. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

In the description of the present invention, it is to be understood that the terms "center", "longitudinal", "lateral", "length", "width", "thickness", "upper", "lower", "front", "rear", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer", "clockwise", "counterclockwise", and the like, indicate orientations and positional relationships based on those shown in the drawings, and are used only for convenience of description and simplicity of description, and do not indicate or imply that the device or element being referred to must have a particular orientation, be constructed and operated in a particular orientation, and thus, should not be considered as limiting the present invention.

Furthermore, the terms "first", "second" and "first" are used for descriptive purposes only and are not to be construed as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Thus, features defined as "first", "second", may explicitly or implicitly include one or more of the described features. In the description of the present invention, "a plurality" means two or more unless specifically defined otherwise. Furthermore, the terms "mounted," "connected," and "connected" are to be construed broadly and may, for example, be fixedly connected, detachably connected, or integrally connected; can be mechanically or electrically connected; they may be connected directly or indirectly through intervening media, or they may be interconnected between two elements. The specific meanings of the above terms in the present invention can be understood in specific cases to those skilled in the art.

Method embodiment

According to the embodiment of the invention, a distributed non-centralized equipment control mutual exclusion method is provided, and the technical scheme of the embodiment of the invention describes a method for quickly realizing control authority mutual exclusion aiming at equipment in a decentralized mode in a completely distributed scene. The following first describes the concept in detail:

for each device, it can be categorized separately from the spatial dimension and the functional dimension. The spatial dimension is classified into positions, that is, a group of devices in the same spatial scene, such as different workshops in a factory, a plurality of stations on a subway line, and the like; the functional dimension is classified into subsystems, namely equipment with functions of completing a set of specific functions, such as a high-voltage power transmission subsystem, a low-voltage power supply subsystem, a lighting subsystem and the like; in industrial practice, from the viewpoint of security control, some critical devices have mutually exclusive control authority requirements.

The mutual exclusion of the control authority means that in the whole system, for the equipment of the same subsystem at the same position at the same time, the control can be performed only by a unique user, and if other users need to perform control, the control authority needs to be explicitly handed over. The embodiment of the invention refers to a group of positions and subsystems with mutual exclusion requirements as a mutual exclusion group.

When a user logs in, a session identifier with system-wide uniqueness is dynamically generated for the session, and the user information, the authority information, the login time, the active time and other contents of the session can be inquired through the session identifier.

Background software services providing support for device control are referred to as device control services (also referred to as simply services), each device control service manages a group of specific devices, and if the managed devices have a requirement for mutual exclusion, the service records a session identifier having a rendering right of a mutual exclusion group to which the managed devices belong, which is referred to as a service mutual exclusion table, as shown in table 1, table 1 is a service mutual exclusion table:

TABLE 1

Session identifier	Position of	Sub-system
			A1	Workshop 1	High pressure
A2	Workshop 2	Illumination device

The exclusive set must have uniqueness, that is, in the above table, two rows are not allowed to exist, and the positions of the two rows are completely consistent with the content of the subsystem; the session identifier is recorded as the current still active session identifier, and if no active session in the current system has the static control authority for a certain mutex group, the session identifier is recorded as NA.

After each user logs in, it will store whether the device of a specific mutex group has control right currently, which is called a session mutex table, as shown in table 2, where table 2 is a session mutex table:

TABLE 2

Whether or not to have mutually exclusive authority	Position of	Sub-system
			Is that	Workshop 1	High pressure
Whether or not	Workshop 2	Low pressure

Like the service mutex table, the mutex group has to be unique, and the table only stores the static control authority actually owned by the user, for example, 6 mutex groups are in total in the whole system, but the login user only has static control authority for 3 groups, and the session mutex table of the user only has 3 rows of records.

In the embodiment of the invention, all message publishing and receiving are processed by a subscribing/publishing mechanism, each mutual exclusion group and session have corresponding subscription themes, a user client subscribes the mutual exclusion group theme with static control authority and publishes related information to the mutual exclusion group theme, and periodically sends keep-alive (keep-alive) information to the corresponding session theme; each service subscribes all conversation topics stored in the current service mutual exclusion table and publishes mutual exclusion authority change information to the mutual exclusion group topics managed by the service.

The technical solutions of the embodiments of the present invention are explained in detail below.

Fig. 1 is a flowchart of a method for controlling mutual exclusion by a distributed decentralized device according to an embodiment of the present invention, and as shown in fig. 1, the method for controlling mutual exclusion by a distributed decentralized device according to an embodiment of the present invention specifically includes:

step 101, receiving login information issued to a subscribed mutual exclusion group theme with static control authority according to a session mutual exclusion table of a user during login, and determining the mutual exclusion authority of the user to the mutual exclusion group by a service for currently managing the mutual exclusion group according to the login information and a service mutual exclusion table stored by the service for currently managing the mutual exclusion group; step 101 specifically includes the following processing:

step 1011, the service managing the mutual exclusion group checks the service mutual exclusion table, if the mutual exclusion group in the service mutual exclusion table is the current unmanned ownership right, the session identifier of the user is updated to the service mutual exclusion table, and the updated session to which the mutual exclusion right belongs is issued to the topic of the mutual exclusion group, so that the user updates the session mutual exclusion table of the user to set the corresponding mutual exclusion group as the owned mutual exclusion right after receiving the information;

step 1012, if the service mutual exclusion table has marked that the current control right of the mutual exclusion group belongs to an existing session, the service of the current management mutual exclusion group notifies the user to inquire whether the user wants to request the control right of the corresponding mutual exclusion group;

step 1013, if the user does not request the control right, the service of the current management mutex group does not perform any processing, and notifies the user to update the session mutex table to set the corresponding mutex group as not having the mutex right;

step 1014, if the new login user requests the control right, the service of the current management mutex group sends a message to the original owner to inquire whether the original owner allows the right to be handed over;

step 1015, if the original owner allows the permission handover, the service currently managing the mutual exclusion group updates the session identifier of the user to the service mutual exclusion table, and issues the session to which the updated mutual exclusion permission belongs to the topic of the mutual exclusion group, so that the new login user updates the session mutual exclusion table of itself to set the corresponding mutual exclusion group as having the mutual exclusion permission after receiving the information, and the original owner updates the session mutual exclusion table of itself to set the corresponding mutual exclusion table as not having the mutual exclusion permission after receiving the information;

step 1016, if the original owner does not respond to the permission handover request within the specified time, the service of the current management mutex group is regarded as the default permission of the original owner for the handover, and step 1015 is executed;

step 1017, if the original owner does not allow the permission to hand over, the service of the current management mutex group does not update the service mutex table, and notifies the user, so that the user sets the corresponding mutex table as not having the mutex permission by setting the session mutex table of the user.

102, after the user determines the mutex group with the mutex authority according to the session mutex table, the service of the corresponding mutex group receives the session identifier and the control command of the user, determines the mutex authority of the user on the mutex group according to the session identifier and the service mutex table, and executes the control command after the user has the mutex authority of the mutex group. Step 102 specifically includes the following processing:

step 1021, after receiving self session identifier and control command issued by user, the service of corresponding mutex group checks whether the session identifier is matched with record in service mutex table;

step 1022, if there is a match, the service of the corresponding exclusive group executes the control action; if the records in the service record table are not matched but are not owned by the current person, executing the control action, updating the corresponding service mutual exclusion table by the service, and notifying all concerned sessions; if the session identifier is not matched and the session identifier recorded in the service record table is other session identifier, the user is informed to initiate an authority transfer application;

step 1023, the service of the corresponding mutual exclusion group receives the authority transfer application initiated by the user and determines whether the user requires forced transfer;

step 1024, the service of the corresponding mutex group informs the current owner that other users initiate permission handover requests, and waits for the response of the original owner;

step 1025, if the original owner does not respond to the handover request within the designated time, the service of the corresponding mutex group considers that the original owner defaults to allow the permission to handover, and starts the permission handover process;

step 1026, during the permission handover, the service of the corresponding mutual exclusion group first updates the session identifier of the new user to the service mutual exclusion table, and then issues the change information in the topic of the mutual exclusion group, so that the user updates the session mutual exclusion table of the user itself after receiving the change information to set the corresponding mutual exclusion group as having the mutual exclusion permission, and the original owner updates the session mutual exclusion table of the user itself to set the corresponding mutual exclusion table as not having the mutual exclusion permission after receiving the information; the corresponding mutual exclusion group executes the corresponding control instruction;

step 1027, if the original owner allows the handover request, the service of the corresponding mutex group executes the step 1026 to start the right handover;

step 1028, if the original owner does not allow the handover request and the new user does not require forced handover, the service of the corresponding mutex group notifies the user of the handover failure, so that the user updates the corresponding mutex group in the session mutex table of the user to not have the mutex right;

step 1029, if the user requests forced handover, the service of the corresponding mutex group checks if the priority of the user is higher than that of the original user, e.g. higher than that of the original user, starting the handover process according to step 1026; if not, notifying the user of the handover failure so that the user should update the corresponding mutex group in the session mutex table of the user to have no mutex right.

In the embodiment of the present invention, in the case of the service initiative permission handover, the following processing is further required: the service of the mutual exclusion group publishes information to the topic of the mutual exclusion group and informs all users subscribing to the topic of the mutual exclusion group to return respective session identifiers; the service of the mutual exclusion group determines the attribution of the mutual exclusion authority of the mutual exclusion group according to the condition of receiving the session identifier, the user priority, the active time and/or the login time.

In the embodiment of the present invention, the condition of the service initiative permission handover specifically includes at least one of the following conditions:

in case 1, a user of an existing mutual exclusion authority logs out, that is, the service of the mutual exclusion group receives log-out information from the existing mutual exclusion authority session topic;

case 2, the service of the mutual exclusion group does not receive keep-alive information from the existing mutual exclusion authority session within the specified time;

in case 3, the service of the mutually exclusive group has just started.

Specifically, the service of the mutual exclusion group determining the attribution of the mutual exclusion authority of the mutual exclusion group according to the condition of receiving the session identifier, the user priority, the active time, and/or the login time specifically includes:

step 1, if the service of the mutual exclusion group does not receive any reply within a period of time, all current login sessions are considered to have no static control authority to the mutual exclusion group, the service of the mutual exclusion group sets a session identifier in a service mutual exclusion table as the current unmanned authority, and the broadcasting process is repeated periodically;

step 2, if the service of the mutual exclusion group only receives a reply within a period of time, the service of the mutual exclusion group selects the replied session identifier as the current owner of the mutual exclusion authority and starts the setting of the mutual exclusion of the authority;

step 3, the service of the mutual exclusion group updates the selected session identifier to a service mutual exclusion table, and publishes mutual exclusion authority change information in the topic of the mutual exclusion group, so that all users concerned about the mutual exclusion group update their own session mutual exclusion table according to the received information;

step 4, if receiving multiple replies, comparing priorities of the multiple replied users, if only one session with the highest priority is available, selecting the session as a current exclusive permission owner, and starting permission exclusive setting according to the step 3;

step 5, if there are a plurality of sessions with the highest priority, comparing the time of sending keep-alive information last time of the sessions, if there is a session which is obviously closer to the current time than the last active time of other sessions, selecting the session as the current exclusive permission owner, and starting the exclusive permission setting according to the step 3; wherein, the condition of judging that the time is obviously close to the current time is that the interval between the last active time of the conversation and other last active times is more than 3 keep-alive information sending intervals;

and 6, if no session which is obviously more active exists, selecting the session with the login time closest to the current time as the current mutual exclusion authority owner from all sufficiently active sessions, and starting the setting of the mutual exclusion of the authorities according to the step 3.

The above technical solutions of the embodiments of the present invention are described in detail below with reference to the accompanying drawings.

The technical scheme of the embodiment of the invention is that under a distributed environment, the mutual exclusion tables dispersedly existing in all the clients and services of the whole system are synchronously updated, so that the whole scheme can be divided into four operations of adding, deleting, changing and searching the mutual exclusion tables; since the participants include two types of user and device management services, each type of participant can actively initiate the above four operations, and therefore, the detailed differentiation is performed for 8 scenes in total.

As the flows of partial scenes have the same part, the 8 scenes are summarized, and 3 flows which can cover the whole scheme are arranged, namely, user login (covering 3 scenes of user addition, service check and service change), user initiation control instructions (covering 4 scenes of user check, user change, service check and service change) and service active initiation permission transfer (covering 5 scenes of user deletion, service addition, service check, service change and service deletion).

The following describes the 3 processes in detail with reference to the accompanying drawings.

Scenario one: user login: fig. 2 is a flowchart of a user login scenario in the embodiment of the present invention, and as shown in fig. 2, the method specifically includes the following processing:

step 201, a user logs in;

step 202, a user item publishes information of a mutual exclusion group subject with static control authority, and publishes the login condition and the session identifier of the user item;

step 203, the service currently managing the mutex group receives the login information issued by the user;

step 204, the service managing the mutex group checks the service mutex table, and determines whether the session identifier of the current mutex group is NA, if yes, step 210 is executed, otherwise, step 205 is executed;

step 205, judging whether the priority of the original user is lower than that of the newly logged-in user, if so, executing step 210, otherwise, executing step 206;

step 206, the service mutual exclusion list marks that the current control right of the mutual exclusion group belongs to an existing session, the service notifies a new login user, inquires whether the user needs to request the control right of the corresponding mutual exclusion group, if so, step 207 is executed, otherwise, step 208 is executed;

step 207, if the new login user requests the control right, the service sends a message to the original owner to inquire whether the original owner allows the right to be handed over; if yes, go to step 210, otherwise, go to step 208; if the original owner does not respond to the permission transfer request within the specified time, the original owner is considered as default to allow the transfer, and step 210 is executed;

step 208, the service does not perform any processing, that is, the service does not update the service mutual exclusion table, and step 209 is executed;

step 209, the new login user updates the session mutual exclusion table to set the corresponding mutual exclusion group as no;

step 210, updating the session identifier of the new login user into a service mutual exclusion table;

step 211, issuing the updated session to which the mutual exclusion authority belongs to the mutual exclusion group topic;

step 212, the new login user updates the session mutual exclusion table of the new login user to set the corresponding mutual exclusion group as yes;

step 213, the original user updates its own session mutual exclusion table to set the corresponding mutual exclusion group as no.

Scenario two: a user initiates a control command, and fig. 3 is a flowchart of a scenario in which the user initiates the control command according to an embodiment of the present invention, and as shown in fig. 3, the following processing is specifically included:

step 301, a user firstly checks a session mutual exclusion table of the user and checks whether the user has a mutual exclusion authority of a mutual exclusion group; if yes, go to step 302, otherwise, go to step 304;

step 302, directly sending the session identifier and the control command of the user to the corresponding service together; after receiving the control instruction, the service checks whether the session identifier is matched with the record in the service mutual exclusion table, and the step aims to avoid the mismatching of the session mutual exclusion table and the service mutual exclusion table caused by network or other faults; if the record is not matched, executing step 311, if the record is not matched but the record in the service record table is NA, executing step 311, and if the record is not matched, executing step 303;

step 303, informing a user to initiate an authority transfer application;

step 304, a user initiates an authority transfer application;

step 305, judging whether the original user makes a corresponding request within the specified time; if yes, go to step 306, otherwise go to step 309;

step 306, judging whether the original user allows the exclusive right handover, if so, executing step 309, otherwise, executing step 307;

step 307, judging whether forced transfer is required; if yes, executing step 308, if the original owner does not allow the handover request and the new user does not require forced handover, the service notifies the new user of the failure of the handover, and the new user shall update the corresponding mutex group in the session mutex table of the new user to be no;

step 308, judging whether the priority of the new user is higher than that of the original user, if so, executing step 309, otherwise, the service notifies the new user of the handover failure, the new user shall update the corresponding mutex group in the session mutex table of the new user to be no, and ending the operation;

309, performing permission transfer, and updating the session identifier of the new user to a service mutual exclusion table by the service;

step 310, the service issues change information in the mutually exclusive group topic, and step 312 and step 313 are executed;

step 311, if matching, executing the control command; if the record in the service record table is not matched but is NA, executing the control command, updating the corresponding service mutual exclusion table by the service, and notifying all concerned sessions;

step 312, after receiving the change information, the new user updates its own session mutual exclusion table to set the corresponding mutual exclusion group as yes;

step 313, after receiving the message, the original owner updates its own session mutual exclusion table to set the corresponding mutual exclusion table to be no.

Scenario three: the service actively initiates permission transfer: fig. 4 is a flowchart of a scenario for handing over a service initiative initiation permission according to an embodiment of the present invention, and as shown in fig. 4, the method specifically includes the following steps:

in steps 401-403, there are three cases that may result in the service actively initiating the right handover:

1. the user of the existing mutual exclusion authority logs out, namely the service receives log-out information from the existing mutual exclusion authority session theme;

2. the service does not receive keep-alive information from the existing mutually exclusive permission session within a specified time;

3. the service has just started;

step 404, when the three situations occur, the service issues information to the mutual exclusion group topic, and notifies all people who concern about the topic to return respective session identifiers;

step 405, determining whether there is a user response within a specified time; if yes, go to step 406, otherwise go to step 416;

step 406, determining whether the number of the reply users is equal to 1, if so, executing step 413, otherwise, executing step 407;

step 407, determining whether the number with the highest priority in the replying users is equal to 1, if so, executing step 414, otherwise, executing step 408;

step 408, judging whether the active time (i.e. the time of sending the keep-alive information last time) of the user with the highest priority is similar, if so, executing step 415, otherwise, executing step 409; wherein the condition for determining that the time is significantly closer to the current time is that the last active time of the session is spaced from other last active times by more than 3 keep-alive message transmission intervals;

step 409, selecting the user with the closest active time;

step 410, the service updates the service mutual exclusion table to the selected user;

step 411, the service issues mutual exclusion information;

step 412, the user updates the session mutual exclusion table and ends the operation; in addition, if the service is off-line, the judgment can be carried out by not contacting the corresponding service, and the control instruction cannot be issued necessarily, so that no operation is needed.

Step 413, selecting the only reply user, and executing step 410;

step 414, selecting the only user with the highest priority, and executing step 410;

step 415, selecting the user with the closest hour of the calendar, and executing step 410;

step 416, if the service does not receive any reply within a period of time, it is determined that all current login sessions do not have the static control authority for the mutex group, the service sets the session identifier in the service mutex table to be NA, and repeats the broadcasting process periodically;

in summary, with the technical solution of the embodiment of the present invention, a completely decentralized manner is implemented, so that a degraded mode is not required to be set, and in any failure manner, it can be ensured that only a single point of failure is performed, that is, the effect of the failure is only constrained to the failure occurrence location, and the system-wide outage or mode change is not caused. Problems 1 and 2 in the prior art are sufficiently solved. Secondly, by adopting the design of non-service, after the device management service receives the control instruction, the mutual exclusion authority verification is carried out on the control initiator, the control safety is ensured, and the problem 3 in the prior art is solved. In addition, the non-service mode of the embodiment of the invention realizes the local permission retrieval of the client and the server, does not need to carry out bidirectional network communication with the center to check the permission like the traditional scheme, saves the steps of controlling the execution process and also improves the real-time property of the control instruction issuing compared with the traditional scheme.

System embodiment

According to an embodiment of the present invention, a distributed decentralization device control mutual exclusion system is provided, and the distributed decentralization device control mutual exclusion system according to the embodiment of the present invention specifically includes: a plurality of distributed mutually exclusive groups of service units, each mutually exclusive group of service units comprising:

the system comprises a user login module, a service mutual exclusion table and a service mutual exclusion table, wherein the user login module is used for receiving login information which is published to a mutual exclusion group theme with static control authority subscribed by a user according to the session mutual exclusion table of the user when the user logs in, and determining the mutual exclusion authority of the user to the mutual exclusion group according to the login information and the service mutual exclusion table stored by the user; the user login module is specifically configured to:

checking a service mutual exclusion table, if the mutual exclusion group in the service mutual exclusion table is the current unmanned ownership right, updating a session identifier of a user into the service mutual exclusion table, and issuing a session to which the updated mutual exclusion right belongs to the topic of the mutual exclusion group, so that the user updates the session mutual exclusion table of the user to set the corresponding mutual exclusion group as the ownership right after receiving the information;

if the service mutual exclusion list marks that the current control right of the mutual exclusion group belongs to an existing session, the service mutual exclusion list informs the user to inquire whether the user needs to request the control right of the corresponding mutual exclusion group;

if the user does not request the control right, no processing is carried out, and the user is informed to update the session mutual exclusion table to set the corresponding mutual exclusion group as not having the mutual exclusion right;

if the new login user requests the control right, sending a message to the original owner to inquire whether the original owner allows the right transfer;

if the original owner allows the authority to be handed over, the session identifier of the user is updated to the service mutual exclusion table, and the session to which the updated mutual exclusion authority belongs is issued to the topic of the mutual exclusion group, so that the new login user updates the session mutual exclusion table of the original owner to set the corresponding mutual exclusion group as possessing the mutual exclusion authority after receiving the information, and the original owner updates the session mutual exclusion table of the original owner to set the corresponding mutual exclusion table as not possessing the mutual exclusion authority after receiving the information;

if the original owner does not respond to the permission transfer request within the appointed time, the service for managing the mutual exclusion group currently is regarded as the default permission transfer of the original owner, the session identifier of the user is updated to the service mutual exclusion table, and the updated session to which the mutual exclusion permission belongs is issued to the topic of the mutual exclusion group, so that the new login user updates the session table of the original owner to set the corresponding mutual exclusion group as the owned mutual exclusion permission after receiving the information, and the original owner updates the session mutual exclusion table of the original owner to set the corresponding mutual exclusion table as the owned mutual exclusion permission after receiving the information;

if the original owner does not allow the authority to be handed over, the service mutual exclusion table is not updated, and the user is informed, so that the user sets the corresponding mutual exclusion table as the one without the mutual exclusion authority by setting the session mutual exclusion table of the user.

And the control command execution module is used for receiving the self session identifier and the control command issued by the user after the user determines the mutual exclusion group with the mutual exclusion authority according to the session mutual exclusion table, determining the mutual exclusion authority of the user to the mutual exclusion group according to the session identifier and the service mutual exclusion table, and executing the control command after the user has the mutual exclusion authority of the mutual exclusion group. The control command execution module is specifically configured to:

after receiving a session identifier and a control command of a user, checking whether the session identifier is matched with a record in a service mutual exclusion table;

if so, executing a control action; if the records in the service record table are not matched but are not owned by the current person, executing the control action, updating the corresponding service mutual exclusion table by the service, and notifying all concerned sessions; if the session identifier is not matched and the session identifier recorded in the service record table is other session identifier, the user is informed to initiate an authority transfer application;

receiving an authority transfer application initiated by a user and determining whether the user requires forced transfer or not;

informing the current owner that other users initiate permission transfer requests, and waiting for the response of the original owner;

if the original owner does not respond to the transfer request within the appointed time, the original owner is considered to allow the permission to transfer by default, and the permission transfer process is started;

when the authority is handed over, firstly, the session identifier of a new user is updated to the service mutual exclusion table, and then, the change information is issued in the theme of the mutual exclusion group, so that the user updates the session mutual exclusion table of the user to set the corresponding mutual exclusion group as the owned mutual exclusion authority after receiving the change information, and the original owner updates the session mutual exclusion table of the user to set the corresponding mutual exclusion table as the unowned mutual exclusion authority after receiving the information; the corresponding mutual exclusion group executes the corresponding control instruction;

if the original owner allows the transfer request, the session identifier of the new user is updated to the service mutual exclusion table, and then the change information is issued in the theme of the mutual exclusion group, so that the user updates the session mutual exclusion table of the user to set the corresponding mutual exclusion group as the owned mutual exclusion authority after receiving the change information, and the original owner updates the session mutual exclusion table of the user to set the corresponding mutual exclusion table as the non-owned mutual exclusion authority after receiving the information; the corresponding mutual exclusion group executes the corresponding control instruction;

if the original owner does not allow the handover request and the new user does not require forced handover, notifying the user of the handover failure so that the user updates the corresponding mutex group in the session mutex table of the user to not own the mutex authority;

if the user requires forced transfer, checking whether the priority of the user is higher than that of the original user, if so, updating the session identifier of the new user to a service mutual exclusion table, and then issuing change information in a mutual exclusion group theme, so that the user updates the session mutual exclusion table of the user to set a corresponding mutual exclusion group as a owned mutual exclusion authority after receiving the change information, and the original owner updates the session mutual exclusion table of the user to set the corresponding mutual exclusion table as a non-owned mutual exclusion authority after receiving the message; the corresponding mutual exclusion group executes the corresponding control instruction; if not, notifying the user of the handover failure so that the user should update the corresponding mutex group in the session mutex table of the user to have no mutex right.

In an embodiment of the present invention, the system further includes:

the active authority transfer module is used for issuing information to the exclusive group theme under the condition of service active authority transfer and informing all users subscribing the exclusive group theme to return respective session identifiers; and determining attribution of the mutual exclusion authority of the mutual exclusion group according to the condition of receiving the session identifier, the user priority, the active time and/or the login time. The condition of the service initiative permission handover specifically includes at least one of the following conditions:

in case 3, the service of the mutually exclusive group has just started.

The active permission handover module is specifically configured to:

if the service of the mutual exclusion group does not receive any reply within a period of time, all the current login sessions are considered to have no static control authority to the mutual exclusion group, the session identifier in the service mutual exclusion table is set as the current unmanned authority, and the broadcasting process is repeated periodically;

if the service of the mutual exclusion group only receives a reply within a period of time, selecting the replied session identifier as the current mutual exclusion authority owner, and starting the setting of the mutual exclusion of the authority;

updating the selected session identifier to a service mutual exclusion table, and issuing mutual exclusion authority change information in a mutual exclusion group subject so that all users concerned about the mutual exclusion group update their own session mutual exclusion table according to the received information;

if receiving multiple replies, comparing the priorities of the multiple replied users, if only one session with the highest priority is available, selecting the session as the current mutual exclusion authority owner, updating the selected session identifier to a service mutual exclusion list, and issuing mutual exclusion authority change information in a mutual exclusion group subject so that all users concerned with the mutual exclusion group update their own session mutual exclusion list according to the received information;

if the number of sessions with the highest priority is multiple, comparing the time of sending keep-alive information of the sessions last time, if one session is obviously closer to the current time than the last active time of other sessions, selecting the session as a current mutual exclusion authority owner, updating the selected session identifier to a service mutual exclusion table, and issuing mutual exclusion authority change information in a mutual exclusion group subject so that all users concerned with the mutual exclusion group update their own session mutual exclusion table according to the received information; wherein, the condition of judging that the time is obviously close to the current time is that the interval between the last active time of the conversation and other last active times is more than 3 keep-alive information sending intervals;

if no obviously more active session exists, selecting the session with the login time closest to the current time from all sufficiently active sessions as the current mutual exclusion authority owner, updating the selected session identifier to the service mutual exclusion table, and issuing mutual exclusion authority change information in the topic of the mutual exclusion group, so that all users concerned with the mutual exclusion group update the own session mutual exclusion table according to the received information.

The embodiment of the present invention is a system embodiment corresponding to the above method embodiment, and specific operations of each module may be understood with reference to the description of the method embodiment, which is not described herein again.

Apparatus embodiment one

An embodiment of the present invention provides a distributed centerless device controlled mutex device, as shown in fig. 5, including: a memory 50, a processor 52 and a computer program stored on the memory 50 and executable on the processor 52, which computer program, when executed by the processor 52, carries out the following method steps:

in case 3, the service of the mutually exclusive group has just started.

Device embodiment II

The embodiment of the present invention provides a computer-readable storage medium, on which an implementation program for information transmission is stored, and when being executed by the processor 52, the implementation program implements the following method steps:

in case 3, the service of the mutually exclusive group has just started.

The computer-readable storage medium of this embodiment includes, but is not limited to: ROM, RAM, magnetic or optical disks, and the like.

In summary, the embodiments of the present invention implement a completely decentralized manner, so that a degraded mode is not required to be set, and any failure manner can ensure that only a single point of failure is performed, that is, the effect of the failure is only constrained to the failure occurrence location, and the system-wide outage or mode change is not caused. Problems 1 and 2 in the prior art are sufficiently solved. Secondly, by adopting the design of non-service, after the device management service receives the control instruction, the mutual exclusion authority verification is carried out on the control initiator, the control safety is ensured, and the problem 3 in the prior art is solved. In addition, the non-service mode of the embodiment of the invention realizes the local permission retrieval of the client and the server, does not need to carry out bidirectional network communication with the center to check the permission like the traditional scheme, saves the steps of controlling the execution process and also improves the real-time property of the control instruction issuing compared with the traditional scheme.

It will be apparent to those skilled in the art that the modules or steps of the present invention described above may be implemented by a general purpose computing device, they may be centralized on a single computing device or distributed across a network of multiple computing devices, and alternatively, they may be implemented by program code executable by a computing device, such that they may be stored in a storage device and executed by a computing device, and in some cases, the steps shown or described may be performed in an order different than that described herein, or they may be separately fabricated into individual integrated circuit modules, or multiple ones of them may be fabricated into a single integrated circuit module. Thus, the present invention is not limited to any specific combination of hardware and software.

Finally, it should be noted that: the above embodiments are only used to illustrate the technical solution of the present invention, and not to limit the same; while the invention has been described in detail and with reference to the foregoing embodiments, it will be understood by those skilled in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some or all of the technical features may be equivalently replaced; and the modifications or the substitutions do not make the essence of the corresponding technical solutions depart from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A distributed decentralization equipment control mutual exclusion method is characterized by comprising the following steps:

receiving login information issued to a subscribed mutual exclusion group theme with static control permission by a user according to a session mutual exclusion table of the user during login, and determining the mutual exclusion permission of the user to the mutual exclusion group by a service currently managing the mutual exclusion group according to the login information and a service mutual exclusion table stored by the service currently;

after a user determines a mutual exclusion group with mutual exclusion authority according to the session mutual exclusion table, the service of the corresponding mutual exclusion group receives a session identifier and a control command of the user, the session identifier and the service mutual exclusion table determine the mutual exclusion authority of the user to the mutual exclusion group, and the control command is executed after the user has the mutual exclusion authority of the mutual exclusion group.

2. The method of claim 1, further comprising:

under the condition of service active authority transfer, the service of the mutual exclusion group issues information to the topic of the mutual exclusion group and informs all users subscribing to the topic of the mutual exclusion group to return respective session identifiers;

and the service of the mutual exclusion group determines the attribution of the mutual exclusion authority of the mutual exclusion group according to the condition of receiving the session identifier, the user priority, the active time and/or the login time.

3. The method as claimed in claim 1, wherein the step of determining the mutual exclusion authority of the user to the mutually exclusive group according to the login information and the service mutual exclusion table stored therein by the service currently managing the mutually exclusive group specifically comprises:

step 1, currently managing the service check service mutual exclusion list of the mutual exclusion group, if the mutual exclusion group in the service mutual exclusion list is the current unmanned ownership right, updating the session identifier of the user to the service mutual exclusion list, and issuing the updated session to which the mutual exclusion right belongs to the topic of the mutual exclusion group, so that the user updates the session list of the user to set the corresponding mutual exclusion group as the owned mutual exclusion right after receiving the information;

step 2, if the service mutual exclusion list marks that the current control right of the mutual exclusion group belongs to an existing session, the service managing the mutual exclusion group currently informs the user to inquire whether the user needs to request the control right of the corresponding mutual exclusion group;

step 3, if the user does not request the control right, the service for managing the mutual exclusion group does not carry out any treatment currently, and the user is informed to update the session mutual exclusion table to set the corresponding mutual exclusion group as not having the mutual exclusion right;

step 4, if the new login user requests the control right, the service currently managing the mutex group sends a message to the original owner to inquire whether the original owner allows the permission to be handed over;

step 5, if the original owner allows the authority to be handed over, the service currently managing the mutual exclusion group updates the session identifier of the user into a service mutual exclusion table, and issues the session to which the updated mutual exclusion authority belongs to the topic of the mutual exclusion group, so that the newly logged-in user updates the session mutual exclusion table of the original owner to set the corresponding mutual exclusion group as having the mutual exclusion authority after receiving the information, and the original owner updates the session mutual exclusion table of the original owner to set the corresponding mutual exclusion table as not having the mutual exclusion authority after receiving the information;

step 6, if the original owner does not respond to the permission transfer request within the appointed time, the service for managing the mutex group currently is regarded as the default permission transfer of the original owner, and step 5 is executed;

and 7, if the original owner does not allow the permission to be handed over, the service for currently managing the mutual exclusion group does not update the service mutual exclusion table, and notifies the user, so that the user sets the corresponding mutual exclusion table as the one without the mutual exclusion permission by setting the session mutual exclusion table of the user.

4. The method of claim 1, wherein determining the mutual exclusion authority of the user for the mutually exclusive group according to the session identifier and the service mutual exclusion table, and after the user has the mutual exclusion authority of the mutually exclusive group, executing the control command specifically includes:

step 1, after receiving self session identifier and control command issued by a user, the service of a corresponding mutex group checks whether the session identifier is matched with records in a service mutex table;

step 2, if the service of the corresponding mutual exclusion group is matched, executing a control action; if the records in the service record table are not matched but are not owned by the current person, executing the control action, updating the corresponding service mutual exclusion table by the service, and notifying all concerned sessions; if the session identifier is not matched and the session identifier recorded in the service record table is other session identifier, the user is informed to initiate an authority transfer application;

step 3, the service of the corresponding mutual exclusion group receives the authority transfer application initiated by the user and determines whether the user requires forced transfer;

step 4, the service of the corresponding mutual exclusion group informs the current owner that other users initiate permission handover requests, and waits for the response of the original owner;

step 5, if the original owner does not respond to the transfer request within the designated time, the corresponding service of the mutual exclusion group considers that the original owner defaults to allow the permission to transfer, and starts the permission transfer process;

step 6, when the authority is handed over, the service of the corresponding mutual exclusion group firstly updates the session identifier of the new user to the service mutual exclusion table, and then releases the change information in the topic of the mutual exclusion group, so that the user updates the session mutual exclusion table of the user to set the corresponding mutual exclusion group as the owned mutual exclusion authority after receiving the change information, and the original owner updates the session mutual exclusion table of the user to set the corresponding mutual exclusion table as the unopposed mutual exclusion authority after receiving the information; the corresponding mutual exclusion group executes the corresponding control instruction;

step 7, if the original owner allows the transfer request, the corresponding service of the mutual exclusion group executes the above step 6 to start the authority transfer;

step 8, if the original owner does not allow the handover request and the new user does not require forced handover, the service of the corresponding mutex group notifies the user of the failure of the handover so that the user updates the corresponding mutex group in the session mutex table of the user to have no mutex authority;

step 9, if the user requires forced handover, the service of the corresponding mutex group checks whether the priority of the user is higher than that of the original user, if so, the handover process is started according to step 6; if not, the user is informed of the handover failure, so that the user should update the corresponding mutex group in the session mutex table of the user to have no mutex right.

5. The method according to claim 2, wherein the condition of the service initiative permission handover specifically comprises at least one of the following:

the user of the existing mutual exclusion authority logs out, namely the service of the mutual exclusion group receives log-out information from the conversation theme of the existing mutual exclusion authority;

the service of the mutual exclusion group does not receive keep-alive information from the existing mutual exclusion authority session within the specified time;

the service of the mutually exclusive group has just started.

6. The method according to claim 2, wherein the service of the mutually exclusive group determining attribution of the mutually exclusive right of the mutually exclusive group according to the condition of receiving the session identifier, the user priority, the active time, and/or the login time specifically comprises:

7. A distributed decentralization equipment control mutual exclusion system is characterized by comprising a plurality of distributed mutual exclusion group service units, wherein the service units of the mutual exclusion group specifically comprise:

and the control command execution module is used for receiving the self session identifier and the control command issued by the user after the user determines the mutex group with the mutex authority according to the session mutex table, determining the mutex authority of the user on the mutex group according to the session identifier and the service mutex table, and executing the control command after the user has the mutex authority of the mutex group.

8. The system of claim 7, further comprising:

the active authority transfer module is used for issuing information to the exclusive group theme under the condition of service active authority transfer and informing all users subscribing the exclusive group theme to return respective session identifiers; and determining attribution of the mutual exclusion authority of the mutual exclusion group according to the condition of receiving the session identifier, the user priority, the active time and/or the login time.

9. The system of claim 7, wherein the user login module is specifically configured to:

checking a service mutual exclusion table, if the mutual exclusion group in the service mutual exclusion table is the current unmanned ownership right, updating the session identifier of the user into the service mutual exclusion table, and issuing the updated session to which the mutual exclusion right belongs to the topic of the mutual exclusion group, so that the user updates the session mutual exclusion table of the user to set the corresponding mutual exclusion group as the ownership right after receiving the information;

if the current control right of the mutual exclusion group is marked in the service mutual exclusion table to belong to an existing session, the user is informed to inquire whether the user needs to request the control right of the corresponding mutual exclusion group;

if the user does not request the control right, no processing is carried out, and the user is informed to update the session mutual exclusion table to set a corresponding mutual exclusion group as not having mutual exclusion authority;

if the original owner allows the authority to be handed over, the session identifier of the user is updated to a service mutual exclusion table, and the session to which the updated mutual exclusion authority belongs is issued to the topic of the mutual exclusion group, so that the new login user updates the session mutual exclusion table of the original owner to set the corresponding mutual exclusion group as possessing the mutual exclusion authority after receiving the information, and the original owner updates the session mutual exclusion table of the original owner to set the corresponding mutual exclusion table as not possessing the mutual exclusion authority after receiving the information;

if the original owner does not respond to the permission transfer request within the appointed time, the service for managing the mutual exclusion group is regarded as the default permission transfer of the original owner, the session identifier of the user is updated to a service mutual exclusion table, and the updated session to which the mutual exclusion permission belongs is issued to the topic of the mutual exclusion group, so that after the new login user receives the information, the session mutual exclusion table of the new login user is updated to set the corresponding mutual exclusion group as the owned mutual exclusion permission, and after the original owner receives the information, the session mutual exclusion table of the new login user is updated to set the corresponding mutual exclusion table as the owned mutual exclusion permission;

and if the original owner does not allow the permission to be handed over, the service mutual exclusion table is not updated, and the user is informed, so that the user sets the corresponding mutual exclusion table as the user not to have the mutual exclusion permission.

10. The system of claim 7, wherein the control command execution module is specifically configured to:

if the original owner does not allow the handover request and the new user does not require forced handover, notifying the user of the handover failure so that the user updates a corresponding mutex group in a session mutex table of the user to have no mutex permission;

if the user requires forced transfer, checking whether the priority of the user is higher than that of the original user, if so, updating the session identifier of the new user to a service mutual exclusion table, and then issuing change information in a mutual exclusion group theme, so that the user updates the session mutual exclusion table of the user to set a corresponding mutual exclusion group as an owned mutual exclusion authority after receiving the change information, and the original owner updates the session mutual exclusion table of the user to set the corresponding mutual exclusion table as a non-owned mutual exclusion authority after receiving the message; the corresponding mutual exclusion group executes the corresponding control instruction; if not, the user is informed of the handover failure, so that the user should update the corresponding mutex group in the session mutex table of the user to have no mutex right.

11. The system of claim 8, wherein the condition of the service initiative permission handover specifically comprises at least one of the following:

the service of the mutually exclusive group has just started.

12. The system of claim 8, wherein the proactive privilege handover module is specifically configured to:

13. A distributed decentralized device control mutual exclusion device, comprising: memory, a processor and a computer program stored on the memory and executable on the processor, the computer program, when executed by the processor, implementing the steps of the distributed decentralised device controlled mutual exclusion method of any of claims 1 to 6.

14. A computer-readable storage medium, characterized in that the computer-readable storage medium has stored thereon an implementation program of information transfer, which when executed by a processor implements the steps of the distributed decentralised device controlled mutual exclusion system method of any of claims 1-6.