An integrated system and method for shelter computing

Abstract

The application provides an integrated system and method for shelter computing, receives an adaptation plug-in provided by an external function module, the adaptation plug-in encapsulates private interaction logic of the external function module, loads and runs the adaptation plug-in in an isolated running environment, and instantiates the external function module into one or more standardized services, wherein the standardized service provides calling support for a predefined standard application program interface, and the unified and standardized access to heterogeneous external function modules is realized, various private interfaces and protocols are converted into standard interfaces recognizable in the integrated system, and the interface fragmentation problem is solved. Then, the standardized service is registered in a service directory, and in response to a calling request of other services to the standardized service, data is transmitted between the standardized service and the other services based on the service directory and through at least one standardized inter-service communication protocol. Through the unified communication protocol, the service cooperation problem is solved.

Description

Technical Field

[0001] This application relates to the field of system integration technology, and in particular to an integrated system and method for mobile cabin computing. Background Technology

[0002] With the rapid development of IoT and edge computing technologies, modular integrated computing systems (also known as mobile computing systems) for scenarios such as emergency command, mobile healthcare, and field operations are being used more and more widely. These systems need to integrate multiple functional modules from different vendors, such as energy efficiency management, network communication, and dedicated equipment control, and enable them to work together in resource-constrained and rapidly deployable edge environments.

[0003] However, existing technical solutions face a fundamental technical challenge when integrating such heterogeneous modules: each functional module typically employs proprietary application programming interfaces (APIs), customized communication protocols, and independently defined data formats. When integrating these modules into a unified system platform, developers must write extensive adaptation code or protocol converters for each module requiring interaction, resulting in customized development. This point-to-point, hard-coded integration approach not only generates massive amounts of repetitive custom development work but also leads to highly coupled system architecture and poor adaptability. Consequently, the system integration and compatibility verification cycle becomes excessively long, often accounting for more than 40% of the entire project cycle.

[0004] Therefore, there is an urgent need for a new technical solution that can fundamentally solve the current problem of inefficient and rigid integration. Summary of the Invention

[0005] To address the aforementioned technical problems, this application provides the following technical solutions: Firstly, an integrated system for mobile cabin computing is provided, the system comprising: The interface management module is used to maintain and provide a set of predefined standard application programming interfaces (APIs). A plug-in integration module is used to load and run adaptation plug-ins provided by external functional modules, and instantiate the external functional modules as one or more standardized services. The adaptation plug-ins encapsulate the private interaction logic of the external functional modules and provide support for calling predefined standard application interfaces. The service communication module, coupled to the plug-in integration module, is used to enable the standardized services to interact through the communication protocol based on at least one standardized inter-service communication protocol.

[0006] According to the integrated system for containerized warfare computing provided in this application, if the standardized services interact through the communication protocol, the service communication module is configured to: Register the standardized services to the service catalog; In response to a request from another service to invoke the standardized service, data is transmitted between the standardized service and other services based on the service catalog and a predefined communication protocol.

[0007] According to the integrated system for containerized warfare computing provided in this application, the service communication module is further configured to: When the standardized service transmits data between other services, the transmitted data is a structured data object conforming to one or more predefined data models.

[0008] Secondly, an integrated method for mobile cabin computing is provided, applied to the mobile cabin computing integrated system described in the first aspect, the method comprising: Receive an adapter plugin provided by an external functional module, wherein the adapter plugin encapsulates the private interaction logic of the external functional module; The adapter plugin is loaded and run in an isolated runtime environment, and the external functional module is instantiated as one or more standardized services, wherein the standardized services provide support for calling predefined standard application interfaces; Register the standardized services to the service catalog; In response to a request from another service to invoke the standardized service, data is transmitted between the standardized service and other services based on the service catalog using at least one standardized inter-service communication protocol.

[0009] According to the integration method for modular computing provided in this application, the transmission of data between the standardized service and other services via at least one standardized inter-service communication protocol includes: When transmitting data between the standardized service and other services, the transmitted data is format-validated based on structured data objects of one or more predefined data models. If the transmitted data conforms to a structured data object of one or more predefined data models, then respond to the data; If verification fails, the data will be refused processing and an error response will be returned.

[0010] According to the integration method for modular container computing provided in this application, the step of loading and running the adapter plugin in an isolated operating environment includes: Obtain the container image containing the aforementioned adapter plugin from the remote repository; Create and start a container instance based on the container image; The adapter plugin is run in the container instance.

[0011] According to the integration method for modular container computing provided in this application, before loading and running the adapter plugin in the isolated operating environment, the method further includes: Verify the digital signature and interface compatibility of the adapter plugin. If the verification is successful, load and run the adapter plugin.

[0012] According to the integration method for mobile cabin computing provided in this application, the method further includes: selecting a subset from multiple available standardized services and combining them to form a customized business function combination based on business scenario requirements.

