In-vehicle multimedia control methods, devices, equipment, media and software products

Abstract

This application relates to the field of vehicle-machine interaction technology, and provides a method, device, equipment, medium, and program product for controlling in-vehicle multimedia. It extracts driving feature sequences from a driving dataset, and environmental perception feature sequences from wiper status signals and light sensor signals. Based on a historical driving database, it analyzes the driving behavior of the driving feature sequences to generate a current driving state label. Based on the current driving state label and the environmental perception feature sequences, it filters a candidate driving mode set from the driving mode and feature set. Based on mode priority, it determines a target driving mode from the candidate driving mode set, and matches a target control strategy from the vehicle control decision set based on the target driving mode, thereby adjusting the multimedia vehicle system according to the target control strategy. This application improves the human-machine interaction experience during driving by integrating multi-dimensional information such as historical travel patterns, real-time driving behavior, and external environmental conditions for comprehensive decision-making.

Description

Technical Field

[0001] This application relates to the field of vehicle-machine interaction technology, and in particular to a vehicle multimedia control method, device, equipment, medium and program product. Background Technology

[0002] With the development of intelligent cockpit and vehicle networking technologies, in-vehicle multimedia systems have gradually evolved from simple music playback devices into comprehensive interactive platforms capable of providing personalized services based on vehicle operating status, driving habits, and environmental information. In actual driving, drivers often have different needs regarding music style, voice interaction methods, interface display formats, and in-car atmosphere in different scenarios such as daily commuting, long-distance driving, driving in the rain, and returning home at night. For example, commuting scenarios prioritize a relaxing and soothing auditory experience, long-distance driving requires alertness and fatigue prevention assistance, rainy conditions necessitate improved clarity of information broadcasts, and the nighttime return home scenario favors a relaxed and comfortable in-car atmosphere. Therefore, how to automatically adjust in-vehicle music and related cockpit configurations based on the vehicle's real-time operating status and driving environment has become an important research direction in the field of intelligent cockpits.

[0003] Existing in-vehicle multimedia control methods typically rely on user-manual playlist selection, preset music style switching, or scene mode control triggered by a single condition. For example, they may automatically switch playlists based on time, adjust volume based on vehicle speed, or recommend specific music content based on navigation status. While some systems can acquire vehicle location, time information, and some environmental sensor data, most rely on independent conditional judgments for music control, lacking comprehensive analysis of driving behavior characteristics, historical travel patterns, and real-time environmental conditions. Furthermore, switching between different scenes often depends on simple threshold judgments, lacking multi-scene conflict handling, priority arbitration, and stability control mechanisms. Therefore, in complex driving environments, inconsistent mode switching or uncoordinated control strategies can easily occur. Summary of the Invention

[0004] This application provides a vehicle multimedia control method, device, equipment, medium, and program product to solve the problem of inconsistent vehicle-machine control decisions during driving.

[0005] In a first aspect, embodiments of this application provide an in-vehicle multimedia control method, including: Driving feature sequences are extracted from synchronously collected driving datasets, and environmental perception feature sequences are extracted from synchronously collected wiper status signals and light sensor signals. Based on a preset historical driving database, the driving feature sequence is analyzed to generate a current driving status marker. Based on the current driving state marker and the environmental perception feature sequence, a candidate driving mode set is selected from the preset driving mode and feature set; The target driving mode is determined from the candidate driving mode set according to the preset mode priority, and the corresponding target control strategy is matched from the preset vehicle control decision set according to the target driving mode, so as to adjust the preset multimedia vehicle system according to the target control strategy.

[0006] In an optional implementation, the step of extracting driving feature sequences from the synchronously acquired driving dataset and extracting environmental perception feature sequences from the synchronously acquired wiper status signals and light sensor signals includes: The collected driving dataset is time-aligned to obtain driving data frames corresponding to each timestamp; According to the preset driving feature type, the corresponding driving feature set is extracted from the driving data frame, and the driving feature set is sorted according to the time sequence to obtain the driving feature sequence. The collected wiper status signal is smoothed through a preset time window to obtain the wiper status value, and the collected light sensor signal is low-pass filtered to obtain the smoothed illumination value. The wiper status values ​​and the smoothed illumination values ​​are aligned according to time sequence to obtain an environmental perception feature sequence.

[0007] In an optional implementation, the step of analyzing the driving behavior sequence based on a preset historical driving database to generate a current driving state marker includes: The driving time is calculated in segments based on vehicle speed information to obtain driving time characteristics. The driving time is then matched with a preset digital map based on location information to obtain the road level. Based on the road grade and time information, the driving feature sequence is compared with historical driving records in a preset historical driving database to count the number of times a user commutes. The driving duration feature, the road grade, and the number of commutes are combined into a current driving status marker according to a preset marking format.

[0008] In an optional implementation, the step of selecting a candidate driving mode set from a preset driving mode and feature set based on the current driving state marker and the environmental perception feature sequence includes: Based on the commuting frequency, driving duration features, and road grade in the current driving status marker, the current driving status marker is matched with each first mode in the preset driving mode and feature set by rules to obtain the confidence value corresponding to each first mode. Based on the wiper status value and the smooth illumination value, the environmental perception feature sequence is matched with each second mode in the driving mode and feature set to obtain the confidence value corresponding to each second mode. From the first mode and the second mode, select a set of candidate driving modes whose confidence values ​​are greater than a preset confidence threshold, and record the candidate confidence values ​​corresponding to each mode in the set of candidate driving modes.

[0009] In an optional implementation, the step of determining a target driving mode from the candidate driving mode set according to a preset mode priority, and matching a corresponding target control strategy from a preset vehicle control decision set according to the target driving mode, so as to adjust the preset multimedia vehicle system according to the target control strategy, includes: The candidate driving modes in the candidate driving mode set are sorted according to the preset mode priority to obtain the mode priority sequence; Based on the candidate confidence values ​​and the mode priority sequence, a weighted arbitration is performed on each candidate driving mode in the candidate driving mode set to obtain the target driving mode; Based on the target driving mode, a target control strategy corresponding to the target driving mode is matched from a preset vehicle control decision set; The preset multimedia vehicle system is adjusted in conjunction with the target control strategy.

[0010] In an optional implementation, the step of comparing the driving feature sequence with historical driving records in a preset historical driving database based on the road grade and time information to count the user's commuting frequency includes: Based on the location information, the historical high-frequency routes corresponding to the driving feature sequence are determined by matching the road links in the preset digital map. Based on the historical high-frequency routes, extract the historical trip start time corresponding to the historical high-frequency routes; Based on the time information, the current trip start time corresponding to the driving feature sequence is extracted, and the current trip start time is compared with the historical trip start time to obtain the time period matching value; When the road level meets the preset commuter road level and the time period matching value is less than or equal to the preset time deviation threshold, the historical driving record corresponding to the historical high-frequency route is determined as a commuter record, and the user's commuting frequency is counted based on the cumulative number of commuter records.

