User permission management method for vehicle, domain controller, vehicle and storage medium

Abstract

The application relates to a user authority management method, a domain controller, a vehicle and a storage medium. The vehicle is provided with a first domain controller and a second domain controller, the method is used for the first domain controller, and the method comprises the following steps: according to a preset user creation request, a first user identifier is allocated to a target user from a first identifier set; user creation is carried out according to the first user identifier locally in the first domain controller; and at least the second domain controller is informed to carry out user creation according to the first user identifier; wherein the user creation according to the first user identifier comprises the following step: an association between the first user identifier and SOA service authority data of the target user is established. The scheme provided in the embodiment of the application can control the ability of a user to control a vehicle, thereby improving the safety of the vehicle.

Description

Technical Field

[0001] This application relates to the field of vehicle technology, and in particular to a user rights management method for vehicles, a domain controller, a vehicle, and a storage medium. Background Technology

[0002] SOA is a component model that breaks down an application into different functional units (called services) and connects them through well-defined interfaces and protocols. This improves service reusability, makes business logic composable, and allows each service to be deployed in a distributed manner according to usage, resulting in standardized, high-performance, and highly available services.

[0003] With the development of automotive Ethernet technology, SOA (Service-oriented architecture) has gradually been introduced into vehicle software design. By adopting SOA architecture on top of Ethernet, vehicle functions, such as body function control, can be controlled. However, the SOA architecture provides users with unlimited control capabilities, allowing them to manipulate the vehicle at will. If this unlimited control is not managed properly, it can become a disaster, and in severe cases, may even lead to life-threatening situations. Summary of the Invention

[0004] This application provides a user rights management method for vehicles, a domain controller, a vehicle, and a storage medium, which can control the user's ability to control the vehicle, thereby improving the security of vehicle use.

[0005] A first aspect of this application provides a user access control method for a vehicle, wherein the vehicle has multiple domain controllers, the multiple domain controllers including at least a first domain controller and a second domain controller, and the method is used on the first domain controller, comprising:

[0006] Based on the preset user creation request, assign a first user identifier to the target user from the first identifier set;

[0007] The user is created locally on the first domain controller based on the first user identifier; and...

[0008] At least notify the second domain controller to create a user based on the first user identifier;

[0009] The step of creating a user based on the first user identifier includes: establishing an association between the first user identifier and the SOA service permission data of the target user.

[0010] In one embodiment, the method further includes:

[0011] If a user identifier conflict is determined to occur based on the user creation response message returned by the second domain controller, a second user identifier different from the first user identifier is assigned to the target user from the first identifier set. The user is then created locally on the first domain controller based on the second user identifier, and the second domain controller is notified to create the user based on the second user identifier.

[0012] In one embodiment, after determining that a user identifier conflict has occurred based on the user creation response message returned by the second domain controller, the method further includes:

[0013] Log out the first user ID locally on the first domain controller; and,

[0014] The SOA service interface is used to notify other domain controllers among the multiple domain controllers that have successfully created a user based on the first user identifier to deregister the first user identifier.

[0015] In one embodiment, the method further includes:

[0016] Based on a preset user logout request, the first user identifier is logged out locally on the first domain controller; and...

[0017] The second domain controller is notified to cancel the first user identifier via the SOA service interface;

[0018] The user logout request can be either a user logout request from the local application layer of the first domain controller or a user creation response message indicating a user identifier conflict, wherein the user creation response message comes from any other domain controller other than the first domain controller among the plurality of domain controllers.

[0019] In one embodiment, the method further includes:

[0020] When the preset user logout conditions are met, the first user identifier is logged out locally on the first domain controller, and when the SOA service of the second domain controller is invoked, the second domain controller is notified to log out the first user identifier through the SOA service interface.

[0021] In one embodiment, notifying the second domain controller to create a user based on the first user identifier includes:

[0022] When invoking the SOA service of the second domain controller, the first user identifier and the SOA service permission data are used as SOA service invocation parameters, and the second domain controller is notified through the SOA service interface to create a user based on the first user identifier.

[0023] In one embodiment, notifying the second domain controller to create a user based on the first user identifier includes:

[0024] Obtain a first user information list local to the first domain controller, wherein the first user information list includes the first user identifier;

[0025] The first user information list is sent to the second domain controller through the SOA service interface, so that the second domain controller updates the second user information list locally based on the first user information list.

[0026] After notifying the second domain controller to create a user based on the first user identifier, the method further includes:

[0027] Receive the list of second user information before or after the update returned by the second domain controller;

[0028] Update the first user information list locally on the first domain controller based on the second user information list returned by the second domain controller.

[0029] In one embodiment, notifying the second domain controller to create a user based on the first user identifier includes:

[0030] Send the first user identifier and the corresponding user permission management data to the second domain controller so that the second domain controller can create a user based on the first user identifier and the user permission management data.

[0031] A second aspect of this application provides a domain controller, comprising:

[0032] Processor; and

[0033] A memory that stores executable code, which, when executed by the processor, causes the processor to perform the method described above.

[0034] A third aspect of this application provides a vehicle, the vehicle being equipped with a plurality of domain controllers, the plurality of domain controllers including at least a first domain controller and a second domain controller connected via an in-vehicle Ethernet, the first domain controller comprising:

