Software modular management method, system, device, equipment and medium

Abstract

The invention discloses a software modular management method, system, device and equipment and a medium, and the method comprises the following steps: an authorization stage: obtaining user activation information which is used for indicating function modules allowed to be activated; independently encrypting each function module allowed to be activated according to the user activation information and a random algorithm library, and generating a corresponding authorization file; an authentication stage: obtaining an authority verification request of the function module; authenticating an authorization file of the function module according to the authority verification request to generate authentication information; and under the condition that the authentication information indicates that the verification is passed, allowing the corresponding function module to be started. According to the method, the flexibility, the expandability and the security of software can be improved.

Description

Technical Field

[0001] This application relates to the field of software management, and in particular to a software modular management method, system, device, equipment, and medium. Background Technology

[0002] With the widespread use and increasing complexity of software applications, ensuring software security and authorization management has become crucial. Traditional software authorization methods typically involve unified authentication and authorization across the entire system, but this approach often lacks flexibility and scalability. As software continues to expand and functional modules increase, this unified authorization method becomes increasingly unable to meet the diverse authorization requirements of each module. Furthermore, reconfiguring the entire system for authorization during software updates and maintenance is not only costly but may also introduce new security risks.

[0003] In summary, the software in these related technologies suffers from poor flexibility, scalability, and security. Summary of the Invention

[0004] This application aims to provide a software modular management method, system, device, equipment, and medium that can improve the flexibility, scalability, and security of software.

[0005] In a first aspect, embodiments of this application provide a software modularization management method for a modular software system, the system comprising multiple functional modules, the method including an authorization and authentication phase, and comprising the following steps:

[0006] Authorization phase:

[0007] Obtain user activation information, which is used to indicate the functional modules that are allowed to be activated;

[0008] Based on the user activation information and a random algorithm library, each allowed-to-activate functional module is independently encrypted to generate a corresponding authorization file;

[0009] Authentication stage:

[0010] Obtain the permission verification request from the aforementioned functional module;

[0011] The authorization file of the functional module is authenticated according to the permission verification request, and authentication information is generated;

[0012] If the authentication information indicates that the verification is successful, the corresponding functional module is allowed to start.

[0013] According to some embodiments of this application, the step of independently encrypting each allowed-to-activate functional module based on the user activation information and a random algorithm library includes:

[0014] Based on the user activation information, select an enabled functional module as the module to be encrypted;

[0015] Using the authorization time as a random seed, an encryption algorithm from a random algorithm library is randomly selected to encrypt the module to be encrypted, generating an authorization file;

[0016] Repeat the above steps until license files for all enabled functional modules are generated.

[0017] According to some embodiments of this application, the user activation information further includes authorization time information, and after independently encrypting each allowed-to-activate functional module based on the user activation information and a random algorithm library, the method further includes:

[0018] Set the authorization period for the licensed file based on the authorization time information.

[0019] According to some embodiments of this application, after independently encrypting each allowed-to-activate functional module based on the user activation information and a random algorithm library to generate a corresponding authorization file, the method further includes:

[0020] Obtain module update information, which is used to indicate the addition or removal of functional modules;

[0021] Each newly added functional module is independently encrypted based on module update information and a random algorithm library, generating an authorization file for the newly added functional module. Additionally, authorization files for functional modules that have been removed or reduced are deleted based on the module update information.

[0022] According to some embodiments of this application, after authenticating the authorization file of the functional module based on the permission verification request and generating authentication information, the method further includes:

[0023] Log information is generated, which is used to record the user's authentication process.

[0024] Secondly, embodiments of this application provide a modular software system, including a basic platform and multiple functional modules, wherein the basic platform manages the functional modules through the aforementioned software modular management method.

[0025] According to some embodiments of this application, the plurality of functional modules include at least two of the following: a state machine module, a remote driving control module, an electronic fence module, an active safety module, a planning module, a perception module, and a positioning module.