[0011] Secondly, embodiments of this application provide an in-vehicle multimedia control device, comprising: The acquisition and extraction module is used to extract driving feature sequences from the synchronously acquired driving dataset and to extract environmental perception feature sequences from the synchronously acquired wiper status signals and light sensor signals. The behavior analysis module is used to perform driving behavior analysis on the driving feature sequence based on a preset historical driving database and generate a current driving status marker. The mode candidate module is used to filter out a set of candidate driving modes from a preset driving mode and feature set based on the current driving state marker and the environmental perception feature sequence. The mode decision module is used to determine the target driving mode from the candidate driving mode set according to the preset mode priority, and to match the corresponding target control strategy from the preset vehicle control decision set according to the target driving mode. The vehicle infotainment system adjustment module is used to adjust the preset multimedia vehicle infotainment system according to the target control strategy.

[0012] Thirdly, embodiments of this application provide a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described vehicle multimedia control method.

[0013] Fourthly, embodiments of this application provide a readable storage medium storing a computer program that, when executed by a processor, implements the steps of the above-described vehicle multimedia control method.

[0014] Fifthly, embodiments of this application provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the above-described vehicle multimedia control method.

[0015] In one solution provided by the aforementioned in-vehicle multimedia control method, device, equipment, medium, and program products, driving information such as vehicle speed, position, and time generated during vehicle operation is utilized, combined with historical driving records, to analyze the user's travel patterns and distinguish different driving states such as commuting and long-distance travel. Subsequently, the external environmental state is perceived by combining windshield wiper status and ambient light information, and the driving state and environmental state are jointly matched to filter candidate modes that match the characteristics of the current scenario. Based on this, a mode priority mechanism is used to further determine the target mode that best meets the current needs, and the corresponding control strategy is invoked to adjust the vehicle system accordingly. This application integrates multi-dimensional information such as historical travel patterns, real-time driving behavior, and external environmental states for comprehensive decision-making, thus reducing the probability of scenario misjudgment and incorrect mode switching. This makes the adjustments to in-vehicle music, interaction methods, and cabin environment more in line with the driver's current actual needs, thereby improving comfort, immersion, and human-computer interaction experience during driving. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a schematic diagram of the operating environment of the in-vehicle multimedia control method in an embodiment of the present invention; Figure 2 This is a flowchart illustrating the in-vehicle multimedia control method in an embodiment of the present invention; Figure 3 yes Figure 1 Functional module diagram of the in-vehicle multimedia control device integrated into the CRRC's CRRC controller; Figure 4 This is a schematic diagram of the structure of the computer device in an embodiment of the present invention. Detailed Implementation

[0018] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of 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] It should be understood that, when used in this specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or collections thereof. It should also be understood that, as used in this specification and the appended claims, the term "and / or" refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0020] Furthermore, in the description of this invention and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0021] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of the invention include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0022] It should be understood that the sequence number of each step in the following embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0023] To illustrate the technical solution of the present invention, specific embodiments are described below.

[0024] With the development of intelligent cockpit and vehicle networking technologies, in-vehicle multimedia systems have gradually evolved from simple music playback devices into comprehensive interactive platforms capable of providing personalized services based on vehicle operating status, driving habits, and environmental information. In actual driving, drivers often have different needs regarding music style, voice interaction methods, interface display formats, and in-car atmosphere in different scenarios such as daily commuting, long-distance driving, driving in the rain, and returning home at night. For example, commuting scenarios prioritize a relaxing and soothing auditory experience, long-distance driving requires alertness and fatigue prevention assistance, rainy conditions necessitate improved clarity of information broadcasts, and the nighttime return home scenario favors a relaxed and comfortable in-car atmosphere. Therefore, how to automatically adjust in-vehicle music and related cockpit configurations based on the vehicle's real-time operating status and driving environment has become an important research direction in the field of intelligent cockpits.

[0025] Existing in-vehicle multimedia control methods typically rely on user-manual playlist selection, preset music style switching, or scene mode control triggered by a single condition. For example, they may automatically switch playlists based on time, adjust volume based on vehicle speed, or recommend specific music content based on navigation status. While some systems can acquire vehicle location, time information, and some environmental sensor data, most rely on independent conditional judgments for music control, lacking comprehensive analysis of driving behavior characteristics, historical travel patterns, and real-time environmental conditions. Furthermore, switching between different scenes often depends on simple threshold judgments, lacking multi-scene conflict handling, priority arbitration, and stability control mechanisms. Therefore, in complex driving environments, inconsistent mode switching or uncoordinated control strategies can easily occur.

[0026] Existing methods typically rely on a single dimension of information for music control decisions, making it difficult to accurately identify the driver's current driving scenario. This results in a low degree of matching between the music content and cockpit control strategies output by the vehicle's infotainment system and actual driving needs. When the vehicle is in scenarios with similar characteristics but different needs, such as weekday commuting versus ordinary city travel, driving in the rain versus driving through tunnels, or long-distance driving versus short-term highway driving, existing methods are prone to misjudgments or frequent switching. This affects the control experience of the vehicle's multimedia system (e.g., music playback) and the human-machine interaction, making it difficult to achieve scenario-based intelligent control based on the collaborative analysis of driving behavior characteristics, historical travel patterns, and environmental conditions.

[0027] To address the aforementioned issues, this application proposes an in-vehicle multimedia control method, device, equipment, medium, and program product. It utilizes driving information such as vehicle speed, location, and time generated during vehicle operation, combined with historical driving records, to analyze user travel patterns and differentiate between different driving states, such as commuting and long-distance travel. Subsequently, it combines windshield wiper status and ambient light information to perceive the external environment and jointly match the driving state with the environmental state to filter candidate modes that match the characteristics of the current scenario. Based on this, a mode priority mechanism further determines the target mode that best meets the current needs, and the corresponding control strategy is invoked to adjust the vehicle's infotainment system accordingly. This application integrates multi-dimensional information such as historical travel patterns, real-time driving behavior, and external environmental conditions for comprehensive decision-making, thus reducing the probability of scenario misjudgment and incorrect mode switching. This makes the adjustments to in-vehicle music, interaction methods, and the cabin environment more aligned with the driver's actual needs, thereby improving driving comfort, immersion, and the human-machine interaction experience.

[0028] The in-vehicle multimedia control method provided in this embodiment of the invention can be applied to, for example... Figure 1The operating environment shown adopts a layered vehicle electronic architecture, with the vehicle controller as the decision-making core. Bidirectional communication between the data acquisition layer and the execution output layer is achieved through the vehicle interface layer. The data acquisition layer consists of a real-time clock, GPS / BeiDou positioning module, vehicle speed signal (CAN bus), wiper signal (CAN bus), light sensor, ignition status signal, and user configuration (such as home address). The real-time clock provides date and time information, GPS / BeiDou provides latitude, longitude, and road level, vehicle speed and ignition signals are used to calculate driving time and driving cycles, wiper and light sensors are used to sense weather and ambient light changes, and user configuration provides personalized judgment criteria for the system. The vehicle controller integrates algorithms for data cleaning, feature extraction, environmental feature fusion, driving behavior integration, multi-dimensional judgment, and state machine and priority arbitration. It is responsible for receiving raw signals from the data acquisition layer, processing them to generate a uniquely activated scenario mode, and issuing control commands through the vehicle interface layer. The vehicle interface layer includes a CAN bus interface, a LIN bus interface, an audio output interface, a display / touch interface, and a network communication interface. The CAN bus is responsible for collecting vehicle signals such as speed, wipers, and ignition, and simultaneously sending control commands to the air conditioning system; the LIN bus is used to communicate with the ambient lighting system; the audio output interface connects to the audio system and the speech synthesis system; the display / touch interface connects to the central control display screen; and the network communication interface (4G / 5G / Wi-Fi) connects to cloud services to obtain real-time traffic conditions, online playlists, and holiday configuration updates. The execution and output layer includes the audio system (music playback and volume adjustment), the speech synthesis system (voice broadcast and tone adjustment), the central control display screen (UI theme switching and information display), the air conditioning system (temperature, fan speed, and airflow direction control), and the ambient lighting system (color, brightness, and dynamic effect control). Each execution unit works collaboratively according to the target control strategy issued by the vehicle controller to achieve an immersive cockpit presentation of scene modes.

