Movement application adaptation system and digital signage device

Abstract

The application discloses a core application adaptation system and a digital signage device, and relates to the technical field of commercial display, wherein the core application adaptation system comprises: an application management module connected with a middleware module, used for running a digital signage application and transmitting an application calling request corresponding to the digital signage application to the middleware module; the middleware module is connected with the application management module and a core module respectively, used for receiving the application calling request and transmitting a middleware instruction corresponding to the application calling request to the core module; and the core module is connected with the middleware module, used for receiving the middleware instruction and driving the core according to the middleware instruction. By introducing the middleware module, the application and the underlying core are decoupled, so that the application management module does not need to directly interact with the core module, but carries out standardized request conversion and instruction transmission through the middleware module, thereby effectively improving the efficiency and reliability of core replacement or addition of the digital signage product.

Description

Technical Field

[0001] This application relates to the field of display technology, and in particular to a mechanism application adaptation system and a digital signage device. Background Technology

[0002] Currently, to meet diverse market demands, the commercial display equipment industry widely adopts chassis solutions based on different hardware architectures and interface specifications. Against this backdrop, digital signage application software needs to be compatible with a variety of different underlying chassis hardware.

[0003] However, the current development model typically employs a direct coupling between digital signage application software and specific hardware modules. This tightly coupled architecture results in a deep bond between the application software and the hardware. When equipment manufacturers need to introduce a new module to improve performance or reduce costs, developers must perform extensive and tedious modifications and adaptations to the source code of the upper-layer digital signage application software because the underlying interfaces of the new module differ from those of the original module. This process not only significantly extends the development and testing cycle of digital signage products and increases labor costs, but also introduces additional stability and compatibility risks due to directly modifying mature applications. Utility Model Content

[0004] The main purpose of this application is to propose a movement application adaptation system and digital signage device, which addresses the technical problem that currently requires extensive modifications and re-adaptations to upper-layer applications when replacing or adding movements.

[0005] To achieve the above objectives, this application proposes a movement application adaptation system, which includes: An application management module, which is connected to the middleware module, is used to run the digital signage application and transmit the application call request corresponding to the digital signage application to the middleware module. The middleware module is connected to both the application management module and the core module, and is used to receive the application call request and transmit the middleware instruction corresponding to the application call request to the core module. The movement module is connected to the middleware module and is used to receive the middleware instructions and drive the movement according to the middleware instructions.

[0006] This application also proposes a digital signage device, which includes a device housing, a display module, and the aforementioned mechanism application adaptation system. Attached Figure Description

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

[0008] Figure 1 A schematic diagram of the structure of an embodiment of the movement application adaptation system provided in this application; Figure 2 A schematic diagram of another embodiment of the movement application adaptation system provided in this application; Figure 3 A schematic diagram of the middleware service unit in the movement application adaptation system provided in this application; Figure 4 A schematic diagram of the main circuit board in the movement application adaptation system provided in this application; Figure 5 A schematic diagram of another embodiment of the movement application adaptation system provided in this application; Figure 6 A schematic diagram of another embodiment of the movement application adaptation system provided in this application.

[0009] Explanation of icon numbers:

[0010] The realization of the purpose, functional features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0011] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0012] It should be noted that if the embodiments of this application involve directional indicators (such as up, down, left, right, front, back, etc.), the directional indicators are only used to explain the relative positional relationship and movement of the components in a specific posture. If the specific posture changes, the directional indicators will also change accordingly.

[0013] Furthermore, if the embodiments of this application involve descriptions such as "first" or "second," these descriptions are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined with "first" or "second" may explicitly or implicitly include at least one of those features. Additionally, the use of "and / or" or "and / or" throughout the text includes three parallel solutions. For example, "A and / or B" includes solution A, solution B, or a solution that simultaneously satisfies A and B. Furthermore, the technical solutions of the various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. When the combination of technical solutions is contradictory or impossible to implement, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed in this application.

[0014] Currently, the development model typically employs a direct coupling between digital signage application software and specific hardware modules. This tightly coupled architecture results in a deep bond between the application software and the hardware. When equipment manufacturers need to introduce a new module to improve performance or reduce costs, developers must perform extensive and tedious modifications and adaptations to the source code of the upper-layer digital signage application software because the underlying interfaces of the new module differ from those of the original module. This process not only significantly extends the development and testing cycle of digital signage products and increases labor costs, but also introduces additional stability and compatibility risks due to directly modifying mature applications.