[0035] Processor; and

[0036] A memory that stores executable code, which, when executed by the processor, causes the processor to perform the method described above.

[0037] In one embodiment, the second domain controller is configured to assign a third user identifier to another target user from a second identifier set based on another preset user creation request, so that the domain controllers among the plurality of domain controllers create the user based on the third user identifier;

[0038] Wherein, the first identifier set of the first domain controller and the second identifier set of the second domain controller at least partially intersect or are completely identical; or,

[0039] The first set of identifiers of the first domain controller does not intersect with the second set of identifiers of the second domain controller.

[0040] A fourth aspect of this application provides a computer-readable storage medium having executable code stored thereon, which, when executed by a processor of a domain controller, causes the processor to perform the method described above.

[0041] The technical solutions provided in this application embodiment may include the following beneficial effects:

[0042] In some embodiments, the vehicle's first domain controller assigns a first user identifier to the target user based on a preset user creation request, creates the user locally based on the first user identifier, and notifies the second domain controller to create the user based on the first user identifier. This enables the distributed synchronous creation of the user's SOA service permissions, thereby allowing each domain controller of the vehicle to control the user's ability to control the vehicle based on the user's SOA service permissions, thus improving the security of vehicle use.

[0043] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0044] The above and other objects, features and advantages of this application will become more apparent from the more detailed description of exemplary embodiments thereof in conjunction with the accompanying drawings, wherein the same reference numerals generally represent the same components in the exemplary embodiments thereof.

[0045] Figure 1 This is a flowchart illustrating a user rights management method for vehicles according to an embodiment of this application;

[0046] Figure 2 This is a schematic diagram of SOA service grouping for a user rights management method for vehicles according to an embodiment of this application;

[0047] Figure 3 This is a flowchart illustrating a user rights management method for vehicles according to another embodiment of this application;

[0048] Figure 4 This is a flowchart illustrating a user rights management method for vehicles according to another embodiment of this application;

[0049] Figure 5 This is a flowchart illustrating a user rights management method for vehicles according to another embodiment of this application;

[0050] Figure 6 This is a schematic diagram of the structure of a domain controller according to an embodiment of this application. Detailed Implementation

[0051] Embodiments of this application will now be described in more detail with reference to the accompanying drawings. While embodiments of this application are shown in the drawings, it should be understood that this application may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided to make this application more thorough and complete, and to fully convey the scope of this application to those skilled in the art.

[0052] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used in this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the associated listed items.

[0053] It should be understood that although the terms "first," "second," "third," etc., may be used in this application to describe various information, this information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0054] This application provides a user rights management method for vehicles, which can control the user's ability to control the vehicle, thereby improving the security of vehicle use.

[0055] The technical solutions of the embodiments of this application are described in detail below with reference to the accompanying drawings.

[0056] This application embodiment is a user rights management method for vehicles. The vehicle is equipped with multiple domain controllers, and the multiple domain controllers include at least a first domain controller and a second domain controller.

[0057] In some embodiments, the first domain controller and the second domain controller are connected via an in-vehicle Ethernet network. Each of the first and second domain controllers can be connected to actuators within its corresponding control domain, for example, via a CAN bus. These actuators may include, for example, door actuators, window actuators, headlight actuators, air conditioning system actuators, driving system actuators, etc.

[0058] The second domain controller is configured with SOA (Service-Oriented Architecture) services and provides a calling interface to the first domain controller. The first domain controller can send SOA service call parameters to the second domain controller through the calling interface to invoke the SOA service. The second domain controller generates control signals based on the SOA service call parameters to control the corresponding actuators.

[0059] Figure 1 This is a flowchart illustrating a user rights management method for vehicles according to an embodiment of this application.

[0060] See Figure 1 A user access control method for vehicles, for a first domain controller, comprising:

[0061] In S110, a first user identifier is assigned to the target user from the first identifier set according to the preset user creation request.

[0062] In this embodiment of the application, each target user has a unique global user identifier.

[0063] In one embodiment, when the first domain controller receives a preset user creation request from the target user, it assigns a first user identifier to the target user. The first user identifier may be a user identifier selected from a first identifier set.

[0064] In S120, a user is created locally on the first domain controller based on the first user identifier.

[0065] In S130, at least the second domain controller is notified to create a user based on the first user identifier.

[0066] In this embodiment, user creation based on a user identifier includes: establishing an association between the user identifier and the target user's SOA service permission data. In one embodiment, the SOA service permission data includes SOA service access permission data and / or SOA service access priority data. In another embodiment, establishing the association between the user identifier and the target user's SOA service permissions includes, for example, adding the target user's user identifier to the user group list corresponding to the SOA service permissions.

[0067] In one embodiment, user creation based on a first user identifier on the local machine of the first domain controller includes: the first domain controller creating user permission management data for the target user based on the target user's SOA service permission information and the first user identifier assigned to the target user; the user permission management data may include the first user identifier and an SOA service access permission flag, wherein the parameter value of the SOA service access permission flag corresponds to the target user's SOA service permission information.

