Tbox test software architecture, configuration method, medium and electronic device

Abstract

The application provides a TBOX test software architecture, a configuration method, a medium and an electronic device, which are applied to the technical field of intelligent networked vehicles and comprise a communication layer, a function adaptation layer, a software adaptation layer and a hardware layer. The hardware layer provides device components, the software adaptation layer manages the components and provides function modules, the function adaptation layer realizes function adaptation of different devices, and the communication layer supports data interaction with a host computer and external devices. The application adopts an architecture design which can adapt to various modules and external devices and has flexible configuration capability, supports function requirements of multiple master control units, realizes efficient hardware adaptation, and is helpful for quickly and effectively testing the function of the TBOX.

Description

Technical Field

[0001] This invention relates to the field of intelligent connected vehicle technology, and in particular to the TBOX test software architecture, configuration method, medium and electronic equipment. Background Technology

[0002] In modern production lines, rapid and efficient functional testing of Telematics Boxes (TBOX) is crucial for ensuring product quality. As automotive electronics become increasingly complex, the hardware architecture of TBOXes has evolved from a simple MCU (Microcontroller Unit) + MPU (Microprocessor Unit) configuration to a multi-master MCU + MPU + MPU structure. This change necessitates a suitable software architecture to support complex hardware functions, reduce problems during final inspection development, and ensure smooth production line operation and on-time delivery.

[0003] Existing testing solutions are primarily based on an MCU+MPU architecture, achieving functional interaction through CAN (Controller Area Network) communication between the host computer and the MCU. While this architecture performs well on simple hardware, it faces challenges such as chaotic control logic across multiple master control units and difficulties in software compatibility as hardware structures become more complex. Furthermore, changes in hardware configuration lead to extended development cycles and reduced production efficiency, becoming a common problem in the industry.

[0004] Therefore, how to support the functional requirements of multiple master control units and achieve efficient hardware adaptation has become a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0005] In view of the above problems, the present invention provides a TBOX test software architecture, configuration method, medium, and electronic device that overcomes or at least partially solves the above problems. The technical solution is as follows:

[0006] A TBOX testing software architecture, comprising: a communication layer, a functional adaptation layer, a software adaptation layer, and a hardware layer.

[0007] The hardware layer is located at the bottom layer and is used to provide corresponding device components according to different TBOX devices to support the implementation of software and functions;

[0008] The software adaptation layer is located above the hardware layer and is used to adapt to and manage the device components in the hardware layer, and to provide device function modules corresponding to the device components.

[0009] The functional adaptation layer is located above the software adaptation layer and is used to interact with the device components in the hardware layer through the software adaptation layer according to the software configuration requirements of different TBOX devices, so as to realize the functional adaptation of the TBOX device on different device components and provide the functional configuration units required by the TBOX device on the device components.

[0010] The communication layer is located above the functional adaptation layer and is used to interact with the host computer and external devices, and provides relevant protocols and interfaces to support the implementation of functions of the upper layer application.

[0011] Optionally, the communication layer includes CAN components and Ethernet components configured according to different communication methods to adapt to different communication scenarios.

[0012] Optionally, the device components include modules and peripherals.

[0013] A configuration method applied to the TBOX test software architecture, the method comprising:

[0014] For each device function module in the software adaptation layer, different device function modules are enabled through software configuration so that the device function modules can perform corresponding functions.

[0015] The communication layer abstracts different communication methods, allowing multiple communication methods to be used simultaneously to interact with the host computer, in order to adapt to different communication scenarios. The communication methods include CAN communication and / or Ethernet communication.

[0016] The data content sent by the host computer is parsed according to the protocol, and the parsing results are distributed to each device functional module. Each device functional module processes the corresponding protocol and requests the device status result from the corresponding device component. Each device component feeds back the device status result related to its own functional status to the corresponding device functional module. The device functional module feeds back the obtained device status result to the host computer.

[0017] Optionally, the method further includes:

[0018] The software abstracts and adapts the same functions of different device functional modules to reuse the functions, wherein the software matches each functional item through a corresponding protocol.

[0019] Optionally, the method further includes:

[0020] The device function modules in the software adaptation layer are selected, adapted, and compiled using configuration files to meet the differentiated needs of different TBOX devices for different device components.

[0021] Optionally, the method further includes:

[0022] The software adaptation layer configures the enabling of each device function module to adapt to the differentiated detection functions of different TBOX devices, thereby enabling each TBOX device to use different device components.

[0023] Optionally, the method further includes:

[0024] Differentiated function configurations are performed on each device function module in the software adaptation layer. The differentiated function configuration is used to configure the differentiated functions of each device function module in different TBOX devices so that the same device function module can adapt to different functions.

[0025] A computer-readable storage medium having a program stored thereon that, when executed by a processor, implements the configuration method described above.

[0026] An electronic device includes at least one processor, at least one memory connected to the processor, and a bus; wherein the processor and the memory communicate with each other via the bus; the processor is used to call program instructions in the memory to execute the configuration method.

[0027] By employing the above technical solutions, the present invention provides a TBOX testing software architecture, configuration method, medium, and electronic device. This architecture includes: a communication layer, a function adaptation layer, a software adaptation layer, and a hardware layer. The hardware layer is at the bottom layer, providing corresponding device components for different TBOX devices to support software and function implementation. The software adaptation layer is above the hardware layer, adapting and managing the device components in the hardware layer and providing corresponding device function modules. The function adaptation layer is above the software adaptation layer, interacting with the device components in the hardware layer according to the software configuration requirements of different TBOX devices to achieve function adaptation of the TBOX device on different device components, and providing the required function configuration units for the TBOX device on the device components. The communication layer is above the function adaptation layer, interacting with the host computer and external devices for data exchange, and providing relevant protocols and interfaces to support the function implementation of upper-layer applications. The present invention, by adopting an architecture design that can adapt to multiple modules and external devices and has flexible configuration capabilities, supports the functional requirements of multiple master control units, thereby achieving efficient hardware adaptation and facilitating rapid and effective functional testing of TBOX devices.

[0028] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention and to implement it in accordance with the contents of the specification, and in order to make the above and other objects, features and advantages of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0029] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0030] Figure 1 A production system topology diagram provided in an embodiment of the present invention is shown;

[0031] Figure 2 A block diagram of the EOL module system provided in an embodiment of the present invention is shown;

[0032] Figure 3 This diagram illustrates the hierarchical architecture of the TBOX testing software provided in an embodiment of the present invention.

[0033] Figure 4 The diagram shows a flowchart of one implementation of the configuration method provided in this invention. Detailed Implementation

[0034] Exemplary embodiments of the invention will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the invention are shown in the drawings, it should be understood that the invention may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided to enable a more thorough understanding of the invention and to fully convey the scope of the invention to those skilled in the art.

[0035] In modern production lines, rapid and efficient functional testing of in-vehicle telematics boxes (TBOX) has become a crucial step in ensuring product quality. As automotive electronics become increasingly complex, the hardware architecture of TBOXes has evolved from a simple configuration of traditional MCU (Microcontroller Unit) + MPU (Microprocessor Unit) to a multi-master architecture of MCU + MPU + MPU, or even more master control units. This shift makes building a suitable software architecture a critical prerequisite for supporting complex hardware, reducing problems during the end-of-line (EOL) development process, and ensuring smooth production line operation and on-time delivery.

[0036] Existing testing solutions are mostly based on an MCU+MPU architecture, using CAN (Controller Area Network) communication between the host computer and the MCU for functional interaction. The MCU is responsible for data forwarding with the host computer, while the MPU is responsible for overall control. This architecture can achieve the required functions well with simple hardware. However, with the increasing complexity of hardware structures, this single architecture faces many challenges. First, for multi-master control unit architectures, existing solutions struggle to effectively distinguish the primary and secondary roles of each master unit, leading to confusion in control logic. Second, at the software level, compatibility and adaptation for different hardware become increasingly difficult, especially when hardware configurations change. Extended development cycles and reduced production efficiency have become common problems in the industry.

[0037] Furthermore, because the peripheral circuits of each main control unit have different functions, existing adaptation solutions can only be customized for single products, lacking a platform-based, universal solution. This not only leads to a significant waste of human resources but also impacts production efficiency. Therefore, there is an urgent need to develop a new software architecture that can support the functional requirements of multiple main control units, achieve efficient hardware adaptation, shorten the development cycle, and improve system compatibility and scalability. This need has spurred in-depth research and development of the TBOX test software architecture to achieve a more efficient and flexible production testing solution.