[0026] Thirdly, embodiments of this application provide a software modular management device, including:

[0027] An activation module is used to obtain user activation information, which is used to indicate which functional modules are allowed to be activated.

[0028] The authorization module is used to independently encrypt each allowed-to-activate functional module based on the user activation information and a random algorithm library, and generate a corresponding authorization file.

[0029] The permission verification request module obtains the permission verification request from the functional module.

[0030] The authentication module authenticates the authorization file of the functional module according to the permission verification request and generates authentication information.

[0031] The function startup module allows the corresponding function module to start when the authentication information indicates that the verification has passed.

[0032] Fourthly, embodiments of this application provide an electronic device, the device comprising: a processor and a memory storing computer program instructions;

[0033] When the processor executes the computer program instructions, it implements the software modular management method as described in the first aspect.

[0034] Fifthly, embodiments of this application provide a computer-readable storage medium storing computer program instructions, which, when executed by a processor, implement the software modular management method as described in the first aspect.

[0035] The software modular management method, system, apparatus, device, and medium of the embodiments of this application have at least the following beneficial effects:

[0036] In this embodiment, during the authorization phase, user activation information is first obtained; then, based on the user activation information and a random algorithm library, each allowed-to-activate functional module is independently encrypted to generate a corresponding authorization file; during the authentication phase, the permission verification request of the functional module is first obtained; then, the authorization file of the functional module is authenticated based on the permission verification request to generate authentication information; finally, if the authentication information indicates that the verification is successful, the corresponding functional module is allowed to start. This application can realize modular software authorization management and authentication, improving the flexibility, scalability, and security of the software.

[0037] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0038] The present application will be further described below with reference to the accompanying drawings and embodiments, wherein:

[0039] Figure 1 A flowchart illustrating the authorization phase in an embodiment of the software modular management method provided in this application;

[0040] Figure 2 A flowchart illustrating the authentication phase in an embodiment of the software modular management method provided in this application;

[0041] Figure 3 A schematic diagram of the structure of the encryption key in an embodiment of the software modular management method provided in this application;

[0042] Figure 4 A schematic diagram of the software modular management device provided in this application;

[0043] Figure 5 A schematic diagram of the structure of the electronic device provided in this application. Detailed Implementation

[0044] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0045] In this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, without necessarily requiring or implying any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes said element.

[0046] To address the problems of the prior art, embodiments of this application provide a software modular management method, system, apparatus, device, and medium. The software modular management provided in the embodiments of this application will be described below.

[0047] Figure 1 and Figure 2A flowchart illustrating the software modular management method provided in this application embodiment is shown. This method is applied to electronic devices and is a software modular management method for modular software systems. The system includes multiple functional modules, and the method includes authorization and authentication phases, comprising the following steps:

[0048] Authorization phase:

[0049] S101. Obtain user activation information, which is used to indicate the functional modules that are allowed to be activated.

[0050] S102. Based on the user activation information and the random algorithm library, each allowed-to-activate functional module is independently encrypted to generate the corresponding authorization file;

[0051] Authentication stage:

[0052] S201, Obtain the permission verification request from the functional module;

[0053] S202. Authenticate the authorization files of the functional modules according to the permission verification request and generate authentication information;

[0054] S203. If the authentication information indicates that the verification is successful, the corresponding functional module is allowed to start.

[0055] In this embodiment, during the authorization phase, user activation information is first obtained; then, based on the user activation information and a random algorithm library, each allowed-to-activate functional module is independently encrypted to generate a corresponding authorization file; during the authentication phase, the permission verification request of the functional module is first obtained; then, the authorization file of the functional module is authenticated based on the permission verification request to generate authentication information; finally, if the authentication information indicates that the verification is successful, the corresponding functional module is allowed to start. This application can realize modular software authorization management and authentication, improving the flexibility, scalability, and security of the software.

