Access control model construction method, access control policy generation method, and apparatus

Abstract

Disclosed in the present application are an access control model construction method, an access control policy generation method, and an apparatus. The access control policy generation method comprises: acquiring user configuration information, and inputting the user configuration information into an access control model to obtain an access control policy, the construction of the access control model being related to interfaces of functional components of a vehicle and the types of the interfaces, the user configuration information comprising attribute configuration information of the functional components of the vehicle, and the access control model being used for describing the access permission of the interfaces of the functional components of the vehicle with respect to at least one of a service resource, a network resource and a system resource. Thus, the present application improves the efficiency of access control policy configuration in in-vehicle scenarios, and improves the accuracy of access control policies.

Description

A method and apparatus for constructing an access control model and generating access control policies.

[0001] This application claims priority to Chinese Patent Application No. 202410704174.X, filed on May 31, 2024, entitled "An Access Control Model Construction, Access Control Policy Generation Method and Apparatus", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of vehicle safety technology, and in particular to a method and apparatus for constructing an access control model and generating access control policies. Background Technology

[0003] Configuring access control policies for vehicles can ensure the security, integrity, and privacy of the vehicle's internal systems, and improve the defense capabilities of in-vehicle software to better cope with increasing security challenges and threats.

[0004] In-vehicle software systems are complex software architectures that combine the software of multiple Electronic Control Units (ECUs) with various heterogeneous operating systems superimposed on traditional control systems. These heterogeneous operating systems include, for example, the vehicle's platform operating system (Platform OS), the data plane operating system associated with autonomous driving, and the microcontroller operating system (MCU OS) associated with vehicle control. Different operating systems may have different software architectures, and each operating system and each ECU's software has its own unique access control method, typically requiring manual configuration of corresponding access control policies by professionals in the relevant fields. Therefore, configuring access control policies is quite complex and inefficient. Summary of the Invention

[0005] This application discloses an access control model construction, access control policy generation method and apparatus, which can improve the configuration efficiency of access control policies in vehicle software systems and also help improve the accuracy of access control policies.

[0006] In a first aspect, this application provides an access control model construction method, which includes: obtaining information about multiple functional components of a vehicle, each functional component being used to implement a business function of in-vehicle software, the information of each functional component including the identifier of the functional component, the identifier of the interface of the functional component, and the type of the interface of the functional component; and constructing an access control model based on the information of the multiple functional components, the access control model being used to describe the access permissions of the interfaces of the multiple functional components to at least one of service resources, network resources, and system resources.

[0007] Here, the vehicle's functional components are a logical grouping; they do not represent actual software components or deployment units. In the actual software development process, the vehicle's functional components will be mapped to specific software components or part units. The functions of different functional components are orthogonal. That is, the functions of different functional components are independent and unrelated, and there is no interdependence between them.

[0008] The vehicle's multiple functional components include, for example, execution management components, network management components, configuration management components, safety management components, diagnostic management components, communication management components, log management components, time management components, etc.

[0009] In the aforementioned vehicle software, software refers to a collection of computer data and instructions organized in a specific order. Generally speaking, software is divided into system software, application software, and middleware that falls between the two. Software includes not only programs that can run on a computer, but also the documentation associated with these programs.

[0010] In the above method, an access control model is constructed based on the interfaces of the vehicle's functional components and the types of those interfaces. This constructed access control model can be used to generate access control policies. The access control model is applicable to different access control scenarios or access control mechanisms, avoiding the need for manual, discrete configuration of access control policies. This improves the configuration efficiency of in-vehicle access control policies and also helps to improve the accuracy of access control policies.

[0011] Optionally, the functional component includes at least one interface, and the interface types included in the functional component are at least one of service interfaces, system interfaces, and network interfaces. Here, one interface corresponds to one interface type. That is, the functional component includes at least one type of interface.

[0012] Implementing the above method provides an example of the type division of functional component interfaces. Based on the interface types of functional components, it is convenient to modularly model the subsequent access control model, so that the constructed model can cover different access control mechanisms or access scenarios of the whole vehicle.

[0013] Optionally, the vehicle's multiple functional components include a first group of functional components, each of which has a service interface, and the access control model includes a first access model. Based on the information of the aforementioned multiple functional components, an access control model is constructed, including: constructing a first access model based on a list of service interfaces of the first group of functional components. The first access model is used to describe the service provider and service consumer corresponding to each service interface in the list of service interfaces of the first group of functional components, the service resources associated with the access when each service interface is accessed, the system resources associated with the access, and the network resources associated with the access. Each functional component in the first group of functional components acts as the aforementioned service provider and / or service consumer.

[0014] The service provider is the party that implements the service functions (including control algorithms, functional logic, etc.), and the service consumer is the party that uses the service-oriented interface to call the service. The service consumer is also called the service visitor.

[0015] For example, the service resource includes at least one of the services and service-oriented interfaces.

[0016] The system resources associated with the aforementioned access include, for example, memory information, process scheduling, file system, pipes, signals, sockets, message queues, controller area network (CAN) bus resources (e.g., identifiers and data fields of CAN messages), FlexRay resources (e.g., frame definitions and channel configurations), local interconnect network (LIN) bus resources (e.g., frame definitions and communication rates), wireless communication resources (e.g., at least one of the configurations and parameters required for wireless communication technologies such as Wi-Fi, Bluetooth, and LTE), and global positioning system (GPS) resources (e.g., hardware and related configurations for receiving GPS signals).

[0017] The network resources associated with the aforementioned access include at least one of the following: IP address, subnet mask, gateway, MAC address, routing table, domain name system configuration information, dynamic host configuration protocol (DHCP) configuration information, virtual private network (VPN) configuration information, quality of service (QoS) information, network protocol information, and network security protocol information.

[0018] By implementing the above method, a service-oriented access control model (i.e., the first access model) is constructed based on the service interface list of the functional components. The first access model can reveal the access relationships between service resources when the service interfaces of the functional components are accessed, as well as the system resources and network resources involved when each access occurs.

[0019] Optionally, based on the list of service interfaces of the first set of functional components, a first access model is constructed, including:

[0020] Define a Service-Oriented Architecture (SOA) service communication matrix, which describes the access relationships between services and between services and service-oriented interfaces.

[0021] Define the service provider for the service;

[0022] Define the service consumer of the service;

[0023] Define the system resources required for each access relationship in the SOA service communication matrix; and

[0024] Define the network resources required for each access relationship in the SOA service communication matrix.

[0025] Here, the services mentioned above are those provided by each functional component in the first group of functional components.

[0026] Service providers and service consumers are, for example, at least one of the following: a process in a Linux-like operating system, a network node, and a task in a real-time operating system (RTOS). Functional components with service-oriented interfaces can act as both service providers and service consumers.

[0027] By implementing the above method, the model parameters of the first access model include service providers, service consumers, SOA service communication matrix, system resources associated with each access relationship in the SOA service communication matrix, and network resources, thus realizing access control modeling for SOA.

[0028] Optionally, the vehicle's multiple functional components include a second set of functional components, each of which has a system interface, and the access control model includes a second access model; based on the information of the aforementioned multiple functional components, an access control model is constructed, including: based on the system interface list of the second set of functional components, constructing a second access model, the second access model being used to describe the system resources associated with the system interface of each functional component in the second set of functional components.

[0029] By implementing the above method, an access control model (i.e., the second access model) oriented towards system resources is constructed based on the system interface list of functional components. Through the second access model, the system resources associated with the system interfaces of the vehicle's functional components can be known, that is, the permissions of the system interfaces of the functional components to access system resources can be known.

[0030] Optionally, based on the system interface list of the second set of functional components, a second access model is constructed, including:

[0031] Define the system interfaces for the second set of functional components;

[0032] Define the system interfaces that the vehicle software needs to access in the system interfaces of the second set of functional components;

[0033] Define the component atomic policy for each functional component in the second group of functional components. The component atomic policy of a functional component includes the atomic policy corresponding to each system interface of the functional component. The atomic policy corresponding to each system interface is associated with the permission of the interface to system resources.

[0034] By implementing the above method, the model parameters of the second access model include the system interface of the functional component, the system interface to be accessed by the vehicle software, and the atomic policy corresponding to each system interface of the functional component. The system interface to be accessed by the vehicle software belongs to the system interface of the second group of functional components. Thus, the second access model also describes the system resources associated with the system interface to be accessed by the vehicle software, realizing access control modeling oriented towards system resources.

[0035] Optionally, the method further includes: constructing a third access model through the following operations:

[0036] Define a non-service-oriented architecture (SOA) in-vehicle communication matrix. The non-SOA in-vehicle communication matrix describes the access relationships between target nodes using in-vehicle network communication in non-SOA scenarios.

[0037] Define an external network access list, which includes firewall rules and domain filtering rules corresponding to the external networks that the in-vehicle software needs to access.

[0038] For example, in non-SOA scenarios, the access relationships between target nodes using in-vehicle network communication include point-to-point communication scenarios such as between two processes within an operating system, between the vehicle's microprocessor unit (MPU) and the vehicle's microcontroller unit (MCU), and between the vehicle's MPU and the attached sensors.

[0039] By implementing the above methods, the third access model, as a supplement to the first and second access models, realizes access control modeling for network resources. The constructed third access model can cover access scenarios between in-vehicle nodes and external nodes, as well as point-to-point communication scenarios where in-vehicle nodes use the in-vehicle network under non-SOA architecture.

[0040] Secondly, this application provides an access control policy generation method, which includes: obtaining user configuration information, including attribute configuration information of functional components of a vehicle; and obtaining an access control policy based on the user configuration information and an access control model. The access control model describes the access permissions of interfaces of multiple functional components of the vehicle to at least one of service resources, network resources, and system resources. Each functional component is used to implement a business function of the in-vehicle software. The access control model is constructed based on information from multiple functional components of the vehicle, and the information of each functional component includes the identifier of the functional component, the identifier of the interface of the functional component, and the type of the interface of the functional component.

[0041] In the above method, the construction of the access control model is related to the interface of the vehicle's functional components and the type of the interface. Based on the access control model, access control policies are automatically generated, avoiding discrete manual configuration of access control policies, which helps to improve the configuration efficiency and accuracy of access control policies.

[0042] Optionally, the functional components may include at least one of the following types of interfaces: service interfaces, system interfaces, and network interfaces.

[0043] Implementing the above method provides an example of classifying the interface types of functional components. The construction of the access control model is related to the interface types of functional components, which facilitates the modularization of access control policies generated by the access control model and makes them applicable to different access control mechanisms or access scenarios of the whole vehicle.

[0044] Optionally, the vehicle's functional components include a first functional component, which has a service-oriented interface, and an access control model including a first access model. Based on user configuration information and the access control model, an access control policy is obtained, including: inputting the attribute configuration information of the first functional component into the first access model to obtain the access control policy. The access control policy includes access policies for service resources associated with the target service, access policies for system resources associated with the target service, and access policies for network resources associated with the target service. The target service is a service provided by the first functional component. The attribute configuration information of the first functional component includes the identifier of the service provided by the first functional component, the identifier of the service that each service needs to access, the identifier of the service-oriented interface that each service needs to access, and the attribute information of the network associated with the access.

[0045] For example, the attribute information of the accessed network includes at least one of the following: the service's IP address, port, communication protocol, and whether a secure communication protocol is used.

[0046] By implementing the above method, the attribute configuration information of functional components with service interfaces is input into the first access model. The first access model is then used to generate access policies for SOA service resources, thereby improving the configuration efficiency of access control policies.

[0047] Optionally, the vehicle's functional components include a second functional component, which has system interfaces. The user configuration information also includes a list of system interfaces that the in-vehicle software needs to access. The access control model includes a second access model. Based on the user configuration information and the access control model, an access control policy is obtained, including: inputting the attribute configuration information of the second functional component and the list of system interfaces that the in-vehicle software needs to access into the second access model to obtain the access control policy. The access control policy includes the in-vehicle software's access policy for system resources. The list of system interfaces that the in-vehicle software needs to access belongs to the system interfaces of the second functional component. The attribute configuration information of the second functional component is used to determine the system resources associated with each system interface of the second functional component.

[0048] The attribute configuration information of the second functional component includes the identifier of the system interface of the second functional component and the system resources associated with each system interface of the second functional component.

[0049] The attribute configuration information of the second functional component is used to instantiate the atomic policies corresponding to the system interfaces defined in the second access model. For example, in the second access model, an interface (e.g., interface 1) is defined. Assuming interface 1 implements opening files and reading file directories, the atomic policies corresponding to interface 1 include: allowing interface 1 to access files, allowing interface 1 to access network cards, and allowing interface 1 to access the IP address of the peer. When using the second access model, the attribute configuration information of the second functional component and the list of system interfaces that the vehicle software needs to access are input into the second access model. Assuming that the list of system interfaces that the vehicle software needs to access includes interface 1, the second access model obtains the relevant information of interface 1 from the attribute configuration information of the second functional component. Based on the relevant information of interface 1, it can determine which file (i.e., file name), the file directory, and the path where the file is located, as well as which network card and which IP address of the peer that interface 1 is accessing. It can be seen that the system resources associated with interface 1 can be specifically determined through the attribute information of the second functional component, thus realizing the instantiation of the atomic policies corresponding to interface 1. Thus, the second access model instantiates the atomic policy corresponding to each system interface in the system interface list based on the system interface list that the vehicle software needs to access and the attribute configuration information of the second functional components. The result obtained after the atomic policy corresponding to each system interface is instantiated as the access policy of the vehicle software to system resources.

[0050] By implementing the above method, the attribute configuration information of functional components with system interfaces and the list of system interfaces to be accessed by the vehicle software are input into the second access model. The second access model is used to generate the access policy of the vehicle software system for system resources, which increases the richness and completeness of the access control policy.

[0051] Optionally, the user configuration information also includes at least one of external network access information and in-vehicle non-SOA access information. The external network access information is used to indicate the access relationship between in-vehicle nodes and external nodes, and the in-vehicle non-SOA access information is used to indicate the access relationship between target nodes using in-vehicle network communication in non-SOA scenarios. The access control model also includes a third access model. Based on the user configuration information and the access control model, an access control policy is obtained, including: inputting the external network access information and / or the in-vehicle non-SOA access information into the third access model to obtain the access control policy. The access control policy includes the access policy of network resources associated with the external network access information and / or the access policy of network resources associated with the in-vehicle non-SOA access information.

[0052] In non-SOA scenarios, target nodes for in-vehicle network communication include point-to-point communication nodes such as those between two processes within an operating system, between the vehicle's MPU and MCU, and between the vehicle's MPU and attached sensors.

