Vehicle machine component self-detection method and device, electronic equipment and storage medium

Abstract

The application relates to a vehicle machine component self-detection method and device, computer equipment and a storage medium; the method is applied to a system on chip (SOC) end, and the method comprises the following steps: after a vehicle machine component detection work is started, a component list to be detected is acquired; installation verification is sequentially performed on each component in the component list to be detected according to the component list to be detected; if the verification is passed, the component passed in the verification is deleted from the component list or is marked in the component list; and if the verification is not passed, installation repair work of the component is performed. According to the scheme, the deployment state of a vehicle machine system component program can be found in time after the vehicle machine is started, the state of unsuccessful deployment or abnormal deployment can be corrected in time, the stability of the vehicle machine system work is ensured, the user experience is improved, and the operation and maintenance cost is reduced.

Description

Technical Field

[0001] This application relates to the field of vehicle infotainment system testing technology, and in particular to a self-testing method, device, electronic device and storage medium for vehicle infotainment components. Background Technology

[0002] With the rapid development of intelligent connected vehicles, the functional complexity and software scale of in-vehicle infotainment systems continue to rise, and the in-vehicle electronic and electrical architecture is gradually evolving towards centralization and domain control. In the actual production and manufacturing process of in-vehicle infotainment systems, the program deployment and parameter configuration of its core functional components mainly rely on the factory electrical inspection and off-line testing stage in the vehicle manufacturing process. In the factory electrical inspection and off-line testing stage of vehicle manufacturing, the in-vehicle infotainment equipment needs to complete the configuration and installation of core functional components, such as fuel pack parameter components and ENC noise reduction parameter components. This process is a key step to ensure the normal operation of the in-vehicle infotainment system thereafter.

[0003] However, in actual production environments, due to various uncontrollable factors such as power outages, voltage fluctuations, equipment communication interruptions, and abnormal transmission of deployment instructions, the program deployment of some vehicle infotainment components is often incomplete, which may manifest as problems such as interrupted component program installation, missing files, and incomplete version writing.

[0004] In existing technologies, the factory electrical inspection and deployment process for vehicle-mounted equipment operates on a single-execution mechanism. This means that once deployment is complete (regardless of success), the system does not proactively trigger a second deployment verification. Furthermore, component deployment is typically the final step in the electrical inspection process, leaving no remedial steps. If component deployment fails, this anomaly cannot be detected and corrected in a timely manner, leading to functional malfunctions and instability in the vehicle-mounted equipment after it leaves the factory. This not only severely impacts the user experience but also increases after-sales maintenance costs for automakers. Summary of the Invention

[0005] In order to solve the above-mentioned technical problems, or at least partially solve the above-mentioned technical problems, this application provides a vehicle detection method, device, electronic device and storage medium.

[0006] In a first aspect, this application provides a self-testing method for vehicle infotainment components, the method being applied to a system-on-a-chip (SoC) terminal, the method comprising: After the vehicle infotainment system component testing is started, a list of components to be tested is obtained; Referring to the list of components to be tested, each component in the list is installed and verified in turn; If the verification passes, the component that passes the verification will be removed from the list or marked in the list; If the verification fails, the installation and repair of the component will be performed.

[0007] In one embodiment of this application, the step of referring to the list of components to be tested and sequentially performing installation verification on each component in the list includes: Obtain the first component information of the detected component from the list; Obtain information about the second component actually installed in the current vehicle infotainment system. Compare the information of the first component with the information of the second component to see if they are consistent; Based on the comparison results, it is confirmed whether the detected component has passed the verification.

[0008] In one embodiment of this application, the step of confirming whether the detected component passes verification based on the comparison result includes: If the comparison is inconsistent, it is confirmed that the component being tested has failed the test; If the verification fails, the installation and repair work of the component will be performed, including: If the verification fails, the installation package storage location information of the abnormal component is obtained from the list of detected components; According to the storage location information, retrieve the corresponding installation package of the abnormal component from the local resource library; Send the installation package data to the faulty component, causing the faulty component to perform a reinstallation. After the reinstallation is completed, the component under test is reinstalled and tested until the component under test passes the test or the specified number of installations is reached, then the testing of the component under test is ended.

[0009] In one embodiment of this application, the step of confirming whether the detected component passes the detection based on the comparison result includes: If the comparison matches, the detected component passes the test.

[0010] In one embodiment of this application, the method further includes: After the vehicle system is started, it receives the status of the preset flag bit reported by the MCU. If the preset flag bit is in the enabled state, the detection work of the vehicle system component is started.

[0011] In one embodiment of this application, the method further includes: The list of components to be tested is stored in advance. The list includes component information of all vehicle-mounted components that need to be tested and are deployed during the factory electrical inspection stage. Each vehicle-mounted component is assigned a unique identifier.

[0012] In one embodiment of this application, the first component information includes a preset standard version number of the component to be detected; The second component information includes the actual installed version number of the component to be tested in the vehicle infotainment system; The step of comparing the first component information with the second component information to determine if they are consistent includes: The preset standard version number of the component to be tested in the test list is compared with the actual installed version number of the component to be tested in the vehicle system.