[0068] In one embodiment, notifying the second domain controller to create a user based on the first user identifier includes: sending a user creation request including user rights management data to the second domain controller, causing the second domain controller to store the user rights management data locally.

[0069] In one embodiment, SOA service permissions include SOA service access permission level and / or SOA service access priority. SOA service access priority is used to arbitrate access conflicts when multiple users access the same SOA service. SOA service access permission level corresponds to SOA service access permission, which limits a user's ability to access the SOA service. Only when a user's SOA service access permission meets the permission requirements of the accessed service can the user successfully access the service.

[0070] In a specific instance, such as Figure 2 As shown, to manage access to SOA services by users with different permissions, SOA services are divided into three groups: Level 0 Basic Function Service Group 201, Level 1 Restricted Function Service Group 202, and Level 2 Restricted Function Service Group 203. Level 0 Basic Function Service Group 201 has the lowest permission level and defines the basic SOA services that external applications can access by default. Level 1 Restricted Function Service Group 202 defines the SOA services that in-vehicle applications can access by default; external applications need special authorization to access services in this group. Level 2 Restricted Function Service Group 203 has the highest permission level and defines in-vehicle security-related SOA services; only authorized security applications can access them.

[0071] A user's SOA service access permissions can be used to restrict which levels of SOA service groups a user can access. User SOA service permissions can include SOA service access permission flags. Different SOA service access permission flags can represent different SOA service access permissions. For example, SOA service access permission flags can be L0, L1, and L2. A user with an SOA service access permission flag of L0 can only access SOA services in the Level 0 basic functional service group; a user with an SOA service access permission flag of L1 can access SOA services in the Level 1 restricted functional service group and the Level 0 basic functional service group; a user with an SOA service access permission flag of L2 can access SOA services in all groups of the Level 0 basic functional service group, the Level 1 restricted functional service group, and the Level 2 restricted functional service group.

[0072] In one embodiment, the SOA service permissions of a target user can be determined based on the source of a preset user creation request. For example, if the user creation request comes from an external application on a remote user terminal, the target user's SOA service access permission can be marked as L0 based on the information that the preset user creation request comes from an external application, allowing access to the SOA services of the Level 0 basic function service group.

[0073] In one embodiment, the user permission management method further includes: deregistering a first user identifier locally on a first domain controller according to a preset user deregistration request; and notifying a second domain controller to deregister the first user identifier via an SOA service interface. The user deregistration request may be a user deregistration request from the local application layer of the first domain controller, or it may be a user creation response message indicating a user identifier conflict, wherein the user creation response message originates from any other domain controller besides the first domain controller among multiple domain controllers.

[0074] In some embodiments, the vehicle's first domain controller assigns a first user identifier to the target user based on a preset user creation request, creates the user locally based on the first user identifier, and notifies the second domain controller to create the user based on the first user identifier. This enables the distributed synchronous creation of the user's SOA service permissions, ensuring the global visibility and global uniqueness of the user's SOA service permission management data. As a result, each domain controller of the vehicle can control the user's ability to control the vehicle based on the user's SOA service permissions, thereby improving the security of vehicle use.

[0075] In this embodiment, each domain controller may have a domain master controller or a distributed deployment of multiple ECU (Electronic Control Unit) nodes, and each domain controller is equipped with a user and permission management module. The multiple domain controllers of the vehicle achieve distributed synchronous management of user permissions through the distributed user and permission management module. Distributed management of user permissions includes, for example, creating user permission management data, synchronizing user permission management data, and deregistering user permission management data.

[0076] In one embodiment, after the first domain controller successfully creates a user locally based on the first user identifier, it notifies the second domain controller and other domain controllers (if any) among the plurality of domain controllers to create a user based on the first user identifier; and after S130, the following is also included:

[0077] In S140, if the second domain controller and other domain controllers have successfully created users based on the first user identifier, confirm that all domain controllers have successfully created users based on the first user identifier, and end the process.

[0078] In one embodiment, the first domain controller sequentially notifies the other domain controllers (excluding the first domain controller) to create corresponding users according to a preset user creation order.

[0079] Taking a scenario where multiple domain controllers consist of a first domain controller, a second domain controller, and a third domain controller, and users are created in the order of the first domain controller, the second domain controller, and the third domain controller, as an example, the first domain controller, the second domain controller, and the third domain controller can share a user ID pool, meaning that the range of available user IDs allocated to the first domain controller, the second domain controller, and the third domain controller overlaps or intersects.

[0080] After the first domain controller creates a user based on the first user identifier, it notifies the second domain controller to create a user based on the first user identifier. If the first domain controller determines a user identifier conflict based on the user creation response message returned by the second domain controller, it will not notify the third domain controller to create a user based on the first user identifier, and will deregister the first user identifier locally. Afterwards, a second user identifier different from the first user identifier can be reassigned for user creation. If the first domain controller determines no user identifier conflict based on the user creation response message returned by the second domain controller, it continues to notify the third domain controller to create a user based on the first user identifier. If the first domain controller determines a user identifier conflict based on the user creation response message returned by the third domain controller, it deregisters the first user identifier locally and notifies the second domain controller to deregister the first user identifier. Afterwards, a second user identifier can be reassigned for user creation. If the first domain controller determines no user identifier conflict based on the user creation response message returned by the third domain controller, since the third domain controller is the last domain controller to be synchronized, it can confirm that all domain controllers have successfully created users based on the first user identifier, and can therefore, for example, return a success message to a remote user terminal.