[0013] According to the integration method for modular cabin computing provided in this application, the formation of a customized business function combination includes: The system receives user selection instructions for the standardized services through a graphical interface. A deployment configuration list is generated based on the selection instructions; Deploy the business function combination based on the deployment configuration list.

[0014] Thirdly, a product application is provided for implementing the integrated method for container computing as described in any of the second aspects.

[0015] Fourthly, an electronic device is provided, including a memory, a processor, and an integrated method program for containerized computing stored in the memory and executable on the processor, wherein the processor, when executing the integrated method program for containerized computing, implements the integrated method for containerized computing as described in any one of the second aspects.

[0016] Fifthly, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, performs the integrated method for containerized computing as described in any one of the second aspects.

[0017] The system receives adapter plugins provided by external functional modules, which encapsulate the private interaction logic of these modules. These plugins are loaded and run in an isolated runtime environment, instantiating the external functional modules as one or more standardized services. These standardized services provide support for calling predefined standard application programming interfaces (APIs). This achieves unified and standardized access to heterogeneous external functional modules, converting various private interfaces and protocols into standard interfaces recognizable within the integrated system, thus resolving the interface fragmentation problem. Subsequently, the standardized services are registered in the service directory. In response to calls to the standardized services from other services, data is transmitted between the standardized services and other services based on the service directory and using at least one standardized inter-service communication protocol. This unified communication protocol addresses the issue of insufficient service collaboration.

[0018] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

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

[0020] Figure 1 This is a schematic diagram of the architecture of an integrated system for container computing provided in this application; Figure 2 This is an example interaction diagram of an integrated system for container computing provided in this application; Figure 3 This is a flowchart illustrating an integrated method for modular cabin computing provided in this application; Figure 4 This is another flowchart illustrating an integrated method for modular cabin computing provided in this application; Figure 5 This is a schematic diagram of a computer-readable storage medium provided in this application; Figure 6 This is a schematic diagram of the structure of a computing device provided in this application. Detailed Implementation

[0021] This application describes multiple technical solutions with different concepts. Each concept has one or more embodiments, and these different concepts can be combined to form more embodiments. Those skilled in the art, after reading this application, can combine these different concepts to obtain new technical solutions, and these new technical solutions should also fall within the scope of this application.

[0022] The technical solutions of these different concepts will be introduced in turn below. Some concepts may appear in multiple technical solutions of different concepts. For these concepts, this article will explain them when they first appear and will not repeat them in the following text.

[0023] To address the aforementioned technical problems, this application provides an integrated method for modular container computing.

[0024] The aim is to enable rapid, flexible, and standardized integration of third-party functional modules (or heterogeneous functional modules) without modifying the core system platform, and to enable them to work efficiently with other modules.

[0025] It should be noted that third-party functional modules or heterogeneous functional modules refer to software / hardware modules from different manufacturers and using different technology stacks. They can also be modules from the same manufacturer and using the same technology stack.

[0026] Figure 1 This is a schematic diagram of the architecture of an integrated system for container computing provided in one embodiment of this application.

[0027] The system includes: an interface management module, a plug-in integration module, and a service communication module.

[0028] The interface management module is used to maintain and provide a set of predefined standard application programming interfaces (APIs).

[0029] Currently, methods for system integration in edge micro-data centers, tailored to different business scenarios, suffer from poor architectural adaptability and require significant custom development. This is due to the lack of interface standards. Understandably, the interconnection methods between intelligent computing devices, gigabit network switches, and various sensors in edge computing systems lack a unified software platform interface specification. Most rely on proprietary resource scheduling protocols, making direct integration with third-party energy efficiency management systems impossible, thus necessitating custom development for system integration.

[0030] Based on this, the unified system platform interface standard of the interface management module enables plug-and-play functionality for modules such as network and communication, energy efficiency control, and micro-miniature architecture.

[0031] In some possible implementations, the interface management module includes a software interface standard system and stores and manages metadata for all predefined standard application programming interfaces (APIs) in the software interface standard system, including interface name and version, input / output parameter format, call permission requirements, performance indicator requirements, compatibility rules, and version evolution strategies.

[0032] The software interface standard system includes at least a three-layer interface architecture and corresponding interface design specifications.

[0033] The three-layer interface architecture includes a basic service layer, a business function layer, and an extension plugin layer.

[0034] Specifically, the basic service interface layer provides APIs for system-level functions, including but not limited to Log API, Configuration API, and Auth API.

[0035] The business function interface layer is used to define the APIs of core business capabilities, including but not limited to resource scheduling interface (Resource API), energy efficiency control interface (Energy API), and network management interface (Network API).

[0036] The extended plugin interface layer is used to support third-party feature extensions and define the plugin lifecycle management interface (PluginAPI).

