A linkage method and system of a vehicle-mounted instrument, an electronic device and a storage medium

Abstract

The application provides a linkage method and system of a vehicle-mounted instrument, an electronic device and a storage medium, comprising: a first processor matching a binding path corresponding to each UI control with a data source path of all CAN signals in a configuration table; the first processor establishing data association between each UI control and a corresponding CAN signal based on a matching result; and the first processor triggering a second processor to drive a display chip to perform a corresponding interface rendering operation on at least one UI control associated with a target CAN signal based on a historical physical value of a buffer currently in a reading state in a shared memory, so that the CAN signal is linked with the UI interface, if the first processor determines that a current physical value of the target CAN signal is different from the historical physical value of the buffer currently in a writing state in the shared memory. The application realizes linkage between the CAN signal and the UI interface without hard coding.

Description

Technical Field

[0001] This application relates to the field of vehicle technology, and in particular to a linkage method, system, electronic device and storage medium for an in-vehicle instrument panel. Background Technology

[0002] In-vehicle instrument cluster software development typically relies on firmware hard-coding to implement CAN signal parsing and UI (User Interface) data binding. Specifically, during CAN signal parsing, all parameters are fixed in the program as code; in terms of UI development, the interface layout, control properties, animation effects, and data binding logic all need to be implemented in code using programming languages ​​such as C / C++ or Qt; the interaction between CAN data and UI controls is relayed through intermediate layers such as message queues, callback functions, and business logic code.

[0003] However, the above technical architecture has at least the following drawbacks: First, when adapting CAN signals to different vehicle models, it is necessary to manually modify the underlying code, recompile and burn the signal, and use professional tools for debugging. The process is cumbersome, time-consuming, and risky. Second, changes to the UI interface solution require redevelopment, making it impossible to directly deploy the UI interface design, resulting in high customization costs. Third, the CAN signal and the UI interface are independent of each other, and the data link needs to go through multiple layers of code. The binding relationship is complex, the maintainability is poor, the failure rate is high, and it is impossible to achieve direct data linkage. Summary of the Invention

[0004] In view of this, embodiments of this application provide a linkage method, system, electronic device and storage medium for vehicle instrument clusters, which realizes the linkage between CAN signals and UI interface without hard coding.

[0005] This application mainly includes the following aspects: In a first aspect, embodiments of this application provide a linkage method for an in-vehicle instrument cluster, the linkage method being applied to an in-vehicle instrument cluster linkage system; the linkage system includes: a first processor, a second processor, shared memory, and a display chip; the linkage method includes: After the first processor is powered on, it reads the CAN signal configuration file from the external storage device and constructs a configuration table containing configuration information for multiple CAN signals based on the CAN signal configuration file; wherein, the configuration information includes: the data source path of the CAN signal; After the second processor is powered on, it reads the UI resource package from the external storage device and constructs a UI object tree based on the UI resource package. For each UI control in the UI object tree, the first processor matches the binding path corresponding to the UI control with the data source paths of all CAN signals in the configuration table; Based on the matching results, the first processor establishes a data association between each UI control and the corresponding CAN signal; When the vehicle is running, if the first processor determines that the current physical value of the target CAN signal is different from the historical physical value of the buffer currently in the write state in the shared memory, it triggers the second processor to drive the display chip to perform corresponding interface rendering operations on at least one UI control associated with the target CAN signal based on the historical physical value of the buffer currently in the read state in the shared memory, so that the CAN signal and the UI interface can be linked.

[0006] Furthermore, the configuration table, which contains configuration information for multiple CAN signals, is constructed based on the CAN signal configuration file, including: The first processor extracts configuration information for multiple CAN signals from the CAN signal configuration file; The first processor generates corresponding mapping entries based on the configuration information of each CAN signal; The first processor constructs a configuration table containing configuration information for multiple CAN signals from the mapping entries of all CAN signals.

[0007] Furthermore, before the first processor matches the binding path corresponding to each UI control in the UI object tree with the data source paths of all CAN signals in the configuration table, the linkage method further includes: The first processor allocates storage addresses for storing physical values ​​for each data source path of all CAN signals in the shared memory buffer.

[0008] Furthermore, for each UI control in the UI object tree, the first processor matches the binding path corresponding to that UI control with the data source paths of all CAN signals in the configuration table, including: Based on the configuration table, the first processor constructs a data source directory containing the data source paths of all CAN signals; The first processor extracts the binding path string for each UI control based on the binding path field of all UI controls in the UI object tree; For each UI control, the first processor matches the data source path string of the CAN signal that is the same as the binding path string of that UI control from the data source directory.

[0009] Furthermore, the linkage system also includes a CAN controller; the linkage method further includes: When the vehicle is running, the CAN controller responds to the current message corresponding to the received target CAN signal and determines the current physical value of the target CAN signal based on the configuration table and the current message; The first processor compares the current physical value of the target CAN signal with the historical physical value of the buffer currently in a write state in the shared memory.