[0038] Figure 1The diagram illustrates the production system topology provided in this embodiment of the invention, highlighting the key roles and workflow of the TBOX device within the system. The TBOX supports a multi-module and multi-peripheral hardware architecture, designed to meet the needs of different application platforms and ensure flexible adaptation. The diagram shows multiple platforms (Platform A, ..., Platform N, etc.), representing different application environments or usage scenarios. The TBOX can interact bidirectionally with these different platforms, ensuring it can adapt and optimize according to the specific needs of each platform. Located at the center of the diagram, the TBOX is the core of the entire system, integrating multiple modules and peripherals. This design enables the TBOX to quickly respond to production demands and supports various combinations, thereby improving production efficiency and applicability. During production, the interaction between the TBOX and the industrial control computer (ICC) is crucial. The ICC manages, monitors, and configures the TBOX, ensuring its normal operation according to predetermined parameters and requirements. Ultimately, the TBOX transmits and controls data with the production system through the ICC, ensuring the coordination and efficiency of the entire production process. The production system is responsible for final product testing, quality control, and data recording, ensuring that the produced products meet standards. It is evident that the TBOX equipment, through collaboration with various platforms, industrial control computers, and production systems, forms an efficient and flexible production adaptation system that can meet various combined uses and quickly adapt to production.

[0039] Figure 2 The diagram shown is a block diagram of the EOL module system provided in an embodiment of the present invention. This diagram illustrates the actual physical composition of the TBOX and its multi-module and multi-peripheral architecture design concept. Through this design, the TBOX can be flexibly combined and expanded according to different needs, thereby meeting diverse application scenarios. The TBOX device is shown at the center of the diagram; it is the core of the entire system. The TBOX forms a feature-rich system by connecting multiple peripherals and modules. Each peripheral and module can contain multiple functional modules, giving the TBOX high flexibility and adaptability. It is evident that the design concept of the TBOX is to ensure that users can add or replace modules and peripherals at any time according to their needs, enabling rapid response to market changes and technological updates. This design not only improves the usability of the device but also reduces the cost of later maintenance and upgrades.

[0040] Based on this, embodiments of the present invention provide a TBOX testing software architecture, such as... Figure 3 As shown, the architecture consists of four layers: a communication layer, a functional adaptation layer, a software adaptation layer, and a hardware layer.

[0041] The hardware layer is located at the bottom layer and is used to provide corresponding device components for different TBOX devices to support the implementation of software and functions.

[0042] The hardware layer is the foundation of the entire TBOX system architecture, located at the lowest level, and is primarily responsible for providing physical devices and basic hardware support. The hardware layer provides the necessary hardware foundation for the TBOX, including processors, memory, interface modules, etc. These hardware components provide the necessary environment and resources for the operation of upper-layer software. The hardware layer can also flexibly select and configure appropriate device components according to different models and functions of TBOX devices, enabling the TBOX to adapt to various application scenarios and meet different user needs.

[0043] Device components are an important part of the hardware layer, specifically including modules and peripherals, each undertaking different functions and tasks.

[0044] Modules are hardware units with fixed functions, such as communication modules and sensor modules. They are responsible for implementing specific functions, such as data acquisition, signal processing, and communication with other devices. Module design emphasizes modularity, allowing users to select and replace modules according to different needs, thereby achieving customized functions.

[0045] Peripherals refer to various peripheral devices connected to the TBOX, such as monitors, input devices, and storage devices. Peripherals are typically used for user interaction or to extend the functionality of the TBOX. Users can select and combine appropriate peripherals according to their actual needs to enhance the overall functionality of the system.

[0046] The software adaptation layer is located above the hardware layer. It is used to adapt to and manage device components in the hardware layer and to provide device function modules corresponding to the device components.

[0047] The software adaptation layer sits above the hardware layer, primarily responsible for adapting and managing device components within the hardware layer. Through drivers and middleware, the software adaptation layer interacts with the underlying device components (modules and peripherals), ensuring these components function correctly and fulfill their intended purpose, monitoring device status and performance, and performing necessary resource allocation and scheduling. The software adaptation layer provides an abstract interface, allowing upper-layer applications to access and control different device components in a unified manner. This abstraction eliminates the need for applications to concern themselves with the specific implementation details of the underlying hardware, thereby improving development efficiency and system flexibility. The software adaptation layer also adapts to various hardware models and brands, giving the TBOX system better compatibility. By adapting to different hardware, TBOX can be flexibly configured according to user needs.

