Container isolation-based vehicle component operation control system and method

Abstract

The application relates to the technical field of vehicle-mounted component operation control, and discloses a vehicle-mounted component operation control system and method based on container isolation, which comprises the following steps: acquiring real-time driving state information of a vehicle-mounted computing platform; determining a corresponding safety level identifier and generating a linkage control strategy according to the real-time value of the driving state parameter and a preset nonlinear mapping model; synchronously changing the capability set and resource quota of a target container in the same kernel transaction where the target container runs, to obtain an updated target container, according to the linkage control strategy; and scheduling the updated target container as a container instance in a target isolation state, to control the operation of the vehicle-mounted component. According to the application, the capability set permission and the resource quota are synchronously changed in the container freezing window of the same kernel transaction, the intermediate state generated by separately adjusting the permission and the resource is eliminated, and the control precision and safety of the vehicle-mounted component are improved.

Description

Technical Field

[0001] This application relates to the field of vehicle component operation control technology, and more specifically to a container-isolated vehicle component operation control system and method. Background Technology

[0002] Currently, multiple functional components, such as navigation, instrument cluster, multimedia, voice interaction, and driver assistance perception, need to run in parallel on the same in-vehicle computing platform. These components differ significantly in terms of safety level, resource requirements, and communication modes. To reduce interference between components, operating system-level container virtualization has been introduced into in-vehicle computing platforms. Leveraging the inherent namespace isolation and control group resource management capabilities of containers, different components are constrained to independent operating environments. In terms of hardware resources, in-vehicle computing platforms are limited by the power consumption and heat dissipation constraints of automotive-grade embedded processors. The number of processor cores and memory capacity cannot be compared with data center nodes, requiring container management mechanisms to provide isolation guarantees while reducing resource overhead.

[0003] The existing technology has the following problems: the adjustment of container capability set permissions and resource quotas is usually triggered separately by the application layer policy engine, lacking joint control, which leads to situations where permissions have been tightened but resource quotas have not been tightened synchronously when the driving state changes rapidly; triggering container configuration changes by judging a single driving parameter through a threshold cannot effectively distinguish between operating conditions with similar parameters but different safety requirements, such as high-speed straight driving and high-speed turning; when a container fails to rebuild, the failure to cut off the failure release channel in combination with the data relationship between components leads to a mismatch between the failure response process and the real-time vehicle status; in order to solve at least one of the above problems, this application proposes a container-isolated vehicle component operation control system and method. Summary of the Invention

[0004] To address the shortcomings of existing technologies, the purpose of this application is to provide a container-isolated vehicle component operation control system and method, which can effectively solve the problems in the background technology. The specific technical solution of this application is as follows:

[0005] A container-isolated method for controlling the operation of automotive components includes:

[0006] Obtain real-time driving status information from the vehicle computing platform, which includes real-time values ​​of multiple driving status parameters;

[0007] Based on the real-time values ​​of driving state parameters and a preset nonlinear mapping model, the corresponding safety level identifier is determined, and a linkage control strategy is generated. The linkage control strategy includes capability set pruning items and resource quota restriction items for the target container. The nonlinear mapping model reflects the nonlinear correspondence between the combination of driving state parameters and the safety level identifier.

[0008] According to the linkage control strategy, in the same kernel transaction in which the target container is running, the capability set and resource quota of the target container are synchronously changed to obtain the updated target container;

[0009] The target container is scheduled as a container instance in a target isolation state to control the operation of the vehicle components.

[0010] Specifically, obtaining the real-time driving status information of the in-vehicle computing platform includes:

[0011] The system extracts message signals from different electronic control units from the controller area network bus connected to the vehicle computing platform. The message signals include vehicle speed messages, gear messages, and brake pedal status messages.

[0012] The message signals are parsed and time-aligned to obtain real-time driving status information.

[0013] Specifically, the step of determining the corresponding safety level identifier based on the real-time values ​​of driving state parameters and a preset nonlinear mapping model, and generating a linkage control strategy, includes:

[0014] Based on the real-time values ​​in the driving status parameters, the motion status level and control intention level are determined, and matched in a preset nonlinear mapping model to determine the corresponding safety level identifier.

[0015] Based on the security level identifier, the corresponding capability set pruning items and resource quota restriction items are determined, and linkage control strategies are generated.

[0016] Specifically, the process involves determining the motion state level and control intention level based on real-time values ​​in the driving state parameters, matching them within a preset nonlinear mapping model, and determining the corresponding safety level identifier, including:

[0017] The motion state level is determined based on the real-time values ​​of the vehicle speed parameter and the steering wheel angle parameter in the driving state parameters.

[0018] The level of control intention is determined based on the real-time values ​​of the gear position parameter and the brake pedal status parameter in the driving status parameters.

[0019] By combining the motion state level and the control intention level, a matching process is performed in a preset nonlinear mapping model to determine the corresponding safety level identifier.

[0020] Specifically, the process of determining corresponding capability set pruning items and resource quota restriction items based on security level identifiers and generating linkage control strategies includes:

[0021] According to the security level identifier, it is matched in the preset capability set trimming mapping table to obtain the capability set trimming item, where the capability set trimming item reflects the list of kernel capabilities removed from the target container;

[0022] According to the security level identifier, it is matched in the preset resource quota limit mapping table to obtain the resource quota limit item, which reflects the upper limit of processor time and memory usage of the target container;

[0023] By combining the capability set pruning items and resource quota restriction items, a linkage control strategy is obtained.

[0024] Specifically, according to the linkage control strategy, within the same kernel transaction where the target container is running, the capability set and resource quota of the target container are synchronously changed to obtain an updated target container, including:

[0025] According to the linkage control strategy, after the same kernel transaction is started, the target container is put into a frozen state to prevent the process in the target container from being scheduled and executed.

[0026] In the frozen state, modify the capability set configuration and resource quota configuration corresponding to the target container;

[0027] After the modifications are completed, the target container is unfrozen and the same kernel transaction is committed to obtain the updated target container.

[0028] Specifically, in the frozen state, the capability set configuration and resource quota configuration corresponding to the target container are modified, including:

[0029] In a frozen state, compare the safety level identifier with the real-time safety level identifier corresponding to the target container;

[0030] If the security level of the security level identifier is higher than that of the real-time security level identifier, the capability set configuration will be trimmed and modified, and the resource quota configuration will be tightened.

[0031] If the security level of the security level identifier is not higher than the security level of the real-time security level identifier, the resource quota configuration will be relaxed and modified, and the capability set configuration will be restored and modified.

[0032] Specifically, the step of scheduling the updated target container as a container instance in a target isolation state to control the operation of the vehicle components includes:

[0033] Reset the network access whitelist of the target container to a predefined set of communication ports corresponding to the security level identifier;

[0034] Reset the device node access permissions of the target container to a predefined list of device nodes corresponding to the security level identifier.

[0035] Specifically, the step of scheduling the updated target container as a container instance in a target isolation state to control the operation of the vehicle components further includes:

[0036] During the update of the target container, monitor the real-time processor utilization and memory utilization.

[0037] If the occupancy rate exceeds the processor time limit in the resource quota limit, or the memory occupancy rate exceeds the memory usage limit in the resource quota limit, the target container will be marked as abnormal, and the container instance will be replaced.

[0038] A container-isolated on-board component operation control system, used to implement the container-isolated on-board component operation control method, includes:

[0039] The data acquisition module acquires real-time driving status information from the vehicle computing platform, which includes real-time values ​​of multiple driving status parameters.

[0040] The linkage control module determines the corresponding safety level identifier based on the real-time values ​​of driving state parameters and a preset nonlinear mapping model, and generates a linkage control strategy. The linkage control strategy includes capability set pruning items and resource quota restriction items for the target container. The nonlinear mapping model reflects the nonlinear correspondence between the combination of driving state parameters and the safety level identifier.

[0041] The container change module, based on the linkage control strategy, synchronously changes the capability set and resource quota of the target container in the same kernel transaction in which the target container is running, to obtain the updated target container;

[0042] The component operation control module schedules the updated target container as a container instance in a target isolation state to control the operation of the vehicle components.

[0043] The beneficial effects of this application are as follows: Capability set permissions and resource quotas are synchronously changed within the container freeze window of the same kernel transaction, eliminating the intermediate state caused by separate adjustments of permissions and resources; the security level identifier is generated through nonlinear mapping of multi-dimensional driving state parameters, which can obtain dangerous operating condition combinations that cannot be distinguished by a single parameter threshold, thereby improving safety; the control of pruning capabilities and then tightening resources when constraints are tightened, and relaxing resources and then restoring capabilities when constraints are relaxed, eliminates the window of unauthorized operation during the tightening process and the window of insufficient resources during the relaxation process; the network whitelist and device node permissions shrink in conjunction with the security level, and the super user privileges within the container cannot be bypassed; and the control accuracy and security of vehicle components are improved. Attached Figure Description

[0044] Figure 1This is a flowchart illustrating the operation control method for onboard components based on container isolation in this application embodiment;

[0045] Figure 2 This is a schematic diagram of the structure of the container-isolated vehicle component operation control system in the embodiments of this application. Detailed Implementation

[0046] The present application will be further described in detail below with reference to the accompanying drawings and embodiments.

