Seat armrest screen control method and vehicle

Abstract

The invention discloses a seat armrest screen control method and a vehicle, and belongs to the technical field of man-machine interaction, and the method comprises the following steps: carrying out scene recognition on operation state parameters of a target seat to obtain a semantic scene to which the target seat currently belongs; the semantic scene is used for representing the use condition of the target seat; performing strategy mapping on the semantic scene, and determining an adaptive control strategy corresponding to the semantic scene; and controlling a target seat armrest screen based on the self-adaptive control strategy. Self-adaptive linkage control in the whole period inside and outside the vehicle is achieved, and interaction continuity and safety are enhanced.

Description

Technical Field

[0001] This application relates to the field of human-computer interaction technology, and in particular to a method for controlling a seat armrest screen and a vehicle. Background Technology

[0002] Currently, some vehicles are equipped with seats (such as welfare seats) that can be electrically retracted and used as independent wheelchairs. The control panel integrated into the seat armrest (armrest screen) usually serves as the control and display terminal for the seat and some in-vehicle functions, mainly used for in-vehicle entertainment and vehicle control.

[0003] However, once the seat is removed from the vehicle, existing systems generally only trigger a simple exit mode via a mechanical switch, resulting in either a black screen or a switch to a static information interface (such as battery level and time), lacking a deep understanding of actual usage scenarios. The content and interaction logic of the armrest screen fail to adapt to the complex and dynamic actual operating conditions after the seat is removed from the vehicle, leading to unreachable key information or an accumulation of invalid functions, thus increasing the risk of misoperation and creating a fragmented user experience. Summary of the Invention

[0004] To address the aforementioned problems, this application proposes a method for controlling a seat armrest screen, the method comprising: Scene recognition is performed on the operating status parameters of the target seat to obtain the semantic scene to which the target seat currently belongs; the semantic scene is used to represent the usage status of the target seat; Perform policy mapping on the semantic scenario to determine the adaptive control policy corresponding to the semantic scenario; Based on the aforementioned adaptive control strategy, the target seat armrest screen is controlled.

[0005] In one example, scene recognition is performed on the operating status parameters of the target seat to obtain the semantic scene to which the target seat currently belongs, specifically including: Based on the aforementioned operating status parameters, an operating status representation reflecting the overall operating status of the target seat is generated; The operating state representation is matched with multiple predefined semantic scenarios to determine the semantic scenario to which the target seat currently belongs; the predefined semantic scenarios are obtained by clustering analysis of the operating state parameters of the target seat during its full lifecycle use inside and outside the vehicle.

[0006] In one example, generating an operational status representation reflecting the overall operational status of the target seat based on the operational status parameters specifically includes: Based on the state mapping relationship of each running state parameter, determine the state vector corresponding to each running state parameter; The operating state representation of the target seat is obtained by combining multiple state vectors.

[0007] In one example, determining the adaptive control strategy corresponding to the armrest screen of the target seat specifically includes: Based on the predefined scenario-policy mapping relationship, a policy configuration set that uniquely corresponds to the semantic scenario is determined; the scenario-policy mapping relationship is established by binding the semantic scenario with its respective pre-configured control policy.

[0008] In one example, when dealing with semantic scenarios related to movement outside the vehicle, the method further includes: If the battery level of the target seat is below a certain threshold, the displayed content in the semantic scenario corresponding strategy configuration set includes navigation information for guiding the return to the vehicle.

[0009] In one example, the method further includes: When a change in the operating status parameters is detected, a status confirmation timer is started. Determine whether the duration for which the changed running status parameters meet the corresponding semantic scene recognition conditions reaches the preset status confirmation window; Upon arrival, the semantic scene to which the target seat currently belongs is updated to the corresponding semantic scene.

[0010] In one example, the method further includes: If the changed operating status parameters meet the emergency semantic scenario recognition conditions, the status confirmation window is bypassed, and the current semantic scenario of the target seat is identified as the corresponding emergency semantic scenario.

[0011] In one example, the method further includes: If the changed operating state parameters do not meet the recognition conditions of any semantic scene, the semantic scene to which the target seat currently belongs remains unchanged; If the duration for which the changed operating status parameters do not meet any semantic scene recognition conditions reaches the preset state degradation confirmation window, the current semantic scene of the target seat will be updated to the predefined safe default scene.

[0012] In one example, based on the aforementioned adaptive control strategy, the target seat armrest screen is controlled, specifically including: According to the adaptive control strategy, the armrest screen of the target seat is controlled to perform at least one of the following: Update the display interface content of the armrest screen according to the display content strategy in the adaptive control strategy; Based on the interaction permission policy in the adaptive control strategy, specific input methods or functional areas of the armrest screen can be enabled or disabled. The screen-on or screen-off behavior of the armrest screen is controlled according to the wake-up rule strategy in the adaptive control strategy. According to the alarm mode strategy in the adaptive control strategy, corresponding visual, auditory, tactile or remote alarms are triggered under specific conditions.

[0013] On the other hand, embodiments of this application provide a vehicle including a controller, the controller including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform a seat armrest screen control method as described above.

[0014] The above-described technical solutions adopted in the embodiments of this application can achieve the following beneficial effects: By acquiring multi-dimensional operational status parameters of the seat, the semantic context in which the seat currently belongs can be identified, thus accurately reflecting its actual usage status. This process allows the armrest screen to move beyond simple mode switching based on a single status signal, instead relying on a comprehensive judgment of multi-dimensional states, thereby improving the depth of understanding and accuracy of recognition of usage scenarios.

[0015] After identifying the current semantic scenario, the system can match a corresponding adaptive control strategy based on that scenario. These strategies are differentiated for different usage situations, ensuring that the content displayed on the armrest screen and the interaction logic are highly consistent with the actual scenario. This avoids information mismatch and unreasonable interaction caused by scenario misjudgment or rigid strategies, achieving adaptive linkage control throughout the entire lifecycle inside and outside the vehicle. This allows the armrest screen to present the most critical information and provide the most appropriate operating permissions at different stages of use, while ensuring information accessibility and reducing unnecessary interference, thus enhancing the consistency and safety of the interaction.

[0016] In summary, by using state-driven scene recognition and control strategy adaptation, the armrest screen can autonomously decide on the display and interaction methods based on the actual operating state of the seat. This breaks through the limitations of the armrest screen as a passive display terminal in traditional systems, realizing intelligent, adaptive interaction and overall user experience throughout the entire process of the seat's independent movement in the vehicle. Attached Figure Description

[0017] To more clearly illustrate the technical solution of this application, some embodiments of this application will be described in detail below with reference to the accompanying drawings, in which: Figure 1 A schematic flowchart illustrating a seat armrest screen control method provided in an embodiment of this application; Figure 2 This is a structural schematic diagram of a vehicle provided in an embodiment of this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0019] Some embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0020] Figure 1 This application provides a schematic flowchart of a seat armrest screen control method, which includes the following steps: S101: Perform scene recognition on the operating status parameters of the target seat to obtain the semantic scene to which the target seat currently belongs; the semantic scene is used to represent the usage status of the target seat.

