Multi-wheel vehicle tire inflation and deflation control method, device, equipment and medium

Abstract

The application discloses a kind of control method, device, equipment and medium of multi-wheel vehicle tire inflation and deflation, is related to tire inflation and deflation control technical field, comprising: the multiple wheel edge devices corresponding to multiple tires are divided into at least one wheel edge group, and mutual exclusion lock is established in group, ensure that any moment in the same group only allows one wheel edge device to be in inflation and deflation execution state;Collect the state information of each wheel edge device to determine whether to generate the inflation and deflation request of tire to be inflated and deflated;In response to the request, query the mutual exclusion lock state, judge whether to issue inflation and deflation control command;For the control command that has been issued, establish command slot, receive execution information to confirm execution progress;After confirming execution progress enters working state, keep the occupation of mutual exclusion lock, continuously receive the execution information returned by current wheel edge device, until confirming execution progress enters completed working state, release mutual exclusion lock.The application improves the control precision of multi-wheel vehicle tire inflation and deflation.

Description

Technical Field

[0001] This application relates to the field of tire inflation and deflation control technology, specifically to a method, device, equipment, and medium for controlling the inflation and deflation of tires in multi-wheeled vehicles. Background Technology

[0002] Currently, multi-tire vehicles are typically equipped with tire pressure monitoring and automatic inflation / deflation systems. These systems collect pressure and temperature data via wheel-side sensors, and the main control unit determines whether to inflate or deflate each tire. However, existing systems still have the following shortcomings when dealing with multi-wheel-side coordinated control: When multiple wheel-side devices share the same air supply circuit or vehicle power resources, if two or more wheel-side devices in the same group simultaneously perform inflation or deflation actions, not only will fluctuations in air circuit pressure lead to insufficient air supply or pressure disturbances in each actuator, but it will also cause excessive instantaneous power load, affecting system stability and execution accuracy. Furthermore, the main control unit and wheel-side devices typically use wireless half-duplex communication. In actual working environments, there are situations such as busy channels, data packet loss, or lost acknowledgment frames. If the main control unit only sends results or status updates based on a single command, the system will be compromised. If control is released immediately upon reporting a status, the status of the activated wheel-side equipment may become unclear due to the inability to effectively track the actual execution progress of commands, leading to control confusion. During the intervals between inflation and deflation, pressure stabilization after the action is completed, or mode switching, the wheel-side equipment may briefly report an idle status. If the master controller misjudges this momentary idleness as the completion of the action and prematurely releases control over the wheel-side equipment and its group resources, other wheel-side equipment in the same group may be started prematurely before the wheel-side equipment has completely stopped physical movement, causing mutual interference in the inflation and deflation process, reducing control accuracy, and even posing safety risks. Summary of the Invention

[0003] This application provides a method, device, equipment, and medium for controlling the inflation and deflation of tires in multi-wheeled vehicles, which can solve the technical problem of low control accuracy of tire inflation and deflation in multi-wheeled vehicles in the prior art.

[0004] In a first aspect, embodiments of this application provide a method for controlling the inflation and deflation of tires in a multi-wheeled vehicle, the method comprising: The multiple wheel-side devices corresponding to multiple tires are divided into at least one wheel-side group, and a mutual exclusion lock is established within the group to ensure that only one wheel-side device is allowed to be in the inflation / deflation execution state at any given time within the same group. Collect the status information of each wheel-side device, and determine whether to generate an inflation / deflation request for the tire to be inflated / deflated based on the status information; In response to the request, query the mutex lock status of the wheel side group to which the current wheel side device of the tire to be inflated / deflated belongs, and determine whether to issue an inflation / deflation control command based on the mutex lock status; Create a command slot for the issued control command, record the issuance time and retry count of the control command, and receive the execution information returned by the current wheel-side device within the command validity period to confirm the execution progress; After confirming that the execution progress has entered the working state, the mutex lock is held and the execution information returned by the current wheel-side device is continuously received until the execution progress is confirmed to have entered the completed working state, at which point the mutex lock is released.

[0005] In conjunction with the first aspect, in one implementation, the step of collecting status information of each wheel-side device and determining whether to generate an inflation / deflation request for a tire to be inflated or deflated based on the status information includes: Collect status information for each wheel-side device, including at least tire pressure value, low pressure alarm, or high pressure alarm. Based on this status information, determine whether to generate an inflation / deflation request for the tire to be inflated / deflated. If the collected tire pressure value is lower than the preset low pressure inflation threshold and the low pressure state reaches the preset number of times within the preset time interval, or if a low pressure alarm is collected, an inflation request is generated. If the collected tire pressure value is higher than the preset high-pressure deflation threshold or a high-pressure alarm is detected, a deflation request will be generated.

[0006] In conjunction with the first aspect, in one implementation, the step of querying the mutex lock status of the wheelside group to which the current wheelside device corresponding to the tire to be inflated / deflated belongs, and determining whether to issue an inflation / deflation control command based on the mutex lock status, includes: Query the mutual exclusion lock status of the wheel end group to which the current wheel end device belongs, corresponding to the tire to be inflated or deflated. Determine whether to issue an inflation / deflation control command based on the mutual exclusion lock status: If the mutex is in the released state, the corresponding inflation control command or deflation control command is issued to the current wheel-side device according to the inflation request or deflation request, and the current wheel-side device is marked as the current execution device of its wheel-side group; If the mutex lock is in an occupied state, the inflation or deflation request will be stored in the request queue of the wheel side group to which the current wheel side device belongs and wait.

[0007] In conjunction with the first aspect, in one implementation, storing the inflation or deflation request in the request queue of the wheel rim group to which the current wheel rim device belongs for waiting includes: Allocate a fixed request queue slot to each wheel-side device; If there are already unprocessed inflation or deflation requests in the request queue of the same wheel-side device, the currently stored inflation or deflation request will overwrite the unprocessed inflation or deflation request. Requests from different wheel-side devices are stored in the corresponding request queue slots in the order in which the requests were generated.