[0013] In one embodiment of this application, obtaining the corresponding installation package of the abnormal component from the local resource library according to the storage location information includes: Obtain the vehicle model configuration parameters of the current vehicle, including vehicle function configuration codes and vehicle software version levels; Based on the vehicle model function configuration code and the vehicle model software version level, index the storage path of the installation package that matches the current vehicle in the local resource library; According to the storage path obtained by the index, retrieve the standard installation package of the abnormal component from the local resource library.

[0014] Secondly, this application provides a vehicle infotainment component testing device, comprising: The acquisition module is used to obtain the list of components to be tested after the vehicle component detection work is started; The verification module is used to perform installation verification on each component in the list of components to be tested in turn. The first processing module is used to remove the verified component from the list or mark it in the list if the verification passes. The second processing module is used to perform the installation and repair work of the component if the verification fails.

[0015] Thirdly, this application provides an electronic device, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; When the processor executes a program stored in the memory, it implements the vehicle component self-detection method as described in any embodiment of the first aspect.

[0016] Fourthly, this application provides a computer-readable storage medium storing a program for a vehicle infotainment system component self-testing method, wherein when the program for the vehicle infotainment system component self-testing method is executed by a processor, the program implements the steps of the vehicle infotainment system component self-testing method as described in any embodiment of the first aspect.

[0017] The beneficial effects of this invention are: This application provides a self-testing method for vehicle infotainment components, applied to the SOC (System-on-a-Chip) terminal. After the vehicle infotainment component testing process is initiated, a list of components to be tested is obtained. Referring to this list, each component in the list is sequentially verified for installation. If the verification passes, the verified component is removed from the list or marked. If the verification fails, the installation and repair of the component is performed. This solution, by implementing the installation verification process for vehicle infotainment components at the SOC terminal and performing installation and repair work on abnormal components when verification fails, can promptly detect the deployment status of component programs. It can promptly correct unsuccessful or abnormal deployment states, ensuring the stability of the vehicle infotainment system, improving user experience, and reducing maintenance costs. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0019] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 A flowchart illustrating a self-testing method for vehicle infotainment components provided in an embodiment of this application; Figure 2 A flowchart illustrating a vehicle infotainment component installation verification method provided in this application embodiment; Figure 3 A schematic diagram illustrating the installation and repair process of an abnormal component provided in an embodiment of this application; Figure 4 A flowchart illustrating another self-testing method for vehicle infotainment components provided in this application embodiment; Figure 5 A flowchart illustrating another self-testing method for vehicle infotainment components provided in this application embodiment; Figure 6 A schematic diagram of the overall architecture of a self-testing method for vehicle infotainment components provided in a specific embodiment of this application; Figure 7 This is a schematic diagram of the structure of a vehicle infotainment component testing device provided in an embodiment of this application; Figure 8 This is a structural diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0021] 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. Obviously, the described embodiments are only some embodiments of this application, 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.

[0022] During the vehicle infotainment system's electrical testing and off-line phase at the factory, the testing equipment exits after completing the deployment of various components, and the system does not proactively perform secondary verification of the deployment results. When abnormal situations such as power outages or communication interruptions occur during deployment, resulting in incomplete deployment of some components, the vehicle infotainment system lacks an automated detection and repair process to detect and handle these abnormalities. Based on this, embodiments of this application provide a self-testing method, device, electronic device, and storage medium for vehicle infotainment system components, achieving a complete closed loop from detection initiation to repair execution.

[0023] The technical solution of this application will be described in detail below through specific embodiments.

[0024] Figure 1 This is a flowchart illustrating a self-testing method for vehicle infotainment components provided in an embodiment of this application; see also... Figure 1 As shown, the self-testing method for vehicle infotainment components provided in this embodiment of the application is applied to the SOC end and specifically includes the following steps S10-S40: S10. After the vehicle infotainment system component testing is started, obtain the list of components to be tested.

[0025] This embodiment implements the self-testing method for vehicle infotainment components through a self-testing management program, which runs on the Android vehicle infotainment system on the SOC side. This self-testing management program is an independent system-level service and is decoupled from the main functional modules of the vehicle infotainment system.

[0026] After the vehicle infotainment system component testing is initiated, the self-test management program first retrieves a pre-defined list of components to be tested. This list is stored in the local flash memory of the SOC and organized in a structured data format. It contains information on all core functional components that need to be deployed during the factory electrical testing phase, such as fuel package parameter components and ENC noise reduction parameter components. Each component in the list has a unique component identifier (component ID), as well as corresponding standard version number and installation package storage path information.

[0027] S20. Referring to the list of components to be tested, perform installation verification on each component in the list in sequence.

[0028] After obtaining the list of components to be tested, the self-test management program refers to the list and performs installation verification on each component in the list in sequence. The purpose of installation verification is to determine whether the component has been correctly deployed in the vehicle system.

[0029] S30. If the verification passes, the verified component is removed from the list or marked in the list.

[0030] S40. If the verification fails, the installation and repair work of the component shall be performed.