[0081] Understandably, when the first domain controller reassigns a second user identifier different from the first user identifier for user creation, it re-instructs the second and third domain controllers to create the user based on the second user identifier, until all three domain controllers successfully create user access control data for the target user based on the same conflict-free user identifier. Understandably, the process of the first, second, and third domain controllers creating users based on the second user identifier can be referenced from the process of creating users based on the first user identifier, and will not be elaborated further.

[0082] The following section will provide a more detailed explanation using a specific implementation as an example.

[0083] After the first domain controller receives the user creation request from the remote user terminal through the local application layer SWC, it calls the user creation method CreateUser() of the service management module SM1 of the first domain controller with the SOA service permission information of the target user as the calling parameter. This causes the service management module SM1 to call the new user creation method CreateNewUser() of the user and permission management module UAM1 of the first domain controller, so that the user and permission management module assigns a first user identifier to the target user locally on the first domain controller and establishes the association between the first user identifier and the SOA service permissions.

[0084] After the User and Access Management (UAM1) module on the first domain controller successfully creates a user based on the first user identifier, it uses the first user identifier and the corresponding SOA service permissions as call parameters. Through the local communication management layer CM1 of the first domain controller and the communication management layer CM2 of the second domain controller, it calls the user creation method `CreateUser()` of the User and Access Management (UAM2) module on the second domain controller. This causes the User and Access Management (UAM2) module to call the new user creation method `CreateNewUser()` to create a new user based on the first user identifier and SOA service permissions. Then, the User and Access Management (UAM2) module returns a user creation response message to the User and Access Management (UAM1) module on the first domain controller.

[0085] The new user creation method called by the User and Access Management module UAM2 may include: searching for a first user identifier among the user identifiers already allocated and used by the second domain controller to determine whether the second domain controller has already created a user using the first user identifier, i.e., determining whether there is a user identifier conflict between the first user identifier and the user identifier of the second domain controller; if there is a user identifier conflict between the first user identifier and the user identifier of the second domain controller, returning a user creation response message indicating a user identifier conflict to the first domain controller; if there is no user identifier conflict between the first user identifier and the user identifier of the second domain controller, the second domain controller creates the user based on the first user identifier and returns a user creation response message indicating successful creation of user access management data to the first domain controller.

[0086] Understandably, the first domain controller can use the same method to notify the second and third domain controllers to create the corresponding users. The above explanation uses the example of the first domain controller notifying the second domain controller to create users as an example; the scenario of the first domain controller notifying the third domain controller to create users can be deduced similarly and will not be elaborated further.

[0087] The service management module SM1 of the first domain controller can confirm that all domain controllers have successfully created users based on the first user identifier by receiving user creation response messages from the user and permission management modules UAM1, UAM2, and UAM3 of the three domain controllers, indicating that the user has been successfully created. Then, for example, it can return a creation success message to the remote user terminal through the application layer.

[0088] If the user and permission management module UAM1 of the first domain controller determines that a conflict has occurred with the first user identifier, it can use the first user identifier as a calling parameter to call the user deregistration method DestroyUser() of the corresponding domain controller, so that the user and permission management module of the corresponding domain controller will deregister the first user identifier.

[0089] The user rights management method for vehicles provided in this application embodiment can be any suitable domain controller of the vehicle, and this application embodiment does not limit this.

[0090] Figure 3 This is a flowchart illustrating a user rights management method for a vehicle according to another embodiment of this application. For ease of understanding, the following description uses a specific example, in which the vehicle's multiple domain controllers include, but are not limited to, a center domain control unit (CDCU), a left domain control unit (LDCU), and a right domain control unit (RDCU). The first domain controller can be a CDCU, and the second domain controller can be an LDCU.

[0091] See Figure 3 A user access control method for vehicles, applied to a central domain controller, the method comprising:

[0092] In S311, a first user identifier is assigned to the target user from the first identifier set according to the preset user creation request.

[0093] In S312, the user is created locally on the central domain controller based on the first user identifier. If the creation is successful, S313 is executed.

[0094] In S313, the middle domain controller instructs the left and right domain controllers to create users based on the first user identifier and the corresponding SOA service permission data, respectively.

[0095] In one embodiment, when the middle domain controller invokes the SOA service of the left domain controller, it can use the first user identifier and the corresponding SOA service permission data as SOA service invocation parameters to notify the left domain controller to create a user based on the first user identifier and the corresponding SOA service permission data. The process of the middle domain controller notifying the right domain controller to create a user is similar and will not be described in detail here.

[0096] In S314, if the middle domain controller determines that a user identifier conflict has occurred based on the user creation response message returned by the left or right domain controller, it shall deregister the first user identifier locally on the middle domain controller; and notify the domain controllers on the left and right domain controllers that have successfully created the user based on the first user identifier to deregister the first user identifier.

[0097] In one embodiment, when the middle domain controller invokes the SOA service of the left domain controller, it can use the first user identifier as an SOA service invocation parameter to notify the left domain controller to deregister the first user identifier. The process of the middle domain controller notifying the right domain controller to register users is similar and will not be described in detail here.

