An intelligent lock application software simulation system

Abstract

This invention discloses a smart lock application software simulation system, comprising a hardware driver layer, a functional component layer, a bridging layer, an operating system layer, and an application layer. Each layer communicates via standardized interfaces. The hardware driver layer shields hardware differences, and the bridging layer handles cross-layer data adaptation, resolving the hardware-software coupling problem. This allows application development to be completely decoupled from the hardware foundation, and the code can be directly deployed after debugging, improving development efficiency and code reusability. The task isolation architecture allows the application layer to run in independent tasks, and the component-based design achieves loose coupling between functional modules. This avoids single-module malfunctions affecting the overall system while supporting dynamic module loading and updates, improving system stability and scalability. Furthermore, the combination of a visual development platform and an AI engine lowers the development threshold, and the remote monitoring and management functions further enhance system maintainability and management efficiency.

Description

Technical Field

[0001] This invention relates to the field of smart lock technology, and in particular to a smart lock application software simulation system. Background Technology

[0002] As intelligent security devices, smart locks rely heavily on their software systems to achieve functions such as fingerprint recognition and lock body control. With the diversification of application scenarios, the industry has placed higher demands on the cross-platform compatibility, development efficiency, and scalability of smart lock software systems, creating an urgent need for better software architecture adaptation technologies to meet market demands.

[0003] In existing technologies, smart lock software systems mostly adopt an integrated architecture without standardized hierarchical division and interaction interfaces. Hardware drivers, business logic, and function implementation are highly integrated, and development and debugging are highly dependent on real hardware. The communication protocols of different hardware platforms are not unified, and development requires separate programming and testing for different platforms.

[0004] Existing smart lock software systems suffer from numerous technical problems: high coupling between hardware and software necessitates software refactoring for hardware upgrades, resulting in high maintenance costs; the lack of standardized layers and interfaces leads to high complexity in data transmission and command interaction between layers, resulting in poor system scalability; communication protocols are tied to hardware, making adaptation to new platforms labor-intensive and integration difficult; furthermore, development requires proficiency in multiple language stacks, leading to high barriers to entry and low efficiency, while the reliance on real hardware for debugging further reduces development and testing efficiency; traditional systems employ a monolithic architecture, lacking dynamic loading and hot update mechanisms, requiring debugging and testing on real hardware, making it impossible to detect compatibility and stability issues in advance, and inconsistent protocols increase system integration complexity. Summary of the Invention

[0005] This invention provides a smart lock application software simulation system. By adopting a five-layer distributed architecture, task isolation technology, component-based design, a visual development platform, and a hardware simulation mode, it solves the technical problems of traditional smart lock systems, such as difficulty in adapting communication protocols, severe software and hardware coupling, high development threshold, stringent requirements for multi-language technology stacks, insufficient system scalability, and low debugging and testing efficiency.

[0006] According to one aspect of the present invention, a smart lock application software simulation system is provided, the system comprising: a hardware driver layer, a functional component layer, a bridging layer, an operating system layer, and an application layer, wherein each layer communicates bidirectionally with the other through a standardized interface; The hardware driver layer is used to obtain hardware status data of the underlying hardware devices and send the hardware status data to the functional component layer. The functional component layer is used to generate hardware control data based on hardware status data, send the hardware control data to the hardware driver layer, generate component event and state change data, and send the component event and state change data to the bridge layer. The bridging layer is used to serialize, route, and transform component event and state change data, generate transformed data, and send the transformed data to the application layer.

[0007] Optionally, the bridging layer is also used to receive control command data from the application layer, perform deserialization and parsing to generate parsed data, and forward the parsed data to the functional component layer.

[0008] Optionally, the operating system layer provides basic system services such as process management, memory management, file management, and task scheduling for the hardware driver layer, functional component layer, bridging layer, and application layer, and receives system service requests from each layer and feeds back result data to each layer based on the system service requests.

[0009] Optionally, the system also includes: a task isolation architecture module, a component-based design module, and a working mode selection module, each of which communicates with each layer; the task isolation architecture module is used to create independent real-time operating system tasks for the application layer, configure independent priorities and stack spaces for the real-time operating system tasks, obtain the task code of the application layer, and run the task code in the real-time operating system task, so that the application layer tasks run in isolation from other system tasks; the component-based design module is used to modularize and standardize the functional component layer, so as to divide the smart lock function into at least one independent functional component.

[0010] Optionally, the working mode selection module includes: a simulation panel selection unit, a master-slave role selection unit, and a hardware code simulation unit.

[0011] Optionally, the system also includes: a visual development platform that communicates with the application layer, and an AI engine that communicates with the visual development platform; the visual development platform is used to obtain user input functional requirements based on a graphical development interface and send the functional requirements to the AI ​​engine; the AI ​​engine is used to parse natural language requirements based on a large language model, generate application code, optimize the application code to generate optimized code, and send the optimized code to the visual development platform; the visual development platform is used to obtain user input editing instructions, edit the optimized code based on the editing instructions, generate the edited optimized code, and send the edited optimized code to the application layer.

[0012] Optionally, the bridging layer includes a first bridging layer and a second bridging layer. The first bridging layer includes an application layer loader, component bridging, front-end and back-end board communication bridging, message bridging, and log bridging. The second bridging layer includes an operating system abstraction layer bridging, device stubs, and a message queue manager.

[0013] Optionally, the functional component layer is divided into front panel components and rear panel components according to function. The front panel components include fingerprint recognition components, face recognition components, card recognition components, keypad components, audio playback components, and LED indicator components, which are used to receive user input and execute output actions. The rear panel components include lock body control components, motor control components, door magnetic sensor components, battery management components, Bluetooth communication components, and wireless LAN communication components, which are used for lock body control, status monitoring, and network communication.

[0014] Optionally, the operating system layer includes the operating system abstraction layer interface, which includes message queue interface, event handling interface, timer interface, and task scheduling interface.

[0015] Optionally, the system may also include: a remote monitoring and management module that communicates with each level; the remote monitoring and management module is used to: obtain system-related status and system operation logs in real time, and display the system-related status and system operation logs to the user, in order to obtain configuration modification commands input by the user, and remotely modify system configuration parameters based on the configuration modification commands, wherein the system-related status includes system operation status and functional component status.

[0016] The technical solution of this invention solves the hardware coupling problem by shielding hardware differences through a hardware driver layer and completing cross-layer data adaptation through a bridging layer. This allows application development to be completely decoupled from the hardware base, and the code can be directly deployed after debugging, improving development efficiency and code reusability. The task isolation architecture allows application-layer programs to run in independent tasks, and the component-based design achieves loose coupling of functional modules. This avoids the impact of a single module's failure on the overall system and supports dynamic module loading and updates, improving system stability and scalability. Furthermore, the combination of a visual development platform and an AI engine lowers the development threshold, and the remote monitoring and management functions further enhance system maintainability and management efficiency.

