TBOX test software architecture, configuration method, medium and electronic equipment

Abstract

The invention provides a TBOX test software architecture, a configuration method, a medium and electronic equipment, which are applied to the technical field of intelligent networked automobiles, and the architecture comprises a communication layer, a function adaptation layer, a software adaptation layer and a hardware layer. The hardware layer provides equipment components, the software adaptation layer manages the components and provides function modules, the function adaptation layer realizes function adaptation of different equipment, and the communication layer supports data interaction with an upper computer and external equipment. According to the invention, a framework design which can adapt to various modules and external equipment and has flexible configuration capability is adopted, and functional requirements of multiple main control units are supported, so that efficient hardware adaptation is realized, and the function test on the TBOX can be quickly and effectively carried out.

Description

Technical Field

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

[0002] On modern production lines, fast and efficient functional testing of in-vehicle intelligent terminals (Telematics Boxes, TBOXes) is critical to ensuring product quality. With the increasing complexity of automotive electronic products, TBOX hardware architectures have evolved from a simple MCU (Microcontroller Unit) + MPU (Microprocessor Unit) configuration to a multi-master MCU + MPU + MPU structure. This evolution requires the establishment of a suitable software architecture to support complex hardware functions, reduce issues during final inspection and development, and ensure smooth production line operation and on-time delivery.

[0003] Existing testing solutions are primarily based on an MCU+MPU architecture, enabling functional interaction through CAN (Controller Area Network) communication between the host computer and the MCU. While this architecture performs well on simple hardware, as hardware becomes more complex, it faces challenges such as confusing control logic within multiple master control units and difficulty in software compatibility and adaptation. Furthermore, changes in hardware configuration extend development cycles and reduce production efficiency, becoming common industry issues.

[0004] Therefore, how to support the functional requirements of multiple main control units and achieve efficient hardware adaptation has become a technical problem that technical personnel in this field urgently need to solve. 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 overcome the above problems or at least partially solve the above problems. The technical solution is as follows:

[0006] A TBOX test software architecture, comprising: a communication layer, a function 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 and manage device components in the hardware layer and provide device function modules corresponding to the device components;

[0009] The function 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, to achieve function adaptation of the TBOX device on different device components, and to provide the function configuration units required by the TBOX device on the device components;

[0010] The communication layer is located above the function adaptation layer, and is used for data interaction with the host computer and external devices, and provides relevant protocols and interfaces to support the function implementation of upper-layer applications.

[0011] Optionally, the communication layer includes CAN components and Ethernet components configured according to different communication modes 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, comprising:

[0014] For each device function module of the software adaptation layer, different device function modules are enabled through software configuration so that the device function modules realize corresponding functions;

[0015] By abstracting different communication modes through the communication layer, it is allowed to use multiple communication modes to interact with the host computer at the same time to adapt to different communication scenarios, wherein the communication modes include CAN communication and / or Ethernet communication;

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

[0017] Optionally, the method further includes:

[0018] The same functions of different device function modules are abstractly adapted to reuse the functions of the software, wherein the software matches each function item through the corresponding protocol.

[0019] Optionally, the method further includes:

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

[0021] Optionally, the method further includes:

[0022] Module enabling configuration is performed on each device function module in the software adaptation layer, so as to adapt the differentiated detection functions of different TBOX devices through differentiated enabling configuration, thereby enabling each TBOX device to use different device components.

[0023] Optionally, the method further includes:

[0024] Differentiated functional configuration is performed on each device functional module in the software adaptation layer, wherein the differentiated functional configuration is used to configure differentiated functions of each device functional module in different TBOX devices, so that the same device functional module adapts to different functions.

[0025] A computer-readable storage medium stores a program, which implements the configuration method when executed by a processor.

[0026] An electronic device comprises 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; and the processor is used to call program instructions in the memory to execute the configuration method.