[0037] The interface design specifications include, but are not limited to: adopting a RESTful design style, with URLs named in the format / api / v{version} / {resource} / {action}; using the ProtoBuf data format for transmission; and a unified error code system, defining 100+ standard error types, including error codes, descriptions, and solution suggestions.

[0038] In this embodiment, the basic service interface layer, the business function interface layer, and the extended plug-in interface layer together constitute a unified interface standard, so that different software modules based on this standard can achieve plug-and-play integration.

[0039] The plug-in integration module is used to load and run the adaptation plug-in provided by the external functional module, and instantiate the external functional module as one or more standardized services. The adaptation plug-in encapsulates the private interaction logic of the external functional module and provides support for calling predefined standard application interfaces.

[0040] For the integration of external functional modules, a corresponding adapter plugin needs to be provided. This plugin is responsible for converting the private interface of the external functional module into a standard interface that the system can understand. Then, the adapter plugin will be loaded and run to convert it into an internal standard service.

[0041] The service communication module, coupled to the plug-in integration module, is used to enable the standardized services to interact through the communication protocol based on at least one standardized inter-service communication protocol.

[0042] Current integrated systems also lack a unified communication protocol standard, which can lead to complex protocol conversions during the integration process. Therefore, defining a unified service communication protocol standard in the service communication module is necessary to achieve efficient, low-latency real-time data transmission.

[0043] In some possible implementations, the service communication protocol standard includes at least one standardized inter-service communication protocol. This includes, but is not limited to: For data transmission with high real-time requirements, the first communication protocol is adopted; For non-real-time transactional data transmission, a second communication protocol is adopted; For publish-subscribe communication of IoT devices, a third communication protocol is adopted.

[0044] Furthermore, the first communication protocol is gRPC, which supports bidirectional streaming communication and is used to transmit data with extremely high real-time requirements, such as device emergency status. The second communication protocol is HTTP or HTTPS, which supports asynchronous notification mechanisms and is used for non-real-time daily tasks, such as viewing historical data and issuing configurations. The third communication protocol is MQTT, used for data reporting by a large number of IoT devices, employing a broadcast subscription model. For example, if one sensor publishes data, all devices subscribed to the service can receive the data simultaneously, resulting in relatively high efficiency.

[0045] In some other possible implementations, if the standardized services interact via the communication protocol, the service communication module is configured to: Register the standardized services to the service catalog; In response to a request from another service to invoke the standardized service, data is transmitted between the standardized service and other services based on the service catalog and a predefined communication protocol.

[0046] A service discovery mechanism is set up, based on etcd (Distributed Key-Value Store, commonly used for service discovery and configuration management) to implement service registration and discovery, supporting health checks and automatic failover. In essence, each standardized service registers its corresponding address and capabilities in etcd after startup. Therefore, it can be dynamically discovered during runtime. For example, when other services need to collaborate with it, they can find the standardized service by querying etcd and interact with it through the defined communication protocol.

[0047] In this embodiment, the service metadata in the service discovery mechanism includes at least information such as interface version, supported protocols, and performance metrics.

[0048] In some possible implementations, the service communication module is also configured to: When the standardized service transmits data between other services, the transmitted data is a structured data object conforming to one or more predefined data models.

[0049] Currently, different modules in the integrated system use independent data format definitions, such as CSV for energy efficiency data and JSON for network data. Therefore, complex conversions are required during data fusion, increasing the complexity of data processing.

[0050] Based on this, a data exchange format standard was also set in the service communication module.

[0051] In some possible implementations, the service communication module is also configured to: When the standardized service transmits data between other services, the transmitted data is a structured data object conforming to one or more predefined data models.

[0052] The service communication module defines 12 basic models, including EnergyData, NetworkData, and ResourceState. During data interaction, these models must be formatted according to their corresponding structured formats. For example, JSON Schema is used to automatically validate data during interaction, ensuring data integrity and consistency by verifying the correct format.

[0053] In this embodiment, the request / response format of the data packet uniformly includes three parts: header, body, and metadata. It also supports incremental data synchronization, using timestamps and hash values ​​to verify data consistency.

[0054] In this embodiment, a common data exchange format is used to achieve the fusion of heterogeneous data such as energy efficiency control and network communication.

[0055] Compared to traditional integrated architectures, the above-described integrated system framework for mobile cabin computing offers the following advantages: On the one hand, the adoption of a unified interface standard has reduced the cycle of integrating software modules from different vendors and improved integration efficiency.