[0010] Furthermore, during vehicle operation, if the first processor determines that the current physical value of the target CAN signal differs from the historical physical value of the buffer currently in a write state in the shared memory, it triggers the second processor to drive the display chip to perform corresponding interface rendering operations on at least one UI control associated with the target CAN signal based on the historical physical value of the buffer currently in a read state in the shared memory, so that the CAN signal and the UI interface are linked, including: When the vehicle is running, if the first processor determines that the current physical value of the target CAN signal is different from the historical physical value of the buffer currently in the write state, it writes the current physical value of the target CAN signal to the corresponding storage address in the buffer currently in the write state, and sets the refresh flag of at least one UI control associated with the target CAN signal in the shared memory to the valid state. The second processor identifies all UI controls corresponding to the refresh flags that are in a valid state, and determines all identified UI controls as target UI controls; The second processor determines the target attribute data corresponding to each target UI control based on the historical physical values ​​in the buffer currently in the reading state of the target CAN signal. The second processor, based on the target attribute data corresponding to each target UI control, drives the display chip to perform corresponding interface rendering operations on all target UI controls.

[0011] Furthermore, the linkage method also includes: Once the interface rendering operation is complete, the first processor sets the refresh flag of all target UI controls to an invalid state, and changes the buffer currently in the write state to the read state, and the buffer currently in the read state to the write state.

[0012] Secondly, embodiments of this application also provide a linkage system for an in-vehicle instrument panel, the linkage system comprising: a first processor, a second processor, shared memory, and a display chip; After the first processor is powered on, it reads the CAN signal configuration file from the external storage device and constructs a configuration table containing configuration information for multiple CAN signals based on the CAN signal configuration file; wherein, the configuration information includes: the data source path of the CAN signal; After the second processor is powered on, it reads the UI resource package from the external storage device and constructs a UI object tree based on the UI resource package. For each UI control in the UI object tree, the first processor matches the binding path corresponding to the UI control with the data source paths of all CAN signals in the configuration table; Based on the matching results, the first processor establishes a data association between each UI control and the corresponding CAN signal; When the vehicle is running, if the first processor determines that the current physical value of the target CAN signal is different from the historical physical value of the buffer currently in the write state in the shared memory, it triggers the second processor to drive the display chip to perform corresponding interface rendering operations on at least one UI control associated with the target CAN signal based on the historical physical value of the buffer currently in the read state in the shared memory, so that the CAN signal and the UI interface can be linked.

[0013] Thirdly, embodiments of this application also provide an electronic device, including: a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory through the bus. The machine-readable instructions are executed by the processor to perform the steps of the linkage method of the vehicle instrument described in the first aspect or any possible implementation of the first aspect.

[0014] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of the linkage method for the vehicle instrument described in the first aspect or any possible implementation of the first aspect.

[0015] This application provides a linkage method, system, electronic device, and storage medium for an in-vehicle instrument cluster. For each UI control in the UI object tree, a first processor matches the binding path corresponding to the UI control with the data source paths of all CAN signals in the configuration table. Based on the matching results, the first processor establishes a data association between each UI control and the corresponding CAN signal. When the vehicle is running, if the first processor determines that the current physical value of the target CAN signal is different from the historical physical value of the buffer currently in the write state in the shared memory, it triggers a second processor to drive the display chip to perform corresponding interface rendering operations on at least one UI control associated with the target CAN signal based on the historical physical value of the buffer currently in the read state in the shared memory, so that the CAN signal and the UI interface are linked.

[0016] In this way, the linkage between CAN signals and the UI interface was achieved without modifying the firmware or recompiling.

[0017] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 One of the flowcharts of a linkage method for an in-vehicle instrument panel provided in an embodiment of this application is shown; Figure 2 The second flowchart illustrates a linkage method for an in-vehicle instrument panel provided in an embodiment of this application; Figure 3 The third flowchart illustrates a linkage method for an in-vehicle instrument panel provided in an embodiment of this application; Figure 4 The fourth flowchart illustrates a linkage method for an in-vehicle instrument panel provided in an embodiment of this application; Figure 5 The fifth flowchart illustrates a linkage method for an in-vehicle instrument panel provided in an embodiment of this application; Figure 6 A schematic diagram of the structure of an electronic device provided in an embodiment of this application is shown. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the drawings in this application are for illustrative and descriptive purposes only and are not intended to limit the scope of protection of this application. Furthermore, it should be understood that the schematic drawings are not drawn to scale. The flowcharts used in this application illustrate operations implemented according to some embodiments of this application. It should be understood that the operations in the flowcharts may not be implemented in sequence, and steps without logical contextual relationships may be reversed or implemented simultaneously. In addition, those skilled in the art, guided by the content of this application, may add one or more other operations to the flowcharts, or remove one or more operations from the flowcharts.

[0021] Furthermore, the described embodiments are merely some, not all, of the embodiments of this application. The components of the embodiments of this application described and illustrated herein can typically be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0022] The methods, systems, electronic devices, or computer-readable storage media described in this application can be applied to any scenario requiring linkage of vehicle instrument clusters. This application does not limit specific application scenarios, and any solution using the linkage method and system for vehicle instrument clusters provided in this application is within the protection scope of this application.