[0053] By implementing the above method, the third access model is applicable to access scenarios between in-vehicle nodes and external nodes, as well as point-to-point communication scenarios using in-vehicle networks under non-SOA architectures. The third access model enables the generation of access policies for network resources by the in-vehicle software system, increasing the richness and completeness of the generated access control policies.

[0054] Optionally, obtaining an access control policy based on user configuration information and an access control model includes: obtaining first intermediate representation IR policy data based on user configuration information and an access control model, wherein the first IR policy data is an intermediate representation of the access control policy; and generating an access control policy based on the first IR policy data if the first IR policy data passes verification.

[0055] Here, the access control policy is policy data that can be directly deployed and run on the in-vehicle software system; that is, the access control policy is deployable and runnable policy data. However, the first IR policy data does not support direct deployment on the in-vehicle software system and must be converted into an access control policy before it can be used by the in-vehicle software system.

[0056] By implementing the above method, the access control model is converted into first IR policy data based on user configuration information. This enables the unified abstract description of access control semantics under different access mechanisms involved in the access control policy, making the verification of IR policy data possible. This improves the verification efficiency of policy data, the accuracy of the generated access control policy, and also helps to increase the scalability of the access control model.

[0057] Optionally, the method further includes: obtaining second IR policy data based on the access control objective, wherein the logical representation direction of the access control objective and the logical representation direction of the second IR policy data are both negative; verifying the first IR policy data using the second IR policy data to obtain verification result information, wherein the verification result information indicates the verification result of the first IR policy data.

[0058] The term "negative" refers to expressing something in a way that forbids doing it. Second IR strategy data can be understood as a rejection rule.

[0059] For example, the logical expression direction of the second IR strategy data is opposite to that of the first IR strategy data, which means that the logical expression direction of the first IR strategy data is positive. The so-called "positive" means that it is expressed in the form of allowing someone to do something. Therefore, the first IR strategy data can be understood as a kind of permission rule.

[0060] From the perspective of verification approach, the second IR strategy data and the first IR strategy data form a logical closed loop. Using the second IR strategy data to verify the first IR strategy data is a reverse verification, which enables the strategy data to converge correctly as soon as possible. This not only improves the accuracy of strategy verification but also improves the efficiency of strategy verification.

[0061] For example, the method further includes prompting the user to check user configuration information when the verification result information indicates that the first IR policy data has failed verification. In this way, the user can promptly check whether the configured system interfaces that the in-vehicle software needs to access, the access relationship information between in-vehicle network communication nodes in non-SOA scenarios, the whitelist for external network access, and the attribute configuration information of functional components are accurate.

[0062] Optionally, the method further includes: presenting the verification result information to the user via a display interface, including at least one of the following:

[0063] Verification results of the first IR strategy data;

[0064] The verification results of each IR strategy entry in the first IR strategy data;

[0065] The evaluation score corresponding to the verification result of each IR strategy item;

[0066] The comprehensive evaluation score corresponding to the first IR strategy data; and

[0067] Repair suggestions for IR policy entries that failed verification in the first IR policy data.

[0068] By implementing the above method, the verification results are presented to the user intuitively. Users can see not only the verification results of individual IR policy entries in the policy data, but also the overall verification status of the policy data. Furthermore, the suggested modifications provide a reference for users' adjustment methods, helping them quickly improve the policy verification process and increasing the policy verification pass rate and accuracy.

[0069] Optionally, the method further includes: indicating to the user the attribute information to be configured, the attribute information to be configured including attribute configuration items of the vehicle's functional components; obtaining user configuration information, including: receiving setting information input by the user; and obtaining user configuration information based on the setting information.

[0070] By implementing the above method, users can configure the attribute information of functional components. The attribute information of different functional components may be different, which has good interactivity.

[0071] Optionally, the attribute information to be configured may also include at least one of the following:

[0072] Whether the system interfaces of the vehicle's functional components are configuration items declared for use by the vehicle software;

[0073] Configuration items for access relationships between target nodes using in-vehicle network communication in non-SOA scenarios;

[0074] Configuration items for accessing external networks; and

[0075] Access control target.

[0076] By implementing the above method, the additional configuration items can enhance the richness of the generated access control policies. They are applicable not only to access control in SOA scenarios but also to access control in non-SOA scenarios, and also cover in-vehicle access control and access control between in-vehicle nodes and external nodes.

[0077] Optionally, the access control model is constructed based on the methods described in the first aspect or any possible implementation thereof. The beneficial effects of this technical feature are explained in the description of the beneficial effects of the corresponding technical feature in the first aspect, and will not be repeated here.

[0078] Thirdly, this application provides an apparatus for constructing an access control model. The apparatus includes: an acquisition unit for acquiring information about multiple functional components of a vehicle, each functional component implementing a business function of in-vehicle software; the information of each functional component includes an identifier of the functional component, an identifier of the functional component's interface, and the type of the functional component's interface; and a processing unit for constructing an access control model based on the information of the multiple functional components. The access control model describes the access permissions of the interfaces of the multiple functional components to at least one of service resources, network resources, and system resources. The access control model is used to obtain the vehicle's access control policy.

[0079] Optionally, the functional component includes at least one interface, and the interface included in the functional component is of at least one of the following types: service interface, system interface, and network interface.

[0080] Optionally, the vehicle's multiple functional components include a first group of functional components, each of which has a service interface, and the access control model includes a first access model. The processing unit is specifically used to: construct a first access model based on the service interface list of the first group of functional components. The first access model is used to describe the service provider and service consumer corresponding to each service interface in the service interface list of the first group of functional components, the service resources associated with the access when each service interface is accessed, the system resources associated with the access, and the network resources associated with the access. Each functional component in the first group of functional components acts as the aforementioned service provider and / or service accessor.

[0081] Optionally, the processing unit is specifically used to construct the first access model through the following operations: defining a service-oriented architecture (SOA) service communication matrix, which describes the access relationships between services and between services and service-oriented interfaces; defining the service provider of the service; defining the service consumer of the service; defining the system resources required for each access relationship in the SOA service communication matrix; and defining the network resources required for each access relationship in the SOA service communication matrix.

[0082] Optionally, the vehicle's multiple functional components include a second set of functional components, each of which has a system interface, and the access control model includes a second access model; the processing unit is specifically used to: construct a second access model based on the system interface list of the second set of functional components, the second access model being used to describe the system resources associated with the system interface of each functional component in the second set of functional components.

[0083] Optionally, the processing unit is specifically configured to construct a second access model through the following operations: defining system interfaces of the second set of functional components; defining system interfaces that the vehicle software needs to access in the system interfaces of the second set of functional components; defining component atomic policies for each functional component in the second set of functional components, wherein the component atomic policies of a functional component include atomic policies corresponding to each system interface of that functional component, and the atomic policies corresponding to each system interface are associated with the permissions of that system interface to system resources.

[0084] Optionally, the processing unit is also configured to: construct a third access model by: defining a non-service-oriented architecture (SOA) in-vehicle communication matrix, which describes the access relationships between in-vehicle nodes using in-vehicle network communication in non-SOA scenarios; and defining an external network access list, which includes firewall rules and domain name filtering rules corresponding to the external networks that the in-vehicle software needs to access.

[0085] Fourthly, this application provides an apparatus for generating access control policies. The apparatus includes: an acquisition unit for acquiring user configuration information, which includes attribute configuration information of functional components of a vehicle; and a processing unit for obtaining an access control policy based on the user configuration information and an access control model. The access control model describes the access permissions of interfaces of multiple functional components of the vehicle to at least one of service resources, network resources, and system resources. Each functional component implements a business function of in-vehicle software. The access control model is associated with information about the multiple functional components of the vehicle. The information of each functional component includes an identifier of the functional component, an identifier of the interface of the functional component, and the type of the interface of the functional component.

[0086] Optionally, the functional components may include at least one of the following types of interfaces: service interfaces, system interfaces, and network interfaces.

[0087] Optionally, the vehicle's functional components include a first functional component, which has a service-oriented interface, and the access control model includes a first access model. The processing unit is specifically used to: input the attribute configuration information of the first functional component into the first access model to obtain an access control policy. The access control policy includes an access policy for service resources associated with the target service, an access policy for system resources associated with the target service, and an access policy for network resources associated with the target service. The target service is a service provided by the first functional component. The attribute configuration information of the first functional component includes the identifier of the service provided by the first functional component, the identifier of the service that each service needs to access, the identifier of the service-oriented interface that each service needs to access, and the attribute information of the network associated with the access.

[0088] Optionally, the vehicle's functional components include a second functional component, which has system interfaces. The user configuration information also includes a list of system interfaces that the in-vehicle software needs to access. The access control model includes a second access model. The processing unit is specifically used to: input the attribute configuration information of the second functional component and the list of system interfaces that the in-vehicle software needs to access into the second access model to obtain an access control policy. The access control policy includes the in-vehicle software's access policy to system resources. The list of system interfaces that the in-vehicle software needs to access belongs to the system interfaces of the second functional component. The attribute configuration information of the second functional component is used to determine the system resources associated with each system interface of the second functional component.

[0089] Optionally, the user configuration information also includes at least one of external network access information and in-vehicle non-SOA access information. The external network access information is used to indicate the access relationship between in-vehicle nodes and external nodes, and the in-vehicle non-SOA access information is used to indicate the access relationship between target nodes using in-vehicle network communication in non-SOA scenarios. The access control model also includes a third access model. The processing unit is specifically used to: input the external network access information and / or the in-vehicle non-SOA access information into the third access model to obtain an access control policy. The access control policy includes the access policy of network resources associated with the external network access information and / or the access policy of network resources associated with the in-vehicle non-SOA access information.

[0090] Optionally, the processing unit is specifically configured to: obtain first intermediate representation IR policy data based on user configuration information and access control model, wherein the first IR policy data is an intermediate representation of access control policy; and generate access control policy based on the first IR policy data if the first IR policy data passes verification.

[0091] Optionally, the processing unit is further configured to: obtain second IR policy data based on the access control objective, wherein the logical expression direction of the access control objective and the logical expression direction of the second IR policy data are both negative; use the second IR policy data to verify the first IR policy data, obtain verification result information, and the verification result information indicates the verification result of the first IR policy data.

[0092] For example, the processing unit is further configured to: prompt the user to check the user configuration information when the verification result information indicates that the first IR strategy data has failed the verification.

[0093] Optionally, the device further includes a display unit for: presenting at least one of the following pieces of information from the verification result information to the user through a display interface:

[0094] Verification results of the first IR strategy data;

[0095] The verification results of each IR strategy entry in the first IR strategy data;

[0096] The evaluation score corresponding to the verification result of each IR strategy item;

[0097] The comprehensive evaluation score corresponding to the first IR strategy data; and

[0098] Repair suggestions for IR policy entries that failed verification in the first IR policy data.

[0099] Optionally, the display unit is also used to: indicate to the user the attribute information to be configured, including the attribute configuration items of the vehicle's functional components; the acquisition unit is specifically used to: receive the setting information input by the user; and obtain the user configuration information based on the setting information.

[0100] Optionally, the attribute information to be configured may also include at least one of the following:

[0101] Whether the system interfaces of the vehicle's functional components are configuration items declared for use by the vehicle software;

[0102] Configuration items for access relationships between target nodes using in-vehicle network communication in non-SOA scenarios;

[0103] Configuration items for accessing external networks; and

[0104] Access control target.

[0105] Optionally, the access control model described above is constructed based on the methods in the first aspect or any possible implementation of the first aspect.

[0106] Fifthly, this application provides a chip system including a memory and at least one processor, wherein the memory is used to store program instructions; the at least one processor invokes the program instructions in the memory to cause the chip to execute the method in the first aspect or any possible implementation of the first aspect, and / or execute the method in the second aspect or any possible implementation of the second aspect.

[0107] Sixthly, this application provides a computing device that includes the apparatus of the third aspect or any possible implementation thereof, or includes at least one of the apparatus of the fourth aspect or any possible implementation thereof, or includes the chip system described in the fifth aspect.

[0108] In a seventh aspect, this application provides a vehicle that includes the means of the third aspect or any possible implementation thereof, or includes the means of the fourth aspect or any possible implementation thereof, or includes the chip system described in the fifth aspect, or includes the computing device described in the sixth aspect.

[0109] Eighthly, this application provides a computer-readable storage medium including computer instructions that, when executed by a processor, implement the method in the first aspect or any possible implementation of the first aspect, and / or implement the method in the second aspect or any possible implementation of the second aspect.

[0110] Ninthly, this application provides a computer program product that, when executed by a processor, implements the method described in the first aspect or any possible embodiment of the first aspect, or implements the method described in the second aspect or any possible embodiment of the second aspect.

[0111] For example, the computer program product is a software installation package. Attached Figure Description

[0112] Figure 1 is a schematic diagram of the architecture of an in-vehicle software system provided in an embodiment of this application;

[0113] Figure 2 is a schematic diagram of the architecture of a policy configuration system provided in an embodiment of this application;

[0114] Figure 3 is a flowchart of an access control model construction method provided in an embodiment of this application;

[0115] Figure 4 is a schematic diagram of a communication matrix between SOA services provided in an embodiment of this application;

[0116] Figure 5 is a schematic diagram of the construction of a second access model provided in an embodiment of this application;

[0117] Figure 6 is a schematic diagram of a meta-model of an access control model provided in an embodiment of this application;

[0118] Figure 7 is a flowchart of an access control policy generation method provided in an embodiment of this application;

[0119] Figure 8A is a schematic diagram of a graphical user interface provided in an embodiment of this application;

[0120] Figure 8B is a schematic diagram of another graphical user interface provided in an embodiment of this application;

[0121] Figure 9 is a schematic diagram of a meta-model of intermediate representation of a strategy language provided in an embodiment of this application;

[0122] Figure 10 is a flowchart of a strategy data verification method provided in an embodiment of this application;

[0123] Figure 11 is a schematic diagram of strategy data verification provided in an embodiment of this application;

[0124] Figure 12 is a schematic diagram of another graphical user interface provided in an embodiment of this application;

[0125] Figure 13 is a schematic diagram of a strategy configuration device provided in an embodiment of this application;

[0126] Figure 14 is a schematic diagram of the structure of a chip system provided in an embodiment of this application. Detailed Implementation