[0021] In this example, the target seat can be a welfare seat, a special type of seat designed to improve the convenience of travel for people with mobility impairments (such as the elderly and disabled). Its core feature is its ability to smoothly extend from inside the vehicle to outside via electric rails and other mechanisms, lowering its height and rotating its angle for easy seating. The welfare seat can then carry the user back into the vehicle and be repositioned and secured. Furthermore, when outside the vehicle, the welfare seat can be detached and used as an independent electrically powered mobility aid, expanding the user's range of independent movement.

[0022] Operating status parameters refer to a series of measurable or communicably obtainable data that reflect the current working conditions, environment, and status of the target seat. For example, operating status parameters include position status, power status, battery status, motion status, and communication status. Position status includes whether the target seat is in the vehicle's preset locking position and whether it has detached from the vehicle; power status includes the vehicle's power supply and built-in battery; battery status includes the remaining battery level; motion status includes stationary, low-speed movement, and high-speed movement; and communication status includes fully connected, partially connected, and disconnected, such as the communication link status between the seat and the vehicle's main unit, user mobile device, or remote server.

[0023] It should be noted that operating status parameters can be obtained through various sensors integrated into the seat, vehicle bus, and wireless communication modules (such as Bluetooth and Wi-Fi).

[0024] For example, the location status can be obtained in the following ways: Whether the seat is in the vehicle's preset locking position: A micro switch, Hall sensor, or proximity sensor installed based on the locking position (snap position) of the vehicle's slide rail is triggered when the seat latch is fully inserted and locked, outputting an in-position signal.

[0025] Whether the seat has detached from the vehicle: This is determined by the on / off status of the dedicated electrical connector (such as a power / communication connector) between the seat and the vehicle base. A reliably engaged connector indicates the seat is in place; a disconnected connector indicates it has detached.

[0026] Alternatively, the power status can be obtained in the following ways: A voltage comparator or power management chip is installed on the power input path of the seat to continuously monitor the power supply voltage from the vehicle. When a valid vehicle power supply voltage is detected, the system determines that the vehicle is powered. When the vehicle power supply voltage fails or is disconnected, the system automatically switches to the built-in battery power supply, which is then determined to be battery powered. Alternatively, the system can directly read the current power supply status flag from the seat's power management unit to make a judgment based on the status signal.

[0027] Alternatively, the running status can be obtained in the following ways: Wheel speed pulse calculation method: A rotary encoder or Hall speed sensor is installed on the drive wheels or follower wheels of the seat (when used as a stand-alone wheelchair). By measuring the number of pulses generated per unit time, the rotational speed of the wheel is calculated, and then combined with the wheel circumference, the real-time moving speed of the seat can be obtained.

[0028] Inertial measurement unit (IMU) calculation method: An accelerometer and gyroscope are integrated into the seat. The velocity change is estimated by integrating the acceleration signal (and removing the gravity component), or by analyzing the spectrum and amplitude characteristics of acceleration / angular velocity to directly determine the state such as stationary, smooth movement, or abnormal shaking / high speed.

[0029] Location information fusion method: When communication is available, GNSS-assisted information from the vehicle or user's mobile phone can be received. Speed ​​is estimated by calculating the rate of change of the seat's own GNSS module position information, thereby determining the motion state.

[0030] In addition, the battery status can be obtained in the following ways: Battery Management System Direct Read Method: Read precise SOC percentage data from the BMS via buses such as I2C and SPI.

[0031] Voltage approximation method: In low-cost solutions, the battery level range can be approximated by measuring the battery terminal voltage and performing rough compensation in combination with the load current.

[0032] In addition, the methods for obtaining communication status can be based on independent monitoring and comprehensive judgment of multiple links, and may include the following: Wired communication link: This is determined by detecting the presence of periodic messages or specific heartbeat messages on the bus. If the expected message is not received within the timeout window, the link is considered disconnected.

[0033] Wireless LAN: Monitors the association status and signal strength with vehicle access points (APs) or mobile hotspots. When the signal strength remains below the threshold or the association is lost, the wireless network is deemed unavailable.

[0034] Low-power wireless (such as Bluetooth BLE): Monitors the connection status and signal quality with paired mobile phones or vehicle modules.

[0035] Wide area network (e.g., cellular, if seat supports): Check network registration status and signal strength.

[0036] Therefore, full connectivity means that the highest bandwidth / reliability link (such as CAN or Wi-Fi) is active and available. Half connectivity means that a high-bandwidth link is disconnected, but at least one low-power, short-range wireless link (such as BLE) remains available. Disconnection means that all monitored communication links are unavailable.

[0037] In this example, semantic scenarios are based on the analysis of the target seat's complete usage cycle, summarizing several typical and stable usage conditions or stages. For example, semantic scenarios include normal in-vehicle use mode, stationary standby mode outside the vehicle, low-speed movement mode outside the vehicle, low battery warning scenario for movement outside the vehicle, low battery loitering scenario for stationary movement outside the vehicle, and high-speed movement mode outside the vehicle.

[0038] The methods for identifying semantic scenes can include state matching based on deterministic rules, scene classification based on machine learning models, and scene judgment based on fuzzy logic or weight calculation.

[0039] For example, for state matching of deterministic rules: a set of explicit state-scene mapping rules (such as lookup tables or decision trees) are predefined. The obtained runtime state parameters are compared with the mapping rules, and when all the conditions of a certain rule are met, it is determined to be the corresponding semantic scene.

[0040] For scene classification based on machine learning models: use pre-trained machine learning models (such as neural networks, support vector machines, random forests) to process the input running state parameters and directly output semantic scene classification labels.

[0041] For scene identification based on fuzzy logic or weight calculation: Define a membership function or feature weight set for each semantic scene. Calculate the matching degree or confidence of the running state parameters with each semantic scene, and select the semantic scene with the highest matching degree as the recognition result. For example, the feature weight characteristics of the external vehicle movement mode are high weight for motion state and low weight for communication state. As long as the motion features are obvious, it can still be reliably identified as this scene. This method is more robust to sensor noise and state jitter.

[0042] S102: Perform policy mapping on the semantic scene to determine the adaptive control policy corresponding to the semantic scene.

[0043] In this example, the adaptive control strategy is a set of behavioral rules corresponding to a specific semantic scenario, used to control the armrest screen to function. For example, the adaptive control strategy includes display content strategy, interaction permission strategy, wake-up rule strategy, alarm mode strategy, etc.

[0044] Display content strategy refers to specifying which information elements should be prioritized, allowed, or prohibited from being displayed on the armrest screen in the current scenario. For example, in mobile mode, the rule might require highlighting speed, battery level, simple navigation arrows, and emergency call buttons, while hiding complex entertainment control menus.

