Multi-account safety management method and system based on mobile energy storage charging pile

Abstract

The invention relates to a multi-account security management method and system based on a mobile energy storage charging pile. According to the method, a multi-level user account system and a dynamic authority management mechanism are established, a dynamic token carrying authority attributes is generated through encryption verification to achieve access control, user operation is captured in real time to generate log data with an identity label, the log data are synchronized with a cloud end, and an equipment control instruction is generated in combination with Internet of Things data collection and authority verification. Meanwhile, authority rules are dynamically updated, whole-course tracing of operation behaviors of the charging pile system, real-time effectiveness of authority change and linkage management and control of equipment states and user authorities are achieved, and the problem that potential safety hazards are caused by extensive authority control, difficult operation tracing and authority strategy lagging of a traditional charging pile management system is effectively solved.

Description

Technical Field

[0001] The present invention belongs to the technical field of charging piles, and in particular relates to a multi-account security management method and system based on a mobile energy storage charging pile. Background Art

[0002] With the rapid development of new energy vehicles, mobile energy storage charging stations are increasingly being used in public spaces as flexible charging facilities. Traditional charging station management systems typically employ a single account management model with coarse-grained permission control, making them incapable of addressing the security management needs of collaborative operations involving multiple operators.

[0003] Existing technologies lack a comprehensive traceability mechanism for operators modifying charging pile parameters, making it impossible to quickly locate the responsible party when configuration errors or safety incidents occur. Remote control command authorization verification is often based solely on static account and password authentication, posing the risk of malicious interception and unauthorized device manipulation. Furthermore, the separation of charging pile operating status data and user permission management prevents automatic association of operator identities when handling abnormal conditions. Furthermore, permission changes require manual configuration updates on each device, which can easily lead to delays in permission policy execution in distributed device deployment scenarios. Summary of the Invention

[0004] Based on this, it is necessary to provide a multi-account security management method and system based on a mobile energy storage charging pile to address the above technical problems.

[0005] In a first aspect, the present application provides a multi-account security management method based on a mobile energy storage charging pile, comprising:

[0006] S1. Based on the permission level mapping rules, create and configure multi-level user accounts through the database to obtain a user table; wherein the user table includes user ID, permission level and permission scope;

[0007] S2. Encrypt and verify the login credentials entered by the user. If the verification is successful, a dynamic token with permission attributes is generated based on the user ID in the user table, and the web configuration interface is rendered according to the permission attributes in the dynamic token.

[0008] S3. Capture user operation requests through the web configuration interface and verify the legitimacy of the user operation requests based on the permission range in the user table. Once the verification is passed, an operation log is generated and synchronized to the cloud for storage. The operation log includes the operation user ID, parameter name, and changed value.

[0009] S4. Collect sensor data from the charging pile through the Internet of Things communication protocol, filter the sensor data for anomalies to generate a standardized status data packet, associate the standardized status data packet with the permission attributes in the user table, and upload it to the cloud;

[0010] S5. Verify the permission level in the user table based on the control command issued by the cloud. If the verification is successful, generate a legal control command and send the legal control command to the target charging pile; the control command is generated based on the operation log and the standardized status data packet;

[0011] S6. Update the permission level mapping rule based on the permission update request of the user table and trigger the refresh of the web configuration interface.

[0012] In a second aspect, the present application also provides a multi-account security management system based on a mobile energy storage charging pile, including:

[0013] The account management module is used to create and configure multi-level user accounts through the database based on the permission level mapping rules to obtain a user table; wherein the user table includes user ID, permission level and permission scope;

[0014] The authentication and token generation module is used to encrypt and verify the login credentials entered by the user. After the verification is passed, a dynamic token with permission attributes is generated based on the user ID in the user table, and the web configuration interface is rendered according to the permission attributes in the dynamic token;

[0015] The operation request processing module is used to capture user operation requests through the web configuration interface, verify the legitimacy of the user operation request based on the permission range in the user table, generate an operation log after verification, and synchronize the operation log to the cloud for storage; the operation log includes the operation user ID, parameter name, and changed value;

[0016] The data acquisition and processing module is used to collect sensor data from charging piles through the Internet of Things communication protocol, filter out abnormalities in the sensor data to generate standardized status data packets, associate the standardized status data packets with the permission attributes in the user table, and upload them to the cloud;

[0017] The control instruction verification module is used to verify the permission level in the user table based on the control instructions issued by the cloud. Once the verification is passed, a legal control instruction is generated and sent to the target charging pile. The control instruction is generated based on the operation log and the standardized status data packet.

[0018] The permission update and interface refresh module is used to update the permission hierarchy mapping rules based on the permission update request of the user table and trigger the refresh of the Web configuration interface.

[0019] In a third aspect, the present application also provides a computer device comprising a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, it implements a multi-account security management method based on a mobile energy storage charging pile as in the first aspect.

[0020] In a fourth aspect, the present application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements a multi-account security management method based on a mobile energy storage charging pile as in the first aspect.

[0021] The above-mentioned multi-account security management method and system based on mobile energy storage charging piles establishes a multi-level user account system and a dynamic permission management mechanism, uses encryption verification to generate dynamic tokens with permission attributes to achieve access control, captures user operations in real time to generate log data with identity identification and synchronizes it with the cloud, combines IoT data collection and permission verification to generate device control instructions, and dynamically updates permission rules at the same time, realizing full traceability of charging pile system operation behavior, real-time effectiveness of permission changes, and linkage management and control of device status and user permissions, effectively solving the security risks caused by the extensive permission control, difficult operation tracing, and lagging permission strategy of traditional charging pile management systems. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the following briefly introduces the drawings required for use in the embodiments or related technical descriptions. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0023] Figure 1 A flowchart of a multi-account security management method based on a mobile energy storage charging pile provided by the present invention;

[0024] Figure 2 A schematic diagram of a flow chart for generating a user table in an optional embodiment of the present invention;