[0015] Based on this, this application proposes a mechanism application adaptation system, which includes: an application management module connected to a middleware module for running digital signage applications and transmitting application call requests corresponding to the digital signage applications to the middleware module; a middleware module connected to both the application management module and the mechanism module for receiving application call requests and transmitting middleware instructions corresponding to the application call requests to the mechanism module; and a mechanism module connected to the middleware module for receiving middleware instructions and driving the mechanism according to the middleware instructions.

[0016] The technical solution of this application decouples the digital signage application from the underlying mechanism hardware by introducing a middleware module between the application management module and the mechanism module. This connection allows the application management module to interact with the mechanism module directly without direct interaction. Instead, the middleware module handles standardized request conversion and instruction transmission. When a new mechanism is introduced, the middleware module only needs to adapt to the interface of the new mechanism, while the digital signage application running in the application management module does not require any modification. This directly solves the problems of long software development cycles, high costs, and high stability and compatibility risks caused by the strong coupling between application software and mechanism hardware. The improved connection between modules effectively enhances the efficiency and reliability of replacing or adding mechanisms in digital signage products.

[0017] This application proposes a movement application adaptation system.

[0018] Please see Figure 1 In one embodiment of this application, the movement application adapter system includes: Application management module 10 is connected to middleware module 20 and is used to run digital signage application and transmit application call requests corresponding to digital signage application to middleware module 20. The middleware module 20 is connected to the application management module 10 and the core module 30 respectively. It is used to receive application call requests and transmit the middleware instructions corresponding to the application call requests to the core module 30. The movement module 30 is connected to the middleware module 20 and is used to receive middleware instructions and drive the movement according to the middleware instructions.

[0019] It should be noted that the application management module 10 can be a control chip integrated on the main circuit board of the digital signage device. This chip establishes an electrical connection with the middleware module 20 via the onboard PCIe bus or parallel data bus. The hardware circuit of this module is configured to run the functional logic of the digital signage application and generate corresponding application call request signals, which are transmitted to the middleware module 20 through the aforementioned PCIe bus or parallel data bus electrical link. Its physical connection structure ensures the isolation between the execution of the application function and the underlying hardware driver. The application call request is an electrical signal or data packet generated by the hardware circuit of the application management module 10, carrying the call information of the digital signage application to the underlying hardware services. This request is transmitted from the application management module 10 to the middleware module 20 through the aforementioned electrical link. This signal transmission process relies on the established electrical connection relationship between the two modules, realizing the application layer's access to hardware services.

[0020] The middleware module 20 is a dedicated integrated circuit or dedicated processing chip, such as an FPGA (Field Programmable Gate Array), located on the main circuit board of the digital signage device. It is electrically connected to the application management module 10 via the aforementioned electrical link and simultaneously electrically connected to the core module 30 via a second electrical link. The internal hardware logic of this module is designed to receive application call request signals from the application management module 10, convert these requests into standardized middleware instruction signals, and forward them via the second electrical link. Its core function is to achieve signal conversion and module decoupling through the physical interface connection. The middleware instruction is a control signal or data packet generated by the middleware module 20 based on the application call request, and its format matches the driving requirements of the core module 30. This instruction is transmitted through the physical data channel formed by the second electrical link connecting the middleware module 20 and the core module 30. This hardware-based signal interaction mechanism enables standardized drive control of the core module 30.

[0021] The mechanism module 30 is a pluggable component with specific hardware functions in the digital signage device. It can be electrically connected to the main circuit board of the device through a mechanism plug-in interface, or soldered onto the main circuit board through a board-to-board connector or a stamp hole package, thereby establishing a second electrical link with the middleware module 20. The hardware circuit of this module is responsible for receiving middleware command signals transmitted through the physical interface and directly executing the corresponding mechanism drive operations. Its characteristic as an independent hardware component means that when the mechanism is replaced, only the compatibility of the physical interface needs to be ensured.