[0127] It should be noted that the prefixes such as "first" and "second" used in this application are merely for distinguishing different descriptive objects and do not impose any limitations on the position, order, priority, quantity, or content of the described objects. For example, if the described object is a "field," then the ordinal numbers before "field" in "first field" and "second field" do not restrict the position or order of the "fields," nor do "first" and "second" restrict whether the "fields" they modify are in the same message, nor do they restrict the order of "first field" and "second field." Similarly, if the described object is a "level," then the ordinal numbers before "level" in "first level" and "second level" do not restrict the priority of the "levels." Furthermore, the number of described objects is not limited by the prefixes and can be one or more; for example, in "first device," the number of "devices" can be one or more. Furthermore, the objects modified by different prefixes can be the same or different. For example, if the object being described is "device," then "first device" and "second device" can be the same device, devices of the same type, or devices of different types. Similarly, if the object being described is "information," then "first information" and "second information" can be information with the same content or information with different content. In summary, the use of prefixes to distinguish the objects being described in the embodiments of this application does not constitute a limitation on the objects being described. The description of the objects being described is based on the claims or the context of the embodiments, and should not constitute an unnecessary limitation due to the use of such prefixes.

[0128] It should be noted that the descriptions used in the embodiments of this application, such as "at least one (or at least one) of a1, a2, ... and an", include the case where any one of a1, a2, ... and an exists alone, as well as the case where any combination of a1, a2, ... and an exists alone. Each case can exist independently. For example, the description "at least one of a, b and c" includes the cases of a alone, b alone, c alone, a combination of a and b, a combination of a and c, a combination of b and c, or a combination of a, b, and c.

[0129] To facilitate understanding, the relevant terms that may be involved in the embodiments of this application will be introduced below.

[0130] Service-oriented architecture (SOA) is a system architecture design approach for software-defined vehicles. SOA abstracts the capabilities of a system into multiple services and meets the diverse needs of the vehicle system based on the dependencies between these services.

[0131] Generally, SOA in vehicles adopts a layered development model with upper-layer applications, a middle-layer operating system, and lower-layer hardware, achieving decoupling of software and hardware. SOA modularizes different functional units of upper-layer applications (such as applications on the vehicle's ECU), breaking them down into different services and defining corresponding service interfaces. A service is a discoverable software entity. Services access each other through service interfaces and can dynamically discover and invoke other services.

[0132] Here, each service can contain one or more service-oriented interfaces, and each service-oriented interface has a unique type (e.g., the SOME / IP service-oriented interface for IP-based scalable service-oriented middleware is divided into RR Method, FF Method, Field_Setter, etc.). The design of service-oriented interfaces follows SOA middleware principles, and different interface protocols are selected according to different use cases.

[0133] For example, the services abstracted by SOA include basic services, extended services, and application services. Among them, basic services are related to the electronic and electrical hardware in the vehicle and are used to provide the most basic functions of the vehicle (such as providing and processing camera data); extended services can implement more complex functions (such as data fusion functions of different sensors), and extended services are implemented by calling multiple basic services; application services are generally user-perceptible functions and are related to the vehicle scenario, such as parking assistance functions, and application services are implemented through at least one extended service.

[0134] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0135] Referring to Figure 1, Figure 1 is a schematic diagram of the architecture of an in-vehicle software system provided in an embodiment of this application. As shown in Figure 1, the system includes a vehicle platform operating system (Platform OS), a data plane operating system (Data Plane OS), and a microcontroller unit operating system (MCU OS). Among them, the platform OS is deployed on the external communication plane, management plane, and kernel, while the data plane OS is deployed on the data plane and kernel.

[0136] The vehicle's platform OS is the foundational operating system running on the vehicle, and also its lowest-level operating system. It manages hardware resources, provides interfaces for upper-level operating systems and applications, and handles basic system services and hardware interactions. The vehicle's platform OS provides fundamental support for the upper-level data plane OS and electronic control unit OS.

[0137] Vehicle platform OSs include Automotive Open System Architecture (AUTOSAR), Android Automotive OS (AAOS), QNX, Linux, etc.

[0138] For example, as shown in Figure 1, the platform OS deploys remote interactive applications, map update applications, etc. on the external communication plane, cryptographic services, health management, operation management, identity management, network management, time management, identity and access management, etc. on the management plane, and hardware drivers, inter-process communication (IPC), network, etc. are deployed in the kernel.

[0139] The vehicle's data plane operating system (OS) is associated with autonomous driving operations. The data plane OS is responsible for processing sensor data (such as perception and vision data) and executing tasks of the autonomous driving system. The data plane OS helps the vehicle perceive its surroundings, supports driver assistance functions, and may communicate with vehicle internet services. Here, the autonomous driving system is not limited to fully autonomous driving systems, highly autonomous driving systems, conditional autonomous driving systems, or partial autonomous driving systems; those skilled in the art will understand that any non-fully manual driving system providing intelligent driving can be included under this concept.

[0140] For example, as shown in Figure 1, the data plane OS deploys components such as isolation gateway, regulation and control, and perception on the data plane, and deploys components such as core mandatory access control (CMAC), file, and IPC in the kernel.

[0141] The vehicle's MCU OS is associated with vehicle control-related functions. The MCU OS, also known as the electronic control operating system, is responsible for managing and controlling various subsystems of the vehicle (such as the steering control unit, braking system control unit, door control unit, etc.), handling control logic related to the vehicle's powertrain, safety systems, chassis systems, etc., ensuring that different control units can work together to provide safe, efficient, and reliable vehicle performance. The MCU OS is compatible with two automotive electronic software standards: OSEK / VDX and AUTOSAR.

[0142] Different operating systems have different types and may have different software architectures. In heterogeneous scenarios, different operating systems have different access control mechanisms. For example, at least the following access control mechanisms exist in Figure 1: application firewalls for network applications (e.g., the network processor NP firewall in Figure 1), service-oriented access control for SOA services (e.g., Identity Access Management (IAM) in Figure 1), kernel access control mechanisms for data plane OS (e.g., kernel mandatory access control (CMAC) in Figure 1), kernel access control mechanisms for platform OS (e.g., LSM / SELinux in Figure 1), firewall mechanisms for gateways (e.g., isolation gateways in Figure 1), and service-oriented access control for MCU OS (e.g., application programming interface (API) access control in Figure 1).

[0143] Figure 1 above is merely an exemplary architecture diagram, but it does not limit the number of network elements included in the in-vehicle software system shown in Figure 1. Although not shown in Figure 1, Figure 1 may include other functional entities besides those shown in Figure 1. Furthermore, the method provided in this application embodiment can be applied to the in-vehicle software system shown in Figure 1; of course, the method provided in this application embodiment can also be applied to other in-vehicle software systems, and this application embodiment does not limit this application.

[0144] Currently, for different access control mechanisms in automotive software systems, mainstream access control mechanisms rely on manually written access control policies. Access control mechanisms for atypical scenarios such as data plane OS and MCU OS are typically developed by the software providers in the relevant fields, but these also involve manually written access control policies. Because automotive software systems involve multiple operating systems, each with numerous components, and require highly skilled personnel to configure access control policies, writing access control policies is complex and inefficient.

[0145] To address the aforementioned issues, this application proposes an access control policy configuration method that can improve the configuration efficiency of access control policies in vehicle software systems.

[0146] This application provides a policy configuration system capable of constructing an access control model that generates corresponding access control policies based on user configuration information. The system explicitly defines that the construction of the access control model is based on the interfaces of the vehicle's functional components and the types of those interfaces, which improves the efficiency of access control policy configuration. Furthermore, the policy configuration system defines the access control objectives for the entire vehicle system, constructs a policy verification model based on these objectives, and performs reverse verification on the policy data generated by the access control model using this verification model. This not only verifies the correctness of the policy data but also improves the efficiency of policy verification.

[0147] In addition, the policy configuration system of this application embodiment also provides a graphical user interface (GUI). The above-mentioned user configuration information is entered by the user on the GUI. The GUI can also present the policy verification model's verification status of the policy data to the user, so that the user can obtain feedback in a timely manner.

[0148] The composition of the above-mentioned strategy configuration system will be described below. Referring to Figure 2, which is a schematic diagram of the architecture of a strategy configuration system provided in an embodiment of this application, the strategy configuration system includes a model building device 210 and a strategy generation device 220.

[0149] The model building device 210 or policy generation device 220 is, for example, a cluster of computing devices, a computing device, or a component within a computing device, such as a chip or integrated circuit. The computing device may, for example, be equipped with an in-vehicle software development platform. The computing device may include a bare metal server (BMS), a virtual machine, a container, or an edge computing device.

[0150] BMS refers to a general-purpose physical server, such as an ARM server or an x86 server.

[0151] A virtual machine (VM) is a complete computer system simulated by software, possessing full hardware system functionality and running in a completely isolated environment. Any task that can be performed on a physical computer can also be performed in a VM. When creating a VM on a computing device, a portion of the physical machine's hard drive and memory capacity is used as the VM's hard drive and memory capacity. Each VM has its own independent Basic Input / Output System (BIOS), hard drive, and operating system, and can be operated just like a physical machine.

[0152] A container is a type of virtualization software that combines an application and all its dependencies into a single software package. This package is not limited by the underlying host operating system, eliminating the need to build complex environments and simplifying the application development and deployment process.

[0153] Edge computing devices refer to devices that are closer to the end device and have the characteristics of low latency and high bandwidth, such as edge servers.

[0154] A computing device cluster may include multiple of the aforementioned computing devices, such as a data center, without being specifically limited here.

[0155] The model building apparatus 210 is used to build an access control model and store the access control model. The process of the model building apparatus 210 building the access control model is described in the following embodiment of the access control model building method, and will not be repeated here.

[0156] In some possible embodiments, the model building apparatus 210 is also used to build a policy verification model and a storage policy verification model, the policy verification model being used to verify the policy data generated by the access control model.

[0157] In one implementation, after constructing the access control model, the model construction device 210 sends the access control model to the policy generation device 220, or the access control model constructed by the model construction device 210 is transferred to the policy generation device 220 via a removable storage medium such as a portable hard drive.

[0158] The policy generation device 220 is used to obtain user configuration information and to call the access control model in the model building device 210 to generate corresponding access control policies based on the user configuration information. In some possible embodiments, the policy generation device 220 locally stores the access control model, and can directly call the access control model locally when it needs to generate an access control policy.

[0159] For example, the model building device 210 and the strategy generation device 220 can be deployed separately on different devices. In some possible embodiments, the model building device 210 and the strategy generation device 220 can also be deployed separately on the same device, without specific limitation.

[0160] Figure 2 is just an example of the composition of a strategy configuration system. It does not limit the strategy configuration system to necessarily consisting of a model building device 210 and a strategy generation device 220. For example, the model building device 210 and the strategy generation device 220 can also be integrated into a single device.

[0161] The generation of access control policies in this embodiment depends on the access control model. The construction of the access control model is described below with reference to Figure 3. Referring to Figure 3, Figure 3 is a flowchart of an access control model construction method provided in this embodiment. This method is applied to the model construction device 210 in Figure 2 above or other devices containing the model construction device 210.

[0162] The method shown in the embodiment of Figure 3 includes, but is not limited to, the following steps S301-S302.

[0163] S301: Obtain information about multiple functional components of the vehicle.

[0164] Each functional component is used to implement a specific business function of the in-vehicle software. In other words, the multiple functional components of a vehicle are obtained by dividing the in-vehicle software based on business functions. It can be understood that the functional components of a vehicle are a logical grouping; they do not represent actual software components or deployment units. In the actual software development process, the functional components of the vehicle will be mapped to specific software components or component units.

[0165] For example, the functions of different functional components are orthogonal. That is, the functions of different functional components are independent and unrelated to each other, and there is no dependency between the functional components. Modifying one functional component will not affect the functions of other functional components. This is beneficial to improving the maintainability, scalability, and reusability of the system.

[0166] As an example, the vehicle's multiple functional components include several of the following: execution management components, network management components, configuration management components, safety management components, diagnostic management components, communication management components, log management components, and time management components. In some possible embodiments, the in-vehicle software system includes, in addition to the platform OS, at least one of a data plane OS and an MCU OS. In this case, the vehicle's functional components also include an autonomous driving control component, an autonomous driving perception component, an autonomous driving fusion component, a vehicle steering component, a vehicle braking component, and a door opening component.

[0167] The execution management component is responsible for the orderly startup and shutdown of applications and supports the management of the lifecycle of software components, including process definition, configuration, instantiation, startup and shutdown.

[0168] The communication management component is used to implement service-oriented communication between applications. It supports a variety of communication protocols, such as scalable service-oriented middleware over IP (SOME / IP), data distribution service (DDS), and inter-process communication (IPC).

[0169] The network management component is responsible for coordinating the normal operation of the underlying network (such as VLANs, physical channels, etc.) in the internal state machine and the switching between bus sleep modes, with the aim of saving vehicle power while meeting the communication needs of the electronic control unit (ECU).

[0170] The configuration management component is responsible for managing system configurations, including the description and distribution of applications, ECUs, communication configurations, etc.

[0171] Security management components are used to provide encryption capabilities for applications and mechanisms for protecting information exchange inside and outside the vehicle, such as authentication and encryption.

[0172] The diagnostic management component is responsible for implementing ISO-based diagnostic services.

[0173] The log management component is responsible for logging and tracking in order to monitor and analyze the operational status of the in-vehicle software system.

[0174] The time management component is used to achieve time synchronization between different applications and / or electronic control units (ECUs), providing functions such as timers and clock management.

[0175] In one implementation, obtaining information about multiple functional components of a vehicle includes: obtaining information about multiple functional components of the vehicle from local memory. The information for each functional component includes an identifier for the functional component, an identifier for the functional component's interface, and the type of the functional component's interface.

[0176] For example, the functional component includes at least one of the following types of interfaces: service interface, system interface, and network interface. Here, the interface of the functional component belongs to the category of software interface.

[0177] Service-oriented interfaces are the interfaces through which SOA services connect to the outside world. An interface can be understood as a function name that can be called by other modules or a wrapped application programming interface (API). Service-oriented interfaces themselves are unrelated to the underlying communication technology.

[0178] In SOA, there are two roles: ServiceProvider and ServiceConsumer (or service consumer). The service provider is the party that implements the service functions (including control algorithms, functional logic, etc.), and the service consumer is the party that uses the service interface to call the service.

[0179] System interfaces include, for example, API interfaces and function interfaces provided by the vehicle's operating system.

[0180] Network interfaces typically implement network communication through programming interfaces or libraries. Examples of network interfaces include RESTful interfaces and domain names. Examples of network interfaces include socket interfaces, Hypertext Transfer Protocol (HTTP) interfaces, Remote Procedure Call (RPC) interfaces, and WebSocket interfaces.