[0047] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0048] Hereinafter, the terms "first," "second," and other generic terms are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0049] refer to Figure 1 The diagram illustrates a specific implementation of the container-isolated vehicle component operation control method of this application, including:

[0050] S101. Obtain real-time driving status information from the vehicle computing platform, wherein the real-time driving status information includes real-time values ​​of multiple driving status parameters.

[0051] S102. Based on the real-time values ​​of driving state parameters and a preset nonlinear mapping model, determine the corresponding safety level identifier and generate a linkage control strategy. The linkage control strategy includes capability set pruning items and resource quota restriction items for the target container. The nonlinear mapping model reflects the nonlinear correspondence between the combination of driving state parameters and the safety level identifier.

[0052] S103. According to the linkage control strategy, in the same kernel transaction where the target container is running, the capability set and resource quota of the target container are synchronously changed to obtain the updated target container;

[0053] S104. Schedule the updated target container as a container instance in a target isolation state to control the operation of the vehicle components.

[0054] In this embodiment, the container-isolated vehicle component operation control method is executed collaboratively by the status acquisition module, linkage control module, container change module, and component operation control module on the vehicle computing platform.

[0055] It's important to note that a container refers to an operating system-level virtualization instance. Each container has its own independent process namespace, file system mount point, network stack, and a set of capabilities and resource quotas managed by the kernel. The capability set refers to the set of kernel privileged operation permissions granted to the container, recorded in the container configuration's capability field as a bitmap, controlling whether the container can perform operations such as creating raw sockets and modifying system parameters. Resource quotas refer to resource usage constraints imposed on the container through a control group mechanism, such as maximum processor time and physical memory limits; the specific values ​​are written to the corresponding parameter file of the control group. The security level identifier characterizes the strength of constraints that should be imposed on the container under the current driving state; a larger identifier value indicates a more stringent constraint. A target container refers to a specific container instance in an isolation state to be adjusted; this instance hosts in-vehicle functional components such as navigation, multimedia, or instrument clusters.

[0056] In this embodiment, the onboard computing platform is connected to various electronic control units in the vehicle body via a controller area network bus. The status acquisition module extracts message signals from the bus at a fixed acquisition period. For example, the acquisition period is set to 50 milliseconds. In a single acquisition, the module extracts the vehicle speed message with identifier 0x100, the gear message with identifier 0x200, the brake pedal status message with identifier 0x300, and the steering wheel angle message with identifier 0x400.

[0057] The seventh byte of the vehicle speed message carries the raw vehicle speed value. The module multiplies it by a scaling factor of 0.01 to obtain the real-time vehicle speed value in kilometers per hour. The lower four bits of the third byte of the gear position message indicate the current gear code. The module parses this code to determine if the current gear is park, reverse, neutral, or drive. The highest bit of the second byte of the brake pedal status message indicates the pedal status; a 1 indicates the pedal is depressed, and a 0 indicates it is released. The module outputs a Boolean pedal status value accordingly. The fourth and fifth bytes of the steering wheel angle message together form a signed integer value. The module performs a physical value conversion to obtain the steering wheel deflection angle in degrees.

[0058] Specifically, a time-series alignment operation is performed on the four-way parsing results: using the arrival timestamp of the vehicle speed message as a baseline, the parsed values ​​of the other three parameters within the same acquisition period are merged under that timestamp to form a set of real-time driving status information. This set of information includes the real-time values ​​of the vehicle speed parameter, the steering wheel angle parameter, the gear position parameter, and the brake pedal status parameter. Time-series alignment ensures consistency in the time dimension of signals asynchronously emitted by different electronic control units, eliminating deviations caused by signal transmission delay differences in subsequent safety level determinations.

[0059] Furthermore, a nonlinear mapping model is pre-defined in the onboard computing platform. Its function is to map multi-dimensional driving state parameter combinations into a single safety level identifier, and this mapping relationship exhibits nonlinear characteristics. Nonlinearity means that the change in the safety level identifier does not linearly increase or decrease with the increase or decrease of any single parameter value; there are step-like jumps in level between different combinations of parameters. For example, when driving at high speed and with a large steering wheel angle, the jump in safety level is far greater than that of an increase in vehicle speed or steering angle alone. This coupling effect cannot be characterized by linear mapping.

[0060] As one implementation method, the nonlinear mapping model is implemented in the form of a two-dimensional safety level lookup table. This lookup table uses motion state level as the first dimension and control intention level as the second dimension, with each entry storing a safety level identifier. The motion state level is determined by the real-time values ​​of the vehicle speed parameter and the steering wheel angle parameter. The determination method is as follows: vehicle speed is divided into three numerical intervals, and steering wheel angle is divided into three numerical intervals; the combination of these intervals corresponds to one of the three motion state levels. The control intention level is determined by the real-time values ​​of the gear position parameter and the brake pedal state parameter. The determination method is as follows: when the gear is forward and the brake pedal is released, the control intention level is driving intention; when the gear is park or the brake pedal is depressed, the control intention level is parking intention; when the gear is reverse, the control intention level is reversing intention. After obtaining the motion state level and control intention level, the corresponding safety level identifier is located in the two-dimensional safety level lookup table.

[0061] As another implementation method, the nonlinear mapping model is implemented using a trained neural network classifier. The training data for the neural network classifier is obtained through real-world road data collection, covering urban congestion, expressways, mountain curves, and parking scenarios. The data collection system simultaneously records parameters such as vehicle speed, steering wheel angle, gear position, and brake pedal status. Safety engineers then label each record with a safety level based on the component's safety policy, with levels ranging from 1 to 5, where 5 corresponds to the most stringent constraint scenario and 1 corresponds to a parking entertainment scenario. After data cleaning and normalization, approximately 80,000 labeled samples are obtained, which are divided into training and validation sets at a ratio of 4:1.

[0062] Specifically, the neural network classifier is a fully connected network with two hidden layers. The input layer has four neurons, receiving normalized values ​​for vehicle speed, steering wheel angle, gear position, and brake pedal state, respectively. The first hidden layer has sixteen neurons, using the hyperbolic tangent activation function; the second hidden layer has eight neurons, also using the hyperbolic tangent activation function. The output layer has five neurons, each corresponding to a safety level category. A flexible maximum operation is then applied to convert the output into a probability distribution for each category, and the safety level identifier corresponding to the category with the highest probability is taken as the output. The hyperbolic tangent activation function enters the saturation region when the absolute value of the input is large, making it suitable for capturing nonlinear abrupt changes in driving parameters under extreme combinations.

[0063] During training, cross-entropy loss was chosen as the loss function, Adam was selected as the optimizer, the initial learning rate was set to 0.001, the batch size was set to 64, and the weight decay coefficient was set to 0.0001. An early stopping strategy was adopted for training epochs; training was terminated when the validation set loss did not decrease for five consecutive epochs, retaining the model parameters with the minimum validation set loss. After training, the weight matrices and bias vectors of each layer of the network were extracted into fixed arrays and stored in the memory of the linkage control module of the vehicle computing platform as instance parameters for the runtime nonlinear mapping model. During runtime, the linkage control module normalizes or encodes the four real-time values ​​of the driving state parameters output in step S101 in the same way as the training data to form an input vector. This vector is then sequentially processed by weighted summation and hyperbolic tangent transformation in the first hidden layer, weighted summation and hyperbolic tangent transformation in the second hidden layer, and weighted summation and maximum flexibility transformation in the output layer to obtain the safety level identifier.

[0064] After determining the security level identifier, the linkage control module generates linkage control policies based on this identifier. The module internally has a pre-built capability set pruning mapping table and a resource quota limit mapping table. These two mapping tables are constructed during the design phase according to the principle of least privilege and written into the non-volatile memory of the onboard computing platform. The capability set pruning mapping table uses the security level identifier as an index, with each index corresponding to a list of kernel capability names. The list shows the capabilities that should be removed from the target container under that security level. For example, the list corresponding to security level 1 is empty, and no capabilities are removed; the list corresponding to security level 3 includes CAP_NET_RAW and CAP_SYS_PTRACE, prohibiting the container from performing raw socket operations and process tracing; the list corresponding to security level 5 adds CAP_SYS_ADMIN, etc., to further restrict container privileges. The resource quota limit mapping table also uses the security level identifier as an index, with each index corresponding to a processor time limit and a memory usage limit. The processor time limit is expressed as a percentage: 50% for security level 1, 30% for security level 3, and 15% for security level 5. Similarly, the memory usage limit is expressed as a percentage of total memory: 50% for security level 1, 30% for security level 3, and 20% for security level 5. These percentage values ​​were determined through resource allocation tests after the target platform's hardware specifications and the number of running components were finalized. Different platforms may be adjusted according to their actual specifications, but the decreasing trend of percentages as the security level increases remains consistent.

[0065] Specifically, using the security level identifier as an index, the capability set pruning mapping table and the resource quota limit mapping table are queried sequentially to obtain the capability set pruning items and resource quota limit items. These are then encapsulated in the same data structure to form a linked control strategy. This strategy comprises three components: a list of kernel capability names to be removed, an integer value representing the processor time limit, and an integer value representing the memory usage limit.