[0022] Understandably, the direct coupling between digital signage applications and the underlying hardware can lead to significant application modifications when replacing the hardware. Therefore, this embodiment employs a technical solution consisting of an application management module 10, a middleware module 20, and a hardware module 30 electrically connected in sequence. This establishes a standardized signal conversion and transmission path at the hardware level. The middleware module 20 converts application call requests and generates middleware instructions, avoiding the need for the application management module 10 to directly adapt to the underlying driver interfaces of different hardware modules 30. This decouples the digital signage application from the underlying hardware, ensuring that when replacing or adding a hardware module 30, only the compatibility of the physical interface between the middleware module 20 and the hardware module 30 needs to be ensured, while the upper-level application management module 10 and its functions remain unchanged. Ultimately, this achieves the effects of shortening the development cycle, reducing labor costs, and improving system compatibility and reliability.

[0023] For example, on the main circuit board of the digital signage device, the application management module 10 can be specifically implemented as a control chip equipped with dedicated logic circuitry. This control chip establishes an electrical connection with the middleware module 20 through the first set of printed circuit lines on the board. The middleware module 20 can be specifically implemented as a dedicated integrated circuit that integrates signal conversion logic. In addition to receiving application call request signals from the main controller through the first set of printed circuit lines, this integrated circuit is also electrically connected to a standardized mechanism slot through the second set of printed circuit lines. The mechanism module 30 can be specifically implemented as an independent functional board that can be inserted into the aforementioned mechanism slot. It completes electrical interconnection with the dedicated integrated circuit of the middleware module 20 through the metal pins of the slot, thereby receiving middleware instruction signals and driving the display driver circuit and media decoding circuit on it to work.

[0024] The technical solution of this application decouples the digital signage application from the underlying mechanism hardware by introducing a middleware module 20 between the application management module 10 and the mechanism module 30. This connection allows the application management module 10 to interact directly with the mechanism module 30, instead using the middleware module 20 for standardized request conversion and instruction transmission. When a new mechanism is introduced, the middleware module 20 only needs to adapt to the interface of the new mechanism, while the digital signage application running in the application management module 10 does not require any modification. This directly solves the problems of long software development cycles, high costs, and high stability and compatibility risks caused by the strong coupling between application software and mechanism hardware. The improved connection between modules effectively enhances the efficiency and reliability of replacing or adding mechanisms in digital signage products.

[0025] In one feasible implementation, please refer to Figure 2 Middleware module 20 includes: Application interface unit 21 is connected to application management module 10 and middleware service unit 22 respectively, and is used to receive application call requests and transmit application call requests to middleware service unit 22. Middleware service unit 22 is connected to application interface unit 21 and mechanism interface unit 23 respectively, and is used to receive application call requests and transmit middleware instructions to mechanism interface unit 23. The mechanism interface unit 23 is connected to the middleware service unit 22 and the mechanism module 30 respectively, and is used to receive middleware instructions and transmit middleware instructions to the mechanism module 30.

[0026] It should be noted that the application interface unit 21 is a dedicated hardware circuit in the middleware module 20 that is electrically connected to the application management module 10 via a first electrical link. It is configured to receive application call request signals from the application management module 10 via the electrical link and transmit the signals to the middleware service unit 22 via the printed circuits inside the unit. This unit serves as a dedicated hardware port for signal reception, and its physical connection structure establishes a fixed communication path between the application management module 10 and the middleware module 20.

[0027] The middleware service unit 22 is a core processing circuit integrated within the middleware module 20. It is electrically connected to the application interface unit 21 and the mechanism interface unit 23 via printed circuits within the unit. This unit contains necessary logic circuits and storage units, and is configured to receive and process signals from the application interface unit 21, and generate corresponding control signals that are transmitted to the mechanism interface unit 23 via internal circuitry. Its hardware structure is the core of signal conversion and routing.

