Self-service terminal hardware service driving method, system and equipment for realizing cross-platform self-adaption and medium

Abstract

The invention provides a self-service terminal hardware service driving method, system and device for achieving cross-platform self-adaption and a medium, and belongs to the technical field of hardware service driving. The method comprises the steps that a front-end application is received to generate a hardware service request; the service bus dynamically loads a corresponding hardware service plug-in from a plug-in library according to the target hardware identifier; the interface adaptation layer selects a protocol template according to the interface type, and injects an operation parameter into the selected protocol template to generate an intermediate instruction; the loaded hardware service plug-in converts the intermediate instruction into a platform-independent hardware instruction; the platform adaptation layer detects the type of a current operating system, and calls a corresponding bottom driver library to convert a platform irrelevant hardware instruction into an operating system level hardware instruction; and sending an operating system level hardware instruction to the physical hardware, packaging a return result into a uniform response format, and returning the return result to the front-end application. According to the invention, cross-platform adaptive hardware driving is realized, and compatibility, flexibility and maintenance efficiency are improved.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of hardware service driving, and particularly relates to a self-service terminal hardware service driving method and system realizing cross-platform adaptation, equipment and a medium. BACKGROUND

[0002] With the popularity of self-service terminals in the fields of government affairs, finance and medical treatment, the flexibility and compatibility of hardware driving become the key. The traditional hardware service driving scheme is usually based on a monolithic architecture design, which has the following defects: Firstly, the traditional hardware service driving scheme is usually closely combined with the kernel of a specific operating system, such as a Windows dedicated driving framework or a Linux customized scheme, which leads to the need for completely redeveloping the driving for cross-platform deployment, greatly increasing the adaptation cost and development cycle. Secondly, the traditional driving scheme only supports fixed interface protocols and cannot adapt to modern communication standards such as HTTP / RESTful and WebSocket. When the self-service terminal is connected with a third-party system (such as a cloud server or a mobile application), a customized gateway needs to be additionally developed, increasing the complexity and cost of system integration. In addition, the interface parameter definition is usually coded in the hardware driving layer, which leads to the need for recompiling and deploying the entire driving program when new hardware functions or interface modifications are made, further intensifying the rigidity of the interface and the difficulty of maintenance. Finally, the hardware service and the main program are statically linked, which cannot realize hot plug management, and the addition of new hardware services requires downtime upgrade. In addition, hardware service and main program dependency conflicts frequently occur, and there is a lack of dependency automatic analysis mechanism, which is low in maintenance efficiency. SUMMARY

[0003] In a first aspect, the embodiments of the application provide a self-service terminal hardware service driving method realizing cross-platform adaptation, comprising the following steps: S1. receiving a hardware service request generated by a front-end application, the hardware service request containing a target hardware identifier, an interface type and operation parameters; S2. a service bus dynamically loading a corresponding hardware service plug-in from a plug-in library according to the target hardware identifier; S3. an interface adaptation layer selecting a protocol template according to the interface type, and injecting operation parameters into the selected protocol template to generate intermediate instructions; S4. the loaded hardware service plug-in converting the intermediate instructions into platform-independent hardware instructions; S5. a platform adaptation layer detecting a current operating system type, and calling a corresponding underlying driving library to convert the platform-independent hardware instructions into operating system-level hardware instructions; S6. sending the operating system-level hardware instructions to physical hardware, and encapsulating a return result into a unified response format and returning the result to the front-end application.

[0004] Further, before the step S1, there is also a development deployment step as follows: SS1. Develop hardware driver including service bus module, interface adaptation layer module, platform adaptation layer module; SS2. Develop hardware service plug-in for each hardware device, which contains the following components: Instruction conversion engine: for converting intermediate instructions into platform-independent hardware instructions; Result parser: for processing raw data returned by hardware; Metadata file: declaring hardware identification and version number supported by the plug-in; SS3. Install hardware driver framework into target operating system and register as system service; SS4. Upload developed hardware service plug-in to plug-in library, which is deployed on local or cloud server; SS5. Configure protocol template library containing template definitions of different communication protocols.

[0005] Further, the specific steps of step S2 are as follows: S21. The service bus determines whether the corresponding plug-in is loaded according to the target hardware identification; If yes, go to step S3; If no, go to step S22; S22. The service bus retrieves the plug-in list table according to the target hardware identification to locate the corresponding plug-in file in the plug-in library; the plug-in list table records hardware identification, storage path, and dependency relationship; S23. Load the located plug-in file and determine all dependent plug-ins and load according to the dependency relationship; S24. Call the initialization function of the loaded plug-in to complete registration.