[0008] In conjunction with the first aspect, in one implementation, the step of establishing a command slot for the issued control command, recording the issuance time and retry count of the control command, and receiving execution information returned by the current wheel-side device within the command validity period to confirm the execution progress includes: Establish command slots for the issued control commands, and set the corresponding command slots to a waiting confirmation state after the control command is issued for the first time, and determine whether the confirmation information returned by the current wheel-side device is received within the preset retry interval; If so, the command slot corresponding to the control command is switched from the waiting confirmation state to the confirmed state, the repeated sending of the control command is stopped, the mutex lock of the wheel group to which the current wheel-side device belongs is maintained, and the status information of the current wheel-side device is collected to confirm the execution progress. If not, the control command is resent and the retry count is incremented by one. When the retry count exceeds the preset retry count, the command slot corresponding to the control command is set to a failure state, and isolation protection is applied to the wheel group to which the current wheel-side device belongs.

[0009] In conjunction with the first aspect, in one implementation, applying isolation protection to the wheel rim group to which the current wheel rim device belongs includes: Set an isolation time window for the wheel side group to which the current wheel side equipment belongs, and prevent all wheel side equipment in the group from performing new inflation / deflation actions within the isolation time window; If no valid status information is received from the current wheel-side device after the isolation time window expires, the current wheel-side device will be marked as being in a suspected working state. In this suspected working state, continue to prevent other wheel-side devices in the group from performing inflation / deflation actions until a valid status information of the current wheel-side device is received or the suspected working state times out.

[0010] In conjunction with the first aspect, in one implementation, after confirming that the execution progress has entered the working state, the mutex lock is maintained, and execution information returned by the current wheel-side device is continuously received until the execution progress is confirmed to have entered the completed working state, at which point the mutex lock is released, including: Once the execution progress has entered the working state, voltage stabilization state, or rest state, confirm that the control command has been executed and stop repeatedly sending the control command. Maintain the holding of the mutex lock and continuously collect the status information reported by the current wheel-side device until the execution progress enters the idle state, the work is completed, or the fault state is received; Upon receiving an idle state, a completed work state, or a fault state, the mutex lock is released.

[0011] Secondly, embodiments of this application provide a control device for inflating and deflating tires of a multi-wheeled vehicle, the control device comprising: The partitioning module is used to divide the multiple wheel-side devices corresponding to multiple tires into at least one wheel-side group, and establish a mutual exclusion lock within the group to ensure that only one wheel-side device is allowed to be in the inflation / deflation execution state at any given time within the same group. The data acquisition module is used to collect the status information of each wheel-side device and determine whether to generate an inflation / deflation request for the tire to be inflated or deflated based on the status information. The issuing module is used to respond to inflation / deflation requests, query the mutex lock status of the wheel side group to which the current wheel side device of the tire to be inflated / deflated belongs, and determine whether to issue an inflation / deflation control command based on the mutex lock status. The module is used to create command slots for issued control commands, record the issuance time and retry count of the control command, and receive the execution information returned by the current wheel-side device within the command validity period to confirm the execution progress. The confirmation module is used to maintain the mutex lock after confirming that the execution progress has entered the working state. It continuously receives the execution information returned by the current wheel-side device until it confirms that the execution progress has entered the completed working state, and then releases the mutex lock.

[0012] Thirdly, embodiments of this application provide a control device for inflating and deflating multi-wheeled vehicle tires. The control device includes a processor, a memory, and a control program for inflating and deflating multi-wheeled vehicle tires stored in the memory and executable by the processor. When the control program for inflating and deflating multi-wheeled vehicle tires is executed by the processor, it implements the steps of the control method for inflating and deflating multi-wheeled vehicle tires as described in any of the above embodiments.

[0013] Fourthly, embodiments of this application provide a computer-readable storage medium storing a control program for inflating and deflating multi-wheeled vehicle tires. When executed by a processor, the control program implements the steps of the control method for inflating and deflating multi-wheeled vehicle tires as described in any of the above embodiments.

[0014] The beneficial effects of the technical solutions provided in this application include: This embodiment of the application ensures that only one wheel-side device in the same group is allowed to be in the inflation / deflation execution state at any given time by grouping the wheel-side devices and establishing mutual exclusion locks within the group. This effectively avoids mutual interference of air circuit pressure and excessive instantaneous load caused by the simultaneous operation of multiple devices on the same air circuit or power supply branch, thus guaranteeing the execution accuracy and system stability of the inflation / deflation process. This embodiment of the application also establishes command slots for issued control commands, recording the issuance time and retry count. This allows the main controller to continuously track the sending history and current status of each command, accurately determining whether the command has been received by the wheel-side device, and avoiding premature release of the mutual exclusion lock or unclear command status due to unreliable communication. Furthermore, this embodiment of the application maintains the mutual exclusion lock after confirming that the execution progress has entered the working state, and only releases the lock after confirming that the execution progress has entered the completed working state. This prevents the main controller from misjudging the completion of the action due to the brief idle state reported by the wheel-side device during the inflation / deflation interval or the stabilization process after the action is completed. This avoids mutual interference and control chaos in the inflation / deflation process caused by premature activation of other wheel-side devices in the same group. Attached Figure Description

[0015] Figure 1 A schematic flowchart illustrating the control method for inflating and deflating multi-wheeled vehicle tires provided in an embodiment of this application; Figure 2 This is a network architecture diagram of a control inflation / deflation system provided in an embodiment of this application; Figure 3 This application provides an embodiment of an automatic inflation / deflation process flowchart for a main control device. Figure 4 A flowchart of group mutual exclusion scheduling provided in an embodiment of this application; Figure 5 A control command confirmation, retry, and exception protection status diagram provided in an embodiment of this application; Figure 6 A schematic diagram of the functional modules of the control device for inflating and deflating tires of a multi-wheeled vehicle provided in an embodiment of this application. Detailed Implementation

[0016] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0017] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0018] This application provides a method, apparatus, device, and medium for controlling the inflation and deflation of multi-wheeled vehicle tires, which can solve the technical problem of low control accuracy of multi-wheeled vehicle tire inflation and deflation in the prior art. In a first aspect, embodiments of this application provide a method for controlling the inflation and deflation of multi-wheeled vehicle tires.