[0028] The mechanism interface unit 23 is a dedicated hardware circuit within the middleware module 20 that is electrically connected to the mechanism module 30 via a second electrical link. It is connected to the middleware service unit 22 via internal printed circuitry, and is used to receive control signals generated by the middleware service unit 22 and transmit these signals as middleware instructions to the mechanism module 30 via the second electrical link. This unit serves as a dedicated hardware port for signal transmission, and its physical connection structure establishes a standardized driver interface between the middleware module 20 and the mechanism module 30. It is understandable that if the middleware module 20 lacks a standardized signal processing path, it may still lead to risks of internal coupling and inconsistent interfaces. Therefore, this embodiment divides the middleware module 20 into a hardware scheme that is sequentially connected by an application interface unit 21, a middleware service unit 22, and a mechanism interface unit 23 via internal electrical links. This forms a clear three-level physical signal path of "receive-process-forward" within the middleware module 20. The application interface unit 21 is responsible for receiving signals from the application management module 10, the middleware service unit 22 is responsible for core signal conversion, and the mechanism interface unit 23 ensures signal driving with the mechanism module 30. This avoids the problems of poor scalability and maintenance difficulties caused by mixed functions and unclear signal flow within the middleware module 20. It realizes hardware-level division of labor and isolation of tasks within the middleware module 20, improves signal processing efficiency and system stability, and provides a standardized internal hardware foundation for rapid adaptation of different models of mechanism modules 30.

[0029] For example, on the main circuit board of the digital signage device, the middleware module 20 can be implemented as a set of dedicated hardware circuits working together. The application interface unit 21 can be a signal receiving chip connected to the main controller of the application management module 10 through the first set of printed circuits, which is specifically responsible for receiving electrical signals of application call requests. The middleware service unit 22 can be a dedicated processor with an integrated logic processing core and static memory. The middleware service unit 22 is electrically connected to the application interface unit 21 and the mechanism interface unit 23 through the internal data bus on the motherboard, and is responsible for parsing and converting the received signals. The mechanism interface unit 23 can be a drive circuit chip connected to the mechanism slot through the second set of printed circuits, which is specifically responsible for converting the control signals processed by the middleware service unit 22 into electrical instructions that meet the driving requirements of the mechanism module 30. These three functional units form a complete hardware signal processing chain through predetermined wiring on the main circuit board.

[0030] In the specific implementation process, further references Figure 2 The application interface unit 21 is connected to the application management module 10 through the first cross-process channel C1, and the mechanism interface unit 23 is connected to the mechanism module 30 through the second cross-process channel C2.

[0031] The first cross-process channel C1 is a physical data communication link connecting the application interface unit 21 and the application management module 10. It is electrically connected through the first set of printed lines or a dedicated data bus on the main circuit board of the digital signage device. This channel is configured to transmit application call request signals at the hardware level, ensuring stable signal interaction between the application interface unit 21 and the application management module 10 without relying on the communication mechanism between software processes.

[0032] The second cross-process channel C2 is a physical data communication link connecting the mechanism interface unit 23 and the mechanism module 30. It is electrically connected through the metal pins of the mechanism plug-in interface or the second set of printed circuits. This channel is configured to transmit middleware instruction signals at the hardware level. It establishes a standardized drive signal transmission path between the mechanism interface unit 23 and the mechanism module 30, thereby ensuring the reliability and compatibility of the mechanism drive.

[0033] Understandably, even with functional separation within a module, the lack of an independent and stable physical signal channel between the unit and external modules still poses risks of signal interference and coupling dependencies. Therefore, by establishing a dedicated first cross-process channel C1 connecting the application interface unit 21 and the application management module 10, and a dedicated second cross-process channel C2 connecting the mechanism interface unit 23 and the mechanism module 30, dedicated physical data communication links are constructed for critical signal interaction paths. This solution, by configuring an independent physical channel for each critical interface, avoids signal integrity damage, mutual interference, and coupling failures caused by shared communication resources when different functional units interact with external modules. It achieves stable and non-interfering electrical isolation between the three core functions of application management, middleware processing, and mechanism driving, significantly improving the reliability and anti-interference capability of the system's modules working collaboratively.

[0034] Alternatively, in one implementation, please refer to Figure 3 The middleware service unit 22 is equipped with a memory 221, which is used to store hardware interface configuration information corresponding to at least one mechanism in the mechanism module 30. The mechanism interface unit 23 is connected to the memory 221, and the second cross-process channel C2 is established by the mechanism interface unit 23 according to the hardware interface configuration information.