[0017] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a schematic diagram of the structure of a smart lock application software simulation system according to Embodiment 1 of the present invention; Figure 2 This is a schematic diagram of the structure of a smart lock application software simulation system provided in Embodiment 3 of the present invention. Detailed Implementation

[0020] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0021] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0022] Example 1 Figure 1 The present invention provides a schematic diagram of the structure of a smart lock application software simulation system according to Embodiment 1. The system includes: a hardware driver layer 110, a functional component layer 120, a bridging layer 130, an operating system layer 140, and an application layer 150. The layers communicate bidirectionally with each other through standardized interfaces.

[0023] The smart lock application software simulation system provided in this embodiment adopts a five-layer distributed architecture, including: a hardware driver layer, a functional component layer, a bridging layer, an operating system layer, and an application layer. Communication and data transmission between each layer are achieved through standardized interfaces, enabling flexible system expansion and upgrades. The hardware driver layer is the bottom layer of the five-layer distributed architecture of the smart lock application software simulation system. It is the core layer responsible for direct interaction with the underlying hardware devices of the smart lock, such as general-purpose input / output ports (GPIO), universal asynchronous receiver / transmitter (UART), serial peripheral interface (SPI), and inter-integrated circuit (I2C) buses, as well as physical hardware such as fingerprint recognition, lock motor, and door magnetic sensor. The hardware driver layer provides a unified hardware abstraction interface, shielding the differences between different hardware platforms, so that upper-layer applications do not need to worry about the specific hardware implementation details. The hardware driver layer supports multiple embedded platforms, including but not limited to ARM Cortex-M series and RISC-V. In addition, the hardware driver layer collects hardware status data and sends it upwards to the functional component layer. Simultaneously, it receives hardware control data from the functional component layer and converts it into hardware-recognizable instructions to drive hardware operations. The functional component layer is a modular layer that implements various core functions of the smart lock, breaking down the smart lock's functions into multiple independent functional components. Its core role is modular functional processing and data relay: based on the hardware status data uploaded by the hardware driver layer, it generates hardware control data by combining the component's own functional logic and sends it down to the hardware driver layer; simultaneously, it encapsulates hardware status changes and component operation events, such as successful fingerprint recognition and lock unlocking completion, into component events and status change data, sending them upwards to the bridging layer to achieve linkage between hardware status and the upper-layer system. The bridging layer is the relay layer connecting the hardware driver layer, functional component layer, and application layer, and is also key to achieving cross-layer and cross-language communication. It consists of two parts: a Python bridging layer and a C bridging layer. Its core functions are data processing and interface adaptation: after receiving component events and state change data from the functional component layer, it uses its core modules such as message bridging and component bridging to complete data serialization, routing, and interface conversion, ultimately generating standardized converted data and sending it to the application layer; it is also responsible for reverse-converting and routing control commands from the application layer to the functional component layer / hardware driver layer. The operating system layer, located between the bridging layer and the application layer, is the core layer providing the basic operating environment and system services for the entire system. It adopts an embedded operating system, such as an event-driven real-time operating system (Kernel Operating System, KOS), and includes a system management framework.The core function is system resource management and task scheduling: providing basic services such as process management, file management, memory management, and network connectivity; through the Operating System Abstraction Layer (OSAL), it provides standardized interfaces for message queues, event handling, timers, and task scheduling, supporting the task execution of the upper application layer and the lower bridging layer; it also enables dynamic loading and runtime management of applications, ensuring the concurrent and real-time execution of multiple system tasks. The application layer provides a layer for developers and users to develop, run, and debug smart lock business logic. Its core function is business logic implementation and interaction: receiving converted data sent by the bridging layer, processing it based on the business logic written by developers / generated by the platform, and sending corresponding control commands downwards; it supports two running modes: hardware code simulation mode and PC simulation application layer mode, achieving complete decoupling between the application and the hardware base, allowing developers to complete development and debugging on the PC without relying on real hardware.

[0024] Optionally, the hardware driver layer is used to obtain hardware status data of the underlying hardware device and send the hardware status data to the functional component layer; the functional component layer is used to generate hardware control data based on the hardware status data, send the hardware control data to the hardware driver layer, and generate component event and state change data, and send the component event and state change data to the bridge layer; the bridge layer is used to serialize, route and interface convert the component event and state change data, generate converted data, and send the converted data to the application layer.

[0025] The standardized interface is a unified specification interface for communication and data transmission between different layers of the system. It establishes a unified communication protocol, data format, and calling rules for bidirectional interaction between the five-layer architecture. The standardized interface shields the implementation details of each layer, allowing layers to complete data transmission and command interaction solely through this interface, enabling independent development, upgrades, and replacements for each layer. It also solves compatibility issues between different hardware platforms, programming languages, and functional modules, improving the system's flexibility and scalability. The underlying hardware devices refer to the various physical hardware components and interfaces of the smart lock, forming the foundation for its physical functions. These are divided into hardware interfaces and functional hardware. Hardware status data refers to real-time status information collected by the hardware driver layer from the underlying hardware devices. This raw data reflects the current operating status and physical state of the hardware, such as whether the fingerprint recognition module is working, the lock's current locked / unlocked state, remaining battery power, and the door's open / closed status detected by the door magnetic sensor. Hardware control data refers to instruction data generated by the functional component layer based on hardware state data and its own functional logic. It is standardized instruction that can be recognized by the hardware driver layer and converted into hardware actions. Examples include instructions to unlock the lock motor, instructions to control the LED indicator to light up, and instructions to adjust fingerprint recognition sensitivity. Component event and state change data refers to standardized event and state data encapsulated and generated by the functional component layer. It is a structured expression of functional component operation events and hardware state changes, distinct from raw hardware state data. This data has been modularly encapsulated in conjunction with component functions. Examples include fingerprint recognition success / failure events, lock unlock / lock state changes, and password input error count exceeding limits. Serialization is the format conversion processing performed by the bridging layer, referring to the process of converting component event and state change data into standardized binary / specific format data. Routing is the precise forwarding processing of data by the bridging layer, referring to the process of forwarding component event and state change data to the corresponding module / task in the application layer based on information such as data type, destination address, and business affiliation. Interface conversion is the bridging layer's solution for cross-layer / cross-language interface incompatibility. It involves converting the hardware / component interface protocols of the functional component layer into development interface protocols recognizable by the application layer, while simultaneously adapting the interfaces between C and Python languages. Transformed data is standardized data generated by the bridging layer after serializing, routing, and converting component event and state change data. This data is directly recognizable and parsed by the application layer and represents the final data format transmitted from the bridging layer to the application layer. It retains the core information of the original data and adapts to the application layer's interface specifications and data parsing logic.