[0006] Further, the specific steps of step S3 are as follows: S31. The interface adaptation layer maintains the protocol template library; the storage structure of the protocol template in the protocol template library is: protocol type, template content, and parameter verification rule; S32. Match the protocol template according to the interface type and verify the operation parameters according to the parameter verification rule; If the verification is passed, go to step S33; If the verification fails, go to step S34; S33. Return error code to the front-end application and end; S34. Inject operation parameters into the protocol template to generate intermediate instructions.

[0007] Further, the specific steps of step S4 are as follows: S41. The hardware service plugin is configured with an instruction mapping table; the instruction mapping table structure includes intermediate instruction codes, platform-independent instruction codes, and parameter conversion rules. S42. The hardware service plugin parses the JSON field of the intermediate instruction to obtain the intermediate instruction code, converts the intermediate instruction code into platform-independent instruction code according to the instruction mapping table, and then reassembles the parameters according to the parameter conversion rules to generate platform-independent hardware instructions.

[0008] Furthermore, the specific steps of step S5 are as follows: S51. The platform adaptation layer detects the operating system type through system calls; S52. Select the underlying driver library according to the operating system type; S53. Convert platform-independent hardware instructions into operating system-level hardware instructions.

[0009] Furthermore, the specific steps of step S6 are as follows: S61. The raw data returned by the physical hardware is processed by the result parser of the hardware service plugin; S62. The result parser performs a CRC check on the raw data and marks an error status when the check fails; S63. Encapsulate the parsed data into a unified JSON response format and return it to the front-end application via the service bus.

[0010] Secondly, embodiments of this application also provide a self-service terminal hardware service driver system that enables cross-platform adaptation, comprising: The hardware service request receiving module is used to receive hardware service requests generated by the front-end application, which include the target hardware identifier, interface type, and operation parameters. The hardware plugin dynamic loading module is used to dynamically load the corresponding hardware service plugin from the plugin library according to the target hardware identifier via the service bus. The protocol adaptation and intermediate instruction generation module is used to select a protocol template according to the interface type through the interface adaptation layer, and inject the operation parameters into the selected protocol template to generate intermediate instructions. A cross-platform adaptation module is used to convert the intermediate instructions into platform-independent hardware instructions through a loaded hardware service plugin; The operating system-level instruction conversion module is used to detect the current operating system type through the platform adaptation layer and call the corresponding underlying driver library to convert platform-independent hardware instructions into operating system-level hardware instructions. The execution and feedback module is used to send operating system-level hardware commands to the physical hardware and encapsulate the returned results into a unified response format before returning them to the front-end application.

[0011] In a third aspect, the embodiments of the present application further provide an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the method for driving hardware service of self-service terminal in cross-platform adaptation according to the program.

[0012] In a fourth aspect, the embodiments of the present application further provide a storage medium having a computer program stored thereon, wherein the computer program is executable on a processor to implement the steps of the method for driving hardware service of self-service terminal in cross-platform adaptation according to the first aspect.

[0013] From the above technical solutions, the present application has the following advantages: The method, system, device and medium for driving hardware service of self-service terminal in cross-platform adaptation provided by the present application realize unified processing and execution of hardware service requests on different operating system platforms through cross-platform hardware request processing, dynamic plug-in loading and protocol adaptation, solve the problems of platform dependency, single interface, high module coupling, difficult version management and complex deployment and maintenance of the traditional scheme, improve the compatibility, flexibility and maintainability of the self-service terminal device, and reduce the development cost and maintenance difficulty. BRIEF DESCRIPTION OF DRAWINGS

[0014] In order to more clearly illustrate the technical solutions of the present application, the drawings required to be used in the description will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0015] Figure 1 The flowchart of the method for driving hardware service of self-service terminal in cross-platform adaptation of the present application.

[0016] Figure 2 The schematic diagram of the system for driving hardware service of self-service terminal in cross-platform adaptation of the present application. DETAILED DESCRIPTION

