文档中心
系统服务层核心模块¶
QCloudServer 模块¶
Pilot QCloudServer 模块作为用户访问 Pilot 量子操作系统的唯一官方入口。它暴露了安全的基于 HTTPS 的 API 接口，确保所有通信都是加密且可靠的。
统一访问网关。 所有用户请求——包括量子任务提交、状态查询和结果获取——必须通过 Pilot 云服务路由。不暴露其他直接访问系统的路径，以确保安全性和集中控制。
请求验证与安全强制。 收到请求后，服务会验证用户身份、API 权限和请求参数。格式错误、未授权或潜在的恶意请求将在到达核心系统组件之前被拒绝。
持久化任务管理。 验证通过的请求将持久存储在云服务的数据库中，包括任务元数据，如用户 ID、提交时间戳、任务类型和配置参数。这实现了全生命周期的跟踪、审计和恢复。
安全内部调度。 任务和查询通过安全的内部系统通道转发至下游 Pilot 模块（如 QCloudServer, OSServerManager）进行编译、调度、执行或状态查找。
结果交付与状态同步。 完成后，计算结果或查询响应通过相同的内部通道中继回云服务，然后再通过 HTTPS API 交付给用户——完成端到端工作流。
ComputerServer 模块¶
ComputerServer 模块位于PilotOS云服务层和系统内核层之间，作为一个中间件模块。其主要目的是将通用但不常用的计算功能从核心执行流程中解耦。这种设计不仅减轻了系统内核的负载，还增强了整体的可扩展性和功能敏捷性。
目前，计算服务提供以下关键能力： - 期望值评估 用于量子线路； - 全线路保真度估计；
该服务采用模块化架构，由四个核心组件组成： - 任务预处理， 解析传入的任务请求，验证输入参数，并生成标准化的内部任务表示； - 子任务展开 ，根据语义要求，自动将高级任务分解为多个可并行或顺序执行的子任务； - 子任务执行， 将子任务分发到底层量子或经典计算资源进行实际计算； - 结果聚合， 通过归一化、加权或统计融合将子任务输出组合成最终面向用户的结果。
该框架设计用于易于扩展，能够在保持与主 Pilot 系统松耦合的同时，无缝集成新的特定领域计算功能。
OSServerManager 模块¶
OSServerManager 模块作为 Pilot 系统内的中央协调组件。它通过标准化的系统调用接口 (SysCall) 与上层应用通信，负责两个关键功能：任务资源预估和端到端任务队列管理。
任务资源预估: 在量子任务排队执行之前，OSServerManager 对提交的量子线路进行静态分析以预估其资源需求。这包括：所需量子比特数、线路深度、量子门数量。基于此分析，系统确定当前是否有足够的资源来接受该任务。
任务队列管理: 通过资源预估的任务被放入统一的调度队列。OSServerManager 持续跟踪每个任务在执行流程中的进度并实时更新其状态。这些状态更新会立即推送给您的应用程序，使您能够细粒度地了解任务执行的每个阶段。
任务数据的持久化存储: 任务完成后，Pilot 自动使用分层存储策略持久化其数据：结构化元数据（如任务 ID、后端 ID、开始/结束时间戳）存储在 MySQL 中以进行高效查询和监控。大型非结构化数据（如完整量子线路、原始测量结果）保存到 MongoDB 中以支持灵活访问和扩展。这种设计确保了数据的可靠性和可审计性，同时保持核心系统的轻量级和响应速度。
ScheduleServer 模块¶
ScheduleServer 模块接收已通过资源预估的任务——连同其关联的资源需求——并将符合条件的任务分发给编译模块进行处理。默认情况下，系统采用最高响应比优先 (HRRN) 调度策略，该策略通过基于等待时间和预估执行时长来确定任务优先级，从而平衡公平性和吞吐量。
调度工作流：
任务入队: 任务在 OSServerManager 中通过资源预估后，会被分配一个初始优先级。该值由 OSServerManager 根据可配置策略（如任务类型、用户等级或业务上下文）确定——它不是固定为零。然后任务被推入调度器的优先级队列，该队列实现为最大堆，以确保当前响应比最高的任务始终位于顶部。
动态优先级更新: 任务的有效调度优先级由其响应比控制，随着任务在队列中等待时间的增加，其响应比会增加，从而随时间推移获得更高的优先级。这防止了长时间等待的任务被饿死。
调度决策逻辑: 在每个调度周期中，系统执行以下步骤：
检查堆顶任务的资源需求是否能被当前可用资源满足。
如果资源充足：任务从队列中弹出并转发至编译模块。
如果资源不足：不分发任务；相反，更新所有排队任务的响应比（优先级）。
无论结果如何，在周期结束时刷新优先级队列以准备下一次调度事件。
QCompileServer 模块¶
本源司南提供了一个全面、灵活且高性能的量子线路编译与优化框架。该框架抽象了底层量子硬件的复杂性，使量子软件开发者能够专注于算法设计和应用创新——无需了解不同量子处理器架构的具体细节。
主要优势：
硬件无关开发: 开发者只需提交标准量子线路（例如 QASM 或内部中间表示）。编译器自动将线路适配到目标后端，实现跨支持量子硬件平台的”一次编写，到处运行”。
异构多后端支持: 当前版本支持两种主流量子计算模态：超导和离子阱处理器。根据用户指定的目标后端，系统动态选择合适的编译流程以生成完全兼容的原生指令集。
并行编译加速: 基于并行编译框架构建，服务可以并发处理多个任务或将大型线路分解为片段进行并行优化——显著提高整体编译吞吐量，特别是对于批量作业或高复杂度线路。
编译与优化能力：Pilot 编译器集成了一套先进的优化算法，每个算法都通过标准化、模块化接口封装，以促进重用、组合和未来的扩展。
核心优化技术包括： - 多控门分解 - 门集转换 - 量子线路优化 - 量子比特映射与拓扑路由
ResourceManager 模块¶
资源管理模块负责接收来自量子计算后端的资源更新通知或来自上层系统组件的资源配置消息。它维护可用资源的最新清单，并将此信息与系统中的其他服务同步。
核心职责：
处理资源更新和配置请求: 接收有关资源变更（如后端可用性、量子比特状态）或显式资源配置命令的消息，并相应地更新内部资源注册表。
服务资源信息查询: 响应其他系统组件的请求，按需提供当前且准确的资源数据。
BackendServer 模块¶
BackendServer 模块负责管理多个异构量子计算后端单元（如超导、离子阱），并处理计算任务的分发和执行结果的接收。作为 Pilot 系统与底层量子控制服务之间的中央通信枢纽，该模块采用混合消息模型来平衡可靠性、实时响应性和可扩展性。
通信架构：为了满足多样化的操作需求，后端服务模块在与量子控制服务交互时集成了两种 ZeroMQ 通信模式：
Router-Dealer 模式（请求-应答模式）
特征: 面向连接、双向、同步请求-响应。
主要用例: 将量子计算任务分发至特定后端；接收任务执行结果；查询实时任务状态；获取随机基准测试 (RB) 实验数据；交换心跳信号以进行链路健康监控和故障检测。
优势: 确保有序、可靠的消息传递——是关键控制命令和结果获取的理想选择。
Pub-Sub 模式（发布-订阅模式）
特征: 无连接、单向、异步、事件驱动。
角色: Pilot 后端服务作为订阅者，持续监听来自控制服务的广播消息。
推送事件: 典型的推送事件主要包括：主动任务状态更新（如异常终止、资源抢占）；芯片参数的动态变化（如 T1/T2 相干时间、门保真度）；自动校准例程完成时的通知；芯片资源可用性的实时更新（如量子比特故障、冷却恢复）。
优势: 消除轮询开销并实现低延迟事件传播，增强系统响应能力。