[0181] For example, each functional component includes at least one interface, and each interface corresponds to one interface type, which also means that each functional component includes at least one type of interface. The number of interfaces of different functional components may be different or the same. The interface types of different functional components may be different or the same.

[0182] Furthermore, different functional components provide different services, and the service interfaces of different services are different.

[0183] For example, functional component 1 has two types of interfaces: service interface and system interface, while functional component 2 has three types of interfaces: service interface, system interface and network interface.

[0184] For example, the interfaces of functional component 1 include interface 1, interface 2, and interface 3. Interface 1 and interface 2 are system interfaces, and interface 3 is a service interface. Here, the interfaces of functional component 1 are just an example and do not limit functional component 1 to only having service interfaces and system interfaces. They should not limit the number of interfaces of functional component 1, nor should they limit the number of interfaces of each type in functional component 1.

[0185] For example, a functional component has a service-oriented interface, meaning that the functional component can provide services (i.e., SOA services). Each service corresponds to at least one service-oriented interface of the functional component.

[0186] For example, suppose that the interface of functional component A includes interface a1 and interface a2, where interface a1 and interface a2 are service interfaces. Functional component A provides service 1, and service 1 corresponds to interface a1 and interface a2. This means that other services besides service 1 can access service 1 provided by functional component A through interface a1 or interface a2 of functional component A.

[0187] S302: Construct an access control model based on information from multiple functional components of the vehicle.

[0188] The access control model describes the access permissions of the interfaces of multiple functional components of the vehicle to at least one of the following: service resources, network resources, and system resources. The access control model can be used to generate the vehicle's access control policy. The process of generating the access control policy is described in the relevant description of the embodiment shown in Figure 7 below, and will not be repeated here.

[0189] In this embodiment, the access control model is constructed from three levels (or dimensions) based on the different types of interfaces of functional components: SOA service-oriented, system-oriented, and network-oriented. That is, the access control model includes an access control model for SOA services (denoted as the first access model), an access control model for system resources (denoted as the second access model), and an access control model for network resources (denoted as the third access model).

[0190] The construction of the first access model and the second access model will be introduced below.

[0191] First-access model:

[0192] In one implementation, the vehicle's multiple functional components include a first group of functional components, each of which has a service interface. The access control model includes a first access model, which is constructed based on information about the vehicle's multiple functional components. This includes: constructing the first access model based on a list of service interfaces of the first group of functional components. The first access model describes the service provider and service consumer corresponding to each service interface in the list, the service resources associated with the access when each service interface is accessed, the system resources associated with the access, and the network resources associated with the access. Each functional component in the first group of functional components acts as the aforementioned service provider and / or service consumer.

[0193] Service resources include, for example, services and service-oriented interfaces. For instance, in practical applications, it's possible that a certain service-oriented interface in the list of service-oriented interfaces of the first group of functional components may not have a corresponding service consumer. For example, if the first group of functional components includes functional component 1, and the service-oriented interface of functional component 1 has no corresponding service consumer, it means that no service consumer accesses the service provided by functional component 1 through its service-oriented interface.

[0194] The system resources associated with the aforementioned access are understood as the system resources required to implement the access, or the system resources involved when the access occurs. These system resources include, for example, memory information (e.g., shared memory), process scheduling, file systems, pipes, signals, sockets, message queues, controller area network (CAN) bus resources (e.g., CAN message identifiers, data fields, etc.), FlexRay resources (e.g., frame definitions, channel configurations, etc.), local interconnect network (LIN) bus resources (e.g., frame definitions, communication rates, etc.), wireless communication resources (e.g., at least one of the configurations and parameters required for wireless communication technologies such as Wi-Fi, Bluetooth, and LTE), and global positioning system (GPS) resources (e.g., hardware and related configurations for receiving GPS signals, etc.).

[0195] The network resources associated with the aforementioned access are understood as the network resources required to realize the access, or the network resources involved when the access occurs. These network resources include, for example, at least one of the following: IP address, subnet mask, gateway, MAC address, routing table, Domain Name System (DNS) configuration information, Dynamic Host Configuration Protocol (DHCP) configuration information, Virtual Private Network (VPN) configuration information, Quality of Service (QoS) information, network protocol information, and network security protocol information.

[0196] Furthermore, based on the service interface list of the first set of functional components, a first access model is constructed, including:

[0197] Define an SOA service communication matrix, which is used to describe the access relationships between services and between services and service-oriented interfaces;

[0198] Define the service provider for the service;

[0199] Define the service consumer of the service;

[0200] Define the system resources required for each access relationship in the SOA service communication matrix; and

[0201] Define the network resources required for each access relationship in the SOA service communication matrix;

[0202] The aforementioned services are provided by each functional component in the first group of functional components.

[0203] In other words, the SOA service communication matrix, the service provider, the service consumer, the system resources required for each access relationship in the SOA service communication matrix, and the network resources required for each access relationship are used as model parameters for constructing the first access model.

[0204] Here, the service provider and service consumer are at least one of the following: a process in a Linux-like operating system, a network node, and a task in a real-time operating system (RTOS).

[0205] Functional components with service-oriented interfaces can act as both service providers and service consumers. For the system resources required for each access relationship, please refer to the aforementioned description of "System Resources Associated with Access," and for the network resources required for each access relationship, please refer to the aforementioned description of "Network Resources Associated with Access." These details will not be repeated here.

[0206] As an example, the SOA service communication matrix is ​​defined in the form shown in Figure 4. As can be seen from Figure 4, the SOA service communication matrix includes a subject, an object, and the access relationships between the subject and the object. The subject refers to the object initiating the access (or the initiator of the access), and the object refers to the object being accessed. In this embodiment, the subject is defined as a service (i.e., an SOA service), and the object is a service or a service-oriented interface. In Figure 4, a "√" indicates that access is allowed. Taking service A in Figure 4 as an example, it can be seen that service A can access service C and service-oriented interface α. Figure 4 is an example of an SOA service communication matrix, but it does not limit the SOA service communication matrix to the form shown in Figure 4. In some possible embodiments, "√" can also be represented by a value such as "1".

[0207] Within a vehicle, middleware is a software framework situated between the underlying system and upper-level applications. It connects upper-level applications with the underlying hardware and software, enabling various autonomous driving applications to flexibly adapt to different sensors, chips, vehicle platforms, and other hardware. Different operating systems may use different middleware. Even within the same operating system, different middleware may be used. The SOA service communication matrix described above, used to construct the first access model, can cover the access relationships corresponding to the communication links involved in various middleware within the vehicle.

[0208] Second access model:

[0209] In one implementation, the vehicle's multiple functional components include a second group of functional components. Each functional component in the second group has a system interface. The access control model includes a second access model, constructed based on information about the vehicle's multiple functional components. This includes: constructing the second access model based on a list of system interfaces of the second group of functional components. The second access model describes the system resources associated with the system interfaces of each functional component in the second group. The access permissions of the functional components' system interfaces to system resources can be determined through the second access model.

[0210] Furthermore, based on the system interface list of the second set of functional components, a second access model is constructed, including:

[0211] Define the system interfaces for the second set of functional components;

[0212] Define the system interfaces that the vehicle software needs to access in the system interfaces of the second set of functional components;

[0213] Define the component atomic policy for each functional component in the second group of functional components. The component atomic policy of a functional component includes the atomic policy corresponding to each system interface of that functional component. The atomic policy corresponding to each system interface is associated with the system interface's permissions to system resources.

[0214] For example, the atomic policy corresponding to an interface is associated with the goal that the interface aims to achieve. For instance, if interface 1 is used to open a file and read its directory, based on interface 1's permissions to system resources, the atomic policy corresponding to interface 1 includes policy entries such as allowing interface 1 to access files, allowing interface 1 to access the network interface card (NIC), and allowing interface 1 to access the peer's IP address. It can be seen that the atomic policy corresponding to a system interface is equivalent to a pre-set template. This template defines the system resources that the system interface is allowed to access. For example, the atomic policy corresponding to interface 1 defines the system resources that interface 1 is allowed to access as files, NICs, and peer IP addresses, but it does not know what those files, NICs, and peer IP addresses are allowed to access; that is, they have not yet been instantiated.

[0215] Referring to Figure 5, which is a schematic diagram of the construction of a second access model provided in an embodiment of this application. In Figure 5, the functional components with system interfaces include at least functional component 1 and functional component 2. The system interfaces of functional component 1 include interface 1, interface 2, and interface 3, and the system interfaces of functional component 2 include interface 4 and interface 5. The second access model is constructed based on the system interface list of each functional component, including: defining the system interfaces of the second group of functional components; defining the system interfaces that the vehicle software needs to access in the system interfaces of the functional components. As shown in Figure 5, for functional component 1, only interface 1 and interface 2 are system interfaces that the vehicle software needs to access; for functional component 2, interface 5 is the system interface that the vehicle software needs to access; and constructing the component atomic policy of the functional components based on the functional components with system interfaces. The component atomic policy of the functional component includes the atomic policy corresponding to each system interface of the functional component. In Figure 5, the elliptical box represents the atomic policy. Taking functional component 1 as an example, it can be seen that the component atomic policy of functional component 1 includes the atomic policy corresponding to interface 1, the atomic policy corresponding to interface 2, and the atomic policy corresponding to interface 3.

[0216] Figure 5 is an example of constructing a second access model, and should not limit the number of functional components with system interfaces, the interfaces contained in the functional components, or the number of interfaces.

[0217] Third-access model:

[0218] In in-vehicle software systems, besides SOA architecture, other architectures (such as monolithic applications, microservices, etc.) may also be used. Regarding in-vehicle networks, communication exists not only between SOA services but also between in-vehicle nodes that require point-to-point communication under non-SOA architectures. Examples include point-to-point communication between two processes within an operating system, between a microprocessor unit (MPU) and a microcontroller unit (MCU), or between an MPU and a connected sensor. Compared to SOA services using standard web service protocols, Simple Object Access Protocol (SOAP), or Representational State Transfer (RESTful), communication between in-vehicle nodes under non-SOA architectures is more flexible, such as direct API calls or message queues. Furthermore, regarding external networks, there may be communication between in-vehicle software (excluding user-installed applications) and external networks. In this case, a third access model can be constructed. The third access model serves as a supplement to the first and second access models mentioned above.

[0219] In one implementation, the third access model is constructed through the following operations:

[0220] Define a non-SOA in-vehicle communication matrix. This matrix describes the access relationships between target nodes and between target nodes and ports' IP addresses when using in-vehicle network communication in non-SOA scenarios.

[0221] Define an external network access list, which includes firewall rules and domain filtering rules for the external networks that the in-vehicle software needs to access.

[0222] For example, a non-SOA in-vehicle communication matrix corresponds to a point-to-point communication scenario under a non-SOA architecture within a vehicle. In a non-SOA scenario, the two target nodes communicating using the in-vehicle network are, for example, two processes within an operating system, the in-vehicle MPU and the in-vehicle MCU, or the in-vehicle MPU and the undermount sensors.

[0223] For example, the external network access list can be a whitelist. In this case, the firewall rule includes specifying at least one of the following: a specific IP address, port (e.g., Secure Shell SSH port, HTTP port, etc.), application (e.g., SELinux application, etc.), and protocol. Domain filtering rules include specifying at least one of the following: a list of allowed domain names, the protocol of the allowed domain names, and the port.

[0224] In some possible embodiments, firewall rules may also include at least one of source and destination address rules, port rules, protocol rules, etc. In some possible embodiments, domain name filtering rules may also include at least one of specifying that authenticated users are allowed to access specific domain names, indicating that domain names are allowed to use secure connections (such as Hypertext Transfer Security Protocol HTTPS), etc.

[0225] For example, the access control model constructed above is represented using the Unified Modeling Language (UML) to obtain the metamodel of the access control model. The metamodel of the access control model can be understood as a descriptive language for the access control model. Specifically, the metamodel defines the specifications for describing the access control model, mainly including the elements that construct the access control model, the relationships between elements, and various constraints.

[0226] Referring to Figure 6, which is a schematic diagram of a meta-model of an access control model provided in an embodiment of this application, each rectangle represents an element that constructs the access control model; an element can also be called a class. The connecting lines between rectangles represent the relationship between the two elements connected by the connecting lines.

[0227] The elements in the metamodel shown in Figure 6 include ServiceConsumer, ServiceProvider, SOA resources, Transport, SOME / IP (an IP-based scalable service-oriented middleware), DDS (Data Distribution Service), NetworkInformation, CommunicationMatrix, App, WebDomain, System Interface, and ComponentInterface.

[0228] As shown in Figure 6, the relationships between elements include realization relationships, dependency relationships, aggregation relationships, and composition relationships.

[0229] Implementation relationships, also known as interface relationships, indicate that one class implements an operation defined in another class or interface. An implementation relationship is represented by a dashed line with an open triangle arrowhead, where the implementing class points to the implemented interface or abstract class, and the implemented interface or abstract class does not depend on the concrete classes that implement it. Implementation relationships help in understanding system interfaces and enabling code reuse.

[0230] Dependency, also known as usage or reference, indicates that one element uses or depends on another element; that is, the implementation of one type requires the assistance of another class. A dependency is represented by a dashed arrowhead pointing to the element that is used or depends on it.

[0231] Both aggregation and composition relationships represent a connection between a whole and its parts. An aggregation relationship is represented by a solid line with an open diamond arrowhead, while a composition relationship is represented by a solid line with a full diamond arrowhead. In both cases, the arrowhead points from the part to the whole. The difference between aggregation and composition relationships lies in the fact that composition represents a strong connection between the whole and its parts; that is, composition emphasizes that the "part" does not exist if the "whole" does not exist. In contrast, aggregation represents a weak connection between the whole and its parts; aggregation emphasizes that the "part" can exist if the "whole" does not exist.

[0232] Taking the elements "<<Interface>>SOA Resource" and "CommunicationMatrix" in Figure 6 as examples, the connecting line between the two elements is a solid line with a hollow diamond arrowhead, indicating an aggregation relationship. The arrow points to the element "CommunicationMatrix," suggesting that multiple "<<Interface>>SOA Resources" aggregate to form "CommunicationMatrix." The relationships between other elements in Figure 6 can be found in the explanations of the relationships shown by the corresponding connecting lines, and will not be repeated here.

[0233] In Figure 6, the operations defined by the "<<interface>>SOA resource" are implemented by at least one of "ServiceConsumer" and "ServiceProvider". The "<<interface>>SOA resource" is aggregated into "CommunicationMatrix".

[0234] In Figure 6, both "ServiceConsumer" and "ServiceProvider" depend on "App". The line connecting "ServiceProvider" and "App" is labeled "provider", indicating that "ServiceProvider" references "App" as a "provider"; the line connecting "ServiceConsumer" and "App" is labeled "consumer", indicating that "ServiceConsumer" references "App" as a "consumer".