[0029] In one embodiment, such as Figure 2 As shown, an in-vehicle multimedia control method is provided, which is applied to... Figure 1 Taking the operating environment of the vehicle as an example, from the perspective of the vehicle controller, the explanation includes the following steps: Step S1: Extract driving feature sequences from the synchronously collected driving dataset, and extract environmental perception feature sequences from the synchronously collected wiper status signals and light sensor signals.

[0030] First, various raw signals constituting the driving dataset are synchronously collected through multiple data channels, including the vehicle's CAN bus, real-time clock chip, and GPS / BeiDou positioning module. The driving dataset is not a single data stream output by a specific piece of hardware on the vehicle, but rather a multi-dimensional data set collected and aggregated in parallel from multiple heterogeneous data sources under a unified time reference by the vehicle's infotainment controller. Specifically, this driving dataset includes raw time fields such as year, month, day, hour, minute, second, and day of the week provided by the real-time clock chip; raw position signals given in latitude and longitude coordinates output by the GPS / BeiDou positioning module; raw vehicle speed signals read from the electronic stability control system or wheel speed sensors via the CAN bus; and ignition status signals read from the body control module. These raw signals physically originate from different sensors and bus nodes, and their sampling frequencies vary—the GPS positioning module typically outputs position data at a frequency of 1Hz, the vehicle speed signal updates on the CAN bus at a frequency of 10Hz or even higher, and the time information from the real-time clock chip is continuously maintained and updated by the vehicle's infotainment system's timer interrupt after being read at system startup. The driving dataset is a comprehensive data set formed by the vehicle controller after associating the raw data from all the above sources according to the same timestamp. Its purpose is to provide a unified and complete raw data input for subsequent feature extraction.

[0031] After acquiring the driving dataset, the vehicle controller first performs time alignment processing on the raw signals in the dataset. Because the sampling times of different sensors are not synchronized—for example, the GPS positioning module outputs location data at the beginning of a second, while the vehicle speed signal may be updated at multiple points within that second—directly mixing these data with different sampling times would lead to inconsistent time bases for feature extraction, thus affecting the accuracy of subsequent calculations such as driving time integration and position matching. To solve this problem, the vehicle controller uses the global time base provided by the system clock as a reference axis and resamples all raw signals in the driving dataset according to their actual sampling timestamps using a linear interpolation method to a unified target time series. The time interval of this target time series is set to 100ms, that is, generating 10 evenly distributed timestamps per second, with each timestamp corresponding to a set of aligned data frames. For data with a high update frequency, such as vehicle speed signals, the sampled value closest to the target timestamp is directly used. For data with a low update frequency, such as GPS location signals, the time interval and position difference between two adjacent valid positioning points are used to perform linear interpolation calculations on longitude and latitude according to the relative position ratio of the target timestamp between the two adjacent positioning points, thereby estimating the calculated position corresponding to the target timestamp. After time alignment processing, the vehicle controller obtains a series of driving data frames arranged in chronological order. Each data frame contains the time field, latitude and longitude coordinates, vehicle speed value, and ignition status at the same moment.

[0032] Subsequently, the vehicle controller extracts the corresponding driving feature sets from each driving data frame according to the preset driving feature types. The driving feature types are the pre-defined data required for driving behavior analysis, specifically including three categories: time features, location features, and vehicle speed features. Under the time feature category, standardized hour, minute, second, and day of the week values ​​are extracted from each data frame; under the location feature category, time-aligned longitude and latitude coordinates are extracted; and under the vehicle speed feature category, the vehicle speed value at that moment is extracted. After extraction, the vehicle controller sorts the driving feature sets corresponding to each data frame in chronological order, forming a driving feature sequence arranged chronologically. Each element in this sequence corresponds to a driving feature vector at a specific moment, and all elements are arranged sequentially from morning to night, thus completely recording the vehicle's state change trajectory during a continuous driving process. The driving feature sequence integrates the time, location, and speed information originally scattered across multiple data frames into an ordered data structure along the time dimension.

[0033] While extracting driving feature sequences, the vehicle controller independently processes the synchronously acquired wiper status signals and light sensor signals for environmental perception feature extraction. The wiper status signal originates from the status message sent by the vehicle's wiper switch via the CAN bus. This message represents the physical position of the wiper lever in the form of enumerated values, including off, intermittent, low-speed continuous, and high-speed continuous. Because the driver may experience brief vibrations when operating the wiper lever, or there may be momentary electrical instability in the wiper switch contacts during position switching, the raw wiper status signal may contain extremely short-duration abnormal jumps, such as rapid back-and-forth between off and intermittent positions. Directly using this raw signal containing vibrations for subsequent environmental determination may lead to frequent erroneous switching in the system's rain mode trigger condition judgment. To eliminate such vibrations, the vehicle controller uses a time window mode smoothing algorithm to process the raw wiper status signal. Specifically, the vehicle controller maintains a 3-second sliding time window. Within this window, 30 wiper status sampling points are collected at 100ms intervals. Each new sampling point is added to the end of the window, and the oldest sampling point at the beginning is removed. Then, the frequency of each wiper setting value among the 30 sampling points in the current window is counted, and the wiper setting value with the highest frequency is output as the wiper status value for that moment. Because the proportion of sampling points with any brief jump within the window cannot exceed the normal state value, the above operation filters out accidental jumps lasting less than 3 seconds, thus statistically suppressing jumps.

[0034] It should be understood that light sensors are typically installed at the bottom of the windshield or behind the rearview mirror. Their output is an analog voltage signal or digital value proportional to the ambient illuminance. The vehicle's infotainment controller reads this raw value through an analog-to-digital converter or digital interface and converts it into an illuminance value in lux (Lux) according to the sensor's factory calibration curve. The raw illuminance signal may experience rapid, instantaneous fluctuations during vehicle operation due to factors such as dappled sunlight, oncoming headlights, and entering / exiting tunnels. These fluctuations often last only a few hundred milliseconds to a second or two. If the raw illuminance value is directly used to determine whether the environment is dark, the vehicle might trigger a dimness detection when passing through a short stretch of shade, and then regain brightness detection less than a second after exiting the shade. This high-frequency fluctuation would cause instability in the conditional judgment of rain or night modes. Therefore, the vehicle's infotainment controller uses a first-order low-pass filter algorithm to process the converted raw illuminance value. The recursive calculation formula for this filter is I... f (t)=αI r (t)+(1 α)I f (t Δt), where I f (t) represents the smoothed illumination value after filtering at the current time t; Ir (t) represents the raw illuminance value read at the current time t; I f (t Δt) is the previous sampling time (t) The filtering result is Δt, where Δt represents the time interval between two adjacent samples; α is the filter coefficient, a dimensionless constant between 0 and 1. The value of the filter coefficient determines the filter's response speed to changes in the original signal. A larger value results in faster tracking of the current original value but weaker smoothing effect, while a smaller value results in stronger smoothing effect but slower response to changes in the original signal. In this method, α is set to 0.2, corresponding to a filter time constant of approximately 0.5s at a sampling period of 100ms. This parameter combination can effectively filter out high-frequency noise while maintaining a reasonable tracking speed for changes in real ambient light. After low-pass filtering, the vehicle controller obtains a smoothed illumination value, which eliminates instantaneous spikes and rapid fluctuations in the original signal, more realistically reflecting the overall level of ambient light.