[0026] Specifically, the hardware driver layer, as the direct layer for interaction between the system and the underlying hardware devices, collects the real-time operating status of various underlying hardware devices in the smart lock through drivers for hardware interfaces such as GPIO, UART, SPI, and I2C. This includes data such as the fingerprint recognition module's recognition status, the lock / unlock status of the lock body, the door opening / closing status detected by the door magnetic sensor, the remaining battery power of the battery management module, and the connection status of the Bluetooth / Wi-Fi communication components—in other words, hardware status data. The hardware driver layer itself provides a unified hardware abstraction interface. It first standardizes the hardware status data from different hardware platforms, shielding the differences in the underlying implementation of different hardware. Then, through the standardized interface between layers, it sends the processed hardware status data upwards to the functional component layer, ensuring that the functional component layer can directly recognize and use this data without needing to concern itself with the specific hardware acquisition details or hardware platform differences.

[0027] Then, after receiving the hardware status data from the hardware driver layer, the functional component layer parses and processes the data according to its own functional logic and preset business rules to generate hardware control data. For example, after receiving the hardware status data of successful fingerprint recognition, the fingerprint component in the functional component layer combines the business logic of lock body control to generate hardware control data to drive the lock body motor to unlock; if it receives the hardware status data of incorrect password input, it will generate hardware control data to control the LED indicator to flash and the audio playback component to emit a prompt sound. The generated hardware control data is sent to the hardware driver layer through a standardized interface, where it is converted into specific instructions executable by the underlying hardware device to drive the hardware to complete the corresponding actions. At the same time, in the process of processing hardware status data and executing relevant functional logic, the functional component layer modularly encapsulates the hardware state changes and the component's own running events to form component event and state change data, such as fingerprint recognition success event, lock body unlocking state change, password error three times exceeding the limit event, Bluetooth connection success event, etc. The functional component layer sends these component event and state change data to the bridge layer through a standardized interface.

[0028] Finally, upon receiving component event and state change data from the functional component layer, the message bridging module first serializes the data, transforming the original structured data into standardized binary protocol data. After serialization, the bridging layer, based on information such as data type, target address, and business affiliation, uses modules like component bridging and operating system port protocol bridging to precisely route the data, clarifying which specific module or task in the application layer the data needs to be sent to, achieving accurate data navigation and avoiding data transmission chaos. Furthermore, due to differences in programming languages ​​and interface protocols between the functional component layer and the application layer, the bridging layer also performs interface conversion, transforming the hardware / component interface protocols adapted by the functional component layer into development interface protocols recognizable by the application layer, resolving cross-layer and cross-language interface incompatibility issues. After this series of processes—serialization, routing, and interface conversion—component event and state change data is transformed into standardized, directly recognizable and parsable data by the application layer. Finally, the bridging layer accurately sends the transformed data to the application layer through standardized inter-layer interfaces, ensuring the application layer can smoothly execute subsequent business logic processing based on this data.

[0029] Optionally, the bridging layer is also used to receive control command data from the application layer, perform deserialization and parsing to generate parsed data, and forward the parsed data to the functional component layer.

[0030] Specifically, the bridging layer receives control command data in real time from the application layer, processed based on business logic. This control command data consists of commands issued by the application layer for various functions of the smart lock, such as triggering lock unlocking, controlling LED indicator lights, adjusting fingerprint recognition sensitivity, and issuing Bluetooth communication connection commands. This data is standardized serialized data and must be processed by the bridging layer before it can be recognized by the functional component layer. Upon receiving the control command data, the bridging layer first performs deserialization processing via the message bridging module, restoring the standardized binary protocol data transmitted by the application layer into structured data that the bridging layer can parse. This process is the reverse of the previous serialization of component event and state change data, ensuring the complete restoration of the core information of the control command and guaranteeing that the command content is not lost or tampered with. After deserialization, the bridging layer parses the restored structured data, identifying key information such as the target component, command type, and execution parameters of the control command. For example, it parses whether the command is an unlock command sent to the lock body control component or a constant-on command sent to the LED indicator component. It also extracts execution parameters from the command, such as the LED indicator's illumination duration and the fingerprint recognition sensitivity threshold. This parsing process generates parsed data that the functional component layer can directly recognize and execute. Then, based on the parsed target component information, the bridging layer forwards the parsed data through the component bridging module and the operating system port protocol bridging module. If the command is for a component within a single board, it is directly forwarded to the corresponding functional component via the component bridging module. If it is a control command across front and rear boards, it uses the operating system port protocol bridging module to achieve transparent cross-board forwarding based on the operating system port protocol, shielding the details of low-level hardware communication such as UART, SPI, and I2C, ensuring that the parsed data is accurately delivered to the specific component in the target functional component layer.

[0031] Optionally, the operating system layer provides basic system services such as process management, memory management, file management, and task scheduling for the hardware driver layer, functional component layer, bridging layer, and application layer, and receives system service requests from each layer and feeds back result data to each layer based on the system service requests.

[0032] Specifically, the operating system layer provides basic system services such as process management, memory management, file management, and task scheduling for the hardware driver layer, functional component layer, bridging layer, and application layer. It also receives various system service requests from each layer in real time, processes them, and feeds back the results to the corresponding layer, providing underlying support for the normal operation of each layer and collaborative work between layers, ensuring the overall real-time performance, stability, and orderliness of the system. Process management services refer to the operating system layer's unified creation, startup, suspension, termination, and scheduling management of all processes running at each layer. For example, it allocates independent running resources and identifiers to the hardware code simulation process in the application layer, the Python and C bridge processes in the bridging layer, and the running processes of each component in the functional component layer, avoiding conflicts and interference between processes. When a layer needs to create a new process to implement a specific function, such as when the application layer needs to create an independent process to load new C application layer code, it will send a process creation service request to the operating system layer. After receiving the request, the operating system layer will complete the process creation based on the current system resource usage and feed back the result data such as the process creation success identifier and process ID to the application layer. If the creation fails due to insufficient resources, it will feed back the failure reason and related prompt data. Memory management services refer to the operating system layer using static memory allocation to allocate dedicated memory space to each layer, while uniformly managing the overall system memory resources to avoid memory fragmentation issues caused by dynamic memory allocation. For example, 20KB of stack space is allocated for complex business processing tasks in the application layer, 5KB for simple logging tasks, a fixed circular buffer for the message queue in the bridge layer, and dedicated memory for the hardware data acquisition cache in the hardware driver layer. When each layer has a need for memory allocation, release, or querying, such as a fingerprint component in the functional component layer needing temporary memory to cache fingerprint data and initiating a memory allocation request, the operating system layer allocates an appropriate memory area according to memory allocation rules, and then feeds back the memory address, memory size, and other result data to the fingerprint component. After data caching is complete, the fingerprint component initiates a memory release request, and the operating system layer releases the memory area and feeds back the successful release result data to the component. File management services refer to the operating system layer providing file creation, reading, writing, storage, and management services to each layer, supporting the needs of each layer for log storage, configuration file reading, and data persistence. Upon receiving a request, the operating system layer performs the corresponding operation based on the type of file operation. For example, it opens the specified log file for the log bridging module and completes the log writing, then sends back the results, such as successful file writing and the writing position, to the log bridging module. If the file is not found when reading the configuration file, it sends back an error message indicating that the file does not exist. The task scheduling service refers to the operating system layer's priority- and event-driven scheduling mechanism, which uniformly schedules all tasks at each level.The operating system layer assigns different priorities to different tasks based on their importance and real-time requirements. When multiple tasks initiate execution requests simultaneously, the operating system layer prioritizes the execution of high-priority tasks and allocates corresponding CPU resources to each task to ensure the orderly execution of tasks.

