A ventilator equipment data analysis hybrid architecture running system based on a macOS single-machine running environment

Abstract

The application provides a ventilator equipment data analysis hybrid architecture running system based on a macOS single-machine running environment, comprising front-end master control, secure file access agent, native bridge call and back-end data analysis modules. The system realizes compliant import of peripheral files through a secure scope bookmark mechanism; encapsulates Java analysis logic as a native executable file to solve the problem that JAR cannot run stably in a sandbox; adopts a partition block analysis and CRC check mechanism to automatically complete structured analysis of binary files and medical index calculation; realizes decoupling of the front end and the back end through IPC communication, with the front end only rendering a JSON result to improve security; introduces process life cycle management to prevent resource leakage; and combines x86_64 and arm64 architectures to support single installation package cross-platform running. The system meets the App Store sandbox compliance requirements and builds a stable, secure and deployable single-machine medical data analysis closed loop.

Description

Technical Field

[0001] This application belongs to the field of medical device data parsing technology, specifically relating to a hybrid architecture operating system for ventilator device data parsing based on a macOS standalone operating environment. Background Technology

[0002] As medical devices such as ventilators generate proprietary format data files (e.g., binary files with the .bkp extension) during treatment, which contain treatment parameters, pressure curves, respiratory event records, and basic patient information, clinicians need to legally read, verify the integrity of, parse the structured data, and calculate the indicators through a local client, and then display it in a visual format.

[0003] However, given the application sandboxing mechanism and multi-architecture processor environment of the macOS platform, existing technologies typically employ a front-end / back-end separated desktop application architecture to achieve the above functionality: The front-end interface module is developed using native languages ​​such as Objective-C or Swift to create macOS client applications for file selection, data display, and graphical interfaces.

[0004] The backend data parsing module uses the Java technology stack to develop the data parsing program, and encapsulates the parsing logic into a JAR file.

[0005] During application runtime, a standalone JVM process is started by calling the system command `java -jar xxx.jar`.

[0006] Existing technologies struggle to ensure stable operation of stand-alone applications that include backend parsing engines, specifically due to the following technical issues: 1. Under the constraints of the macOS sandbox, applications cannot stably start the Java Virtual Machine-based backend parsing service using the traditional java -jar method, resulting in the inability to complete structured parsing of professional .bkp binary files; 2. The sandbox file access mechanism imposes strict permission restrictions on external storage devices (such as SD card mount paths) and lacks a unified mechanism for authorization acquisition, path persistence, and secure cross-process access. 3. In the macOS device environment where both Intel and ARM architectures coexist, the backend runtime engine lacks a unified binary encapsulation and adaptive loading mechanism, making it difficult to form a single stable running mode; 4. In hybrid architecture applications consisting of a front-end web interface and a back-end data parsing engine, there is a lack of technical solutions that can achieve controlled bridging between the front-end and back-end, process lifecycle management, and path isolation under sandbox constraints. 5. Existing technologies lack partitioning and block verification and statistical calculation mechanisms for professional .bkp binary data, making it difficult to complete automated calculation and structured output of medical indicators while ensuring data integrity and legality.

[0007] Therefore, there is a need for a single-machine hybrid architecture operation method and system that can stably run the backend parsing engine in the macOS sandbox environment, support legal reading from external storage devices, be compatible with multiple processor architectures, and implement data integrity verification, structured parsing, and secure display, in order to meet the technical requirements of professional offline data parsing and doctor-side display of medical devices such as ventilators. Summary of the Invention

[0008] To address the aforementioned technical issues, this application proposes a hybrid architecture operating system for ventilator device data parsing based on a macOS standalone operating environment. The system includes: The front-end main control module is used to display the user interaction page, read data files from removable storage media, and use the native bridging call module to send the data file content to the back-end data parsing module for data processing; it is also used to receive the result data returned by the back-end data parsing module and complete the dynamic rendering of medical indicators, physiological signal curves and statistical reports. The secure file access proxy module is used to read data files from removable storage media based on macOS security policies. The native bridging module is used to implement cross-process communication between the front-end main control module and the back-end data parsing module; and The backend data parsing module is used to parse, verify, and calculate indicators for the content of data files, and output standardized result data.

[0009] As an improvement to the above system, the front-end main control module builds the user interface based on Vue.js and encapsulates it into a native desktop application using the Electron framework.