[0235] In Figure 6, "App" is composed of two parts: "WebDomain" and "<<Interface>> System Interface". The line connecting "WebDomain" and "App" is labeled "domainList", indicating that "WebDomain" provides "domainList" to "App". Similarly, the line connecting "<<Interface>> System Interface" and "App" is labeled "systemInterfaceList", indicating that "<<Interface>> System Interface" provides "systemInterfaceList" to "App". Furthermore, the operations defined by "<<Interface>> System Interface" are implemented by "ComponentInterface".

[0236] In Figure 6, for the "<<Interface>> Transport", one part is combined as "ServiceConsume" and the other part is combined as "ServiceProvider". In addition, the "<<Interface>> Transport" can be implemented by at least one of "SOME / IP" and "DDS", where "SOME / IP" and "DDS" are both communication transport protocols.

[0237] In Figure 6, "SOME / IP" and "NetworkInformation" are related; when "SOME / IP" does not exist, "NetworkInformation" also does not exist. The line connecting "SOME / IP" and "NetworkInformation" is labeled "deployment," indicating that "NetworkInformation" provides deployment information to "SOME / IP."

[0238] As shown in Figure 6, the metamodel includes an SOA-oriented metamodel, a system-oriented metamodel, and a network-oriented metamodel. Taking the system-oriented metamodel as an example, Figure 6 shows that the system-oriented metamodel includes the elements "<<Interface>> System Interface" and "Component Interface". The SOA-oriented metamodel corresponds to the first access model mentioned above, the system-oriented metamodel corresponds to the second access model mentioned above, and the network-oriented metamodel corresponds to the third access model mentioned above.

[0239] It is understood that Figure 6 is an example of the metamodel of the access control model described above. In some possible embodiments, the metamodel of the access control model may include more or less information than shown in Figure 6. For example, the transport layer protocols shown in Figure 6 may include other communication transport protocols in addition to the aforementioned "IP-based scalable service-oriented middleware SOME / IP" and "Data Distribution Service DDS," which are not specifically limited here. The example in Figure 6 should not be construed as limiting the drawing of the metamodel of the access control model.

[0240] In one implementation, after constructing the access control model described above, the access control model is used to obtain access control policies, which are used to implement access control of the vehicle software to service resources, network resources, and system resources. Referring to Figure 7, Figure 7 is a flowchart of an access control policy generation method provided in an embodiment of this application. The method shown in Figure 7 is applied to the policy generation device 220 in Figure 2 above, or other devices containing a policy generation device 220.

[0241] The method shown in the embodiment of Figure 7 includes, but is not limited to, the following steps S701-S702.

[0242] S701: Obtain user configuration information, which includes the attribute configuration information of the vehicle's functional components.

[0243] Here, the attribute configuration information differs for different functional components. The attribute configuration information for each functional component is used to configure the attributes that the functional component depends on in order to implement the corresponding business function.

[0244] For example, the attribute configuration information of the communication management component includes the identifier of the service provided by the communication management component, the identifier of the service that each service needs to access, the identifier of the service-oriented interface that each service needs to access, and the attribute information of the network associated with the access. The attribute information of the network associated with the access includes at least one of the following: the IP address of the service provided by the functional component, the port, the communication protocols supported by the service, and whether a secure communication protocol is used.

[0245] For example, the attribute configuration information of the execution management component includes at least one of the following: the storage location information of the executable file, the identity of the vehicle software during runtime (or the identity of the main body after the process corresponding to the vehicle software is launched), and the resource limit information of the vehicle software during runtime (such as the upper limit of CPU, memory and other load usage).

[0246] For example, the attribute configuration information of the configuration management component includes at least one of the following: key-value pairs that the vehicle software (or the process running the vehicle software) needs to access, and the identifier of the file accessed by the vehicle software.

[0247] For example, the attribute configuration information of the security management component includes at least one of the following: key information used by the vehicle software, certificate information used by the vehicle software, etc.

[0248] In some possible embodiments, the user configuration information may also include a list of system interfaces for functional components that the vehicle software needs to access.

[0249] In some possible embodiments, the user configuration information may further include at least one of external network access information and in-vehicle non-SOA access information. The external network access information indicates the access relationship between in-vehicle nodes and external nodes. An in-vehicle node may be, for example, an SOA service, an operating system process, an MPU, an MCU, a sensor, etc., while an external node may be, for example, a domain name, a specific IP address, a port (e.g., a Secure Shell SSH port, an HTTP port, etc.), an application (e.g., an SELinux application), and network traffic protocols. The external network access information may include, for example, at least one of firewall rules and domain name filtering rules.

[0250] In-vehicle non-SOA access information is used to indicate the access relationships between target nodes using in-vehicle network communication in non-SOA scenarios. Two target nodes using in-vehicle network communication in non-SOA scenarios can be, for example, two processes within an operating system, the vehicle's MPU and MCU, the vehicle's MPU and an undermount sensor, etc.

[0251] In one implementation, the user is instructed to configure attribute information, which includes attribute configuration items of the vehicle's functional components; obtaining user configuration information includes: receiving setting information input by the user and obtaining user configuration information based on the setting information.

[0252] As an example, the attribute information to be configured may also include at least one of the following:

[0253] Whether the system interfaces of the vehicle's functional components are configuration items declared for use by the vehicle software;

[0254] Configuration items for access relationships between target nodes using in-vehicle network communication in non-SOA scenarios; and

[0255] Configuration items for accessing external networks.

[0256] Users include professionals such as developers of access control models, security experts, and system architects.

[0257] For example, receiving user-inputted settings information includes receiving settings information input by the user via at least one of a touchscreen, button, keyboard, etc.

[0258] For example, the strategy generation device 220 integrates a display device or other device including the strategy generation device 220, which displays the attribute information to be configured to the user. That is, the attribute information to be configured is presented on the display interface of the display device. The display device is, for example, a liquid crystal display (LCD), an organic or inorganic light-emitting diode (OLED), an active matrix organic light-emitting diode (AMOLED), etc.

[0259] The following description, based on Figure 8A, illustrates how a user can obtain a list of system interfaces for functional components that the in-vehicle software requires access through touchscreen settings. Referring to Figure 8A, which is a schematic diagram of a graphical user interface provided in an embodiment of this application.

[0260] In Figure 8A, taking Application 1 as an example, the configuration interface for Application 1's system interface access declaration is shown. The upper left part of Figure 8A shows the list of vehicle functional components, which can be viewed using the drop-down arrow. When the user selects a functional component, the upper right part of Figure 8A displays the interface settings interface for that component. This interface settings interface includes checkboxes indicating the interface type for that functional component. If the interface type is set to "System Interface," all system interfaces for that functional component are displayed. Each system interface corresponds to a checkbox. If the user checks the checkbox for a system interface, it means that Application 1 declares that it needs to access that system interface. After configuring the access declaration for a functional component's system interface for Application 1, clicking the "Save" button generates a list of system interfaces that Application 1 declares it needs to access.

[0261] For example, in Figure 8A, the user enters the configuration interface for the system interface access declaration of application 1. The user selects "Functional Component 1" from the list of functional components, and correspondingly, the interface settings interface for functional component 1 is displayed on the right side of the interface. Specifically, setting the interface type of functional component 1 to "System Interface" displays all system interfaces of functional component 1, including interface 1 and interface 2. The user checks the checkboxes corresponding to interface 1 and interface 2, meaning that application 1 needs to access interface 1 and interface 2 of functional component 1. Subsequently, the user clicks the "Save" button, and obtains the list of system interfaces that application 1 declares it needs to access from functional component 1, including interface 1 and interface 2. Therefore, the correspondence "Functional Component 1 - System Interfaces Declared by Application 1 to Access (System Interface 1, System Interface 2)" is stored locally and displayed in the "Completed Declaration Information" display area of ​​the configuration interface. It can be understood that for application 1, functional components with system interfaces need to go through the above-described "Functional Component 1" setting process, and the user selects each functional component in the list of functional components in turn to make the corresponding settings. If a functional component does not have a system interface, then there is no need to perform the setup process described above for "Functional Component 1" on that functional component. Thus, a list of system interfaces of the functional components that Application 1 declares it needs to access can be obtained.

[0262] Here, Figure 8A is just an example of the configuration interface for the system interface access declaration. This application embodiment does not limit the configuration interface for the system interface access declaration to the form shown in Figure 8A.

[0263] In some possible embodiments, Figure 8A may display more or less information than currently shown. For example, the display area for "Completed Declaration Information" in Figure 8A may not be set, that is, it may not be presented to the user, and the "Completed Declaration Information" may be stored in the background. As another example, when the user selects a functional component, the option box for the interface type of the functional component may not be presented, but instead all the system interfaces of the functional component and the selection box corresponding to each system interface may be presented directly.

[0264] Referring to Figure 8B, which is a schematic diagram of another graphical user interface provided in an embodiment of this application, the graphical user interface shown in Figure 8B is used by the user to configure the access relationships between target nodes using in-vehicle network communication in non-SOA scenarios, as well as the access relationships between in-vehicle nodes and external nodes.

[0265] Figure 8B shows two navigation keys: "Non-SOA In-Vehicle Communication Matrix Configuration" and "External Network Access Whitelist Configuration." The interface corresponding to the "Non-SOA In-Vehicle Communication Matrix Configuration" key is used to configure the access relationships between target nodes using in-vehicle network communication in non-SOA scenarios. The interface corresponding to the "External Network Access Whitelist Configuration" key is used to configure the access relationships between in-vehicle nodes and external nodes. Taking the "Non-SOA In-Vehicle Communication Matrix Configuration" key as an example, when the user clicks it, the configuration interface for the in-vehicle communication matrix in non-SOA scenarios is displayed. This configuration interface has a table containing two fields: the identifier of the target node initiating the access and the identifier of the target node being accessed. The user can add the corresponding relationships between the identifiers of the target nodes initiating the access and the identifiers of the target nodes being accessed, one by one, in this table. After adding the corresponding information, clicking the "Save" key retrieves the aforementioned in-vehicle non-SOA access information.

[0266] Here, the configuration interface for the in-vehicle communication matrix in a non-SOA scenario shown in Figure 8B is merely an example. It is not limited to the form shown in Figure 8B; it could also be other display interfaces capable of obtaining in-vehicle non-SOA access information and / or external network access information. In some possible embodiments, Figure 8B may also display more or less information than currently shown.

[0267] For example, in Figure 8B, a display area can be set up for the configuration interface corresponding to the in-vehicle communication matrix in the non-SOA scenario shown in Figure 8B. This display area is used to present the correspondence between the currently configured "identifier of the target node initiating the access" and "identifier of the target node being accessed".

[0268] For example, in Figure 8B, the configuration interface for "Non-SOA In-vehicle Communication Matrix Configuration" and the configuration interface for "External Network Access Whitelist Configuration" are displayed on the same screen, eliminating the need to set up two separate navigation keys for "Non-SOA In-vehicle Communication Matrix Configuration" and "External Network Access Whitelist Configuration" to switch between the two interfaces.

[0269] For example, different navigation keys (or index keys) can be used to navigate to the interfaces shown in Figure 8A and Figure 8B, respectively. In some possible embodiments, the interfaces shown in Figure 8A and Figure 8B can be presented on the same display interface, in which case both the interfaces shown in Figure 8A and Figure 8B are part of that display interface.

[0270] S702: Obtain access control policies based on user configuration information and access control models.

[0271] The access control policy describes the access permissions of the interfaces of the vehicle's functional components to at least one of the service resources, network resources, and system resources.

[0272] In one implementation, the vehicle's functional components include a first functional component, the interface type of the first functional component includes a service-oriented interface, the access control model includes the aforementioned first access model, and an access control policy is obtained based on user configuration information and the access control model, including: inputting the attribute configuration information of the first functional component into the first access model to obtain the access control policy, the access control policy including the access policy for service resources associated with the target service, the access policy for system resources associated with the target service, and the access policy for network resources associated with the target service, wherein the aforementioned target service is a service provided by the first functional component (i.e., an SOA service).

[0273] The attribute configuration information of the first functional component includes the identifier of the service provided by the first functional component, the service that each service needs to access, the service-oriented interface that each service needs to access, and the attribute information of the network associated with the access. Here, the attribute information of the network associated with the access includes at least one of the following: the service's IP address, port, communication protocol, and whether a secure communication protocol is used.

[0274] In one implementation, the vehicle's functional components further include a second functional component. The interface type of the second functional component includes system interfaces. The user configuration information also includes a list of system interfaces that the in-vehicle software needs to access. The access control model also includes the aforementioned second access model. Based on the user configuration information and the access control model, an access control policy is obtained, including: inputting the attribute configuration information of the second functional component and the list of system interfaces that the in-vehicle software needs to access into the second access model to obtain the access control policy. This access control policy includes the in-vehicle software's access policy for system resources. The list of system interfaces that the in-vehicle software needs to access belongs to the system interfaces of the second functional component. The attribute configuration information of the second functional component is used to determine the system resources associated with each system interface of the second functional component.

[0275] The attribute configuration information of the second functional component includes the identifier of the system interface of the second functional component and the system resources associated with each system interface of the second functional component.

[0276] The attribute configuration information of the second functional component is used to instantiate the atomic policies corresponding to the system interfaces defined in the second access model. For example, in the second access model, an interface (e.g., interface 1) is defined. Assuming interface 1 implements opening files and reading file directories, the atomic policies corresponding to interface 1 include: allowing interface 1 to access files, allowing interface 1 to access network cards, and allowing interface 1 to access the IP address of the peer. When using the second access model, the attribute configuration information of the second functional component and the list of system interfaces that the vehicle software needs to access are input into the second access model. Assuming that the list of system interfaces that the vehicle software needs to access includes interface 1, the second access model obtains the relevant information of interface 1 from the attribute configuration information of the second functional component, and determines, based on the relevant information of interface 1, which specific file (i.e., file name), the file directory, and the path where the file is located, which specific network card and which specific IP address of the peer that interface 1 is accessing. It can be seen that the system resources associated with interface 1 can be specifically determined through the attribute information of the second functional component, thus realizing the instantiation of the atomic policies corresponding to interface 1. Thus, the second access model instantiates the atomic policy corresponding to each system interface in the system interface list based on the system interface list that the vehicle software needs to access and the attribute configuration information of the second functional components. The result obtained after the atomic policy corresponding to each system interface is instantiated as the access policy of the vehicle software to system resources.

