System Service Layer Core Modules

QCloudServer Module

The Pilot QCloudServer module serves as the only official entry point for users to access the Pilot quantum operating system. It exposes secure HTTPS-based API interfaces, ensuring all communications are encrypted and reliable.

• Unified Access Gateway. All user requests—including quantum task submission, status queries, and result retrieval—must be routed through the Pilot cloud service. No other direct access paths to the system are exposed to ensure security and centralized control.

• Request Validation and Security Enforcement. Upon receiving a request, the service validates user identity, API permissions, and request parameters. Malformed, unauthorized, or potentially malicious requests are rejected before reaching core system components.

• Persistent Task Management. Validated requests are persistently stored in the cloud service’s database, including task metadata such as user ID, submission timestamp, task type, and configuration parameters. This enables full lifecycle tracking, auditing, and recovery.

• Secure Internal Scheduling. Tasks and queries are forwarded through secure internal system channels to downstream Pilot modules (such as QCloudServer, OSServerManager) for compilation, scheduling, execution, or status lookup.

• Result Delivery and Status Synchronization. Upon completion, computation results or query responses are relayed back to the cloud service through the same internal channels, and then delivered to users via the HTTPS API—completing the end-to-end workflow.

ComputerServer Module

The ComputerServer module is sits between the PilotOS cloud service layer and the system kernel layer, functioning as a middleware module. Its main purpose is to decouple general but infrequently used computing functions from the core execution flow. This design not only reduces the load on the system kernel but also enhances overall scalability and functional agility.

Currently, the computing service provides the following key capabilities:

• Expectation value evaluation for quantum circuits;

• Full circuit fidelity estimation;

The service adopts a modular architecture consisting of four core components:

• Task preprocessing, which parses incoming task requests, validates input parameters, and generates standardized internal task representations;

• Sub-task unrolling, which automatically decomposes high-level tasks into multiple subtasks that can be executed in parallel or sequentially based on semantic requirements;

• Sub-task execution, which distributes subtasks to underlying quantum or classical computing resources for actual computation;

• Result aggregation, which combines subtask outputs into final user-facing results through normalization, weighting, or statistical fusion.

This framework is designed for easy extensibility, enabling seamless integration of new domain-specific computing functions while maintaining loose coupling with the main Pilot system.

OSServerManager Module

The OSServerManager module serves as the central coordination component within the Pilot system. It communicates with upper-layer applications through a standardized system call interface (SysCall) and is responsible for two key functions: task resource estimation and end-to-end task queue management.

• Task Resource Estimation: Before quantum tasks are queued for execution, OSServerManager performs static analysis on submitted quantum circuits to estimate their resource requirements. This includes: required number of qubits, circuit depth, and number of quantum gates. Based on this analysis, the system determines whether there are sufficient resources to accept the task.

• Task Queue Management: Tasks that pass resource estimation are placed into a unified scheduling queue. OSServerManager continuously tracks the progress of each task in the execution flow and updates its status in real-time. These status updates are immediately pushed to your application, enabling you to understand each stage of task execution with granular detail.

• Persistent Storage of Task Data: After task completion, Pilot automatically persists its data using a hierarchical storage strategy: structured metadata (such as task ID, backend ID, start/end timestamps) is stored in MySQL for efficient querying and monitoring. Large unstructured data (such as complete quantum circuits, raw measurement results) is saved to MongoDB to support flexible access and scalability. This design ensures data reliability and auditability while maintaining the core system’s lightweight nature and responsiveness.

ScheduleServer Module

The ScheduleServer module receives tasks that have passed resource estimation—along with their associated resource requirements—and distributes eligible tasks to the compilation module for processing. By default, the system adopts the Highest Response Ratio Next (HRRN) scheduling strategy, which balances fairness and throughput by determining task priority based on waiting time and estimated execution duration.

Scheduling Workflow:

• Task Enqueueing: After passing resource estimation in OSServerManager, tasks are assigned an initial priority. This value is determined by OSServerManager according to configurable policies (such as task type, user level, or business context)—it is not fixed at zero. The task is then pushed into the scheduler’s priority queue, which is implemented as a max-heap to ensure the task with the highest current response ratio is always at the top.