[0066] Furthermore, a container manager runs on the onboard computing platform. This container manager maintains a corresponding control group and configuration file for each container and provides interfaces for freezing, unfreezing, and modifying configurations. After receiving the linkage control policy, the container change module initiates a transactional control session with the container manager.

[0067] At the start of the transaction, the container manager writes the value 1 to the cgroup.freeze file under the corresponding control group of the target container. After receiving this write, the kernel removes all user-space processes within the target container from the scheduling queue, and the container enters a frozen state. In the frozen state, processes within the container no longer receive processor time slices and cannot initiate system calls. Therefore, they will not be aware of partial changes to capability sets or resource quotas during configuration modifications.

[0068] During the frozen state, the container change module writes the capability set configuration and resource quota configuration of the target container. For capability sets, the module locates a pseudo file in the container configuration directory that records capability sets. This file separates currently enabled capability names with whitespace characters. The module reads the current content, compares each item with the capability set pruning items in the linkage control policy, removes the matching capability names from the content, and writes them back. For resource quotas, the module writes the processor time limit to the cpu.max file in the target container control group and the memory usage limit to the memory.max file. Both writes are completed sequentially during the frozen state.

[0069] For different scenarios involving ascending and descending security levels, the order in which modules execute writes varies. When the current security level indicator is higher than the target container's current effective level (i.e., constraints are tightened), the module first performs capability set pruning writes, followed by resource quota tightening writes. When the current security level indicator is lower than the current level (i.e., constraints are relaxed), the module first performs resource quota relaxation writes, followed by capability set restoration writes. During tightening, capability channels are closed before resources are compressed to prevent residual capabilities from being misused while resources are still ample. During relaxation, resource supply is restored before permissions are granted to prevent component execution anomalies due to insufficient resources after permissions are restored.

[0070] As an optional implementation, if the container change module receives a new linkage control policy for the same target container while the transaction is uncommitted, the module interrupts the current transaction. The interruption operation includes abandoning the partially modified capability sets and resource quotas already written, rolling back the relevant configuration files to the snapshot state saved before the transaction started, unfreezing the target container, and re-initiating the transaction with the latest received linkage control policy as input. This mechanism ensures that the system always responds to the latest state when the driving state changes rapidly, and is not blocked by outdated transactions.

[0071] After the configuration is written, the container modification module unfreezes the target container, writes the value 0 to the cgroup.freeze file, and resumes process scheduling within the container. The module commits the transaction and obtains the updated target container. All modifications to the capability set and resource quotas are completed within the freeze window, appearing externally as an atomic transition. There are no intermediate observable windows where the capability set has changed but the resource quota has not, or vice versa.

[0072] Furthermore, after obtaining the target container for the update, the component operation control module implements isolation and hardening measures on both the network and device sides. On the network side, the module resets the network access whitelist of the target container to a predefined set of communication ports corresponding to the security level identifier. Specifically, the module executes iptables rule updates in the network namespace of the target container, clears existing filtering rules, and loads the corresponding rule file based on the security level identifier. Taking security level 3 as an example, the corresponding rule file only allows outbound connections with target IP addresses that are the instrument display service port and navigation data service port, discarding all other outbound requests and all inbound requests. The shrinking of the network access whitelist forcibly restricts the set of ports that the container can communicate with, preventing the container from sending or receiving data to or from unauthorized services even if the component code within the container has defects.

[0073] On the device side, the access permissions of the target container's device nodes are reset to a predefined list of device nodes corresponding to the security level identifier. Processes within the container access hardware peripherals such as cameras, audio codecs, and graphics accelerators through device node files. Based on the security level identifier, the module modifies the device control group configuration of the target container, writing the major and minor device numbers of device nodes not in the predefined list to the `devices.deny` file, thus blocking read and write operations on these nodes by the container at the kernel's device access control layer. For example, at security level 4, the container for the back-end entertainment components is denied access to the camera and audio input device nodes, but retains access to the display and audio output device nodes, ensuring that media playback can continue while recording and video recording are blocked.

[0074] As an optional implementation, during the execution of the target container update, the component execution control module continuously monitors its real-time processor and memory usage. Monitoring is achieved by periodically reading the cpu.stat and memory.current files of the container's corresponding control group to obtain processor usage time and current memory usage, comparing these values ​​with the upper limits for processor time and memory usage in the resource quota limits. When either the processor usage or memory usage exceeds the upper limit, the module determines that the container has entered an abnormal state. This abnormal state may be caused by component memory leaks, infinite loops, or external attacks. After marking the target container as abnormal, the module triggers a container instance replacement process: it selects an initialized and idle standby instance of the same type from a pre-maintained container instance pool, performs the configuration process of step S103 on the standby instance based on the current security level identifier of the abnormal container, and after configuration, the standby instance takes over the component functions of the abnormal container and destroys the abnormal container instance.

[0075] This application's capability set permissions and resource quotas are synchronously changed within the container freeze window of the same kernel transaction, eliminating intermediate states caused by separate adjustments to permissions and resources; the security level identifier is generated through nonlinear mapping of multi-dimensional driving state parameters, which can obtain dangerous operating condition combinations that cannot be distinguished by a single parameter threshold, thus improving safety; the control of tightening constraints by pruning capabilities and then tightening resources, and relaxing constraints by relaxing resources and then restoring capabilities, eliminates the window of unauthorized operation during the tightening process and the window of insufficient resources during the relaxation process; the network whitelist and device node permissions shrink in conjunction with the security level, and superuser permissions within the container cannot be bypassed; improving the control accuracy and security of vehicle components.

[0076] Furthermore, real-time driving status information from the in-vehicle computing platform is obtained, including:

[0077] S201. Extract message signals from different electronic control units from the controller area network bus connected to the vehicle computing platform. The message signals include vehicle speed message, gear message and brake pedal status message.

[0078] S202. Parse and time-align the message signals to obtain real-time driving status information.

[0079] In this embodiment, the original message is extracted from the bus driver layer according to the preset message identifier, and the extracted message is parsed for physical value and time alignment is performed to output a set of multi-parameter real-time values ​​with a unified timestamp.

[0080] Specifically, the onboard computing platform connects to the vehicle bus via a Controller Area Network (CAN) transceiver, which continuously receives message frames periodically reported by each electronic control unit (ECU). The status acquisition module writes filtering rules to the CAN controller at the driver layer. The rules pre-set message identifiers include three groups: 0x100, 0x200, and 0x300, corresponding to vehicle speed messages, gear messages, and brake pedal status messages, respectively. During reception, the controller performs hardware comparison on the identifier segment of each arriving message frame. Message data frames that match the filtering rules are automatically copied to a circular buffer allocated in memory by the module; messages that do not match the rules are directly discarded by hardware, without incurring memory copy overhead. Each message frame includes a start bit, identifier segment, data length code, data segment, and cyclic redundancy check (CRC) segment. After reading the data frame from the buffer, the module performs integrity verification on the message according to the CRC polynomial. Frames that pass the verification have their header and trailer removed, retaining the data segment's payload bytes; frames that fail the verification are discarded, and a discard count is recorded.

[0081] The vehicle speed message data segment is 8 bytes long, with the seventh byte storing the raw vehicle speed value. This raw value is an unsigned integer, quantized from the analog voltage output by the vehicle speed sensor after analog-to-digital conversion. The lower four bits of the third byte of the gear position message data segment are the gear position encoding field. The mapping relationship between this encoding value and the specific gear is defined by the vehicle manufacturer in the electronic control unit communication matrix. The module has a pre-set encoding mapping table consistent with this communication matrix. The highest bit of the second byte of the brake pedal status message data segment is a single-bit status flag. These three sets of messages are sent independently by their respective electronic control units on the bus, with asynchronous transmission periods and phases. The module only copies the data during the extraction of each set of messages and does not interfere with the message broadcast transmission process on the bus.

[0082] Furthermore, for the vehicle speed message, the module reads the unsigned integer value of the seventh byte, multiplies it by a preset scaling factor of 0.01. The scaling factor is determined based on the range of the vehicle speed sensor and the resolution of the analog-to-digital conversion. The result of the multiplication is the real-time vehicle speed value in kilometers per hour. For the gear message, the module extracts the lower four bits of the third byte and matches them in a preset gear coding mapping table. This mapping table stores four sets of entries: code 0x01 corresponds to parking gear, 0x02 corresponds to reverse gear, 0x03 corresponds to neutral gear, and 0x04 corresponds to drive gear. After a successful match, the corresponding gear name is output as the real-time value of the gear parameter. For the brake pedal status message, the module extracts the logic value of the highest bit of the second byte. When the value is 1, a Boolean value representing that the pedal is depressed is output; when the value is 0, a Boolean value representing that the pedal is released is output.

[0083] Specifically, timing alignment is performed on the three parsing results, with the reference time point for the alignment operation being the received timestamp of the vehicle speed message. Internally, the module maintains a buffer for each of the gear position parsing result and the brake pedal state parsing result, storing the most recent few frame parsing values ​​and their received timestamps. After a frame of vehicle speed message is parsed and a timestamp is generated, the module searches the gear position buffer for the record with the smallest absolute time difference between the received timestamp and the reference time point, while simultaneously determining whether this minimum time difference exceeds a preset alignment tolerance. The alignment tolerance is a time difference threshold set to determine whether two signals from different sources can be considered to be at the same moment. In this embodiment, the threshold is 5 milliseconds, less than the minimum change interval of both the vehicle speed signal and the gear position signal, ensuring that two signals within the tolerance can reasonably be considered to reflect the vehicle state at the same moment. If the minimum time difference is within the alignment tolerance, the module retrieves the gear position parsing value; if it exceeds the alignment tolerance, the module abandons the alignment and waits for the next frame of vehicle speed message. The same operation is performed on the brake pedal state buffer. After the gear position and brake pedal status are aligned, the module merges the real-time vehicle speed, gear position, and brake pedal status values ​​into the same timestamp and outputs them as a set of real-time driving status information.