[0027] By means of the above technical solution, the present invention provides a TBOX test software architecture, configuration method, medium and electronic device. 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 and manage the device components in the hardware layer and provide device function modules corresponding to the device components; the function 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 to achieve the function adaptation of the TBOX device on different device components and provide the function configuration units required by the TBOX device on the device components; the communication layer is located above the function adaptation layer and is used to exchange data with the host computer and external devices and provide relevant protocols and interfaces to support the function implementation of upper-layer applications. The present invention adopts an architecture design that can adapt to multiple modules and external devices and has flexible configuration capabilities, supports the functional requirements of multiple main control units, thereby achieving efficient hardware adaptation, and thus facilitating fast and effective function testing of TBOX.

[0028] The above description is only an overview of the technical solution of the present invention. In order to more clearly understand the technical means of the present invention, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the present invention more obvious and easy to understand, the specific implementation methods of the present invention are specifically listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] Various other advantages and benefits will become apparent to those skilled in the art upon reading the detailed description of the preferred embodiment below. The accompanying drawings are for illustration purposes only and are not to be considered as limiting the present invention. The same reference symbols are used throughout the drawings to represent the same components. In the drawings:

[0030] Figure 1 shows a topological diagram of a production system provided by an embodiment of the present invention;

[0031] Figure 2 shows a block diagram of the EOL module system provided by an embodiment of the present invention;

[0032] Figure 3 A schematic diagram of the hierarchical architecture of the TBOX test software architecture provided by an embodiment of the present invention is shown;

[0033] Figure 4 A flow chart showing an implementation of a configuration method provided by an embodiment of the present invention is shown. DETAILED DESCRIPTION

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

[0035] On modern production lines, rapid and efficient functional testing of in-vehicle intelligent terminals (Telematics Boxes, TBOXes) has become a crucial step in ensuring product quality. With the increasing complexity of automotive electronic products, TBOX hardware architecture has evolved from the traditional simple configuration of MCU (Microcontroller Unit) + MPU (Microprocessor Unit) to a multi-controller architecture consisting of MCU + MPU + MPU, or even more. This shift makes building a suitable software architecture a crucial prerequisite for supporting complex hardware, mitigating issues during the final end-of-line (EOL) development process and ensuring smooth production line operation and on-time delivery.

[0036] Existing testing solutions are mostly based on the MCU+MPU architecture, with functional interaction achieved through CAN (Controller Area Network) communication between the host computer and the MCU. The MCU is responsible for data forwarding with the host computer, while the MPU is responsible for overall control. This architecture can well implement the required functions when faced with simple hardware. However, with the increasing complexity of hardware structures, this single architecture faces many challenges. First, for architectures with multiple master control units, existing solutions cannot effectively distinguish the primary and secondary status of each master control, resulting in confusion in the control logic. Second, at the software level, compatibility and adaptation for different hardware are becoming increasingly difficult, especially when the hardware configuration changes. Extended development cycles and reduced production efficiency have become common problems in the industry.

[0037] Furthermore, because each master control unit (MCU) carries distinct peripheral circuit functions, existing adaptation solutions can only be customized for a single product, lacking a universal platform-based solution. This not only results in a significant waste of human resources but also compromises production efficiency. Therefore, there is an urgent need to develop a new software architecture that can support the functional requirements of multiple MCUs, enable efficient hardware adaptation, shorten development cycles, and improve system compatibility and scalability. This need has prompted in-depth research and development of the TBOX test software architecture to achieve a more efficient and flexible production test solution.