[0098] In one embodiment, if the middle domain controller determines that a user identifier conflict has occurred based on the user creation response message returned by the second domain controller, it assigns a second user identifier, which is different from the first user identifier, to the target user from the first identifier set, creates the user locally on the middle domain controller based on the second user identifier, and notifies the left domain controller and the right domain controller to create the user based on the second user identifier.

[0099] The following is a more detailed example.

[0100] A100: The CDCU receives a user creation request for the target user sent by the remote user terminal. Based on the application source information contained in the user creation request, it determines the SOA service access permission level (SrvAccessLevel) and SOA service access priority (SrvAccessPriority) corresponding to the target user. Then, the CDCU determines whether the target user's SOA service access priority and access permission level are valid according to the preset highest SOA service access priority and highest SOA service access permission level. If the target user's SOA service access priority and access permission level are valid, a first user identifier is assigned to the target user for user creation. If the target user's SOA service access priority and / or SOA service access permission level are invalid, error handling is performed, for example, returning a message indicating invalid creation to the remote user terminal.

[0101] The CDCU can assign user identifiers to users through static configuration or dynamic allocation. Static configuration is used for in-vehicle applications, while dynamic allocation is used for out-of-vehicle applications. In a specific implementation, the range of available user identifiers is 0x0 to 0xFFFFFFFE, where 0x0 and 0xFFFFFFFF are reserved user identifiers, and 0xFFFFFFFF represents an invalid ID. Different ranges of available user identifiers can be configured for static configuration and dynamic allocation, referred to as the first identifier range and the second identifier range, respectively. For example, the first identifier range for static configuration corresponding to in-vehicle applications is 0x1 to 0x0FFFFFF, while the second identifier range for dynamic allocation corresponding to out-of-vehicle applications is 0x10000000 to 0xFFFFFFFE.

[0102] After the CDCU (Access Control Unit) determines that the SOA service access priority and service access permission level of the target user are valid, it dynamically allocates a first user identifier to the target user from a first identifier set, where the first identifier set is a subset of the first identifier range. If there are free identifiers available for allocation in the first identifier set, a first user identifier (DyncID) is selected for the target user from the free identifiers. Then, using the first user identifier (DyncID), SOA service access permission level (SrvAccessPriority), and SOA service access priority (SrvAccessLevel) as calling parameters, the local user creation method is called to create the user locally. The target user's first user identifier, SOA service access permission level, and SOA service access priority are bound, user permission management data is created for the target user, and a message indicating successful user creation is returned to the remote user terminal. If all identifiers in the first identifier set have been allocated and no free identifiers are available for allocation to the target user, the user identifier allocation fails, and preset error handling can be performed. For example, a message indicating that user creation cannot be performed can be returned to the remote user terminal.

[0103] After successfully creating a user locally based on the first user identifier, the A300 CDCU notifies the LDCU to create a user based on the first user identifier through the SOA service interface when subsequently calling the LDCU's SOA service, and also notifies the RDCU to create a user based on the first user identifier when calling the RDCU's SOA service.

[0104] The CDCU can use the same method to notify the LDCU and RDCU to create the corresponding users. The following explanation uses the example of the CDCU notifying the LDCU to create users. The case of the CDCU notifying the RDCU to create users can be deduced by analogy and will not be elaborated further.

[0105] In one specific implementation, after the CDCU's application layer SWC receives a user creation request from a remote user terminal, it calls the user creation method CreateUser() of the CDCU's local service management module SMC, using the target user's SOA service permission information as the calling parameter. The service management module SMC then calls the new user creation method CreateNewUser() of the CDCU's local user and permission management module UAMC, causing the user and permission management module UAMC to assign a first user identifier to the target user and establish a connection between the first user identifier and the target user's SOA service permission data. Then, the user and permission management module UAMC returns a user creation response message to the service management module SMC. If the creation is successful, the response message contains the first user identifier, and the service management module SMC can return a successful user creation prompt message to the remote user terminal through the application layer SWC.

[0106] When the CDCU subsequently calls the LDCU's SOA services, the User and Access Management Module (UAMC) calls the Method type service interface of the CDCU's Communication Management Module (CMC) to send a service call request to the LDCU's Communication Management Module (CML). This request includes the first user identifier, SOA service permission data, and SOA service access information parameters, such as the SOA service identifier and the second domain controller identifier. Upon receiving the service call request, the LDCU's Communication Management Module (CML) sends a remote user creation notification containing the first user identifier and SOA service permission data to the LDCU's User and Access Management Module (UAML). The UAML then calls the CreateNewUser() method to create the user based on the first user identifier.

[0107] In one embodiment, the new user creation method called by the LDCU's user and permission management module UAML includes: searching for a first user identifier among the user identifiers already allocated and used by the LDCU to determine whether the LDCU has already created a user using the first user identifier, that is, determining whether there is a user identifier conflict between the first user identifier newly created by the CDCU and the user identifier of the LDCU; if there is a user identifier conflict between the first user identifier newly created by the CDCU and the user identifier of the LDCU, the LDCU returns a remote user creation response message indicating a user identifier conflict to the CDCU; if there is no user identifier conflict between the first user identifier newly created by the CDCU and the user identifier of the LDCU, the LDCU creates the user according to the first user identifier and returns a remote user creation response message indicating successful creation to the CDCU.