[0035] After smoothing the wiper status signal and low-pass filtering the light sensor signal, the vehicle controller aligns the obtained wiper status values ​​and smoothed illumination values ​​according to their actual sampling time sequence. The sampling times of the wiper status signal and the light sensor signal are not synchronized—the transmission period of the wiper status message on the CAN bus may differ from the data acquisition period of the light sensor. If the values ​​at their respective sampling times are directly paired, the time base for pairing will be inconsistent. Specifically, using the global time axis of the system clock as a reference, the wiper status value and smoothed illumination value are interpolated or mapped to a unified target time series, ensuring that a wiper status value and a smoothed illumination value exist simultaneously at each target timestamp. After alignment, the vehicle controller organizes the wiper status values ​​and smoothed illumination values ​​at each time point into an environmental perception feature sequence in chronological order. Each element in this sequence contains both the wiper status component and the illumination component at the same time point, and all elements are arranged chronologically, completely recording the trajectory of environmental perception-related signals over time. The environmental perception feature sequence constitutes the two conditions required to determine the rainy weather mode: "whether the wipers are on" and "whether the environment is dark".

[0036] Step S2: Analyze the driving behavior of the driving feature sequence based on the preset historical driving database to generate a current driving status marker.

[0037] It should be understood that the driving feature sequence is merely a collection of raw observation data arranged in chronological order, containing key information such as vehicle speed, latitude and longitude coordinates, time field, and ignition status at each moment. However, this data has not yet been assigned any semantic meaning related to driving behavior. Step S2 of this application, based on the driving feature sequence, performs behavioral analysis and state identification on the vehicle driving process recorded in the sequence, thereby generating a current driving state label to characterize the user's current driving behavior. For example, it extracts behavioral features from this sequence in three dimensions: "how long has the vehicle been driving continuously," "what type of road is the vehicle currently driving on," and "whether the current trip belongs to the user's daily commuting behavior," and combines them into a structured current driving state label.

[0038] Among the various types of information contained in the driving feature sequence, vehicle speed information is the direct data source for calculating driving duration features. The vehicle controller reads the vehicle speed and ignition status values ​​recorded in each data frame of the driving feature sequence in chronological order, and calculates the segmented cumulative driving duration based on these values. Since vehicles may experience situations where their speed is zero but the engine is not turned off due to waiting at traffic lights, traffic jams, or temporary stops to pick up or drop off passengers, these brief periods of stopping and waiting are still part of the driving activity. During these times, the driver does not get effective rest, and fatigue continues to accumulate. Therefore, directly using the simple time difference from ignition time to the current time as driving duration is unreasonable. However, if the vehicle is stationary for a long time while the engine remains running, it may mean that the driver is resting or waiting for a considerable period. Continuing to include the parking time in the driving duration would lead to misjudgment of fatigue levels. Based on this, the segmented cumulative driving duration method adopted by the vehicle controller introduces a parking time threshold determination mechanism. Specifically, the vehicle controller traverses the driving feature sequence from its starting position, performing the following judgment for each data frame: If the ignition status of the current frame is on and the vehicle speed is greater than zero, the time period of that frame is included in the driving time; if the ignition status of the current frame is on and the vehicle speed is zero, a parking timer is started to record the duration of continuous zero speed. When this duration is less than 900 seconds, the parking time period continues to be included in the driving time. When the duration reaches or exceeds 900 seconds, the parking timer is reset to zero and the starting point for the accumulation of driving time is reset to the current time, after which the accumulation restarts. 900 seconds, or 15 minutes, is a threshold set based on the human body's fatigue recovery pattern and driving rest recommendations. Continuous parking exceeding 15 minutes usually indicates that the driver has intentionally taken a rest, and the fatigue timer should restart at this time. Through the above segmented accumulation method, after traversing the entire driving feature sequence, the vehicle controller obtains the driving time feature of the current trip. This feature, in seconds, accurately reflects the cumulative length of time the driver was actually in a driving state or in a short-term parking and waiting state during this trip. Driving duration features will be used to match the triggering conditions of long-distance mode. In this embodiment, the determination condition for long-distance mode is whether continuous driving has exceeded 1 hour.

[0039] While calculating driving duration features, the vehicle controller obtains the road classification of the current road based on the location information in the driving feature sequence. Location information exists in the form of latitude and longitude coordinates in each data frame of the driving feature sequence, but latitude and longitude coordinates themselves only represent a point on the Earth's surface and cannot directly indicate what type of road that point is located on. To convert latitude and longitude coordinates into road classification information with traffic engineering semantics, the vehicle controller invokes a preset digital map matching function. This digital map is pre-stored in the vehicle system's local storage medium and contains road network data covering commonly used driving areas. Each road link is labeled with its road classification attribute, such as highway, national highway, provincial highway, urban expressway, urban arterial road, urban secondary arterial road, etc. The specific map matching process is as follows: the vehicle controller extracts the current latitude and longitude coordinates from the driving feature sequence and passes these coordinates as input to the digital map engine. The map engine searches the road network data for a road link that is spatially closest to this coordinate point and whose angle between the vehicle's driving direction and the road direction is less than a preset angle threshold. Then, it returns the road classification attribute of this road link as the matching result. During actual driving, a vehicle may be located at the intersection of multiple roads or near parallel roads. In such cases, matching based solely on the nearest spatial distance may lead to ambiguity. Therefore, the map engine also refers to the vehicle's historical location trajectory from previous moments during matching to determine which road the vehicle is most likely actually traveling on. This trajectory continuity-based matching method effectively reduces erroneous matching caused by GPS positioning errors or dense road areas. After map matching processing, the vehicle controller obtains the road level information corresponding to the current trip. This road level information will be used in two scenarios: firstly, in determining long-distance travel, it is necessary to confirm whether the vehicle is traveling on a highway; secondly, when counting commuting trips, it serves as an auxiliary condition to verify whether the current trip is consistent with historical commuting records.

[0040] After calculating driving duration characteristics and acquiring road classifications, the vehicle controller performs statistical operations on the user's commuting frequency. Commuting refers to the regular travel behavior of a user between their residence and workplace during fixed weekday morning and evening rush hours along a fixed route. Identifying commuting behavior is crucial for triggering commuting modes, as these modes should only be activated during weekday peak hours when the vehicle is traveling on the user's usual commuting route. The vehicle controller extracts location and time information from the driving characteristic sequence and compares it with historical driving records in a pre-set historical driving database to determine whether the current trip belongs to a commuting record.