[0045] User interaction permission policies define the extent to which users can interact with the armrest screen via touch, voice, gestures, etc., in the current scenario. For example, in scenarios involving high-speed movement or low battery, rules may restrict most non-emergency touch operations, leaving only the emergency SOS function available to prevent accidental operations from distracting the user or causing danger.

[0046] A wake-up rule strategy refers to a set of rules that define the conditions under which the armrest screen is triggered or kept in an interactive, on-screen state, and the conditions under which it enters a low-power, off-screen or locked state. For example, in critical alarm scenarios such as low battery warnings or high-speed movement, the strategy might be set to force the screen to remain on to ensure that the alarm information remains visible until the state is cleared.

[0047] Alarm mode strategy refers to a set of rules that specify the sensory channels through which the system should issue warnings to users and potential stakeholders under specific risk or abnormal conditions, and at what intensity and frequency. For example, in a basic battery warning (such as when the battery level is below 25%), the strategy may only trigger a visual alarm (such as the battery icon turning yellow and flashing slowly). In the highest level alarm (such as detecting a seat slipping at high speed), the strategy will activate a full-channel strong alarm: a full-screen red flashing warning, a continuous beeping sound, a continuous strong tactile vibration, and remotely push alarm information and real-time location to the associated mobile phone or cloud monitoring platform via wireless communication.

[0048] It should be noted that the methods for determining the corresponding adaptive control strategy may include the following: Policy mapping based on a dynamic rule engine: It has a built-in rule engine and a knowledge base containing a large number of rules described in IF-THEN form. The condition part of these rules involves semantic scenarios, sub-states or contexts, and the conclusion part corresponds to a specific adjustment action of the displayed content or interaction permissions.

[0049] Machine learning-based strategy recommendation: This involves establishing a machine learning model that takes semantic scenes and / or real-time context as input, maps parameters based on a pre-trained model, and outputs a recommendation strategy. The model is trained using historical best-in-class interaction data and security policy specifications, learning the complex mapping relationship between which display and interaction strategies should be adopted under what circumstances. For example, the identified semantic scene, along with other current contextual information (such as precise battery percentage, ambient light intensity, and user historical preference identifiers), forms a feature vector. This feature vector is then input into a trained model (such as a deep neural network or gradient boosting decision tree). The model outputs a policy vector or policy identifier, which represents the adaptive control strategy recommended for the current overall situation.

[0050] Based on this, the policy content changes dynamically with different semantic scenarios through dynamic adaptive output based on semantic scenarios.

[0051] S103: Based on the aforementioned adaptive control strategy, control the target seat armrest screen.

[0052] In this example, the adaptive control strategy is translated into specific, executable control commands, which drive the armrest screen of the target seat to make corresponding state changes and behavioral responses. For example, control over the display content dimension, the interaction permission dimension, the device status dimension, and the alarm output dimension enables the armrest screen's output content, input response, power consumption status, and warning behavior to dynamically and automatically adjust according to changes in the semantic context, thereby realizing the adaptive operation of the human-computer interaction system at the physical level.

[0053] For example, when generating an adaptive control strategy through the seat controller, the strategy command can be sent to the control unit of the armrest screen via an available communication link (such as the vehicle CAN bus, Bluetooth BLE, Wi-Fi, etc.). The armrest screen receives and parses the strategy command, and implements adaptive changes at the visual and interactive levels based on the adaptive control content contained therein.

[0054] It should be noted that, although the embodiments in this application are based on... Figure 1Steps S101 to S103 will be described sequentially, but this does not mean that steps S101 to S103 must be performed in a strict order. The reason this embodiment follows this order is... Figure 1 The order in which steps S101 to S103 are described is provided to facilitate understanding of the technical solutions of the embodiments of this application by those skilled in the art. In other words, in the embodiments of this application, the order of steps S101 to S103 can be appropriately adjusted according to actual needs.

[0055] pass Figure 1 This method, by acquiring multi-dimensional operational status parameters of the target seat, can identify the semantic scenario to which the target seat currently belongs, thereby accurately reflecting its actual usage status. This process allows the armrest screen to move beyond simple mode switching based on a single status signal, and instead relies on a comprehensive judgment of multi-dimensional states, improving the depth of understanding and accuracy of recognition of usage scenarios.

[0056] After identifying the current semantic scenario, the system can match a corresponding adaptive control strategy based on that scenario. These strategies are differentiated for different usage situations, ensuring that the content displayed on the armrest screen and the interaction logic are highly consistent with the actual scenario. This avoids information mismatch and unreasonable interaction caused by scenario misjudgment or rigid strategies, achieving adaptive linkage control throughout the entire lifecycle inside and outside the vehicle. This allows the armrest screen to present the most critical information and provide the most appropriate operating permissions at different stages of use, while ensuring information accessibility and reducing unnecessary interference, thus enhancing the consistency and safety of the interaction.

[0057] In summary, through state-driven scene recognition and strategy adaptation, the armrest screen can autonomously decide on the display and interaction methods based on the actual operating state of the target seat. This breaks through the limitations of the armrest screen as a passive display terminal in traditional systems, realizing intelligent, adaptive interaction and overall user experience for the target seat throughout its independent movement within the vehicle.

[0058] based on Figure 1 In addition to the method described herein, this application also provides some specific implementation schemes and extension schemes of the method, which will be further explained below.

[0059] In one example, scene recognition is performed on the operating status parameters of the target seat to obtain the semantic scene to which the target seat currently belongs, including the following steps: Step 1: Based on the operating status parameters, generate an operating status representation that reflects the overall operating status of the target seat.

[0060] In this example, because the original operational state parameters are discrete, isolated, and of varying dimensions, they cannot be directly processed by a unified decision logic. Therefore, intermediate processing, such as information integration or feature generation, is performed on the operational state parameters to form a representation that comprehensively reflects the overall situation. The operational state representation can be a structured data vector, a feature hash value, or any other computationally integrated data form.

[0061] Specifically, the process of generating a representation of the running state can be rule-based structured coding, model-based automatic feature extraction, etc.

[0062] Rule-based structured coding refers to mapping the values ​​of various runtime state parameters to a state and assembling them into a structured data object. This data object can carry all key state dimension information without loss. For example, it can be a vector, a feature dictionary (such as hash values, bitmasks), etc.

[0063] Model-based automatic feature extraction refers to directly inputting the original running state parameters into a pre-trained feature extraction network model, which then automatically converts the running state parameters into a high-dimensional feature vector.

[0064] Based on this, generating an operational status representation reflecting the overall operational status of the target seat based on the aforementioned operational status parameters may include the following steps: First, based on the state mapping relationship of each running state parameter, determine the state vector corresponding to each running state parameter.