[0017] In the following detailed description of the specific steps of the method for driving hardware service of self-service terminal in cross-platform adaptation, various embodiments of the present disclosure will be described more fully. The present disclosure can have various embodiments, and adjustments and changes can be made therein. However, it should be understood that there is no intention to limit various embodiments of the present disclosure to the specific embodiments disclosed herein, but the present disclosure should be understood to cover all adjustments, equivalents and / or alternatives falling within the spirit and scope of various embodiments of the present disclosure.

[0018] With the wide application of self-service terminals in government affairs, finance, medical treatment and other fields, the flexibility and compatibility of hardware drivers become crucial. However, the traditional hardware service driving scheme is based on a monolithic architecture, which has the following limitations: first, the traditional hardware service driving scheme is tightly bound to a specific operating system kernel, such as a Windows exclusive driving framework or a Linux customized scheme, which makes it necessary to completely redevelop the driver when deploying across platforms, greatly increasing the adaptation cost and development cycle. Second, the traditional driving scheme only supports fixed interface protocols and cannot adapt to modern communication standards such as HTTP / RESTful and WebSocket, resulting in the need for additional development of customized gateways when self-service terminals are connected to third-party systems (such as cloud servers and mobile applications), which increases the complexity and cost of system integration. Moreover, interface parameter definitions are usually coded at the hardware driver layer, and once new hardware functions or interfaces are added or modified, the entire driver program must be recompiled and deployed, making the interface rigid and increasing maintenance difficulty. Third, the hardware service and the main program are statically linked, which cannot achieve hot plug management, and adding new hardware services requires downtime upgrade. At the same time, hardware service and main program dependency conflicts occur frequently, and there is a lack of dependency automatic analysis mechanism, which reduces maintenance efficiency.

[0019] To solve the above problems, the embodiment provides a self-service terminal hardware service driving method for realizing cross-platform adaptation, which realizes cross-platform adaptive self-service terminal hardware service driving, solves the problems of platform dependence, single interface and maintenance difficulty of traditional schemes through hardware driving architecture design and plug-in management, improves compatibility, flexibility and maintainability, and reduces development cost.

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

[0021] Please refer to Figure 1 Fig. 1 is a flowchart of a self-service terminal hardware service driving method for realizing cross-platform adaptation in a specific embodiment, and the method comprises the following steps: The self-service terminal hardware service driving method for realizing cross-platform adaptation comprises the following steps: S1. receiving a hardware service request generated by a front-end application, the request containing target hardware identification, interface type and operation parameters; It should be noted that the receiving front-end application generates a hardware service request, which clearly defines the basic elements of the hardware service request as the target hardware identifier, the interface type and the operation parameter, providing accurate input information for subsequent processing steps, so that the hardware service driver can be processed according to different hardware devices, communication protocols and operation requirements, improving the pertinence and flexibility of the hardware service request; S2. The service bus dynamically loads the corresponding hardware service plug-in from the plug-in library according to the target hardware identifier; It should be noted that the service bus dynamically loads the corresponding hardware service plug-in from the plug-in library according to the target hardware identifier, which realizes the plug-in management and dynamic loading of the hardware service, avoids the problems caused by the static linking of the hardware service and the main program in the traditional scheme, such as unable to hot plug, shutdown upgrade, etc., improves the flexibility and maintainability, and facilitates the rapid expansion and update of hardware service functions according to actual needs; S3. The interface adaptation layer selects a protocol template according to the interface type, and injects the operation parameter into the selected protocol template to generate intermediate instructions; It should be noted that the interface adaptation layer selects a protocol template according to the interface type, and injects the operation parameter into the protocol template to generate intermediate instructions, which supports multiple communication protocols through the identification of the interface type and the selection of the corresponding protocol template, meets the communication needs of the self-service terminal device with different platforms (such as cloud servers, mobile applications, etc.), and enhances the universality and adaptability of the hardware service driver; S4. The loaded hardware service plug-in converts the intermediate instructions into platform-independent hardware instructions; It should be noted that the loaded hardware service plug-in converts the intermediate instructions into platform-independent hardware instructions, which generates hardware instructions independent of the specific operating system through the instruction conversion function of the hardware service plug-in, provides a basis for subsequent cross-platform adaptation, reduces the dependence of hardware instructions on the operating system, and improves the cross-platform ability of the hardware service driver; S5. The platform adaptation layer detects the current operating system type, and calls the corresponding underlying driver library to convert the platform-independent hardware instructions into operating system-level hardware instructions; It should be noted that the platform adaptation layer detects the current operating system type, and calls the corresponding underlying driver library to convert the platform-independent hardware instructions into operating system-level hardware instructions, which realizes the adaptation and execution of hardware instructions on different operating system platforms, ensures that the hardware service can run normally in multiple operating system environments, effectively solves the platform dependency problem of the traditional scheme, and improves the compatibility and usability of the hardware service driver; S6. Send the operating system-level hardware instructions to the physical hardware, and encapsulate the return result into a unified response format and return it to the front-end application; It needs to be explained that the operation system level hardware instruction is sent to the physical hardware, and the returned result is packaged as a unified response format and returned to the front-end application, completing the final execution and result feedback of the hardware operation. Through the packaging of the unified response format, the front-end application can conveniently receive and process the hardware operation result, improving the interactivity and user experience between the hardware service driving and the front-end application.