[0033] In addition, the operating system layer provides a unified OSAL (Operating System Abstraction Layer) interface, which shields the underlying implementation details of process management, memory management, file management, and task scheduling. Each layer does not need to concern itself with the specific implementation logic of the operating system; it only needs to initiate system service requests through the standardized OSAL interface. After receiving all system service requests initiated by each layer through the OSAL interface, the operating system layer first parses the requests, identifying key information such as the initiating layer, request type, and request parameters. Then, it processes the requests according to the corresponding service rules and the current system running status. After processing, it feeds back the result data, including processing results, execution status, and relevant parameters, to the requesting layer through the standardized OSAL interface, ensuring that the system service needs of each layer receive a fast and accurate response, and guaranteeing the efficient and stable operation of the entire smart lock application software simulation system.

[0034] Optionally, the bridging layer includes a first bridging layer and a second bridging layer. The first bridging layer includes an application layer loader, component bridging, front-end and back-end board communication bridging, message bridging, and log bridging. The second bridging layer includes an operating system abstraction layer bridging, device stubs, and a message queue manager.

[0035] The bridging layer enables cross-language data serialization and routing, and supports dynamic loading and unloading of different types of applications.

[0036] Specifically, the bridging layer is divided into two functional modules: the first bridging layer and the second bridging layer. These two layers adapt to different operating environments and interaction objects. The first bridging layer is the Python bridging layer, running on the PC, primarily responsible for interacting with the Python application layer and graphical user interface (GUI) on the PC, completing cross-platform message interaction, code loading, and log management. The second bridging layer is the C bridging layer, running in an independent task within the C application layer, primarily responsible for interacting with the underlying hardware driver layer and operating system abstraction layer, implementing hardware emulation and underlying message communication management. The two layers work together to achieve end-to-end data transmission, interface conversion, and functional support from the PC application layer to the underlying hardware. The first bridging layer includes an application layer loader, component bridging, front-to-back board communication bridging, message bridging, and log bridging; the second bridging layer includes operating system abstraction layer bridging, device stubs, and a message queue manager.

[0037] The application layer loader is responsible for dynamically loading and launching the C application layer hardware code. In the PC development environment, this module uses task isolation technology to run the C application layer code in an independent thread or task, isolated from the PC's Python main thread, preventing the entire PC simulation system from crashing due to C code malfunctions. In the embedded real hardware environment, this module loads the C application layer code into an independent Real-Time Operating System (RTOS) task, allowing it to communicate with other tasks through a message queue mechanism, ensuring the independence and stability of the code execution. The component bridging module is crucial for the interaction between PC-side virtual components and the underlying code. This module receives point-to-point control messages from the C application layer's message mailbox (MBOX) in real time and routes them to the corresponding PC-side virtual component based on the target component identifier in the message to perform relevant operations. It also receives publish / subscribe event notification messages from PC-side virtual components and forwards them to the C application layer for processing, achieving bidirectional message communication between the two. The front-to-back board communication bridging module is responsible for communication between the front and back boards of the smart lock using the standardized Operating System Port Protocol (OSPORT). The front board primarily handles user interaction functions such as fingerprint recognition and password input, while the back board handles core control functions such as lock body control and motor drive. This module enables transparent communication between the front and back boards, freeing the application layer from understanding the underlying communication details. The message bridging module handles the serialization, deserialization, and unified routing of various messages. This module supports processing multiple message types, including component messages, OSPORT front-to-back board communication messages, and system log messages, providing a unified message processing interface. In embedded systems, a binary protocol is used for message serialization, improving message transmission efficiency and reducing system memory usage. The log bridging module is responsible for the unified management and output of the entire system logs. It collects all log messages from the C application layer and the Python application layer, performs unified formatting processing on them, and then outputs the formatted logs to the specified log file or the PC console. In the embedded real hardware environment, this module can also output logs through hardware interfaces such as UART and SPI, or store them in Flash storage devices, making it convenient for developers and operations personnel to view the system running status and troubleshoot problems.

[0038] The Operating System Abstraction Layer (OSAL) bridging module provides a bridging implementation of the OSAL interface, including bridging adaptations for basic system functions such as message queues, event handling, and timers. This module uniformly converts OSAL interface calls from the upper-layer C application layer into message queue operations, interacting with the bridging layer through the RTOS's message mechanism. In the embedded real hardware environment, this module directly calls the native mechanisms provided by the RTOS itself, such as message queues, mailboxes, and semaphores, to achieve communication and synchronization between the C application layer and other tasks, freeing the upper-layer code from concern itself with the underlying implementation details of the OSAL interface. The device stub module is the core of PC-side hardware simulation, specifically providing hardware device stub implementations for the PC-side simulation environment. This module accurately simulates the behavior and operating logic of various real hardware devices in smart locks, such as the fingerprint recognition module's recognition process, the unlocking action of the lock body components, and the status detection of the door magnetic sensor. This allows the C application layer's hardware code to run normally on the PC without relying on real hardware devices. When switching to the real hardware environment, this module is replaced by the actual hardware driver, ensuring seamless operation of the C application layer code in both simulation and real environments. The Message Queue Manager module is responsible for the unified management of all message queues between the C application layer and the bridge layer. It is the core of the underlying message transmission management. This module implements message queues using a circular buffer, supports a multi-producer, single-consumer message passing mode, and ensures reliable message transmission. In embedded systems, static memory allocation is used to allocate memory for message queues to avoid memory fragmentation problems caused by dynamic memory allocation, thus ensuring the long-term stability of the system. At the same time, this module provides unified control over the creation, destruction, and message sending and receiving of message queues, ensuring orderly and efficient message interaction between the C application layer and the bridge layer.

[0039] Optionally, the functional component layer is divided into front panel components and rear panel components according to function. The front panel components include fingerprint recognition components, face recognition components, card recognition components, keypad components, audio playback components, and LED indicator components, which are used to receive user input and execute output actions. The rear panel components include lock body control components, motor control components, door magnetic sensor components, battery management components, Bluetooth communication components, and wireless LAN communication components, which are used for lock body control, status monitoring, and network communication.