[0023] It is worth noting that automotive instrument cluster software development typically relies on firmware hard-coding to achieve CAN signal parsing and UI data binding. Specifically, during CAN signal parsing, parameters such as message ID, signal start bit, bit length, byte order, scaling factor, offset, and routing target are all fixed in the program in code form. In terms of UI interface development, traditional UI interface development adopts a "design-slicing-coding-integration debugging" model, where interface layout, control properties, animation effects, and data binding logic all need to be implemented in code form using programming languages ​​such as C / C++ or Qt. The linkage between CAN data and UI controls is relayed through intermediate layers such as message queues, callback functions, and business logic code. In dual-core instrument cluster systems, the task division, data synchronization, refresh handshake, and state switching logic between the first and second processors are all fixedly implemented by firmware code, and the logic cannot be changed. Different vehicle models correspond to independent firmware versions, with the hardware platform and software program bound one-to-one.

[0024] However, the above technical architecture has the following drawbacks: First, CAN signal parsing is strongly bound to business code. Adapting to different vehicle models requires manual modification of the underlying code, recompiling the project, re-flashing the firmware, and using specialized tools for bench and real-vehicle debugging. This process is cumbersome, time-consuming, has high barriers to entry, and carries significant risks, making it impossible to quickly respond to the market demands of multiple vehicle models, small batches, and rapid iterations. Second, UI interface development is deeply coupled with the underlying firmware, preventing quick skinning and flexible customization. Changes to the interface solution require redevelopment, compilation, flashing, and joint debugging. It cannot achieve direct deployment from UI design to target hardware without compilation. Even if some tools support prototype preview, true code-free deployment is still impossible, resulting in long UI iteration cycles, high customization costs, and low delivery efficiency. Third, CAN signals and the UI interface are independent of each other. The data link requires multiple layers of code relay, resulting in complex binding relationships, poor maintainability, and high failure rates. It cannot achieve direct data flow and linkage, and the configuration is scattered without a unified mechanism. Vehicle model switching and UI skinning cannot be completed with a single click. Fourth, the dual-core collaborative logic is hard-coded, and the data synchronization and refresh strategies cannot be dynamically adjusted. If it is necessary to adjust the data flow or rendering strategy, the underlying firmware must be modified. It cannot be flexibly adapted through configuration, resulting in poor scalability. Fifth, the firmware is strongly coupled with the business logic. The pattern of one firmware and one interface per vehicle model leads to numerous firmware versions and complex management. It is impossible to form a general software architecture under a unified hardware platform, which seriously restricts R&D efficiency and product delivery capabilities.

[0025] To address the aforementioned issues, this application proposes a linkage method, system, electronic device, and storage medium for vehicle instrument clusters, which achieves linkage between CAN signals and the UI interface without requiring firmware modification or recompilation.

[0026] To facilitate understanding of this application, the technical solutions provided in this application will be described in detail below with reference to specific embodiments.

[0027] Please see Figure 1 , Figure 1 This is one of the flowcharts for a linkage method of an in-vehicle instrument provided in an embodiment of this application.

[0028] like Figure 1 As shown in the illustration, the linkage method for an in-vehicle instrument cluster provided in this application embodiment is applied to an in-vehicle instrument cluster linkage system. The linkage system includes a first processor, a second processor, shared memory, a display chip, and a CAN controller. The shared memory provides physical memory space for data interaction between the first processor and the second processor.

[0029] The linkage method for vehicle instrument clusters includes the following steps: Step S101: After the first processor is powered on, the first processor reads the CAN signal configuration file from the external storage device and constructs a configuration table containing configuration information of multiple CAN signals based on the CAN signal configuration file.

[0030] In this embodiment, external storage devices include Flash memory, USB flash drives, and SD cards. The CAN signal configuration file defines the configuration information for multiple CAN signals. This configuration information describes the physical attributes, signal parsing rules, and data source path of each CAN signal. The configuration information includes message ID, extended frame identifier, period, start bit, bit length, byte order, signal name, scaling factor, offset, and data source path. The CAN signal configuration file format can be DBC, JSON, XML, YAML, or BIN. The signal parsing rules refer to the conversion logic used to convert the binary bit segment data in the CAN message into physical values. The data source path refers to a unique path string identifier assigned to the storage location of the physical value of each CAN signal in shared memory according to a unified naming rule, used to achieve data binding and matching between CAN signals and UI controls.

[0031] As an example, assuming the icon lights up in the seatbelt reminder scenario, the seatbelt CAN signal configuration file includes: message ID=0x1820FF01, period 100ms, signal start bit 3, bit length 1, signal name seat_belt_state, scaling factor 1, offset 0, data source path can.body.seat_belt_state, etc.

[0032] The following is combined Figure 2 This section will explain in detail how to build a configuration table containing configuration information for multiple CAN signals based on the CAN signal configuration file.

[0033] Please see Figure 2 , Figure 2 This is a second flowchart of a linkage method for an in-vehicle instrument panel provided in an embodiment of this application.

[0034] like Figure 2 As shown, regarding step S101, which involves constructing a configuration table containing configuration information for multiple CAN signals based on the CAN signal configuration file, in a specific implementation, as an example, the following steps may be included: In step S1011, the first processor extracts the configuration information of multiple CAN signals from the CAN signal configuration file.

[0035] Here, the first processor parses and extracts the configuration information of each defined CAN signal from the CAN signal configuration file.