[0277] In one implementation, the user configuration information further includes at least one of external network access information and in-vehicle non-SOA access information. The external network access information is used to indicate the access relationship between in-vehicle nodes and external nodes, and the in-vehicle non-SOA access information is used to indicate the access relationship between target nodes using in-vehicle network communication in non-SOA scenarios. The access control model further includes the aforementioned third access model. Based on the user configuration information and the access control model, an access control policy is obtained, including: inputting the external network access information and / or the in-vehicle non-SOA access information into the third access model to obtain the access control policy. The access control policy includes the access policy for network resources associated with the external network access information and / or the access policy for network resources associated with the in-vehicle non-SOA access information.

[0278] It is understood that inputting the aforementioned external network access information into the third access model can obtain the access strategy for network resources associated with the external network access information, and inputting the aforementioned in-vehicle non-SOA access information into the third access model can obtain the access strategy for network resources associated with the in-vehicle non-SOA access information.

[0279] For example, the access control model runs in an integrated development environment (IDE). The IDE uses the access control model to process the input user configuration information to generate the aforementioned access control policy. This access control policy is deployable and executable policy data. Furthermore, from the perspective of access scenarios or access control mechanisms, access control policies include policies for various access scenarios. As an example, access control policies include multiple policies such as Security-Enhanced Linux (SELinux) policies, kernel-mandated access control (CMAC) policies, middleware policies, network processor (NP) firewall policies, and intelligent vehicle control policies.

[0280] The method embodiment shown in Figure 7 enables automated generation of access control policies based on the access control model, avoiding the need for manually and discretely writing access control policies, thus improving the configuration efficiency of access control policies in the vehicle software system. Furthermore, it provides a user-friendly interface for users to configure attribute information of vehicle functional components, enhancing the user experience and reducing the configuration cost of access control policies.

[0281] In the above implementation method, the access control policy is directly generated using the embodiment shown in Figure 7.

[0282] In another implementation approach, to ensure the accuracy of the access control policies generated by the access control model, the generated access control policies can be verified. Access control policies have two main characteristics: First, in-vehicle software systems involve numerous access mechanisms, each defining its own unique configuration language syntax or configuration file format for representing access control policies based on its own access control functions. For example, some access mechanisms use structured markup syntax, such as XML or JSON, while others use a self-defined domain-specific language (DSL). The representation of different languages ​​or formats varies significantly. Second, each access mechanism has a large number of access control policies, resulting in a large number of access control policies that need to be verified. Using functional testing to verify each policy entry of the access control policy for each access mechanism is not only costly but also involves a long verification chain and significant time consumption.

[0283] Different access mechanisms involved in in-vehicle software systems may have different configuration language syntax or configuration file formats. Although the expression of different language syntaxes or formats varies greatly, their abstract meaning in access control semantics is the same or similar. This application proposes an intermediate representation (IR) for policy language to abstract and unify access control semantics. Before generating access control policies, the access control model is converted into IR policy data using the policy language IR and the aforementioned user configuration information. Verification of this IR policy data achieves the verification of the access control policy. Through the policy language IR, a unified abstract description of access control semantics under different access mechanisms can be achieved, making automated verification of IR policy data possible.

[0284] In one implementation, obtaining an access control policy based on user configuration information and an access control model includes: obtaining first IR policy data based on the user configuration information and the access control model; and generating an access control policy based on the first IR policy data if the first IR policy data passes verification. The first IR policy data is represented using a policy language (IR) and serves as an intermediate representation of the access control policy. The verification process for the first IR policy data is described in the embodiment shown in Figure 10 below and will not be repeated here.

[0285] For example, the metamodel of a policy language IR defines the specifications for describing a policy language IR, mainly including the elements involved in the policy language IR and the relationships between elements. The front end of the metamodel of a policy language IR can be a structured markup syntax, such as XML or JSON, or a user-defined DSL, without specific limitations here.

[0286] Referring to Figure 9, which is a schematic diagram of a meta-model of a policy language intermediate representation provided in an embodiment of this application, the meta-model shown in Figure 9 is obtained through UML. In Figure 9, each rectangle represents an element of the policy language IR, and the connecting lines between rectangles represent the relationship between the two elements connected by the connecting lines.

[0287] In Figure 9, when an element is represented by a rectangle with dividing lines, the element is a class in UML. The rectangle with dividing lines includes a first layer and a second layer. The first layer represents the class name of the element, and the second layer represents the attributes of the element.

[0288] The elements of the metamodel shown in Figure 9 include Policy, Rule, Subject, Object, Process, NetworkNode, SOA Service, File, Operation, FileOperation, SocketOperation, iptableActions, class, and PolicySet.

[0289] Taking the element "Subject" in Figure 9 as an example, based on the rectangle with dividing lines of "Subject", we can see that the class name is "Subject" and the attributes of "Subject" include type and attribute.

[0290] In Figure 9, the relationships between elements include dependency (represented by a dashed line with an arrowhead), inheritance (represented by a solid line with an open triangle arrowhead), composition (represented by a solid line with a solid diamond arrowhead), and aggregation (represented by a solid line with an open diamond arrowhead).

[0291] The inheritance relationship described above, also known as generalization, describes the relationship between a parent class and a child class, where the child class inherits the attributes and methods of the parent class. In some possible implementations, the parent class is also called the base class, and the child class is also called the derived class. In the representation of inheritance, the arrow points from the child class to the parent class. Through inheritance, a child class is allowed to possess all members of the parent class, including fields, methods, and attributes. This reduces code duplication and improves code reusability and maintainability.

[0292] Both composition and aggregation relationships represent a whole-part relationship. Aggregation emphasizes that the "whole" contains the "part," but the "part" can exist independently of the "whole." Composition emphasizes that the "whole" contains the "part," but the "part" cannot exist independently of the "whole." The descriptions of composition, aggregation, and dependency relationships can be found in the corresponding content of the aforementioned embodiment in Figure 6, and will not be repeated here.

[0293] Taking the elements "Policy" and "PolicySet" in Figure 9 as examples, the connecting line between them is a solid line with a filled diamond arrowhead. Therefore, the relationship between "Policy" and "PolicySet" is an aggregation relationship, meaning multiple "Policies" are aggregated into one "PolicySet". The relationships between other elements in Figure 9 can be found in the explanations of the relationships shown by the corresponding connecting lines, and will not be repeated here.

[0294] It is understood that Figure 9 is merely an example of the metamodel of the policy language IR described above. In some possible embodiments, the metamodel of the policy language IR may include more or less information than shown in Figure 9. The example in Figure 9 should not be construed as limiting the drawing of the metamodel of the policy language IR.

[0295] In other words, the policy language IR provides a general policy language, enabling the access control model to support more scenarios where heterogeneous software systems coexist, and also improving the scalability of the access control model.

[0296] Furthermore, addressing the challenges of complex configuration and error detection caused by the large number of access control policies involved in in-vehicle software systems, this application defines an access control objective for the entire system. This objective is used to verify whether the IR policy data corresponding to the aforementioned access control model passes validation. To improve the efficiency and accuracy of policy data validation, the logical expression direction of the access control objective is defined to be opposite to that of the access control policy. The validation process is as follows: a policy validation model is constructed based on the access control objective; the policy validation model is then converted into IR policy data using the policy language IR; and this IR policy data is used to perform reverse validation on the IR policy data corresponding to the access control model. This ensures that the policy data converges correctly and quickly, improving both the accuracy and efficiency of policy validation.

[0297] For example, access control objectives are set by users. Users may be security experts, security architects, system architects, or other professionals with security knowledge. As an example, access control objectives can be set from the perspective of the overall system security level. The system's resources are divided into subjective resources and objective resources. Subjective resources include, for example, data plane applications, management plane applications, external communication plane applications, OTA applications, and map applications. Objective resources include, for example, high-functionality security services, financial services, and system-sensitive resources.

[0298] Access control objectives may include at least one of the following: three-sided isolation (i.e., external communication, management, and data isolation) or vehicle control domain isolation.

[0299] Taking three-sided isolation as an example to define access control objectives, please refer to Table 1 below for the definition of access control objectives and the construction of the policy verification model. As shown in Table 1, access control objectives include allowing only the external communication plane to access the external network and allowing only the data plane to access data plane resources. Since the logical expression direction of access control objectives is reversed, "allowing only the external communication plane to access external network resources" is equivalent to "not allowing the management plane and data plane to access external network resources", and "allowing only the data plane to access data plane resources" is equivalent to "not allowing the management plane and external communication plane to access data plane resources".

[0300] Furthermore, modeling is performed based on the access control objective to define the following associated content: management plane subjects, data plane subjects, external communication plane subjects, external network resources, and data plane resources. The content associated with each subject and each resource is further defined. Taking the management plane subject as an example, as shown in Table 1, the defined management plane subjects include file management applications, configuration management applications, network management applications, and time management applications. For other subjects or resources associated with this access control objective besides the management plane subject, please refer to the descriptions in Table 1; they will not be repeated here.

[0301] Furthermore, based on the modeling results of the access control objective, the access control objective is represented in reverse, thus the access control objective is represented as: Not allowed:

[0302] [

[0303] {Management Surface Main Body, External Network Resources}

[0304] {Data plane main body, external network resources}

[0305] {Management-level main body, data-level resources}

[0306] {External communication plane main body, data plane resources}

[0307] ].

[0308] Table 1

[0309] Table 1 illustrates an access control objective defined using three-sided isolation as an example. Table 1 serves only as an example of the reverse description, modeling, and representation of the modeling results for this access control objective, and should not be construed as limiting the setting or representation of the access control objective. Furthermore, in the representation of the modeling results, the contents of the aforementioned defined subjects (e.g., management plane subjects, data plane subjects, external communication plane subjects) and resources (e.g., external network resources, data plane resources) can be substituted into the representation. For example, {data plane subject, external network resource} should be specifically represented as {(perception application, converged application, regulatory application), (external IP address, external domain name)}. In some possible embodiments, {(perception application, converged application, regulatory application), (external IP address, external domain name)} can also be split and represented as: {perception application, external IP address}, {perception application, external domain name}, {converged application, external IP address}, {converged application, external domain name}, {regulatory application, external IP address}, {regulatory application, external domain name}.

[0310] The following describes the process of validating policy data generated by the access control model, using the Policy Language (IR) and access control objectives described above. Referring to Figure 10, which is a flowchart of a policy data validation method provided in an embodiment of this application, this method is applied to the model building device 210, policy generation device 220 (when equipped with the Policy Language (IR) function), or other devices capable of invoking the Policy Language (IR) function to perform policy verification, as shown in Figure 2.

[0311] The method shown in Figure 10 includes, but is not limited to, the following steps S1001-S1005.

[0312] S1001: Generate the first IR policy data based on user configuration information and access control model.

[0313] The first IR strategy data is represented by the aforementioned strategy language IR.

[0314] Here, the first IR policy data is understood as an intermediate representation of the aforementioned access control policy.

[0315] The first IR policy data is a positively described resource permission, that is, it is expressed in the form of who is allowed to do a certain thing. In other words, the logical direction of the first IR policy data is positive. The first IR policy data can be understood as a kind of permission rule.

[0316] For details regarding user configuration information, access control models, etc., please refer to the descriptions in the aforementioned embodiments; they will not be repeated here.

[0317] S1002: Obtain the access control target.

[0318] For example, obtaining an access control target includes receiving an access control target input by a user via a touchscreen, keyboard, or button. That is, the access control target can be user-defined. Further, the access control target may be, for example, the access control target that the user selects from a plurality of system-preset or user-defined access control targets to be applied currently.

[0319] As an example, by showing users the settings for access control targets through a graphical user interface, users can configure access control targets themselves based on the security requirements of the in-vehicle software system. This improves the user experience, increases the efficiency of access control policy configuration, and reduces the configuration cost of policies.

[0320] In one implementation, the access control target is included in the aforementioned user configuration information.

[0321] In another implementation, the access control target is independent of the user configuration information. The access control target and the user configuration information may be carried by the same message or by different messages.

[0322] The logical expression of access control objectives is either reverse or negative, meaning it expresses the idea of ​​disallowing certain actions.

[0323] S1003: Based on the policy language (IR) and access control objectives, obtain the second IR policy data corresponding to the access control objectives.

[0324] In one implementation, obtaining second IR policy data corresponding to the access control objective based on the policy language IR and the access control objective includes: modeling based on the access control objective; and using the policy language IR to convert the result of the access control objective modeling into second IR policy data.

[0325] Since the logical expression of the access control objective is negative, the logical expression of the second IR policy data is also negative. "Negative" means expressing it in the form of disallowing certain actions. The second IR policy data can be understood as a denial rule.

[0326] For example, the logical representation direction of the second IR strategy data is negative, the logical representation direction of the first IR strategy data is positive, and the logical representation direction of the second IR strategy data is opposite to that of the first IR strategy data.

[0327] From the perspective of verification approach, the second IR strategy data and the first IR strategy data form a logical closed loop. The subsequent verification of the first IR strategy data using the second IR strategy data is a reverse verification, which is conducive to achieving reverse convergence of the strategy data.

[0328] S1004: Verify the first IR strategy data based on the second IR strategy data to obtain verification result information.

[0329] The verification result information includes the verification result of each IR strategy entry in the first IR strategy data.

[0330] For any IR policy entry in the first IR policy data, the verification result of the IR policy entry is classified into three types, such as correct (or passed), incorrect (or failed), and alarm. In some possible embodiments, the verification result of the IR policy entry may also be classified into two types: correct and incorrect, which is not specifically limited here.

[0331] For example, verifying the first IR strategy data based on the second IR strategy data includes: comparing whether the logic of each IR strategy entry in the first IR strategy data is consistent with that of each IR strategy entry in the second IR strategy data. Taking the verification of the first IR strategy entry in the first IR strategy data as an example, the verification result of the first IR strategy entry is mainly divided into three cases, please refer to cases 1-3 below.

[0332] Case 1: The verification result of the first IR strategy entry is incorrect.

[0333] If there is a logical inconsistency between the first IR policy entry in the first IR policy data and the second IR policy entry in the second IR policy data, it means that the first IR policy entry does not meet the access control objective, and the verification result of the first IR policy entry is incorrect.

[0334] To illustrate the determination of an error in the verification result of the first IR policy entry, consider the following specific example: If the first IR policy entry allows A to access B, while the second IR policy entry disallows A to access B, then there is a logical inconsistency between the first and second IR policy entries, and the verification result of the first IR policy entry is incorrect.

[0335] Scenario 2: The verification result of the first IR strategy entry is an alarm.