[0048] Device functional modules are primarily used to implement specific functions related to hardware components. Each device functional module corresponds to a specific hardware component and is responsible for implementing the functions of that component. For example, a communication module may include functions such as data transmission and protocol processing, while a sensor module is responsible for data acquisition and processing. The device functional modules adopt a modular design concept, allowing users to select, add, or replace specific functional modules according to the actual needs of the device components. Device functional modules can also provide standardized interfaces, enabling upper-layer applications to easily call and use these functions. Therefore, the software adaptation layer can support the hardware requirements of different types of TBOXes and has the ability to flexibly adapt to new modules or peripherals. The design of the software adaptation layer emphasizes good scalability, enabling the TBOX testing software architecture to adapt to constantly changing needs, easily integrate and manage new device components, and achieve effective utilization of hardware resources and functional expansion.

[0049] The functional adaptation layer is located above the software adaptation layer. It is used to interact with the device components in the hardware layer according to the software configuration requirements of different TBOX devices, so as to realize the functional adaptation of the TBOX device on different device components, and provide the functional configuration units required by the TBOX device on the device components.

[0050] The function configuration unit is a crucial component of the function adaptation layer, primarily used for specific function settings and management. It provides the necessary function configurations for each device component, employing a modular design that allows different functions to be configured independently. This structure enables users to flexibly select and configure functions according to their actual needs.

[0051] The functional adaptation layer sits above the software adaptation layer. Its main function is to adapt the functions of various device components according to the software configuration requirements of different TBOX devices to meet differentiated usage needs. Specifically, each TBOX product has specific requirements. By breaking down these requirements, the specific functions that each device functional module needs to support on that TBOX device can be identified. In this process, the functional adaptation layer analyzes the potential functions of each device functional module. For example, if a device functional module has ten functions, but a specific TBOX device only requires five, then the functional adaptation layer will focus on adapting those five functions. In this case, the unselected functions will not be activated, thus ensuring efficient system operation. Furthermore, for some functions, if the decomposed requirements are not yet supported by the current device functional module, the functional adaptation layer will need to develop corresponding code to implement these functions; while functions that are already available can be directly reused. The functional adaptation layer also allows for the adjustment and adaptation of unnecessary functions or the implementation of differentiated requirements through configuration files, thereby providing flexible solutions and ensuring smooth functional adaptation of TBOX devices on different device components.

[0052] The communication layer sits above the functional adaptation layer and is used to interact with the host computer and external devices, providing relevant protocols and interfaces to support the implementation of functions in upper-layer applications.

[0053] The communication layer sits above the functional adaptation layer and is primarily responsible for data interaction with the host computer and external devices. The communication layer provides relevant protocols and interfaces to support the functionality of upper-layer applications. The design of the communication layer aims to ensure that the TBOX can flexibly and efficiently exchange information with external systems, meeting the communication requirements under various communication protocols.

[0054] The host computer refers to a computer or system outside the TBOX device, typically used for monitoring, managing, and controlling the TBOX's functions. The host computer connects to the TBOX via a communication layer, enabling data acquisition, analysis, and the transmission of operational commands, providing users with a convenient management interface and functional control.

[0055] External devices refer to other systems or hardware that interact with the TBOX, including sensors, actuators, and other control units. These devices connect to the TBOX via a communication layer, responsible for sending and receiving data, enabling functional expansion and system interconnection.

[0056] Upper-layer applications refer to specific application programs or functional modules built upon the interfaces and protocols provided by the communication layer. These applications interact with the host computer and external devices through the communication layer to complete specific tasks, such as data processing, status monitoring, and execution of control commands.

[0057] Optionally, the communication layer includes CAN and Ethernet components configured according to different communication methods to adapt to different communication scenarios.

[0058] The CAN component is specifically designed to support communication based on the CAN protocol. CAN is a highly efficient serial communication protocol widely used in automotive and industrial automation. The CAN component, through its specific interface and protocol, exchanges data with other CAN-enabled devices, ensuring real-time performance and stability, making it suitable for scenarios requiring high-speed data transmission.

[0059] The Ethernet component supports Ethernet-based communication. Ethernet, a common network communication technology, boasts high bandwidth and a wide range of applications. The Ethernet component provides connectivity to external networks, enabling the TBOX to interact with other devices via the internet or local area network, conduct functional testing, and perform remote management.