[0040] The front panel component, as the functional module for direct interaction between the smart lock and the user, integrates fingerprint recognition, face recognition, card recognition, keypad, audio playback, and LED indicator components. Its function is to receive various user inputs and execute corresponding output actions according to system instructions, thereby achieving two-way interaction with the user. The fingerprint recognition component, facial recognition component, card recognition component, and keypad component are input components. They are responsible for collecting the user's fingerprint information, facial information, sensor card information, and password input information, respectively. After preliminary recognition and verification of the collected user input data, the input components convert it into standardized hardware status data and send it to the hardware driver layer. The hardware driver layer then passes it upwards to provide a basis for subsequent unlocking and other business logic processing. The audio playback component and LED indicator component are output components. They do not actively collect user input but receive hardware control data processed by the functional component layer and execute corresponding output actions according to instructions. For example, the audio playback component will issue voice prompts for fingerprint recognition failure, incorrect password input, and successful unlocking according to instructions. The LED indicator component will intuitively display the smart lock's operating status through different on / off and flashing states according to instructions. For example, a flashing red light indicates an incorrect password, a solid green light indicates successful unlocking, and a slow flashing yellow light indicates low battery, allowing users to quickly perceive the smart lock's working status.

[0041] The back panel assembly, as the core control and monitoring module of the smart lock, integrates lock body control components, motor control components, door magnetic sensor components, battery management components, Bluetooth communication components, and wireless LAN communication components. Its function is to complete lock body control, system-wide status monitoring, and various network communications, ensuring the normal operation of the smart lock and enabling remote interaction. The lock body control component and motor control component are control components. The lock body control component receives unlock and lock commands from the system and works in conjunction with the motor control component to control the mechanical movements of the lock body. The motor control component is specifically responsible for driving the lock body's motor, providing power for unlocking and locking. Together, they realize the smart lock's locking and unlocking functions. The door magnetic sensor component and battery management component are status monitoring components. The door magnetic sensor component monitors the door's open / closed status in real time, collecting and uploading data on whether the door is closed or slightly ajar. The battery management component continuously monitors the smart lock's battery level and power supply status. When the battery level falls below a preset threshold, it promptly generates and uploads status data, allowing the system to monitor the status. These two components can monitor the hardware's operating status in real time, and also provide status feedback based on system instructions to ensure the safe operation of the smart lock. The Bluetooth communication component and the wireless LAN communication component are network communication components that handle data transmission between the smart lock and mobile terminals and cloud servers. The Bluetooth communication component mainly enables point-to-point communication between the smart lock and nearby mobile terminals, supporting local password configuration, fingerprint enrollment, status viewing, and other functions. The wireless LAN communication component mainly enables network communication between the smart lock and cloud servers and remote mobile terminals, providing network support for remote monitoring, remote unlocking, remote upgrades, and other functions of the system. Together, they enable the smart lock to achieve dual communication interaction, both local and remote.

[0042] It is understood that although the front panel and rear panel components have different functions, they achieve seamless collaboration through the system's bridging layer and the OSPORT standardized communication protocol. The user input information collected by the front panel component is converted into component event and state change data, which is forwarded to the rear panel component through the OSPORT bridging module of the bridging layer, providing a decision basis for the lock body control of the rear panel component. The state monitoring data and control execution results of the rear panel component are also fed back to the front panel component through the OSPORT protocol, and the audio and indicator light components of the front panel component complete the output display. At the same time, all operations of the front and rear panel components are implemented through the standardized interface of the functional component layer. The components can be flexibly combined and replaced, which greatly improves the scalability and maintainability of the system.

[0043] Optionally, the operating system layer includes the operating system abstraction layer interface, which includes message queue interface, event handling interface, timer interface, and task scheduling interface.

[0044] The operating system abstraction layer interface specifically includes message queue interface, event handling interface, timer interface, and task scheduling interface. Each interface performs its own function, providing corresponding standardized system services to each upper layer. The calling logic and usage specifications of all interfaces are consistent. Upper-layer modules only need to call the interfaces according to the standard to achieve the corresponding functions, without needing to adapt to the native interfaces of different operating systems.

[0045] Specifically, the message queue interface is a standardized interface for message communication between different levels and tasks within the system. This interface encapsulates the native message queue functionality of the underlying RTOS, supporting two core message passing modes: MBOX point-to-point messaging and PUBLISH publish-subscribe messaging. It provides standardized operations such as sending, receiving, registering, and destroying messages for the upper layers. When the upper-layer functional components, bridging layer, and application layer need to communicate between tasks, they do not need to directly manipulate the underlying message queue mechanism; they can simply call the standardized functions of this interface to complete the transmission of various messages, such as control commands and event notifications. This interface also adapts to a circular buffer message storage method, ensuring the reliability of message transmission and preventing data loss. The event handling interface is a standardized interface for synchronization and coordination between tasks. It encapsulates the native functions of the underlying RTOS, such as event flags and event groups, providing standardized operations such as setting, clearing, waiting for, and querying event flags for the upper layers. The timer interface is a standardized interface that provides delay and periodic task execution capabilities to upper layers. It encapsulates the native functions of the underlying RTOS's single-time and periodic timers, providing upper layers with standardized operations such as timer creation, start, stop, destruction, and registration of timer callback functions. The task scheduling interface is a standardized interface for implementing system multi-task management and scheduling. It encapsulates the native scheduling functions of the underlying RTOS, such as task creation, start, pause, termination, and priority modification, providing upper layers with standardized operations for full lifecycle task management.

[0046] The technical solution of this invention solves the problem of software-hardware coupling by shielding hardware differences through a hardware driver layer and completing cross-level data adaptation through a bridging layer. This allows application development to be completely decoupled from the hardware base, and the code can be directly deployed after debugging, improving development efficiency and code reusability. The standardized division of labor and interaction among each layer breaks the high degree of software-hardware coupling in traditional smart lock systems, reducing system integration and maintenance difficulty, improving data transmission efficiency and accuracy, and allowing each layer to be developed, debugged, and upgraded independently. This improves system scalability and development efficiency, providing flexible architectural support for subsequent functional iterations and hardware upgrades.

[0047] Example 2 In Embodiment 2 of the present invention, a task isolation architecture module, a component-based design module, and a working mode selection module are added based on Embodiment 1. Each module is connected to each level for communication.