[0056] On the other hand, real-time data communication between services is achieved using the gRPC protocol. Compared to the traditional HTTP interface, gRPC uses Protobuf (an efficient binary message format) for serialization, resulting in high compression and a smaller payload. Furthermore, gRPC is designed for HTTP / 2, making it compact and efficient in both sending and receiving, supporting multiplexing, and meeting the real-time requirements of the mobile cabin computing, thus improving system response speed. Simultaneously, the agreed-upon unified communication protocol avoids complex protocol conversions during adaptation, improving system response performance and reducing service interaction complexity, ensuring compatibility between services. Moreover, the standardized data exchange format enables the fusion of heterogeneous data such as energy efficiency control and network communication during data exchange.

[0057] In some possible implementations, a general-purpose mobile cabin business management system can be built based on the framework of the aforementioned integrated system for mobile cabin computing. This management system enables modular management of the entire lifecycle of various business module components, specifically including: Module deployment and version management: Each system module is packaged as a container application image, and version storage and management are carried out in a unified manner through a remote image library. Data management is carried out through persistent storage, which realizes the standardized packaging and version control of software.

[0058] Based on plug-in integrated modules, during deployment, the platform pulls the image and, according to a declarative configuration manifest (such as a Kubernetes YAML file), creates a running instance of the service within the deployment module with a single click. Zero-copy means there's no need to pre-store a large number of software installation packages within the deployment module, achieving decoupling between deployment and software sources. By introducing a remote image repository through the zero-copy deployment mode of the initial configuration manifest, the required images are dynamically pulled from the remote repository during deployment, decoupling system modules from the deployment process and supporting independent installation, activation, updating, or uninstallation of any system module.

[0059] Resource isolation and configuration-based management: The platform allocates an independent running container for each system module instance. Utilizing containerization technologies (such as Docker) and orchestration tools (such as Kubernetes), independent CPU and memory resource limits are allocated to each service instance, achieving resource isolation and preventing interference between modules. In other words, the platform achieves resource isolation for system modules by configuring and managing their resources separately, thereby enabling modular management of the mobile shelter business system.

[0060] Standardized module interaction: Different business modules must meet the interface standards, service communication protocols, and data exchange format standards defined in this solution, and the platform supports configurable management. Typical system modules include a streamlined kernel, monitoring system, log service, operation and maintenance center, configuration center, and system authorization, etc. Based on this, business modules suitable for specific business scenarios can be flexibly configured.

[0061] Furthermore, the mobile hospital business management system software platform adopts interactive one-click deployment technology based on a graphical interface. Through the graphical configuration interface, the complex business details inside the mobile hospital are ignored. Administrators can perform resource configuration, parameter optimization and other operations on different modules by dragging and clicking, so as to realize fine-grained configuration management and rapid deployment of mobile hospital services, which greatly reduces the operation and maintenance threshold.

[0062] Within this management system, users can flexibly select and combine required modules from the module repository to quickly build customized mobile cabin service instances based on the needs of specific business scenarios (such as mobile smart healthcare and emergency command). The platform supports the tailoring of business functions; for example, it can build a minimal deployment package containing only a streamlined kernel, core monitoring, and security authentication to meet the needs of field operations with extremely limited resources.

[0063] It's understandable that the applications in the platform refer to Deployments within the cluster. Depending on the specific scenario, several applications can be packaged into specific services. Furthermore, services can be tailored according to their functionalities. For example, in a minimized functionality scenario, the service contains only the core applications, thus requiring minimal resources to provide the essential functionality; conversely, in a fully functional scenario, the service contains the most comprehensive applications, requiring more resources but providing the most complete and complete functionality. Based on this, related services can be further packaged into modular units, which can then be deployed to a data center to provide services for specific real-world scenarios.

[0064] As an example, based on the framework of the integrated system for mobile cabin computing and the general mobile cabin business management system, a mobile smart medical cabin can be quickly built.

[0065] In this scenario, the interface standard system proposed in this application enables seamless integration of multiple devices. For example, the 5G+AR ward round system commonly found in this type of mobile hospital adopts a three-layer architecture design. Basic service interfaces: integrate Log API and Auth API to enable automatic identification and operation auditing of medical staff.

[0066] Business function interface: Dynamically allocate resources such as CT equipment and ECG monitors through the resource scheduling interface (Resource API) to achieve flexible allocation of business resources.

[0067] Extended plug-in interface: Supports the development of dedicated medical device plug-ins to adapt to different manufacturers, enabling plug-and-play use of various specialized equipment such as blood gas analyzers and ventilators.

[0068] Furthermore, by applying the data exchange format standard of this application, the following can be achieved: JSON Schema is used to define multiple types of detection data models to achieve a unified representation of sample information, detection results, and device status.

[0069] The incremental data synchronization mechanism reduces the data synchronization delay between the makeshift hospitals and the disease control / medical headquarters.