[0036] In step S1012, the first processor generates a corresponding mapping entry based on the configuration information of each CAN signal.

[0037] Here, the mapping entries are stored in the private memory of the first processor as data structures. Continuing with the example above, for the CAN signal with the signal name seat_belt_state, the generated mapping entry includes: message ID=0x1820FF01, start bit 3, bit length 1, conversion formula: physical value = original value × scaling factor 1 + offset 0, data source path can.body.seat_belt_state, etc.

[0038] In step S1013, the first processor constructs a configuration table containing configuration information for multiple CAN signals from the mapping entries of all CAN signals.

[0039] Here, the first processor integrates all CAN signal mapping entries to build a configuration table. Once built, the configuration table is registered with the CAN controller. The configuration table is dynamically built at runtime, not determined at compile time.

[0040] As one possible embodiment, the linkage method further includes: the first processor performing multi-level validity checks on the read CAN signal configuration file. The multi-level validity checks performed by the first processor on the CAN signal configuration file include: file format and integrity checks, message ID duplication checks, signal bit segment out-of-bounds checks, frame format validity checks, and validity checks on scaling factors, offsets, and data ranges. If a check anomaly occurs, i.e., any check fails, the following processing is performed: the current CAN signal configuration file in the external storage device is discarded, the factory default CAN security configuration is retrieved from the first processor's built-in Flash, and an exception flag 0x01 is written to the system status control area of ​​the shared memory. If all checks are successful, the first processor constructs a configuration table containing configuration information for multiple CAN signals based on the CAN signal configuration file.

[0041] See again Figure 1 In step S102, after the second processor is powered on, the second processor reads the UI resource package from the external storage device and constructs a UI object tree based on the UI resource package.