[0065] It should be noted that for each type of operating status parameter (such as location, battery level), the system pre-stores a set of state mapping relationships. This relationship is essentially a set of judgment rules or functions. The input is an operating status parameter of a certain dimension, and the output is the corresponding state vector. This represents the digital encoding of the qualitative judgment result for a single dimension. It is a discrete numerical value or symbol used to clearly identify which preset qualitative state category the operating status parameter of that dimension belongs to.

[0066] Then, the multiple state vectors are combined to obtain the operating state representation of the target seat.

[0067] All state vectors are arranged and combined according to a predetermined order and structure. A typical and efficient way to combine them is to construct a multidimensional state vector or state tuple.

[0068] Based on this, the operational state representation is a comprehensive snapshot of the state after preliminary understanding and abstraction. It effectively integrates multi-dimensional information, eliminates the differences in dimensions and types between the original parameters, and enables the subsequent semantic scene recognition process to directly perform efficient matching or classification based on this structured and semantically clear representation, greatly improving the efficiency and accuracy of the recognition algorithm.

[0069] For example, operating status parameters include position, power supply, motion, battery level, and communication; the operating status is represented as a state vector. As shown in Table 1.

[0070] Table 1

[0071] Based on this, the above logical judgment is performed based on the running status value to obtain the status variable.

[0072] Step 2: Match the operational status representation with multiple predefined semantic scenarios to determine the semantic scenario to which the target seat currently belongs. The predefined semantic scenarios are obtained by clustering analysis of the operational status parameters of the target seat throughout its entire lifecycle of use inside and outside the vehicle.

[0073] In this example, the entire lifecycle encompasses the complete, closed-loop workflow of the target seat, starting from its use inside the vehicle, undergoing the process of detaching from the vehicle, entering independent use outside the vehicle, and finally returning and securing itself back inside the vehicle. The usage scenarios included in the entire lifecycle can include stable operating phases, critical mode switching phases, and abnormal or boundary phases. For example, stable operating phases include in-vehicle static entertainment, in-vehicle static conditions, and low-speed movement outside the vehicle. Critical mode switching phases include the seat sliding out / in process. Abnormal or boundary phases include before battery depletion, during communication interruptions, and during high-speed vehicle movement.

[0074] The vehicle interior and exterior clearly define two fundamental usage environments for the target seat. The interior state refers to the seat as a fixed component of the vehicle, locked in its sliding rail position, primarily relying on the vehicle's power supply and communication network. The exterior state refers to the seat detached from the vehicle, functioning as an independent mobility aid, primarily relying on its built-in battery and limited communication capabilities.

[0075] A predefined semantic scenario is typically a finite, discrete set of typical situations with clear semantic labels that is pre-determined and stored in the system before it actually runs, through analysis, induction, or calculation. Therefore, the core attributes of a semantic scenario include: predefinedness, semantics, and finiteness.

[0076] It's important to note that predefinedness refers to the fact that the content, quantity, and judgment rules of the scenario set are determined and fixed before system deployment or startup. It is not dynamically generated, learned in real-time, or inferred temporarily during system runtime. Semanticity indicates that each scenario corresponds to a meaningful usage stage or state category (e.g., normal use inside the vehicle, moving with low battery outside the vehicle), rather than simply a status code. Finiteness indicates that the number of scenarios is finite and enumerable (e.g., 6, 10), forming a complete scenario library or rule base, within which all online recognition operations of the system are limited to searching.

[0077] Matching methods can include deterministic rule judgment, similarity calculation and comparison, etc. For example, deterministic rule judgment includes using if-else logic chains or decision trees for precise matching. Similarity calculation and comparison includes calculating the Euclidean distance, cosine similarity, etc., between the state representation and each scene feature template, and selecting the most similar one.

[0078] Cluster analysis can take the form of algorithmic clustering, semantic clustering, etc. For example, algorithmic clustering involves using unsupervised machine learning algorithms such as K-means and DBSCAN to group state data points. Semantic clustering involves manually summarizing and classifying state combinations based on domain knowledge (physical logic, security specifications, user experience).

[0079] It should be noted that clustering analysis is a process of pre-summarizing and abstracting a complex state space. Semantic scenarios are typical patterns extracted after analyzing a large number of states, rather than being arbitrarily set or generated through other means. The analytical basis considered in clustering analysis is all theoretically possible and physically reasonable combinations of states for the target seat in the complete service chain from onboard to independent movement and back.

[0080] For example, based on Table 1, semantic clustering was used to summarize the effective state combinations into 6 typical scenarios, as shown in Table 2.

[0081] Table 2

[0082] It should be noted that the remaining combinations are considered invalid or transitional states (such as contradictory states where P=0 but E=1, or transient jitters during the slip-out process), and do not trigger policy updates. The reasons are explained below: Many combinations are physically impossible to hold simultaneously, or are merely instantaneous intermediate states, for example: Contradictory combination: P=0 (in the vehicle) but E=1 (battery powered): If the seat is in the latch position, the vehicle's power supply should be connected, and it should not be powered by the battery (unless the vehicle is turned off but the latch is not broken, which is abnormal).

[0083] Transient combination: The seat is sliding out, the latch has been released (P=1), but the CAN communication has not been interrupted (C=0), and the power is still switching (E=0→1). This is a transition process that lasts for less than 1 second.

[0084] Rare combination: M=2 (high-speed movement) and B=0 (sufficient power) and C=0 (connected vehicle). Theoretically possible, but in reality, the target seat's maximum speed is usually ≤6km / h, and the connection is lost immediately after detachment, so it is almost impossible to occur.

[0085] In summary, these combinations are either logically conflicting or have a very short duration. Designing an independent strategy for each would lead to a bloated system, difficult testing, and high maintenance costs.

[0086] In conclusion, predictable response time is crucial in assisted living or accessible environments. Predefined matching based on clustering analysis ensures decisions are made within a constant and extremely short timeframe under all circumstances, without the fluctuations or delays associated with complex model inference. This is essential for target seats that require immediate triggering of safety alarms or interactive feedback. Furthermore, it facilitates deployment on cost-controlled embedded chips, reducing overall vehicle cost and power consumption.

[0087] The correspondence between scenarios and policies is clear and fixed, and the behavior is predictable, ensuring the absolutely reliable triggering of critical safety policies (such as emergency stop and SOS) and meeting functional safety requirements. Complex models, however, contain uncertainty and may pose a risk of unpredictable responses due to unexpected inputs. Therefore, deterministic outputs, avoiding state transitions caused by fluctuations in model confidence or misjudgments of edge cases, are more suitable for safety-sensitive scenarios.

[0088] The usage of the target seat throughout its entire lifecycle, both inside and outside the vehicle, is finite, discrete, and clearly defined by domain experts. Therefore, a knowledge-based inductive approach is suitable for constructing a clear and interpretable scenario library. Cluster analysis, by inducing typical scenarios from a large number of possible states, is precisely the process of solidifying domain knowledge (safety specifications, user experience) into a clear physical meaning.