[0022] The embodiment realizes the unified processing and execution of the hardware service request on different operating system platforms through the cross-platform hardware request processing, solves the platform dependency problem of the traditional scheme, reduces the cross-platform deployment cost, improves the flexibility and scalability of the hardware service, and provides a basis for the wide application of the self-service terminal device in a multi-operating system environment.

[0023] Further, as a refinement and extension of the above embodiment, in order to completely describe the specific implementation process in the embodiment, another self-service terminal hardware service driving method for realizing cross-platform adaptation is provided, which comprises the following steps: The self-service terminal hardware service driving method for realizing cross-platform adaptation comprises the following steps: S1. receiving a hardware service request generated by a front-end application, the hardware service request containing a target hardware identifier, an interface type and operation parameters; S2. the service bus dynamically loads a corresponding hardware service plug-in from a plug-in library according to the target hardware identifier; the step S2 specifically comprises the following steps: S21. the service bus determines whether the corresponding plug-in is loaded according to the target hardware identifier; If yes, go to step S3; If no, go to step S22; S22. the service bus searches a plug-in list table according to the target hardware identifier to locate a corresponding plug-in file in the plug-in library; the plug-in list table records hardware identifiers, storage paths and dependency relationships; S23. loading the located plug-in file and determining and loading all dependent plug-ins according to the dependency relationship; S24. calling an initialization function of the loaded plug-in to complete registration; S3. the interface adaptation layer selects a protocol template according to the interface type, and injects the operation parameters into the selected protocol template to generate intermediate instructions; the step S3 specifically comprises the following steps: S31. the interface adaptation layer maintains a protocol template library; the storage structure of the protocol template in the protocol template library is: protocol type, template content and parameter verification rule; S32. matching the protocol template according to the interface type, and verifying the operation parameters according to the parameter verification rule; If the verification is passed, go to step S33; If the verification fails, go to step S34; S33. Return an error code to the front-end application and end; S34. Inject operation parameters into the protocol template to generate intermediate instructions; S4. The loaded hardware service plug-in converts the intermediate instructions into platform-independent hardware instructions; The specific steps of step S4 are as follows: S41. The hardware service plug-in is configured with an instruction mapping table; the instruction mapping table structure includes intermediate instruction codes, platform-independent instruction codes, and parameter conversion rules; S42. The hardware service plug-in parses the JSON field of the intermediate instructions to obtain the intermediate instruction codes, and converts the intermediate instruction codes into platform-independent instruction codes according to the instruction mapping table, and generates platform-independent hardware instructions by recombining parameters according to the parameter conversion rules; S5. The platform adaptation layer detects the current operating system type, and calls the corresponding underlying drive library to convert the platform-independent hardware instructions into operating system-level hardware instructions; The specific steps of step S5 are as follows: S51. The platform adaptation layer detects the operating system type through system call; For example, the Windows operating system is identified by calling the `GetVersionExW()` function; Linux / UOS is identified by parsing the ` / proc / version` file; S52. Select the underlying drive library according to the operating system type; For example, the underlying drive libraries and calling functions of different operating systems are shown in Table 1; Table 1

[0024] S53. Convert the platform-independent hardware instructions into operating system-level hardware instructions; For example, the Windows operating system is encapsulated as an IO control code (IOCTL) structure; Linux / UOS is encapsulated as a byte stream command; S6. Send the operating system-level hardware instructions to the physical hardware, and encapsulate the returned results into a unified response format and return them to the front-end application; the specific steps of step S6 are as follows: S61. The raw data returned by the physical hardware is processed by the result parser of the hardware service plug-in; S62. The result parser performs CRC check on the raw data, and marks an error state when the check fails; S63. Encapsulate the parsed data into a JSON unified response format, and return it to the front-end application through the service bus.