[0010] As an improvement to the above system, the secure file access proxy module is implemented based on the secure scope bookmark mechanism provided by macOS.

[0011] As an improvement to the above system, the native bridging call module interacts with the front-end main control module through the inter-process communication interface provided by Electron; the native bridging call module and the back-end data parsing module use JNA to enable the Java layer to directly call the C / C++ native library.

[0012] As an improvement to the above system, it also includes: The lifecycle control module is used to start and stop the backend data parsing module and continuously monitor the health status of the backend data parsing module.

[0013] As an improvement to the above system, the lifecycle control module can start the backend data parsing module in the following ways: by calling an interface or by having the backend data parsing module directly loaded and executed by the Electron main process. The process by which the lifecycle control module continuously monitors the health status of the backend data parsing module is as follows: It actively detects the availability of the backend data parsing module at set time intervals, including: Port liveness check: Confirms whether the local communication port being listened to by the DNS service is open; Data response verification: Send a lightweight heartbeat request to verify whether the backend data parsing module can return a structured response normally; If the detection fails for a set number of consecutive times, the backend data parsing module is deemed to be malfunctioning. When the backend data parsing module is detected to be unresponsive or returns an error status, the following recovery operation is performed: Terminate the current abnormal process; Clean up temporary cache files and memory-mapped resources; Restart the new backend data parsing module instance; The lifecycle control module can exit the backend data parsing module in the following ways: Send a termination signal to the backend data parsing module to request the backend data parsing module to terminate; Wait for the backend data parsing module to complete the current task and release resources; Forcefully clean up any unreleased temporary files.

[0014] As an improvement to the above system, it also includes: Multi-architecture compatibility modules are used to build the system into a universal binary format, making the executable file compatible with both x86_64 and arm64 architectures.

[0015] As an improvement to the aforementioned system, the multi-architecture compatible module uses the lipo tool provided by the macOS SDK to merge the executable files of the x86_64 architecture and arm64 architecture into a single universal binary format.

[0016] Compared with existing technologies, the advantages of this application are: 1. Achieved stable operation of Java backend in sandbox environment, and solved the problem of JAR files failing to start stably in macOS sandbox environment.

[0017] By encapsulating the Java data parsing logic into a native Mach-O executable file, the system recognizes it as a legitimate child process under sandbox control, thus avoiding the problem that the java -jar method cannot run due to path permissions and process model restrictions, and achieving stable execution of the backend parser in the sandbox environment.

[0018] 2. Enables the legal import of professional data files from external storage devices, breaks through the sandbox's access restrictions on external mount paths such as / Volumes, and achieves secure reading of SD card data.

[0019] The Security Scoped Bookmark mechanism is used to obtain the user's authorized path and copy the original .bkp file to the sandbox's allowed access directory, enabling legal cross-process file reading and ensuring that the data import process complies with App Store security specifications.

[0020] 3. The professional .bkp binary data generated by the ventilator is converted into interpretable medical statistics, realizing automatic structured parsing of professional binary data.

[0021] Through a partitioned block parsing mechanism (Header verification, CRC verification, patient information block parsing, treatment parameter block parsing, and event block statistical calculation), the system completes data validity verification, sleep apnea event statistics, and automatic calculation of indicators such as AHI, thereby realizing the automatic conversion of professional data into structured medical indicators.

[0022] 4. It decouples the parsing logic from the display logic, improving the system's operational stability and data processing security.

[0023] The backend outputs structured JSON data, and the frontend is only responsible for displaying it. This avoids the frontend directly participating in binary parsing and reduces the risk of system anomalies from an architectural perspective.

[0024] 5. It enables the front-end to control the operation of the back-end process, preventing abnormal residual processes or resource leaks in the back-end parsing process.

[0025] By recording the PID in the main process, performing heartbeat detection, and implementing an abnormal restart mechanism, the backend parsing program is always kept under control, thus improving the operational reliability of the medical software.

[0026] 6. The same installation package can be run directly on both Intel and ARM architecture devices, achieving unified deployment across architectures.

[0027] By merging multiple architecture binary files into a unified executable file, the backend parser can automatically match the running architecture in different processor environments, thus avoiding version splitting issues.

[0028] 7. A standalone data parsing application that can be successfully packaged, signed, and run stably in the App Store environment has been developed, creating a complete closed loop for sandbox compliance.