[0025] Figure 3 A schematic diagram of a process for generating a JSON Web Token in an optional embodiment of the present invention;

[0026] Figure 4 This is a structural diagram of a multi-account security management system based on a mobile energy storage charging pile provided by the present invention. DETAILED DESCRIPTION

[0027] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0028] refer to Figure 1, which presents a flow chart of a multi-account security management method based on a mobile energy storage charging pile provided by this application, the method comprising the following steps:

[0029] S1. Based on the permission level mapping rules, create and configure multi-level user accounts through the database to obtain a user table; wherein the user table includes user ID, permission level and permission scope.

[0030] Specifically, the permission hierarchy mapping rules mentioned in this step refer to the pre-set permission ranges and levels corresponding to different levels of users based on the actual needs of charging pile management and operation. For example, the super administrator with the highest authority can perform all operations such as creating, deleting, and modifying permissions for user accounts; ordinary administrators can perform parameter configuration and status monitoring for a specific area or a specific number of charging piles; while ordinary operators only have the authority to view the status of charging piles and execute simple remote control commands. According to this rule, user accounts are created and configured in the database. The database can be a relational database such as MySQL, PostgreSQL, etc., or a non-relational database such as MongoDB, etc., and can be selected based on the actual data storage scale and performance requirements.

[0031] Key fields in the user table may include user ID (used to uniquely identify each user), permission level (a number or specific label indicates the user's permission level, such as super administrator is level 1, ordinary administrator is level 2, ordinary operator is level 3, etc.) and permission scope (specifies the specific functional modules and operation objects that each user can access and modify in the charging pile management system, such as the charging pile area number allowed to be accessed, the configurable parameter type, etc.).

[0032] S2. Encrypt and verify the login credentials entered by the user. If the verification is passed, a dynamic token with permission attributes is generated based on the user ID in the user table, and the web configuration interface is rendered according to the permission attributes in the dynamic token.

[0033] Specifically, when a user logs into the system, they need to enter login credentials, such as a username and password. These login credentials are then encrypted and verified. The purpose of encryption verification is to ensure that the user's login information is not stolen or tampered with during the transmission and verification process. The method used can be to irreversibly encrypt the password based on a hash algorithm (such as MD5, SHA-1, SHA-256, etc.). That is, the password entered by the user is calculated through a hash function to obtain a digest value, and then compared with the password digest corresponding to the username pre-stored in the database. If the verification is successful, it means that the identity of the logged-in user is legal. At this time, a dynamic token with permission attributes will be generated based on the user ID in the user table.

[0034] A dynamic token is a time-sensitive electronic credential that can be implemented using technologies such as JWT (JSON Web Token). It contains user permission attributes, such as permission level and permission scope. The web configuration interface is rendered based on the permission attributes in the dynamic token. That is, the web configuration interface will dynamically display or hide corresponding functional modules and operation options based on the permission information in the token, so that users with different permission levels can only see and operate the authorized functional parts after logging in, thereby realizing personalized interface display and permission control. For example, the interface after an ordinary operator logs in may only display basic status information of the charging pile and a simple remote start and stop control button, while the interface of the super administrator will display a complete set of functional modules including user management, system configuration, data statistical analysis, etc.

[0035] S3. Capture user operation requests through the web configuration interface, verify the legitimacy of the user operation requests based on the permission range in the user table, generate operation logs after verification, and synchronize the operation logs to the cloud for storage; the operation logs include the operation user ID, parameter name, and changed value.

[0036] Specifically, through the Web configuration interface, it is possible to capture operation requests initiated by users, such as modifications to charging pile parameters (including charging power adjustment, charging time setting, fault threshold setting, etc.), remote control instructions (such as starting charging, stopping charging, restarting the charging pile, etc.). After receiving the operation request, the legitimacy of the user's operation request is verified based on the authority range in the user table. Specifically, it is to check whether the authority range corresponding to the user ID that issued the operation request includes the functional modules and operation objects involved in the operation. For example, a user tries to modify the charging power parameters of a specific charging pile. At this time, it is checked whether the user has the authority to modify the parameters of the charging pile. If the verification is successful, it means that the operation is legal, and an operation log is generated.

[0037] Operation logs can include information such as the user ID (to clearly identify the user who performed the operation), parameter names (such as the specific modified parameters such as charging power and charging time), and change values ​​(the specific values ​​before and after the parameter modification, such as changing the charging power from 30kW to 50kW). The purpose of synchronizing operation logs to the cloud for storage is to achieve centralized data management and long-term preservation, facilitating subsequent operation audits, troubleshooting, and accountability. Cloud storage can use cloud database services such as Alibaba Cloud RDS and Tencent Cloud Database.

[0038] S4. Collect sensor data from the charging pile through the Internet of Things communication protocol, filter the sensor data for anomalies to generate a standardized status data packet, associate the standardized status data packet with the permission attributes in the user table, and upload it to the cloud.

[0039] Specifically, the sensor data of the charging pile is collected through the Internet of Things communication protocol, such as MQTT (Message Queuing Telemetry Transport), CoAP (Constrained Application Protocol) or HTTP / HTTPS. The sensors on the charging pile can monitor various status information in real time, such as operating parameters such as voltage, current, temperature, and power, as well as physical status information such as the access control status of the charging pile and the connection status of the gun head. The collected sensor data often contain some abnormal values ​​or noise data, such as instantaneous error readings caused by sensor failure, garbled data caused by communication interference, etc. Therefore, these raw sensor data are filtered for abnormalities. Technical means such as statistical methods (such as eliminating values ​​that exceed the set confidence interval) and rule-based judgments (such as setting upper and lower thresholds based on the normal operating parameter range of the charging pile to filter out data that exceeds the threshold) can be used to remove abnormal data, thereby obtaining a standardized status data packet. The standardized status data packet contains the accurate status information of the charging pile after cleaning and sorting, and then associates it with the permission attributes in the user table. This association can be achieved by adding the corresponding user permission identification field to the data packet, or by establishing a mapping relationship between data and user permissions when storing it in the cloud. Uploading the associated data to the cloud not only enables real-time monitoring of the charging pile status and historical data storage, but also provides a foundation for subsequent permission-based operation control and data analysis.

[0040] S5. Verify the permission level in the user table based on the control instructions sent from the cloud. After verification, generate a legal control instruction and send the legal control instruction to the target charging pile; wherein, the control instruction is generated based on the operation log and the standardized status data packet.

[0041] Specifically, the cloud generates corresponding control instructions according to the preset business logic rules based on the received standardized status data packets and operation logs. For example, when the operation log shows that a user with legal authority has issued an operation request to modify the parameters of the charging pile through the Web configuration interface, and the standardized status data packet indicates that the charging pile is currently in a configurable state (such as no charging task in progress, operating parameters such as temperature are within a safe range, etc.), the cloud will generate the corresponding control instruction to implement the parameter modification operation. After generating the control instruction, first verify whether the permission level in the user table meets the requirements for executing the control instruction to ensure that only users with sufficient authority can trigger the control behavior of the charging pile. After the verification is passed, a legal control instruction will be generated and sent to the target charging pile to realize remote operation and control of the charging pile, such as parameter update, remote start and stop, etc., so as to achieve the purpose of convenient charging pile operation and maintenance management.

[0042] S6. Update the permission level mapping rule based on the permission update request of the user table and trigger the refresh of the web configuration interface.

[0043] Specifically, when a permission update request based on the user table is received, this may be due to a user permission change requirement caused by internal personnel position adjustments, new additions, or resignations. At this time, the relevant permission information in the user table is updated according to the new permission hierarchy mapping rules, including permission level, permission scope, etc. After the permission update is completed, a refresh operation of the Web configuration interface will be triggered, so that the Web configuration interface after the user logs in can immediately reflect the latest permission settings, ensuring that the functional modules and operation options seen by the user match the updated permissions, thereby maintaining the effectiveness and accuracy of the entire multi-account security management method and realizing a dynamic permission management and user operation control mechanism.

[0044] The above-mentioned multi-account security management method based on mobile energy storage charging piles establishes a multi-level user account system and a dynamic permission management mechanism, uses encryption verification to generate dynamic tokens with permission attributes to achieve access control, captures user operations in real time to generate log data with identity identification and synchronizes it with the cloud, combines IoT data collection and permission verification to generate device control instructions, and dynamically updates permission rules to achieve full traceability of charging pile system operation behavior, real-time effectiveness of permission changes, and linkage management and control of device status and user permissions, effectively solving the security risks caused by the extensive permission control, difficult operation tracing, and lagging permission strategy of traditional charging pile management systems.

[0045] refer to Figure 2 In an optional embodiment, S1 includes the following steps:

[0046] S11. Create a top-level administrator account in the database transaction, perform SHA-256 hash encryption on the username and password of the top-level administrator account, and generate an initial user table containing fields such as user ID, username hash value, password hash value, permission level, and global permission range.

[0047] Specifically, create a top-level administrator account in a database transaction. This step involves the atomicity, consistency, isolation, and persistence (ACID characteristics) of database operations to ensure the reliability of the account creation process. The username and password of the top-level administrator account are encrypted with SHA-256 hash. This algorithm is an irreversible encryption algorithm that can effectively protect the security of user identity information. Hash encryption is used to generate an initial user table containing fields such as user ID (used to uniquely identify the administrator account), username hash value (encrypted username), password hash value (encrypted password), permission level (usually the highest level, such as level 1), and global permission scope (covering all functional modules and operation objects of the entire charging pile management system). The initial user table is stored in the database with a specific data table structure.

[0048] S12. Receive an account creation instruction submitted by the highest-authority administrator through a web interface, parse the secondary user permission parameters in the account creation instruction, and generate a permission association table including the secondary user ID, the administrator ID to which it belongs, and the inherited permission range.

[0049] Specifically, receive the account creation instruction submitted by the highest-authority administrator through the Web interface. The Web interface serves as an interactive bridge between the front-end and the back-end, and can use HTTP / HTTPS protocol for data transmission. Parse the received account creation instruction and extract the secondary user permission parameters therein. These parameters specify the scope of the secondary user's authority, such as the charging pile area allowed to be accessed, the type of operable parameters, etc. Based on these parameters, generate a permission association table containing the secondary user ID (used to uniquely identify the secondary user), the administrator ID (associated with the administrator account that created the secondary user), and the inherited permission scope. The permission association table is associated with the user table in the database. By establishing appropriate data table relationships (such as a one-to-many relationship, one administrator can create multiple secondary users), standardized data storage is achieved to facilitate subsequent permission management and query operations.

[0050] S13. Based on the inherited permission range in the permission association table, a database trigger is used to automatically verify that the permission level of the secondary user does not exceed the permission level corresponding to the administrator ID to which the secondary user belongs, and a permission level verification result is generated.

[0051] Specifically, a database trigger is a special stored procedure that is automatically executed when a specific data operation (such as insert, update, delete) is performed on a table in the database. In this step, when a new record is inserted into the permission association table, the trigger is activated and the permission level verification logic is executed. The core of the verification is to compare whether the permission level corresponding to the inherited permission range of the secondary user exceeds the permission level corresponding to the administrator ID to which it belongs. For example, if the administrator's permission level is level 2, then the secondary user's permission level cannot be lower than level 2 (that is, it cannot be higher than or equal to the administrator's permission). Through this automatic verification mechanism, the rationality and security of the permission system are ensured, and the occurrence of permission overstepping is avoided. Generate a permission level verification result, which can be expressed in the form of a Boolean value (valid or invalid), a status code, etc., to guide subsequent business process operations.

[0052] S14. When the permission level check result is valid, the secondary user ID, permission level and inherited permission range are written into the initial user table, and a foreign key constraint relationship between the user table and the permission association table is established to obtain the user table.

[0053] Specifically, when the permission level verification result is valid, it means that the permission setting of the secondary user complies with the permission hierarchy relationship specified by the system. At this time, the secondary user ID, permission level and inherited permission range are written into the user table, and the secondary user's information is formally incorporated into the entire user permission management system. At the same time, a foreign key constraint relationship is established between the user table and the permission association table. The foreign key constraint is a database integrity constraint mechanism used to ensure the referential integrity between data. For example, in the user table, the administrator ID field is set as a foreign key, referencing the primary key (user ID) of the user table where the administrator account is located. In this way, at the database level, it can be ensured that each secondary user corresponds to a valid administrator account, preventing data inconsistency and the generation of isolated data, and enhancing the integrity and reliability of database data.

[0054] S15. Generate data access control rules that restrict low-authority users from accessing high-authority configuration items based on the permission level field in the user table, and write the data access control rules into a database access policy file.

[0055] Specifically, the data access control rules define specific restrictions on users with different permission levels when accessing data in the database, such as prohibiting low-privilege users from querying or modifying database records corresponding to high-privilege configuration items. The data access control rules are written into the database access policy file, which is a configuration file used by the database management system (DBMS) to control user data access rights and can be defined in a specific format (such as XML, JSON, etc.). In this way, refined permission control is achieved at the database level, and combined with permission control at the application layer, the security of the entire system and the effectiveness of permission management are further improved, ensuring that only users with sufficient permissions can access and operate the corresponding data resources, effectively preventing the risk of data leakage and illegal operations.

[0056] In an optional embodiment, S2 includes the following steps:

[0057] S21. Receive the login credentials input by the user and generate a verification result through an encryption algorithm.

[0058] Specifically, the login credentials entered by the user through the login interface are first received. These credentials may include a username and password. To ensure the security of the login process, these login credentials are encrypted. The password can be irreversibly encrypted using the SHA-256 hash algorithm to generate a hash value. This encryption method effectively prevents the theft and cracking of user passwords during transmission and storage. Simultaneously, the username is also hashed to enhance the security of the user's identity information. The encrypted username and password hash value are then compared and verified against the user table information stored in the database to generate a verification result.

[0059] S22. Query the user table based on the verification result and generate a JSON Web token that carries the user ID and the corresponding permission level.

[0060] Specifically, based on the verification results, if the username and password hash values ​​match the records in the user table successfully, the legitimacy of the user's identity will be confirmed. At this time, a JSON Web Token (JWT) is generated based on the user ID and the corresponding permission level in the user table. JWT is a compact and self-contained way to transmit information as a JSON object between parties. JWT can be composed of three parts: Header, Payload, and Signature. The Header part specifies the type of token and the hash algorithm used; the Payload part contains declaration information such as user ID and permission level; the Signature part signs the Header and Payload to ensure the integrity and tamper-proofing of the token. The generated JWT will serve as the user's identity credential.

[0061] S23. Parse the permission level in the JSON Web token, load the corresponding functional module, and generate a Web configuration interface with restricted permissions.

[0062] Specifically, after receiving the JWT, the permission level information therein will be parsed, and the corresponding Web configuration interface function module will be loaded according to the parsed permission level. This process involves dynamic rendering and permission control of the front-end interface. According to the permission level, it is decided which function modules and operation options should be displayed to the user and which should be hidden or disabled. For example, a user with low permissions may only be able to see the basic status information and simple operation buttons of the charging pile, while an administrator with high permissions can see advanced function modules including user management and system configuration. In this way, a personalized display of the Web configuration interface based on user permissions is achieved, ensuring that users can only operate within their authorized scope, effectively preventing the risk of unauthorized access and operation, and maintaining the security and stability of the system.

[0063] refer to Figure 3 In an optional embodiment, S22 includes the following steps:

[0064] S221. Query the user table based on the user ID, obtain the corresponding permission level and permission scope, and generate a JWT claim set including the user ID, permission level and permission scope.

[0065] Specifically, this step mainly relies on the query operation of the database. By using the user ID as the query condition, key information such as the user's permission level and permission scope is retrieved from the user table. A JWT claim set containing the user ID, permission level and permission scope is generated. The JWT claim set is an object in JSON format, which contains relevant statements for identifying the user's identity and permissions, such as the user's unique identifier (user ID), permission level (such as level 1, level 2, etc. to represent different permission levels), permission scope (a list of specific accessible resources and executable operations), and other information. This information will serve as the Payload part of the JWT to provide the necessary user permission data for subsequent token generation.

[0066] S222. Generate a JWT header containing a signature algorithm identifier, perform Base64 encoding on the JWT header and the JWT claim set, and generate a data block to be signed.

[0067] Specifically, the JWT header can be a JSON object that specifies the type of token (such as JWT) and the signature algorithm used (such as RS256 represents the RSA algorithm combined with SHA-256). Then, the generated JWT header and the previously generated JWT declaration set are Base64 encoded respectively to generate a data block to be signed. Base64 encoding is a binary data encoding method that can convert binary data into printable ASCII characters for easy transmission and storage on the network. The encoded strings of the header and the declaration set are concatenated to form a string to be signed, which serves as the input data for the next step of digital signature.

[0068] S223. Digitally sign the data block to be signed using the RSA algorithm to generate a JWT signature segment.

[0069] Specifically, the RSA algorithm is an asymmetric encryption algorithm based on the problem of large prime number factorization and is widely used in the field of digital signatures. During the digital signature process, a private key is used to encrypt data to generate a signature segment. Here, the private key is used to encrypt the previously signed data block. The resulting ciphertext is the JWT signature segment, which is used to ensure the integrity and non-repudiation of the JWT. Only the corresponding public key can be used to decrypt and verify the validity of the signature, thus confirming that the JWT has not been tampered with since its generation and was indeed issued by a trusted party with the private key.

[0070] S224. Concatenate the JWT header, JWT claim set, and JWT signature segment in order to generate a complete JWT string as a JSON Web Token.

[0071] Specifically, the concatenation method involves concatenating the Base64-encoded string of the header, the Base64-encoded string of the claim set, and the Base64-encoded string of the signature segment with a period (.) to form a complete, understandable, and verifiable JWT string. This string, known as the JSON Web Token, contains user identity and permission information and is digitally signed to ensure its authenticity and integrity. This token is sent to users and serves as a credential for identity authentication and permission verification during system interactions, ensuring that users can only perform operations within their authorized scope, thereby enhancing system security and reliability.

[0072] In an optional embodiment, S3 includes the following steps:

[0073] S31. Intercept the configuration operation request triggered by the user through the Web interface, and parse the HTTP header of the configuration operation request to obtain the operation user ID.

[0074] Specifically, intercepting requests can be achieved by setting up request interceptors or filters at the web server or application server level. These components can pre-process the request before it reaches the business logic processing layer. Then parse the HTTP header of the configuration operation request to obtain the operation user ID. The HTTP header contains various meta-information of the request, such as user agent, authentication information, etc. In this step, the focus is on extracting the operation user ID, which may be the user ID information in the previously generated JWT token, or attached to the request header through other authentication mechanisms to identify the identity of the user who currently initiates the operation request.

[0075] S32: Extract the parameter key-value pairs contained in the configuration operation request, and parse the parameter names and the new values ​​requested for modification based on the parameter key-value pairs.

[0076] Specifically, the parameter key-value pair is the specific content that the user wants to modify the charging pile configuration, such as a key-value pair like "charging power = 50kW". Based on these key-value pairs, the parameter name (such as "charging power") and the new value requested to be modified (such as "50kW") are parsed. The parsing process may involve parsing the request body (such as URL-encoded query strings, JSON formatted data, etc.), and using corresponding parsing methods according to different Web request formats to extract specific parameter information, in preparation for subsequent permission verification and operation execution.

[0077] S33. Query the database to obtain the current stored value corresponding to the parameter name as the original value, and generate a change record including the operating user ID, parameter name, original value, and new value.

[0078] Specifically, the database is queried to obtain the current stored value corresponding to the parameter name, which is the original value. For example, if the parameter name is "charging power", the current value of the parameter in the configuration database may be "30kW". A change record is then generated containing the operating user ID (identifying who initiated the modification), the parameter name (which parameter was modified), the original value (the value before the modification), and the new value (the expected value after the modification). A change record is a data structure that can be in the form of a JSON object, a database record, etc. It is used to record the key information of the configuration modification operation in detail to facilitate subsequent operation log generation and audit tracking.

[0079] S34. Call the preset permission verification interface to verify whether the parameter name belongs to the set of configuration items that are allowed to be modified based on the permission range corresponding to the operating user ID in the user table.

[0080] Specifically, the permission verification interface is an encapsulated functional module that implements logic to verify the legitimacy of operations based on the user's permission scope. Based on the permission scope corresponding to the operating user ID in the user table, it verifies whether the parameter name belongs to the set of configuration items that are allowed to be modified. For example, if the set of modifiable configuration items in the user's permission scope does not include "charging power", it means that the user does not have permission to modify this parameter. The permission verification interface will compare the parameter name of the current operation request with the permission definition in the user table to determine whether the operation is allowed, thereby ensuring that only users with corresponding permissions can modify specific configuration items, maintaining the security of the system and the standardization of operations.

[0081] S35. When the parameter name belongs to the set of configuration items that are allowed to be modified, the change record is marked as a legal operation log; when it does not belong, a rejection log containing an error code is generated.

[0082] Specifically, if the parameter name belongs to the set of configuration items that are allowed to be modified, the change record is marked as a valid operation log, indicating that the operation is authorized and subsequent modification operations can be performed and recorded. Conversely, if the parameter name does not belong to the set of configuration items that are allowed to be modified, a rejection log is generated containing an error code that identifies the specific reason for the rejection, such as "insufficient permissions." This log processing mechanism clearly distinguishes between valid and invalid operations, providing detailed data for subsequent operation audits, troubleshooting, and security analysis.

[0083] S36. Write the legal operation log into the local ring buffer in chronological order, and generate a log block with a sequence number based on the log entry timestamp.

[0084] Specifically, a ring buffer is a fixed-size memory buffer. When data fills the buffer, new data overwrites the oldest data. This structure is suitable for scenarios with continuous writes and limited storage space, such as local log caches. Writing in chronological order ensures the time sequence of logs, facilitating subsequent queries and analysis. At the same time, log blocks with sequence numbers are generated based on the log entry timestamps. The timestamp is used to identify the time when the log was generated, and the sequence number can be used to ensure the integrity and order of the log during log synchronization or backup. Even if the log is lost or out of order during transmission, it can be restored and sorted based on the sequence number.

[0085] S37. Perform binary serialization processing on the log block to generate a data packet to be synchronized that meets the cloud storage format requirements.

[0086] Specifically, serialization is the process of converting data structures or object states into a form that can be stored or transmitted. Binary serialization converts log blocks into an efficient binary format. Compared to text formats, binary formats are generally more compact, occupy less storage space, and have high transmission efficiency. This generates a data packet to be synchronized that meets the cloud storage format requirements. Cloud storage may require specific data formats, such as compression methods and data encapsulation structures. The serialized log blocks are encapsulated according to the cloud's requirements to form the final data packet to be synchronized, ensuring that the data can be correctly received and stored by the cloud.

[0087] S38. Synchronize the data package to be synchronized to the cloud.

[0088] Specifically, the data packets to be synchronized are synchronized to the cloud via network communication. This may involve using IoT communication protocols such as HTTP / HTTPS and MQTT for data transmission, ensuring the security and integrity of the data during transmission. Synchronization can be performed in real time or in scheduled batches, depending on system performance requirements and network conditions. After receiving the data, the cloud stores the operation log data for subsequent important purposes such as big data analysis, operation auditing, and fault tracing. This enables centralized management and long-term preservation of operation logs, further improving system manageability and security.

[0089] In an optional embodiment, S5 includes the following steps:

[0090] S51: Receive the control instruction sent from the cloud, and parse the initiating user ID, target charging pile identifier, and instruction parameter set in the control instruction.

[0091] Specifically, the control instructions can be transmitted through IoT communication protocols, such as MQTT, CoAP or HTTP / HTTPS, to ensure the security and reliability of instruction transmission. Parse the initiating user ID, target charging pile identifier and instruction parameter set in the control instruction. The initiating user ID is used to identify the identity of the user who initiated the control instruction, the target charging pile identifier is used to determine the specific charging pile to be operated, and the instruction parameter set contains specific parameters and operation requirements for operating the charging pile, such as charging power adjustment value, charging start / stop instructions, etc. The parsing process involves decoding the instruction format and extracting data. According to the encapsulation format of the instruction (such as JSON, XML, etc.), the corresponding parsing method is adopted to obtain key operation information.

[0092] S52: Query the user table to obtain the authority level corresponding to the initiating user ID, and verify whether the authority level includes the operation authority for the target charging pile identifier.

[0093] Specifically, this step complements the previous permission verification step to ensure operational continuity and consistency. Verify whether the permission level includes permission to operate the target charging station identifier, that is, check whether the user has permission to operate the specified charging station. This may involve parsing the permission range in the user table, which can be stored in the form of a list of charging station identifiers, region codes, etc. Determine whether the target charging station identifier is within the initiating user's operational range, ensuring that only users with the corresponding permission can issue control commands to a specific charging station, maintaining the system's permission management and security.

[0094] S53: When the verification passes, generate the legal control instruction carrying the operation timestamp and digital signature based on the instruction parameter set.

[0095] Specifically, the operation timestamp is used to record the time when the control instruction was generated, ensuring the timeliness and sequence of the instruction, and facilitating subsequent operation audits and troubleshooting. Digital signatures are used to ensure the integrity and non-repudiation of control instructions. An asymmetric encryption algorithm (such as RSA) can be used to sign the instruction, and the private key is used to encrypt the instruction content to generate a signature. Only the corresponding public key can decrypt and verify the validity of the signature, thereby ensuring that the instruction has not been tampered with during transmission and is indeed initiated by a legitimate user. The generation process of a legitimate control instruction includes combining the instruction parameter set, operation timestamp, and digital signature into a complete instruction data structure to form the control instruction that will eventually be sent to the charging pile.

[0096] S54: Send the legal control instruction to the target charging pile corresponding to the target charging pile identifier through the Internet of Things communication protocol.

[0097] Specifically, IoT communication protocols may include MQTT (suitable for device communication due to its lightweight, efficient and reliable message transmission mechanism), CoAP (a web transmission protocol suitable for resource-constrained devices), or HTTP / HTTPS (a universal web communication protocol with good security and a broad application base). During the transmission process, the appropriate communication protocol and transmission parameters are selected based on the network connection status and configuration of the charging pile, and the control instructions are encapsulated into data frames or messages that comply with the protocol specifications and sent through the network. After receiving the control instructions, the target charging pile performs corresponding operations based on the content of the instructions, such as adjusting charging parameters, starting or stopping charging, etc., thereby realizing remote control and management of the charging pile, improving operation and maintenance efficiency and system flexibility.

[0098] The above-mentioned multi-account security management method based on mobile energy storage charging piles establishes a multi-level user account system and a dynamic permission management mechanism, uses encryption verification to generate dynamic tokens with permission attributes to achieve access control, captures user operations in real time to generate log data with identity identification and synchronizes it with the cloud, combines IoT data collection and permission verification to generate device control instructions, and dynamically updates permission rules to achieve full traceability of charging pile system operation behavior, real-time effectiveness of permission changes, and linkage management and control of device status and user permissions, effectively solving the security risks caused by the extensive permission control, difficult operation tracing, and lagging permission strategy of traditional charging pile management systems.

[0099] It should be understood that, although the various steps in the flowcharts involved in the various embodiments described above are displayed in sequence according to the instructions of the arrows, these steps are not necessarily executed in sequence in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order restriction on the execution of these steps, and these steps can be executed in other orders. Moreover, at least a portion of the steps in the flowcharts involved in the various embodiments described above can include multiple steps or multiple stages, and these steps or stages are not necessarily executed and completed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a portion of steps or stages in other steps.

[0100] Based on the same inventive concept, the embodiments of the present application also provide a system for implementing the aforementioned multi-account security management method based on a mobile energy storage charging pile. The implementation solution provided by this system is similar to the implementation solution described in the aforementioned method. Therefore, the specific limitations of one or more embodiments of the multi-account security management system based on a mobile energy storage charging pile provided below can be found in the above-mentioned limitations of the multi-account security management method based on a mobile energy storage charging pile, and will not be repeated here.

[0101] In an exemplary embodiment, as shown in FIG. 4 , a multi-account security management system 40 based on a mobile energy storage charging station is provided, including:

[0102] The account management module 41 is used to create and configure multi-level user accounts through the database based on the permission level mapping rules to obtain a user table; wherein the user table includes user ID, permission level and permission range.

[0103] The authentication and token generation module 42 is used to encrypt and verify the login credentials entered by the user. After the verification is passed, a dynamic token with permission attributes is generated based on the user ID in the user table, and the Web configuration interface is rendered according to the permission attributes in the dynamic token.

[0104] The operation request processing module 43 is used to capture user operation requests through the Web configuration interface, verify the legitimacy of the user operation request based on the permission range in the user table, generate an operation log after the verification is passed, and synchronize the operation log to the cloud for storage; wherein, the operation log includes the operation user ID, parameter name and change value.

[0105] The data collection and processing module 44 is used to collect sensor data from the charging pile through the Internet of Things communication protocol, filter the sensor data for abnormalities to generate standardized status data packets, associate the standardized status data packets with the permission attributes in the user table, and upload them to the cloud.

[0106] The control instruction verification module 45 is used to verify the permission level in the user table based on the control instruction issued by the cloud. After the verification is passed, a legal control instruction is generated and sent to the target charging pile; wherein, the control instruction is generated based on the operation log and the standardized status data packet.

[0107] The permission update and interface refresh module 46 is used to update the permission level mapping rules based on the permission update request of the user table and trigger the refresh of the Web configuration interface.

[0108] Optionally, the account management module includes:

[0109] The administrator account initialization unit is used to create a top-level administrator account in a database transaction, perform SHA-256 hash encryption on the username and password of the top-level administrator account, and generate an initial user table containing user ID, username hash value, password hash value, permission level, and global permission range fields.

[0110] The account association unit is used to receive the account creation instruction submitted by the highest-authority administrator through the web interface, parse the secondary user permission parameters in the account creation instruction, and generate a permission association table including the secondary user ID, the administrator ID to which it belongs, and the inherited permission range.

[0111] The first permission verification unit is used to automatically verify that the permission level of the secondary user does not exceed the permission level corresponding to the administrator ID of the secondary user based on the inherited permission range in the permission association table through a database trigger, and generate a permission level verification result.

[0112] The user table maintenance unit is used to write the secondary user ID, permission level and inherited permission range into the initial user table when the permission level verification result is valid, and establish a foreign key constraint relationship between the user table and the permission association table to obtain the user table.

[0113] The data access control rule generation unit is used to generate data access control rules that restrict low-authority users from accessing high-authority configuration items based on the authority level field in the user table, and write the data access control rules into the database access policy file.

[0114] Optional authentication and token generation modules include:

[0115] The login credential verification unit is used to receive the login credential input by the user and generate a verification result through an encryption algorithm.

[0116] The token generation unit is used to query the user table based on the verification result and generate a JSON Web token carrying the user ID and the corresponding permission level.

[0117] The interface rendering unit is used to parse the permission level in the JSON Web token, load the corresponding functional module, and generate a Web configuration interface with restricted permissions.

[0118] Optionally, the token generation unit includes:

[0119] The claim set generation subunit is used to query the user table based on the user ID, obtain the corresponding permission level and permission scope, and generate a JWT claim set containing the user ID, permission level and permission scope.

[0120] The data encoding subunit to be signed is used to generate a JWT header containing a signature algorithm identifier, Base64 encode the JWT header and the JWT claim set, and generate a data block to be signed.

[0121] The token signature subunit is used to digitally sign the signature data block using the RSA algorithm to generate a JWT signature segment.

[0122] The token concatenation subunit is used to concatenate the JWT header, JWT claim set, and JWT signature segment in sequence to generate a complete JWT string as a JSON Web token.

[0123] Optionally, the operation request processing module includes:

[0124] The operation request interception unit is used to intercept the configuration operation request triggered by the user through the Web interface, and parse the HTTP header of the configuration operation request to obtain the operation user ID.

[0125] The parameter parsing unit is used to extract the parameter key-value pairs contained in the configuration operation request, and parse the parameter name and the new value requested to be modified based on the parameter key-value pairs.

[0126] The change record generating unit is used to query the database to obtain the current stored value corresponding to the parameter name as the original value, and generate a change record including the operation user ID, parameter name, original value and new value.

[0127] The second permission verification unit is used to call a preset permission verification interface and verify whether the parameter name belongs to the set of configuration items allowed to be modified according to the permission range corresponding to the operation user ID in the user table.

[0128] The log marking unit is used to mark the change record as a legal operation log when the parameter name belongs to the set of configuration items that are allowed to be modified; when it does not belong, a rejection log containing an error code is generated.

[0129] The log buffering and sorting unit is used to write legal operation logs into the local ring buffer in chronological order and generate log blocks with sequence numbers based on the log entry timestamps.

[0130] The log serialization unit is used to perform binary serialization processing on log blocks and generate data packets to be synchronized that meet the cloud storage format requirements.

[0131] The log synchronization unit is used to synchronize the data packets to be synchronized to the cloud.

[0132] Optionally, the control instruction verification module includes:

[0133] The instruction receiving and parsing unit is used to receive the control instructions sent from the cloud and parse the initiating user ID, target charging pile identifier and instruction parameter set in the control instructions.

[0134] The authority verification unit is used to query the user table to obtain the authority level corresponding to the initiating user ID and verify whether the authority level includes the operation authority for the target charging pile identifier.

[0135] The legal instruction generation unit is used to generate a legal control instruction carrying an operation timestamp and a digital signature based on the instruction parameter set when the verification is passed.

[0136] The instruction sending unit is used to send the legal control instruction to the target charging pile corresponding to the target charging pile identifier through the Internet of Things communication protocol.

[0137] An embodiment of the present application further provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor implements the steps in the above-mentioned method embodiments when executing the computer program.

[0138] An embodiment of the present application further provides a computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments are implemented.

[0139] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to the partial description of the method embodiments. The device embodiments described above are merely illustrative, wherein the components described as separate parts may or may not be physically separated, and the parts displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the disclosed solution. A person of ordinary skill in the art can understand and implement it without expending creative work.

[0140] The above-described embodiments merely represent several implementation methods of the embodiments of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the patent application. It should be noted that a person skilled in the art may make various modifications and improvements without departing from the concept of the embodiments of the present application, and these modifications and improvements fall within the scope of protection of the embodiments of the present application.

Claims

1. A multi-account security management method based on a mobile energy storage charging pile, characterized in that: The method comprises: S1. Based on the permission level mapping rules, create and configure multi-level user accounts through the database to obtain a user table; wherein the user table includes user ID, permission level and permission range; S2. Perform encryption verification on the login credentials input by the user. If the verification is successful, generate a dynamic token with permission attributes based on the user ID in the user table, and render the web configuration interface according to the permission attributes in the dynamic token; S3. Capturing user operation requests through the web configuration interface, verifying the legitimacy of the user operation requests based on the authority range in the user table, generating an operation log after verification, and synchronizing the operation log to the cloud for storage; wherein the operation log includes the operation user ID, parameter name, and changed value; S4. Collect sensor data from the charging pile through the Internet of Things communication protocol, perform anomaly filtering on the sensor data to generate a standardized status data packet, associate the standardized status data packet with the permission attributes in the user table, and upload the data packet to the cloud; S5. Verify the permission level in the user table based on the control instruction issued by the cloud, generate a legal control instruction after the verification is passed, and issue the legal control instruction to the target charging pile; wherein the control instruction is generated based on the operation log and the standardized status data packet; S6. Update the permission level mapping rule based on the permission update request of the user table, and trigger the refresh of the Web configuration interface.

2. The method according to claim 1, characterized in that Said S1 comprises: S11. Create a top-level administrator account in a database transaction, perform SHA-256 hash encryption on the username and password of the top-level administrator account, and generate an initial user table containing fields such as user ID, username hash value, password hash value, permission level, and global permission range; S12: Receive an account creation instruction submitted by the highest-authority administrator through a web interface, parse the secondary user permission parameters in the account creation instruction, and generate a permission association table including the secondary user ID, the administrator ID to which the secondary user belongs, and the inherited permission range; S13. Based on the inherited permission range in the permission association table, automatically verify through a database trigger that the permission level of the secondary user does not exceed the permission level corresponding to the administrator ID to which the secondary user belongs, and generate a permission level verification result; S14. When the permission level verification result is valid, the secondary user ID, permission level, and inherited permission range are written into the initial user table, and a foreign key constraint relationship is established between the user table and the permission association table to obtain the user table; S15. Generate data access control rules that restrict low-authority users from accessing high-authority configuration items based on the authority level field in the user table, and write the data access control rules into a database access policy file.

3. The method according to claim 1, characterized in that The S2 includes: S21, receiving the login credentials input by the user, and generating a verification result through an encryption algorithm; S22. Query the user table based on the verification result and generate a JSON Web token carrying the user ID and the corresponding permission level; S23: Parse the permission level in the JSON Web token, load the corresponding functional module, and generate the Web configuration interface with limited permissions.

4. The method according to claim 3, characterized in that The S22 includes: S221. Query the user table based on the user ID, obtain the corresponding permission level and permission range, and generate a JWT claim set including the user ID, permission level, and permission range; S222. Generate a JWT header containing a signature algorithm identifier, perform Base64 encoding on the JWT header and the JWT claim set, and generate a data block to be signed; S223. Digitally sign the data block to be signed using the RSA algorithm to generate a JWT signature segment; S224. Concatenate the JWT header, the JWT claim set, and the JWT signature segment in order to generate a complete JWT string as the JSON Web token.

5. The method according to claim 1, wherein The S3 includes: S31. Intercept a configuration operation request triggered by a user through a web interface, and parse the HTTP header of the configuration operation request to obtain an operation user ID; S32. Extract the parameter key-value pairs contained in the configuration operation request, and parse the parameter names and the new values ​​requested for modification based on the parameter key-value pairs; S33, querying the database to obtain the current stored value corresponding to the parameter name as the original value, and generating a change record including the operating user ID, parameter name, the original value, and the new value; S34. Call a preset permission verification interface to verify whether the parameter name belongs to a set of configuration items that are allowed to be modified according to the permission range corresponding to the operation user ID in the user table; S35. When the parameter name belongs to the set of configuration items that are allowed to be modified, mark the change record as a legal operation log; when it does not belong to the set, generate a rejection log containing an error code; S36. Write the legal operation log into the local ring buffer in chronological order, and generate a log block with a sequence number based on the log entry timestamp; S37: Perform binary serialization processing on the log block to generate a data packet to be synchronized that meets the cloud storage format requirements; S38: Synchronize the data packet to be synchronized to the cloud.

6. The method according to any one of claims 1 to 5, characterized in that The S5 includes: S51, receiving the control instruction issued by the cloud, parsing the initiating user ID, target charging pile identifier and instruction parameter set in the control instruction; S52: Query the user table to obtain the permission level corresponding to the initiating user ID, and verify whether the permission level includes the operation permission for the target charging pile identifier; S53. When the verification passes, generating the legal control instruction carrying the operation timestamp and the digital signature based on the instruction parameter set; S54: Send the legal control instruction to the target charging pile corresponding to the target charging pile identifier through the Internet of Things communication protocol.

7. A multi-account security management system based on a mobile energy storage charging pile, characterized in that: The system comprises: An account management module is used to create and configure multi-level user accounts through a database based on permission level mapping rules to obtain a user table; wherein the user table includes user ID, permission level, and permission range; The authentication and token generation module is used to encrypt and verify the login credentials entered by the user. If the verification is successful, a dynamic token with permission attributes is generated based on the user ID in the user table, and the web configuration interface is rendered according to the permission attributes in the dynamic token; An operation request processing module, configured to capture user operation requests through the web configuration interface, verify the legitimacy of the user operation request based on the permission range in the user table, generate an operation log upon successful verification, and synchronize the operation log to the cloud for storage; wherein the operation log includes the operation user ID, parameter name, and changed value; A data acquisition and processing module, configured to collect sensor data from charging piles through an Internet of Things communication protocol, perform anomaly filtering on the sensor data to generate a standardized status data packet, associate the standardized status data packet with the permission attributes in the user table, and upload the data packet to the cloud; a control instruction verification module, configured to verify the permission level in the user table based on the control instruction issued by the cloud, generate a legal control instruction upon successful verification, and issue the legal control instruction to the target charging pile; wherein the control instruction is generated based on the operation log and the standardized status data packet; The permission update and interface refresh module is used to update the permission level mapping rules based on the permission update request of the user table and trigger the refresh of the Web configuration interface.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the method according to any one of claims 1 to 6 is implemented.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method according to any one of claims 1 to 6 is implemented.

Images