[0019] In one embodiment, reference is made to Figure 1 , Figure 1 This is a flowchart illustrating the control method for inflating and deflating multi-wheeled vehicle tires provided in an embodiment of this application. Figure 1 As shown, the method for controlling the inflation and deflation of multi-wheeled vehicle tires specifically includes the following steps: Step S1: Divide the multiple wheel-side devices corresponding to multiple tires into at least one wheel-side group, and establish a mutual exclusion lock within the group to ensure that only one wheel-side device is allowed to be in the inflation / deflation execution state at any given time within the same group.

[0020] Specifically, in this embodiment, the execution entity is a main control device. The main control device divides all wheel-side devices into one or more wheel-side groups based on their installation location on the vehicle, their axle affix, shared air circuit, and power supply topology. Each wheel-side group contains at least two wheel-side devices. Only one wheel-side device within the same group is allowed to be in an inflation or deflation state at any given time, and different wheel-side groups can be independently scheduled. Each wheel-side device includes a pressure acquisition unit, a status acquisition unit, a wheel-side control unit, and an inflation or deflation actuator.

[0021] A mutex lock is specifically a resource occupancy marker. Its data structure includes a locked status bit and an identifier of the wheel-side device currently holding the lock. When the mutex lock is in the released state, the master control device allows the issuance of inflation / deflation control commands to the target wheel-side devices in the group, and simultaneously locks the mutex lock, recording the identifier of the wheel-side device currently holding the lock. When the mutex lock is in the locked state, the master control device refuses to issue new inflation / deflation control commands to any wheel-side device in the group. The release of the mutex lock is only executed by the master control device after the wheel-side device currently holding the lock has completed all inflation / deflation actions and reported the completion status. After release, the group returns to a schedulable state. This ensures that only one device in the same wheel-side group performs inflation or deflation at any given time, avoiding safety risks associated with shared gas pressure interference, excessive power supply load, and simultaneous operation of multiple actuators.

[0022] Step S2: Collect the status information of each wheel-side device, and determine whether to generate an inflation / deflation request for the tire to be inflated or deflated based on the status information.

[0023] In this embodiment of the application, step S2 specifically includes the following steps: Step S21: Collect the status information of each wheel-side device. The status information includes at least the tire pressure value, low pressure alarm or high pressure alarm. Based on the status information, determine whether to generate an inflation / deflation request for the tire to be inflated or deflated. If the collected tire pressure value is lower than the preset low pressure inflation threshold and the low pressure state reaches the preset number of times within the preset time interval, or a low pressure alarm is collected, proceed to step S22. If the collected tire pressure value is higher than the preset high pressure deflation threshold or a high pressure alarm is collected, proceed to step S23. Step S22: Generate an inflation request; Step S23: Generate a venting request.

[0024] Specifically, the status information includes heartbeat frames and status reporting frames. The heartbeat frame carries the heartbeat count, wheel-side status, alarm bits, and source address. The status reporting frame carries tire pressure, temperature, pump / valve status, wheel-side status, alarm information, and source address. The main controller identifies the wheel-side equipment through the source address and updates the online flag, sensor cache, heartbeat timestamp, and heartbeat pause count.

[0025] In normal operating mode, the main control equipment performs the following checks based on the information in the most recent valid status report frame received from the current wheel-side equipment: Whether the wheel-side equipment is currently in an idle state (only if the wheel-side equipment is not currently in an inflation, inflation stabilization, inflation rest, deflation, deflation stabilization, deflation rest, or fault state can it proceed to the next step); Whether all pumps and valves are in a closed state (only if both the pump and solenoid valve are not open can it proceed to the next step); Pressure threshold validity check: The main control equipment checks whether the low-pressure inflation threshold and high-pressure deflation threshold corresponding to the current wheel-side equipment are correctly configured and active to avoid incorrect judgments due to missing or invalid threshold parameters; Inflation / deflation condition determination: The tire pressure measurement value in the status report frame is compared with the low-pressure inflation threshold and high-pressure deflation threshold respectively to determine whether the low-pressure inflation condition or high-pressure deflation condition is met. After all four conditions are met, the main control equipment enters the formal triggering logic for the inflation / deflation request.

[0026] The main control device extracts the tire pressure value corresponding to the current wheel-side device from the status information and compares it with a pre-stored low-pressure inflation threshold. If the tire pressure value is lower than the low-pressure inflation threshold, it further obtains the historical tire pressure values ​​corresponding to the wheel-side device in multiple historical reporting cycles, and determines whether the low-pressure state has been reached a preset number of times within a preset time interval. If so, the low-pressure state is determined to be a continuous and real low pressure, rather than a momentary disturbance, and an inflation request is generated for the wheel-side device. If the main control device directly extracts a low-pressure alarm flag from the status information, an inflation request is generated immediately regardless of the tire pressure measurement value. This avoids the main control device erroneously triggering inflation action due to a single abnormal sampling value, reduces the frequency of unnecessary actuator actions, and extends the service life of the wheel-side device.

[0027] Step S3: In response to the request, query the mutex lock status of the wheel side group to which the current wheel side device belongs to the tire to be inflated or deflated belongs, and determine whether to issue an inflation / deflation control command based on the mutex lock status.

[0028] In this embodiment of the application, step S3, which involves querying the mutex lock status of the wheelside group to which the current wheelside device belongs, and determining whether to issue an inflation / deflation control command based on the mutex lock status, specifically includes the following steps: Step S31: Query the mutex lock status of the wheel side group to which the current wheel side device belongs, corresponding to the tire to be inflated or deflated. Determine whether to issue an inflation / deflation control command based on the mutex lock status. If the mutex lock is in the released state, proceed to step S32. If the mutex lock is in the occupied state, proceed to step S33.

[0029] Specifically, after receiving the inflation or deflation request transmitted in step S2, the main control device first queries the group configuration table stored locally to find the wheel rim group number to which the target wheel rim device belongs, as well as the mutex lock data structure corresponding to the wheel rim group, based on the target wheel rim device identifier carried in the request.

[0030] Step S32: Issue the corresponding inflation control command or deflation control command to the current wheel-side device according to the inflation request or deflation request, and mark the current wheel-side device as the current execution device of its wheel-side group.