[0070] Through the above embodiments, this system framework not only defines a set of standards but also provides a set of executable and manageable engineering practices, supporting the entire process from module development, integration, deployment to operation and maintenance, ultimately forming a deployable and operational mobile cabin business system. A plug-in framework enables heterogeneous modules to be compliant with standard services, protocols and discovery mechanisms achieve dynamic service collaboration, data models unify information semantics, and finally, containerization, orchestration, and visual deployment tools encapsulate this system, enabling cloud-platform-like boundary and standard software delivery and operation and maintenance capabilities even in edge scenarios like mobile cabins. (Refer to...) Figure 2 The modular shelter subsystem 1 and modular shelter subsystem 2 generated through the above system framework are integrated and interact with each other through the established specifications.

[0071] On the other hand, compared with the problems of repetitive, disordered and high-cost customization development in traditional integration, this application effectively solves the chaotic customization requirements through unified rules, and ultimately reduces the overall integration workload.

[0072] This application provides an embodiment of an integrated method for modular cabin computing, referring to... Figure 3 , Figure 3 This is a flowchart illustrating an integration method for containerized computing provided in an embodiment of this application. It should be noted that the integration method for containerized computing described in this application is applied to an integrated system for containerized computing.

[0073] Specifically, this includes the following steps 101 to 102: Step 101: Receive the adapter plugin provided by the external functional module, wherein the adapter plugin encapsulates the private interaction logic of the external functional module.

[0074] Equipment manufacturers or integrators, based on the plugin development specifications set by the interface management module of the integrated system, write corresponding adapter plugins. These adapter plugins encapsulate the device-specific interaction logic. Within these plugins, at least one standard API defined in the business function interface layer is implemented. Receiving an adapter plugin means the system has obtained this software package encapsulating private logic.

[0075] Specifically, the plugin, its configuration file, and a file describing the plugin's metadata are encapsulated. Operations personnel can then upload the plugin package through the system's graphical one-click deployment interface.

[0076] For example, taking the integration of a new non-standard medical device (such as a blood gas analyzer) into a smart medical mobile unit as an example, the blood gas analyzer manufacturer, based on the published plug-in development specifications, writes a blood gas analyzer driver plug-in. This plug-in encapsulates the device's proprietary USB / TCP communication logic. Within the plug-in, the command to start the detection can be mapped to a private instruction that calls the device, and the detection results can be encapsulated into data in the standard DeviceData model. After encapsulation and packaging, this data is uploaded to the mobile unit's business management system.

[0077] In some possible implementations, the system verifies the signature to ensure security, parses metadata, and checks interface compatibility and resource requirements. The plugin is then dynamically loaded into a separate, resource-isolated container. Finally, the plugin's lifecycle management API is invoked to activate it.

[0078] Based on this, for the mobile hospital business management system, this blood gas analyzer is no longer a proprietary device, but a service that provides a standard DeviceData API, which enables it to be used as an external functional module in a plug-and-play manner.

[0079] Step 102: Load and run the adaptation plugin in an isolated runtime environment, and instantiate the external functional module as one or more standardized services, wherein the standardized services provide support for calling predefined standard application interfaces.

[0080] The system first places the received adapter plugins in an isolated runtime environment (such as a container, sandbox, or independent process). This ensures that the operation of the plugins does not affect other parts of the system and also provides resource limits and security.