[0056] It should be noted that the modular software system mentioned above refers to a software system that adopts a modular design and consists of multiple modules with different functions, such as a state machine module, a remote driving control module, an electronic fence module, an active safety module, a planning module, a perception module, and a positioning module. Through the combination of different functional modules, diverse software functions can be provided, such as mini versions, lightweight versions, standard versions, and professional versions.

[0057] In step S101 above, user activation information refers to the relevant information of the functional modules that are allowed to be activated, such as the unique code or number of each functional module. User activation information can be the activation code entered by the user, or it can be the activation command issued by the server according to the user's needs after the user purchases the corresponding software.

[0058] In step S102 above, independently encrypting each allowed functional module based on user activation information and a random algorithm library to generate a corresponding authorization file means selecting allowed functional modules based on user activation information, encrypting each allowed functional module using a randomly selected encryption algorithm from the random algorithm library, and then generating an authorization file for each functional module. It should be understood that this application uses a random algorithm library to improve encryption security. Using a random algorithm library can significantly reduce the risk of encryption algorithms being cracked. Even if the encryption algorithm used by a certain functional module is cracked, the encryption algorithms of other functional modules remain effective. Combined with the modular encryption mechanism, even if a single authorization is cracked, the entire system's functionality will not be completely exposed.

[0059] Specifically, the encryption process is as follows:

[0060] First, a public key is generated using the RSA private key, and then the public key data is base64 encoded and written to `pub_key`. The `data` field contains the actual encrypted content. Base64 is a method of representing binary data using 64 printable characters. For detailed structure of the `data` field, please refer to [link to documentation]. Figure 3 As shown, the Data field comprises three segments: a data header, an encryption key, and encrypted data. The data header is 32 bytes long; the first 16 bytes represent the length of the encryption key data, and the last 16 bytes represent the specific encryption algorithm used by the encryption key. The encryption key is one of the keys used to encrypt the data. The encryption key generation process involves selecting a pseudo-random parameter as a random seed, randomly selecting an encryption algorithm from the algorithm library, and recording the index name of the algorithm. For example, after base64 encoding, pkcs7padding is applied to pad the data to the latter half of the 16-byte data header. Next, the activation code is encrypted using a random algorithm and then base64 encoded. The base64 encoded RSA private key is used to encrypt the base64 encoded ciphertext again, the ciphertext length is recorded, and the length information is padded with 16 bytes before being base64 encoded as the first half of the data header. Finally, the RSA-encrypted data is base64 encoded to form the encryption key. The encrypted data generation process includes serializing the binding information into binary format using protobuf, then base64 encoding the binary data and encrypting it using AES. The AES encryption key uses the current device activation code, while the AES IV uses the device serial number, which is base64 encoded and pkcs7 padding. Finally, the AES encrypted content is base64 encoded and placed into the encrypted data segment, which constitutes the content of the entire data area.

[0061] It's important to note that Protocol Buffers provides a serialization format for typed, structured data packets, which can reach sizes of several megabytes. This format is suitable for both transient network traffic and long-term data storage. Protocol Buffers can be extended with new information without invalidating existing data or requiring code updates. Protocol Buffers is Google's most commonly used data format. They are widely used for inter-server communication and archiving data on disk. Protocol Buffer messages and services are described by .proto files written by engineers.

[0062] In step S201 above, obtaining the permission verification request for a functional module refers to the need to verify the user's permissions before enabling a certain functional module based on user operations or server instructions. This verification involves validating the authorization file of the functional module. For example, the permission verification request can be generated using various authentication methods and permission management strategies, such as biometric authentication, multi-factor authentication, and role-based access control.

[0063] In step S202 above, authenticating the authorization file of the functional module according to the permission verification request and generating authentication information refers to responding to the permission verification request and verifying the validity of the authorization file of the functional module that needs to be started / called.