[0031] For components that pass verification (meaning they are correctly deployed on the vehicle's infotainment system), the self-check management program removes the component from the list of components to be checked, or marks the verified components in the list so they do not need to be checked again on subsequent boots. Removing the component from the list is preferred to save storage space. For components that fail verification (meaning they are abnormally deployed on the vehicle's infotainment system, possibly due to not being installed, version mismatch, or missing files), the self-check management program performs the installation and repair work for that component.

[0032] Furthermore, this embodiment of the application achieves full-coverage detection and differentiated processing of the deployment status of vehicle-mounted system components through an automated detection process of list acquisition, traversal verification, and tiered processing (normal removal / abnormal repair). Normal components are removed from the list after passing verification, and subsequent boots do not require repeated verification, avoiding the waste of system resources caused by full traversal. Abnormal components automatically trigger the repair process without manual intervention, ensuring that the deployment status of each component in the vehicle-mounted system is normal at the time of factory shipment. Moreover, this process runs as an independent system-level service, decoupled from the main functional modules of the vehicle-mounted system, and does not affect the main system's operating efficiency.

[0033] In the above installation verification process, a specific verification method is needed to accurately determine whether the installed components in the vehicle system have been correctly deployed. For example, components may be partially installed, the version may be incomplete, or the parameter configuration may be incorrect.

[0034] Figure 2 A flowchart illustrating a vehicle infotainment component installation verification method provided in this application embodiment; see reference Figure 2 As shown in the embodiment of this application, step S20, referring to the list of components to be tested, sequentially performs installation verification on each component in the list, specifically includes the following steps S201-S204: S201. Obtain the first component information of the detected component from the list.

[0035] In this embodiment, when performing component installation verification, the first component information of the component to be detected is obtained from the list of components to be detected. This first component information is the information that the component should have in the correct deployment state, such as the preset standard version number.

[0036] S202. Obtain the information of the second component actually installed in the detected component in the current vehicle system.

[0037] In this embodiment, the self-test management program obtains the information of the second component actually installed in the current vehicle system through the component communication interface of the vehicle system. The information of the second component is the information presented after the component is actually deployed in the vehicle system, such as the actual running version number.

[0038] S203. Compare the first component information with the second component information to see if they are consistent.

[0039] S204. Based on the comparison results, confirm whether the detected component has passed the verification.

[0040] After acquiring the two sets of information, the self-check management program compares the information of the first component with that of the second component. The comparison includes, but is not limited to, consistency of version numbers, matching of component identifiers, and completeness of component parameter configurations. Based on the comparison results, the self-check management program confirms whether the component being checked has passed the verification.

[0041] For example, the self-test management program communicates with the vehicle module (the standard software service layer in the vehicle system SOC responsible for communicating with the vehicle hardware MCU) through the HIDL (Hardware Abstraction Layer Interface Definition Language) interface to obtain the actual version information of each functional component on the MCU side. The HIDL interface, as a standardized communication bridge between the SOC and the MCU, can reliably obtain component operating status data.

[0042] Furthermore, this embodiment of the application achieves accurate determination of the component deployment status by comparing preset component information with the actual information of the component. Compared with simple file existence checks or process status detection, comparison based on structured information such as version numbers can accurately identify hidden deployment anomalies such as incomplete component version writing and incorrect parameter configuration, improving the accuracy and reliability of detection. Obtaining the actual component information through the HIDL interface ensures the standardization and reliability of data acquisition.

[0043] The existing single-repair mechanism lacks fault tolerance when faced with occasional repair failures due to transient factors such as communication jitter and hardware response delays. It abandons the repair process after a single failure, resulting in a low success rate. Furthermore, the repair process needs to be able to obtain the correct installation resources locally, without relying on an external network connection, to meet the repair needs in network-free environments after the factory shutdown.

[0044] Figure 3 This application provides a schematic diagram of an installation and repair process for an abnormal component; see reference. Figure 3 As shown, in this embodiment, step S204, confirming whether the detected component has passed the verification based on the comparison result, includes the following step S2041: S2041. If the comparison is inconsistent, it is confirmed that the component being tested has failed the test.

[0045] If the information of the first component (preset standard information) does not match the information of the second component (actual installation information), the self-test management program will confirm that the tested component has failed the test and then start the repair process.

[0046] Then refer to Figure 3 As shown in this embodiment, if the verification fails in step S40, the installation and repair of the component is performed, specifically including the following steps S401-S404: S401. If the verification fails, obtain the installation package storage location information of the abnormal component from the list of detected components.

[0047] In this embodiment, the aforementioned storage location information points to a locally partitioned local parameter resource library in the local flash memory of the SOC, which pre-stores the full standard installation packages of all vehicle model projects required for deployment.

[0048] S402. Obtain the corresponding installation package of the abnormal component from the local resource library according to the storage location information.

[0049] The self-check management program accurately reads the standard installation package file corresponding to the abnormal component from the local resource library according to the storage location information.

[0050] During the repair process, the self-check management program needs to retrieve the standard installation package corresponding to the abnormal component from the local resource repository. However, the local resource repository stores a large number of installation package files for multiple vehicle models; for example, different vehicle models may require different versions of component parameters. Simply searching in the resource repository by component ID may match the wrong version, causing the repaired component to still not work properly.