[0035] It should be noted that the hardware interface configuration information is a set of fixed data or electrical parameters pre-stored in the memory 221 of the middleware service unit 22. It defines the physical interface specifications required for electrical interaction with a specific movement module 30, and may include, but is not limited to, hardware driver parameters such as signal timing, voltage levels, pin definitions, and communication protocols. This configuration information is transmitted to the movement interface unit 23 via the internal data bus, guiding it to establish a second cross-process channel C2 that matches the target movement module 30, thereby achieving standardized hardware adaptation between the movement interface unit 23 and different movement models within the movement module 30.

[0036] Understandably, since fixed hardware connections alone are insufficient for flexibly adapting to various models of movement modules 30, and there is a limitation that requires manual reconfiguration of the hardware interface when the movement is replaced, this embodiment addresses this limitation by setting up a memory 221 within the middleware service unit 22 to pre-store the hardware interface configuration information corresponding to various movement modules 30, and transmitting the required configuration to the movement interface unit 23 via an internal data bus. This allows the movement interface unit 23 to dynamically establish a matching second cross-process channel C2 based on the configuration information. This solution, through the physical structure of hardware storage and data bus transmission of configuration parameters, avoids the problem of needing manual intervention or modification of hardware connections to re-establish the communication channel when replacing the movement module 30. It achieves automatic, accurate, and rapid establishment of physical communication channels between the movement interface unit 23 and different models of movement modules within the movement module 30, significantly improving the flexibility, efficiency, and system compatibility of movement adaptation.

[0037] For example, a memory 221 is integrated into the hardware circuit of the middleware service unit 22. This memory is electrically connected to the chassis interface unit 23 via an internal data bus. The memory stores hardware interface configuration information for different chassis models within the chassis module 30, which may include, but is not limited to, signal timing parameters, level standards, and pin definitions. When the system starts, the logic circuit of the middleware service unit 22 transmits the configuration data set corresponding to the specific chassis model to the configurable I / O (Input / Output) controller of the chassis interface unit 23 via the internal bus. The chassis interface unit 23 then automatically adjusts its output drive characteristics and signal protocol according to the received configuration parameters, thereby establishing a second cross-process channel that is fully matched with the target chassis module 30 at the physical level.

[0038] In the specific implementation process, please refer to Figure 4 The application interface unit 21, middleware service unit 22 and mechanism interface unit 23 are integrated in the same integrated circuit on the main circuit board 100 of the digital signage. The main circuit board 100 is also provided with a mechanism plug-in interface 101, and the mechanism module 30 is electrically connected to the main circuit board 100 through the mechanism plug-in interface 101.

[0039] The mechanism insertion interface 101 is a standardized physical connector located on the main circuit board 100 of the digital signage device. It includes multiple metal pins arranged in a predetermined layout. These pins are electrically connected to the mechanism interface unit 23 and the power management circuit of the middleware module 20 through printed lines on the main circuit board 100. The interface is configured to match and be inserted into the corresponding metal contacts on the edge of the mechanism module 30, thereby establishing a stable electrical connection and signal transmission physical channel between the mechanism module 30 and the main circuit board 100 while fixing the mechanical connection.

[0040] Understandably, the dispersed layout of modules and non-standardized connections can lead to low system integration, excessively long signal transmission paths, and unreliable mechanical connections. Therefore, by integrating the application interface unit 21, middleware service unit 22, and chassis interface unit 23 onto the same integrated circuit on the main circuit board 100, and by setting up a standardized chassis plug-in interface 101 for electrical connection with the chassis module 30, a highly integrated hardware structure is constructed. This solution ensures the mechanical stability and electrical continuity of external connections through standardized plug-in interfaces, avoiding problems such as signal attenuation, poor contact, and excessive assembly complexity caused by module separation and inconsistent connectors. It also improves internal transmission efficiency and enhances the plug-and-play convenience and reliability of the chassis module 30.

[0041] For example, the movement plug-in interface 101 is provided with a movement model identification pin. The middleware service unit 22 obtains the movement model of the corresponding movement in the movement module 30 through the model identification pin, and transmits the hardware interface configuration information corresponding to the movement model in the memory 221 to the movement interface unit 23. The hardware interface configuration information corresponding to the movement model is used to establish the second cross-process channel C2.