[0060] The communication layer enables efficient data interaction with the host computer and external devices, supporting the implementation of functions in upper-layer applications. Its internal CAN and Ethernet components are adapted to different communication scenarios, ensuring that the system can flexibly cope with diverse communication needs.

[0061] The TBOX testing software architecture provided by this invention includes a communication layer, a function adaptation layer, a software adaptation layer, and a hardware layer. The hardware layer, located at the bottom, provides corresponding device components for different TBOX devices to support software and function implementation. The software adaptation layer, located above the hardware layer, adapts to and manages the device components in the hardware layer and provides corresponding device function modules. The function adaptation layer, located above the software adaptation layer, interacts with the device components in the hardware layer according to the software configuration requirements of different TBOX devices, enabling function adaptation of the TBOX device on different device components and providing the required function configuration units for the TBOX device on the device components. The communication layer, located above the function adaptation layer, interacts with the host computer and external devices, providing relevant protocols and interfaces to support the function implementation of upper-layer applications. This invention, by adopting an architecture design that can adapt to multiple modules and external devices and has flexible configuration capabilities, supports the functional requirements of multiple master control units, thereby achieving efficient hardware adaptation and facilitating rapid and effective functional testing of TBOX devices.

[0062] Based on the components and functions of the TBOX testing software architecture described above, this embodiment of the invention also provides a configuration method to achieve flexible function configuration and efficient data interaction on this architecture. Through this configuration method, customized settings can be made for each device functional module in the software adaptation layer, and interaction with the host computer and external devices can be achieved through various communication methods via the communication layer. This method not only optimizes the functional implementation of the device but also improves the overall performance and adaptability of the TBOX testing software architecture. Figure 4 The diagram shows a flowchart of one embodiment of the configuration method provided by this invention. The configuration method may include:

[0063] S400. For each device function module in the software adaptation layer, different device function modules are enabled through software configuration so that the device function modules can perform the corresponding functions.

[0064] In the software adaptation layer, each device functional module can be flexibly configured according to actual needs. By configuring different enable options in the software, specific device functional modules can be selectively activated or disabled, thereby enabling the activated device functional modules to perform corresponding functions and meet the testing requirements of different TBOXes.

[0065] In the software adaptation layer, each device functional module can flexibly manage its enabling state through configuration files to achieve the required functions. Specifically, users can selectively disable unnecessary device functional modules to avoid impacting overall performance and prevent interference between functions. For example, a WiFi module can simultaneously connect to a wireless network and act as a wireless hotspot, but not all TBOXes need both functions. Some devices may only support one function, or require both. In this case, the configuration file will ensure that only the necessary functions are enabled based on the actual functional requirements of the TBOX. Furthermore, considering that different TBOXes may use different models of WiFi modules, although most WiFi modules support both connecting to a wireless network and acting as a wireless hotspot, the TBOX's hardware or software may only support one function, making it impossible to configure the other function.

[0066] Optionally, embodiments of the present invention can also abstract and adapt the same functions of different device functional modules to reuse the functions of the software, wherein the software matches each functional item through a corresponding protocol.

[0067] If a TBOX is equipped with two WiFi modules, and you want to control one WiFi module as a hotspot while the other connects to a wireless network, the host computer needs to identify and operate the different modules using predefined protocols. For example, protocol A can be set to control the first WiFi module, and protocol B to control the second. Therefore, regardless of the number of WiFi modules connected to the TBOX, it can flexibly adapt and correctly control the functions.

[0068] S410 abstracts different communication methods through the communication layer, allowing multiple communication methods to be used simultaneously to interact with the host computer, in order to adapt to different communication scenarios. The communication methods include CAN communication and / or Ethernet communication.

[0069] In the communication layer, by abstracting different communication methods, flexible interaction with the host computer can be achieved. This design allows the TBOX to use multiple communication methods simultaneously to adapt to different communication scenarios and needs. Specifically, communication methods can include CAN communication and Ethernet communication, etc. For example, in some TBOXes, CAN communication may be used for real-time transmission of vehicle status data, while Ethernet communication can be used for transmission of larger data volumes, such as video streams or remote control commands. This embodiment of the invention supports interaction with the host computer through the abstraction of different communication methods at the communication layer, including CAN communication and Ethernet communication. This allows for flexible selection of single or multiple communication methods for data transmission in different communication scenarios, thereby achieving efficient TBOX adaptation. Regardless of whether the TBOX uses CAN communication, Ethernet communication, or both, it can meet the corresponding testing requirements.