[0051] In one embodiment of this application, step 402, obtaining the corresponding installation package of the abnormal component from the local resource library according to the storage location information, includes the following steps A10-A30: Step A10: Obtain the vehicle model configuration parameters of the current vehicle, including the vehicle function configuration code and the vehicle software version level; Step A20: Based on the vehicle model function configuration code and the vehicle model software version level, index the storage path of the installation package that matches the current vehicle in the local resource library; Step A30: Retrieve the standard installation package of the abnormal component from the local resource library according to the storage path obtained by the index.

[0052] In this embodiment, the self-test management program first obtains the vehicle model configuration parameters. For example, these parameters include two dimensions: the vehicle function configuration code (e.g., FD01, used to identify the vehicle's function configuration scheme) and the vehicle software version level (e.g., LEVEL, used to identify the software version level installed in the vehicle). These two parameters are written into the vehicle system's configuration storage area before the vehicle leaves the factory, and the self-test management program can read them through the system configuration interface.

[0053] Secondly, the self-check management program performs path indexing in the local resource library based on the vehicle's function configuration code and software version level. For example, the directory structure of the local resource library is organized hierarchically according to "vehicle function configuration code / vehicle software version level / component type". For instance, the path " / storage / programs / FD01 / LEVEL01 / fuel / " stores the fuel package parameter component installation package corresponding to the vehicle with configuration code FD01 and software level LEVEL01. The self-check management program matches the obtained vehicle configuration parameters with the resource library directory structure, indexing out the storage path of the installation package that precisely matches the current vehicle.

[0054] Finally, based on the storage path obtained from the index, the self-check management program retrieves the standard installation package of the abnormal component from the local resource library, triggering the abnormal component to perform subsequent reinstallation operations.

[0055] This embodiment achieves precise matching of installation packages in scenarios where multiple projects share a resource library. Compared to simple component ID lookup, this mechanism ensures that vehicles with different model configurations obtain component installation packages that perfectly match their functional schemes and software versions, avoiding functional anomalies after repair due to version mismatches. The hierarchical directory structure of the resource library makes indexing operations efficient and controllable, enabling rapid location of the target installation package even when a large number of model projects coexist, ensuring the real-time nature of the repair process. Furthermore, this mechanism operates entirely based on locally stored configuration information, without relying on network or cloud services, making it highly compatible with application scenarios where there is no network after the factory rollout.

[0056] S403. Send the installation package data to the abnormal component, so that the abnormal component can perform a reinstallation.

[0057] The self-test management program sends installation package data to the MCU-side functional module where the abnormal component is located, and issues a reinstallation command through the HIDL interface to cause the abnormal component to perform a reinstallation operation.

[0058] S404. After the reinstallation is completed, the component under test is reinstalled and tested until the component under test passes the test or the specified number of installations is reached, then the testing of the component under test is ended.

[0059] After the reinstallation process is completed, the self-test management program retrieves the actual installation information of the component under test again and compares it with the preset standard information. For example, if the comparison matches, the component is removed from the list of components to be tested, indicating successful repair, and the current test ends. If the comparison still does not match, a retry count is initiated, and the above steps of resource location, installation package acquisition, reinstallation execution, and post-reinstallation verification are repeated until the component under test passes the test, or after reaching a specified number of installations, the current test for the component ends.

[0060] After completing this test, proceed to the next component in the list of components to be tested.

[0061] In this embodiment, the specified number of installation attempts (i.e., the maximum number of retries) can be preset to 3 times. This threshold can be modified through the vehicle system configuration file as needed. If the version number is still abnormal after 3 retries, the self-test management program stops the current repair attempt for the component, keeps it in the list of components to be tested, and waits for the self-test repair process to be triggered again when the vehicle system starts up next time.

[0062] This embodiment achieves automated repair of faulty components. A limited retry mechanism (default 3 times) balances repair success rate and system resource consumption, providing sufficient retry opportunities for intermittent anomalies to improve the repair success rate, while avoiding excessive boot delays caused by infinite retries through upper limits. Furthermore, retaining failed components in the checklist across boot cycles ensures that components that failed to repair this time can continue to be repaired on the next boot, significantly improving the final repair success rate. Moreover, the entire repair process does not rely on a network connection, making it fully adaptable to application scenarios without network access after factory shutdown.

[0063] In one embodiment of this application, step S204, confirming whether the detected component has passed the detection based on the comparison result, further includes the following step S2042: S2042. If the comparison is consistent, the detected component passes the test.

[0064] In this embodiment, if the information of the first component (preset standard information) and the information of the second component (actual installation information) are completely matched, the self-test management program confirms that the tested component has passed the test and begins the test process for the next component.

[0065] For example, after confirming that the test passes, the self-test management program removes the component from the list of components to be tested. The removal takes effect immediately, and the self-test management program will skip this component during subsequent iterations and continue processing the next component to be tested in the list. If all components in the list of components to be tested are removed (i.e., the list is empty), the self-test management program will stop running directly after the iteration is completed and will not perform any further testing operations.

[0066] In another implementation, the self-check management program can mark components that have passed verification in the list of components to be checked, for example, by setting the component status field to "verified" instead of "physically deleted". During subsequent boots, the self-check management program automatically skips components marked "verified" when traversing the list. The self-check process only needs to handle abnormal components that have not yet been successfully repaired, gradually narrowing the detection scope and continuously reducing system resource overhead. Both methods achieve the technical effect of avoiding duplicate checks.

[0067] If the vehicle infotainment system component self-testing method described in the aforementioned embodiments is triggered unconditionally every time the vehicle infotainment system is started, it will lead to unnecessary system resource consumption and prolonged boot time. Furthermore, this testing process should only be effective for vehicle infotainment equipment that has undergone factory electrical testing and deployment. For vehicles that have not undergone factory electrical testing (such as aftermarket replaced vehicle infotainment equipment), the self-testing process should not be triggered.

[0068] Figure 4 A flowchart illustrating another self-testing method for vehicle infotainment components provided in this application embodiment; see reference. Figure 4 As shown, in this embodiment, the above-mentioned vehicle infotainment component self-testing method further includes the following step S101: S101. After the vehicle system is started, the preset flag status reported by the microcontroller unit (MCU) is received. If the preset flag is in the enabled state, the detection work of the vehicle system component is started.

[0069] For example, during the factory electrical inspection and off-line phase of the vehicle's infotainment system, after the electrical inspection equipment completes the deployment operations on various components of the vehicle's infotainment system, the electrical inspection equipment sends a self-test status setting instruction to the MCU through a specific electrical inspection instruction. After receiving the instruction, the MCU writes a preset flag bit into its non-volatile memory area (e.g., EEPROM), putting the flag bit in an "on" (i.e., enabled) state.

[0070] Because it uses non-volatile storage, this flag will not be lost after the vehicle's infotainment system is powered off, ensuring the reliability of the triggering logic.

[0071] Each time the vehicle infotainment system starts up, the MCU actively reports the status of the preset flag bit to the self-test management program on the SOC side. After receiving the preset flag bit status reported by the MCU, the self-test management program makes a judgment: if the preset flag bit is in the enabled state (i.e., the flag bit is "on"), the detection work of the vehicle infotainment components is started, and the self-test and repair are performed according to the above process; if the preset flag bit is not in the enabled state (i.e., the flag bit is "not on"), the self-test management program does not start the detection process, but directly stops running or enters a sleep state, without affecting the normal startup of the vehicle infotainment system.

[0072] In this embodiment, the detection process is triggered by writing a flag bit. The flag bit is only written via a dedicated control command after the factory electrical inspection deployment is completed, ensuring that the self-test logic only applies to vehicle-mounted systems deployed in the factory, thus avoiding invalid triggering. The flag bit is stored in the non-volatile memory area of ​​the MCU and is not lost when power is off, ensuring the reliability and durability of the triggering logic. The self-test process starts automatically upon power-on, requiring no manual intervention, forming an unmanned closed loop of "factory setup - power-on trigger - automatic repair." This solves the problems of low efficiency and human error that arise from the need for manual intervention in the detection process in existing technologies.

[0073] The self-test management program relies on a complete list of components to be tested when performing component testing. This list should cover all core functional components that need to be deployed during the factory electrical testing phase. If the list is incomplete, some components may be missed, resulting in deployment anomalies going undetected. Furthermore, each component in the list needs a unique identifier so that the self-test management program can accurately locate and operate on the target component during the traversal and repair process.

[0074] Figure 5A flowchart illustrating another self-testing method for vehicle infotainment components provided in this application embodiment; see reference. Figure 5 As shown, the self-testing method for vehicle infotainment components described above in this embodiment further includes the following step S102: S102. The list of components to be tested is stored in advance. The list of components to be tested includes component information of all vehicle-mounted components that need to be tested and are deployed in the factory electrical inspection stage. Each vehicle-mounted component is assigned a unique identifier.

[0075] In this embodiment of the application, before the release of the vehicle system software version, the developers pre-compile a list of components to be tested based on all components required for deployment during the factory electrical inspection phase of the vehicle model project. This list is stored in the local flash memory of the SOC in a structured data format (e.g., Extensible Markup Language XML format) as the input data source for the self-test management program.

[0076] The list of components to be tested contains information on all vehicle infotainment components that need to be deployed during the factory electrical testing phase, such as fuel pack parameter components and ENC noise reduction parameter components. Each vehicle infotainment component in the list is assigned a unique identifier (component ID), which cannot be repeated within the list and is used to uniquely indicate the specific component type. In addition to the component ID, each component entry also includes information such as the component name, the preset standard version number, and the storage path of the corresponding installation package in the local resource library.

[0077] The list of components to be tested supports dynamic updates during the self-test and repair process: once a component passes the verification, the component entry is removed from the list; when the list is empty, no further substantive testing will be triggered upon subsequent system boots.

[0078] This embodiment ensures comprehensive coverage of the self-test process by pre-storing a complete list of components to be tested, including all components that need to be deployed during the factory electrical testing phase, eliminating the risk of omissions. The unique component ID design guarantees accurate operation of the self-test management program during traversal, verification, and repair, avoiding accidental operations on erroneous components. Structured data format storage makes list reading, parsing, and updating operations efficient and reliable, supporting runtime management requirements such as dynamic deletion and tagging.

[0079] Figure 6 A schematic diagram of the overall architecture of a self-testing method for vehicle infotainment components provided in a specific embodiment of this application; see reference Figure 6 As shown, the MCU and SOC communicate via signals. The self-test management program matches the "fuel package parameters" and "ENC noise reduction parameters" in the local parameter resource library of the SOC with vehicle configuration information such as FD01, and sends the signals to the corresponding functional components of the MCU. In this solution, the overall architecture is divided into two parts: the SOC end and the MCU end, and the two ends achieve data interaction through signal communication.

[0080] In a specific embodiment, a self-test management program runs on the SOC side. From a functional module perspective, this program includes an electronic test flag detection module, a self-test management module, a component list storage module, and a local parameter resource library. The electronic test flag detection module reads the flag status reported by the MCU when the vehicle starts up to determine whether to trigger the self-test process. The self-test management module, as the core control unit, is responsible for operations such as component list traversal, version number verification, repair execution, and retry counting. The component list storage module stores a preset list of components to be tested. The local parameter resource library pre-stores full parameter files for multiple vehicle model items, including fuel package parameters and ENC noise reduction parameters.

[0081] On the MCU side, there is an electrical test flag storage area and multiple functional modules. The electrical test flag storage area uses non-volatile storage media (such as EEPROM) to persistently store the self-test control flags written during the factory electrical test phase, ensuring that the flags are not lost after power failure. The functional modules include a fuel module and a DSP module, which respectively handle the actual operation of the fuel pack parameter components and the ENC noise reduction parameter components.

[0082] During the self-test and repair process, the self-test management program matches the corresponding fuel package parameters and ENC noise reduction parameter standard installation package in the local parameter resource library of the SOC terminal with the vehicle configuration information (such as vehicle function configuration code FD01 and vehicle software version level LEVEL), and then sends the standard parameters to the corresponding functional module of the MCU terminal through signal communication to complete the verification and repair of the components.

[0083] In one embodiment of this application, the first component information includes a preset standard version number of the component to be tested; for example, this version number is the version identifier that the component should present in a correctly deployed state, which is determined by the component developer and written into the list of components to be tested when the software version is released. Correspondingly, the second component information includes the actual installed version number of the component to be tested in the vehicle system; it can be obtained by the self-test management program from the corresponding functional module on the MCU side through the HIDL interface.

[0084] Therefore, in this embodiment, the above step S203, comparing the first component information with the second component information to see if they are consistent, includes the following step S203': S203': Compare the preset standard version number of the component to be tested in the test list with the actual installation version number of the component to be tested in the vehicle system.

[0085] Taking the fuel pack parameter component as an example, the default standard version number is "6FL04FUE20260122". If the self-test management program obtains the actual version number of this component on the MCU side through the HIDL interface, which is also "6FL04FUE20260122", then the comparison is consistent, and the component deployment is determined to be normal. If the actual version number is "00L00FUE00000000" (indicating the default value of incorrect deployment) or any other non-standard version number, then the comparison is inconsistent, the component deployment is determined to be abnormal, and the subsequent repair process is triggered.

[0086] In this embodiment, the version number is used as the core indicator for determining the deployment status of a component, which has the following technical advantages: First, the version number is an objective and quantifiable indicator of the deployment status of a component, and the comparison result is deterministic, leaving no room for ambiguity; Second, the method of determining the precise matching of version numbers can effectively identify various deployment anomalies, such as not installed (version number is empty or default value), installation interrupted (version number is incomplete), and incorrect version installed (version number does not match); Finally, the acquisition and comparison of version numbers is simple and efficient, and will not have a significant impact on the performance of the vehicle system.

[0087] In one possible embodiment of this application, when performing installation verification on a certain vehicle infotainment component, if the component has dependencies on other vehicle infotainment components, the system first confirms, based on the dependency information, that the other components the component being tested depends on have passed the verification. Furthermore, in this embodiment, the aforementioned list of components to be tested also records the dependencies between components.

[0088] Figure 7 This is a schematic diagram of the structure of a vehicle infotainment component testing device provided in an embodiment of this application; see reference. Figure 7 As shown, the vehicle infotainment component testing device provided in this embodiment includes: The acquisition module 701 is used to acquire the list of components to be tested after the vehicle component detection work is started; The verification module 702 is used to perform installation verification on each component in the list of components to be tested in turn, referring to the list of components to be tested. The first processing module 703 is used to remove the verified component from the list or mark it in the list if the verification passes. The second processing module 704 is used to perform the installation and repair work of the component if the verification fails.

[0089] In one embodiment of this application, the above-mentioned verification module 702 specifically includes: The first component information acquisition unit is used to acquire the first component information of the detected component from the list; The second component information acquisition unit is used to acquire information about the second component actually installed in the detected component in the current vehicle system. The comparison unit is used to compare the first component information with the second component information to see if they are consistent. The confirmation unit is used to confirm whether the detected component has passed the verification based on the comparison result.

[0090] In one embodiment of this application, the above-mentioned confirmation unit is specifically used for: If the comparison is inconsistent, it is confirmed that the component being tested has failed the test; The second processing module 704 mentioned above is specifically used for: If the verification fails, the installation package storage location information of the abnormal component is obtained from the list of detected components; According to the storage location information, retrieve the corresponding installation package of the abnormal component from the local resource library; Send the installation package data to the faulty component, causing the faulty component to perform a reinstallation. After the reinstallation is completed, the component under test is reinstalled and tested until the component under test passes the test or the specified number of installations is reached, then the testing of the component under test is ended.

[0091] In one embodiment of this application, the above-mentioned confirmation unit is specifically used for: If the comparison matches, the detected component passes the test.

[0092] In one embodiment of this application, the above-mentioned apparatus further includes: The receiving module (not shown in the figure) is used to receive the preset flag status reported by the microcontroller unit (MCU) after the vehicle system is started. If the preset flag is in the enabled state, the detection work of the vehicle system component is started.

[0093] In one embodiment of this application, the above-mentioned apparatus further includes: A storage module (not shown in the figure) is used to pre-store the list of components to be tested. The list of components to be tested includes component information of all vehicle-mounted components deployed during the factory electrical inspection phase that need to be tested. Each vehicle-mounted component is assigned a unique identifier.

[0094] In one embodiment of this application, the first component information includes a preset standard version number of the component to be detected; The second component information includes the actual installed version number of the component to be tested in the vehicle infotainment system; In this embodiment, the comparison unit is specifically used for: The preset standard version number of the component to be tested in the test list is compared with the actual installed version number of the component to be tested in the vehicle system.

[0095] In one embodiment of this application, the second processing module 704 is specifically used for: Obtain the vehicle model configuration parameters of the current vehicle, including vehicle function configuration codes and vehicle software version levels; Based on the vehicle model function configuration code and the vehicle model software version level, index the storage path of the installation package that matches the current vehicle in the local resource library; According to the storage path obtained by the index, retrieve the standard installation package of the abnormal component from the local resource library.

[0096] In another embodiment of this application, an electronic device is also provided, with reference to Figure 8 As shown, the electronic device includes a processor 1110, a communication interface 1120, a memory 1130, and a communication bus 1140, wherein the processor 1110, the communication interface 1120, and the memory 1130 communicate with each other through the communication bus 1140. Memory 1130 is used to store computer programs; When the processor 1110 executes the program stored in the memory 1130, it implements the vehicle component self-detection method described in any of the foregoing method embodiments: After the vehicle infotainment system component testing is started, a list of components to be tested is obtained; Referring to the list of components to be tested, each component in the list is installed and verified in turn; If the verification passes, the component that passes the verification will be removed from the list or marked in the list; If the verification fails, the installation and repair of the component will be performed.

[0097] In one possible implementation, referring to the list of components to be tested, the installation verification is performed on each component in the list in sequence, including: Obtain the first component information of the detected component from the list; Obtain information about the second component actually installed in the current vehicle infotainment system for the component being detected. Compare the information of the first component with the information of the second component to see if they are consistent; Based on the comparison results, it is confirmed whether the detected component has passed the verification.

[0098] In one possible implementation, confirming whether the detected component passes verification based on the comparison result includes: If the comparison is inconsistent, it is confirmed that the component being tested has failed the test; If the verification fails, the installation and repair work of the component will be performed, including: If the verification fails, the installation package storage location information of the abnormal component is obtained from the list of detected components; According to the storage location information, retrieve the corresponding installation package of the abnormal component from the local resource library; Send the installation package data to the faulty component, causing the faulty component to perform a reinstallation. After the reinstallation is completed, the component under test is reinstalled and tested until the component under test passes the test or the specified number of installations is reached, then the testing of the component under test is ended.

[0099] In one possible implementation, confirming whether the detected component passes the detection based on the comparison result includes: If the comparison matches, the detected component passes the test.

[0100] In one possible implementation, the method further includes: After the vehicle system is started, it receives the status of the preset flag bit reported by the microcontroller unit (MCU). If the preset flag bit is in the enabled state, the detection work of the vehicle system components is started.

[0101] One possible implementation also includes: The list of components to be tested is stored in advance. The list includes component information of all vehicle-mounted components that need to be tested and are deployed during the factory electrical inspection stage. Each vehicle-mounted component is assigned a unique identifier.

[0102] In one possible implementation, the first component information includes a preset standard version number of the component to be detected; The second component information includes the actual installed version number of the component to be tested in the vehicle infotainment system; The step of comparing the first component information with the second component information to determine if they are consistent includes: The preset standard version number of the component to be tested in the test list is compared with the actual installed version number of the component to be tested in the vehicle system.

[0103] In one possible implementation, obtaining the corresponding installation package of the abnormal component from the local repository according to the storage location information includes: Obtain the vehicle model configuration parameters of the current vehicle, including vehicle function configuration codes and vehicle software version levels; Based on the vehicle model function configuration code and the vehicle model software version level, index the storage path of the installation package that matches the current vehicle in the local resource library; According to the storage path obtained by the index, retrieve the standard installation package of the abnormal component from the local resource library.

[0104] The electronic device provided in this embodiment of the invention enables the processor to execute programs stored in the memory to implement an installation verification process for vehicle-mounted components at the SOC end. When the verification fails, it performs installation and repair work on abnormal components. This allows for timely detection of the deployment status of component programs and timely correction in the case of unsuccessful or abnormal deployment, ensuring the stability of the vehicle-mounted system, improving the user experience, and reducing maintenance costs.

[0105] The communication bus 1140 mentioned in the above electronic device can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus 1140 can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, it is shown in the figure with only one thick line, but this does not indicate that there is only one bus or one type of bus.

[0106] The communication interface 1120 is used for communication between the above-mentioned electronic device and other devices.

[0107] The memory 1130 may include random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0108] The processor 1110 mentioned above can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0109] In another embodiment of this application, a computer-readable storage medium is also provided, on which a program for a vehicle component self-testing method is stored. When the program for the vehicle component self-testing method is executed by a processor, it implements the steps of the vehicle component self-testing method described in any of the foregoing method embodiments.