[0029] By combining path constraints, process control, and binary encapsulation mechanisms, the entire runtime process complies with the macOS sandbox security policy, forming a legitimate running loop. Attached Figure Description

[0030] Figure 1 The diagram shows the architecture of a hybrid architecture system for data parsing of ventilator equipment based on a macOS standalone operating environment. Detailed Implementation

[0031] The technical solution of this application will be described in detail below with reference to the accompanying drawings.

[0032] This application provides a hybrid architecture operating system for ventilator device data parsing based on a macOS standalone environment. The system's front-end module is implemented using an application framework built on a Web technology stack, including the Vue framework and a component-based development model. The front-end module is encapsulated as a macOS desktop application and runs as the main process, used to implement the user interface, file selection control, and scheduling management of the back-end parsing program. The front-end main process interacts with the back-end data parsing executable program via inter-process communication mechanisms to exchange parameters and receive results.

[0033] The technical solution of this application constructs a "restricted environment-driven layered parsing execution mechanism" in the restricted runtime environment of macOS sandbox. It realizes the legal introduction of data from external devices through a secure file access proxy mechanism; achieves controlled execution of parsing tasks by scheduling native executable parsing programs through the front-end main process; achieves decoupled transmission of parsing parameters and results through cross-process communication and standard input / output mechanisms; achieves efficient processing of complex binary data by calling the underlying high-performance parsing module through a cross-language bridging mechanism; and achieves full-process controllability of the parsing execution process through a lifecycle control mechanism. Thus, a closed-loop data parsing system suitable for sandbox-constrained environments is formed.

[0034] like Figure 1 As shown, the hybrid architecture operating system for ventilator device data parsing based on the macOS standalone operating environment includes: a front-end main control module, a secure file access proxy module, a back-end data parsing module, a native bridging call module, a lifecycle control module, and a multi-architecture compatible module. These modules work together to form a complete technical system.

[0035] 1. Front-end main control module; The front-end control module serves as the core scheduling unit of the entire system, running within the main process of the macOS desktop application. This module builds the user interface using Vue.js and encapsulates it into a native desktop application using the Electron framework, achieving cross-platform compatibility and access to local system resources.

[0036] The front-end main control module mainly undertakes the following core functions: User interface rendering: Responsible for displaying basic patient information and related interactive interfaces; File import control: Manages the reading and import process of data files in local and external storage devices (such as USB flash drives and SD cards); Backend task scheduling: coordinates and triggers backend data parsing tasks to achieve decoupling and asynchronous processing between the frontend and backend; Data reception and visualization: Receives structured result data returned from the backend and dynamically renders medical indicators (such as AHI), physiological signal curves, and statistical reports.

[0037] The front-end main control module establishes a controlled communication channel between the rendering process and the main process through the secure context bridge mechanism provided by Electron. The specific implementation is as follows: (1) File operation capabilities The following local file system interfaces are securely exposed to the rendering layer via a preload script: readLocalFile: Reads a local file within the application's sandbox directory; readUsbFile: Reads the specified file from a USB or SD card device connected to the host. getUsbList: Enumerates the list of currently mounted removable storage devices; copyAllFiles: Batch copy files from external storage devices to the application sandbox directory to meet macOS application sandbox security policy requirements.

[0038] The above interface effectively supports the need to import raw data files from multiple sources, while ensuring compliance with operating system security specifications.

[0039] (2) Task triggering mechanism The front-end constructs a standardized parsing task parameter object (JSON format) based on user actions, containing the following fields: { "filePath":"Path to the original data file", "logPath":"Log output path", "parseMode":"parse mode identifier", "checksumFlag": "Whether to enable checksum verification", "requestId": "Unique request identifier" } Subsequently, through Electron's IPC (Inter-Process Communication) mechanism, the ipcRenderer.invoke('get:dat-data', params) method is called to asynchronously trigger the backend parsing service in the main process to execute the corresponding task.

[0040] (3) Display of results data After the backend task is completed, the structured parsing results are returned to the frontend in JSON format. The frontend receives this data through the encapsulated `getDatData()` JavaScript method and uses it for the following visualization scenarios: Display of AHI (Apnea-Hypopnea Index) values; Dynamic plotting of multi-channel physiological signal curves; Tables and charts present medical statistics such as sleep quality and event distribution.