[0025] In an embodiment of the present application, the following will give a possible embodiment to specifically illustrate the non-limiting embodiment.

[0026] Before the step S1, the development deployment step is further included as follows: SS1. Develop the hardware driver including the service bus module, the interface adaptation layer module, and the platform adaptation layer module; SS2. Develop the hardware service plug-in for each hardware device, which contains the following components: Instruction conversion engine: for converting intermediate instructions into platform-independent hardware instructions; Result parser: for processing raw data returned by hardware; Metadata file: declaring the hardware identification and version number supported by the plug-in; SS3. Install the hardware driver framework into the target operating system and register as a system service; SS4. Upload the developed hardware service plug-in to the plug-in library, which is deployed on a local or cloud server; SS5. Configure the protocol template library containing template definitions of different communication protocols; Exemplarily, the communication protocols include HTTP and WebSocket; It should be noted that through the development deployment steps of the hardware driver development, the hardware service plug-in development and registration, and the protocol template library configuration, a perfect implementation framework is provided for the construction and operation of the entire hardware service driving system, ensuring the integrity and operability of the system, and facilitating the improvement of development efficiency and system stability.

[0027] It should be understood that the size of the serial number of each step in the above embodiment does not mean the order of execution, and the execution order of each process should be determined according to its function and internal logic, and should not constitute any limitation on the implementation process of the embodiment of the present application.

[0028] As Figure 2 shown below is an embodiment of the self-service terminal hardware service driving system provided by the embodiment of the present disclosure for realizing cross-platform adaptation, which belongs to the same inventive concept as the cross-platform adaptive self-service terminal hardware service driving method of the above embodiments. Details not described in the embodiment of the self-service terminal hardware service driving system for realizing cross-platform adaptation can be referred to the above embodiment of the cross-platform adaptive self-service terminal hardware service driving method.

[0029] The system comprises: A hardware service request receiving module is configured to receive a hardware service request generated by a front-end application, the hardware service request containing a target hardware identification, an interface type, and operation parameters; The hardware plug-in dynamic loading module is configured to dynamically load a corresponding hardware service plug-in from a plug-in library according to the target hardware identifier through a service bus. The protocol adaptation and intermediate instruction generation module is configured to select a protocol template according to the interface type through the interface adaptation layer, and generate an intermediate instruction by injecting operation parameters into the selected protocol template. The cross-platform adaptation module is configured to convert the intermediate instruction into platform-independent hardware instructions through the loaded hardware service plug-in. The operating system level instruction conversion module is configured to detect a current operating system type through the platform adaptation layer, and convert the platform-independent hardware instructions into operating system level hardware instructions by calling a corresponding underlying driver library. The execution and feedback module is configured to send the operating system level hardware instructions to the physical hardware, and encapsulate a returned result into a unified response format and return the result to the front-end application.

[0030] The hardware service request is uniformly processed and executed on different operating system platforms through the interaction and cooperation of the hardware service request receiving module, the hardware plug-in dynamic loading module, the protocol adaptation and intermediate instruction generation module, the cross-platform adaptation module, the operating system level instruction conversion module, and the execution and feedback module. The problems of platform dependency, single interface, high module coupling degree, difficult version management, and complex deployment and maintenance of the traditional scheme are effectively solved.

[0031] The self-service terminal hardware service driving method for realizing cross-platform self-adaptation provided in the embodiments of the present application can be applied to electronic devices. Those skilled in the art can understand that the electronic device structure involved in the embodiments of the present application does not constitute a limitation on the electronic device, and the electronic device can include more or fewer components than the illustration, or combine certain components, or different component arrangements. In the embodiments of the present application, the electronic device includes but is not limited to a laptop computer, a desktop computer, a workstation, a personal digital assistant, a server, a blade server, a mainframe computer, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as a personal digital processor, a cellular phone, a smart phone, a wearable device, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the embodiments of the present application described and / or claimed herein.

[0032] The electronic device can include a processor, an external memory interface, an internal memory, a universal serial bus (USB) interface, a charge management module, a power management module, a battery, a wireless communication module, an audio module, a speaker, a microphone, a sensor module, a key, a camera, a display screen, and a SIM card interface, etc.