[0042] Here, the UI resource package includes: UI description configuration file, image resources, font resources, animation sequence resources, and binding paths. The UI description configuration file defines the properties and hierarchy of UI controls. The binding path is a matching identifier string specified by the `bind_source` field, used to associate the UI control with the corresponding CAN signal data source path. Continuing with the example above, the UI resource package includes the properties of the red alarm icon control, specifically: the binding path `bind_source`: `can.body.seat_belt_state`, and refresh rules (the icon lights up as a red alarm icon when the physical value is 0 (seatbelt not fastened), and the icon is hidden transparently when the physical value is 1 (seatbelt properly worn), etc.

[0043] In this embodiment, the UI configuration description file in the UI resource package is parsed, and various UI control structures are recursively instantiated. The root node is the screen object, the first-level child node is the main instrument layer, and the leaf controls are various UI controls. The screen object includes width, height, resolution, layer list head, and global rendering configuration, etc.; the layer object includes the parent layer pointer, layer Z-order, transparency, display enable, and a list of all controls under the layer, etc.; the leaf controls include coordinates, size, visibility, and binding path, etc. Continuing with the above example, taking the alarm icon control as an example, the alarm icon control attributes extracted by the second processor from the UI resource package include: binding path bind_source: can.body.seat_belt_state, red alarm icon material corresponding to physical value 0, and transparent hidden icon material corresponding to physical value 1, etc. Among them, the two icon materials are stored in the video memory of the second processor. The completed UI object tree can directly drive the hardware rendering pipeline without intermediate code encapsulation or logic conversion.

[0044] As one possible embodiment, the linkage method further includes: the second processor performing multi-level validity checks on the UI resource package. The multi-level validity checks performed by the second processor on the UI resource package include: file format and integrity checks of the UI resource package, UI control attributes, layer relationships, resolution and image resource validity checks, and checks on the validity, conflict, and existence of binding paths. If a check anomaly occurs, i.e., any check fails, the following processing is performed: the current UI resource package in the external storage device is discarded, the factory default UI resource package is loaded, the vehicle instrument UI interface is run normally using the factory default UI resource package, safe mode is entered, and an exception flag 0x01 is written to the system status control area of ​​the shared memory. If all checks are successful, the second processor constructs a UI object tree based on the UI resource package.

[0045] Step S103: For each UI control in the UI object tree, the first processor matches the binding path corresponding to the UI control with the data source paths of all CAN signals in the configuration table.

[0046] The following is combined Figure 3 To explain in detail how, for each UI control in the UI object tree, the first processor matches the binding path corresponding to that UI control with the data source paths of all CAN signals in the configuration table.

[0047] Please see Figure 3 , Figure 3 This is the third flowchart of a linkage method for an in-vehicle instrument panel provided in an embodiment of this application.

[0048] like Figure 3 As shown, regarding step S103, in a specific implementation, as an example, the following steps may be included: Step S1031: The first processor constructs a data source directory containing the data source paths of all CAN signals based on the configuration table.

[0049] Here, all mapping entries in the configuration table are traversed, and the data source path string contained in each mapping entry is extracted. The data source paths of all CAN signals are then summarized into a data source directory. After the data source directory is built, it is stored in shared memory, providing a data foundation for the automatic association between CAN signals and UI controls.

[0050] In step S1032, the first processor extracts the binding path string of each UI control based on the binding path field of all UI controls in the UI object tree.

[0051] Here, the first processor accesses the UI control property mapping area in shared memory to obtain the structural information of the UI object tree that the second processor has built, traverses all UI control nodes in the UI object tree, reads the binding path field of each UI control, i.e. the bind_source field, and extracts the binding path string of each UI control from it.

[0052] In step S1033, for each UI control, the first processor matches the data source path string of the CAN signal that is the same as the binding path string of the UI control from the data source directory.

[0053] Here, the first processor compares the binding path string of each UI control with all CAN signal data source path strings in the data source directory. When a CAN signal data source path string that exactly matches the binding path string of a UI control is found in the data source directory, it is determined that the UI control and the CAN signal are successfully matched.

[0054] Before step S103, the linkage method of this embodiment further includes: the first processor allocating storage addresses for storing physical values ​​for all CAN signal data source paths in the shared memory buffer. It should be noted that the shared memory space is pre-partitioned with fixed static partitions, the addresses are permanently fixed and cannot be dynamically changed during runtime, thus eliminating the risk of memory fragmentation and out-of-bounds errors. Specifically, as shown in Table 1, the shared memory area includes a system status control area, a CAN global data source area, a UI control attribute mapping area, a refresh flag bitmap area, a dual-processor handshake interrupt area, and a reserved safety redundancy area. The data source area is divided into two equal-capacity ping-pong buffers, A and B. Upon power-on initialization, buffer A is the buffer currently in the write state for the first processor, and buffer B is the buffer currently in the read state for the second processor. Each CAN signal data source path is allocated a fixed storage address in the data source area, and the relative positions of the storage addresses in buffers A and B are completely consistent.

[0055] Table 1. Memory partitioning of shared memory

[0056] In step S104, the first processor establishes a data association between each UI control and the corresponding CAN signal based on the matching result.

[0057] Here, after a successful match, the first processor assigns a refresh flag bit to each UI control in the refresh flag bitmap area of ​​shared memory, completing the logical binding. That is, it establishes a data association between the refresh flag bit of each UI control and the storage address of the corresponding CAN signal in the buffer. When the physical value of the corresponding CAN signal in shared memory changes, the refresh flag bit is automatically set to a valid state, thereby triggering a UI refresh. This binding process is configuration-driven, requiring no callback functions, message queues, or business logic code, achieving automatic, code-free binding between CAN signals and UI controls.

[0058] In this application, after establishing data association between each UI control and the corresponding CAN signal, the linkage method further includes: when the vehicle is running, if the first processor determines that the current physical value of the target CAN signal is different from the historical physical value of the buffer currently in the write state in the shared memory, it triggers the second processor to drive the display chip to perform corresponding interface rendering operations on at least one target UI control associated with the target CAN signal based on the historical physical value of the buffer currently in the read state in the shared memory, so that the CAN signal and the UI interface are linked.

[0059] The following is combined Figure 4To explain in detail how, when the vehicle is running, if the first processor determines that the current physical value of the target CAN signal is different from the historical physical value of the buffer currently in the write state in the shared memory, it triggers the second processor to drive the display chip to perform corresponding interface rendering operations on at least one target UI control associated with the target CAN signal based on the historical physical value of the buffer currently in the read state in the shared memory, so that the CAN signal and the UI interface can be linked.

[0060] Please see Figure 4 , Figure 4 This is the fourth flowchart of a linkage method for an in-vehicle instrument provided in an embodiment of this application.

[0061] like Figure 4 As shown, regarding the above steps, in specific implementation, as an example, the following steps may be included: Step S11: When the vehicle is running, if the first processor determines that the current physical value of the target CAN signal is different from the historical physical value of the buffer currently in the write state, it writes the current physical value of the target CAN signal to the corresponding storage address in the buffer currently in the write state, and sets the refresh flag bit of at least one UI control associated with the target CAN signal in the shared memory to the valid state.

[0062] Here, the first processor compares the current physical value of the target CAN signal with the historical physical value stored at the corresponding memory address in the buffer currently in the write state. If they differ, it indicates that the vehicle state represented by the target CAN signal has changed. In this case, the first processor writes the current physical value of the target CAN signal to the memory address corresponding to the data source path of the target CAN signal in the buffer currently in the write state, overwriting the original historical physical value and completing the data update. The first processor also sets the refresh flag of at least one UI control associated with the target CAN signal to a valid state in the refresh flag bitmap area of ​​the shared memory, marking that the UI control needs to be rendered and updated based on the new physical value in the next interface refresh cycle. This data change detection and marking mechanism ensures that the subsequent UI control refresh process is triggered only when the physical value of the CAN signal actually changes, avoiding invalid repeated rendering operations and improving the overall operating efficiency of the system.

[0063] like Figure 5 As shown, prior to step S11, the following steps are also included: Step S21: When the vehicle is running, the CAN controller responds to the current message corresponding to the received target CAN signal and determines the current physical value of the target CAN signal based on the configuration table and the current message.

[0064] Here, during vehicle operation, the CAN controller continuously monitors message transmissions on the CAN bus. When a message is received, the CAN controller parses it, extracting the corresponding bit segment data and calculating the physical value according to the conversion rules in the configuration table. Continuing with the example above, for message ID 0x1820FF01, it extracts the data of start bit 3 and bit length 1, and obtains the current physical value according to the formula: physical value = original value × 1 + 0. The parsing process is entirely automated at the hardware level by the CAN controller based on the configuration table built during runtime. It does not rely on application layer code, has no business branches, no conditional judgments, and no hard coding, achieving configuration-driven and data-pass-through CAN signal parsing.

[0065] In step S22, the first processor compares the current physical value of the target CAN signal with the historical physical value of the buffer currently in the write state in the shared memory.

[0066] It should be noted that after the refresh flags of all UI controls associated with the CAN signals that have undergone physical value changes are set to the valid state, the first processor triggers a first register interrupt to generate a first interrupt signal indicating that the current physical value has been written to the buffer currently in the write state, and sends it to the second processor. The first register interrupt is the INTR_A interrupt. Continuing with the example above, when the seatbelt is not fastened, the physical value is 0. The first processor writes the physical value 0 to the corresponding storage address in the buffer currently in the write state, then sets the refresh flag of the seatbelt icon control to 1, triggering the INTR_A interrupt to notify the second processor that new data is ready. Data changes are notified in real time via interrupts, ensuring low latency.

[0067] In step S12, the second processor identifies all UI controls corresponding to the refresh flags that are in a valid state, and determines all identified UI controls as target UI controls.

[0068] Here, in response to receiving the first interrupt signal triggered by the first processor, the second processor performs a complete scan of the refresh flag bitmap area in the shared memory, reading the current state of each refresh flag. During the scan, it identifies the UI controls corresponding to all refresh flags that are currently set to 1, and determines all identified UI controls as the target UI controls that need to be refreshed in the current rendering cycle.

[0069] Step S13: The second processor determines the target attribute data corresponding to each target UI control based on the historical physical values ​​in the buffer currently in the reading state of the target CAN signal.

[0070] Here, for each target UI control, the second processor first reads the historical physical value stored in the currently read buffer of shared memory based on the storage address bound to the target UI control. It should be noted that, due to the A / B ping-pong double buffering mechanism used in this application, the currently read buffer and the currently write buffer are physically isolated from each other. Therefore, the historical physical value read by the second processor is the data from the last write, thus avoiding data half-frame or screen tearing issues that may occur due to concurrent read / write operations at the hardware level. After obtaining the historical physical value from the currently read buffer, the second processor uses this historical physical value as a criterion to determine the target attribute data matching the historical physical value from the video memory according to the display rules preset in the UI resource package for the target UI control. Continuing with the above example, when the historical physical value obtained by the second processor from the storage address of the currently read buffer is 0, the red alarm icon material is determined to be the target attribute data of the target UI control in the current rendering cycle; when the historical physical value is 1, the transparent hidden icon material is determined to be the target attribute data.

[0071] In step S14, the second processor drives the display chip to perform corresponding interface rendering operations on all target UI controls based on the target attribute data corresponding to each target UI control.

[0072] Here, the second processor constructs a rendering instruction sequence for each target UI control based on its target attribute data, driving the display chip to perform graphics processing operations such as texture mapping, layer blending, and pixel filling at the hardware level. For all target UI controls, the display chip executes rendering sequentially from the bottom layer to the top layer according to the layer hierarchy defined in the UI object tree. Continuing with the example above, when the alarm icon control is identified as a target UI control and its target attribute data is a red alarm icon material, the display chip draws a red alarm icon at the coordinates of the alarm icon control, causing it to light up and be displayed on the instrument interface. It should be noted that the two interrupts are independent of each other, the registers are set separately, they do not interfere with each other, and there is no risk of contention.

[0073] After the interface rendering operation is completed, the linkage method also includes: when the interface rendering operation is completed, the first processor sets the refresh flag of all target UI controls to an invalid state, changes the buffer currently in the write state to the read state, and changes the buffer currently in the read state to the write state.

[0074] Here, after the interface rendering operation is completed, the second processor triggers a second register interrupt to generate a second interrupt signal indicating that the interface rendering is complete, and sends it to the first processor. The second register interrupt is the INTR_B interrupt. In response to the second interrupt signal received from the second processor, the first processor modifies the buffer switching flag in the handshake interrupt area, sets the refresh flag of all target UI controls to an invalid state, changes the buffer currently in write state to read state, and changes the buffer currently in read state to write state, completing the ping-pong buffer switching, and waiting for the next CAN message data to be written.

[0075] This application also provides an exception fallback mechanism: if the first hardware interrupt triggered by the first processor does not receive a response interrupt signal from the second processor within a preset time (e.g., 5ms), the second processor is determined to be blocked, the system abandons the newly written data, the second processor continues to use the historical physical values ​​in the buffer currently in the reading state, the icon maintains its original state, the instrument panel does not go black or crash, and meets automotive-grade safety requirements.

[0076] This application dynamically constructs configuration tables and UI object trees during runtime through external CAN signal configuration files and UI resource packages, and establishes automatic binding based on standardized data source paths. Combined with ping-pong buffering and dual-processor interrupt collaboration, it achieves configuration-driven, hard-coded, integrated CAN-UI linkage, solving the problems of slow adaptation, difficult customization, and multiple versions of automotive instrument clusters. It realizes fully visualized configuration and one-click activation of the entire process of CAN signal parsing, data distribution, UI rendering, and data linkage. From an architectural perspective, it completely decouples firmware from business logic, significantly improving instrument cluster adaptation efficiency, customization flexibility, and platform capabilities. It should be noted that this application achieves code-free configuration. Specifically, when implementing functions such as vehicle model adaptation, signal adjustment, UI replacement, and data binding, there is no need to modify the firmware program, recompile, link to generate new firmware, burn the MCU, write business logic code, perform manual online debugging on CANoe, or have engineers modify the parsing logic. All functions are implemented through importing external configuration files, and the entire configuration process does not change the system program, does not affect operational stability, and does not compromise automotive-grade reliability.

[0077] This application provides a method for linking an in-vehicle instrument panel, which enables the linkage between a CAN signal without hard-coding and a UI interface.

[0078] Based on the same application concept, this application also provides an in-vehicle instrument linkage system corresponding to the linkage method of the in-vehicle instrument provided in the above embodiments. Since the principle of the system in this application to solve the problem is similar to the linkage method of the in-vehicle instrument in the above embodiments of this application, the implementation of the system can refer to the implementation of the method, and the repeated parts will not be described again.

[0079] This application provides a linkage system for an in-vehicle instrument panel, the linkage system comprising: a first processor, a second processor, shared memory, and a display chip; After the first processor is powered on, it reads the CAN signal configuration file from the external storage device and constructs a configuration table containing configuration information for multiple CAN signals based on the CAN signal configuration file; wherein, the configuration information includes: the data source path of the CAN signal; After the second processor is powered on, it reads the UI resource package from the external storage device and constructs a UI object tree based on the UI resource package. For each UI control in the UI object tree, the first processor matches the binding path corresponding to the UI control with the data source paths of all CAN signals in the configuration table; Based on the matching results, the first processor establishes a data association between each UI control and the corresponding CAN signal; When the vehicle is running, if the first processor determines that the current physical value of the target CAN signal is different from the historical physical value of the buffer currently in the write state in the shared memory, it triggers the second processor to drive the display chip to perform corresponding interface rendering operations on at least one UI control associated with the target CAN signal based on the historical physical value of the buffer currently in the read state in the shared memory, so that the CAN signal and the UI interface can be linked.

[0080] This application provides a linkage system for an in-vehicle instrument panel, which enables the linkage between CAN signals without hard-coding and the UI interface.

[0081] Please see Figure 6 , Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0082] like Figure 6 As shown, the electronic device 600 includes a processor 610, a memory 620, and a bus 630.