[0041] This design achieves efficient collaboration between data processing and the user interface, ensuring consistency between system responsiveness and user experience.

[0042] 2. Secure File Access Proxy Module To address the strict restrictions imposed by macOS's application sandboxing mechanism on access to external storage devices, this system designed and implemented a secure file access proxy module. This module enables the secure and compliant import of medical data from removable storage media such as USB flash drives and SD cards, while ensuring compliance with operating system security policies.

[0043] The macOS sandbox environment by default prohibits applications from directly accessing system mount paths (such as / Volumes / *), making it impossible to access data on the user's external storage devices using traditional file reading methods. Forcibly bypassing the sandbox restrictions will trigger a permission denial error, affecting the normal operation of the application and potentially violating App Store review guidelines and medical data processing compliance requirements.

[0044] This module is based on the Security-Scoped Bookmark mechanism provided by macOS. It establishes a persistent and controlled file access channel through user authorization. The specific process is as follows: (1) User-initiated authorization: Call the system's native file selection interface chooseFile() or chooseFilePath() to guide the user to manually select the target directory from the SD card or USB device in Finder.

[0045] (2) Generate security credentials: After the user completes the selection, the system automatically generates an encrypted Security-ScopedBookmark for the selected directory. This bookmark can be used in subsequent sessions to regain access to the directory without having to re-authorize it.

[0046] (3) Initiate controlled data migration: Provided a valid bookmark is available, a data copying task can be initiated using encapsulated local APIs (such as copyAllFiles(), copyBKP(), copyDAT()) to securely migrate the original medical data files (such as .DAT, .BKP, etc. formats) from external storage devices to a dedicated data directory within the application sandbox. ~ / Library / Containers / <bundleidentifier> / Data / This module has the following significant advantages: Legality and Compliance: Fully complies with the macOS Sandbox security model, and access to external storage is granted through explicit user authorization to avoid application crashes or failures to be listed on the App Store due to permission violations; Stable and reliable: Utilizing a system-level bookmark mechanism, it ensures that access to authorized directories can still be restored after the application restarts; Supports standardized import of medical data: Provides a standardized and auditable import path for data files generated by medical devices, meeting the compliance requirements of medical software for data integrity and operational traceability.

[0047] In summary, the secure file access proxy module effectively solves the technical bottleneck of importing external medical data in the macOS sandbox environment, ensuring system security while improving user experience and product compliance.

[0048] 3. Backend data parsing module The backend data parsing module is the core data processing unit of the system. It is dedicated to performing structured parsing, verification, and indicator calculation on professional binary files in .bkp format generated by medical devices, and outputting standardized JSON data for frontend display and analysis.

[0049] This module mainly implements the following four core functions: File structure analysis: Identify and disassemble the internal binary layout of the .bkp file, and extract each logical block; Data integrity verification: Verify that the file has not been tampered with or damaged during transmission or storage using the CRC (Cyclic Redundancy Check) mechanism; Medical indicator calculation: Based on the parsed raw event data, key sleep apnea indicators are calculated according to clinical standards; Structured data output: The processing results are encapsulated into JSON objects in a unified format for front-end calls and visualization.

[0050] The technical implementation process of this module is as follows: (1) Data reading The module receives the file path parameter filePath from the front end and reads the contents of the .bkp file as a binary stream, ensuring efficient loading of large data files with low memory usage.

[0051] (2) File structure parsing Based on the predefined protocol of the .bkp file, the following key information is parsed in block order: Header: File header information, including metadata such as version number and data length; Patient information: Basic information such as patient name, ID, gender, and age; Treatment parameters: Pressure settings, usage duration, and other configurations during CPAP or BiPAP treatment; Respiratory event log: Records detailed timestamps and types of events such as apnea and hypoventilation.

[0052] (3) Verification mechanism A custom CRC checksum algorithm is used to verify data integrity. The calculation formula is as follows: in, This is a preset byte weight sequence. If the verification result does not match, the module will return an error status to prevent invalid or corrupted data from entering subsequent processing.

[0053] (4) Calculation of medical indicators Based on the total number of respiratory events and effective sleep duration analyzed, key clinical indicators are calculated, such as: This indicator is used to assess the severity of sleep apnea-hypopnea syndrome (OSA) and conforms to international diagnostic and treatment standards.