[0084] Preferably, the unitless quantization encoding transmitted on the bus is converted into real-time parameter values ​​carrying physical units, enabling subsequent safety level determinations to be based on the vehicle's physical motion and control states. This eliminates the incomparability of parameters caused by differences in sensor ranges and encoding methods. The timing alignment operation uses the timestamp of a single reference signal as a benchmark and merges the most recent valid values ​​of other signals under alignment tolerance constraints. This mechanism avoids the situation where parameters sampled at different times are encoded into the same set of input vectors, ensuring the internal consistency of the output set of real-time driving state information in the time dimension. It provides the subsequent nonlinear mapping model with an input that accurately reflects the complete state of the vehicle at the same moment, avoiding misjudgments of safety level identification due to parameter time misalignment, and preventing incorrect adjustments to container capacity sets and resource quotas due to misjudgments.

[0085] Furthermore, based on the real-time values ​​of driving state parameters and a preset nonlinear mapping model, the corresponding safety level identifier is determined, and a linkage control strategy is generated, including:

[0086] S301. Based on the real-time values ​​in the driving status parameters, determine the motion status level and control intention level, and match them in the preset nonlinear mapping model to determine the corresponding safety level identifier.

[0087] S302. Based on the security level identifier, determine the corresponding capability set pruning items and resource quota restriction items, and generate linkage control strategies.

[0088] In this embodiment, the real-time values ​​of driving state parameters are converted into motion state level and control intention level, and a safety level identifier is mapped out through a nonlinear mapping model. Using the safety level identifier as an index, the corresponding capability set pruning items and resource quota restriction items are retrieved from the preset configuration mapping table and combined into a linkage control strategy.

[0089] Specifically, the real-time driving status information includes four parameters: vehicle speed, steering wheel angle, gear position, and brake pedal status. The linkage control module extracts the values ​​of these four parameters from the real-time driving status information and sends them to the motion state evaluation branch and the control intention evaluation branch, respectively.

[0090] Furthermore, the motion state assessment branch processes data based on the real-time values ​​of vehicle speed and steering wheel angle. The vehicle speed range is divided into three continuous intervals: the first interval is a low-speed zone (less than 30 km / h), the second interval is a medium-speed zone (30 km / h to 80 km / h), and the third interval is a high-speed zone (greater than 80 km / h). Similarly, the steering wheel angle range is divided into three intervals: the first interval is a small-angle zone (absolute value less than 15 degrees), the second interval is a medium-angle zone (absolute value between 15 and 45 degrees), and the third interval is a large-angle zone (absolute value greater than 45 degrees). The real-time vehicle speed value is read to determine its corresponding speed interval number; the absolute value of the real-time steering wheel angle is read to determine its corresponding angle interval number. Two sets of interval numbers form a two-dimensional combination. The table is searched in the preset motion state level lookup table using this two-dimensional combination as the index. The lookup table is a 3-row, 3-column matrix, with rows corresponding to vehicle speed intervals and columns corresponding to corner intervals. Each entry stores a motion state level identifier.

[0091] The combination of low speed and small turning angle corresponds to motion state level 1, indicating that the vehicle is stationary or in a low-speed, stable driving condition. The combination of high speed and large turning angle corresponds to motion state level 3, indicating that the vehicle is in a high-speed turning condition. The remaining combinations correspond to motion state level 2. The logic for constructing this lookup table is based on the non-linear distribution of the degree of danger in driving conditions: both increased vehicle speed and increased turning angle increase the degree of danger, but when both occur simultaneously, the increase in the degree of danger is significantly greater than the sum of their individual contributions. Therefore, the level classification is not based on a linear threshold of a single parameter, but rather on a two-dimensional combination to reflect the coupling effect.

[0092] Specifically, the processing of the control intent evaluation branch is based on the real-time values ​​of two parameters: gear position and brake pedal state. The real-time values ​​of the gear position and brake pedal state are read, and a control intent level is generated according to a set of preset classification rules. These rules include: when the gear is park, regardless of the brake pedal state, the control intent level is determined to be 0, corresponding to a parking intent. When the gear is reverse, the control intent level is determined to be 2, corresponding to a reversing intent. When the gear is drive and the brake pedal is depressed, the control intent level is determined to be 1, corresponding to a deceleration intent. When the gear is drive and the brake pedal is released, the control intent level is determined to be 3, corresponding to a driving intent. The classification rules are fixed in the module code in the form of a control logic decision tree. The four branches are mutually exclusive and exhaustive; any valid gear position and brake pedal state input will inevitably fall into one of the branches, producing a definite control intent level output.

[0093] After obtaining the motion state level and control intention level, these are fed into a pre-defined nonlinear mapping model. The nonlinear mapping model employs a two-dimensional safety level lookup table. This lookup table uses the motion state level as the row index and the control intention level as the column index. The number of rows equals the number of possible motion state level values, and the number of columns equals the number of possible control intention level values. Each cell stores a safety level identifier. The lookup table is constructed as follows: during the vehicle development phase, safety engineers conduct safety analyses on various combinations of motion states and control intentions. For each combination, they assess the safety sensitivity and resource requirements of each component in the cockpit. Factors considered during the assessment include the driver's reliance on instrument information, their need for entertainment functions, and the probability of a collision under that combination. A comprehensive safety level identifier is derived and filled into the corresponding cell. The safety level identifier ranges from 1 to 5, with higher values ​​indicating stricter safety constraints.

[0094] For example, the combination of motion state level 3 and control intention level 3 corresponds to high-speed driving and active vehicle control, with a safety level of 5, requiring the most stringent container constraints. The combination of motion state level 1 and control intention level 0 corresponds to a parked and stationary state, with a safety level of 1, and the most lenient container constraints.

[0095] Furthermore, the linkage control module has two pre-built configuration mapping tables: a capability set pruning mapping table and a resource quota limit mapping table. These two tables are constructed during the design phase based on the principle of least privilege and resource hierarchical strategy, and are stored in the non-volatile memory of the vehicle computing platform. During runtime, the module directly reads them using the security level identifier as an index.

[0096] Specifically, the capability set trimming mapping table is structured as an array, with array indices corresponding to security level identifiers 1 to 5. Each array element stores a list of kernel capability names. The hierarchical setting logic of this mapping table is as follows: Security level 1 corresponds to an empty list, with no kernel capabilities trimmed; Security level 2 corresponds to a list containing CAP_NET_RAW, prohibiting containers from creating raw sockets; Security level 3 corresponds to a list that adds CAP_SYS_PTRACE to the list that is based on security level 2, prohibiting containers from performing process tracing; Security level 4 corresponds to a list that adds CAP_SYS_ADMIN to the list that is based on security level 3, prohibiting containers from performing system management operations; Security level 5 corresponds to a list that adds CAP_SYS_MODULE to the list that is based on security level 4, prohibiting containers from loading kernel modules. The newly added capability names at each level are selected from the capability set defined by the Linux kernel, and the specific permission scope of each capability item is consistent with the kernel standard.

[0097] Specifically, the resource quota limit mapping table is structured as an array, with array indices corresponding to security level identifiers 1 to 5. Each array element stores a set of resource quota values, including processor time limits and memory usage limits. Processor time limits are expressed as percentages, and memory usage limits are expressed as a percentage of total physical memory. The hierarchical setting logic of this mapping table is as follows: at security level 1, both processor time and memory usage limits are 50%; at security level 2, they are 40%; at security level 3, they are 30%; at security level 4, they are 20%; and at security level 5, they are 15% and 20%. These percentage values ​​are calculated based on the total number of processor cores and total physical memory capacity of the target platform. The monotonically decreasing percentage trend with increasing security level ensures that when security constraints tighten, platform resources occupied by non-critical components are forcibly compressed, and the released resources are reclaimed by the system or allocated to components strongly related to driving safety.

[0098] Using the security level identifier as the index, retrieve the corresponding list of kernel capability names from the capability set pruning mapping table as capability set pruning items; retrieve the corresponding processor time limit and memory usage limit values ​​from the resource quota limit mapping table as resource quota limit items. Encapsulate the capability set pruning items and resource quota limit items in the same data structure, and pass this data structure as the output of the linkage control policy to step S103.

[0099] Preferably, the separate evaluation mechanism of motion state level and control intention level quantifies the vehicle's physical motion and the driver's control actions as two independent dimensions, avoiding semantic confusion caused by simply mixing four heterogeneous parameters such as vehicle speed, steering angle, gear position, and brake pedal. The nonlinear mapping model couples the two dimensions in a two-dimensional combination or a nonlinear neural network manner, capturing the cross-effects that cannot be reflected by simple threshold judgment. Under certain combinations of motion state and control intention, the safety level increases dramatically, while under other combinations, the safety level remains stable, more accurately identifying driving conditions that require increased constraint intensity and reducing missed judgments and misjudgments.