[0038] Figure 1The diagram shows a production system topology diagram provided by an embodiment of the present invention, illustrating the key roles and workflows of the TBOX device within the production system. The TBOX supports a multi-module and multi-peripheral hardware architecture designed to meet the needs of diverse application platforms and ensure flexible adaptability. The diagram shows multiple platforms (Platform A, ..., Platform N, etc.), representing different application environments or usage scenarios. The TBOX is capable of bidirectional data exchange with these different platforms, ensuring its adaptability and optimization based on the specific needs of each platform. The TBOX, located at the center of the diagram, is the core of the entire system, integrating multiple modules and peripherals. This design enables the TBOX to quickly respond to production needs and support diverse combinations, thereby improving production efficiency and applicability. The interaction between the TBOX and the industrial computer is crucial during the production process. The industrial computer is responsible for managing, monitoring, and configuring the TBOX, ensuring its proper operation according to pre-defined parameters and requirements. Finally, the TBOX communicates and controls data with the production system through the industrial computer, ensuring a coordinated and efficient production process. The production system is responsible for final product testing, quality control, and data logging to ensure that products meet standards. It can be seen that TBOX equipment, through collaboration with various platforms, industrial computers and production systems, has formed an efficient and flexible production adaptation system that can meet various combinations and quickly adapt to production.

[0039] Figure 2 The following is a block diagram of the EOL module system provided by an embodiment of the present invention. This block diagram illustrates the physical composition of the TBOX and the design concept of its multi-module and multi-peripheral architecture. This design allows the TBOX to be flexibly combined and expanded according to different needs, thus meeting diverse application scenarios. The center of the block diagram shows the TBOX device, the core of the entire system. By connecting multiple peripherals and modules, the TBOX forms a feature-rich system. Each peripheral and module can contain multiple functional modules, making the TBOX highly flexible and adaptable. As can be seen, 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, allowing for rapid response to market changes and technological advancements. This design not only increases the device's usability but also reduces the cost of subsequent maintenance and upgrades.

[0040] Based on this, the embodiment of the present invention provides a TBOX test software architecture, such as Figure 3 As shown in Figure 1, the architecture consists of four layers: communication layer, function adaptation layer, software adaptation layer, and hardware layer.

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

[0042] The hardware layer, the foundation of the entire TBOX system architecture, lies at the bottom layer and is primarily responsible for providing physical equipment and basic hardware support. The hardware layer provides the necessary hardware infrastructure for TBOX, including processors, memory, and interface modules. These hardware components provide the necessary environment and resources for the operation of upper-layer software. The hardware layer also enables flexible selection and configuration of appropriate device components based on the different models and functions of TBOX devices, enabling TBOX to adapt to various application scenarios and meet diverse user needs.

[0043] Device components are an important part of the hardware layer, including modules and peripherals, which each undertakes 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 them based on their specific needs, thereby achieving customized functionality.

[0045] Peripherals refer to various peripheral devices connected to the TBOX, such as displays, input devices, and storage devices. Peripherals are typically used to interact with the user or expand the functionality of the TBOX. Users can select appropriate peripherals and combine them according to their needs to enhance the overall functionality of the system.

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

[0047] The software adaptation layer, located above the hardware layer, is primarily responsible for adapting and managing device components within the hardware layer. Through drivers and middleware, the software adaptation layer interacts with underlying device components (modules and peripherals), ensuring they function properly and achieve their intended functions. It also monitors device status and performance and performs necessary resource allocation and scheduling. The software adaptation layer provides an abstract interface, enabling upper-layer applications to access and control different device components in a unified manner. This abstraction frees applications from the specific implementation details of the underlying hardware, improving development efficiency and system flexibility. The software adaptation layer also adapts to a wide variety of hardware models and brands, enhancing the compatibility of the TBOX system. By adapting to different hardware, TBOX can be flexibly configured to meet user needs.

[0048] Device function modules (devices) primarily implement specific functions related to hardware components. Each device function module corresponds to a specific hardware component and is responsible for implementing that component's functionality. 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 function modules adopt a modular design concept, allowing users to select, add, or replace specific function modules based on the actual needs of the device components. Device function modules also provide standardized interfaces, allowing upper-layer applications to easily call and use these functions. As can be seen, the software adaptation layer can support the hardware requirements of different TBOX types 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 test software architecture to adapt to changing requirements, easily integrate and manage new device components, and achieve efficient utilization of hardware resources and functional expansion.