[0083] The memory 620 stores machine-readable instructions executable by the processor 610. When the electronic device 600 is running, the processor 610 and the memory 620 communicate via the bus 630. When the machine-readable instructions are executed by the processor 610, they can perform the operations described above. Figure 1 , Figure 2 , Figure 3 , Figure 4 and Figure 5 The steps of the linkage method for the vehicle instrument in the method embodiment shown are described in detail in the method embodiment, and will not be repeated here.

[0084] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, can perform the above-described actions. Figure 1 , Figure 2 , Figure 3 , Figure 4 and Figure 5 The steps of the linkage method for the vehicle instrument in the method embodiment shown are described in detail in the method embodiment, and will not be repeated here.

[0085] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems and devices described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. In the several embodiments provided in this application, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. The system embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Another point is that the displayed or discussed mutual coupling or direct coupling or communication connection may be through some communication interfaces; the indirect coupling or communication connection of devices or units may be electrical, mechanical, or other forms.

[0086] 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.

[0087] In addition, the functional units in the various embodiments of this application 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.

[0088] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0089] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A linkage method for an in-vehicle instrument panel, characterized in that, The linkage method is applied to the linkage system of the vehicle instrument panel; The linkage system includes: a first processor, a second processor, shared memory, and a display chip; the linkage method includes: After the first processor is powered on, it reads the CAN signal configuration file from the external storage device and constructs a configuration table containing configuration information for multiple CAN signals based on the CAN signal configuration file; wherein, the configuration information includes: the data source path of the CAN signal; After the second processor is powered on, it reads the UI resource package from the external storage device and constructs a UI object tree based on the UI resource package. For each UI control in the UI object tree, the first processor matches the binding path corresponding to the UI control with the data source paths of all CAN signals in the configuration table; Based on the matching results, the first processor establishes a data association between each UI control and the corresponding CAN signal; When the vehicle is running, if the first processor determines that the current physical value of the target CAN signal is different from the historical physical value of the buffer currently in the write state in the shared memory, it triggers the second processor to drive the display chip to perform corresponding interface rendering operations on at least one UI control associated with the target CAN signal based on the historical physical value of the buffer currently in the read state in the shared memory, so that the CAN signal and the UI interface can be linked. The linkage system further includes: a CAN controller; the linkage method further includes: When the vehicle is running, the CAN controller responds to the current message corresponding to the received target CAN signal and determines the current physical value of the target CAN signal based on the configuration table and the current message; The first processor compares the current physical value of the target CAN signal with the historical physical value of the buffer in the shared memory that is currently in a write state; When the vehicle is running, if the first processor determines that the current physical value of the target CAN signal is different from the historical physical value of the buffer currently in the write state in the shared memory, it triggers the second processor to drive the display chip to perform corresponding interface rendering operations on at least one UI control associated with the target CAN signal based on the historical physical value of the buffer currently in the read state in the shared memory, so that the CAN signal and the UI interface are linked, including: When the vehicle is running, if the first processor determines that the current physical value of the target CAN signal is different from the historical physical value of the buffer currently in the write state, it writes the current physical value of the target CAN signal to the corresponding storage address in the buffer currently in the write state, and sets the refresh flag of at least one UI control associated with the target CAN signal in the shared memory to the valid state. The second processor identifies all UI controls corresponding to the refresh flags that are in a valid state, and determines all identified UI controls as target UI controls; The second processor determines the target attribute data corresponding to each target UI control based on the historical physical values ​​in the buffer currently in the reading state of the target CAN signal. The second processor, based on the target attribute data corresponding to each target UI control, drives the display chip to perform corresponding interface rendering operations on all target UI controls.