[0042] It should be noted that the movement model identification pin is one or more specific metal pins with predefined functions in the movement plug-in interface 101. These pins are electrically connected to the model identification circuit in the middleware service unit 22 through dedicated printed circuits on the main circuit board 100. Their electrical level state or encoded signal has a unique correspondence with different models of movement modules 30. When the movement module 30 is inserted into the plug-in interface, this pin transmits a characteristic electrical signal representing the identity of the movement module 30 to the middleware service unit 22 through its physical contact, thereby providing the system with a hardware means to automatically identify the specific model of the currently connected movement module 30.

[0043] Understandably, even with a unified physical interface, if the specific movement model cannot be automatically identified, the system still requires manual intervention for configuration, leading to low operational efficiency and the risk of configuration errors. Therefore, this implementation also establishes a hardware-level automatic movement model identification mechanism by setting a dedicated movement model identification pin in the movement plug-in interface 101 and electrically connecting it to the middleware service unit 22 via a dedicated printed circuit. This solution enables the middleware service unit 22 to automatically retrieve the matching hardware interface configuration information from the memory 221 by identifying the movement characteristic electrical signals transmitted through the pin. This avoids the inefficiency and human error problems that may result from manual model identification and configuration loading when replacing the movement. It achieves automatic configuration identification and loading when the movement module 30 is plug-and-play, significantly improving the automation, accuracy, and overall system efficiency of the movement replacement operation.

[0044] As an example, two dedicated chassis model identification pins are provided in the pin array of the chassis plug-in interface 101. These two pins are electrically connected to the GPIO (General Purpose Input Output) detection circuit in the middleware service unit 22 via dedicated printed circuits on the main circuit board 100. Different chassis modules 30 have different pull-up resistor values ​​at their corresponding interface positions. When the module is inserted, a specific high and low level combination is formed on the identification pin. After the hardware detection circuit of the middleware service unit 22 reads the level combination, it queries the memory 221 through the internal data bus and automatically loads the complete hardware interface configuration information corresponding to the level code. Then, it controls the chassis interface unit 23 to establish a matching second cross-process channel C2, thereby realizing plug-and-play and automatic adaptation of the chassis hardware.

[0045] In one feasible implementation, please refer to Figure 5 The middleware module 20 also includes: Resource management unit 24 is connected to middleware service unit 22 via a monitoring bus. It is used to receive performance status data of mechanism module 30 from middleware service unit 22 and transmit resource scheduling signals to middleware service unit 22 according to the performance status data. The resource scheduling signals are used to schedule middleware service unit 22 to transmit middleware instructions to mechanism interface unit 23.

[0046] It should be noted that the resource management unit 24 is an independent hardware monitoring circuit or a dedicated monitoring chip, such as a microcontroller, integrated on the main circuit board. It is electrically connected to the middleware service unit 22 through the monitoring bus. The unit contains signal acquisition and logic judgment circuits and is configured to receive performance status data through the hardware link and generate resource scheduling control signals accordingly.

[0047] The monitoring bus is a dedicated physical data channel connecting the resource management unit 24 and the middleware service unit 22. It is electrically connected through specific printed circuits on the main circuit board. The bus is configured to transmit performance status data and resource scheduling signals at the hardware level, establishing a dedicated monitoring signal transmission path between the two units.

[0048] Performance status data is a set of electrical parameters characterizing the operating status of the mechanism module 30, including operating voltage, current signal or temperature sensor readings. These physical quantities are transmitted from the middleware service unit 22 to the resource management unit 24 through the electrical link of the monitoring bus, providing a basis for hardware resource scheduling.

[0049] The resource scheduling signal is a hardware control instruction generated by the resource management unit 24 based on the performance status data. This signal is transmitted to the middleware service unit 22 through the physical channel of the monitoring bus. Its electrical characteristics directly control the timing or priority of the instruction transmission from the middleware service unit 22 to the mechanism interface unit 23.

[0050] Understandably, since the system may experience performance bottlenecks or overheating risks due to load fluctuations in the core module 30 during continuous operation, and there is currently a lack of real-time monitoring and dynamic scheduling mechanisms at the hardware level, this embodiment adds a resource management unit 24 electrically connected to the middleware service unit 22 via a monitoring bus to construct an independent hardware monitoring and scheduling path. This allows the resource management unit 24 to obtain the performance status data of the core module 30 in real time through the physical link and generate resource scheduling signals to feed back to the middleware service unit 22. This hardware-level closed-loop control mechanism avoids problems such as performance degradation, resource conflicts, or overheating damage that may occur due to the system's inability to respond to changes in the core module's status in real time. It achieves proactive monitoring of the core module 30's operating status and intelligent scheduling of resource commands, effectively improving the system's operational stability, resource utilization efficiency, and hardware reliability.