[0064] Specifically, the authentication process in step S202 can be considered the reverse operation of the authorization process. The specific steps include extracting the first 32 bytes of the data segment, dividing it into an upper and lower half. These two parts are processed using pkcs7unpadding to obtain the original data content. The encryption key data is extracted from the upper half, and the name of the random algorithm is obtained from the lower half. First, it is decrypted using the RSA public key, and then decrypted again using the corresponding algorithm to obtain the AES key. The device serial number is used as the AES IV, and the binding information is further decrypted using the AES encryption key. After decryption, the binding information content is obtained using protobuf deserialization. Since authentication is performed before each module starts, each functional module passes its corresponding module loading name to the authentication component. By comparing this name with the active module name in the binding information, it can be determined whether the current module is valid and the corresponding authentication information is provided. The authentication information has two possible outcomes: verification passed or failed.

[0065] S203. If the authentication information indicates that the verification is successful, the corresponding functional module is allowed to start.

[0066] Specifically, a successful authentication message indicates that the license file for the current module is valid. For example, if the system determines the license file is valid, it uses Poco::ClassLoader to dynamically load the runtime library and ultimately execute the module's functionality; if the license file is invalid, the program exits. It's worth noting that Poco is a collection of open-source C++ class libraries for building network and internet applications. For the task of loading (and unloading) shared libraries at runtime, Poco provides a low-level Poco::SharedLibrary class. Above this is the Poco::ClassLoader class template and the corresponding support framework, allowing you to dynamically load and unload C++ classes at runtime, similar to functionality in Java and .NET. The class loader framework allows for the addition of plugin support to programs in a platform-independent manner.

[0067] In some implementations, each allowed-to-activate functional module is independently encrypted based on user activation information and a random algorithm library, which may include:

[0068] Select an enabled functional module as the module to be encrypted based on the user's activation information;

[0069] Using the authorization time as a random seed, an encryption algorithm from the random algorithm library is randomly selected to encrypt the module to be encrypted, and an authorization file is generated.

[0070] Repeat the above steps until license files for all enabled functional modules are generated.

[0071] In this implementation, firstly, a functional module that is allowed to be activated is selected as the module to be encrypted based on the user's activation information; then, the authorization time is used as a random seed to randomly select an encryption algorithm from a random algorithm library to encrypt the module to be encrypted, generating an authorization file; finally, the above steps are repeated until authorization files for all allowed functional modules are generated. This can further improve the security of encryption.

[0072] It should be noted that while a random algorithm from a random algorithm library can be selected using computer-generated random numbers, these numbers are pseudo-random and exhibit certain patterns, thus their security is generally limited. To improve security, truly random numbers are required. This embodiment uses time as the random seed because time is constantly changing. Using nanosecond-level precision ensures that the random seed is different each time, resulting in truly random numbers and further enhancing the security of the encryption process.

[0073] In some implementations, the user activation information also includes authorization time information. After independently encrypting each permitted functional module based on the user activation information and a random algorithm library, it may also include:

[0074] Set the authorization period for the licensed file based on the authorization time information.

[0075] In this implementation, the authorization period of the authorization file is set based on the authorization time information. This can further improve the flexibility of software licensing.

[0076] The aforementioned authorization time information refers to adding a feature code corresponding to the authorization time to the user activation information. For example, the binding information corresponding to the user activation information may include the authorization time (issued_time), the hardware serial number (serial), the activation status (activation), the authorized modules (authorize_modules), and when there is no time limit, not_before and not_after are both 0. It may also include the company information (app_id) of the authorization file, customer information (customer_info), etc.

[0077] In some implementations, after independently encrypting each permitted functional module based on user activation information and a random algorithm library to generate a corresponding authorization file, the following may also be included:

[0078] Obtain module update information, which is used to indicate the addition or removal of functional modules;

[0079] Each newly added functional module is independently encrypted based on module update information and a random algorithm library, generating an authorization file for the newly added functional module. Additionally, authorization files for functional modules that have been removed or reduced are deleted based on the module update information.