[0054] (5) Output data structure The final parsed result is returned in structured JSON format, containing the following fields: { "patientInfo": { / * Basic patient information * / }, "therapyStats": { / * Treatment parameter statistics * / }, "ahi": 12.3, "eventList": [ / * Time series of respiratory events * / ], "curveData": { / * Sampling data used to plot physiological curves such as pressure and flow rate * / } } The output structure design balances semantic clarity with front-end rendering efficiency, supporting diverse application scenarios such as AHI numerical display, event list browsing, and dynamic drawing of multi-channel physiological curves.

[0055] 4. Native bridging module call The native bridging module aims to achieve efficient and secure cross-process communication between the front-end control module and the back-end data parsing module, building a collaborative processing architecture of "control layer + native execution layer". Through a multi-level communication mechanism, this module effectively decouples business logic from underlying computation, significantly improving overall system performance and maintainability.

[0056] This system adopts a three-tier interaction structure, forming clear boundaries of responsibilities: Front-end layer (Vue rendering process): responsible for user interaction, task parameter construction, and result display; Intermediate coordination layer (Electron main process): As the communication hub, it manages inter-process message routing and the lifecycle of native processes; Native execution layer (C / C++ parser): Handles high-load tasks such as binary file parsing, verification, and index calculation.

[0057] The three components work together through standardized interfaces to form a complete data processing pipeline.

[0058] The native bridging module call technology implementation includes: (1) Electron IPC communication mechanism The front-end layer interacts with the main process through the inter-process communication (IPC) interface provided by Electron: Use ipcRenderer.invoke() to implement asynchronous bidirectional calls, which are used to pass parsing task parameters (such as file paths, verification flags, etc.) and wait for the structured results to be returned; The ipcRenderer.send() function supports one-way status notifications, such as reporting events like task startup, progress updates, or abnormal interruptions.

[0059] This mechanism ensures low-latency, high-reliability communication between the rendering process and the main process.

[0060] (2) Standard input / output pipe communication After the main process starts the native parsing child process, it interacts with it through the operating system-level stdin / stdout pipes: stdin: Writes task configuration parameters in JSON format to the native program; stdout: Reads structured JSON output data from native programs.

[0061] This method has the advantages of strong platform compatibility and low resource consumption, and is suitable for data exchange between cross-language processes.

[0062] (3) JNA native function bridging mechanism (enhanced implementation) In some deployment scenarios, the system further introduces Java Native Access (JNA) to enable direct calls from the Java layer to native C / C++ libraries. The process is as follows: Dynamically load native parsing libraries in .so, .dylib, and .dll formats; Pass the binary data buffer (byte[]) passed from the front end as a parameter to the native function; Native functions perform efficient parsing and CRC check logic; The result is encapsulated into a structure and returned to the Java layer via JNA mapping.

[0063] The advantage of this mechanism is that: Logical decoupling: The upper-level control logic (Java / Vue) is completely separated from the lower-level computational logic (C / C++); Performance optimization: Leveraging the efficient memory manipulation capabilities of C / C++, the parsing of complex binary protocols is significantly accelerated; Reduced call overhead: Avoids frequent process creation and IPC serialization, suitable for high-frequency or real-time scenarios.

[0064] The native bridging module achieves the following core values ​​by integrating multiple communication paradigms such as IPC, standard I / O, and JNA bridging: Decoupling of front-end and back-end: The front-end does not need to care about the underlying parsing details, but only triggers tasks and consumes results through standardized interfaces; Improved parsing performance: Key computations are moved to the native layer, fully leveraging the advantages of C / C++ in numerical computation and memory management; Cross-language interoperability support: Flexible adaptation to Electron (JavaScript), Java and C / C++ multi-language stacks, ensuring the scalability and compatibility of the system in different deployment environments.

[0065] In summary, the native bridging module not only solves the technical challenges of cross-process and cross-language calls, but also builds a high-performance, highly reliable, and easy-to-maintain medical data parsing infrastructure.

[0066] 5. Lifecycle Control Module The lifecycle control module aims to ensure the stability, reliability, and resource security of the backend data parsing module throughout the entire application's operation. This module effectively prevents the continuity and accuracy of medical data processing from being affected by process malfunctions or resource leaks by managing the entire parsing process's startup, monitoring, anomaly recovery, and orderly exit.