[0070] S420: Parse the data sent by the host computer according to the protocol, and distribute the parsing results to each device function module. Each device function module processes the corresponding protocol and requests the device status result from the corresponding device component. Each device component feeds back the device status result related to its own function status to the corresponding device function module. The device function module feeds back the obtained device status result to the host computer.

[0071] In this embodiment of the invention, the data content sent by the host computer undergoes protocol parsing to ensure correct understanding and processing. Specifically, the protocol parsing process interprets the information sent by the host computer into instructions or data that the system can understand. The parsed results are distributed to various device function modules, which are responsible for their respective functional processing. Each device function module requests the current device status from the device components it manages based on the parsing results. For example, if a device function module is responsible for monitoring a temperature sensor, it will send a request to the relevant temperature sensor component to obtain the latest temperature data. Each device component, based on its own functional status, will report its own status results, such as the current temperature value or functional operating status, to the corresponding device function module. Finally, the device function modules summarize all the collected device status results and feed this information back to the host computer.

[0072] To facilitate understanding of the complete configuration process provided in this embodiment of the invention, an example is given below: Assume a TBOX contains two Wi-Fi modules. Module A supports both STA (client) and AP (hotspot) modes, while module B only supports STA mode. Although both modules have low-power functionality, under current requirements, module A only needs to use AP mode and enable its low-power function, while module B operates in STA mode but does not require low-power functionality. To simultaneously support and verify the functionality of both Wi-Fi modules, the following steps are required: First, the hardware must ensure support for the connection and functionality of both Wi-Fi modules. Next, in the software adaptation layer, the STA and AP functions of module A need to be developed (although the STA mode may have been developed in other projects, it can be omitted here), and the STA function of module B and the low-power characteristics of both chips need to be implemented. Subsequently, in the functional adaptation layer, both Wi-Fi modules need to be configured simultaneously, explicitly indicating that module A uses only AP mode, while module B uses STA mode. Simultaneously, the low-power function of module A must be enabled, while the low-power function of module B must be disabled. At this point, the communication protocols supported by each module also need to be configured. During the host computer testing process, different protocols are used to control the use of the Wi-Fi modules. When module A needs to be activated, the corresponding protocol command is sent to activate its AP mode; when module B needs to be used, its STA mode is activated via a protocol command, thus avoiding software conflicts. Furthermore, for the functional adaptation layer, scenarios where multiple master controllers connect to the same Wi-Fi module need to be considered. In this case, a master controller serial number configuration needs to be set, and the protocol index is calculated using the protocol. In this way, regardless of the number of master controllers connected to how many types of modules, the TBOX testing software architecture can effectively adapt, ensuring smooth collaboration and information transmission between modules.

[0073] This invention implements corresponding device functions by configuring different functional modules in the software adaptation layer. Simultaneously, the abstraction of the communication layer allows the TBOX testing software architecture to flexibly support multiple communication methods (such as CAN and Ethernet communication) to adapt to different communication scenarios. Based on this, the data sent by the host computer is precisely distributed to each device functional module after protocol parsing. These modules then request status from the corresponding device components and feed back the received device status results to the host computer. Through this efficient hardware adaptation method, this invention not only enables rapid response to different functional requirements but also significantly improves the functional testing efficiency of the TBOX.

[0074] Optionally, in the above Figure 4 In addition to one or more corresponding embodiments, another optional embodiment provided by the present invention may further include:

[0075] The device function modules in the software adaptation layer are selected, adapted, and compiled using configuration files to meet the differentiated needs of different TBOX devices for different device components.

[0076] In this context, "selection and adaptation" refers to choosing the most suitable functional modules from the existing device functional modules based on the actual application scenario and device requirements. This process allows users to quickly adjust the combination of functional modules according to different project needs, ensuring that the TBOX testing software architecture can effectively support the required functions.

[0077] In this process, compilation adaptation refers to compiling selected functional modules based on the chosen adaptation criteria to generate the final software suitable for a specific TBOX device. This process ensures that the selected functional modules can run efficiently on the target hardware, while also allowing for targeted optimization to meet the performance requirements of different device components.