[0048] Specifically, the smart lock application software simulation system, based on a five-layer distributed architecture, also includes three functional modules: a task isolation architecture module, a component-based design module, and a working mode selection module. All three modules achieve full-level communication connections with the hardware driver layer, functional component layer, bridging layer, operating system layer, and application layer. This provides support for the system from three dimensions: architecture design, functional decomposition, and scenario adaptation. It collaborates with each layer to decouple the application program from the hardware base, improving system stability, scalability, and development flexibility. Specifically, the task isolation architecture module is used for the independent operation and resource isolation of system tasks, the component-based design module is used for the standardized decomposition and flexible combination of functional components, and the working mode selection module adapts to different development and usage scenarios.

[0049] Optionally, the system also includes: a task isolation architecture module, a component-based design module, and a working mode selection module, each of which communicates with each layer; the task isolation architecture module is used to create independent real-time operating system tasks for the application layer, configure independent priorities and stack spaces for the real-time operating system tasks, obtain the task code of the application layer, and run the task code in the real-time operating system task, so that the application layer tasks run in isolation from other system tasks; the component-based design module is used to modularize and standardize the functional component layer, so as to divide the smart lock function into at least one independent functional component.

[0050] Specifically, the task isolation architecture module, based on the RTOS (Real-Time Operating System) and OSAL interface at the operating system layer, creates independent real-time operating system tasks for the application layer. This allows the application layer's business logic to run in a dedicated task environment, achieving complete isolation from other system tasks. After system startup and OSAL system initialization, the task isolation architecture module configures dedicated and independent task priorities and stack space for the created independent RTOS task according to the application layer's development needs and business characteristics. The priority is typically set to a medium level, while the stack space is flexibly allocated based on the application layer task's code volume and data processing requirements, ensuring the normal operation of the application layer task while preventing it from consuming excessive system resources. After task creation and parameter configuration, the module obtains the application layer's task code, loads the code into the independent RTOS task for execution, and simultaneously implements standardized communication between this independent task and other system tasks based on the operating system layer's message queues, event handling, and other mechanisms. The task isolation architecture module allows application-layer tasks to become independent running units. Even if an application-layer task experiences runtime exceptions or crashes due to code issues, it will not affect the operation of other layers such as the hardware driver layer and functional component layer. At the same time, independent priorities and stack space can prevent application-layer tasks from competing for resources and conflicting with other tasks, ensuring the real-time response of high-priority core tasks such as lock body control. In addition, developers can debug this independent application-layer task separately without interfering with the normal operation of other system tasks, which greatly improves the efficiency of development and debugging.

[0051] Specifically, the component-based design module is used for professional modular division and standardized design of functional components. Based on the functional attributes and business logic of the smart lock, the overall function of the smart lock is broken down into at least one independent functional component, ensuring each component assumes a single and clearly defined functional responsibility. When performing modular division, the module adheres to the single responsibility principle, combining the actual usage needs of the smart lock. Front-end user interaction functions are divided into front-panel components such as fingerprint recognition, facial recognition, and keypad components. Back-end lock body control, status monitoring, and network communication functions are divided into back-panel components such as lock body control, motor control, and Bluetooth communication components. Basic functional components such as storage components are also included. Each decomposed functional component is an independent operating unit, with no direct dependencies between components. Based on this modular division, the module standardizes the design of all functional components, defining and implementing unified standardized component interfaces for all components, including component initialization interfaces, message processing interfaces, and status query interfaces. This supports plug-and-play functionality, allowing all components to communicate and interact with other layers and components of the system following the same interface specifications. This module also designs a standardized message communication mechanism for components, supporting both PUBLISH publish-subscribe messaging and MBOX point-to-point messaging modes. This allows components to communicate loosely coupled through the messaging mechanism. Furthermore, the module supports dynamic loading and unloading of components, enabling updates and replacements of functional components without restarting the system. Through this modular division and standardized design, the smart lock's functionality achieves a high degree of modularity. Developers can flexibly combine and match different functional components according to actual needs, quickly customizing the smart lock's functionality. At the same time, the single-responsibility component design makes system maintenance, testing, and upgrades more convenient; modifications or upgrades to a single component will not affect other components or the operation of the entire system, improving the system's scalability and maintainability.

[0052] Specifically, the working mode selection module can select and configure the corresponding working mode for the system based on the actual development needs, testing scenarios, and usage requirements of the developers. Simultaneously, it issues mode configuration commands to each layer, allowing the hardware driver layer, functional component layer, bridging layer, and other layers to adjust their operating logic and interaction methods according to the configured working mode, ensuring stable and efficient system operation in different modes. This module supports the selection and configuration of multiple working modes, including a PC simulation panel selection mode, which allows flexible selection of simulating the front or back panel on the PC, while another panel connects to real hardware for mixed debugging; a master-slave role selection mode, which allows setting the PC as the master or slave to communicate and interact with the real smart lock hardware device; a hardware code simulation mode, which allows enabling or disabling hardware code simulation. When enabled, the system runs hardware C application layer code; when disabled, it runs application layer code implemented in Python on the PC. It also supports a pure PC-side development and testing simulation mode, in which both the front and back panels run on the PC, communicating through a virtual channel without connecting to any real hardware. In this mode, the master role of the front and back panels and the hardware code simulation on / off of the front and back panels can be flexibly configured. After selecting the working mode, this module will synchronize the mode configuration information to each layer. The bridging layer will adjust the message routing and interface conversion logic according to the configuration. For example, in simulation mode, a virtual channel will be enabled to complete front-end and back-end communication. The operating system layer will adjust the task scheduling and resource allocation strategies according to the configuration. The application layer will switch between hardware code simulation mode and PC simulation application layer mode according to the configuration. Each layer will work together according to the mode configuration, allowing the system to adapt to various scenarios such as pure PC development, PC and hardware mixed debugging, and real hardware operation, meeting the needs of different stages such as development, testing, and deployment, and improving the system's development efficiency and usage flexibility.

[0053] Optionally, the working mode selection module includes: a simulation panel selection unit, a master-slave role selection unit, and a hardware code simulation unit.

[0054] Specifically, the simulation panel selection unit enables flexible configuration of the PC-side simulation panel and the actual hardware panel. It primarily manages the hardware simulation selection for the front and rear panels of the smart lock. Developers can use this unit to independently choose to simulate the front or rear panel on the PC, while the other panel connects to the actual smart lock hardware device, enabling a hybrid debugging mode. The master-slave role selection unit configures the master-slave communication relationship between the PC and the actual smart lock hardware device, allowing the PC to flexibly switch between master and slave modes to adapt to different debugging and communication needs. This unit's configuration mainly affects the OSPORT bridging module in the bridging layer and the communication components in the functional component layer. When the PC is configured as a master in this unit, it acts as the initiator and controller of communication, actively sending control commands to the real hardware device and collecting hardware status data. The real hardware device acts as a slave, receiving and executing commands from the PC, while simultaneously feeding back its operating status. When the PC is configured as a slave, the real hardware device acts as the master, autonomously running core functions. The PC only acts as a data receiver and monitor, acquiring real-time operating logs and status data from the hardware device, without actively sending control commands. The hardware code simulation unit controls the switching of the system application layer's operating mode, enabling flexible selection between hardware C application layer code simulation and PC-simulated Python application layer code execution. It is a key unit for enabling application development to be independent of the hardware platform. Its configuration commands primarily affect the application layer loader modules of the application layer and the bridging layer.