[0089] Developers can directly understand and modify the logic. When product features are upgraded or new usage patterns emerge, the semantic scenario library can be expanded by supplementing data and re-clustering without changing the overall architecture. It has good scalability, facilitates development debugging, problem tracing, feature upgrades and personalization, and has low lifecycle maintenance costs.

[0090] Therefore, the entire interactive control module can be integrated as a highly integrated, loosely coupled software unit, making it easier to embed into the complex electronic and electrical architecture of the vehicle and to communicate and collaborate stably with the seat ECU, the body CAN network, and other components. It is particularly suitable for application in in-vehicle target seat systems with high requirements for real-time performance, reliability, and interpretability.

[0091] In one example, policy mapping is performed on the semantic scene to determine the adaptive control policy corresponding to the semantic scene, including the following steps: Based on the predefined scenario-policy mapping relationship, determine the policy configuration set that uniquely corresponds to the semantic scenario.

[0092] It should be noted that the scenario-policy mapping relationship is established by statically binding semantic scenarios with their respective pre-configured control policies.

[0093] In this example, the predefined scenario-policy mapping relationship refers to a data association structure that is pre-established and stored in the target seat control system. This mapping relationship is not dynamically generated at runtime through complex algorithms, but is based on in-depth analysis of the target seat's usage throughout its entire lifecycle.

[0094] Mapping relationships can be represented by lookup tables, configuration files, or switch-case statements embedded in program logic. For example, by inputting a scenario identifier, a unique set of policy configurations can be output; the process is direct and deterministic, requiring no real-time reasoning or computation.

[0095] Each strategy configuration set is a complete and indivisible solution package. It addresses the core needs of its semantic scenario (such as battery warning and vehicle return guidance requirements) and allows for collaborative design and parameter presets across dimensions such as display content, interaction permissions, wake-up rules, and alarm modes.

[0096] Based on this, the same semantic scene input will trigger the exact same policy set response at any time and under any conditions, avoiding inconsistencies in behavior caused by model probability output or environmental interference, and to a certain extent eliminating the risk of frequent UI jumps caused by state jitter.

[0097] In this example, based on the identified semantic scenarios related to movement outside the vehicle, the battery charge status is further introduced as a core decision variable to achieve secondary dynamic adjustment of the control strategy.

[0098] Therefore, if the battery level is below the power threshold, the display content in the semantic scenario corresponding strategy configuration set will include navigation information used to guide the vehicle back.

[0099] The dynamic adjustment of displayed content has evolved from status notification to behavior guidance, including both regular and guiding displays.

[0100] The standard display refers to the display of basic status information such as current battery percentage and speed when the battery is fully charged. The guided display refers to the automatic insertion or highlighting of navigation information to guide the user back to the vehicle when the battery level falls below a set threshold (e.g., 15%).