[0031] Specifically, when the mutex lock status bit is set to "released," it indicates that there are no wheel-side devices currently performing inflation / deflation operations within the wheel-side group, and the group resources are in an allocable state. The main control device issues the corresponding inflation or deflation control command to the current wheel-side device based on the inflation or deflation request, switches the mutex lock status bit from "released" to "occupied," and writes the device identifier of the target wheel-side device into the occupying device identifier field of the mutex lock. Simultaneously, in the locally stored group active device record, the target wheel-side device is marked as the currently executing device in that wheel-side group. This record is used to locate the wheel-side device currently holding the mutex lock in subsequent steps.

[0032] Step S33: Store the inflation or deflation request in the request queue of the wheel side group to which the current wheel side device belongs and wait.

[0033] Specifically, when the mutex lock status bit is set to occupied, it means that there is already a wheel-side device in the current wheel-side group that is performing an inflation / deflation operation, and the group resources are in an unallocable state.

[0034] In this embodiment of the application, step S33 specifically includes the following steps: Step S331: Assign a fixed request queue slot to each wheel-side device; Step S332: If there are already unprocessed inflation or deflation requests in the request queue of the same wheel-side device, the currently stored inflation or deflation request will overwrite the unprocessed inflation or deflation request. Step S333: Store the requests from different wheel-side devices into the corresponding request queue slots in the order of their generation time.

[0035] Specifically, when the mutex lock status is "occupied," the master control device writes the current request into the request queue of the wheel-side group according to a fixed slot. The request queue is a FIFO data structure maintained by the wheel-side group, and each slot in the queue corresponds to one wheel-side device within the group. If a previously stored but unscheduled request already exists in the queue for the same wheel-side device, the master control device overwrites the old request with the new request, preventing expired requests from accumulating in the queue. If no old request exists in the queue for the same wheel-side device, the current request is written into the corresponding slot, and the request's generation timestamp is recorded. This ensures that all wheel-side devices requiring inflation or deflation can obtain execution opportunities in the order in which requests are generated, and requests are not lost due to scheduling thresholds being occupied.

[0036] Step S4: Create a command slot for the issued control command, record the issuance time and retry count of the control command, and receive the execution information returned by the current wheel-side device within the command validity period to confirm the execution progress.

[0037] In this embodiment of the application, step S4 specifically includes the following steps: Step S41: Create a command slot for the issued control command, and after the control command is issued for the first time, set the corresponding command slot to a waiting confirmation state, and determine whether confirmation information is received from the current wheel-side device within the preset retry interval. If yes, proceed to step S42; otherwise, proceed to step S43.

[0038] Specifically, a command slot includes at least the target address, target channel, command word, subcommand, number of retries, first transmission time, most recent transmission time, and slot status. The slot status includes at least three status values: waiting for acknowledgment, acknowledged, and failed.

[0039] After the control command is first sent to the target wheel rim device via the wireless communication link, the master control device immediately sets the slot status of the command tracking slot corresponding to the command to a waiting-for-acknowledgment state, records the first transmission timestamp and the most recent transmission timestamp, and initializes the current retry count to zero. Subsequently, the master control device starts a timed scan with a preset retry interval, checking whether the command tracking slot has received acknowledgment information from the target wheel rim device at each time the timer expires. The acknowledgment information is a response frame returned by the wheel rim device via the wireless link after successfully receiving the control command. This response frame contains at least the command word, sub-command, and execution result code corresponding to the command frame. Furthermore, after the wheel rim device completes inflation or deflation, it reports a completion notification and source address. The master control device accurately locates the wheel rim based on the source address and updates the cache status based on pressure, temperature, and sub-commands.

[0040] Step S42: Switch the command slot corresponding to the control command from the waiting confirmation state to the confirmed state, stop repeatedly sending the control command, continue to maintain the occupancy of the mutex lock of the wheel side group to which the current wheel side device belongs, and collect the status information of the current wheel side device to confirm the execution progress.

[0041] Specifically, if a confirmation message is received from the target wheel-side device within the preset retry interval, the master control device switches the slot status of the current command tracking slot from the waiting confirmation state to the confirmed state, indicating that the master control device has learned that the wheel-side device has successfully received the control command, and stops periodically retransmitting the control command. The master control device continues to maintain the occupancy state of the mutex lock of the wheel-side group to which the current wheel-side device belongs, and continues to receive the status information returned by the current wheel-side device in a periodic manner. The execution progress of the control command is confirmed by parsing the current working status field of the wheel-side device in the status information. If the command is an inflation command, the master control device confirms that the inflation command is in progress when the current working status of the wheel-side device in the status information is in inflation operation, inflation pressure stabilization, or inflation rest. If the command is a deflation command, the master control device confirms that the current working status of the wheel-side device in the status information is in deflation operation, deflation pressure stabilization, or deflation rest.

[0042] Step S43: Resend the control command and increment the retry count by one. When the retry count exceeds the preset retry count, set the command slot corresponding to the control command to the failure state and apply isolation protection to the wheel group to which the current wheel-side device belongs.

[0043] Specifically, if no confirmation is received from the target wheel-side device within the preset retry interval, the master control device retransmits the control command via the wireless communication link and increments the retry count in the current command tracking slot by one. After retransmission, the most recent transmission timestamp is updated to the time of this retransmission, and the slot status remains in the waiting-for-confirmation state, awaiting confirmation upon arrival of the next retry interval. After each retransmission, the master control device compares the current retry count with the preset maximum retry count threshold. If the current retry count does not exceed the preset maximum retry count, it continues to wait for the next retry interval and performs a new round of confirmation. If the current retry count exceeds the preset retry count, retransmission stops, the slot status of the command tracking slot is switched from the waiting-for-confirmation state to the failure state, and isolation protection is applied to the wheel-side group to which the current wheel-side device belongs.

[0044] This avoids the scheduling uncertainty caused by the main control device not knowing whether the command has been delivered, and also avoids continuing to occupy the wireless channel for repeated transmission when the command has been successfully delivered, reducing the invalid communication load of the wireless link and improving the utilization efficiency of channel resources.

[0045] In this embodiment of the application, step S43, which involves applying isolation protection to the wheel group to which the current wheel-side device belongs, specifically includes the following steps: Step S431: Set an isolation time window for the wheel side group to which the current wheel side equipment belongs, and prevent all wheel side equipment in the group from performing new inflation / deflation actions within the isolation time window.