[0055] The technical solution of this invention creates independent RTOS tasks for the application layer through a task isolation architecture module, configuring dedicated priorities and stack space. This achieves isolated operation of the application layer from other tasks, preventing single-module malfunctions from affecting the overall system. Simultaneously, secure communication is achieved through message queues, ensuring real-time response for tasks such as lock control. Independent debugging of the application layer is also supported, improving development efficiency. The component-based design module decomposes smart lock functions into independent components based on single responsibility, unifying component interfaces and using standardized message mechanisms for communication. This achieves loose coupling and plug-and-play functionality, supports dynamic loading and unloading, and allows for function updates without system restarts, significantly improving system scalability and maintainability. The working mode selection module supports flexible configuration of multiple modes, including simulation panel, master-slave roles, and hardware code simulation. It adapts to different scenarios such as mixed debugging with PC and real hardware, and pure PC-side simulation development, eliminating dependence on real hardware and improving the flexibility and efficiency of development and testing.

[0056] Example 3 Figure 2This invention provides a schematic diagram of the structure of a smart lock application software simulation system in Embodiment 3. Based on Embodiment 1, this invention adds a visualization development platform 160 that communicates with the application layer, an AI engine 170 that communicates with the visualization development platform, and a remote monitoring and management module that communicates with each level.

[0057] The smart lock application software simulation system, based on a five-layer distributed architecture and various functional modules, is also equipped with two core development support modules: a visual development platform and an AI engine. The visual development platform communicates directly with the application layer, while the AI ​​engine communicates bidirectionally with the visual development platform. In addition, the system includes a remote monitoring and management module, which establishes full-level communication connections with the hardware driver layer, functional component layer, bridging layer, operating system layer, and application layer, enabling remote operation, maintenance, and control of the system.

[0058] Optionally, the system also includes: a visual development platform that communicates with the application layer, and an AI engine that communicates with the visual development platform; the visual development platform is used to obtain user input functional requirements based on a graphical development interface and send the functional requirements to the AI ​​engine; the AI ​​engine is used to parse natural language requirements based on a large language model, generate application code, optimize the application code to generate optimized code, and send the optimized code to the visual development platform; the visual development platform is used to obtain user input editing instructions, edit the optimized code based on the editing instructions, generate the edited optimized code, and send the edited optimized code to the application layer.

[0059] Specifically, the visual development platform serves as the medium for interaction between developers and the system. Relying on a graphical development interface, it provides users with a convenient development environment. The platform presents development modules such as a functional component library, a visual workspace, and a code display area through the graphical interface. Developers do not need to write code; they can simply use visual operations such as dragging and dropping components, building logical connections between components, and setting component parameters to intuitively input the functional requirements of the smart lock on the platform. These requirements include specific business functions such as fingerprint recognition unlocking, three incorrect password attempts to lock, and Bluetooth remote unlocking. The platform will parse and encapsulate the functional requirements, transforming them into requirement data that the AI ​​engine can recognize, and send them to the AI ​​engine in real time, providing a clear requirement basis for subsequent code generation.

[0060] Furthermore, after receiving functional requirement data from the visual development platform, the AI ​​engine, relying on its built-in large language model and dedicated rule and knowledge bases, first performs in-depth analysis of the functional requirements. This analysis identifies the smart lock business logic, functional module combinations, parameter configuration requirements, and other information that developers need to implement. Based on the analysis results, it automatically generates application code adapted to the smart lock system. The generated code not only supports the C and Python code required by the system application layer but also matches the system's component-based design specifications, standardized interface requirements, and message communication mechanisms, ensuring the code runs correctly within the system. After generating the basic application code, the AI ​​engine further optimizes it in multiple dimensions based on historical high-quality code and best practices in smart lock development. This includes streamlining the code structure, improving operational efficiency, optimizing compatibility, and identifying potential bugs. For example, it optimizes the code's execution logic to reduce redundant steps and adjusts parameter configurations to better suit the system's task scheduling mechanism. Finally, it generates optimized application code, which is then fed back to the visual development platform for developers to view and further edit.

[0061] In addition, the AI ​​engine also has an intelligent recommendation function, which can recommend suitable components and configurations based on the user's operation history.

[0062] Specifically, after receiving the optimized code from the AI ​​engine, the visual development platform displays the code in real-time in the platform's code generation area. Simultaneously, based on the code's logic, it reconstructs the corresponding component combinations and connections in the visual workspace, allowing developers to intuitively see the functional implementation logic of the code. At this point, developers can further edit the optimized code on the graphical interface according to their actual development needs. This includes actions such as dragging and dropping to add functional components, modifying logical connections between components, adjusting component parameters, and deleting unnecessary functional code. By inputting specific editing instructions into the platform, the platform translates these instructions into code modification logic, making corresponding edits and adjustments to the optimized code and generating the revised optimized code. It's important to note that developers do not need to manually write code throughout this process; all editing operations are completed through the graphical interface, and the platform automatically updates the code synchronously, ensuring that the revised optimized code fully matches the developers' functional requirements. Once the developers have completed and confirmed the code editing, the visual development platform directly distributes the final revised optimized code to the system's application layer through standardized interfaces between layers. The application layer loader compiles and loads the optimized code and runs it, displaying the code's execution effect. The application layer loader dynamically loads C application layer code via DLLs or directly loads Python application layer code.

[0063] Optionally, the visual development platform allows users to select necessary components via a visual interface, add them to the workspace through drag-and-drop operations, and set connection relationships between components. Component parameters can be set through the visual interface, and the running status and logs of each component can be displayed in real time. Simultaneously, functional debugging can be performed through the visual interface, including setting breakpoints, viewing runtime effects, viewing variables, and viewing logs.

[0064] Optionally, the system may also include: a remote monitoring and management module that communicates with each level; the remote monitoring and management module is used to: obtain system-related status and system operation logs in real time, and display the system-related status and system operation logs to the user, in order to obtain configuration modification commands input by the user, and remotely modify system configuration parameters based on the configuration modification commands, wherein the system-related status includes system operation status and functional component status.