[0081] Next, the system loads and runs the adapter plugin. During runtime, the adapter plugin establishes connections with external functional modules (e.g., through the device's proprietary protocol) and provides an implementation of a predefined standard application programming interface (API). In this way, external functional modules are instantiated as one or more standardized services, which other services can then call through the standard API.

[0082] In some possible implementations, loading and running the adapter plugin in an isolated runtime environment includes: Obtain the container image containing the aforementioned adapter plugin from the remote repository; Create and start a container instance based on the container image; The adapter plugin is run in the container instance.

[0083] First, the system pulls the adapter plugin, packaged as a container image, from a remote repository. This image employs a layered structure, packaging the plugin code, runtime environment, and dependent libraries into a standard format, and ensuring its integrity and security through content addressing and digital signatures. Next, a container instance is created and started based on this image. Linux kernel namespaces and control groups are used to isolate and restrict resources such as processes, networks, and file systems, providing the plugin with an independent sandbox environment. Finally, the adapter plugin runs inside the container. After initialization, the plugin connects to external devices or services, converts its private protocols and data formats to a platform-defined standard interface, and registers it in the service directory, enabling other services to discover and invoke it in a unified manner.

[0084] In some possible implementations, the method further includes, prior to loading and running the adapter plugin in an isolated runtime environment: Verify the digital signature and interface compatibility of the adapter plugin. If the verification is successful, load and run the adapter plugin.

[0085] Before loading and running the adaptation plugin, the plugin package's hash value is signed and verified to confirm its trustworthy origin and lack of tampering during transmission, thus preventing malicious code injection. Furthermore, by checking the plugin's declared interface version, dependent services, and resource requirements and comparing them with the platform's currently supported standards, it is ensured that the plugin can interact correctly with other components in the system, avoiding runtime failures caused by interface incompatibility or resource conflicts.

[0086] These two layers of verification together form a dual guarantee for secure plugin access. Only plugins that pass all verifications can enter the subsequent containerized loading process, ensuring the stability and trustworthiness of the integration environment from the source, and guaranteeing the portability, security and resource controllability of plugins, thus providing a foundation for achieving plug-and-play integration.

[0087] Step 103: Register the standardized service to the service catalog.

[0088] When the standardized service corresponding to the adaptation plugin is started, it will automatically register with the system's built-in etcd service registry. Registration information includes, but is not limited to, the standardized service's name, version, network address, provided standard interface (DeviceData API), and communication protocol (such as the gRPC port). This allows other services in the system to discover the new service by querying the service directory. Service registration is fundamental to service discovery; it decouples service calls, allowing the caller to locate the callee without needing to know its exact location, simply by searching the service directory.

[0089] Continuing with the blood gas analyzer example above, when the central monitoring system needs to read blood gas data, it queries etcd for relevant information about the DeviceData API to obtain the address of the plugin service corresponding to the blood gas analyzer.

[0090] This embodiment provides a communication channel for the standardized service instance and maintains a service registration and discovery mechanism so that the standardized service instance can be discovered and invoked.

[0091] Step 104: In response to a call request from another service to the standardized service, data is transmitted between the standardized service and other services based on the service catalog using at least one standardized inter-service communication protocol.

[0092] When another service in the system (referred to as the caller) needs to invoke this standardized service, it first queries the service registry's service directory to obtain the location and interface information of the standardized service. Then, the caller initiates a request to the standardized service using a predefined standardized inter-service communication protocol (such as gRPC, HTTP / REST, MQTT, etc.). Upon receiving the request, the standardized service uses an adapter plugin to convert it into a private call to an external functional module, obtains the result, converts it back to the standard format, and returns it to the caller via the communication protocol. Throughout this process, the data transmission format, serialization method, and error handling all adhere to system-defined standards, thereby ensuring interoperability between different services.

[0093] In some possible implementations, the transmission of data between the standardized service and other services via at least one standardized inter-service communication protocol includes: When transmitting data between the standardized service and other services, the transmitted data is format-validated based on structured data objects of one or more predefined data models. If the transmitted data conforms to a structured data object of one or more predefined data models, then respond to the data; If verification fails, the data will be refused processing and an error response will be returned.

[0094] Data exchange is governed by predefined data models (structured data objects), establishing data format rules that all transmitted data must conform to for processing. The verification process compares actual data with the field types, structural relationships, and constraints defined in the model to ensure data integrity and semantic correctness. When data conforms to the model, the system responds and processes it normally; when verification fails, the system immediately rejects the data and returns a clear error response, preventing erroneous or malicious data from entering subsequent processing. This mechanism not only guarantees data interoperability between heterogeneous services but also improves the overall stability and maintainability of the system through a fail-fast principle, achieving data fusion.

[0095] Continuing with the blood gas analyzer example, the platform has predefined core data models such as MedicalTestData, using JSON Schema files to precisely describe fields (e.g., patientId, testItem, value, unit, timestamp). Before sending data, the blood gas analyzer plugin must encapsulate the raw data into a JSON object conforming to the MedicalTestData model structure. Furthermore, when sending or receiving data, the format validity is automatically verified by a JSON Schema validator. Valid data flows through the message bus with a unified header / body / metadata structure.

[0096] In this embodiment, with a unified data format, the data analysis module subscribes to these standard format data streams, enabling seamless correlation analysis of blood gas data, electrocardiogram data from another standard plug-in, and EnergyData from air conditioning, generating a comprehensive diagnostic and treatment environment report. This achieves seamless integration of cross-domain heterogeneous data, providing possibilities for intelligent decision-making.

[0097] In some possible implementations, the method further includes: selecting a subset of available standardized services and combining them to form a customized combination of business functions, based on business scenario requirements.

[0098] In some possible implementations, the formation of a customized business function combination includes: The system receives user selection instructions for the standardized services through a graphical interface. A deployment configuration list is generated based on the selection instructions; Deploy the business function combination based on the deployment configuration list.

[0099] When users combine services through clicking, dragging, or other methods, the system generates a structured deployment configuration manifest (such as Kubernetes YAML or Terraform HCL) in real time. This manifest precisely describes the selected services, their versions, dependencies, and resource constraints. Ultimately, the system automatically executes the deployment process based on this manifest, including scheduling computing resources, pulling service images, and configuring network policies, transforming the user's abstract business intent into a concrete, runnable system instance. This process employs interactive one-click deployment technology based on a graphical interface, achieving agility and customization capabilities for different business scenarios, and enabling rapid deployment of relevant business services.

[0100] Based on the above embodiments, referring to Figure 4 , Figure 4 This is another flowchart illustrating an integrated method for mobile cabin computing provided in this application. It presents an embodiment of a mobile cabin system construction and deployment pipeline, utilizing standardized modules to quickly build a mobile cabin system that meets the needs of a specific scenario.

[0101] The specific process is as follows: Step 1: Image Management.

[0102] External functional module manufacturers or developers prepare corresponding adaptation plugins, i.e., standardized functional modules, based on the specifications (including interface standards, communication protocols, and data format standards) set for the integrated system for modular computing. These adaptation plugins can be obtained by directly uploading the external functional module's image to an image repository, or by generating an image from the application created in the development environment and then uploading it to the image repository. During this process, images can be pulled, deleted, and managed.

[0103] By using image management, application modules that conform to interface standards, communication protocols, and data format standards are stored in the repository as images, ensuring that the versions of all modules are traceable and manageable, and facilitating subsequent calls.

[0104] Step 2: Application Management.

[0105] Obtain application images from the image repository, create ready-to-use application instances, and perform operations such as updating and deleting applications, for example, creating log service applications and energy efficiency control applications.

[0106] By converting the image into a usable functional module, we prepare for subsequent business integration.

[0107] Step 3: Business Management.

[0108] Depending on the specific scenario requirements, multiple applications can be added together to form a business, such as combining resource scheduling applications, network management applications, and energy efficiency control applications into a resource optimization business.

[0109] It also supports tailoring business functions, such as minimizing the functionality to retain only the core application, or including all related applications in the most complete functionality. Understandably, this combination assumes that all applications adhere to a unified standard, requiring no additional adaptation.

[0110] By combining functional modules on demand, lightweight customization of business functions can be achieved to meet the needs of different scenarios.

[0111] Step 4: Management of the makeshift hospital.

[0112] Multiple business units can be combined into a modular system with clearly defined roles and collaborative operations. For example, resource optimization, security authentication, and data synchronization can be combined into an industrial IoT modular system. Another example is combining medical monitoring, energy management, and network communication into a mobile smart healthcare modular system. Simultaneously, the system's resources can be intelligently analyzed, such as calculating the required servers and network bandwidth.

[0113] By integrating multiple business operations, a complete mobile hospital system is formed, while managing the overall resources of the mobile hospital.

[0114] Step 5: Create a virtual cluster.

[0115] Based on the resource requirements of the makeshift hospital, a virtual cluster is created to provide the basic resources necessary for its operation, ensuring sufficient and isolated resources. These basic resources include, but are not limited to, virtual servers, networks, and storage.

[0116] Virtual clusters enable flexible allocation and isolation of resources, ensuring that different mobile shelters do not interfere with each other.

[0117] Step 6: Deploy a mobile cabin example.

[0118] The assembled modular units are deployed to designated data centers (which can be multiple data centers such as Data Center I, Data Center II, etc.). The modular unit instances run on a virtual cluster to provide services for specific scenarios.

[0119] The configuration and business modules of the mobile cabin are deployed to the actual operating environment, realizing the transformation from combined design to practical application.

[0120] The seventh step is to deploy the modular shelter instances to provide services for specific scenarios.

[0121] This application provides an integrated system and method for modular container computing, which has the following advantages compared with the current rigid integration mode that leads to low integration efficiency: The system receives adapter plugins provided by external functional modules, which encapsulate the private interaction logic of these modules. These plugins are loaded and run in an isolated runtime environment, instantiating the external functional modules as one or more standardized services. These standardized services provide support for calling predefined standard application programming interfaces (APIs). This achieves unified and standardized access to heterogeneous external functional modules, converting various private interfaces and protocols into standard interfaces recognizable within the integrated system, thus resolving the interface fragmentation problem. Subsequently, the standardized services are registered in the service directory. In response to calls to the standardized services from other services, data is transmitted between the standardized services and other services based on the service directory and using at least one standardized inter-service communication protocol. This unified communication protocol addresses the issue of insufficient service collaboration.

[0122] Figure 5 This is a schematic diagram of a computer-readable storage medium 140 provided in this application, on which a computer program is stored, which, when executed by a processor, implements the method of any embodiment of this application.

[0123] This application also provides a computing device, including a memory and a processor; the memory is used to store computer instructions that can be executed on the processor, and the processor is used to implement the method of any embodiment of this application when executing the computer instructions.

[0124] Figure 6 This is a schematic diagram of the structure of a computing device provided in this application, such as... Figure 6 As shown, the computing device 15 may include, but is not limited to: a processor 151, a memory 152, and a bus 153 connecting different system components (including the memory 152 and the processor 151).

[0125] The memory 152 stores computer instructions that can be executed by the processor 151, enabling the processor 151 to perform the training method of the aesthetic image generation model according to any embodiment of this application. The memory 152 may include a random access memory unit (RAM) 1521, a cache memory unit (Cache) 1522, and / or a read-only memory unit (ROM) 1523. The memory 152 may also include a program tool 1525 having a set of program modules 1524, which includes, but is not limited to, an operating system, one or more application programs, other program modules, and program data. One or more combinations of these program modules may include an implementation of a network environment.

[0126] Bus 153 may include, for example, a data bus, an address bus, and a control bus. The computing device 15 can also communicate with external devices 155 via I / O interface 154, such as a keyboard or a Bluetooth device. The computing device 15 can also communicate with one or more networks via network adapter 156, such as a local area network (LAN), a wide area network (WAN), or a public network. As shown in the figure, the network adapter 156 can also communicate with other modules of the computing device 15 via bus 153.

[0127] Furthermore, although the operations of the method of this application are described in a specific order in the accompanying drawings, this does not require or imply that these operations must be performed in that specific order, or that all the operations shown must be performed to achieve the desired result. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0128] While the spirit and principles of this application have been described with reference to several specific embodiments, it should be understood that this application is not limited to the disclosed specific embodiments, and the division of aspects does not imply that features in these aspects cannot be combined for benefit; such division is merely for convenience of expression. This application is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.