[0046] Specifically, within the isolation time window, the master control device does not release the mutex lock of the wheel side group, and the mutex lock remains in an occupied state. This avoids the risk of concurrent execution in the same group caused by the master control device releasing the mutex lock prematurely due to communication instantaneous recovery delay or loss of acknowledgment frames.

[0047] Step S432: If no valid status information is received from the current wheel-side device after the isolation time window expires, the current wheel-side device is marked as being in a suspected working state.

[0048] Specifically, valid status information includes heartbeat frames or status reporting frames. The criteria for determination are that the source address in the frame matches the address of the target wheel-side device, and the current operating status field of the wheel-side device in the frame is one of the valid status values. If no such valid status information is received within the isolation time window, it indicates that the target wheel-side device has not yet restored its communication capability within the isolation time window, and the current wheel-side device is marked as being in a suspected operating state. A suspected operating state indicates that the master control device believes the wheel-side device may be undergoing the physical process of inflation / deflation.

[0049] Step S433: In this suspected working state, continue to prevent other wheel-side devices in the group from performing inflation / deflation actions until a valid status information of the current wheel-side device is received or the suspected working state times out.

[0050] Specifically, the master control device continues to prevent all wheel-side devices within the wheel-side device's group from performing new inflation / deflation actions. Once the master control device confirms that the target wheel-side device has resumed communication via a heartbeat frame or status reporting frame, it then performs the corresponding processing based on the actual value of the wheel-side device's current operating status field in the status information. If the status is idle or faulty, it is determined that the target wheel-side device is not in a physically operating state, and the master control device clears the suspected operating flag and releases the mutex lock. If the status is any of the following: inflation operation, inflation stabilization, inflation rest, deflation operation, deflation stabilization, or deflation rest, it is determined that the target wheel-side device is indeed performing a physical action, and the master control device switches the suspected operating flag to the actual active state and takes over, continuing to maintain the mutex lock until the wheel-side device reports completion or becomes idle.

[0051] The master control device sets an independent maximum duration threshold for suspected working states, which is longer than the isolation time window. If no valid status information is received from the target wheel-side device within the maximum duration threshold, the master control device determines that the target wheel-side device may have completely gone offline or lost power, and no longer has physical execution capability. At this time, the master control device clears the suspected working state flag and releases the mutex lock, restoring the wheel-side group to a schedulable state. This provides a safety cover for scenarios where communication is interrupted but physical execution has not yet ended, and the timeout mechanism prevents permanent blocking of group resources due to complete device failure.

[0052] Step S5: After confirming that the execution progress has entered the working state, maintain the holding of the mutex lock, continuously receive the execution information returned by the current wheel-side device, and release the mutex lock after confirming that the execution progress has entered the completed working state.

[0053] In this embodiment of the application, step S5 specifically includes the following steps: Step S51: When confirming that the execution progress has entered the working state, voltage stabilization state or rest state, confirm that the control command has been executed and stop repeatedly sending the control command.

[0054] Specifically, when the main control device parses the status information and determines that the wheel-side equipment is currently in any of the following states: inflation, inflation and pressure stabilization, or inflation rest, if the issued control command is an inflation command, the main control device confirms that the inflation command has been actually executed by the wheel-side equipment, meaning the wheel-side equipment has entered the execution phase of the inflation physical action. When the main control device parses the status information and determines that the wheel-side equipment is currently in any of the following states: deflation, deflation and pressure stabilization, or deflation rest, if the issued control command is a deflation command, the main control device confirms that the deflation command has been actually executed by the wheel-side equipment. After confirming that the wheel-side equipment has entered any of the above-mentioned working states, the main control device stops repeatedly sending the control command.

[0055] Step S52: Maintain the holding of the mutex lock and continuously collect the status information reported by the current wheel-side device until the execution progress is received as entering the idle state, the work is completed, or the fault state.

[0056] Specifically, after confirming that the wheel-side device has entered a working-related state, the main control device does not release the mutex lock of the wheel-side group to which that device belongs, but continues to maintain the mutex lock's occupancy. While maintaining the mutex lock occupancy, the main control device continuously receives the status information periodically reported by the current wheel-side device, and monitors whether the execution of the control command has entered the termination stage by parsing the current working status field of the wheel-side device in the status information. After receiving each status information, the main control device determines whether the current working status belongs to an idle state, a completed working state, or a fault state. If it does not belong to any of these states, it continues to maintain the mutex lock occupancy and waits for the next frame of status information.

[0057] Step S53: Upon receiving an idle state, a completed work state, or a fault state, release the mutex lock.

[0058] Specifically, when the master control device parses the status information and determines that the current working state of the wheel-side device is idle, completed, or faulty, the master control device removes the current wheel-side device from the current execution device record of its wheel-side group, clears or marks the command tracking slot corresponding to the current wheel-side device as completed, and switches the mutex lock state of the wheel-side group to which the current wheel-side device belongs from occupied to released. After the mutex lock is released, the wheel-side group returns to the schedulable state. At this time, if there are requests waiting to be executed in the request queue of the wheel-side group, the master control device retrieves the next request from the queue in ascending order of request generation time and returns to step S3 to continue execution. If the queue is empty, the wheel-side group enters an idle waiting state until a new request arrives. This ensures the temporal continuity and logical reliability of the status determination.

[0059] Furthermore, in this embodiment, the main control device can switch between a normal automatic mode and a monitoring manual mode. When entering the monitoring manual mode, the automatic queue is cleared, and stop commands are issued preferentially to active, pending, or suspected working wheel-side devices. When switching back to normal mode from the monitoring manual mode, residual stop processes are processed first, and normal mode commands are reissued after the wheel-side device is confirmed to be idle or faulty. The stop command is sent first and then the wheel-side group is released, and the historical requests of the wheel-side device in the queue are cleared.

[0060] In one specific embodiment Figure 2 This is a network architecture diagram of a controlled inflation / deflation system provided in one embodiment of this application. See also... Figure 2 The system consists of a main control device MC and eight wheel-side devices WH#0 to WH#7. The main control device uses a GD32F30x series processor as the main control chip and is equipped with an E22 series wireless communication module. The eight wheel-side devices are divided into two groups: Group A contains dev[0] to dev[3], corresponding to WH#0 to WH#3, with communication addresses 0x0001 to 0x0004 respectively; Group B contains dev[4] to dev[7], corresponding to WH#4 to WH#7, with communication addresses 0x0005 to 0x0008 respectively. Group A and Group B are scheduled independently. At any given time, only one wheel-side device in the group is allowed to be in the inflation / deflation execution state. There are no mutual exclusion constraints between groups, and they can be executed in parallel.