[0100] Furthermore, based on the real-time values ​​of the driving state parameters, the motion state level and control intention level are determined, and matched against a preset nonlinear mapping model to determine the corresponding safety level identifier, including:

[0101] S401. Determine the motion state level based on the real-time values ​​of the vehicle speed parameter and the steering wheel angle parameter in the driving state parameters.

[0102] S402. Determine the control intention level based on the real-time values ​​of the gear position parameter and the brake pedal status parameter in the driving status parameters.

[0103] S403. Combining the motion state level and the control intention level, a matching process is performed in a preset nonlinear mapping model to determine the corresponding safety level identifier.

[0104] In this embodiment, the motion state level is determined based on vehicle speed and steering wheel angle. In step S402, the control intention level is determined based on gear position and brake pedal state. The two levels are combined and fed into a nonlinear mapping model to obtain a safety level identifier.

[0105] Specifically, the linkage control module extracts real-time values ​​of vehicle speed and steering wheel angle from the real-time driving status information. The module has two preset threshold groups: vehicle speed thresholds of 30 km / h and 80 km / h, and steering wheel angle thresholds of 15 degrees and 45 degrees. These thresholds are determined during system calibration based on the vehicle's chassis dynamics. The real-time vehicle speed value is compared sequentially with the two speed threshold groups: speeds less than 30 km / h are classified as low-speed, speeds greater than or equal to 30 km / h and less than 80 km / h as medium-speed, and speeds greater than or equal to 80 km / h as high-speed. The real-time steering wheel angle value is then taken as an absolute value and compared sequentially with the two angle threshold groups: an absolute value less than 15 degrees is classified as small-angle, greater than or equal to 15 degrees and less than 45 degrees as medium-angle, and greater than or equal to 45 degrees as large-angle. Absolute values ​​are used because left and right steering have equivalent effects on motion state in terms of symmetry. Once the speed and turning angle ranges are determined, the module uses the speed range number as the row index and the turning angle range number as the column index to look up the motion state level in a 3x3 two-dimensional matrix. The matrix stores the following: low speed and small turning angle combinations correspond to motion state level 1; low speed and medium turning angle, medium speed and small turning angle, and medium speed and medium turning angle combinations correspond to motion state level 2; and the remaining five combinations correspond to motion state level 3. Motion state levels 1 to 3 represent low dynamic, medium dynamic, and high dynamic operating conditions, respectively. This lookup table structure couples the information from both the speed and turning angle dimensions when outputting the level, rather than simply adding them together after separate checks.

[0106] Furthermore, the module extracts real-time values ​​of gear position parameters and brake pedal status parameters from the real-time driving status information. An internal classification decision tree is then embedded. The root node determines whether the gear is park; if so, it outputs control intention level 0. If the gear is reverse, it outputs control intention level 2. If the gear is neutral, it outputs control intention level 0. If the gear is drive, it further determines the brake pedal status: when depressed, it outputs control intention level 1; when released, it outputs control intention level 3. This decision tree covers all valid combinations of gear position and brake pedal status, with no undefined output branches. Control intention levels 0 to 3 represent parking intention, deceleration intention, reversing intention, and driving intention, respectively, with values ​​arranged in ascending order of control activity.

[0107] Specifically, the linkage control module takes the motion state level and control intention level as inputs, feeds them into a preset nonlinear mapping model, and outputs a safety level identifier. The nonlinear mapping model adopts a two-dimensional safety level lookup table, which is a 3-row, 4-column matrix. The rows correspond to motion state levels 1 to 3, and the columns correspond to control intention levels 0 to 3. Each cell stores a safety level identifier with a value range of integers 1 to 5.

[0108] Specifically, the lookup table is constructed by safety engineers during the vehicle development phase. The construction logic is as follows: for each combination of motion state level and control intention level, the safety sensitivity and resource requirements of in-vehicle components such as instruments, navigation, multimedia, and voice systems are analyzed under corresponding operating conditions to comprehensively derive a safety level identifier. The table is specifically distributed as follows: Motion state level 1 and control intention level 0 correspond to safety level 1; Motion state level 1 and control intention level 1 correspond to safety level 2; Motion state level 2 and control intention level 0 correspond to safety level 2; Motion state level 3 and control intention level 3 correspond to safety level 5; the remaining combinations are distributed between safety levels 3 and 4 in an increasing direction of danger. The area in the table where the safety level jumps from 2 to 5 reflects the non-linear characteristics of the mapping: when both the motion state level and control intention level are at a high level, the increase in safety level is significantly greater than the increase when only one dimension level increases. The module locates cells in the lookup table with motion state level as the row and control intention level as the column, reads the safety level identifier, and outputs it.

[0109] As another implementation, the nonlinear mapping model can also employ a trained neural network classifier. Training data is collected from real-world road conditions, including urban congestion, expressways, mountain curves, highways, and parking. Real-time values ​​of vehicle speed, steering wheel angle, gear position, and brake pedal status are recorded simultaneously. Safety engineers assign a safety level of 1 to 5 to each record based on the vehicle's condition at that moment. After normalization and encoding, approximately 80,000 samples are obtained and divided into training and validation sets at a 4:1 ratio. The network structure is a fully connected network with four inputs and five outputs. The two hidden layers have 16 and 8 neurons respectively, and both use the hyperbolic tangent function as the activation function. The output layer outputs the probability of each class using a flexible maximum transform. Training employs the cross-entropy loss function, the Adam optimizer, an initial learning rate of 0.001, a batch size of 64, and a weight decay coefficient of 0.0001. An early-stop strategy is used to determine the training termination round. After training, the weight matrix and bias vector are fixed as an array and written into the memory of the linkage control module. During runtime, the module uses the motion state level and control intention level as part of the input vector to feed forward into the network and outputs a safety level indicator.

[0110] Preferably, the determination of the motion state level adopts a two-dimensional combined lookup table, transforming vehicle speed and steering wheel angle from two independent continuous parameters into a discrete level that comprehensively reflects the vehicle's dynamics. This transformation process preserves the coupling information between parameters, ensuring that dangerous conditions such as high-speed steering are not overwhelmed by single-threshold judgments. The determination of the control intention level uses a classification decision tree to transform the two heterogeneous signals of gear position and brake pedal state into a unified quantized value of intention, removing the original signal encoding details and providing semantically clear and ordered quantized input for subsequent mapping. The mapping of the safety level identifier uses the nonlinear characteristics of a two-dimensional lookup table or neural network to generate a step-like high-level output when both the motion state level and control intention level increase simultaneously, and maintains a moderate output when only one dimension increases. This allows the system to trigger strict container isolation under truly dangerous conditions and maintain appropriate constraints under normal conditions, avoiding both insufficient safety response and excessive constraints.

[0111] Furthermore, based on the security level identifier, the corresponding capability set pruning items and resource quota restriction items are determined, and linkage control strategies are generated, including:

[0112] S501. Match the capability set trimming items in the preset capability set trimming mapping table according to the security level identifier. The capability set trimming items reflect the list of kernel capabilities removed from the target container.

[0113] S502. According to the security level identifier, match it in the preset resource quota limit mapping table to obtain the resource quota limit item, wherein the resource quota limit item reflects the upper limit of processor time and upper limit of memory usage of the target container;

[0114] S503. Combining the capability set pruning items and resource quota restriction items, a linkage control strategy is obtained.

[0115] In this embodiment, capability set pruning items are extracted from the capability set pruning mapping table using the security level identifier, and resource quota restriction items are extracted from the resource quota restriction mapping table using the same security level identifier. The two are then merged and encapsulated into a linkage control strategy.

[0116] Specifically, the linkage control module internally stores a capability set pruning mapping table. This table is generated during the system construction phase according to the principle of least privilege and then permanently stored in non-volatile memory. The principle of least privilege means that components within the container only retain the core capabilities necessary to complete their onboard functions. With each increase in security level, capabilities irrelevant to safe operation under the current driving conditions are further revoked. The mapping table uses security level identifiers 1 to 5 as array subscripts, and each array element is a list of kernel capability names. The contents of the lists corresponding to each subscript are as follows: Security level 1 corresponds to an empty list; Security level 2 corresponds to a list containing CAP_NET_RAW; Security level 3 corresponds to a list that adds CAP_SYS_PTRACE to the list of security level 2; Security level 4 corresponds to a list that adds CAP_SYS_ADMIN to the list of security level 3; and Security level 5 corresponds to a list that adds CAP_SYS_MODULE to the list of security level 4. Each capability name is consistent with the Linux kernel standard capability set definition. CAP_NET_RAW controls raw socket creation permissions, CAP_SYS_PTRACE controls system call tracing permissions, CAP_SYS_ADMIN controls file system mounting and kernel parameter modification permissions, and CAP_SYS_MODULE controls kernel module loading permissions. The module directly addresses the array using the received security level identifier as the index, copies all capability names stored in the list corresponding to that index, and outputs the result as the capability set trimmed items.