[0078] Specifically, embodiments of the present invention can provide configuration files for adapting device functional modules to corresponding API formats. These configuration files allow for the selection, adaptation, and compilation of device functional modules within the software adaptation layer, meeting the diverse needs of different TBOX devices for various modules and peripherals. The configuration files offer exceptional flexibility and ease of use, supporting multi-module architectures within the TBOX. For example, on a specific TBOX, if module model A is used, it can be configured as ql_api_v2; when switching to another module model, the configuration simply needs to be adjusted to ql_api_v3. This mechanism ensures extended support for all module models, making the adaptation process between different modules more efficient and convenient, thereby meeting the needs of various application scenarios.

[0079] This invention, through a configuration file-driven adaptation mechanism, can quickly respond to the differentiated needs of various TBOX devices, thereby achieving personalized customization, reducing development and maintenance complexity, and improving the flexibility and scalability of the TBOX testing software architecture. This method not only saves development time but also enhances the software's adaptability, making the functional implementation of different TBOXes more accurate and efficient.

[0080] Optionally, in the above Figure 4 In addition to one or more corresponding embodiments, another optional embodiment provided by the present invention may further include:

[0081] Configure the module enable for each device function module in the software adaptation layer to enable and configure the different detection functions of different TBOX devices, so that each TBOX device can use different device components.

[0082] This invention configures the enabling of various device functional modules in the software adaptation layer to adapt to the specific detection functions of different TBOX devices through differentiated enabling settings. This process allows for the selective enabling or disabling of certain device functional modules according to the specific needs of each TBOX device, thereby achieving optimal device performance and accurate functional detection.

[0083] Specifically, each TBOX device may be equipped with different hardware components and functional requirements. Therefore, in the software adaptation layer, module enablement configuration can be flexibly performed through configuration files. In this case, users can enable relevant device function modules according to the required functions to support specific detection tasks. That is, specific function modules can be flexibly enabled or disabled according to the needs of different TBOX devices. For example, for GNSS (Global Navigation Satellite System) functionality, if a TBOX device supports GNSS, it is enabled in the configuration; if the device does not support GNSS, it is disabled. Through this differentiated enablement configuration, the specific detection needs of each TBOX device can be effectively adapted, ensuring that they can make full use of their respective device components.

[0084] Through differentiated enable configurations, this invention allows each TBOX device to effectively utilize its unique components to achieve targeted functional testing and performance optimization. This not only improves the flexibility and scalability of the TBOX testing software architecture but also ensures the reliability and efficiency of different TBOX devices in practical applications.

[0085] Optionally, in the above Figure 4In addition to one or more corresponding embodiments, another optional embodiment provided by the present invention may further include:

[0086] Differentiated function configurations are performed on each device function module in the software adaptation layer. The differentiated function configuration is used to configure the differentiated functions of each device function module in different TBOX devices so that the same device function module can adapt to different functions.

[0087] The differentiated function configuration allows for flexible settings of various device function modules in the software adaptation layer to adapt to the specific functional requirements of different TBOX devices. The purpose of this configuration is to enable the same device function module to be adjusted according to the requirements of different products, thereby achieving diverse function adaptation.

[0088] Specifically, different TBOX devices may differ in hardware components, application scenarios, and business requirements. Through differentiated function configuration, users can selectively enable or disable certain functions, or adjust function parameters, based on the characteristics of each device to achieve optimal adaptation. For example, two different WiFi modules, although belonging to the same type, require different usernames and passwords when connecting to WiFi networks. In one TBOX device, the WiFi module's SSID might be set to "TBOX" and the password to "TBOX1234"; while in another device, these settings may need to be changed to different SSIDs and passwords. Through such configuration, differentiated function configuration ensures that the same module can flexibly adapt to different functional implementations according to the needs of each device.

[0089] The embodiments of the present invention improve the flexibility and adaptability of the TBOX test software architecture through differentiated function configuration, enabling each TBOX device to make more effective use of its hardware resources.

[0090] Although the operations are described in a specific order, this should not be construed as requiring these operations to be performed in the specific order shown or in a sequential order. In certain environments, multitasking and parallel processing may be advantageous.

[0091] It should be understood that the various steps described in the method embodiments of the present invention may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of the present invention is not limited in this respect.

[0092] This invention provides a computer-readable storage medium storing a program that, when executed by a processor, implements the configuration method.