[0067] This module mainly implements the following four key functions: Process startup: Securely start the backend data parsing module on demand; Operational status monitoring: Continuously track the health status of the parsing process; Automatic recovery from anomalies: Automatically restarts and cleans up residual state when a process crashes or becomes unresponsive; Safe exit mechanism: Ensures that all system resources are released when the application is closed, avoiding data residue or zombie processes.

[0068] The technical implementation of this module includes: (1) Process startup The module supports two startup methods: The front-end triggers the main process to dynamically start the parsing service by calling the getPort() interface; Alternatively, the Electron main process can directly load and execute a standalone native executable program (such as a parsing engine wrapped in .exe / .dylib).

[0069] The startup process is protected by sandbox permissions and path security checks to ensure that only trusted components are loaded.

[0070] (2) Operational status monitoring The frontend proactively checks the availability of the backend service at fixed time intervals (e.g., every 2 seconds), including: Port liveness check: Confirms whether the local communication port being listened to by the DNS service is open; Data response verification: Send a lightweight heartbeat request to verify whether it can return a structured response normally. If multiple consecutive checks fail, the service is considered abnormal.

[0071] (3) Exception handling mechanism When the parsing process is detected to be unresponsive, crashed, or returning an error status, the module automatically performs the following recovery operations: Terminate the current abnormal process; Clean up temporary cache files and memory-mapped resources; Restart the new parser instance and restore the task queue.

[0072] This mechanism significantly improves the robustness of the system under long-term operation or high-load scenarios.

[0073] (4) Safe Exit Control When a user closes the application (e.g., by clicking the exit button), the frontend calls the exitApp() method, which executes sequentially: Send a SIGTERM signal to the backend parsing process, requesting it to terminate gracefully; Wait for the process to complete its current task and release resources; Force clean up unreleased temporary files (such as intermediate data in the sandbox directory); Finally, it exits the main application process.

[0074] This module has the following beneficial effects: Eliminate zombie processes: Prevent system resource exhaustion caused by process suspension through proactive monitoring and forced recycling mechanisms; Improved system stability: Automatic anomaly recovery capabilities ensure continuous availability of the parsing service without human intervention; Meets medical software compliance requirements: Complies with the specifications for "fault tolerance" and "safe termination" in medical software lifecycle management standards such as IEC 62304, ensuring the integrity of patient data processing and system reliability.

[0075] In summary, the lifecycle control module is not only a "guardian" of system robustness, but also an important technical guarantee for the long-term stable operation of medical-grade software in real clinical environments.

[0076] 6. Multi-architecture compatible module The multi-architecture compatibility module is designed to enable seamless application operation on different macOS hardware platforms, ensuring that the same installer can support Mac devices based on both Intel processors (x86_64) and Apple Silicon chips (arm64). This module effectively solves deployment compatibility issues in heterogeneous hardware environments by building a universal binary.

[0077] The module is implemented in the following ways: The general binary build strategy recommended by Apple is adopted, and the specific process is as follows: Compile separately: Two native executable files are compiled independently for the target architecture: x86_64 architecture version, for Intel Macs; The arm64 architecture version is compatible with Apple Silicon (M1 / M2 / M3, etc.) Macs.

[0078] Merge into universal binary: Using the lipo tool provided by the macOS SDK, the executables of the two architectures mentioned above are merged into a single Universal Binary. This file contains multiple architecture codes internally, but is presented externally as a standard executable program.

[0079] The execution mechanism of the binary files generated by this module includes: When a user launches an application on a macOS device, the operating system kernel automatically identifies the current hardware architecture and loads the matching native code segment from the generic binary for execution: On an Intel Mac, the system loads and runs x86_64 code; On an Apple Silicon Mac, the system loads and runs arm64 code.

[0080] The entire process is completely transparent to the user, requiring no manual selection or installation of different versions.

[0081] This module has the following significant advantages: A single installation package covers all platforms: Regardless of the Mac device used, users can download and install the same application package, greatly simplifying the distribution and update process; Improve deployment and maintenance efficiency: Development and operations teams only need to maintain one set of build artifacts, reducing version management complexity; Meets App Store review requirements: Since 2020, Apple requires all new apps submitted to the Mac App Store to support Apple Silicon. This module ensures that apps comply with platform requirements by providing full arm64 support and a universal binary format.