[0061] The main control device and the wheel-side devices communicate via an E22 wireless module in the 433MHz band. The communication mode is point-to-point addressing half-duplex mode, and each wheel-side device identifies itself through the source address field. Uplink transmission includes heartbeat frames, status reporting frames, and completion notification frames; downlink transmission includes control command frames and configuration frames. The communication frame format is uniform: frame header (0x5), fixed identifier (0x80), command word, data length, data field, CRC16 checksum, and frame trailer (0x5A). The key command words are defined as follows: heartbeat frame command word is 0x01, status reporting frame command word is 0x02, control command frame command word is 0x03, E22 configuration frame command words are 0x10 and 0x11, and completion notification frame command word is 0x92.

[0062] Figure 3 This is a flowchart of the automatic inflation / deflation process of the main control device provided in an embodiment of this application. Figure 3In this context, ACK indicates confirmation, IDLE indicates idle state, WORK indicates working state, STABILIZE indicates stabilizing state, REST indicates resting state, and FAULT indicates fault state. After receiving heartbeat frames, status reporting frames, or completion notification frames from the wheel rims, the master controller identifies the wheel rim devices based on their source addresses and updates the online status and sensor cache. If the current mode is normal automatic and the wheel rim is idle with the pump valve closed, a pressure trigger judgment is initiated: an inflation request is generated if the tire pressure is below the low-pressure inflation threshold and confirmed continuously, or a deflation request is generated if the tire pressure is above the high-pressure deflation threshold. After generating a request, a group mutual exclusion scheduling process is entered. When idle, control commands are directly issued and command slots are filled; when the group is busy, commands are written to the queue and awaiting execution. After the wheel rim enters working, stabilizing, or resting state, the master controller continuously confirms the execution progress but maintains the group lock; the group lock is released after the wheel rim reports a completion notification or enters an idle or fault state, and the next request is scheduled in the queue.

[0063] Figure 4 A flowchart of group mutual exclusion scheduling provided for an embodiment of this application. Figure 4 In the code, WheelGroupRequestAction represents wheel-side group request processing, STOP represents a stop command, slot represents a queue slot, deviceIndex represents the wheel-side device index, requestTick represents the request timestamp, activeDevice represents an active device, active=NONE represents no active device, IsDevicePhysicallyWorking represents physical working status detection, post-action guard represents the protection period after the action is completed, DispatchNextInGroup represents scheduling the next request within the group, and WheelGroupOnActionComplete represents action completion processing. When the master controller receives an inflation, deflation, or stop request, it first determines if it is a stop command. If it is not a stop command, it checks the mutex lock status of the target wheel-side's group: if there are no active devices, no isolation period, and no physically working devices in the group, it directly issues a control command and marks the wheel-side as an active device; otherwise, it writes the request to the fixed slot queue corresponding to the wheel-side and records the request time. When the action is completed or fails, the group release process is invoked, and the next request is selected from the queue in the order of request time for scheduling. For a stop command, first send the stop command, then release the group lock, and clear the historical requests of that wheel edge from the queue.

[0064] Figure 5This diagram illustrates the control command confirmation, retry, and anomaly protection status according to an embodiment of this application. In the diagram, WAIT_CONFIRM represents the waiting-for-confirmation state, CONFIRMED represents the confirmed state, FAILED represents the failure state, suspect-working represents a suspected working flag, ACK represents a confirmation response, 0x83 is the command word for the control command arrival response, 0x02 is the command word for the status reporting frame, and 0x92 is the command word for the completion notification frame. The master controller establishes a command tracking slot for each issued control command. After a command is issued, the slot state switches from idle to waiting for confirmation. If a control command arrival response, status report, or completion notification is received from the wheel-side control command within the retry interval, the slot state switches to confirmed, retransmission stops, but the group lock remains. If no confirmation is received after the maximum number of retries, the slot state switches to failure, the group lock remains, and safety timeout protection is initiated. If an idle state is received within the safety timeout, the command is determined to be invalid, the slot is cleared, and the group is released; if no valid state is received after the timeout, the slot is forcibly cleared, and an isolation period and a suspected working flag are set. After the action is completed, a short protection period is set to prevent momentary idleness during the wheel-side stabilization process from triggering mis-scheduling of other wheel-sides in the same group. After the stop command is confirmed, the groove is cleared and the group is released directly without waiting for completion notification.

[0065] This embodiment of the application ensures that only one wheel-side device in the same group is allowed to be in the inflation / deflation execution state at any given time by grouping the wheel-side devices and establishing mutual exclusion locks within the group. This effectively avoids mutual interference of air circuit pressure and excessive instantaneous load caused by the simultaneous operation of multiple devices on the same air circuit or power supply branch, thus guaranteeing the execution accuracy and system stability of the inflation / deflation process. This embodiment of the application also establishes command slots for issued control commands, recording the issuance time and retry count. This allows the main controller to continuously track the sending history and current status of each command, accurately determining whether the command has been received by the wheel-side device, and avoiding premature release of the mutual exclusion lock or unclear command status due to unreliable communication. Furthermore, this embodiment of the application maintains the mutual exclusion lock after confirming that the execution progress has entered the working state, and only releases the lock after confirming that the execution progress has entered the completed working state. This prevents the main controller from misjudging the completion of the action due to the brief idle state reported by the wheel-side device during the inflation / deflation interval or the stabilization process after the action is completed. This avoids mutual interference and control chaos in the inflation / deflation process caused by premature activation of other wheel-side devices in the same group.

[0066] Secondly, embodiments of this application also provide a control device for inflating and deflating tires of multi-wheeled vehicles.