• Dynamic Priority Updates: The effective scheduling priority of a task is controlled by its response ratio, which increases as the task waits longer in the queue, thereby gaining higher priority over time. This prevents long-waiting tasks from being starved.

• Scheduling Decision Logic: In each scheduling cycle, the system performs the following steps:

  1. Check if the resource requirements of the top-of-heap task can be met by currently available resources.

  2. If resources are sufficient: The task is popped from the queue and forwarded to the compilation module.

  3. If resources are insufficient: No task is dispatched; instead, update the response ratios (priorities) of all queued tasks.

  4. Regardless of the result, refresh the priority queue at the end of the cycle to prepare for the next scheduling event.

QCompileServer Module

Origin PilotOS provides a comprehensive, flexible, and high-performance quantum circuit compilation and optimization framework. This framework abstracts the complexity of underlying quantum hardware, allowing quantum software developers to focus on algorithm design and application innovation—without needing to understand the specific details of different quantum processor architectures.

Primary Advantages:

• Hardware-Agnostic Development: Developers only need to submit standard quantum circuits (e.g., QASM or internal IR). The compiler automatically adapts circuits to the target backend, enabling “write once, run anywhere” across supported quantum hardware platforms.

• Heterogeneous Multi-Backend Support: The current version supports two main quantum computing modalities: superconducting and ion trap processors. Based on the user-specified target backend, the system dynamically selects the appropriate compilation flow to generate fully compatible native instruction sets.

• Parallel Compilation Acceleration: Built on a parallel compilation framework, the service can process multiple tasks concurrently or decompose large circuits into fragments for parallel optimization—significantly improving overall compilation throughput, especially for batch jobs or high-complexity circuits.

Compilation and Optimization Capabilities: The Pilot compiler integrates a suite of advanced optimization algorithms, each encapsulated through standardized, modular interfaces to promote reuse, composition, and future expansion.

Core optimization techniques include: - Multi-controlled gate decomposition - Gate set conversion - Quantum circuit optimization - Qubit mapping and topological routing

ResourceManager Module

The Resource Management module is responsible for receiving resource update notifications from quantum computing backends or resource configuration messages from upper-layer system components. It maintains an up-to-date inventory of available resources and synchronizes this information with other services in the system.

Core Responsibilities:

• Processing Resource Updates and Configuration Requests: Receiving messages about resource changes (such as backend availability, qubit status) or explicit resource configuration commands, and updating the internal resource registry accordingly.

• Serving Resource Information Queries: Responding to requests from other system components, providing current and accurate resource data on demand.

BackendServer Module

The BackendServer module is responsible for managing multiple heterogeneous quantum computing backend units (such as superconducting, trapped ion) and handling the distribution of computing tasks and reception of execution results. As the central communication hub between the Pilot system and underlying quantum control services, this module adopts a hybrid messaging model to balance reliability, real-time responsiveness, and scalability.

Communication Architecture: To meet diverse operational needs, the backend service module integrates two ZeroMQ communication modes when interacting with quantum control services:

1. Router-Dealer Mode (Request-Response Mode)

• Characteristics: Connection-oriented, bidirectional, synchronous request-response.

• Primary Use Cases: Distributing quantum computing tasks to specific backends; receiving task execution results; querying real-time task status; obtaining Randomized Benchmarking (RB) experiment data; exchanging heartbeat signals for link health monitoring and fault detection.

• Advantages: Ensures ordered, reliable message delivery—ideal for critical control commands and result retrieval.

2. Pub-Sub Mode (Publish-Subscribe Mode)

• Characteristics: Connectionless, one-way, asynchronous, event-driven.

• Role: The Pilot backend service acts as a subscriber, continuously listening for broadcast messages from control services.

• Push Events: Typical push events mainly include: proactive task status updates (such as abnormal termination, resource preemption); dynamic changes in chip parameters (such as T1/T2 coherence times, gate fidelities); notifications when automatic calibration routines complete; real-time updates on chip resource availability (such as qubit failures, cooling recovery).

• Advantages: Eliminates polling overhead and enables low-latency event propagation, enhancing system responsiveness.