[0110] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0111] The above description is merely a specific embodiment of the present invention, enabling those skilled in the art to understand or implement the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the present invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A self-testing method for vehicle infotainment components, characterized in that, The method is applied to the system-on-a-chip (SoC) terminal, and the method includes: After the vehicle infotainment component testing process is started, obtain the list of components to be tested; Referring to the list of components to be tested, each component in the list is installed and verified in turn; If the verification passes, the component that passes the verification will be removed from the list or marked in the list; If the verification fails, the installation and repair of the component will be performed.

2. The method according to claim 1, characterized in that, Referring to the list of components to be tested, the installation verification is performed on each component in the list in sequence, including: Obtain the first component information of the detected component from the list; Obtain information about the second component actually installed in the current vehicle infotainment system for the component being detected. Compare the information of the first component with the information of the second component to see if they are consistent; Based on the comparison results, it is confirmed whether the detected component has passed the verification.

3. The detection method according to claim 2, characterized in that, The step of confirming whether the detected component passes the verification based on the comparison result includes: If the comparison is inconsistent, it is confirmed that the component being tested has failed the test; If the verification fails, the installation and repair of the component will be performed, including: If the verification fails, the installation package storage location information of the abnormal component is obtained from the list of detected components; According to the storage location information, retrieve the corresponding installation package of the abnormal component from the local resource library; Send the installation package data to the malfunctioning component, causing the malfunctioning component to perform a reinstallation. After the reinstallation is completed, the component under test is reinstalled and tested until the component under test passes the test or the specified number of installations is reached, then the testing of the component under test is ended.