[0101] It should be noted that the navigation information is intended to provide users with intuitive and effective guidance to return to their vehicle, and this can be achieved in ways including but not limited to the following: Static orientation guidance: Displays a fixed arrow pointing to the approximate direction of the parked vehicle (requires combining the vehicle's last position recorded when the seat was removed or a rough orientation determination based on BLE signal strength).

[0102] Dynamic route guidance: If the armrest screen has positioning capabilities (such as integrated GPS or location sharing via mobile phone), it can display a line or simple path between the user's current location and the vehicle's parking location on the map interface.

[0103] Distance and status prompts: Display auxiliary information such as the distance to the vehicle or that the vehicle is turned off.

[0104] In summary, addressing the core risk of users running out of battery and being unable to return while traveling, the armrest screen has been transformed from an information display into a safety guidance assistant. In mobile scenarios where vehicle communication may be interrupted, the guidance strategy is driven by local battery information, forming an independent safety guarantee that does not rely on external networks, ensuring the availability of the critical safety function (guided return).

[0105] By linking battery status with dynamic strategies, the system can anticipate risks and intervene in advance and in stages during battery depletion, from gentle reminders to strong guidance, effectively avoiding safety issues caused by sudden battery depletion.

[0106] It should be noted that the alarm mode can be dynamically adjusted as the battery level drops from fully charged to critical, with the alarm intensity, frequency, and method increasing progressively. For example, when the battery level falls below the first threshold, it is determined to enter the primary warning zone, and visual alerts may only be provided through a change in the screen icon color (from yellow to red). When the battery level falls below the second threshold, it is determined to enter the intermediate zone, and intermittent voice prompts or tactile vibrations may be added. When the battery level falls below the third threshold, it is determined to enter the critical battery zone, which may trigger continuous alarms and send remote notifications to associated devices.

[0107] For example, based on Tables 1 and 2, each semantic scenario is bound to a set of policy tuples including the following four elements, as shown in Table 3.

[0108] Table 3

[0109] It should be noted that the alarm method can be implemented based on the audio output, haptic feedback or wireless communication module integrated into the armrest screen.

[0110] In summary, the core decision-making relies on querying predefined scenario-policy mapping relationships, which is a deterministic operation with very low computational complexity. Compared to solutions that require running complex prediction or inference models (such as neural networks), it has extremely low requirements for processor computing power and memory, making it very suitable for reliable operation in resource-constrained embedded systems.

[0111] All scenarios and strategies are pre-bound, making system behavior fully predictable and exhaustively testable. This greatly reduces the difficulty of software verification, improves the overall reliability and robustness of the system, and meets the high functional safety requirements of automotive-grade products.

[0112] Feature iteration can be achieved by updating scenario definitions or adjusting corresponding strategy packages, without altering the core decision-making architecture. This modular design gives the system good maintainability and scalability.

[0113] In one example, due to potential instantaneous signal fluctuations, brief communication interruptions, or transitional states during seat physical state switching in the actual operating environment, these factors may cause short-term, unintentional, and drastic changes in operating state parameters. Directly switching semantic scenarios and corresponding complex control strategies based on these changes would result in frequent and abrupt jumps in the armrest screen's display content and interaction logic. This interface flickering not only interferes with users, causing confusion and a poor experience, but may also lead to misoperations and, in extreme cases, affect battery life due to rapid switching of power-consuming modules, posing a risk of frequent UI jumps caused by state jitter.

[0114] Based on this, a stabilization judgment process is introduced to switch from the target seat's operating state to the final scenario strategy, including the following steps: Step 1: When a change in the running status parameters is detected, start the status confirmation timer.

[0115] It should be noted that once a change in the state parameter value of any operational state dimension (such as location, power, etc.) is detected, it is considered the starting point for a possible scene switch and a timer will begin.

[0116] Step 2: Determine whether the duration for which the changed running status parameters meet the corresponding semantic scene recognition conditions reaches the preset status confirmation window.

[0117] The system does not switch immediately when the scene recognition conditions are met, but requires the scene recognition conditions to remain stable for a period of time (e.g., 2 seconds). For example, although the state changes briefly, the duration is extremely short and cannot reach the state confirmation window, so the scene switch will not be triggered incorrectly.

[0118] Step 3: Upon arrival, update the semantic scene to which the target seat currently belongs to the corresponding semantic scene.

[0119] Therefore, the state change is only confirmed as valid and the scenario switch is executed after the above duration condition is met.

[0120] In summary, this method eliminates scene misidentification and interface flickering caused by instantaneous fluctuations in sensor signals or brief communication interruptions, thus preventing erroneous scene and display strategy switching. It effectively filters noise, thereby avoiding user confusion and a poor experience caused by frequent interface transitions, and ultimately improving the continuity of interaction and system stability.

[0121] By using a pre-defined status confirmation window, the system ensures that the conclusions of scene recognition are reliable and verified. This ensures that the system only updates the complex policy set (display content, interaction permissions, etc.) associated with the usage scenario after confirming that a substantial change has actually occurred, thus avoiding erroneous function actions or unintended activation of security policies due to momentary abnormalities in the status.

[0122] Based on this, the shock absorber, which is responsible for the stable operation of the system, achieves extremely high reliability and smoothness of the entire adaptive control system in the face of complex real-world environments by sacrificing a small, predictable time delay.

[0123] In one example, in certain emergency situations (such as a seat malfunction causing high-speed sliding), the speed of the system response takes much higher priority than stability. Therefore, to ensure an immediate response to emergency situations within a general stabilization mechanism, the following steps are included: When the changed operating status parameters meet the emergency semantic scenario recognition conditions, the status confirmation window is bypassed, and the current semantic scenario of the target seat is identified as the corresponding emergency semantic scenario.

[0124] For example, an emergency semantic scenario is a high-speed movement outside a vehicle. High-speed movement is defined as an emergency condition that requires bypassing the usual procedures.

[0125] Therefore, when the aforementioned emergency semantic scenario conditions are triggered, the system will interrupt or not start the prescribed confirmation timing process.

[0126] In summary, under most non-emergency circumstances, the system follows a stable, anti-shake process to ensure a good user experience; in a very few specific emergency situations, the system activates a rapid response path. This tiered response logic (regular anti-shake and emergency bypass) demonstrates a high degree of intelligence, enabling the system to make the most reasonable trade-offs in complex scenarios.

[0127] Once a preset emergency condition is detected, the system immediately triggers scene switching and alarm actions. This green channel mechanism prioritizes safety response over stability, dynamically selecting a handling strategy based on the inherent danger of the situation. This achieves a better balance between safety and availability overall, making the entire adaptive control system not only intelligent and stable but also inherently safe.

[0128] In one example, due to the presence of numerous invalid or transitional states, the system will encounter abnormal or contradictory states. Therefore, to address the system stability problem during invalid or transitional states, the following steps are included: If the changed operating state parameters do not meet the recognition conditions of any semantic scene, the semantic scene to which the target seat currently belongs remains unchanged.

[0129] Based on this, if the current state vector cannot match the recognition conditions of any semantic scene, the scene switch will not be executed. Instead, the armrest screen will continue to use all adaptive control strategies (display content, interaction permissions, etc.) bound to the currently effective (i.e., the last successfully recognized) semantic scene. The screen will continue to display the original content and maintain the original interaction permissions. This achieves the freezing of invalid state strategies, ensuring the continuity of interaction.

[0130] Furthermore, if the duration for which the changed operating status parameters do not meet any semantic scene recognition conditions reaches the preset state degradation confirmation window, the current semantic scene of the target seat will be updated to the predefined safe default scene.

[0131] In this example, upon entering the aforementioned invalid state and initiating the maintenance strategy, a separate state degradation acknowledgment window timer is simultaneously started. The system continuously monitors the state, and if the running state parameters consistently fail to match any semantic scenario within the entire window duration (e.g., 10 seconds), the abnormal state is determined to be persistent and stable. The semantic scenario of the target seat will then be proactively and forcibly updated to a predefined safe default scenario.

[0132] For example, the default safety scenario is a stationary standby mode outside the vehicle. This ensures that even in the worst-case scenario, the user can still see critical information (such as battery level and SOS) and perform basic operations, allowing the system to return to a known safe and controllable baseline state.

[0133] In summary, by freezing invalid states, the system gains fault tolerance to short-term state noise and transition processes, avoiding a fragmented user experience and making the operation of the core adaptive control logic more stable and reliable.

[0134] Maintaining the original interface during the invalid state prevents users from being confused or making mistakes due to the sudden disappearance or change of screen content, and ensures basic safety, especially during movement.

[0135] The timeout safety degradation mechanism, as a safety redundancy in system design, ensures that in any unpredictable long-term abnormal situation, the system can automatically and reliably revert to a functionally limited but absolutely safe mode, fundamentally avoiding the risk of system loss of control and meeting the basic functional safety requirements of the product.

[0136] In one example, controlling the target seat armrest screen based on the adaptive control strategy includes the following steps: On the one hand, the display interface content of the armrest screen is updated according to the display content strategy in the adaptive control strategy.

[0137] In this example, the interface content includes displayed content, status visualization, and injection of guidance information.

[0138] The displayed content is determined by calling the corresponding user interface template or dynamically generating interface elements according to the display content strategy. For example, in a normal in-vehicle use scenario, a full-featured interface containing controls for air conditioning, media, etc., is loaded; while in a moving scenario outside the vehicle, a minimalist interface containing only battery level, speed, and SOS is switched to.

[0139] Status visualization involves transforming abstract states (such as battery level) into intuitive visual elements (such as an icon changing color to yellow and flashing).

[0140] Guidance information injection: Based on strategy requirements, insert or highlight specific information in the interface (such as return vehicle guidance arrows and text).

[0141] On the other hand, based on the interaction permission policy in the adaptive control strategy, specific input methods or functional areas of the armrest screen can be enabled or disabled.

[0142] In this example, the interaction permission policy defines what a user can do and how they can do it. The interaction permission policy includes input method management, functional area division and control, and operation logic binding.

[0143] Input method management: Enable or disable specific input channels according to policies. For example, in scenarios that require focus (such as high-speed movement), disable all touch, voice and gesture recognition functions except for the physical SOS button.

[0144] Functional area division and control are as follows: On the touchscreen, valid response areas and invalid shielding areas are defined by software. For example, for stationary scenarios outside a vehicle, it is stipulated that only clicks on the center area of ​​the screen are valid, and edge touches are only used for waking up, thereby preventing accidental touches.

[0145] The operation logic is bound as follows: set specific trigger logic (such as long press for 1.5 seconds) for reserved functions (such as SOS) to avoid accidental touches.

[0146] On the other hand, the screen-on or-off behavior of the armrest screen is controlled according to the wake-up rule strategy in the adaptive control strategy.

[0147] In this example, the wake-up rule strategy is transformed into control logic for the screen backlight and the sleep / wake state of the main control chip, including screen-on / screen-off behavior control and wake-up trigger source management.

[0148] Screen on / off behavior control: Based on the wake-up rule strategy, execute automatic screen off (such as screen off 3 seconds after touch in low-speed moving scenarios outside the vehicle), periodic dim lighting (such as lighting up for 1 second every 5 minutes in critical battery scenarios), or forced constant lighting (such as high-speed moving scenarios).

[0149] Wake-up trigger source management: Set the events that are allowed to wake up the screen. For example, in normal in-vehicle use scenarios, system notifications and voice commands can wake up the screen; while in stationary standby scenarios outside the vehicle, only specific edge touch gestures or SOS long press events may be allowed to wake up the screen, filtering out irrelevant disturbances.

[0150] On the other hand, based on the alarm mode strategy in the adaptive control strategy, corresponding visual, auditory, tactile, or remote alarms are triggered under specific conditions.

[0151] In this example, the alarm pattern strategy is transformed into an alert action that spans multiple sensory channels and communication links. It is a proactive and progressive means of attracting user attention or seeking external assistance in abnormal or critical situations.

[0152] Visual alarms include flashing of a specific color across the entire screen and violently jumping of a specific icon. Auditory alarms include a buzzer sound or voice prompt at a specific frequency emitted through the built-in speaker. Haptic alarms involve driving a vibration motor to generate vibrations of varying intensities or patterns. Remote alarms are sent via BLE or mobile networks, pushing alarm information and status (such as location and battery level) to a paired smartphone or cloud service center.

[0153] In summary, we should work together to build a secure interactive environment. For example, when a low battery alarm occurs, we should simultaneously simplify the displayed content, restrict unnecessary operations, and adjust the wake-up logic to ensure that the alarm information can be seen.

[0154] Through collaborative management, while ensuring the absolute availability of core functions (such as SOS), screen power consumption, computing overhead, and user interference in unnecessary states are minimized, achieving a balance between security, energy efficiency, and user experience.

[0155] It should be noted that the execution entity of the seat armrest screen control method can be a computing unit integrated into the armrest screen or the vehicle itself (such as a seat controller or vehicle domain controller), or it can be a collaboration between the local computing unit and a cloud server as the execution entity. For example, the cloud server can perform cluster analysis of operating status parameters, semantic scene definition, and optimization of the strategy library based on big data, while the local computing unit is responsible for real-time status perception, scene matching, and rapid execution of control commands.

[0156] Based on Tables 1, 2, and 3, a practical scenario example is as follows: Scenario 1: Normal use inside the car ( ) User behavior: The user is sitting in the parked welfare seat, the vehicle is in the ON position, and the seat is in the sliding rail latch position.

[0157] System status: P=0 (in vehicle), E=0 (vehicle power supply), M=0 (stationary), B=0 (100% battery), C=0 (CAN / WiFi connected).

[0158] The armrest screen responds as follows: Automatically activated. Strategy; Displays the full UI: air conditioning temperature, media playback, window controls, navigation map; Supports voice commands to increase volume and gestures to switch songs; Automatically lights up the screen for 3 seconds when a notification is received.

[0159] Scenario 2: Seat slides out transition (invalid state strategy freeze) User behavior: When the user presses the remove button, the seat begins to slide out of the car, lasting for about 8 seconds.

[0160] System state changes: t=2s: P becomes 1 (the latch is released), but E is still 0 (the power is not cut off), C is still 0 (the CAN is not disconnected), and the running state vector is [1,0,0,0,0].

[0161] Based on this, this combination does not belong to the 6 types of valid scenarios (contradictory state: disconnected but still powered by the whole vehicle).

[0162] Armrest screen response: No strategy switching, continue using the existing one. UI and interaction permissions; keep the screen displaying the in-vehicle interface to avoid sudden UI changes during the slide-out process that could confuse the user.

[0163] Scenario 3: Low-speed movement outside the vehicle ( ) User behavior: The seat completely detaches, and the user pushes the chair towards the mall entrance at a speed of approximately 2.5 km / h.

[0164] System status: P=1, E=1 (battery powered), M=1 (low speed), B=0 (85% battery), C=2 (completely offline).

[0165] System determination: Continuously satisfied Activation will occur 2.5 seconds after the conditions are met and the confirmation window is open. Strategy.

[0166] Armrest screen response: The screen automatically turns off; when the user lightly touches the 8mm area on the right edge, the screen instantly lights up, displaying only the following: battery icon (green, 85%), current speed 2.5km / h, white arrow pointing in the direction of the vehicle, and red SOS button; if there is no click in the center area within 3 seconds, the screen automatically turns off; when the user presses and holds the SOS button for 1.8 seconds, the preset emergency contact will be dialed.

[0167] Scenario 4: Battery level drops, triggering a warning ( ) User behavior: The user stayed in the mall for 1 hour and then returned. During the promotion, the battery level dropped to 22%.

[0168] System status: P=1, E=1, M=1, B=1 (15%~30%), C=2.

[0169] System determination: Enter .

[0170] Armrest screen response: Upon next wake-up, force full-screen display to return to the vehicle guidance page (including dynamic path arrows); battery icon flashes red; all menu items are grayed out, only SOS is operable; every 30 seconds, a gentle prompt is output through bone conduction headphones: low battery, it is recommended to return to the vehicle as soon as possible.

[0171] Scenario 5: Battery level at critical point, resulting in static stagnation ( ) User behavior: The user stopped while queuing, the battery level dropped to 12%, and the user remained still for more than 2 minutes.

[0172] System status: P=1, E=1, M=0, B=2, C=2.

[0173] System determination: Enter .

[0174] Armrest screen response: The screen automatically dims for 1 second every 5 minutes, displaying red text: Low battery, please return to the vehicle; Touch control is only effective in the SOS area; At the same time, the low-frequency vibration motor is activated, and an alarm is pushed to the bound mobile phone via BLE: Welfare seat battery is below 15%, location: East gate of XX shopping mall.

[0175] Scenario 6: Abnormally high-speed movement ( ) User behavior: Loss of control on downhill section, seat speed suddenly increases to 7km / h.

[0176] System status: M=2 (>3km / h), other statuses are arbitrary.

[0177] System determination: Trigger immediately (No 2-second delay).

[0178] Armrest screen response: The screen is forced to remain constantly lit, displaying flashing red text in full screen: Slow down! Please hold the armrest tightly!; All inputs are locked, only the SOS button can be operated through; A high-frequency buzzer is activated, and an emergency location push is sent to the owner's mobile phone.

[0179] Based on this, to ensure the stability and security of policy switching, timing rules for state transitions are introduced. State confirmation window: Any state change must continuously meet the new conditions for a period of time equal to the window duration before entering the new scene is determined, preventing false triggering due to sensor jitter; Emergency pass-through mechanism: Once SC5 (high-speed movement) is detected, it takes effect immediately without confirmation delay. Invalid state policy freeze: If the current state does not belong to any of the 6 valid scenarios, all policies of the previous valid scenario remain unchanged, the screen continues to display the original content, and the original interaction permissions are maintained; Timeout safety degradation: If the invalid state continues for more than the degradation window duration and cannot converge, it automatically degrades to SC1 (external stationary standby mode) as the default safety policy.

[0180] Through the above logical closed loop, the armrest screen is no longer a passive display terminal, but an intelligent interactive agent that can make autonomous decisions based on the operating status of the welfare seat, realizing a fundamental leap from static to dynamic adaptation.

[0181] In summary, to address the current system's inability to dynamically adjust display content and user interaction permissions based on the seat's multi-dimensional operating state inside and outside the vehicle—leading to issues such as displaying invalid control items after leaving the vehicle, interface interference during movement, lack of proactive guidance when battery is low, and even frequent UI jumps due to state fluctuations—this application constructs a five-dimensional state space for welfare seats (position, power, movement, battery level, and communication), clusters it into typical semantic scenarios, and dynamically binds a four-element strategy set—display content, interaction permissions, wake-up rules, and alarm modes—to each scenario. Combined with a state confirmation window and an invalid state strategy freezing mechanism, this achieves adaptive linkage control of the armrest screen throughout the entire lifecycle inside and outside the vehicle. This strengthens safety boundaries while ensuring interaction continuity.

[0182] Based on this, the logical architecture achieves a leap from passive display to state-adaptive operation of the armrest screen. This is expected to significantly reduce interference from invalid information, suppress the risk of misoperation during movement, extend the effective service time under independent power supply, and proactively guide users safely back when the battery is critically low. Thus, throughout the entire lifecycle of the welfare seat, from in-vehicle use to independent mobility, it ensures the accessibility of critical information while also considering mobility safety, interactive rationality, and energy sustainability. This achieves synergistic optimization of information presentation, user interaction, and energy management.

[0183] Based on the same idea, some embodiments of this application also provide devices and non-volatile computer storage media corresponding to the above methods.

[0184] Figure 2 This is a schematic diagram of the structure of a vehicle provided in an embodiment of this application.

[0185] For example, such as Figure 2As shown, the vehicle includes a controller, which includes a memory 201 and a processor 202. The memory 201 stores executable program code 2011, and the processor 202 is used to call and execute the executable program code 2011 to perform the seat armrest screen control method.

[0186] The controller can be a seat controller or an in-vehicle domain controller.

[0187] Some embodiments of this application provide a non-volatile computer storage medium for controlling a seat armrest screen, which stores computer-executable instructions capable of executing any of the above-described seat armrest screen control methods.

[0188] The various embodiments in this application are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the vehicle equipment and medium embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the description of the method embodiments.

[0189] The vehicle equipment and medium provided in this application are one-to-one with the method. Therefore, the vehicle equipment and medium also have similar beneficial technical effects as their corresponding methods. Since the beneficial technical effects of the method have been described in detail above, the beneficial technical effects of the vehicle equipment and medium will not be repeated here.

[0190] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0191] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0192] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0193] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0194] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0195] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0196] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0197] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0198] The above description is merely an embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the technical principles of this application should fall within the protection scope of this application.