[0049] The function adaptation layer is located above the software adaptation layer. It 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, realize the function adaptation of TBOX devices on different device components, and provide the function configuration units required by TBOX devices on device components.

[0050] The function configuration unit is a crucial component of the function adaptation layer, primarily responsible for specific function configuration and management. It provides the required functional configuration for each device component, employing a modular design that allows independent configuration of different functions. This structure allows users to flexibly select and configure functions based on their specific needs.

[0051] The function adaptation layer, located above the software adaptation layer, adapts the functionality of various device components based on the software configuration requirements of different TBOX devices to meet differentiated usage requirements. Specifically, each TBOX product has its own unique requirements. By breaking down these requirements, the specific functions that each device functional module must support on that TBOX device can be identified. During this process, the function adaptation layer analyzes the potential functionality of each device functional module. For example, if a device functional module has ten functions, but a specific TBOX device only requires five, the function adaptation layer will focus on adapting these five functions. In this case, unselected functions will not be activated, ensuring efficient system operation. Furthermore, if the identified requirements for certain functions are not yet supported by the current device functional module, the function adaptation layer will develop the corresponding code to implement these functions. Existing functions can be directly reused. The function adaptation layer also allows for the adjustment and adaptation of unneeded functions or the implementation of differentiated requirements through configuration files, providing a flexible solution to ensure smooth functional adaptation across different TBOX device components.

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

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

[0054] The host computer refers to a computer or system outside the TBOX that is typically used to monitor, manage, and control TBOX functions. The host computer connects to the TBOX via the communication layer and can collect and analyze data, send operational instructions, and provide users with a convenient management interface and functional control.

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

[0056] Upper-layer applications refer to specific applications or functional modules built based on 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 instructions.

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

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

[0059] The Ethernet component supports Ethernet-based communications. As a common network communication technology, Ethernet offers high bandwidth and a wide range of applications. The Ethernet component provides connectivity to external networks, enabling TBOX to exchange data with other devices via the Internet or a local area network, enabling functional testing and remote management.

[0060] The communication layer supports the implementation of upper-layer applications through efficient data exchange with the host computer and external devices. Its internal CAN and Ethernet components are adapted to different communication scenarios, ensuring that the system can flexibly respond to diverse communication needs.

[0061] The present invention provides a TBOX test software architecture, which 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 and manage the device components in the hardware layer and provide device function modules corresponding to the device components; the function 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 to achieve 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 function adaptation layer and is used to exchange data with the host computer and external devices and provide relevant protocols and interfaces to support the functional implementation of upper-layer applications. The present invention adopts an architecture design that can adapt to multiple modules and external devices and has flexible configuration capabilities, supports the functional requirements of multiple main control units, thereby achieving efficient hardware adaptation, and thus facilitating rapid and effective functional testing of TBOX.

[0062] Based on the various components and functions of the above-mentioned TBOX test software architecture, an embodiment of the present invention also provides a configuration method to achieve flexible function configuration and efficient data interaction based on the architecture. Through this configuration method, customized settings can be made for each device function module in the software adaptation layer, and multiple communication methods of interaction with the host computer and external devices can be achieved through 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 test software architecture. Figure 4 As shown, a flowchart of an implementation of a configuration method provided by an embodiment of the present invention is provided. The configuration method may include:

[0063] S400 : For each device function module of the software adaptation layer, enable different device function modules through software configuration, so that the device function modules realize corresponding functions.

[0064] In the software adaptation layer, each device function module can be flexibly configured according to actual needs. By configuring different enable options in the software, specific device function modules can be selectively activated or disabled, so that the activated device function modules can perform the corresponding functions, thus meeting the testing requirements of different TBOXs.