2. The linkage method for vehicle instrument according to claim 1, characterized in that, The configuration table, constructed based on the CAN signal configuration file, contains configuration information for multiple CAN signals, including: The first processor extracts configuration information for multiple CAN signals from the CAN signal configuration file; The first processor generates corresponding mapping entries based on the configuration information of each CAN signal; The first processor constructs a configuration table containing configuration information for multiple CAN signals from the mapping entries of all CAN signals.

3. The linkage method for vehicle instrument clusters according to claim 1, characterized in that, Before the first processor matches the binding path corresponding to each UI control in the UI object tree with the data source paths of all CAN signals in the configuration table, the linkage method further includes: The first processor allocates storage addresses for storing physical values ​​for each data source path of all CAN signals in the shared memory buffer.

4. The linkage method for vehicle instrument clusters according to claim 1, characterized in that, For each UI control in the UI object tree, the first processor matches the binding path corresponding to that UI control with the data source paths of all CAN signals in the configuration table, including: Based on the configuration table, the first processor constructs a data source directory containing the data source paths of all CAN signals; The first processor extracts the binding path string for each UI control based on the binding path field of all UI controls in the UI object tree; For each UI control, the first processor matches the data source path string of the CAN signal that is the same as the binding path string of that UI control from the data source directory.

5. The linkage method for vehicle instrument according to claim 1, characterized in that, The linkage method also includes: Once the interface rendering operation is complete, the first processor sets the refresh flag of all target UI controls to an invalid state, and changes the buffer currently in the write state to the read state, and the buffer currently in the read state to the write state.