[0051] For example, the resource management unit 24 can be an independent monitoring MCU (Microcontroller Unit) on the main circuit board. It is electrically connected to the processor chip of the middleware service unit 22 via an I2C monitoring bus. The ADC (Analog to Digital Converter) pin of this monitoring MCU continuously collects voltage signals from a temperature sensor on the heatsink of the chassis module 30 as performance status data via a dedicated sensor line. When the detected voltage value exceeds a preset threshold, its GPIO pin immediately sends a resource scheduling signal composed of a high-low level combination to the middleware service unit 22 via the same I2C monitoring bus. After receiving this signal, the middleware service unit 22's internal hardware logic circuit adjusts the timing frequency of commands sent through the chassis interface unit 23, thereby achieving overheat protection and performance scheduling of the chassis module 30 at the hardware level.

[0052] In one feasible implementation, please refer to Figure 6 The movement application adaptation system also includes: Interface testing module 40 is connected to the mechanism module 30 through a test channel. It is used to transmit test commands to the mechanism module 30 and receive response signals generated by the mechanism module 30 based on the test commands.

[0053] It should be noted that the interface test module 40 is a dedicated test hardware circuit or a CPLD (Complex Programmable Logic Device) integrated on the main circuit board of the digital signage, or an external test device. It is electrically connected to the mechanism module 30 through an independent test channel. This module is configured to actively send test commands to the mechanism module 30 during the system production or maintenance phase and detect the response signals returned by it, thereby completing the verification of the mechanism interface function at the hardware level.

[0054] The test command is a set of electrical signals or test excitation signals of a specific format generated by the hardware circuit of the interface test module 40. It is transmitted to the core module 30 through the physical link of the test channel to trigger the core module 30 to perform preset self-test or drive operations to verify the correctness and integrity of its interface function.

[0055] Understandably, even though the middleware module 20 achieves decoupling between the application and the movement, there is still a lack of hardware means to quickly and independently verify the interface functions of the movement module 30 during the production assembly or maintenance phase. This poses a risk of difficulty in overall system debugging and quality issues due to underlying hardware failures. Therefore, this embodiment adds an interface test module 40 that is directly electrically connected to the movement module 30 via a dedicated test channel. This module operates independently of the application management module 10 and the middleware module 20, enabling the interface test module 40 to directly send test commands to the movement module 30 and receive its response signals. This avoids the complex process of repeated disassembly and assembly and reliance on upper-layer applications for testing after system integration due to the inability to locate interface failures in the movement module 30 itself. This achieves independent, efficient, and accurate verification of the interface functions and electrical characteristics of the movement module 30, significantly improving the efficiency of production debugging and after-sales maintenance, as well as system reliability.

[0056] For example, the interface test module 40 is specifically implemented as an external hardware tester that is electrically connected to the mechanism module 30 through a standard test interface. The tester sends a boundary scan test command to the test access port of the mechanism module 30 through its dedicated test channel and simultaneously monitors the returned response signal data stream, thereby independently completing the online test of the connectivity and logic function of the interface circuit of the mechanism module 30 under normal operating conditions of the main circuit board.

[0057] In the specific implementation process, the interface test module 40 is integrated into the test chip on the main circuit board of the digital signage. The test chip forms a test channel with the mechanism module 30 through the printed circuit of the main circuit board.

[0058] Understandably, using external testing equipment or independent hardware modules still presents problems such as low system integration, susceptibility to signal integrity interference in the test path, and additional assembly costs. Therefore, this embodiment further integrates the interface testing module 40 directly into a dedicated testing chip on the main circuit board, and utilizes the printed circuit board's own traces to form a test channel with the mechanism module 30. This solution, through the fixed connection between the built-in testing chip and the printed circuit board, avoids the unstable contact resistance, signal noise interference, and additional connector costs caused by using external testing interfaces or flying wire connections. It achieves a high degree of integration between the test channel and the system motherboard, which not only significantly improves the reliability and consistency of test signal transmission, but also simplifies the overall hardware structure and reduces production costs and maintenance complexity.