[0065] In the software adaptation layer, configuration files allow the flexibly managed enablement status of each device's functional modules to achieve the desired functionality. 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 require both. Some devices may only need to support one or both functions. In such cases, the configuration file will ensure that only the necessary functions are enabled based on the TBOX's actual functional requirements. Furthermore, considering that different TBOXes may use different WiFi module models, while 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 of these functions, making it impossible to configure the other.

[0066] Optionally, the embodiment of the present invention may also perform abstract adaptation on 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 as a hotspot and the other as a wireless network, the host computer needs to use predefined protocols to identify and operate the different modules. For example, you can set protocol A to control the first WiFi module and protocol B to control the second WiFi module. This means that no matter how many WiFi modules are connected to the TBOX, they can adapt flexibly and correctly control their functions.

[0068] S410. Abstract different communication modes through the communication layer, allowing multiple communication modes to be used simultaneously to interact with the host computer to adapt to different communication scenarios, wherein the communication modes 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 requirements. Specifically, the communication methods can include CAN communication and Ethernet communication. For example, in some TBOXes, CAN communication may be used to transmit vehicle status data in real time, while Ethernet communication can be used to transmit larger amounts of data, such as video streams or remote control commands. By abstracting different communication methods in the communication layer, the embodiments of the present invention support multiple communication methods for interaction with the host computer, 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. Whether the TBOX uses CAN communication, Ethernet communication, or both communication methods simultaneously, it can meet the corresponding testing requirements.

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

[0071] In an embodiment of the present invention, the data content sent by the host computer is subjected to protocol parsing to ensure that the data is correctly understood and processed. Specifically, the protocol parsing process interprets the information sent by the host computer into instructions or data that can be understood by the system. The parsed results are distributed to each device function module, which is responsible for the corresponding functional processing. Based on the parsing results, each device function module requests the current device status from the device component it manages. 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 will then feedback the results of its own status, such as the current temperature value or functional operation status, to the corresponding device function module based on its own functional status. Ultimately, the device function module will summarize all collected device status results and feedback this information to the host computer.

[0072] To facilitate understanding of the complete configuration process provided by the embodiments of the present invention, let's use an example. Assume a TBOX contains two Wi-Fi modules: Module A supports both STA (client) and AP (hotspot) modes, while Module B supports only STA mode. Although both modules have low-power capabilities, for current requirements, Module A only needs to operate in AP mode with its low-power feature enabled, while Module B operates in STA mode but does not require low-power. To support and verify the functionality of both Wi-Fi modules simultaneously, the following steps are required: First, the hardware must ensure connectivity and functionality for both Wi-Fi modules. Next, in the software adaptation layer, the STA and AP functions of Module A must be developed (although STA mode may have already been developed in other projects and can be omitted here). Module B must also implement STA functionality and the low-power characteristics of both chips. Subsequently, in the function adaptation layer, both Wi-Fi modules must be configured simultaneously, explicitly instructing Module A to operate only in AP mode and Module B to operate in STA mode. Module A's low-power feature must be enabled, while Module B's must be disabled. At this point, the communication protocols supported by each module must also be configured. During the host computer's testing process, different protocols are used to control the use of Wi-Fi modules. When module A needs to be turned on, 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, the function adaptation layer must consider scenarios where multiple master controllers are connected to the same Wi-Fi module. In this case, the master controller serial number configuration is required, and the protocol index is calculated using the protocol. This allows the TBOX test software architecture to effectively adapt to the needs of multiple master controllers and various module types, ensuring smooth inter-module collaboration and information flow.

[0073] This embodiment of the present invention implements corresponding device functions by configuring different functional modules in the software adaptation layer. Furthermore, the abstraction of the communication layer enables the TBOX test software architecture to flexibly support multiple communication methods (such as CAN and Ethernet) to adapt to different communication scenarios. Furthermore, data sent by the host computer is parsed through the protocol and accurately distributed to each device functional module. These modules then request status from the corresponding device components and feed the received device status results back to the host computer. This efficient hardware adaptation approach not only enables rapid response to diverse functional requirements but also significantly improves the efficiency of TBOX functional testing.