6. A linkage system for an in-vehicle instrument panel, characterized in that, The linkage system includes: a first processor, a second processor, shared memory, and a display chip; After the first processor is powered on, it reads the CAN signal configuration file from the external storage device and constructs a configuration table containing configuration information for multiple CAN signals based on the CAN signal configuration file; wherein, the configuration information includes: the data source path of the CAN signal; After the second processor is powered on, it reads the UI resource package from the external storage device and constructs a UI object tree based on the UI resource package. For each UI control in the UI object tree, the first processor matches the binding path corresponding to the UI control with the data source paths of all CAN signals in the configuration table; Based on the matching results, the first processor establishes a data association between each UI control and the corresponding CAN signal; When the vehicle is running, if the first processor determines that the current physical value of the target CAN signal is different from the historical physical value of the buffer currently in the write state in the shared memory, it triggers the second processor to drive the display chip to perform corresponding interface rendering operations on at least one UI control associated with the target CAN signal based on the historical physical value of the buffer currently in the read state in the shared memory, so that the CAN signal and the UI interface can be linked. The linkage system also includes: a CAN controller; When the vehicle is running, the CAN controller responds to the current message corresponding to the received target CAN signal and determines the current physical value of the target CAN signal based on the configuration table and the current message; The first processor compares the current physical value of the target CAN signal with the historical physical value of the buffer in the shared memory that is currently in a write state; When the vehicle is running, if the first processor determines that the current physical value of the target CAN signal is different from the historical physical value of the buffer currently in the write state in the shared memory, it triggers the second processor to drive the display chip to perform corresponding interface rendering operations on at least one UI control associated with the target CAN signal based on the historical physical value of the buffer currently in the read state in the shared memory, so that the CAN signal and the UI interface are linked, including: When the vehicle is running, if the first processor determines that the current physical value of the target CAN signal is different from the historical physical value of the buffer currently in the write state, it writes the current physical value of the target CAN signal to the corresponding storage address in the buffer currently in the write state, and sets the refresh flag of at least one UI control associated with the target CAN signal in the shared memory to the valid state. The second processor identifies all UI controls corresponding to the refresh flags that are in a valid state, and determines all identified UI controls as target UI controls; The second processor determines the target attribute data corresponding to each target UI control based on the historical physical values ​​in the buffer currently in the reading state of the target CAN signal. The second processor, based on the target attribute data corresponding to each target UI control, drives the display chip to perform corresponding interface rendering operations on all target UI controls.

7. An electronic device, characterized in that, include: The device includes a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus. The machine-readable instructions are executed by the processor to perform the steps of the linkage method of the vehicle instrument as described in any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, which, when executed by a processor, performs the steps of the linkage method for the vehicle instrument as described in any one of claims 1 to 5.

Images