[0117] Specifically, the linkage control module internally stores a resource quota limit mapping table, which is fixed after being calibrated through resource allocation testing during the system construction phase. The calibration process is performed on the target on-board computing platform. Testers adjust the container processor time quota and memory quota downwards from 50% of the total resources in increments of 5 percentage points. After each adjustment, a typical on-board component load set corresponding to that safety level is run in the container to monitor whether any component experiences response timeouts or memory allocation failures. The minimum quota value that does not trigger functional degradation under each safety level is selected as the upper limit and written into the mapping table.

[0118] The calibrated mapping table corresponds to the following values ​​at each index: Security Level 1 corresponds to a processor time cap of 50% of total processor resources and a memory usage cap of 50% of total physical memory; Security Level 2 corresponds to a processor time cap of 40% and a memory usage cap of 40%; Security Level 3 corresponds to a processor time cap of 30% and a memory usage cap of 30%; Security Level 4 corresponds to a processor time cap of 20% and a memory usage cap of 20%; and Security Level 5 corresponds to a processor time cap of 15% and a memory usage cap of 15%. The module reads the processor time cap percentage and memory usage cap percentage stored in the corresponding row of the mapping table using the security level identifier as the index, and outputs these two percentage values ​​as resource quota limits. These percentage values ​​are converted into actual processor time quota values ​​and memory quota values ​​by the container modification module during subsequent steps, by multiplying the percentage by the platform's total processor time budget and total physical memory capacity.

[0119] Furthermore, combining capability set pruning items and resource quota limits, the output is a coordinated control policy. The module constructs a policy data structure in memory, containing three members: a kernel capability name list member pointing to a copy of the capability set pruning items, a processor time limit member storing the percentage of the processor time limit from the resource quota limits, and a memory usage limit member storing the percentage of the memory usage limit from the resource quota limits. After the structure is constructed, the module passes its address to the container modification module, completing the generation and transmission of the coordinated control policy.

[0120] Preferably, the capability set trimming mapping table is constructed incrementally at each level. Each security level only adds capability items to be trimmed based on the previous level. The trimming differences between levels are intuitively visible, and the capability tightening path can be traced back level by level during system auditing or security verification. The percentage values ​​of the resource quota limit mapping table are calibrated through progressive load testing rather than theoretical estimation. There is a verified correspondence between the quota upper limit under each level and the actual operating requirements of the component, avoiding the problem of the security level being ineffective due to excessively high quota settings or the component frequently triggering resource throttling due to excessively low quota settings. Both capability set trimming items and resource quota limit items are extracted from their respective mapping tables using the same security level identifier as an index. The generation paths of the two are fully coupled in terms of index variables, eliminating the window of mismatch between permission constraints and resource constraints that may be introduced by separate decisions from the source.

[0121] Furthermore, according to the linkage control strategy, within the same kernel transaction in which the target container runs, the target container's capability set and resource quotas are synchronously changed to obtain an updated target container, including:

[0122] S601. According to the linkage control strategy, after the same kernel transaction is started, the target container is put into a frozen state to prevent the process in the target container from being scheduled and executed.

[0123] S602. In the frozen state, modify the capability set configuration and resource quota configuration corresponding to the target container;

[0124] S603. After the modification is completed, unfreeze the target container and commit the same kernel transaction to obtain the updated target container.

[0125] In this embodiment, freezing the target container blocks process scheduling. While frozen, the capability set and resource quotas are modified synchronously. The container is then unfrozen, and the transaction is committed to obtain the updated target container. After receiving the linkage control policy, the container change module initiates a transactional control session with the container manager. The container manager assigns a transaction identifier to this session and creates a transaction flag file in a temporary directory to record the session state. The container manager locates the control group path corresponding to the target container and writes the value 1 to the cgroup.freeze file under that control group. cgroup.freeze is a freeze control node provided by the kernel control group interface. Writing 1 triggers the kernel to remove all processes within that control group from the ready and run queues. The process's task_struct state is marked as uninterruptible sleep, and the kernel scheduler will not select these processes in subsequent scheduling cycles. The container manager reads the frozen field in the cgroup.events file under the control group in a polling manner. This field is a status indicator bit set by the kernel after the freeze operation is completed. When the value of this field is read as 1, it confirms that the target container has entered the frozen state. The container manager updates the status field in the transaction flag file to frozen and returns a freeze completion confirmation to the container change module.

[0126] Furthermore, during the frozen state, the container change module performs write operations on the target container's capability set configuration file and resource quota configuration file. The capability set configuration file is located in the container runtime configuration directory, with the filename being a pseudo-file of the capability set associated with the container identifier. The file content consists of whitespace-separated strings of kernel capability names. The module reads the current content of this file into a memory buffer, iterates through the capability set pruning item list in the linkage control policy, performs string matching and deletion on each capability name in the buffer, and after deletion, overwrites the remaining content of the buffer back to the capability set configuration file.

[0127] Writing resource quota configuration files involves two control group nodes: cpu.max and memory.max. The cpu.max file accepts two space-separated integers representing the allowed processor time in microseconds per cycle and the cycle length in microseconds, respectively. The percentage of maximum processor time in the resource quota limits is converted to this format by dividing the percentage by 100 and multiplying by the cycle length to obtain the time quota in microseconds. The cycle length uses the kernel default of 100,000 microseconds. The time quota and cycle length are then written to cpu.max. The memory.max file accepts a single integer representing the maximum memory usage in bytes. The module multiplies the maximum memory usage percentage by the total physical memory capacity of the onboard computing platform, obtained from the sysfs node exposed by the kernel. The product is written to memory.max in bytes.

[0128] As an optional implementation, the order of the two write operations is determined by the direction of security level elevation. The current security level identifier is obtained from the security level identifier field associated with the linkage control policy, and the currently effective security level identifier of the target container is read from the container manager's status record and compared. When the current security level identifier indicates a higher level than the current level, the capability set configuration file is written first, followed by the resource quota configuration file. This writing order ensures that in a tightening scenario, permission channels are closed first before resource compression. When the current security level identifier indicates a lower level than the current level, the resource quota configuration file is written first, followed by the capability set configuration file. This writing order ensures that in a relaxed scenario, resource supply is restored first before permission channels are reopened. Both write operations are completed under the condition that the target container process remains frozen.

[0129] Furthermore, after confirming that both configuration file write operations have returned success status codes, the container change module issues a defreezing command to the container manager. The container manager writes the value 0 to the cgroup.freeze file under the target container control group. Upon receiving the write, the kernel iterates through all processes under that control group, restoring the process state from uninterruptible sleep to runnable state, and re-adds the process to the scheduler's ready queue. The container manager polls the frozen field of the cgroup.events file; when it reads a value of 0, it confirms the defreezing is complete, and the process within the container resumes execution. The capability set seen by the defreezed process is determined by the modified capability set configuration file, and the available processor time and memory limits are determined by the modified cpu.max and memory.max files. The container manager updates the transaction flag file status to committed, releases transaction identifiers and temporary resources, and returns the identifier of the target container to the container change module. The container change module then passes this identifier to the component runtime control module.

[0130] Preferably, modifications to both the capability set configuration and the resource quota configuration are completed within the same window when the target container process is frozen by the kernel. Any observer outside the container that obtains the status information through the container status query interface or resource monitoring interface will only have the old values ​​before the change or only the new values ​​after the change. There will be no intermediate snapshot where one configuration has been updated while another has not. In the tightened scenario, the order of writing the capability set first and then the resource quota eliminates the exposure window of the permission channel when resources are still sufficient. In the relaxed scenario, the order of writing the resource quota first and then the capability set avoids process execution abnormalities caused by premature restoration of permissions before resources are available. Freezing, writing, and unfreezing are all completed using the kernel control group's native interface, without relying on user-space locks, semaphores, or inter-process synchronization mechanisms. The transaction boundary is guaranteed by the process state switching of the kernel scheduler, and the local state within the transaction cannot be observed in user space.

[0131] Furthermore, in the frozen state, modifying the capability set configuration and resource quota configuration corresponding to the target container includes:

[0132] S701. In a frozen state, compare the safety level identifier with the real-time safety level identifier corresponding to the target container.

[0133] S702. If the security level of the security level identifier is higher than the security level of the real-time security level identifier, the capability set configuration shall be trimmed and modified, and the resource quota configuration shall be tightened and modified.

[0134] S703. If the security level of the security level identifier is not higher than the security level of the real-time security level identifier, the resource quota configuration shall be relaxed and modified, and the capability set configuration shall be restored and modified.

[0135] In this embodiment, the change direction is determined based on the comparison result of the security level identifiers; tightening changes are handled when the level increases; and relaxing changes are handled when the level decreases or remains unchanged. The container change module reads the integer value of the current security level identifier from the associated field of the linkage control strategy data structure. Simultaneously, it accesses the status file under the target container control group through the container manager. This file records the security level identifier written during the previous round of synchronous changes for the target container, and the module reads this value as the real-time security level identifier. Both identifiers are encoded using integers from 1 to 5, with larger values ​​indicating stricter security constraints. A subtraction comparison is performed on the two integer values: when the value of the current security level identifier is greater than the value of the real-time security level identifier, the constraint level is determined to increase, and the change direction is tightening; when the value of the current security level identifier is less than or equal to the value of the real-time security level identifier, the constraint level is determined to decrease or remain unchanged, and the change direction is relaxing. The comparison result directly serves as the branch condition to drive the execution path selection for subsequent steps.