[0082] In summary, multi-architecture compatibility modules not only ensure the wide applicability of applications within the macOS ecosystem, but also provide users with a consistent and smooth cross-generational device experience, making them an indispensable foundational capability for modern macOS application development.

[0083] The hybrid architecture operating system for ventilator device data parsing based on a macOS standalone operating environment provided in this application has the following advantages: 1. A legitimate access mechanism for external storage devices based on Security Scoped Bookmark; Within the macOS sandbox constraint environment, by generating Security Scoped Bookmark access credentials and combining a data migration strategy of "authorized access + sandbox replication + internal path remapping," the following was achieved: Legitimate access to data on an external SD card; Stable readability in cross-process environments; The data path is transferred from the system's restricted directory to a controlled transfer within the sandbox security domain.

[0084] 2. Native Mach-O executable encapsulation mechanism for Java data parsing logic; The Java data parsing logic is transformed into a Mach-O file that can be directly executed on macOS through native encapsulation, and the runtime dependency environment is embedded in the executable file, thus achieving the following: No need to rely on an external java -jar to start; To avoid the problem of JVM independent processes getting out of control; Meets App Store Sandbox execution guidelines.

[0085] 3. Cross-language bridging call mechanism; By using JNA as a bridge, secure calls between the Java parsing module and the local system libraries are achieved, forming a stable data parsing and execution chain.

[0086] The Java layer is responsible for business logic scheduling, while the local layer is responsible for high-performance binary parsing and verification, forming a collaborative parsing structure of "high-level control + low-level execution".

[0087] 4. Strong control mechanism over the lifecycle of the backend parsing process by the frontend main process; It includes process startup, PID recording, heartbeat detection, abnormal restart, and termination control upon exit, enabling controlled operation of backend processes.

[0088] 5. A structured parsing mechanism for professional binary .bkp files; It includes magic number verification, CRC verification, partition block parsing, and automatic calculation mechanisms for medical statistical indicators, enabling the conversion of professional data into structured data.

[0089] 6. Structured data output and front-end / back-end decoupling mechanism; The backend converts the parsed results into a standard JSON data structure, and the frontend generates a visual Patient Details page based on this structure, thus separating the parsing logic from the display logic.

[0090] 7. Unified executable file generation mechanism across multiple architectures; Executable files for x86_64 and arm64 architectures are generated separately, and then a unified executable program is formed by merging the binary files, enabling a single installation package to run across architectures.

[0091] 8. Hybrid architecture single-machine closed-loop operation model; A hybrid architecture system consisting of "front-end controller + native back-end executable module + secure file access proxy + multi-architecture compatibility mechanism" is constructed to form a complete operating loop in the macOS sandbox environment.

[0092] This application may also provide a computer device, including: at least one processor, memory, at least one network interface, and a user interface. The various components in this device are coupled together via a bus system. It is understood that the bus system is used to implement communication between these components. In addition to a data bus, the bus system also includes a power bus, a control bus, and a status signal bus.

[0093] The user interface can include a display, keyboard, or clicking device. Examples include a mouse, trackball, touchpad, or touchscreen.

[0094] It is understood that the memory in the embodiments disclosed in this application may be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory may be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDRSDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchlink DRAM (SLDRAM), and Direct Rambus RAM (DRRAM). The memories described herein are intended to include, but are not limited to, these and any other suitable types of memory.

[0095] In some implementations, the memory stores elements such as executable modules or data structures, or subsets thereof, or extended sets thereof: operating systems and applications.

[0096] The operating system includes various system programs, such as the framework layer, core library layer, and driver layer, used to implement various basic business functions and handle hardware-based tasks. The application programs include various applications, such as media players and browsers, used to implement various application functions. Programs implementing the methods of the embodiments of this disclosure can be included in the application programs.

[0097] In the above embodiments, the processor can also invoke programs or instructions stored in memory, specifically programs or instructions stored in an application program, for the following purposes: Follow the steps described above.

[0098] The above methods can be applied to or implemented by a processor. The processor may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above methods can be completed by integrated logic circuits in the processor's hardware or by software instructions. The processor can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic diagrams disclosed above. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the disclosed methods can be directly implemented by a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory; the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above methods.