[0074] Optional, in the above Figure 4 On the basis of one or more corresponding embodiments, another optional embodiment provided by the embodiment of the present invention may further include:

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

[0076] Adaptation selection refers to selecting the most suitable functional modules for the current TBOX from existing equipment functional modules based on actual application scenarios and equipment requirements. This process allows users to quickly adjust the combination of functional modules according to different project requirements, ensuring that the TBOX test software architecture can effectively support the required functions.

[0077] Compilation and adaptation refers to compiling the selected functional modules based on the selection and adaptation to generate the final software suitable for the specific TBOX device. This process ensures that the selected functional modules can run efficiently on the target hardware, and also allows for targeted optimization to meet the performance requirements of different device components.

[0078] Specifically, embodiments of the present invention can adapt configuration files in the corresponding API format to device function modules. The configuration files are used to select, adapt, and compile device function modules in the software adaptation layer to meet the differentiated requirements of different TBOX devices for various modules and peripherals. Configuration files are extremely flexible and easy to use, supporting the multi-body architecture of 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, only the configuration needs to be adjusted to ql_api_v3. This mechanism ensures expanded 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] The embodiments of this invention, through a configuration file-driven adaptation mechanism, can quickly respond to the differentiated requirements of different TBOX devices, thereby enabling personalized customization, reducing development and maintenance complexity, and improving the flexibility and scalability of the TBOX test software architecture. This approach not only saves development time but also enhances the software's adaptability, making the functional implementation of different TBOX devices more precise and efficient.

[0080] Optional, in the above Figure 4 On the basis of one or more corresponding embodiments, another optional embodiment provided by the embodiment of the present invention may further include:

[0081] The module enabling configuration is performed on each device function module in the software adaptation layer, so as to adapt the differentiated detection functions of different TBOX devices through differentiated enabling configuration, and realize the use of different device components by each TBOX device.

[0082] The present invention implements module enablement configuration for each device function module in the software adaptation layer to adapt to the specific detection functions of different TBOX devices through differentiated enablement settings. This process allows for the selective enabling or disabling of certain device function modules based on the specific needs of each TBOX device, thereby achieving optimal device performance and accurate function 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 functional modules based on the required functions to support specific detection tasks, that is, flexibly enable or disable specific functional modules according to the needs of different TBOX devices. For example, for the GNSS (Global Navigation Satellite System) function, if a TBOX device supports GNSS, it is set to enabled in the configuration; if the device does not support GNSS, it is set to disabled. Through this differentiated enabling configuration, the specific detection requirements of each TBOX device can be effectively adapted, ensuring that they can fully utilize their respective device components.

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

[0085] Optional, in the above Figure 4On the basis of one or more corresponding embodiments, another optional embodiment provided by the embodiment of the present invention may further include:

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

[0087] Differentiated functional configuration allows for flexible configuration of each device functional module in the software adaptation layer to adapt to the specific functional requirements of different TBOX devices. This configuration aims to enable the same device functional module to be adjusted according to the requirements of different products, thereby achieving diversified functional adaptation.

[0088] Specifically, different TBOX devices may differ in hardware components, application scenarios, and business requirements. Through differentiated functional configuration, users can selectively enable or disable certain functions or adjust the parameters of the functions according to the characteristics of each device to achieve the best adaptation effect. For example, for two different WiFi modules, although they are of the same type, different accounts and passwords are required when connecting to the WiFi network. In one TBOX device, the SSID of the WiFi module may be set to "TBOX" and the password to "TBOX1234"; in another device, these settings may need to be changed to different SSIDs and passwords. Through such configuration, differentiated functional configuration ensures that the same module can flexibly respond 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 functional configuration, so that each TBOX device can more effectively utilize its hardware resources.

[0090] Although the operations are depicted in a particular order, this should not be understood as requiring that the operations be performed in the particular order shown or in a sequential order.Multitasking and parallel processing may be advantageous under certain circumstances.