[0108] Specifically, the LDCU's User and Access Management Module (UAML) returns a remote user creation response message to the CDCU's User and Access Management Module (UAMC) through the LDCU's Communication Management Layer (CML) and the CDCU's Communication Management Layer (CMC). The CDCU's User and Access Management Module (UAMC) then calls the service call response method GetMethodResult() of the Communication Management Layer to retrieve the LDCU's remote user creation response message.

[0109] If the CDCU determines that a user identifier conflict has occurred based on the user creation response message returned by the LDCU or RDCU, it will deregister the first user identifier locally in the CDCU and notify the domain controllers in the LDCU and RDCU that have successfully created the user based on the first user identifier to deregister the first user identifier.

[0110] In one specific implementation, taking the case where LDCU has successfully created a user based on the first user identifier, and RDCU returns a remote user creation response message indicating a user identifier conflict, if the CDCU's user and permission management module UAMC determines that a user identifier conflict has occurred based on the remote user creation response message returned by the LDCU's user and permission management module UAML, it calls the user deletion method DeleteUser() to deregister the first user identifier locally. Additionally, the CDCU's user and permission management module UAMC calls the LCDU's user deregistration method DestroyUser() with the first user identifier as the calling parameter, notifying the LCDU's user and permission management module UAML to deregister the first user identifier. UAML then calls the user deletion method DeleteUser() to deregister the first user identifier in the LCDU.

[0111] In some embodiments, if the CDCU determines that a first user identifier conflict has occurred based on the user creation response message returned by the RDCU, the CDCU will cancel the first user identifier locally and can notify the RDCU to cancel the first user identifier when calling the RDCU's SOA service in a subsequent manner.

[0112] In this embodiment, any domain controller of the vehicle can apply the described method to create users. The allocation of user identifiers for target users by each domain controller is independent. When multiple domain controllers respond to their received user creation requests and create target users, they may assign the same user identifier to different target users, leading to user identifier conflicts. For example, when the CDCU creates a user for one target user, it allocates a user identifier from a first identifier set, and when the RDCU creates a user for another target user, it allocates a user identifier from a second identifier set. In some embodiments, the first identifier set allocated to the first domain controller and the second identifier set allocated to the second domain controller are at least partially intersecting or completely identical. The CDCU and RDCU may assign the same user identifier to their respective target users, leading to user identifier conflicts. In some embodiments, after creating a user, the CDCU notifies other domain controllers to create the corresponding user, enabling each domain controller to complete the synchronous creation of users with conflict-free user identifiers in a timely manner, resulting in good real-time performance.

[0113] In one embodiment, the first identifier set of the first domain controller and the second identifier set of the second domain controller can be configured to be disjoint, thereby avoiding user identifier conflicts. After the first domain controller completes user creation locally, it can "piggyback" on the second domain controller's SOA service until it needs to call the second domain controller's service to synchronize user creation. This reduces remote communication overhead and saves valuable bandwidth.

[0114] Figure 4This is a flowchart illustrating a user rights management method for vehicles, as shown in another embodiment of this application. This embodiment can... Figure 1 The process is executed after S120 in the illustrated embodiment to implement the notification in S130 to the second domain controller to create a user based on the first user identifier. It is understood that this application is not limited thereto; for example, this embodiment may also... Figure 1 The process is executed after S130 in the illustrated embodiment.

[0115] See Figure 4 A user access control method for vehicles, applied to a first domain controller, the method comprising:

[0116] In S411, when the preset active synchronization conditions are met, the first user information list on the local machine of the first domain controller is obtained. The first user information list includes user permission management data corresponding to the first user identifier and user permission management data of other users created locally on the first domain controller.

[0117] Preset active synchronization conditions can include power-on initialization, disconnection and reconnection, device restart, etc. Alternatively, active synchronization can be triggered according to a set period.

[0118] In S412, a first user information list is sent to the second domain controller through the SOA service interface, so that the second domain controller updates its local second user information list based on the first user information list.

[0119] The second user information list includes user permission management data for users created locally on the second domain controller.

[0120] In S413, the second user information list before or after the update is received from the second domain controller.

[0121] In S414, the first user information list on the local machine of the first domain controller is updated based on the second user information list returned by the second domain controller.

[0122] The following example uses LDCU as the first domain controller and CDCU as the second domain controller, and provides a more detailed explanation with a specific implementation.