[0041] The historical driving database is a local data storage system continuously accumulated by the vehicle's infotainment system (V2S) over long-term use. It records key information for each of the user's historical trips, including the start and end times of the trip, the sequence of road links traversed, the weekday value corresponding to the trip's start time, and the road classification involved. The V2S first matches the location information in the driving feature sequence with road links in a preset digital map to determine the route identifier for the current trip. Specifically, the latitude and longitude coordinates of all data frames in the driving feature sequence are input into the digital map engine for road link matching, obtaining the road link number where the vehicle is located at each moment. Then, the frequency and order of each road link number throughout the entire trip are counted, and the consecutive road link sequence with the highest frequency is used as the route identifier for the current trip. After obtaining the route identifier for the current trip, the V2S uses this route identifier as an index to query the historical driving database, counting the total number of times the route identifier has appeared in the past 30 calendar days. If the number of times the route identifier appears exceeds a preset high-frequency route threshold, for example, appearing more than 10 times in 30 days, then the route identifier is marked as a historical high-frequency route. Among them, the frequency threshold of high-frequency routes is based on the regularity of commuting behavior of 5 days / week. Within 30 calendar days, there are approximately 20 to 22 working days. If a certain route is used repeatedly for more than 10 days during working days, it is sufficient to indicate that the route is one of the user's daily commuting routes.

[0042] After determining that the route corresponding to the current trip belongs to a historically high-frequency route, the vehicle controller extracts all historical driving records corresponding to this historically high-frequency route from the historical driving database, and reads the stored historical trip start time and corresponding historical week value from each record (this embodiment takes a weekend as an example). Simultaneously, the vehicle controller extracts the current trip start time from the time information of the driving feature sequence. This start time is defined as the moment when the vehicle speed first exceeds zero after the ignition state switches from off to on. Subsequently, the vehicle controller calculates the difference between the current trip start time and the historical trip start times in each historical driving record, i.e., it calculates the absolute value of the time difference between the two to obtain the time difference corresponding to each historical driving record. At the same time, the vehicle controller compares the week value corresponding to the current trip start time with the historical week values ​​in each historical driving record to determine whether they point to the same week number. This week-based verification is necessary because commuting behavior has a clear week-based regularity. While a trip on Monday morning and a trip on Saturday morning may occur at the same time, their purposes and natures are completely different. If the week value is not distinguished, non-commuting trips on weekends will be incorrectly counted as commuting trips.

[0043] The vehicle controller filters all historical driving records, selecting those with a time difference less than or equal to a preset time deviation threshold and consistent weekday matching. These selected records are designated as candidate commuting records. The time deviation threshold is typically set at 30 minutes, allowing a deviation of no more than 30 minutes between the start time of the current trip and the start time of a historical trip. This tolerance covers normal variations caused by factors such as daily road conditions and human-induced fluctuations in departure times. After obtaining candidate commuting records, the vehicle controller further verifies whether the road level of the current trip matches the historical road level stored in each candidate commuting record. Even if two trips have the same route identifier and match in both time and weekday, if the current trip is redirected to an alternative route with a different road level due to traffic control or road construction, the commuting attribute of that trip should be questioned. Only when the road level matches the historical road level stored in the candidate commuting record is the vehicle controller recognized as a commuting record. The vehicle controller then accumulates and counts all historical driving records identified as commuting records, and the total number obtained is the user's commuting count within the current statistical period.

[0044] After calculating driving duration characteristics, acquiring road level information, and counting commuting times, the vehicle controller combines the information from these three dimensions into a current driving status marker according to a preset marker format. This marker is a structured data object containing a driving duration field, whose value is the cumulative number of seconds calculated in the aforementioned segments; a road level field, whose value is the road level code returned by digital map matching; and a commuting times field, whose value is the cumulative value obtained from the aforementioned comparison and statistics.

[0045] Step S3: Based on the current driving state marker and the environmental perception feature sequence, select a set of candidate driving modes from the preset driving modes and feature set.

[0046] The current driving status flag includes driving duration, road grade, and commuting frequency, representing the vehicle's current driving behavior state. The environmental perception feature sequence includes wiper status values ​​and smoothing light values, representing the vehicle's current external environmental conditions. The driving mode and feature set is a rule base pre-stored in the vehicle controller's local memory, defining the trigger conditions for each scenario mode. Each trigger condition is composed of several decision factors combined according to logical AND / OR relationships. The vehicle controller needs to compare the current actual data with these preset conditions one by one to determine which scenario modes are eligible to be activated at the current moment.

[0047] In this embodiment, the preset driving modes and feature sets include four scenario modes, which are divided into two categories: a first mode group and a second mode group. The first mode group includes commuting mode and long-distance mode. The triggering determination of these two modes mainly depends on the vehicle's own driving status characteristics, that is, on the fields in the current driving status marker. The triggering condition for commuting mode is defined as the simultaneous satisfaction of three determination factors: weekday marker is true, peak hour marker is true, and repetitive commuting route marker is true. The weekday marker is determined by the weekday value at the current time. The marker is valid when the weekday value is any day from Monday to Friday, but exceptions caused by statutory holidays need to be excluded. The vehicle controller corrects the weekday marker by obtaining the holiday configuration file through the network. The peak hour marker is determined by the hour and minute values ​​at the current time. The marker is valid when the time falls within the interval of 7:00 to 9:00 AM or 5:00 to 9:00 PM. The repetitive commuting route marker is directly taken from the number of commutes in the current driving status marker. When the number of commutes is greater than zero, it means that the current route matches the historical high-frequency route and the time and weekday are both verified, and the marker is valid. The commuting mode trigger condition is only determined to be met when all three determination factors are true. When the trigger condition is met, the vehicle controller assigns a base confidence value to the commuting mode, which is set to 1.0, indicating that the trigger condition is fully met. The reason for this confidence value is that the three determination factors of the commuting mode are all discrete Boolean logic variables, and there are no partially satisfied intermediate states; therefore, its confidence value does not have a continuously changing characteristic.

[0048] The trigger condition for long-distance driving mode is defined as the simultaneous fulfillment of two decision factors: driving duration greater than 1 hour and the current road classification being a highway. The driving duration feature is directly read from the current driving status marker, representing the cumulative length of time the driver has been continuously driving or briefly stopped and waiting. When this duration exceeds 1 hour, the first decision factor is met. The road classification field is also read from the current driving status marker; when this field's value is the code corresponding to a highway, the second decision factor is met. Only when both decision factors are met simultaneously is the trigger condition for long-distance driving mode deemed satisfied. Unlike commuting mode, the confidence value for long-distance driving mode is not a simple 0 or 1, but rather a continuous calculation based on the actual driving duration. Specifically, the ratio of the current driving duration to 2 hours represents a typical intensity reference value for long-distance driving. When the driving duration reaches 2 hours, the confidence value reaches its upper limit of 1.0; when the driving duration is exactly 1 hour, the confidence value is 0.5. Through this continuous confidence calculation, the system can trigger the long-distance mode with a low confidence level when the driving time just exceeds the one-hour threshold. As the driving time increases, the confidence level gradually increases, providing a refined quantitative basis for weighted arbitration in the event of multi-mode conflicts.