[0065] Specifically, the remote monitoring and management module continuously and accurately collects system-related status and system operation logs through real-time communication with various levels. System-related status includes system operation status and functional component status. System operation logs are obtained from the log bridging module of the bridging layer and include application layer operation logs, functional component work logs, communication logs between levels, and operating system layer system service logs. The remote monitoring and management module structures and visualizes the system-related status and system operation logs, presenting a clear monitoring interface to users via mobile terminals or a web interface. System-related status is displayed using intuitive status indicators and data panels, such as using different colors to indicate normal or abnormal components, real-time display of lock / unlock status and battery level, and real-time task scheduling. System operation logs support categorization and filtering by time range, log level, level, or module, facilitating quick querying and viewing. Through this visual monitoring interface, users can comprehensively and in real-time grasp the overall system operation and promptly identify anomalies, faults, or configuration errors.

[0066] Furthermore, when users discover problems on the monitoring interface or need to adjust system configurations based on actual usage requirements, they can input configuration modification commands on the remote terminal's operation interface. The remote monitoring and management module will acquire these commands in real time, parse them, and identify core information such as the type of system configuration parameters to be modified, the target value to be modified, and the corresponding modification module. System configuration parameters include functional component parameters, such as the sensitivity threshold for fingerprint recognition, the lockout time for incorrect passwords, and the on / off duration of LED indicators; communication parameters, such as the OSPORT protocol baud rate for front and rear board communication, and Bluetooth and Wi-Fi communication connection parameters; and system operating parameters, such as RTOS task priority fine-tuning, working mode configurations for some components, and security parameters. After parsing, the remote monitoring and management module will distribute the configuration modification commands to the corresponding layers and modules based on standardized interfaces. For example, commands to modify component parameters will be distributed to the corresponding components in the functional component layer; commands to modify communication parameters will be distributed to the OSPORT bridging module or communication component in the bridging layer; and commands to modify system operating parameters will be distributed to the operating system layer. Upon receiving the commands, each layer and module will complete the remote modification of the corresponding configuration parameters according to the command requirements.

[0067] Meanwhile, after modifying the configuration parameters, the remote monitoring and management module will collect the relevant system status in real time to verify whether the configuration changes have taken effect. It will then feed back the modification results and effectiveness status to the monitoring interface on the remote terminal for user display. If any anomalies occur during the configuration modification process, the module will immediately record the anomaly log and issue an alarm on the monitoring interface for timely user intervention. Furthermore, this module, in conjunction with the system's hot update mechanism, can provide foundational support for subsequent remote upgrades of application-layer code and component code while completing configuration modifications. This creates a complete closed loop for the remote operation and management of the entire smart lock application software simulation system, further improving the system's usability and operational efficiency.

[0068] The technical solution of this invention provides a visual development platform that supports drag-and-drop component arrangement, real-time preview, and debugging via a graphical interface. Application development can be completed without manual coding, simplifying the development process. Coupled with an AI engine, it can intelligently analyze user functional requirements and automatically generate and optimize application code. It can also intelligently recommend components based on user habits, lowering the development threshold and allowing developers to improve development efficiency and code quality without requiring expertise in multiple language stacks. The remote monitoring and management module supports real-time viewing of system, component, and lock body status via mobile terminals and web interfaces. It allows filtering of operation logs based on conditions, remote modification of system configuration parameters, and hot updates of application and component code without on-site operation or system restart, improving system maintainability and management efficiency. It also enables timely detection of operational anomalies, ensuring stable system operation.

[0069] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0070] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A smart lock application software simulation system, characterized in that, include: The hardware driver layer, functional component layer, bridging layer, operating system layer, and application layer communicate bidirectionally with each other through standardized interfaces. The hardware driver layer is used to obtain hardware status data of the underlying hardware device and send the hardware status data to the functional component layer. The functional component layer is used to generate hardware control data based on the hardware status data, send the hardware control data to the hardware driver layer, generate component events and state change data, and send the component events and state change data to the bridge layer. The bridging layer is used to serialize, route, and interface-convert the component event and state change data, generate converted data, and send the converted data to the application layer.

2. The system according to claim 1, characterized in that, The bridging layer is also used to receive control command data from the application layer, perform deserialization and parsing to generate parsed data, and forward the parsed data to the functional component layer.

3. The system according to claim 1, characterized in that, The operating system layer provides basic system services such as process management, memory management, file management, and task scheduling for the hardware driver layer, functional component layer, bridging layer, and application layer. It also receives system service requests from each layer and feeds back result data to each layer based on the system service requests.

4. The system according to claim 1, characterized in that, The system also includes: a task isolation architecture module, a component-based design module, and a working mode selection module, each module being communicatively connected to each level; The task isolation architecture module is used to create an independent real-time operating system task for the application layer, configure an independent priority and stack space for the real-time operating system task, obtain the task code of the application layer, and run the task code in the real-time operating system task, so that the application layer task runs in isolation from other system tasks. The modular design module is used to modularize and standardize the functional component layer, so as to divide the smart lock function into at least one independent functional component.

5. The system according to claim 4, characterized in that, The working mode selection module includes: a simulation panel selection unit, a master-slave role selection unit, and a hardware code simulation unit.

6. The system according to claim 4, characterized in that, The system further includes: a visualization development platform that is communicatively connected to the application layer, and an AI engine that is communicatively connected to the visualization development platform; The visual development platform is used to obtain the functional requirements input by the user based on the graphical development interface, and send the functional requirements to the AI ​​engine. The AI ​​engine is used to parse natural language requirements based on a large language model, generate application code, optimize the application code to generate optimized code, and send the optimized code to a visual development platform. The visual development platform is used to obtain editing instructions input by the user, edit the optimized code based on the editing instructions, generate the edited optimized code, and send the edited optimized code to the application layer.

7. The system according to claim 1 or 2, characterized in that, The bridging layer includes a first bridging layer and a second bridging layer. The first bridging layer includes an application layer loader, component bridging, front-side and back-side communication bridging, message bridging, and log bridging. The second bridging layer includes an operating system abstraction layer bridging, device stubs, and a message queue manager.

8. The system according to claim 1, characterized in that, The functional component layer is divided into a front panel component and a rear panel component according to their functions. The front panel component includes a fingerprint recognition component, a face recognition component, a card recognition component, a keypad component, an audio playback component, and an LED indicator component, which are used to receive user input and execute output actions. The rear panel component includes a lock body control component, a motor control component, a door magnetic sensor component, a battery management component, a Bluetooth communication component, and a wireless local area network communication component, which are used for lock body control, status monitoring, and network communication.

9. The system according to claim 1 or 3, characterized in that, The operating system layer includes an operating system abstraction layer interface, which includes a message queue interface, an event handling interface, a timer interface, and a task scheduling interface.

10. The system according to claim 1 or 4, characterized in that, The system also includes: a remote monitoring and management module that communicates with each level; The remote monitoring and management module is used to: acquire system-related status and system operation logs in real time, and display the system-related status and system operation logs to the user to obtain configuration modification instructions input by the user, and remotely modify system configuration parameters based on the configuration modification instructions. The system-related status includes system operation status and functional component status.

Images