Claims

1. An integrated system for computing in mobile cabins, characterized in that, The system includes: The interface management module is used to maintain and provide a set of predefined standard application programming interfaces (APIs). A plug-in integration module is used to load and run adaptation plug-ins provided by external functional modules, and instantiate the external functional modules as one or more standardized services. The adaptation plug-ins encapsulate the private interaction logic of the external functional modules and provide support for calling predefined standard application interfaces. The service communication module, coupled to the plug-in integration module, is used to enable the standardized services to interact through the communication protocol based on at least one standardized inter-service communication protocol.

2. The integrated system for modular container computing as described in claim 1, characterized in that, If the standardized services interact via the communication protocol, the service communication module is configured to: Register the standardized services to the service catalog; In response to a request from another service to invoke the standardized service, data is transmitted between the standardized service and other services based on the service catalog and a predefined communication protocol.

3. The integrated system for modular container computing as described in claim 2, characterized in that, The service communication module is also configured to: When the standardized service transmits data between other services, the transmitted data is a structured data object conforming to one or more predefined data models.

4. An integrated method for mobile cabin computing, characterized in that, The method, applied to the integrated system for containerized warfare computing as described in claim 1, comprises: Receive an adapter plugin provided by an external functional module, wherein the adapter plugin encapsulates the private interaction logic of the external functional module; The adapter plugin is loaded and run in an isolated runtime environment, and the external functional module is instantiated as one or more standardized services, wherein the standardized services provide support for calling predefined standard application interfaces; Register the standardized services to the service catalog; In response to a request from another service to invoke the standardized service, data is transmitted between the standardized service and other services based on the service catalog using at least one standardized inter-service communication protocol.