[0067] In one embodiment, reference is made to Figure 6 , Figure 6 A schematic diagram of the functional modules of the multi-wheel vehicle tire inflation / deflation control device provided in this application embodiment. Figure 6 As shown, the tire inflation / deflation control device for multi-wheeled vehicles includes: The partitioning module is used to divide the multiple wheel-side devices corresponding to multiple tires into at least one wheel-side group, and establish a mutual exclusion lock within the group to ensure that only one wheel-side device is allowed to be in the inflation / deflation execution state at any given time within the same group. The data acquisition module is used to collect the status information of each wheel-side device and determine whether to generate an inflation / deflation request for the tire to be inflated or deflated based on the status information. The issuing module is used to respond to inflation / deflation requests, query the mutex lock status of the wheel side group to which the current wheel side device of the tire to be inflated / deflated belongs, and determine whether to issue an inflation / deflation control command based on the mutex lock status. The module is used to create command slots for issued control commands, record the issuance time and retry count of the control command, and receive the execution information returned by the current wheel-side device within the command validity period to confirm the execution progress. The confirmation module is used to maintain the mutex lock after confirming that the execution progress has entered the working state. It continuously receives the execution information returned by the current wheel-side device until it confirms that the execution progress has entered the completed working state, and then releases the mutex lock.

[0068] The functions of each module in the above-mentioned control device for inflating and deflating multi-wheeled vehicle tires correspond to the steps in the above-mentioned control method embodiment for inflating and deflating multi-wheeled vehicle tires. Their functions and implementation processes will not be described in detail here.

[0069] Thirdly, embodiments of this application provide a control device for inflating and deflating multi-wheeled vehicle tires. The control device for inflating and deflating multi-wheeled vehicle tires includes a processor, a memory, and a control program for inflating and deflating multi-wheeled vehicle tires stored in the memory and executable by the processor. When the control program for inflating and deflating multi-wheeled vehicle tires is executed by the processor, it implements the steps of the control method for inflating and deflating multi-wheeled vehicle tires as described in any of the above embodiments.

[0070] The control equipment for inflating and deflating tires of multi-wheeled vehicles can be devices with data processing capabilities, such as personal computers (PCs), laptops, and servers.

[0071] In this embodiment of the application, the control device for inflating and deflating the tires of a multi-wheeled vehicle may include a processor, a memory, a communication interface, and a communication bus.

[0072] The communication bus can be of any type and is used to interconnect the processor, memory, and communication interface.

[0073] The communication interface includes input / output (I / O) interfaces, physical interfaces, and logical interfaces used for interconnecting internal components of the control equipment for inflating and deflating multi-wheeled vehicle tires, as well as interfaces for interconnecting the control equipment with other devices (such as other computing devices or user equipment). Physical interfaces can be Ethernet interfaces, fiber optic interfaces, ATM interfaces, etc.; user equipment can be displays, keyboards, etc.

[0074] Memory can be various types of storage media, such as random access memory (RAM), read-only memory (ROM), non-volatile RAM (NVRAM), flash memory, optical storage, hard disk, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), etc.

[0075] The processor can be a general-purpose processor, which can call the control program for inflating and deflating multi-wheeled vehicle tires stored in memory and execute the control method for inflating and deflating multi-wheeled vehicle tires provided in the embodiments of this application. For example, the general-purpose processor can be a central processing unit (CPU). The method executed when the control program for inflating and deflating multi-wheeled vehicle tires is called can be referred to in the various embodiments of the control method for inflating and deflating multi-wheeled vehicle tires of this application, and will not be repeated here.

[0076] Fourthly, embodiments of this application provide a computer-readable storage medium storing a control program for inflating and deflating multi-wheeled vehicle tires. When executed by a processor, the control program implements the steps of the control method for inflating and deflating multi-wheeled vehicle tires as described in any of the above embodiments.

[0077] This application stores a control program for inflating and deflating multi-wheeled vehicle tires on a computer-readable storage medium. When the control program for inflating and deflating multi-wheeled vehicle tires is executed by a processor, it implements the steps of the control method for inflating and deflating multi-wheeled vehicle tires as described above.

[0078] The method implemented when the control procedure for inflating and deflating the tires of a multi-wheeled vehicle is executed can be referred to in various embodiments of the control method for inflating and deflating the tires of a multi-wheeled vehicle of this application, and will not be repeated here.

[0079] It should be noted that the sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0080] The terms "comprising" and "having," and any variations thereof, in the specification, claims, and accompanying drawings of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus. The terms "first," "second," and "third," etc., are used to distinguish different objects, etc., and do not indicate a sequence, nor do they limit "first," "second," and "third" to different types.

[0081] In the description of the embodiments of this application, terms such as "exemplary," "for example," or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplary," "for example," or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary," "for example," or "for instance" is intended to present the relevant concepts in a concrete manner.

[0082] In the description of the embodiments of this application, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. The "and / or" in the text is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of this application, "multiple" means two or more.

[0083] In some processes described in the embodiments of this application, multiple operations or steps are included in a specific order. However, it should be understood that these operations or steps may not be executed in the order they appear in the embodiments of this application, or they may be executed in parallel. The sequence number of the operation is only used to distinguish different operations, and the sequence number itself does not represent any execution order. In addition, these processes may include more or fewer operations, and these operations or steps may be executed sequentially or in parallel, and these operations or steps may be combined.

[0084] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device to execute the methods described in the various embodiments of this application.

[0085] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A method for controlling the inflation and deflation of tires in a multi-wheeled vehicle, characterized in that, The method for controlling the inflation and deflation of tires on multi-wheeled vehicles includes: The multiple wheel-side devices corresponding to multiple tires are divided into at least one wheel-side group, and a mutual exclusion lock is established within the group to ensure that only one wheel-side device is allowed to be in the inflation / deflation execution state at any given time within the same group. Collect the status information of each wheel-side device, and determine whether to generate an inflation / deflation request for the tire to be inflated / deflated based on the status information; In response to the request, query the mutex lock status of the wheel side group to which the current wheel side device of the tire to be inflated / deflated belongs, and determine whether to issue an inflation / deflation control command based on the mutex lock status; Create a command slot for the issued control command, record the issuance time and retry count of the control command, and receive the execution information returned by the current wheel-side device within the command validity period to confirm the execution progress; After confirming that the execution progress has entered the working state, the mutex lock is held and the execution information returned by the current wheel-side device is continuously received until the execution progress is confirmed to have entered the completed working state, at which point the mutex lock is released.