[0033] It can be understood that the structure shown in the embodiments of the present application does not constitute a specific limitation on the electronic device. In other embodiments of the present application, the electronic device can include more or fewer components than shown, or combine certain components, or split certain components, or different arrangement of components. The components shown can be implemented in hardware, software, or a combination of software and hardware.

[0034] The processor can include one or more processing units, such as: the processor can include a central processing unit (CPU), an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a memory, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU), etc. Among them, different processing units can be independent devices, or can be integrated in one or more processors.

[0035] Among them, the processor can be the nerve center and command center of the electronic device. The controller can generate operation control signals according to instruction operation codes and timing signals, and complete the control of fetching and executing instructions.

[0036] The processor can also be provided with a memory for storing instructions and data. In some embodiments, the memory in the processor is a cache memory. The memory can save instructions or data that the processor has just used or repeatedly uses. If the processor needs to use the instructions or data again, it can directly call from the memory. Avoiding repeated access, reducing the waiting time of the processor, thus improving the efficiency of the system.

[0037] The electronic device realizes a hardware service request generated by a receiving front-end application and containing a target hardware identifier, an interface type, and operation parameters; a service bus dynamically loads a corresponding hardware service plug-in from a plug-in library according to the target hardware identifier; an interface adaptation layer selects a protocol template according to the interface type, injects operation parameters into the selected protocol template to generate intermediate instructions; the loaded hardware service plug-in converts the intermediate instructions into platform-independent hardware instructions; a platform adaptation layer detects a current operating system type, calls a corresponding underlying driver library to convert the platform-independent hardware instructions into operating system-level hardware instructions; and the operating system-level hardware instructions are sent to physical hardware, and a returned result is packaged into a unified response format and returned to the front-end application.

[0038] In the storage medium provided in the present application, a program product capable of realizing the self-service terminal hardware service driving method across platforms is stored.

[0039] The self-service terminal hardware service driving method across platforms comprises: receiving a hardware service request generated by a front-end application and containing a target hardware identifier, an interface type, and operation parameters; a service bus dynamically loads a corresponding hardware service plug-in from a plug-in library according to the target hardware identifier; an interface adaptation layer selects a protocol template according to the interface type, injects operation parameters into the selected protocol template to generate intermediate instructions; the loaded hardware service plug-in converts the intermediate instructions into platform-independent hardware instructions; a platform adaptation layer detects a current operating system type, calls a corresponding underlying driver library to convert the platform-independent hardware instructions into operating system-level hardware instructions; and the operating system-level hardware instructions are sent to physical hardware, and a returned result is packaged into a unified response format and returned to the front-end application.

[0040] In some possible implementation manners, the self-service terminal hardware service driving method across platforms of the present disclosure can be implemented in the form of a program product, which includes program code for causing a terminal device to execute the steps of various exemplary embodiments of the present disclosure described in the above “Exemplary Method” section of the present specification when the program product is run on the terminal device.

[0041] The storage medium of the present disclosure can employ any combination of one or more computer-readable media. The computer-readable media can be a computer- readable signal medium or a computer-readable storage medium. A computer-readable storage medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer-readable storage medium include the following: an electrical connection having one or more wires, a portable disc, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0042] The foregoing description of the disclosed embodiments enables a person skilled in the art to implement or use the invention. Various modifications to these embodiments will be apparent to those skilled in the art, and the generic principles defined herein can be applied to other embodiments without departing from the spirit or scope of the invention. Accordingly, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for driving hardware services of a self-service terminal to achieve cross-platform adaptability, characterized in that, Includes the following steps: S1. Receive a hardware service request generated by the front-end application, which includes the target hardware identifier, interface type, and operation parameters; S2. The service bus dynamically loads the corresponding hardware service plugin from the plugin library based on the target hardware identifier; S3. The interface adaptation layer selects a protocol template according to the interface type and injects the operation parameters into the selected protocol template to generate intermediate instructions; S4. The loaded hardware service plugin converts the intermediate instructions into platform-independent hardware instructions; S5. The platform adaptation layer detects the current operating system type and calls the corresponding underlying driver library to convert platform-independent hardware instructions into operating system-level hardware instructions. S6. Send operating system-level hardware commands to the physical hardware and encapsulate the returned results into a unified response format before returning them to the front-end application.