[0059] For example, the interface test module 40 is a test chip soldered onto the main circuit board of the digital signage. This test chip is directly electrically connected to the test interface pins of the mechanism module 30 through an independent test channel formed by the printed circuit of the main circuit board. During testing, the internal logic circuit of the chip generates test command electrical signals with specific timings and transmits them to the mechanism module 30 through the test channel. At the same time, the response signal level returned by the mechanism module 30 is monitored through the same channel, thereby completing the hardware-level verification of the interface function of the mechanism module 30 without relying on the application management module 10 and the middleware module 20.

[0060] This application also proposes a digital signage device, which includes a device housing, a display module, and a core application adaptation system. The specific structure of the core application adaptation system is as described in the above embodiments. Since this digital signage device adopts all the technical solutions of all the above embodiments, it has at least all the beneficial effects brought about by the technical solutions of the above embodiments, which will not be described in detail here.

[0061] The above description is merely an exemplary embodiment of this application and does not limit the patent scope of this application. Any equivalent structural transformations made based on the technical concept of this application and the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included within the patent protection scope of this application.

Claims

1. A movement application adaptation system, characterized in that, The movement application adaptation system includes: An application management module, which is connected to the middleware module, is used to run the digital signage application and transmit the application call request corresponding to the digital signage application to the middleware module. The middleware module is connected to both the application management module and the core module, and is used to receive the application call request and transmit the middleware instruction corresponding to the application call request to the core module. The movement module is connected to the middleware module and is used to receive the middleware instructions and drive the movement according to the middleware instructions.

2. The movement application adaptation system as described in claim 1, characterized in that, The middleware module includes: An application interface unit is connected to the application management module and the middleware service unit respectively, and is used to receive the application call request and transmit the application call request to the middleware service unit. A middleware service unit, which is connected to the application interface unit and the core interface unit respectively, is used to receive the application call request and transmit the middleware instruction to the core interface unit. A mechanism interface unit is connected to both the middleware service unit and the mechanism module, and is used to receive middleware instructions and transmit the middleware instructions to the mechanism module.

3. The movement application adaptation system as described in claim 2, characterized in that, The application interface unit is connected to the application management module through a first cross-process channel, and the mechanism interface unit is connected to the mechanism module through a second cross-process channel.

4. The movement application adaptation system as described in claim 3, characterized in that, The middleware service unit is equipped with a memory, which is used to store hardware interface configuration information corresponding to at least one movement in the movement module. The mechanism interface unit is connected to the memory, and the second cross-process channel is established by the mechanism interface unit according to the hardware interface configuration information.

5. The movement application adaptation system as described in claim 4, characterized in that, The application interface unit, middleware service unit, and mechanism interface unit are integrated into the same integrated circuit on the main circuit board of the digital signage. The main circuit board is also provided with a mechanism plug-in interface, and the mechanism module is electrically connected to the main circuit board through the mechanism plug-in interface.

6. The movement application adaptation system as described in claim 5, characterized in that, The movement plug-in interface is provided with a movement model identification pin. The middleware service unit obtains the movement model of the corresponding movement in the movement module through the model identification pin, and transmits the hardware interface configuration information corresponding to the movement model in the memory to the movement interface unit.

7. The movement application adaptation system as described in claim 2, characterized in that, The middleware module also includes: A resource management unit, connected to the middleware service unit via a monitoring bus, is used to receive performance status data of the mechanism module from the middleware service unit and transmit resource scheduling signals to the middleware service unit based on the performance status data. The resource scheduling signals are used to schedule the middleware service unit to transmit the middleware instructions to the mechanism interface unit.

8. The movement application adaptation system as described in claim 1, characterized in that, The movement application adaptation system also includes: An interface testing module is connected to the movement module via a test channel. It is used to transmit test commands to the movement module and receive response signals generated by the movement module based on the test commands.

9. The movement application adaptation system as described in claim 8, characterized in that, The interface testing module is integrated into a test chip on the main circuit board of the digital signage. The test chip forms the test channel with the mechanism module through the printed circuit of the main circuit board.

10. A digital signage device, characterized in that, The digital signage device includes a device housing, a display module, and a mechanism application adaptation system as described in any one of claims 1 to 9.

Images