[0093] This invention provides a processor for running a program, wherein the program executes the configuration method during runtime.

[0094] This invention provides an electronic device, which includes at least one processor, at least one memory connected to the processor, and a bus; wherein the processor and the memory communicate with each other via the bus; the processor is used to call program instructions in the memory to execute the above-described configuration method. The electronic device described herein may be a server, PC, PAD, mobile phone, etc.

[0095] The present invention also provides a computer program product that, when executed on an electronic device, is suitable for executing a program with initialization configuration method steps.

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

[0097] In a typical configuration, an electronic device includes one or more processors (CPUs), memory, and a bus. The electronic device may also include input / output interfaces, network interfaces, etc.

[0098] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, like read-only memory (ROM) or flash RAM, and memory includes at least one memory chip. Memory is an example of computer-readable media.

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

[0100] In the description of this invention, it should be understood that if the terms "upper", "lower", "front", "rear", "left" and "right" are used to indicate the orientation or positional relationship based on the orientation or positional relationship shown in the drawings, they are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the position or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this invention.

[0101] It should be noted that, in this document, relational terms such as "first" and "second" are used only 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. It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, 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 the element.

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

[0103] The above are merely embodiments of the present invention and are not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of the present invention should be included within the scope of the present invention.

Claims

1. A TBOX testing software architecture, characterized in that, The architecture includes: a communication layer, a function adaptation layer, a software adaptation layer, and a hardware layer. The hardware layer is located at the bottom layer and is used to provide corresponding device components according to different TBOX devices to support the implementation of software and functions; The software adaptation layer is located above the hardware layer and is used to adapt to and manage the device components in the hardware layer, and to provide device function modules corresponding to the device components. The functional adaptation layer is located above the software adaptation layer and is used to interact with the device components in the hardware layer through the software adaptation layer according to the software configuration requirements of different TBOX devices, so as to realize the functional adaptation of the TBOX device on different device components and provide the functional configuration units required by the TBOX device on the device components. The communication layer is located above the functional adaptation layer and is used to interact with the host computer and external devices, and provides relevant protocols and interfaces to support the implementation of functions of the upper layer application.

2. The architecture according to claim 1, characterized in that, The communication layer includes CAN and Ethernet components configured according to different communication methods to adapt to different communication scenarios.

3. The architecture according to claim 1 or 2, characterized in that, The device components include modules and peripherals.

4. A configuration method, characterized in that, The method, applied to the TBOX test software architecture of any one of claims 1 to 3, comprises: For each device function module in the software adaptation layer, different device function modules are enabled through software configuration so that the device function modules can perform corresponding functions. The communication layer abstracts different communication methods, allowing multiple communication methods to be used simultaneously to interact with the host computer, in order to adapt to different communication scenarios. The communication methods include CAN communication and / or Ethernet communication. The data content sent by the host computer is parsed according to the protocol, and the parsing results are distributed to each device functional module. Each device functional module processes the corresponding protocol and requests the device status result from the corresponding device component. Each device component feeds back the device status result related to its own functional status to the corresponding device functional module. The device functional module feeds back the obtained device status result to the host computer.

5. The method according to claim 4, characterized in that, Also includes: The software abstracts and adapts the same functions of different device functional modules to reuse the functions, wherein the software matches each functional item through a corresponding protocol.

6. The method according to claim 4, characterized in that, Also includes: The device function modules in the software adaptation layer are selected, adapted, and compiled using configuration files to meet the differentiated needs of different TBOX devices for different device components.

7. The method according to claim 4, characterized in that, Also includes: The software adaptation layer configures the enabling of each device function module to adapt to the differentiated detection functions of different TBOX devices, thereby enabling each TBOX device to use different device components.

8. The method according to claim 4, characterized in that, Also includes: Differentiated function configurations are performed on each device function module in the software adaptation layer. The differentiated function configuration is used to configure the differentiated functions of each device function module in different TBOX devices so that the same device function module can adapt to different functions.

9. A computer-readable storage medium having a program stored thereon, characterized in that, When the program is executed by the processor, it implements the configuration method as described in any one of claims 4 to 8.

10. An electronic device, characterized in that, The electronic device includes at least one processor, at least one memory connected to the processor, and a bus; wherein the processor and the memory communicate with each other through the bus; the processor is used to call program instructions in the memory to execute the configuration method as described in any one of claims 4 to 8.

Images