[0336] Furthermore, if there is a logical inconsistency between the first IR policy entry in the first IR policy data and the second IR policy entry in the second IR policy data, but the second IR policy entry is not a mandatory provision (or a non-mandatory requirement), it means that the first IR policy entry does not meet the access control objective, but the verification result of the first IR policy entry is an alarm.

[0337] In this case, for IR policy entries in the first IR policy data whose verification result is an alarm, the verification result information also includes the corresponding repair suggestions for the IR policy entries whose verification result is an alarm.

[0338] To illustrate the determination of an alarm result for the first IR policy entry, consider the following specific example: If the first IR policy entry allows A to access B, while the second IR policy entry disallows A to access B, but the configuration information of the second IR policy entry shows that it is not mandatory, then the verification result of the first IR policy entry will be an alarm.

[0339] Case 3: The verification result of the first IR strategy entry is correct.

[0340] If no logical inconsistencies are found when comparing the first IR policy entry with each IR policy entry in the second IR policy data, it means that the first IR policy entry conforms to the access control objective, and the verification result of the first IR policy entry is correct.

[0341] To illustrate the determination of the correctness of the verification result for the first IR policy entry, consider the following example: The first IR policy entry allows A to access B. Assume the second IR policy data includes IR policy entry 1, IR policy entry 2, and IR policy entry 3. IR policy entry 1 disallows A from accessing C, IR policy entry 2 disallows C from accessing A, and IR policy entry 3 disallows B from accessing C. In this case, no logical inconsistencies are found between the first IR policy entry and each IR policy in the second IR policy data. Therefore, the verification result of the first IR policy entry is determined to be correct.

[0342] In some possible embodiments, each type of verification result corresponds to an evaluation score, and the verification result information also includes the evaluation score corresponding to the verification result of each IR strategy entry in the first IR strategy data and / or the comprehensive evaluation score corresponding to the first IR strategy data.

[0343] The comprehensive evaluation score corresponding to the first IR strategy data is obtained by statistically analyzing the evaluation scores corresponding to the verification results of each IR strategy item in the first IR strategy data. Here, the statistical method is, for example, to calculate the average, to sum, or to calculate the weighted sum.

[0344] As an example, the better the verification result of an IR policy entry, the higher the evaluation score corresponding to that IR policy entry's verification result. For example, the evaluation score corresponding to the verification result "correct" is higher than the evaluation score corresponding to the verification result "alarm," and the evaluation score corresponding to the verification result "alarm" is higher than the evaluation score corresponding to the verification result "error."

[0345] In some possible embodiments, the verification result information may also include the verification result of the first IR strategy data.

[0346] As an example, when the overall evaluation score corresponding to the first IR strategy data is greater than or equal to the target score, the verification result of the first strategy data indicates that the first IR strategy data has passed the verification; when the overall evaluation score corresponding to the first IR strategy data is less than the target score, the verification result of the first strategy data indicates that the first IR strategy data has failed the verification. The target score is a user-defined value.

[0347] As another example, when the verification result of each IR policy entry in the first IR policy data is not an error, the verification result of the first IR policy data indicates that the first IR policy data has passed the verification; when the verification result of one IR policy entry in the first IR policy data is an error, the verification result of the first IR policy data indicates that the first IR policy data has failed the verification.

[0348] Here, a verification result for the first IR policy data indicates that the first IR policy data passes verification, meaning that the first IR policy data conforms to the access control objective, and therefore the access control policy corresponding to the first IR policy data also conforms to the access control objective. Conversely, a verification result for the first IR policy data indicates that the first IR policy data fails verification, meaning that the first IR policy data does not conform to the access control objective, and therefore the access control policy corresponding to the first IR policy data also does not conform to the access control objective.

[0349] In addition, if the verification result of the first IR policy data indicates that the first IR policy data has passed the verification, it means that the access control policy generated based on the first IR policy data can be directly deployed and used.

[0350] For example, the second IR strategy data and the first IR strategy data are compiled and integrated in an IDE to achieve automatic verification of the first IR strategy data and output the verification result information.

[0351] Optionally, in some possible embodiments, the following S1005 may also be performed.

[0352] S1005: If the verification result information indicates that the first IR strategy data has failed the verification, prompt the user to check the user configuration information.

[0353] The verification result indicates that the first IR policy data failed verification, meaning that a certain IR policy entry in the first IR policy data has an incorrect verification result. This may be due to input errors or omissions by the user when entering settings information on the display interface, leading to errors in the user configuration information. In this case, the user can be prompted to check their configuration information. This allows the user to promptly check the accuracy of the system interfaces accessed by the configured in-vehicle software, the access relationships between in-vehicle network communication nodes in non-SOA scenarios, the whitelist for external network access, and the attribute configuration information of functional components.

[0354] For example, prompting the user to check user configuration information can be done through screen display, announcement, ringing, or other means.

[0355] In some possible embodiments, after the user adjusts the user configuration information based on the verification result information, the adjusted user configuration information is re-entered into the access control model, and the method shown in Figure 10 above is re-executed to verify the newly generated first IR policy data based on the access control objective until the newly generated first IR policy data meets the access control objective.

[0356] To more clearly illustrate the policy data verification process, please refer to Figure 11, which is a schematic diagram of policy data verification provided in an embodiment of the application. As shown in Figure 11, user configuration information is input into the access control model. The Policy Language (IR) converts the access control model containing the user configuration information into first IR policy data. Based on the IR and the input access control target, second IR policy data corresponding to the access control target is obtained. The first IR policy data is verified based on the second IR policy data to obtain verification result information. Finally, the user configuration information is adjusted based on the verification result information.

[0357] In some possible embodiments, at least one of the following pieces of information from the verification result information may also be presented to the user via a graphical user interface (GUI):

[0358] (1) Verification results of the first IR strategy data;

[0359] (2) Verification results of each IR strategy entry in the first IR strategy data;

[0360] (3) The evaluation score corresponding to the verification result of each IR strategy entry in the first IR strategy data;

[0361] (4) The comprehensive evaluation score corresponding to the first IR strategy data; and

[0362] (5) Repair suggestions for IR strategy entries that failed verification in the first IR strategy data.

[0363] The verification results of the first IR strategy data and the corresponding comprehensive score provide an intuitive evaluation from the perspective of the overall strategy. Users can know in a timely manner whether the verification of the first IR strategy data has passed and the overall evaluation score of the first IR strategy data.

[0364] Furthermore, by presenting the verification results and corresponding evaluation scores of each IR policy entry in the first IR policy data to the user, the user can specifically view the IR policy entries in the first IR policy data that failed verification or triggered alarms. This allows the user to make more targeted adjustments to the user configuration information, which helps to quickly improve the verification pass rate and accuracy of the policy.

[0365] By presenting users with repair suggestions for IR policy entries that failed verification, a reference is provided for the user's adjustment methods. This helps users quickly improve the policy verification process and is conducive to improving the policy verification pass rate and accuracy.

[0366] In this embodiment, when the apparatus (such as the strategy generation apparatus 220, model building apparatus 210, etc.) integrates a display device, the aforementioned verification result information is presented through the display interface (e.g., graphical user interface) of the display device. The display device may be, for example, a liquid crystal display (LCD), an organic or inorganic light-emitting diode (OLED), or an active matrix organic light-emitting diode (AMOLED).

[0367] Referring to Figure 12, which is a schematic diagram of a graphical user interface provided in an embodiment of this application, the graphical user interface shown in Figure 12 presents the aforementioned verification result information. The graphical user interface shown in Figure 12 is mainly divided into upper and lower parts. The upper part shows the access control objective and, from an overall perspective, the comprehensive evaluation score and the overall verification result. The lower part mainly shows the verification result of each policy item from a local perspective.

[0368] As shown in Figure 12, the lower part includes the policy master table display area and the policy entry verification result display area. The policy master table display area shows the first IR policy data obtained based on the access control model, user configuration information, and the aforementioned policy language IR model. The first IR policy data includes multiple IR policy entries. The policy entry verification result display area shows the verification result corresponding to each IR policy entry and the corresponding evaluation score. The verification result for each IR policy entry is determined based on the access control objective.

[0369] In Figure 12, the comprehensive evaluation score (i.e., the comprehensive evaluation score corresponding to the first IR strategy data mentioned above) is obtained by statistically analyzing the evaluation scores corresponding to the verification results of each IR strategy item in the strategy item verification result display area. The overall verification result (i.e., the verification result of the first IR strategy data mentioned above) is determined based on the comprehensive evaluation score or the verification results of each IR strategy item in the strategy item verification result display area. Finally, the comprehensive evaluation score and the overall verification result are presented in the upper part of Figure 12.

[0370] As shown in Figure 12, the access control objective is "three-sided isolation". Based on this access control objective, each IR policy entry in the policy master table is validated. From a local perspective, taking the IR policy entry {Radarproces, SignalEvent} indicated by sequence number "1" as an example, the validation result of the IR policy entry {Radarproces, SignalEvent} is "correct" and the corresponding evaluation score is "100". From an overall perspective, the comprehensive evaluation score of the policy is "98", and the overall validation result is "passed", indicating that the access control policy corresponding to the policy master table can be directly deployed and used.

[0371] Figure 12 is merely an example of a graphical user interface for presenting verification result information. This application does not limit the display interface to the form shown in Figure 12; other display interfaces capable of presenting verification result information may also be used. In some possible embodiments, Figure 12 may display more or less information than currently shown. For example, when the verification result is "alarm," corresponding repair suggestions may also be displayed. These repair suggestions can be displayed in the form of a pop-up or by adding a column to the policy entry verification result display area in Figure 12 for filling in repair suggestions. Alternatively, the display interface shown in Figure 12 may not necessarily show "access control objectives."

[0372] The graphical user interface shown in Figure 12 can be set up separately from the graphical user interfaces shown in Figures 8A and 8B. In some possible embodiments, the graphical user interface shown in Figure 12 can also be presented on the same display interface as the graphical user interfaces shown in Figures 8A and 8B.

[0373] After verifying the policy data, the display interface shown in Figure 12 can intuitively provide users with the verification results of the policy data and the verification results of each policy entry in the policy data. This makes it easy for users to know the direction of policy entry adjustments and helps improve the efficiency of policy configuration.

[0374] The method embodiment shown in Figure 10 realizes the unified abstract representation of the access control model as IR policy data. Reverse verification of this IR policy data based on the access control objective enables reverse convergence of the policy data. Compared to the verification method based on functional testing of access control policies, this shortens the verification chain, improving not only the verification efficiency but also the accuracy of the policy.

[0375] Referring to Figure 13, which is a schematic diagram of a policy configuration device provided in an embodiment of this application, the policy configuration device 30 includes an acquisition unit 310 and a processing unit 312. This policy configuration device 30 can be implemented in hardware, software, or a combination of both.

[0376] In one implementation, the policy configuration device 30 is used to construct an access control model. In this case, the acquisition unit 310 is used to acquire information about multiple functional components of the vehicle, each functional component being used to implement a business function of the in-vehicle software, and the information of each functional component including the identifier of the functional component, the identifier of the interface of the functional component, and the type of the interface of the functional component; the processing unit 312 is used to construct an access control model based on the information of these multiple functional components, the access control model being used to describe the access permissions of the interfaces of these multiple functional components to at least one of service resources, network resources, and system resources, and the access control model being used to obtain the vehicle's access control policy.

[0377] The strategy configuration device 30 can be used to implement the method described in the embodiment of FIG3. In the embodiment of FIG3, the acquisition unit 310 is used to execute S301, and the processing unit 312 is used to execute S302.

[0378] In another implementation, the policy configuration device 30 is used to generate access control policies. In this case, the acquisition unit 310 is used to acquire user configuration information, which includes attribute configuration information of the vehicle's functional components; the processing unit 312 is used to obtain access control policies based on the user configuration information and the access control model; wherein, the access control model is used to describe the access permissions of the interfaces of multiple functional components of the vehicle to at least one of service resources, network resources, and system resources, each functional component is used to implement a business function of the in-vehicle software, and the access control model is constructed based on the information of multiple functional components of the vehicle, the information of each functional component includes the identifier of the functional component, the identifier of the interface of the functional component, and the type of the interface of the functional component.

[0379] The strategy configuration device 30 can be used to implement the method described in the embodiment of FIG7. In the embodiment of FIG7, the acquisition unit 310 is used to execute S701, and the processing unit 312 is used to execute S702.

[0380] In some possible embodiments, the policy configuration device 30 can be used to execute the method described in the embodiment of FIG10. In the embodiment of FIG10, the acquisition unit 310 is used to execute S1002, and the processing unit 312 is used to execute S1001, S1003-S1005. In some possible embodiments, the policy configuration device 30 further includes a display unit (not shown), which is used to present the verification result information in the embodiment of FIG10.

[0381] It should be understood that the division of units in the above-described strategy configuration device 30 is only a logical functional division. In actual implementation, they can be fully or partially integrated into a single physical entity, or they can be physically separated. Furthermore, the units in the device can be implemented by a processor calling software; for example, the device includes a processor connected to a memory containing instructions. The processor calls the instructions stored in the memory to implement any of the above methods or to implement the functions of each unit in the device. The processor can be, for example, a general-purpose processor, such as a central processing unit (CPU) or a microprocessor, and the memory can be internal or external to the device. Alternatively, the units in the device can be implemented as hardware circuits. The functionality of some or all units can be achieved through the design of these hardware circuits, which can be understood as one or more processors. For example, in one implementation, the hardware circuit is an application-specific integrated circuit (ASIC). The functionality of some or all of the above units is achieved through the design of the logical relationships between the components within the circuit. In another implementation, the hardware circuit can be implemented using a programmable logic device (PLD). Taking a field-programmable gate array (FPGA) as an example, it can include a large number of logic gates. The connection relationships between the logic gates are configured through a configuration file, thereby achieving the functionality of some or all of the above units. All units of the above device can be implemented entirely through processor-invoked software, entirely through hardware circuits, or partially through processor-invoked software with the remaining parts implemented through hardware circuits.

[0382] In this application embodiment, a processor is a circuit with signal processing capabilities. In one implementation, the processor can be a circuit with instruction reading and execution capabilities, such as a central processing unit (CPU), a microprocessor, a graphics processing unit (GPU) (which can be understood as a type of microprocessor), or a digital signal processor (DSP). In another implementation, the processor can implement certain functions through the logical relationships of hardware circuits. These logical relationships of hardware circuits are fixed or reconfigurable. For example, the processor is a hardware circuit implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD), such as an FPGA. In a reconfigurable hardware circuit, the process of the processor loading a configuration document and configuring the hardware circuit can be understood as the process of the processor loading instructions to implement the functions of some or all of the above units. Furthermore, it can also be a hardware circuit designed for artificial intelligence, which can be understood as a type of ASIC, such as a neural network processing unit (NPU), a tensor processing unit (TPU), a deep learning processing unit (DPU), etc.