Claims

1. A method for controlling a seat armrest screen, characterized in that, The method includes: Scene recognition is performed on the operating status parameters of the target seat to obtain the semantic scene to which the target seat currently belongs; the semantic scene is used to represent the usage status of the target seat; Perform policy mapping on the semantic scenario to determine the adaptive control policy corresponding to the semantic scenario; Based on the aforementioned adaptive control strategy, the target seat armrest screen is controlled.

2. The method according to claim 1, characterized in that, Scene recognition is performed on the operating status parameters of the target seat to obtain the semantic scene to which the target seat currently belongs, specifically including: Based on the aforementioned operating status parameters, an operating status representation reflecting the overall operating status of the target seat is generated; The operating state representation is matched with multiple predefined semantic scenarios to determine the semantic scenario to which the target seat currently belongs; the predefined semantic scenarios are obtained by clustering analysis of the operating state parameters of the target seat during its full lifecycle use inside and outside the vehicle.

3. The method according to claim 2, characterized in that, The step of generating an operational status representation reflecting the overall operational status of the target seat based on the operational status parameters specifically includes: Based on the state mapping relationship of each running state parameter, determine the state vector corresponding to each running state parameter; The operating state representation of the target seat is obtained by combining multiple state vectors.

4. The method according to claim 1, characterized in that, Perform policy mapping on the semantic scene to determine the adaptive control policy corresponding to the semantic scene, specifically including: Based on the predefined scenario-policy mapping relationship, a policy configuration set that uniquely corresponds to the semantic scenario is determined; the scenario-policy mapping relationship is established by binding the semantic scenario with its respective pre-configured control policy.