[0080] In this implementation, module update information is first obtained. Then, each newly added functional module is independently encrypted based on the module update information and a random algorithm library, generating an authorization file for the new functional module. Additionally, authorization files corresponding to functional modules that have been removed or reduced are deleted based on the module update information. This further improves the software's flexibility and scalability.

[0081] It should be noted that when the functionality of a software module changes or user needs are adjusted, such as when a user purchases a new software service or upgrades the software, the software system dynamically updates the licensing policy of the corresponding module, thereby issuing a corresponding module update message. The module update message records the functional modules that need to be added or removed. This implementation method allows the software to flexibly add or remove corresponding functional modules.

[0082] In some implementations, after authenticating the authorization file of the functional module based on the permission verification request and generating authentication information, the process may further include:

[0083] Generate log information, which is used to record the user authentication process.

[0084] In this implementation, relevant log information is recorded and generated during the authentication process for subsequent auditing and troubleshooting. Log information may include the user's login time, login location, accessed resources, and performed operations. By reviewing the log information, system administrators can promptly identify and address any abnormal or suspicious behavior, thereby further enhancing system security.

[0085] This application also relates to a modular software system, including a basic platform and multiple functional modules, wherein the basic platform manages the software modules using the software modular management method described in the above embodiments.

[0086] Specifically, the basic platform includes multiple public modules. These public modules are not encrypted, meaning that users directly authorize the public platform regardless of the features they purchase. Feature modules, on the other hand, are authorized separately as optional configuration items, depending on whether the user chooses to activate them.

[0087] In some implementations, the multiple functional modules include at least two of the following: a state machine module, a remote driving control module, an electronic fence module, an active safety module, a planning module, a sensing module, and a positioning module. Combining different functional modules to achieve different product functions can further improve software flexibility.

[0088] It should be noted that for different software products, different functional modules are authorized separately according to requirements, and the different combinations of functional modules determine the different capabilities of the software product.

[0089] For example, the active safety module is responsible for identifying surrounding environmental information in real time, predicting the vehicle's trajectory based on its current state, and limiting or braking the vehicle if there is a risk of collision on the trajectory, thus ensuring the safety of the vehicle and its occupants.

[0090] Based on the software modular management method provided in the above embodiments, this application also provides a specific implementation of the software modular management device.

[0091] like Figure 4 As shown, the software modular management device 300 provided in this application embodiment may include:

[0092] Activation module 301 is used to obtain user activation information, which is used to indicate the functional modules that are allowed to be activated.

[0093] Authorization module 302 is used to independently encrypt each allowed-to-activate functional module based on user activation information and a random algorithm library, and generate a corresponding authorization file;

[0094] The permission verification request module 303 retrieves the permission verification request from the functional module.

[0095] The authentication module 304 authenticates the authorization file of the functional module based on the permission verification request and generates authentication information.

[0096] The function startup module 305 allows the corresponding function module to start when the authentication information indicates that the verification has passed.

[0097] The software modular management device 300 of this application embodiment is used to execute the software modular management method in the above embodiment. Its specific processing procedure is the same as that of the software modular management method in the above embodiment, and will not be described in detail here.

[0098] Figure 5 A schematic diagram of the hardware structure of the electronic device provided in an embodiment of this application is shown.

[0099] An electronic device may include a processor 401 and a memory 402 storing computer program instructions.

[0100] Specifically, the processor 401 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0101] Memory 402 may include mass storage for data or instructions. For example, and not limitingly, memory 402 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 402 may include removable or non-removable (or fixed) media. Where appropriate, memory 402 may be internal or external to the integrated gateway disaster recovery device. In a particular embodiment, memory 402 is non-volatile solid-state memory.

[0102] In some embodiments, memory 402 may include read-only memory (ROM), random access memory (RAM), disk storage media device, optical storage media device, flash memory device, electrical, optical, or other physical / tangible memory storage device. Thus, generally, memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the method according to one aspect of this disclosure.

[0103] The processor 401 reads and executes computer program instructions stored in the memory 402 to implement any of the software modular management methods in the above embodiments.