[0049] The second mode group includes Rain Mode and Nighttime Homecoming Mode. The triggering of these two modes primarily relies on external environmental perception data, specifically the wiper status value and smoothed illumination value from the environmental perception feature sequence. The Nighttime Homecoming Mode also utilizes the location information implicit in the current driving status marker. The triggering condition for Rain Mode is defined as the simultaneous fulfillment of two judgment factors: wipers are on and ambient illumination is dim. The wiper status value comes from the wiper feature component in the environmental perception feature sequence. The first judgment factor is valid when this value is in any of the intermittent, low-speed continuous, or high-speed continuous settings. The smoothed illumination value comes from the illumination component in the environmental perception feature sequence, reflecting the intensity of the current ambient light. To determine if the environment is dim, the vehicle controller compares the smoothed illumination value with a preset low illumination threshold. When the smoothed illumination value remains below 50 Lux for at least 2 seconds, the dimness flag is set to true. The 2-second duration requirement is to avoid false triggering caused by a sudden drop in light when the vehicle passes through tunnel entrances or dappled shaded areas, ensuring that the rain mode is not disturbed by brief fluctuations in light. When both of the above determination factors are met simultaneously, the triggering condition for the rain mode is determined to be satisfied, and its confidence value is set to 1.0, because both the conditions of wiper activation and ambient darkness are discrete Boolean states, not involving continuously changing intermediate quantities.

[0050] The trigger condition for the nighttime homecoming mode is defined as the simultaneous fulfillment of two judgment factors: the current time is nighttime and the distance between the current location and the preset home address is less than 1×10. 4 Meters. The nighttime period is determined by the hour value of the current moment. This determination factor is valid when the hour value is greater than or equal to 20 or less than 5, i.e., from 8 PM to 5 AM the following day. The distance calculation between the current location and the home address requires extracting the latitude and longitude coordinates of the current moment from the driving feature sequence and combining them with the user's preset home address coordinates in the system for spherical geometric calculation. The calculation formula uses the Havesing formula, which can accurately calculate the great circle distance between two points on the Earth's sphere. When the calculated distance value is less than 1 × 10⁻⁶, the calculation is considered valid. 4 The second decision factor is valid when the distance reaches 10 meters (i.e., 10 kilometers). When both decision factors are valid, the triggering condition for the nighttime homecoming pattern is considered met. The confidence level is calculated as 1 × 10⁻⁶. 4 Subtract the current distance value from the meter and divide by 1 × 10 4The confidence score is calculated in meters, meaning the closer the vehicle is to the home address, the higher the confidence score. A confidence score of 1.0 is given when the vehicle is exactly at the home address, and 0 is given when the vehicle is 10 kilometers away. This continuous confidence score calculation is designed so that the demand for triggering the nighttime homecoming mode is weaker when the vehicle is far from the home address. As the vehicle gets closer to the residence, the rationality and urgency of triggering this mode gradually increase, and the continuous confidence score smoothly reflects this gradual change.

[0051] The vehicle controller aggregates the triggering results of the four scenario modes to construct a candidate driving mode set. Specifically, the vehicle controller checks the triggering condition judgment results of commuting mode, long-distance mode, rainy weather mode, and nighttime return home mode one by one, and adds all modes whose triggering conditions are determined to be met, along with their corresponding confidence values, into the candidate driving mode set. Modes whose triggering conditions are not met are not included in this set. After completing the collection of candidate modes, the vehicle controller further performs a confidence threshold filtering operation. This filtering operation is used to exclude edge cases where the triggering conditions are logically true but the confidence is too low, avoiding the instability that may be caused by the system reacting when the conditions just reach the threshold. The vehicle controller compares the confidence value of each mode in the candidate driving mode set with a preset confidence threshold, which is set to 0.5. If the confidence value of a mode is greater than 0.5, the mode is retained in the candidate set; if the confidence value is less than or equal to 0.5, the mode is removed from the candidate set. After this filtering operation, only those scenario modes that fully meet the triggering conditions and have a sufficiently high confidence level are retained in the candidate driving mode set. These retained modes, along with their corresponding confidence values ​​(i.e., candidate confidence values), will be passed to step S4 as input data for state machine arbitration and mode switching decisions.

[0052] Step S4: Determine the target driving mode from the candidate driving mode set according to the preset mode priority, and match the corresponding target control strategy from the preset vehicle control decision set according to the target driving mode, so as to adjust the preset multimedia vehicle system according to the target control strategy.

[0053] The candidate driving modes in the candidate driving mode set are sorted according to the preset mode priority to obtain the mode priority sequence; Based on the candidate confidence values ​​and the mode priority sequence, a weighted arbitration is performed on each candidate driving mode in the candidate driving mode set to obtain the target driving mode; Based on the target driving mode, a target control strategy corresponding to the target driving mode is matched from a preset vehicle control decision set; The preset multimedia vehicle system is adjusted in conjunction with the target control strategy.

[0054] It should be understood that the candidate driving mode set may contain zero, one, or more candidate modes. When the candidate set is empty, it means that the triggering conditions for any scenario mode are not currently met, and the vehicle controller should maintain the default mode, i.e., not perform any special scenario-based adjustments. When the candidate set contains only one candidate mode, that mode is directly determined as the target driving mode. When the candidate set contains multiple candidate modes, the vehicle controller needs to conduct comprehensive arbitration based on preset priority rules and confidence values ​​to determine the only mode that should be activated. Since environmental conditions and vehicle states in actual driving scenarios are often complex, the triggering conditions for multiple scenario modes may be met simultaneously. For example, at 8 PM on a weekday, a user drives on a highway 8 kilometers from their home address. At this time, it is past 8 PM, the location is less than 10 kilometers from the home address, and the vehicle has been driving continuously for more than 1 hour on a highway. In this case, the conditions for the nighttime homecoming mode and the long-distance mode are both met. If it happens to be raining at this time, the conditions for the rainy day mode are also met simultaneously. These three modes correspond to different multimedia control effects (e.g., music style, voice tone, air conditioning behavior, and ambient lighting). If executed simultaneously without arbitration, it will cause the vehicle's infotainment system to output conflicting commands. For example, the audio system might be required to play jazz and upbeat music simultaneously, or the air conditioning might be required to enter anti-drowsy mode and maintain normal operation at the same time. Therefore, the vehicle's infotainment controller must select the mode that best suits the current scenario from multiple candidate modes.

[0055] The vehicle controller first sorts the candidate driving modes in the candidate driving mode set according to a preset mode priority, obtaining a mode priority sequence. The preset mode priorities are determined by the principle of safety and environmental priority, from highest to lowest: rain mode, long-distance mode, nighttime return mode, and commuting mode. This order is based on the fact that rain mode is directly related to driving safety under conditions of windshield wipers and low light, and is highly correlated with driving visibility and operational safety, therefore it is given the highest priority. Long-distance mode involves alleviating driver fatigue and is also closely related to driving safety, but its corresponding risk level is lower than that of rainy conditions, so it is ranked second. Nighttime return mode and commuting mode mainly involve driving comfort and personalized experience, and their impact on driving safety is relatively indirect, so they are ranked third and fourth, respectively. The vehicle controller sorts all modes in the candidate set according to this fixed priority hierarchy, with higher priority modes listed first and lower priority modes listed last, forming a mode priority sequence.