[0123] When the LDCU determines that the preset active synchronization conditions are met, the LDCU's Service Management Module (SML) calls the LDCU's User and Permission Management Module (UAML) user synchronization method `ResyncUsers()`. The UAML copies the user permission management data of all users stored locally in the LDCU to the first user information list. Using the first user information list as a service call parameter, the LDCU's User and Permission Management Module (UAML) calls the SOA service interface of type `Method` in the LDCU's Communication Management Layer (CML). The CML then sends the first user information list and the user synchronization request to the CDCU's Communication Management Layer (CMC). Upon receiving the user information list and user synchronization request from the LDCU, the CDCU's Communication Management Layer (CMC) sends a user synchronization event notification to the CDCU's User and Permission Management Module (UAMC). The UAMC updates the CDCU's local second user information list based on the user permission management data in the first user information list and returns the updated second user information list as a response parameter to the LDCU's User and Permission Management Module (UAML) through the CDCU's Communication Management Layer (CMC) and the LDCU's Communication Management Layer (CML). The User and Permission Management module (UAML) calls the GetMethodResult() method of the Communication Management Layer (CML) to obtain the second user information list returned by the CDCU, and updates the user permission management data in the first user information list of the LDCU according to the user permission management data in the second user information list.

[0124] Figure 5 This is a flowchart illustrating another embodiment of a user rights management method for vehicles according to this application. The method in this embodiment is used to deregister the user rights management data of a target user on each domain controller. For ease of explanation, the following description uses the example of the LDCU deregistering the target user's user rights management data locally, and then synchronously deregistering the target user's user rights management data in both the CDCU and RDCU through delayed synchronization.

[0125] See Figure 5 A user access control method for vehicles, applied to a first domain controller, includes:

[0126] In S511, the first user ID is deregistered locally on the first domain controller based on a preset user deregistration request.

[0127] In S512, when the SOA service of the second domain controller is called subsequently, the second domain controller is notified to cancel the first user ID through the SOA service interface.

[0128] The following example, using LDCU as the first domain controller and CDCU as the second domain controller, provides a more detailed explanation with a specific implementation. After LDCU receives a user logout request from a remote user terminal via its local application layer SWC, it calls the DestroyUser() method of the Service Management Module (SML). This causes SML to call the DeleteUser() method of LDCU's User and Permission Management Module (UAML), deleting the user permission management data corresponding to the first user identifier. SML can then confirm the successful logout of the first user identifier locally by returning a logout response message from UAML, indicating successful deletion. This can then be used, for example, by returning a successful logout message to the remote user terminal via the application layer.

[0129] When LDCU subsequently calls CDCU's SOA service, it uses the first user identifier as the service call parameter and calls the SOA service interface of type Method in LDCU's Communication Management Layer (CML) through the User and Permission Management Module (UAML) to send a user deregistration request to CDCU's Communication Management Layer (CMC). Upon receiving the user deregistration request, CDCU's Communication Management Layer (CMC) sends a remote user deregistration notification containing the first user identifier to CDCU's User and Permission Management Module (UAMC). The User and Permission Management Module (UAMC) then calls the user deletion method DeleteUser() to delete the user permission management data corresponding to the first user identifier in CDCU. Finally, it returns a remote user deregistration response message to LDCU's User and Permission Management Module (UAML) through both CDCU's Communication Management Layer (CMC) and LDCU's Communication Management Layer (CML).

[0130] Figure 6 This is a schematic diagram of the structure of a domain controller according to an embodiment of this application.

[0131] See Figure 6 The domain controller 1000 includes a memory 1010 and a processor 1020.

[0132] The processor 1020 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0133] Memory 1010 may include various types of storage units, such as system memory, read-only memory (ROM), and permanent storage devices. ROM may store static data or instructions required by processor 1020 or other modules of the computer. Permanent storage devices may be read-write storage devices. Permanent storage devices may be non-volatile storage devices that retain stored instructions and data even when the computer is powered off. In some embodiments, permanent storage devices use mass storage devices (e.g., magnetic or optical disks, flash memory) as permanent storage devices. In other embodiments, permanent storage devices may be removable storage devices (e.g., floppy disks, optical drives). System memory may be a read-write storage device or a volatile read-write storage device, such as dynamic random access memory. System memory may store some or all of the instructions and data required by the processor during operation. Furthermore, memory 1010 may include any combination of computer-readable storage media, including various types of semiconductor memory chips (e.g., DRAM, SRAM, SDRAM, flash memory, programmable read-only memory), and disks and / or optical disks may also be used. In some embodiments, the memory 1010 may include a removable storage device that is readable and / or writable, such as a laser disc (CD), a read-only digital multifunction optical disc (e.g., DVD-ROM, dual-layer DVD-ROM), a read-only Blu-ray disc, a high-density optical disc, a flash memory card (e.g., SD card, mini SD card, Micro-SD card, etc.), a magnetic floppy disk, etc. Computer-readable storage media do not contain carrier waves or transient electronic signals transmitted wirelessly or via wired connections.

[0134] The memory 1010 stores executable code, which, when processed by the processor 1020, can cause the processor 1020 to execute part or all of the methods described above.

[0135] Furthermore, one embodiment of this application also provides a vehicle, which is equipped with multiple domain controllers, including at least a first domain controller and a second domain controller connected via an in-vehicle Ethernet, wherein the first domain controller includes:

[0136] Processor; and

[0137] The memory stores executable code, which, when executed by the processor, causes the processor to perform the method described above.

[0138] In one embodiment, the vehicle's first domain controller assigns a first user identifier to a target user from a first identifier set according to a preset user creation request; performs user creation locally on the first domain controller based on the first user identifier; and notifies at least other domain controllers among a plurality of domain controllers, such as a second domain controller, to perform user creation based on the first user identifier.