2. The self-service terminal hardware service driving method for cross-platform adaptation according to claim 1, characterized in that, The development and deployment steps preceding step S1 are as follows: SS1. Develop hardware drivers including service bus module, interface adaptation layer module, and platform adaptation layer module; SS2. Develop hardware service plugins for each hardware device, wherein the hardware service plugins include the following components: Instruction translation engine: used to translate intermediate instructions into platform-independent hardware instructions; Result parser: Used to process the raw data returned by the hardware; Metadata file: declares the hardware identifiers and version numbers supported by the plugin; SS3. Installs the hardware driver framework into the target operating system and registers it as a system service; SS4. Upload the developed hardware service plugins to the plugin library, which is deployed on a local or cloud server; SS5. Configure a protocol template library containing template definitions for different communication protocols.

3. The self-service terminal hardware service driving method for cross-platform adaptation according to claim 1, characterized in that, The specific steps of step S2 are as follows: S21. The service bus determines whether the corresponding plugin is loaded based on the target hardware identifier; If so, proceed to step S3; If not, proceed to step S22; S22. The service bus retrieves the plugin manifest table based on the target hardware identifier and locates the corresponding plugin file in the plugin library; the plugin manifest table records the hardware identifier, storage path, and dependencies. S23. Load the located plugin files, and determine and load all dependent plugins based on the aforementioned dependencies; S24. Call the initialization function of the loaded plugin to complete the registration.

4. The self-service terminal hardware service driving method for cross-platform adaptation according to claim 3, characterized in that, The specific steps of step S3 are as follows: S31. The interface adaptation layer maintains a protocol template library; the storage structure of the protocol templates in the protocol template library is: protocol type, template content, and parameter verification rules; S32. Match the protocol template according to the interface type and verify the operation parameters according to the parameter verification rules; If the verification passes, proceed to step S33; If verification fails, proceed to step S34; S33. Return the error code to the front-end application and end; S34. Inject the operation parameters into the protocol template to generate intermediate instructions.

5. The self-service terminal hardware service driving method for cross-platform adaptation according to claim 4, characterized in that, The specific steps of step S4 are as follows: S41. The hardware service plugin is configured with an instruction mapping table; the instruction mapping table structure includes intermediate instruction codes, platform-independent instruction codes, and parameter conversion rules. S42. The hardware service plugin parses the JSON field of the intermediate instruction to obtain the intermediate instruction code, converts the intermediate instruction code into platform-independent instruction code according to the instruction mapping table, and then reassembles the parameters according to the parameter conversion rules to generate platform-independent hardware instructions.

6. The self-service terminal hardware service driving method for cross-platform adaptation according to claim 5, characterized in that, The specific steps of step S5 are as follows: S51. The platform adaptation layer detects the operating system type through system calls; S52. Select the underlying driver library according to the operating system type; S53. Convert platform-independent hardware instructions into operating system-level hardware instructions.

7. The self-service terminal hardware service driving method for cross-platform adaptation according to claim 6, characterized in that, The specific steps of step S6 are as follows: S61. The raw data returned by the physical hardware is processed by the result parser of the hardware service plugin; S62. The result parser performs a CRC check on the raw data and marks an error status when the check fails; S63. Encapsulate the parsed data into a unified JSON response format and return it to the front-end application via the service bus.

8. A self-service terminal hardware service driver system that achieves cross-platform adaptability, characterized in that, include: The hardware service request receiving module is used to receive hardware service requests generated by the front-end application, which include the target hardware identifier, interface type, and operation parameters. The hardware plugin dynamic loading module is used to dynamically load the corresponding hardware service plugin from the plugin library according to the target hardware identifier via the service bus. The protocol adaptation and intermediate instruction generation module is used to select a protocol template according to the interface type through the interface adaptation layer, and inject the operation parameters into the selected protocol template to generate intermediate instructions. A cross-platform adaptation module is used to convert the intermediate instructions into platform-independent hardware instructions through a loaded hardware service plugin; The operating system-level instruction conversion module is used to detect the current operating system type through the platform adaptation layer and call the corresponding underlying driver library to convert platform-independent hardware instructions into operating system-level hardware instructions. The execution and feedback module is used to send operating system-level hardware commands to the physical hardware and encapsulate the returned results into a unified response format before returning them to the front-end application.

9. An electronic device, characterized in that, The device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, when the processor executes the program, it implements the steps of the method for implementing a cross-platform adaptive self-service terminal hardware service as described in any one of claims 1 to 7.

10. A storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the method for implementing a cross-platform adaptive self-service terminal hardware service driver as described in any one of claims 1 to 7.

Images