5. The method according to claim 4, characterized in that, When dealing with semantic scenarios related to movement outside the vehicle, the method further includes: If the battery level of the target seat is below a certain threshold, the displayed content in the semantic scenario corresponding strategy configuration set includes navigation information for guiding the return to the vehicle.

6. The method according to claim 1, characterized in that, The method further includes: When a change in the operating status parameters is detected, a status confirmation timer is started. Determine whether the duration for which the changed running status parameters meet the corresponding semantic scene recognition conditions reaches the preset status confirmation window; Upon arrival, the semantic scene to which the target seat currently belongs is updated to the corresponding semantic scene.

7. The method according to claim 6, characterized in that, The method further includes: If the changed operating status parameters meet the emergency semantic scenario recognition conditions, the status confirmation window is bypassed, and the current semantic scenario of the target seat is identified as the corresponding emergency semantic scenario.

8. The method according to claim 6, characterized in that, The method further includes: If the changed operating state parameters do not meet the recognition conditions of any semantic scene, the semantic scene to which the target seat currently belongs remains unchanged; If the duration for which the changed operating status parameters do not meet any semantic scene recognition conditions reaches the preset state degradation confirmation window, the current semantic scene of the target seat will be updated to the predefined safe default scene.

9. The method according to claim 1, characterized in that, Based on the aforementioned adaptive control strategy, the target seat armrest screen is controlled, specifically including: According to the adaptive control strategy, the armrest screen of the target seat is controlled to perform at least one of the following: Update the display interface content of the armrest screen according to the display content strategy in the adaptive control strategy; Based on the interaction permission policy in the adaptive control strategy, specific input methods or functional areas of the armrest screen can be enabled or disabled. The screen-on or screen-off behavior of the armrest screen is controlled according to the wake-up rule strategy in the adaptive control strategy. According to the alarm mode strategy in the adaptive control strategy, corresponding visual, auditory, tactile or remote alarms are triggered under specific conditions.

10. A vehicle, comprising a controller, characterized in that, The controller includes: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform a seat armrest screen control method according to any one of claims 1-9.

Images