[0056] After obtaining the sorted priority sequence of modes, the vehicle controller performs weighted arbitration based on the confidence value of each candidate mode and the priority sequence to ultimately determine the target driving mode. This weighted arbitration does not simply select the mode with the highest priority or the highest confidence, but rather employs a hierarchical arbitration strategy that considers both safety priority and trigger confidence. Specifically, the vehicle controller checks each candidate mode in descending order of priority. When checking a mode of a certain priority, the vehicle controller reads the confidence value assigned to that mode and compares it with a preset high confidence threshold, which is set to 0.7. If the confidence value of the current candidate driving mode is greater than or equal to 0.7, the vehicle controller immediately determines that mode as the target driving mode and does not check subsequent lower priority modes. If the confidence value of the current candidate driving mode is less than 0.7, the mode is skipped, and the system continues to check the next priority mode. Since the confidence score reflects the sufficiency of the triggering conditions for a mode, a low confidence score means that the triggering conditions are barely met but are in a boundary state. In this case, it is more reasonable to let the low-priority but high-confidence mode win than to let the high-priority but insufficient-confidence mode win. For example, in a scene with light rain but not significantly dim lighting in rain mode, the wipers are on but the smoothed illumination value is slightly below 50 Lux. In this case, the confidence score of rain mode is 1.0 because both decision factors in its triggering conditions are strictly met. However, the confidence score of long-distance mode may be only 0.6. In this case, the high confidence threshold of 0.7 causes long-distance mode to be skipped due to insufficient confidence, while rain mode is successfully selected because its confidence score of 1.0 is greater than 0.7. This is in line with the general principle of prioritizing safety.

[0057] After determining the target driving mode, the vehicle control controller matches the corresponding target control strategy from a preset vehicle control decision set. The vehicle control decision set is a mapping table pre-stored in the vehicle control controller's local memory, using scenario modes as index keys and a set of specific control parameters as index values. Each scenario mode corresponds to a complete control strategy record in this mapping table, containing control parameters in five dimensions: audio playback strategy, voice synthesis strategy, central control display strategy, air conditioning control strategy, and ambient lighting control strategy. The audio playback strategy specifies the song tags to be played; for example, commuting mode corresponds to tracks tagged as relaxing, white noise, and light music; long-distance mode corresponds to tracks tagged as high-tempo; rainy day mode corresponds to tracks tagged as rain ambient sounds; and nighttime homecoming mode corresponds to tracks tagged as soft jazz. The voice synthesis strategy specifies the volume gain coefficient, pitch offset, and tone template type for voice output; for example, commuting mode uses a short command template with constant volume, while rainy day mode sets the volume gain to 20% and the pitch to 20%. The central control display strategy specifies the paths to the interface theme files and touch feedback sound effect files. For example, the rain mode corresponds to a large button theme and a water droplet touch feedback sound effect. The air conditioning control strategy specifies the temperature adjustment value, fan speed level, and airflow mode. For example, the long-distance mode corresponds to the intermittent facial cooling control command in the anti-drowsy mode. The ambient lighting control strategy specifies the color code and dynamic effect parameters. For example, the nighttime homecoming mode corresponds to a warm yellow breathing gradient effect. The vehicle controller uses the name of the target driving mode as the query key, performs a precise matching query in the vehicle control decision set, and combines the five-dimensional control parameters returned by the query results as the target control strategy.

[0058] After obtaining the target control strategy, the vehicle controller adjusts the preset multimedia vehicle system accordingly. The multimedia vehicle system comprises five independent execution subsystems: an audio system, a voice synthesis system, a central control display, an air conditioning system, and an ambient lighting system. These five subsystems are connected to the vehicle controller via audio output interfaces, display touch interfaces, CAN bus interfaces, and LIN bus interfaces in the vehicle interface layer. The vehicle controller parses the five-dimensional control parameters in the target control strategy into specific instructions for each subsystem and sends them to the respective execution subsystems through the corresponding interfaces. For example, the audio playback strategy is parsed into song tag query instructions and playback control instructions. The vehicle controller sends a playback request containing the tag category to the audio system. Upon receiving the request, the audio system retrieves tracks matching the tags from the local song database or cloud streaming service and begins sequential playback, while simultaneously adjusting the audio amplifier gain coefficient according to the volume value specified in the target control strategy. The speech synthesis strategy is parsed into speech engine configuration commands. The vehicle controller sends volume gain parameters and pitch offset parameters to the speech synthesis system. Upon receiving the parameters, the speech synthesis system adjusts the fundamental frequency and amplitude of the speech output in real time to ensure that the volume and pitch of subsequent speech matches the requirements of the target mode. The central control display strategy is parsed into UI theme switching commands and touch feedback configuration commands. The vehicle controller sends the loading path of the interface theme file and the path of the touch feedback sound effect file to the central control display. Upon receiving the commands, the central control display reads the corresponding theme resources from local storage and re-renders the display interface, while replacing the touch operation feedback sound effect with the sound effect sample specified in the target file. The air conditioning control strategy is parsed into CAN bus control messages. The vehicle controller encapsulates the temperature adjustment value, fan speed level, and airflow mode into a standard format CAN message according to the air conditioning controller's communication protocol and sends it to the air conditioning control unit through the CAN bus interface. After parsing the message, the air conditioning control unit drives the damper motor and blower to perform the corresponding actions. The ambient lighting control strategy is parsed into LIN bus control commands. The vehicle controller encapsulates the color code and dynamic mode parameters into LIN messages and sends them to the ambient lighting control module via the LIN bus interface. Upon receiving the commands, the ambient lighting control module drives each LED to output according to the specified color and breathing gradient cycle. When executing the above-mentioned linkage adjustment, the vehicle controller sends commands sequentially in the order of audio system priority over display and voice systems, and display and voice systems priority over air conditioning and ambient lighting systems, with a 100ms interval between each command to avoid communication conflicts caused by multiple commands occupying the bus simultaneously. Through the sequential command issuance, the various execution subsystems of the multimedia vehicle system work together to complete a comprehensive contextual switching from audio content to visual interface to the in-vehicle environment, ultimately presenting the driver and passengers with an immersive cockpit experience that matches the current driving scenario.

[0059] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0060] In one embodiment, an in-vehicle multimedia control device is provided, which corresponds one-to-one with the in-vehicle multimedia control method described in the above embodiments. For example... Figure 3 As shown, the in-vehicle multimedia control device 2 may include: a data acquisition module 21, a behavior analysis module 22, a pattern candidate module 23, a pattern decision module 24, and an in-vehicle system adjustment module 25. Detailed descriptions of each functional module are as follows: The acquisition and extraction module 21 is used to extract driving feature sequences from the synchronously acquired driving dataset and to extract environmental perception feature sequences from the synchronously acquired wiper status signal and light sensor signal. The behavior analysis module 22 is used to perform driving behavior analysis on the driving feature sequence based on a preset historical driving database and generate a current driving state marker; The mode candidate module 23 is used to filter out a set of candidate driving modes from a preset driving mode and feature set based on the current driving state marker and the environmental perception feature sequence. The mode decision module 24 is used to determine the target driving mode from the candidate driving mode set according to the preset mode priority, and to match the corresponding target control strategy from the preset vehicle control decision set according to the target driving mode. The vehicle infotainment system adjustment module 25 is used to adjust the preset multimedia vehicle infotainment system according to the target control strategy.