[0136] For tightening scenarios with increased constraint levels, the capability set configuration is first pruned and modified, followed by the resource quota configuration. The capability set pruning modification targets the target container's capability set configuration file, located in the container's runtime configuration directory, which uses whitespace to separate currently enabled kernel capability names. The file content is read into a memory buffer, and each capability name in the capability set pruning list is traversed. Matching strings are located in the buffer and deleted, removing leading and trailing whitespace delimiters to maintain formatting. After traversal, the buffer content is written back to the capability set configuration file. The resource quota configuration is then tightened, targeting the cpu.max and memory.max files under the target container's control group. The processor time limit from the resource quota restrictions is written to cpu.max, and the memory usage limit is written to memory.max. In tightening scenarios, the written quota value is less than the target container's current quota value. After writing, the kernel scheduler and memory management subsystem immediately apply the new quota to manage resources for the target container.

[0137] For relaxed scenarios where the constraint level is reduced or remains the same, the resource quota configuration is relaxed first, followed by the capability set configuration being restored. The resource quota relaxation modification also targets the `cpu.max` and `memory.max` files, writing the processor time limit from the resource quota restrictions to `cpu.max` and the memory usage limit to `memory.max`. In relaxed scenarios, the written quota value is greater than or equal to the target container's current quota value, thus increasing the target container's available processor time and memory space. The capability set configuration is then restored, targeting the target container's capability set configuration file. The current content of the capability set configuration file is read, and the capability names in the capability set pruning list are compared with the currently enabled set of capability names. For capability names missing from the current content but present in the capability set pruning list, they are appended to the capability set configuration file to restore previously pruned kernel capabilities; capability names already present in the current content are not written again.

[0138] Preferably, by controlling the change order, the risk of transition is eliminated. In the tightening scenario, capability set pruning is executed before resource quota tightening. The kernel capability channel is closed while resources are still sufficient. The target container no longer has the privileged operation permission required to abuse resources before the resource quota compression takes effect, thus preventing the process from using the soon-to-be-revoked permissions to perform unauthorized operations during the short period when resources are still plentiful. In the relaxing scenario, resource quota relaxation is executed before capability set restoration. The processor time quota and memory limit are expanded before the permission channel is opened. The target container has sufficient resource margin when the capability is restored, thus preventing the process from triggering rate limiting or memory allocation failure due to insufficient resources after the capability is restored. Both capability set modification and resource quota modification are executed in a frozen state. The process remains unschedulable during the interval between the two modifications. After unfreezing, the process simultaneously faces the capability set and resource quota that have been fully modified and will not observe the intermediate configuration of partial modifications.

[0139] Furthermore, the target container will be updated and scheduled as a container instance in a target isolation state to control the operation of in-vehicle components, including:

[0140] S801. Reset the network access whitelist of the target container to a predefined set of communication ports corresponding to the security level identifier;

[0141] S802. Reset the device node access permissions of the target container to a predefined list of device nodes corresponding to the security level identifier.

[0142] In this embodiment, the component operation control module has a pre-built network whitelist configuration library. This configuration library is indexed by security level identifiers 1 to 5, and each entry stores a set of transport layer port numbers. The configuration library is constructed based on the communication matrix of the service components inside the vehicle platform. The communication matrix records the binding relationships between various functional components such as instrument display service, navigation data service, audio service, video service, and body control service and their service ports, and labels each port with a security attribute tag.

[0143] The classification criteria for safety attribute labels are derived from the vehicle functional safety analysis. Ports that directly support driving control and information display are classified as safety-related ports, while other ports are classified as non-safety-related ports. The narrowing path of the port number set as the safety level increases is as follows: at safety level 1, the whitelist includes all registered ports in the communication matrix; at safety level 2, video service ports are removed from the non-safety-related ports; at safety level 3, audio service ports are further removed from the non-safety-related ports; at safety level 4, Bluetooth communication service ports and wireless network service ports are further removed; at safety level 5, only instrument display service ports and body control service ports are retained.

[0144] Specifically, using the security level identifier as an index, the set of port numbers is read from the corresponding entry in the network whitelist configuration library. This is then accessed through the container runtime interface to update the target container's network namespace, where iptables rule injection is performed. The injection process is as follows: first, `iptables -F` is executed to clear all rules in the existing rule chains of the filter table; then, `iptables -P` is executed to set the policy of the three default chains to DROP; next, for each port number in the port number set, `iptables -A` is executed sequentially to append a allow rule to the OUTPUT chain. Each rule's matching conditions are: destination port equal to the port number, protocol is TCP, and action is ACCEPT; a UDP allow rule is also appended for the same port number. After rule injection, network requests issued by processes within the container are matched one by one through the OUTPUT chain. Packets destined for ports in the whitelist are allowed, while other packets are dropped by the default policy DROP.

[0145] Furthermore, the component operation control module has a pre-built device node permission configuration library. This library is indexed by security level identifiers 1 to 5, and each entry stores a pair of major and minor device numbers and device types for each device node. The configuration library is constructed based on the peripheral topology table and component functional requirement matrix of the in-vehicle computing platform. The peripheral topology table records the major device number, minor device number, and device type (character device or block device) registered by each peripheral in the kernel. The component functional requirement matrix records the list of peripherals that each in-vehicle component needs to access during normal operation. Each peripheral is divided into secure peripherals and non-secure peripherals according to its security attributes. Secure peripherals include the instrument display controller and the body gateway communication interface, while non-secure peripherals include the rear entertainment display, camera, audio input device, audio output device, Bluetooth communication interface, and wireless network communication interface. The shrinking path of the device number list as the security level increases is synchronized with the shrinking path of the port number set in step S801: at security level 1, the list includes all peripheral device numbers; at security level 2, cameras and audio input devices are removed from non-security peripherals; at security level 3, Bluetooth and wireless network communication interfaces are further removed; at security level 4, audio output devices and rear entertainment displays are further removed; at security level 5, only the device numbers of the instrument display controller and the body gateway communication interface are retained.

[0146] Furthermore, the module reads the corresponding device number list from the device node permission configuration library using the security level identifier as an index, and enters the device control group of the target container to execute permission configuration. The device control group path is located in the devices subdirectory under the corresponding control group of the target container. First, a denial rule is written to the devices.deny file, with the format of device type wildcard 'a', major device number wildcard asterisk, minor device number wildcard asterisk, and access permission wildcard 'rwm'. This rule covers all device types and all device numbers. After being written, all read, write, and execution accesses of the container to all device nodes are blocked by the kernel.

[0147] The device number list is traversed. For each device number pair in the list, an access rule is written to the devices.allow file. The rule specifies the major device number, minor device number, device type (c for character device or b for block device), and access permissions (r for read permission and w for write permission). After all access rules are injected, when a process inside the container accesses a device node in the open system call, the kernel VFS layer matches the device control group rules one by one. Access to devices whose device numbers are in the allow list is allowed, while access to devices whose device numbers are not in the allow list returns an EPERM error at the VFS layer.

[0148] Preferably, the rule injection operation for network access whitelists directly operates on the kernel netfilter framework. The rules take effect at the IP layer output point of the kernel protocol stack, and processes within the container cannot bypass them through application layer means. As the security level increases, unnecessary communication ports are closed step by step, reducing the number of paths for attackers to inject malicious data into the container through insecure service ports. The reset of device node access permissions is implemented at the kernel VFS layer through the deny and allow rules of the device control group. The control granularity reaches the level of major and minor device numbers, which is more fundamental than user-space file permission control and cannot be bypassed by the superuser within the container. The corresponding rule set is directly retrieved from the configuration library that has been solidified during the build phase using the security level identifier as an index. The number of steps and execution time of the rule injection process are fixed, and no additional delay is caused by changes in the running state within the container. The target container being updated already has network isolation and device isolation constraints that match the current driving state when it is scheduled to go online.

[0149] Furthermore, scheduling the updated target container as a container instance in a target isolation state to control the operation of in-vehicle components also includes:

[0150] S901. During the update of the target container, monitor the real-time processor utilization and memory utilization.

[0151] S902. If the occupancy rate is greater than the processor time limit in the resource quota limit, or the memory occupancy rate is greater than the memory usage limit in the resource quota limit, the target container will be marked as abnormal and the container instance will be replaced.

[0152] In this embodiment, after the component operation control module puts the target container as a container instance in target isolation into scheduling, it creates a bound monitoring task for that container instance. The monitoring task executes at a fixed period, with a period duration of 100 milliseconds in this embodiment. Within each monitoring period, the monitoring task reads the cpu.stat and memory.current files under the control group corresponding to the target container. The cpu.stat file contains a usage_usec field, which cumulatively records the processor time consumed by all processes in the control group since the container's creation, in microseconds. The monitoring task reads the current usage_usec value from cpu.stat, subtracts the baseline usage_usec value recorded in the previous monitoring period, and obtains the processor time consumption increment for the current period. This increment is divided by the monitoring period duration of 100 milliseconds to obtain the real-time processor utilization rate for the current period, expressed as a percentage. After reading, the monitoring task updates the current usage_usec value to the baseline value for the next period. The memory.current file records the total physical memory currently occupied by all processes in the control group, in bytes. The monitoring task directly reads the contents of this file to obtain the real-time memory utilization rate, in bytes. The monitoring task writes real-time processor usage and real-time memory usage to the monitoring record cache.