[0099] It is understood that the embodiments described in this application can be implemented using hardware, software, firmware, middleware, microcode, or a combination thereof. For hardware implementation, the processing unit can be implemented in one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers, microprocessors, other electronic units for performing the functions described in this application, or combinations thereof.

[0100] For software implementation, the technology of this application can be implemented by executing the functional modules (e.g., procedures, functions, etc.) of this application. The software code can be stored in memory and executed by a processor. The memory can be implemented in the processor or outside the processor.

[0101] This application may also provide a non-volatile storage medium for storing a computer program. When the computer program is executed by a processor, it can implement the steps in the above method embodiments.

[0102] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application and are not intended to limit it. Although this application has been described in detail with reference to the embodiments, those skilled in the art should understand that modifications or equivalent substitutions to the technical solutions of this application do not depart from the spirit and scope of the technical solutions of this application, and should all be covered within the scope of the claims of this application.< / bundleidentifier>

Claims

1. A hybrid architecture operating system for data parsing of ventilator equipment based on a macOS standalone operating environment, characterized in that, The system includes: The front-end main control module is used to display the user interaction page, read data files from removable storage media, and use the native bridging call module to send the data file content to the back-end data parsing module for data processing; it is also used to receive the result data returned by the back-end data parsing module and complete the dynamic rendering of medical indicators, physiological signal curves and statistical reports. The secure file access proxy module is used to read data files from removable storage media based on macOS security policies. The native bridging module is used to implement cross-process communication between the front-end main control module and the back-end data parsing module; and The backend data parsing module is used to parse, verify, and calculate indicators for the content of data files, and output standardized result data.

2. The hybrid architecture operating system for ventilator device data parsing based on a macOS standalone operating environment as described in claim 1, characterized in that, The front-end main control module is built on Vue.js to create the user interface and is encapsulated into a native desktop application using the Electron framework.

3. The hybrid architecture operating system for ventilator device data parsing based on a macOS standalone operating environment as described in claim 1, characterized in that, The secure file access proxy module is implemented based on the secure scope bookmark mechanism provided by macOS.

4. The hybrid architecture operating system for ventilator device data parsing based on a macOS standalone operating environment as described in claim 1, characterized in that, The native bridging module interacts with the front-end main control module through the inter-process communication interface provided by Electron; the native bridging module and the back-end data parsing module use JNA to enable direct calls from the Java layer to the native C / C++ libraries.

5. The hybrid architecture operating system for ventilator device data parsing based on a macOS standalone operating environment as described in claim 1, characterized in that, Also includes: The lifecycle control module is used to start and stop the backend data parsing module and continuously monitor the health status of the backend data parsing module.

6. The hybrid architecture operating system for ventilator device data parsing based on a macOS standalone operating environment as described in claim 5, characterized in that, The lifecycle control module can start the backend data parsing module in the following ways: by calling an interface or by having the Electron main process directly load and execute the backend data parsing module. The process by which the lifecycle control module continuously monitors the health status of the backend data parsing module is as follows: It actively detects the availability of the backend data parsing module at set time intervals, including: Port liveness check: Confirms whether the local communication port being listened to by the DNS service is open; Data response verification: Send a lightweight heartbeat request to verify whether the backend data parsing module can return a structured response normally; If the detection fails for a set number of consecutive times, the backend data parsing module is deemed to be malfunctioning. When the backend data parsing module is detected to be unresponsive or returns an error status, the following recovery operation is performed: Terminate the current abnormal process; Clean up temporary cache files and memory-mapped resources; Restart the new backend data parsing module instance; The lifecycle control module can exit the backend data parsing module in the following ways: Send a termination signal to the backend data parsing module to request the backend data parsing module to terminate; Wait for the backend data parsing module to complete the current task and release resources; Forcefully clean up any unreleased temporary files.

7. The hybrid architecture operating system for ventilator device data parsing based on a macOS standalone operating environment as described in claim 1, characterized in that, Also includes: Multi-architecture compatibility modules are used to build the system into a universal binary format, making the executable file compatible with both x86_64 and arm64 architectures.

8. The hybrid architecture operating system for ventilator device data parsing based on a macOS standalone operating environment as described in claim 7, characterized in that, The multi-architecture compatible module uses the lipo tool provided by the macOS SDK to merge the executable files of the x86_64 architecture and arm64 architecture into a single universal binary format.

Images