[0383] As can be seen, each unit in the above device can be one or more processors (or processing circuits) configured to implement the above methods, such as: CPU, GPU, NPU, TPU, DPU, microprocessor, DSP, ASIC, FPGA, or a combination of at least two of these processor forms.

[0384] Furthermore, the units in the above devices can be integrated in whole or in part, or they can be implemented independently. In one implementation, these units are integrated together as a system-on-a-chip (SOC). The SOC may include at least one processor for implementing any of the above methods or implementing the functions of the units in the device. The at least one processor may be of different types, such as CPU and FPGA, CPU and artificial intelligence processor, CPU and GPU, etc.

[0385] Referring to Figure 14, which is a schematic diagram of a chip system according to an embodiment of this application, the chip system 40 includes a processor 401, a communication interface 402, a memory 403, and a bus 404. The processor 401, the memory 403, and the communication interface 402 communicate with each other via the bus 404. It should be understood that this application does not limit the number of processors and memories in the chip system 40.

[0386] In one implementation, the chip system 40 is, for example, a computing device cluster, a computing device, or a component within a computing device, such as a chip or integrated circuit. The computing device includes a bare metal server (BMS), a virtual machine, a container, or an edge computing device.

[0387] Bus 404 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, only one line is used in Figure 14, but this does not imply that there is only one bus or one type of bus. Bus 404 can include pathways for transmitting information between various components of the chip system 40 (e.g., memory 403, processor 401, communication interface 402).

[0388] The processor 401 can be referred to the relevant description of the processor in the above embodiments, and will not be repeated here.

[0389] Memory 403 provides storage space, which can store data such as the operating system and computer programs (e.g., access control models). Memory 403 can be one or a combination of several of the following: random access memory (RAM), erasable programmable read-only memory (EPROM), read-only memory (ROM), or compact disc read memory (CD-ROM). Memory 403 can exist alone or be integrated within processor 401.

[0390] The communication interface 402 can be used to provide information input or output to the processor 401. Alternatively, the communication interface 402 can be used to receive and / or send data to externally transmitted data, and can be a wired link interface including an Ethernet cable, or a wireless link interface (such as Wi-Fi, Bluetooth, general wireless transmission, etc.). Alternatively, the communication interface 402 may also include a transmitter (such as an RF transmitter, antenna, etc.) or a receiver coupled to the interface.

[0391] In some possible embodiments, the chip system 40 further includes a display 405, which is connected or coupled to the processor 401 via a bus 404. The display 405 can be used to indicate the attribute information to be configured to the user and to present the aforementioned verification result information to the user. The display 405 can be a liquid crystal display (LCD), an organic or inorganic light-emitting diode (OLED), an active matrix organic light-emitting diode (AMOLED), etc. When the chip system 40 is deployed in a vehicle, the display 405 can also be a vehicle-mounted tablet, an in-vehicle display, or a head-up display (HUD) system, etc.

[0392] The processor 401 in the chip system 40 is used to read the computer program stored in the memory 403 to execute the aforementioned methods, such as those described in FIG3, FIG7 or FIG10.

[0393] In one possible design, chip system 40 may be one or more modules in an execution body that performs the method shown in FIG3. The processor 401 may be used to read one or more computer programs stored in memory for performing the following operations:

[0394] The information of multiple functional components of the vehicle is obtained by the acquisition unit 310. Each functional component is used to implement a business function of the vehicle software. The information of each functional component includes the identifier of the functional component, the identifier of the interface of the functional component, and the type of the interface of the functional component.

[0395] Based on the information from these multiple functional components, an access control model is constructed. The access control model describes the access permissions of the interfaces of these multiple functional components to at least one of the service resources, network resources, and system resources. The access control model is used to obtain the vehicle's access control policy.

[0396] In one possible design, chip system 40 may be one or more modules in an execution body that performs the method shown in FIG7. The processor 401 may be used to read one or more computer programs stored in memory for performing the following operations:

[0397] User configuration information is obtained through the acquisition unit 310. The user configuration information includes the attribute configuration information of the vehicle's functional components.

[0398] Based on user configuration information and access control model, an access control policy is obtained. The access control model describes the access permissions of the interfaces of multiple functional components of the vehicle to at least one of service resources, network resources, and system resources. Each functional component is used to implement a business function of the in-vehicle software. The access control model is constructed based on the information of multiple functional components of the vehicle. The information of each functional component includes the identifier of the functional component, the identifier of the interface of the functional component, and the type of the interface of the functional component.

[0399] In the embodiments described above, each embodiment has its own emphasis. For parts not described in detail in a particular embodiment, please refer to the relevant descriptions in other embodiments. Furthermore, in the embodiments of this application, unless otherwise specified or logically conflicting, the terminology and / or descriptions between the embodiments are consistent and can be mutually referenced. Technical features from different embodiments can be combined to form new embodiments based on their inherent logical relationships.

[0400] It should be noted that those skilled in the art will recognize that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing related hardware. This program can be stored in a computer-readable storage medium, including read-only memory (ROM), random access memory (RAM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), one-time programmable read-only memory (OTPROM), electrically-erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disc storage, disk storage, magnetic tape storage, or any other computer-readable medium capable of carrying or storing data.

[0401] The technical solution of this application, in essence, or the part that makes the contribution, or all or part of the technical solution, can be embodied in the form of a software product. The computer program product is stored in a storage medium and includes several instructions to cause a device (which may be a personal computer, server, network device, robot, microcontroller, chip, robot, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application.

Claims

1. A method for constructing an access control model, characterized in that, The method includes: Information on multiple functional components of a vehicle is obtained. Each functional component is used to implement a business function of the in-vehicle software. The information of each functional component includes the identifier of the functional component, the identifier of the interface of the functional component, and the type of the interface of the functional component. Based on the information from the multiple functional components, an access control model is constructed. The access control model is used to describe the access permissions of the interfaces of the multiple functional components to at least one of service resources, network resources, and system resources.

2. The method according to claim 1, characterized in that, The functional component includes at least one interface, and the interface type of the functional component includes at least one of the following: service interface, system interface, and network interface.

3. The method according to claim 1 or 2, characterized in that, The plurality of functional components include a first group of functional components, each of which has a service interface, and the access control model includes a first access model. The process of constructing an access control model based on information from the multiple functional components includes: Based on the service interface list of the first group of functional components, the first access model is constructed. The first access model is used to describe the service provider and service consumer corresponding to each service interface in the service interface list of the first group of functional components, the service resources associated with the access when each service interface is accessed, the system resources associated with the access, and the network resources associated with the access. Each functional component in the first group of functional components acts as the service provider and / or the service visitor.

4. The method according to claim 3, characterized in that, The construction of the first access model based on the service interface list of the first group of functional components includes: Define a service-oriented architecture (SOA) service communication matrix, which is used to describe the access relationships between services and between services and service-oriented interfaces. Define the service provider of the service; Define the service consumer of the service; Define the system resources required for each access relationship in the SOA service communication matrix; and Define the network resources required for each access relationship in the SOA service communication matrix.

5. The method according to any one of claims 1-4, characterized in that, The plurality of functional components includes a second group of functional components, each of which has a system interface, and the access control model includes a second access model. The process of constructing an access control model based on information from the multiple functional components includes: Based on the system interface list of the second group of functional components, the second access model is constructed. The second access model is used to describe the system resources associated with the system interface of each functional component in the second group of functional components.

6. The method according to claim 5, characterized in that, The system interface list based on the second set of functional components is used to construct the second access model, including: Define the system interface for the second functional component; Define the system interfaces that the in-vehicle software needs to access in the system interfaces of the second group of functional components; Define a component atomic policy for each functional component in the second group of functional components. The component atomic policy for each functional component includes the atomic policy corresponding to each system interface of the functional component. The atomic policy corresponding to each system interface is associated with the system interface's permissions to system resources.

7. The method according to any one of claims 1-6, characterized in that, The method further includes: The third access model is constructed through the following operations: Define a non-service-oriented architecture (SOA) in-vehicle communication matrix, which describes the access relationships between target nodes using in-vehicle network communication in the non-SOA scenario; and Define an external network access list, which includes firewall rules and domain name filtering rules corresponding to the external networks that the in-vehicle software needs to access.

8. A method for generating access control policies, characterized in that, The method includes: Obtain user configuration information, which includes attribute configuration information of the vehicle's functional components; Based on the user configuration information and access control model, an access control policy is obtained; The access control model is used to describe the access permissions of the interfaces of multiple functional components of the vehicle to at least one of service resources, network resources, and system resources. Each functional component is used to implement a business function of the vehicle software. The access control model is associated with the information of the multiple functional components of the vehicle. The information of each functional component includes the identifier of the functional component, the identifier of the interface of the functional component, and the type of the interface of the functional component.

9. The method according to claim 8, characterized in that, The functional components include interfaces of at least one of the following types: service interfaces, system interfaces, and network interfaces.

10. The method according to claim 8 or 9, characterized in that, The vehicle's functional components include a first functional component, which has a service interface, and the access control model includes a first access model. The step of obtaining the access control policy based on the user configuration information and access control model includes: The attribute configuration information of the first functional component is input into the first access model to obtain the access control policy. The access control policy includes the access policy of the service resources associated with the target service, the access policy of the system resources associated with the target service, and the access policy of the network resources associated with the target service. The target service is the service provided by the first functional component. The attribute configuration information of the first functional component includes the identifier of the service provided by the first functional component, the identifier of the service that each service needs to access, the identifier of the service interface that each service needs to access, and the attribute information of the network associated with the access.

11. The method according to any one of claims 8-10, characterized in that, The vehicle's functional components include a second functional component, which has a system interface. The user configuration information also includes a list of system interfaces that the vehicle software needs to access. The access control model includes a second access model. The step of obtaining the access control policy based on the user configuration information and access control model includes: The attribute configuration information of the second functional component and the list of system interfaces that the vehicle software needs to access are input into the second access model to obtain the access control policy. The access control policy includes the access policy of the vehicle software to system resources. The list of system interfaces that the vehicle software needs to access belongs to the system interfaces of the second functional component. The attribute configuration information of the second functional component is used to determine the system resources associated with each system interface of the second functional component.

12. The method according to any one of claims 8-11, characterized in that, The user configuration information also includes at least one of external network access information and in-vehicle non-SOA access information. The external network access information is used to indicate the access relationship between in-vehicle nodes and external nodes. The in-vehicle non-SOA access information is used to indicate the access relationship between target nodes using in-vehicle network communication in the vehicle under non-SOA scenarios. The access control model also includes a third access model. The step of obtaining the access control policy based on the user configuration information and access control model includes: The external network access information and / or the in-vehicle non-SOA access information are input into the third access model to obtain the access control policy. The access control policy includes the access policy for network resources associated with the external network access information and / or the access policy for network resources associated with the in-vehicle non-SOA access information.

13. The method according to any one of claims 8-12, characterized in that, The step of obtaining the access control policy based on the user configuration information and access control model includes: Based on the user configuration information and the access control model, a first intermediate representation IR policy data is obtained, wherein the first IR policy data is an intermediate representation of the access control policy; If the first IR policy data passes verification, the access control policy is generated based on the first IR policy data.

14. The method according to claim 13, characterized in that, The method further includes: Based on the access control objective, second IR policy data is obtained, wherein the logical expression direction of the access control objective and the logical expression direction of the second IR policy data are both negative; The first IR strategy data is verified using the second IR strategy data to obtain verification result information, which indicates the verification result of the first IR strategy data.

15. The method according to claim 14, characterized in that, The method further includes: presenting at least one of the following pieces of information from the verification result information to the user through a display interface: The verification result of the first IR strategy data; The verification result of each IR policy entry in the first IR policy data; The evaluation score corresponding to the verification result of each IR strategy entry; The comprehensive evaluation score corresponding to the first IR strategy data; and Repair suggestions for IR policy entries that failed verification in the first IR policy data.

16. The method according to any one of claims 8-15, characterized in that, The method further includes: Indicates to the user the attribute information to be configured, the attribute information including the attribute configuration items of the vehicle's functional components; The process of obtaining user configuration information includes: Receive the settings information input by the user; The user configuration information is obtained based on the settings information.

17. The method according to claim 16, characterized in that, The attribute information also includes at least one of the following: Whether the system interfaces of the vehicle's functional components are configuration items declared for use by the vehicle software; Configuration items for access relationships between target nodes using in-vehicle network communication in non-SOA scenarios; Configuration items for accessing external networks; and Access control target.

18. The method according to any one of claims 8-17, characterized in that, The access control model is constructed based on the method described in any one of claims 1-7.

19. An apparatus for constructing an access control model, characterized in that, The device includes: The acquisition unit is used to acquire information about multiple functional components of the vehicle. Each functional component is used to implement a business function of the vehicle software. The information of each functional component includes the identifier of the functional component, the identifier of the interface of the functional component, and the type of the interface of the functional component. The processing unit is configured to construct an access control model based on information from the plurality of functional components. The access control model is used to describe the access permissions of the interfaces of the plurality of functional components to at least one of service resources, network resources, and system resources.

20. An apparatus for generating access control policies, characterized in that, The device includes: The acquisition unit is used to acquire user configuration information, which includes attribute configuration information of the vehicle's functional components; The processing unit is used to obtain the access control policy based on the user configuration information and the access control model; The access control model is used to describe the access permissions of the interfaces of multiple functional components of the vehicle to at least one of service resources, network resources, and system resources. Each functional component is used to implement a business function of the vehicle software. The access control model is associated with the information of the multiple functional components of the vehicle. The information of each functional component includes the identifier of the functional component, the identifier of the interface of the functional component, and the type of the interface of the functional component.

21. A chip system, characterized in that, The chip system includes a memory and at least one processor, the memory storing computer program instructions, and the at least one processor executing the computer program instructions to cause the chip system to perform the method as claimed in any one of claims 1-8, and / or perform the method as claimed in any one of claims 9-11.

22. A computing device, characterized in that, The computing device includes at least one of the apparatuses as described in claims 19 and 20, including the chip system as described in claim 21.

23. A vehicle, characterized in that, The vehicle includes the chip system as described in claim 21, or the computing device as described in claim 22.

24. A computer-readable storage medium, characterized in that, Includes computer instructions that, when executed by a processor, implement the method as described in any one of claims 1-7 and / or any one of claims 8-18.

Images