[0104] In one example, the electronic device may also include a communication interface 404 and a bus 410. For example, Figure 5 As shown, the processor 401, memory 402, and communication interface 404 are connected through bus 410 and complete communication with each other.

[0105] Communication interface 404 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0106] Bus 410 includes hardware, software, or both, that couples components of an online data traffic metering device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 410 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, this application contemplates any suitable bus or interconnect.

[0107] Furthermore, in conjunction with the software modular management method in the above embodiments, this application embodiment can provide a computer storage medium for implementation. The computer storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the software modular management methods in the above embodiments.

[0108] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0109] The functional blocks shown in the above-described structural diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0110] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0111] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by special-purpose hardware performing the specified functions or actions, or can be implemented by a combination of special-purpose hardware and computer instructions.

[0112] The above description is merely a specific implementation of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A software modular management method, characterized in that, For a modular software system comprising multiple functional modules, the method includes authorization and authentication phases, comprising the following steps: Authorization phase: Obtain user activation information, which is used to indicate the functional modules that are allowed to be activated; Based on the user activation information and a random algorithm library, each allowed-to-activate functional module is independently encrypted to generate a corresponding authorization file; Authentication stage: Obtain the permission verification request from the aforementioned functional module; The authorization file of the functional module is authenticated according to the permission verification request, and authentication information is generated; If the authentication information indicates that the verification is successful, the corresponding functional module is allowed to start.

2. The software modular management method according to claim 1, characterized in that, The step of independently encrypting each allowed-to-activate functional module based on the user activation information and a random algorithm library includes: Based on the user activation information, select an enabled functional module as the module to be encrypted; Using the authorization time as a random seed, an encryption algorithm from a random algorithm library is randomly selected to encrypt the module to be encrypted, generating an authorization file; Repeat the above steps until license files for all enabled functional modules are generated.

3. The software modular management method according to claim 1, characterized in that, The user activation information also includes authorization time information. After independently encrypting each allowed-to-activate functional module based on the user activation information and a random algorithm library, the process further includes: Set the authorization period for the licensed file based on the authorization time information.

4. The software modular management method according to claim 1, characterized in that, After independently encrypting each allowed-to-activate functional module based on the user activation information and a random algorithm library to generate a corresponding authorization file, the process further includes: Obtain module update information, which is used to indicate the addition or removal of functional modules; Each newly added functional module is independently encrypted based on module update information and a random algorithm library, generating an authorization file for the newly added functional module. Additionally, authorization files for functional modules that have been removed or reduced are deleted based on the module update information.

5. The software modular management method according to claim 1, characterized in that, After authenticating the authorization file of the functional module according to the permission verification request and generating authentication information, the process further includes: Log information is generated, which is used to record the user's authentication process.

6. A modular software system, characterized in that, It includes a basic platform and multiple functional modules, wherein the basic platform manages the software modules using the software modular management method described in any one of claims 1 to 5.

7. The modular software system according to claim 6, characterized in that, The plurality of functional modules include at least two of the following: state machine module, remote driving control module, electronic fence module, active safety module, planning module, perception module, and positioning module.

8. A software modular management device, characterized in that, include: An activation module is used to obtain user activation information, which is used to indicate which functional modules are allowed to be activated. The authorization module is used to independently encrypt each allowed-to-activate functional module based on the user activation information and a random algorithm library, and generate a corresponding authorization file. The permission verification request module obtains the permission verification request from the functional module. The authentication module authenticates the authorization file of the functional module according to the permission verification request and generates authentication information. The function startup module allows the corresponding function module to start when the authentication information indicates that the verification has passed.

9. An electronic device, characterized in that, The device includes: a processor and a memory storing computer program instructions; When the processor executes the computer program instructions, it implements the software modular management method as described in any one of claims 1-5.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions, which, when executed by a processor, implement the software modular management method as described in any one of claims 1-5.

Images