[0139] In one embodiment, the second domain controller of the vehicle is configured to assign a third user identifier to another target user from a second identifier set according to another preset user creation request, and to perform user creation locally on the second domain controller based on the third user identifier; and to notify at least other domain controllers (including the first domain controller) among a plurality of domain controllers to perform user creation based on the third user identifier, so that the plurality of domain controllers perform user creation synchronously based on the third user identifier.

[0140] In one embodiment, the first identifier set of the first domain controller and the second identifier set of the second domain controller are at least partially intersecting or completely identical; or, the first identifier set of the first domain controller and the second identifier set of the second domain controller do not intersect.

[0141] The specific manner in which the vehicle's first and second domain controllers perform operations has been described in detail in the embodiments of the method, and will not be elaborated further here.

[0142] Furthermore, the method according to this application can also be implemented as a computer program or computer program product, which includes computer program code instructions for performing some or all of the steps in the method described above.

[0143] Alternatively, this application may be implemented as a computer-readable storage medium (or a non-transitory machine-readable storage medium or a machine-readable storage medium) storing executable code (or computer program or computer instruction code) thereon, which, when executed by a processor of a domain controller (or server, etc.), causes the processor to perform part or all of the steps of the methods described above according to this application.

[0144] The various embodiments of this application have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or improvement of the technology in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A user access control method for vehicles, characterized in that, The vehicle is equipped with multiple domain controllers, the multiple domain controllers including at least a first domain controller and a second domain controller, the method being used on the first domain controller, including: Based on the preset user creation request, assign a first user identifier to the target user from the first identifier set; The user is created locally on the first domain controller based on the first user identifier; and... Obtain a first user information list local to the first domain controller, the first user information list including the first user identifier; The first user information list is sent to the second domain controller through the SOA service interface, so that the second domain controller updates the second user information list locally based on the first user information list. At least notify the second domain controller to create a user based on the first user identifier; Receive the list of second user information before or after the update returned by the second domain controller; Update the first user information list locally on the first domain controller based on the second user information list returned by the second domain controller; The step of creating a user based on the first user identifier includes: establishing an association between the first user identifier and the SOA service permission data of the target user.

2. The method according to claim 1, characterized in that, The method further includes: If a user identifier conflict is determined to occur based on the user creation response message returned by the second domain controller, a second user identifier different from the first user identifier is assigned to the target user from the first identifier set. The user is then created locally on the first domain controller based on the second user identifier, and the second domain controller is notified to create the user based on the second user identifier.

3. The method according to claim 2, characterized in that, After determining that a user identifier conflict has occurred based on the user creation response message returned by the second domain controller, the process further includes: Log out the first user ID locally on the first domain controller; and, The SOA service interface is used to notify other domain controllers among the multiple domain controllers that have successfully created a user based on the first user identifier to deregister the first user identifier.

4. The method according to claim 1, characterized in that, The method further includes: Based on a preset user logout request, the first user identifier is logged out locally on the first domain controller; and... The second domain controller is notified to cancel the first user identifier via the SOA service interface; The user logout request can be either a user logout request from the local application layer of the first domain controller or a user creation response message indicating a user identifier conflict, wherein the user creation response message comes from any other domain controller other than the first domain controller among the plurality of domain controllers.

5. The method according to claim 1, characterized in that, The method further includes: When the preset user logout conditions are met, the first user identifier is logged out locally on the first domain controller, and when the SOA service of the second domain controller is invoked, the second domain controller is notified to log out the first user identifier through the SOA service interface.

6. The method according to claim 1, characterized in that, The notification to the second domain controller to create a user based on the first user identifier includes: When invoking the SOA service of the second domain controller, the first user identifier and the SOA service permission data are used as SOA service invocation parameters, and the second domain controller is notified through the SOA service interface to create a user based on the first user identifier.

7. The method according to claim 1, characterized in that, The notification to the second domain controller to create a user based on the first user identifier includes: Send the first user identifier and the corresponding user permission management data to the second domain controller so that the second domain controller can create a user based on the first user identifier and the user permission management data.

8. A domain controller, characterized in that, include: processor; as well as A memory having executable code stored thereon, which, when executed by the processor, causes the processor to perform the method as described in any one of claims 1-7.

9. A vehicle, characterized in that, The vehicle is equipped with multiple domain controllers, which include at least a first domain controller and a second domain controller connected via an in-vehicle Ethernet, wherein the first domain controller includes: Processor; and A memory having executable code stored thereon, which, when executed by the processor, causes the processor to perform the method as described in any one of claims 1-7.

10. The vehicle according to claim 9, characterized in that: The second domain controller is configured to assign a third user identifier to another target user from a second identifier set based on another preset user creation request, so that the domain controllers among the plurality of domain controllers can create a user based on the third user identifier; Wherein, the first identifier set of the first domain controller and the second identifier set of the second domain controller at least partially intersect or are completely identical; or, The first set of identifiers of the first domain controller does not intersect with the second set of identifiers of the second domain controller.

11. A computer-readable storage medium, characterized in that: It stores executable code that, when executed by a processor, causes the processor to perform the method as described in any one of claims 1-7.

Images