[0061] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.

[0062] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0063] This application also provides a computer device, such as... Figure 4 As shown, the computer device includes: at least one processor 32, a memory 31, and a computer program stored in the memory 31 and executable on the at least one processor 32. When the processor 32 executes the computer program, it implements the steps in any of the above method embodiments, or when the processor 32 executes the computer program, it implements the functions of each module / unit in the above device embodiments.

[0064] For example, the computer program may be divided into one or more modules / units, which are stored in the memory 31 and executed by the processor 32 to complete this application. The one or more modules / units may be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of the computer program in the computer device.

[0065] Those skilled in the art will understand that Figure 4 The computer device described is merely an example and does not constitute a limitation on the computer device. It may include more or fewer components than shown, or combine certain components, or different components. For example, the computer device may also include input / output devices, network access devices, buses, etc.

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

[0067] The memory 31 can be an internal storage unit of the computer device, such as a hard drive or memory. The memory 31 can also be an external storage device of the computer device, such as a plug-in hard drive, Smart Media Card (SMC), Secure Digital (SD) card, or Flash Card. Furthermore, the memory 31 can include both internal and external storage units of the computer device.

[0068] This application also provides a readable storage medium storing a computer program that, when executed by a processor, implements the steps described in the various method embodiments above.

[0069] This application provides a computer program product that, when run on an electronic device, enables the electronic device to perform the steps described in the various method embodiments above.

[0070] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying computer program code to a photographing device / terminal device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

[0071] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0072] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0073] In the embodiments provided in this application, it should be understood that the disclosed apparatus / devices and methods can be implemented in other ways. For example, the apparatus / device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0074] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0075] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A vehicle-mounted multimedia control method, characterized in that, The method includes: Driving feature sequences are extracted from synchronously collected driving datasets, and environmental perception feature sequences are extracted from synchronously collected wiper status signals and light sensor signals. Based on a preset historical driving database, the driving feature sequence is analyzed to generate a current driving status marker. Based on the current driving state marker and the environmental perception feature sequence, a candidate driving mode set is selected from the preset driving mode and feature set; The target driving mode is determined from the candidate driving mode set according to the preset mode priority, and the corresponding target control strategy is matched from the preset vehicle control decision set according to the target driving mode, so as to adjust the preset multimedia vehicle system according to the target control strategy.

2. The vehicle multimedia control method as described in claim 1, characterized in that, The step of extracting driving feature sequences from synchronously acquired driving datasets and extracting environmental perception feature sequences from synchronously acquired wiper status signals and light sensor signals includes: The collected driving dataset is time-aligned to obtain driving data frames corresponding to each timestamp; According to the preset driving feature type, the corresponding driving feature set is extracted from the driving data frame, and the driving feature set is sorted according to the time sequence to obtain the driving feature sequence. The collected wiper status signal is smoothed through a preset time window to obtain the wiper status value, and the collected light sensor signal is low-pass filtered to obtain the smoothed illumination value. The wiper status values ​​and the smoothed illumination values ​​are aligned according to time sequence to obtain an environmental perception feature sequence.

3. The vehicle multimedia control method as described in claim 1, wherein the driving feature sequence includes vehicle speed information, driving duration, location information, and time information, characterized in that, The step of analyzing the driving behavior sequence based on a preset historical driving database to generate a current driving state marker includes: The driving time is calculated in segments based on vehicle speed information to obtain driving time characteristics. The driving time is then matched with a preset digital map based on location information to obtain the road level. Based on the road grade and time information, the driving feature sequence is compared with historical driving records in a preset historical driving database to count the number of times a user commutes. The driving duration feature, the road grade, and the number of commutes are combined into a current driving status marker according to a preset marking format.

4. The vehicle multimedia control method as described in claim 2, characterized in that, The step of selecting a candidate driving mode set from a preset driving mode and feature set based on the current driving state marker and the environmental perception feature sequence includes: Based on the commuting frequency, driving duration features, and road grade in the current driving status marker, the current driving status marker is matched with each first mode in the preset driving mode and feature set by rules to obtain the confidence value corresponding to each first mode. Based on the wiper status value and the smooth illumination value, the environmental perception feature sequence is matched with each second mode in the driving mode and feature set to obtain the confidence value corresponding to each second mode. From the first mode and the second mode, select a set of candidate driving modes whose confidence values ​​are greater than a preset confidence threshold, and record the candidate confidence values ​​corresponding to each mode in the set of candidate driving modes.

5. The in-vehicle multimedia control method as described in claim 4, characterized in that, The step of determining a target driving mode from the candidate driving mode set according to a preset mode priority, and matching a corresponding target control strategy from a preset vehicle control decision set according to the target driving mode, so as to adjust the preset multimedia vehicle system according to the target control strategy, includes: The candidate driving modes in the candidate driving mode set are sorted according to the preset mode priority to obtain the mode priority sequence; Based on the candidate confidence values ​​and the mode priority sequence, a weighted arbitration is performed on each candidate driving mode in the candidate driving mode set to obtain the target driving mode; Based on the target driving mode, a target control strategy corresponding to the target driving mode is matched from a preset vehicle control decision set; The preset multimedia vehicle system is adjusted in conjunction with the target control strategy.

6. The vehicle multimedia control method as described in claim 3, characterized in that, The step of comparing the driving feature sequence with historical driving records in a preset historical driving database based on the road grade and time information to count the user's commuting frequency includes: Based on the location information, the historical high-frequency routes corresponding to the driving feature sequence are determined by matching the road links in the preset digital map. Based on the historical high-frequency routes, extract the historical trip start time corresponding to the historical high-frequency routes; Based on the time information, the current trip start time corresponding to the driving feature sequence is extracted, and the current trip start time is compared with the historical trip start time to obtain the time period matching value; When the road level meets the preset commuter road level and the time period matching value is less than or equal to the preset time deviation threshold, the historical driving record corresponding to the historical high-frequency route is determined as a commuter record, and the user's commuting frequency is counted based on the cumulative number of commuter records.

7. A vehicle-mounted multimedia control device, applied to the vehicle-mounted multimedia control method of claim 1, characterized in that, The device includes: The acquisition and extraction module is used to extract driving feature sequences from the synchronously acquired driving dataset and to extract environmental perception feature sequences from the synchronously acquired wiper status signals and light sensor signals. The behavior analysis module is used to perform driving behavior analysis on the driving feature sequence based on a preset historical driving database and generate a current driving status marker. The mode candidate module is used to filter out a set of candidate driving modes from a preset driving mode and feature set based on the current driving state marker and the environmental perception feature sequence. The mode decision module is used to determine the target driving mode from the candidate driving mode set according to the preset mode priority, and to match the corresponding target control strategy from the preset vehicle control decision set according to the target driving mode. The vehicle infotainment system adjustment module is used to adjust the preset multimedia vehicle infotainment system according to the target control strategy.

8. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the in-vehicle multimedia control method as described in any one of claims 1 to 6.

9. A readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the in-vehicle multimedia control method as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the in-vehicle multimedia control method as described in any one of claims 1 to 6.

Images