2. The method for controlling tire inflation and deflation of multi-wheeled vehicles according to claim 1, characterized in that, The process of collecting status information from each wheel-side device and determining whether to generate an inflation / deflation request for the tire to be inflated or deflated based on the status information includes: Collect status information for each wheel-side device, including at least tire pressure value, low pressure alarm, or high pressure alarm. Based on this status information, determine whether to generate an inflation / deflation request for the tire to be inflated / deflated. If the collected tire pressure value is lower than the preset low pressure inflation threshold and the low pressure state reaches the preset number of times within the preset time interval, or if a low pressure alarm is collected, an inflation request is generated. If the collected tire pressure value is higher than the preset high-pressure deflation threshold or a high-pressure alarm is detected, a deflation request will be generated.

3. The method for controlling tire inflation and deflation of multi-wheeled vehicles according to claim 2, characterized in that, The process of querying the mutex lock status of the wheelside group to which the current wheelside device belongs, corresponding to the tire to be inflated or deflated, and determining whether to issue an inflation / deflation control command based on the mutex lock status, includes: Query the mutual exclusion lock status of the wheel end group to which the current wheel end device belongs, corresponding to the tire to be inflated or deflated. Determine whether to issue an inflation / deflation control command based on the mutual exclusion lock status: If the mutex is in the released state, the corresponding inflation control command or deflation control command is issued to the current wheel-side device according to the inflation request or deflation request, and the current wheel-side device is marked as the current execution device of its wheel-side group; If the mutex lock is in an occupied state, the inflation or deflation request will be stored in the request queue of the wheel side group to which the current wheel side device belongs and wait.

4. The method for controlling the inflation and deflation of multi-wheeled vehicle tires according to claim 3, characterized in that, The step of storing the inflation or deflation request in the request queue of the wheel side group to which the current wheel side device belongs includes: Allocate a fixed request queue slot to each wheel-side device; If there are already unprocessed inflation or deflation requests in the request queue of the same wheel-side device, the currently stored inflation or deflation request will overwrite the unprocessed inflation or deflation request. Requests from different wheel-side devices are stored in the corresponding request queue slots in the order in which the requests were generated.

5. The method for controlling tire inflation and deflation of multi-wheeled vehicles according to claim 3, characterized in that, The process of establishing command slots for issued control commands, recording the issuance time and retry count of the control commands, and receiving execution information returned by the current wheel-side device within the command validity period to confirm the execution progress includes: Establish command slots for the issued control commands, and set the corresponding command slots to a waiting confirmation state after the control command is issued for the first time, and determine whether the confirmation information returned by the current wheel-side device is received within the preset retry interval; If so, the command slot corresponding to the control command is switched from the waiting confirmation state to the confirmed state, the repeated sending of the control command is stopped, the mutex lock of the wheel group to which the current wheel-side device belongs is maintained, and the status information of the current wheel-side device is collected to confirm the execution progress. If not, the control command is resent and the retry count is incremented by one. When the retry count exceeds the preset retry count, the command slot corresponding to the control command is set to a failure state, and isolation protection is applied to the wheel group to which the current wheel-side device belongs.

6. The method for controlling tire inflation and deflation of multi-wheeled vehicles according to claim 5, characterized in that, The step of applying isolation protection to the wheel group to which the current wheel-side device belongs includes: Set an isolation time window for the wheel side group to which the current wheel side equipment belongs, and prevent all wheel side equipment in the group from performing new inflation / deflation actions within the isolation time window; If no valid status information is received from the current wheel-side device after the isolation time window expires, the current wheel-side device will be marked as being in a suspected working state. In this suspected working state, continue to prevent other wheel-side devices in the group from performing inflation / deflation actions until a valid status information of the current wheel-side device is received or the suspected working state times out.

7. The method for controlling tire inflation and deflation of multi-wheeled vehicles according to claim 3, characterized in that, After confirming that the execution progress has entered the working state, the mutex lock is maintained, and execution information returned by the current wheel-side device is continuously received until the execution progress is confirmed to have entered the completed working state, at which point the mutex lock is released, including: Once the execution progress has entered the working state, voltage stabilization state, or rest state, confirm that the control command has been executed and stop repeatedly sending the control command. Maintain the holding of the mutex lock and continuously collect the status information reported by the current wheel-side device until the execution progress enters the idle state, the work is completed, or the fault state is received; Upon receiving an idle state, a completed work state, or a fault state, the mutex lock is released.

8. A control device for inflating and deflating tires of a multi-wheeled vehicle, characterized in that, The multi-wheel vehicle tire inflation / deflation control device includes: The partitioning module is used to divide the multiple wheel-side devices corresponding to multiple tires into at least one wheel-side group, and establish a mutual exclusion lock within the group to ensure that only one wheel-side device is allowed to be in the inflation / deflation execution state at any given time within the same group. The data acquisition module is used to collect the status information of each wheel-side device and determine whether to generate an inflation / deflation request for the tire to be inflated or deflated based on the status information. The issuing module is used to respond to inflation / deflation requests, query the mutex lock status of the wheel side group to which the current wheel side device of the tire to be inflated / deflated belongs, and determine whether to issue an inflation / deflation control command based on the mutex lock status. The module is used to create command slots for issued control commands, record the issuance time and retry count of the control command, and receive the execution information returned by the current wheel-side device within the command validity period to confirm the execution progress. The confirmation module is used to maintain the mutex lock after confirming that the execution progress has entered the working state. It continuously receives the execution information returned by the current wheel-side device until it confirms that the execution progress has entered the completed working state, and then releases the mutex lock.

9. A control device for inflating and deflating tires of a multi-wheeled vehicle, characterized in that, The multi-wheel vehicle tire inflation / deflation control device includes a processor, a memory, and a multi-wheel vehicle tire inflation / deflation control program stored in the memory and executable by the processor, wherein when the multi-wheel vehicle tire inflation / deflation control program is executed by the processor, it implements the steps of the multi-wheel vehicle tire inflation / deflation control method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a control program for inflating and deflating multi-wheeled vehicle tires, wherein when the control program for inflating and deflating multi-wheeled vehicle tires is executed by a processor, it implements the steps of the control method for inflating and deflating multi-wheeled vehicle tires as described in any one of claims 1 to 7.

Images