[0153] Furthermore, the monitoring task retrieves the processor time limit and memory usage limit from the resource quota restrictions corresponding to the target container. The processor time limit is stored as a percentage, consistent with the expression of real-time processor utilization; the memory usage limit is stored in bytes, consistent with the unit of reading values ​​from the memory.current file. The monitoring task compares the two collected values ​​with the two limits in each monitoring cycle. When the real-time processor utilization exceeds the processor time limit, or the real-time memory utilization exceeds the memory usage limit, the monitoring task determines that the target container has entered an abnormal state. Sources of this abnormality include the component process entering an infinite loop, memory leaks, or abnormal load caused by external attacks.

[0154] The status flag field of the target container in the container manager is set to an anomalous value. The container manager catches this anomalous value during status polling and initiates the container instance replacement process: An idle standby instance of the same type as the anomalous container component is selected from the container instance pool pre-created during system startup. The standby instance has completed file system initialization and is in a suspended state; no processes run in the suspended state, and no processor time is consumed. Using the anomalous container's currently effective security level identifier and linkage control policy as input, the container manager performs the synchronization change operation in step S103 on the selected standby instance. After writing the capability set configuration and resource quota configuration, the standby instance is switched from the suspended state to the running state. The container manager updates the container identifier mapping relationship in the service discovery record, pointing the service endpoint of the vehicle component carried by the anomalous container to the standby instance, so that subsequent requests to this component are routed to the standby instance. After the migration is complete, the container manager performs a destruction operation on the anomalous container, releasing the processor time quota, memory pages, and file system resources it occupies.

[0155] Preferably, processor utilization is calculated by the ratio of the increment of usage_usec in cpu.stat between adjacent cycles to the monitoring cycle. The data comes directly from the processor time accounting of the kernel control group, using the same statistical source as when the kernel scheduler imposes quota limits on containers. The latency between monitoring judgment and quota effectiveness is only one monitoring cycle. The standby instance selected for container instance replacement is configured with the same security level identifier and linkage control policy as the abnormal container, ensuring that the safety constraints of the replacement instance are consistent with the current driving state and that the security level is not changed due to the replacement operation. The standby instance is selected and configured from the pre-created pool. The replacement path does not involve image pulling or file system reconstruction. The recovery time is determined by the synchronous change operation. The path is fixed and is not affected by the system runtime load.

[0156] like Figure 2 As shown, a container-isolated on-board component operation control system is used to implement a container-isolated on-board component operation control method, including:

[0157] The data acquisition module acquires real-time driving status information from the vehicle computing platform, which includes real-time values ​​of multiple driving status parameters.

[0158] The linkage control module determines the corresponding safety level identifier based on the real-time values ​​of driving state parameters and a preset nonlinear mapping model, and generates a linkage control strategy. The linkage control strategy includes capability set pruning items and resource quota restriction items for the target container. The nonlinear mapping model reflects the nonlinear correspondence between the combination of driving state parameters and the safety level identifier.

[0159] The container change module, based on the linkage control strategy, synchronously changes the capability set and resource quota of the target container in the same kernel transaction in which the target container is running, to obtain the updated target container;

[0160] The component operation control module schedules the updated target container as a container instance in a target isolation state to control the operation of the vehicle components.

[0161] The above description is merely a preferred embodiment of this application. The scope of protection of this application is not limited to the above embodiments. All technical solutions falling within the scope of this application's concept are within the scope of protection of this application. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of this application should also be considered within the scope of protection of this application.

Claims

1. A method for controlling the operation of on-board components based on container isolation, characterized in that, include: Obtain real-time driving status information from the vehicle computing platform, which includes real-time values ​​of multiple driving status parameters; Based on the real-time values ​​of driving state parameters and a preset nonlinear mapping model, the corresponding safety level identifier is determined, and a linkage control strategy is generated. The linkage control strategy includes capability set pruning items and resource quota restriction items for the target container. The nonlinear mapping model reflects the nonlinear correspondence between the combination of driving state parameters and the safety level identifier. According to the linkage control strategy, in the same kernel transaction in which the target container is running, the capability set and resource quota of the target container are synchronously changed to obtain the updated target container; The target container is scheduled as a container instance in a target isolation state to control the operation of the vehicle components.

2. The on-board component operation control method based on container isolation according to claim 1, characterized in that, The acquisition of real-time driving status information from the vehicle computing platform includes: The system extracts message signals from different electronic control units from the controller area network bus connected to the vehicle computing platform. The message signals include vehicle speed messages, gear messages, and brake pedal status messages. The message signals are parsed and time-aligned to obtain real-time driving status information.

3. The on-board component operation control method based on container isolation according to claim 1, characterized in that, The step of determining the corresponding safety level identifier based on the real-time values ​​of driving state parameters and a preset nonlinear mapping model, and generating a linkage control strategy, includes: Based on the real-time values ​​in the driving status parameters, the motion status level and control intention level are determined, and matched in a preset nonlinear mapping model to determine the corresponding safety level identifier. Based on the security level identifier, the corresponding capability set pruning items and resource quota restriction items are determined, and linkage control strategies are generated.

4. The method for controlling the operation of on-board components based on container isolation according to claim 3, characterized in that, The process involves determining the motion state level and control intention level based on real-time values ​​of driving state parameters, matching them within a preset nonlinear mapping model, and determining the corresponding safety level identifier, including: The motion state level is determined based on the real-time values ​​of the vehicle speed parameter and the steering wheel angle parameter in the driving state parameters. The level of control intention is determined based on the real-time values ​​of the gear position parameter and the brake pedal status parameter in the driving status parameters. By combining the motion state level and the control intention level, a matching process is performed in a preset nonlinear mapping model to determine the corresponding safety level identifier.

5. The on-board component operation control method based on container isolation according to claim 4, characterized in that, Based on the security level identifier, the corresponding capability set pruning items and resource quota restriction items are determined, and a linkage control strategy is generated, including: According to the security level identifier, it is matched in the preset capability set trimming mapping table to obtain the capability set trimming item, where the capability set trimming item reflects the list of kernel capabilities removed from the target container; According to the security level identifier, it is matched in the preset resource quota limit mapping table to obtain the resource quota limit item, which reflects the upper limit of processor time and memory usage of the target container; By combining the capability set pruning items and resource quota restriction items, a linkage control strategy is obtained.

6. The on-board component operation control method based on container isolation according to claim 1, characterized in that, According to the linkage control strategy, within the same kernel transaction where the target container is running, the capability set and resource quota of the target container are synchronously changed to obtain the updated target container, including: According to the linkage control strategy, after the same kernel transaction is started, the target container is put into a frozen state to prevent the process in the target container from being scheduled and executed. In the frozen state, modify the capability set configuration and resource quota configuration corresponding to the target container; After the modifications are completed, the target container is unfrozen and the same kernel transaction is committed to obtain the updated target container.

7. The on-board component operation control method based on container isolation according to claim 6, characterized in that, In the frozen state, modify the capability set configuration and resource quota configuration corresponding to the target container, including: In a frozen state, compare the safety level identifier with the real-time safety level identifier corresponding to the target container; If the security level of the security level identifier is higher than that of the real-time security level identifier, the capability set configuration will be trimmed and modified, and the resource quota configuration will be tightened. If the security level of the security level identifier is not higher than the security level of the real-time security level identifier, the resource quota configuration will be relaxed and modified, and the capability set configuration will be restored and modified.

8. The on-board component operation control method based on container isolation according to claim 1, characterized in that, The step of scheduling the updated target container as a container instance in a target isolation state to control the operation of the vehicle components includes: Reset the network access whitelist of the target container to a predefined set of communication ports corresponding to the security level identifier; Reset the device node access permissions of the target container to a predefined list of device nodes corresponding to the security level identifier.

9. The on-board component operation control method based on container isolation according to claim 8, characterized in that, The step of scheduling the updated target container as a container instance in a target isolation state to control the operation of the vehicle components also includes: During the update of the target container, monitor the real-time processor utilization and memory utilization. If the occupancy rate exceeds the processor time limit in the resource quota limit, or the memory occupancy rate exceeds the memory usage limit in the resource quota limit, the target container will be marked as abnormal, and the container instance will be replaced.

10. A container-isolated on-board component operation control system, characterized in that, The method for implementing the container-isolated vehicle component operation control method as described in any one of claims 1 to 9 includes: The data acquisition module acquires real-time driving status information from the vehicle computing platform, which includes real-time values ​​of multiple driving status parameters. The linkage control module determines the corresponding safety level identifier based on the real-time values ​​of driving state parameters and a preset nonlinear mapping model, and generates a linkage control strategy. The linkage control strategy includes capability set pruning items and resource quota restriction items for the target container. The nonlinear mapping model reflects the nonlinear correspondence between the combination of driving state parameters and the safety level identifier. The container change module, based on the linkage control strategy, synchronously changes the capability set and resource quota of the target container in the same kernel transaction in which the target container is running, to obtain the updated target container; The component operation control module schedules the updated target container as a container instance in a target isolation state to control the operation of the vehicle components.

Images