4. The detection method according to claim 2, characterized in that, The step of confirming whether the detected component passes the detection based on the comparison result includes: If the comparison matches, the detected component passes the test.

5. The detection method according to claim 1, characterized in that, The method further includes: After the vehicle system is started, it receives the preset flag status reported by the microcontroller unit (MCU). If the preset flag is in the enabled state, the detection work of the vehicle system components is started.

6. The detection method according to claim 1, characterized in that, The method further includes: The list of components to be tested is stored in advance. The list includes component information of all vehicle-mounted components that need to be tested and are deployed during the factory electrical inspection stage. Each vehicle-mounted component is assigned a unique identifier.

7. The method according to claim 2, characterized in that, The first component information includes the preset standard version number of the component to be detected; The second component information includes the actual installed version number of the component to be tested in the vehicle infotainment system; The step of comparing the first component information with the second component information to determine if they are consistent includes: The preset standard version number of the component to be tested in the test list is compared with the actual installed version number of the component to be tested in the vehicle system.

8. The method according to claim 3, characterized in that, The step of retrieving the corresponding installation package of the abnormal component from the local resource library according to the storage location information includes: Obtain the vehicle model configuration parameters of the current vehicle, including vehicle function configuration codes and vehicle software version levels; Based on the vehicle model function configuration code and the vehicle model software version level, index the storage path of the installation package that matches the current vehicle in the local resource library; According to the storage path obtained by the index, retrieve the standard installation package of the abnormal component from the local resource library.

9. A vehicle infotainment component testing device, characterized in that, include: The acquisition module is used to obtain the list of components to be tested after the vehicle component detection work is started; The verification module is used to perform installation verification on each component in the list of components to be tested in turn. The first processing module is used to remove the verified component from the list or mark it in the list if the verification passes. The second processing module is used to perform the installation and repair work of the component if the verification fails.

10. An electronic device, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; When the processor executes the program stored in the memory, it implements the self-detection method for vehicle components as described in any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a program for a vehicle infotainment system component self-testing method, which, when executed by a processor, implements the steps of the vehicle infotainment system component self-testing method according to any one of claims 1-8.

Images