[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. In addition, 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] An embodiment of the present invention provides a computer-readable storage medium having a program stored thereon, which implements the configuration method when executed by a processor.

[0093] An embodiment of the present invention provides a processor, which is used to run a program, wherein the configuration method is executed when the program is running.

[0094] An embodiment of the present invention provides an electronic device comprising at least one processor, at least one memory device connected to the processor, and a bus. The processor and the memory device communicate with each other via the bus. The processor is configured to invoke program instructions stored in the memory device to execute the configuration method described above. The electronic device herein may be a server, a PC, a PAD, a mobile phone, or the like.

[0095] The present invention also provides a computer program product, which, when executed on an electronic device, is adapted to execute a program initializing the configuration method steps.

[0096] The present invention is described with reference to the flowcharts and / or block diagrams of the TBOX test software architecture, configuration method, apparatus, electronic device (system), and computer program product according to embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable device to produce a machine, so that the instructions executed by the processor of the computer or other programmable device generate instructions for implementing the process in the flowchart and / or block diagram. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

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

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

[0099] Computer-readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. The information can be computer-readable instructions, data structures, program modules 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 technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory media such as modulated data signals and carrier waves.

[0100] In the description of the present invention, it should be understood that if the terms "up", "down", "front", "back", "left" and "right" are used to indicate directions or positional relationships, they are based on the directions or positional relationships shown in the accompanying drawings. They are only used to facilitate the description of the present invention and simplify the description, and do not indicate or imply that the positions or elements referred to must have a specific direction, be constructed and operate in a specific direction. Therefore, they should not be understood as limitations of the present invention.

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

[0102] Those skilled in the art will appreciate that embodiments of the present invention may be provided as methods, systems, or computer program products. Thus, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROMs, 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 present invention. It will be apparent to those skilled in the art that various modifications and variations of the present invention are possible. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention are intended to be within the scope of the present invention.

Claims

1. A TBOX test software architecture, characterized in that: The architecture includes: communication layer, function adaptation layer, software adaptation layer and 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 and manage device components in the hardware layer and provide device function modules corresponding to the device components; The function 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, to achieve function adaptation of the TBOX device on different device components, and to provide the function configuration units required by the TBOX device on the device components; The communication layer is located above the function adaptation layer, and is used for data interaction with the host computer and external devices, and provides relevant protocols and interfaces to support the function implementation of upper-layer applications.

2. The architecture according to claim 1, wherein: The communication layer includes CAN components and Ethernet components set 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 TBOX test software architecture applied to any one of claims 1 to 3, wherein the method comprises: For each device function module of the software adaptation layer, different device function modules are enabled through software configuration so that the device function modules realize corresponding functions; By abstracting different communication modes through the communication layer, it is allowed to use multiple communication modes to interact with the host computer at the same time to adapt to different communication scenarios, wherein the communication modes include CAN communication and / or Ethernet communication; The data content sent by the host computer is subjected to protocol parsing, and the parsing results are distributed to each device function module. Each device function module processes the corresponding protocol and requests the device status result of the corresponding device component. Each device component feeds back the device status result related to its own functional status to the corresponding device function module, and the device function module feeds back the acquired device status result to the host computer.

5. The method according to claim 4, characterized in that Also includes: The same functions of different device function modules are abstractly adapted to reuse the functions of the software, wherein the software matches each function item through the 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 and adapted and compiled through configuration files to meet the differentiated requirements of different TBOX devices for different device components.

7. The method according to claim 4, characterized in that Also includes: Module enabling configuration is performed on each device function module in the software adaptation layer, so as to adapt the differentiated detection functions of different TBOX devices through differentiated enabling configuration, thereby enabling each TBOX device to use different device components.

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

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

10. An electronic device, characterized in that: The electronic device includes at least one processor, and at least one memory and a bus connected to the processor; 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