5. The integrated method for modular container computing as described in claim 4, characterized in that, The transmission of data between the standardized service and other services via at least one standardized inter-service communication protocol includes: When transmitting data between the standardized service and other services, the transmitted data is format-validated based on structured data objects of one or more predefined data models. If the transmitted data conforms to a structured data object of one or more predefined data models, then respond to the data; If verification fails, the data will be refused processing and an error response will be returned.

6. The integrated method for modular container computing as described in claim 4, characterized in that, The process of loading and running the adaptation plugin in an isolated runtime environment includes: Obtain the container image containing the aforementioned adapter plugin from the remote repository; Create and start a container instance based on the container image; The adapter plugin is run in the container instance.

7. The integrated method for modular container computing as described in claim 6, characterized in that, Before loading and running the adapter plugin in the isolated runtime environment, the method further includes: Verify the digital signature and interface compatibility of the adapter plugin. If the verification is successful, load and run the adapter plugin.

8. The integrated method for modular container computing as described in claim 4, characterized in that, The method further includes: selecting a subset from multiple available standardized services and combining them according to business scenario requirements to form a customized business function combination.

9. The integrated method for modular container computing as described in claim 8, characterized in that, The formation of customized business function combinations includes: The system receives user selection instructions for the standardized services through a graphical interface. A deployment configuration list is generated based on the selection instructions; Deploy the business function combination based on the deployment configuration list.

10. An electronic device, characterized in that, The system includes a memory, a processor, and an integrated method program for containerized computing stored in the memory and executable on the processor. When the processor executes the integrated method program for containerized computing, it implements the integrated method for containerized computing as described in any one of claims 4 to 9.

Images