77 lines
6.3 KiB
Markdown
77 lines
6.3 KiB
Markdown
# 情景模拟分析结果
|
||
|
||
## 1. `initSimulation` 现状分析与建议
|
||
|
||
### 1.1 现状分析
|
||
`initSimulation` 方法是模拟系统的核心入口，负责将静态的项目拓扑结构和动态的情景事件转化为可用于推理的时序数据帧（Frames）。目前的实现主要包含以下几个关键部分：
|
||
|
||
1. **静态属性加载**：
|
||
* **拓扑解析**：方法首先加载 `Project` 实体，并解析其 `topology` JSON 字段。这包含了设备（Devices）和物料（Material）的基础定义。
|
||
* **数据库补全**：通过 `buildMaterialStaticFromDb` 方法（L1116），系统会根据拓扑中的 `materialId` 查询 `Material` 数据库表，补全如 `u_concentration`, `pu_isotope`, `pu_concentration` 等关键理化属性。
|
||
* **尺寸注入**：通过 `injectDeviceSize` 方法（L776），解析设备 `ui.size` 或 `properties` 中的尺寸信息（如 `diameter`, `height`）并注入到模拟状态中。
|
||
* **符合度**：这部分逻辑基本覆盖了需求 1.1 中关于“项目设备属性、物料属性的静态值”的处理。
|
||
|
||
2. **始发事件处理**：
|
||
* **事件解析**：方法查询指定 `scenarioId` 下的所有 `Event` 记录。
|
||
* **插值逻辑**：通过 `buildValueProviders` 方法（L929），解析 `attr_changes` JSON 字段。代码明确处理了 `step-set`（阶跃变化）和 `ramp`（线性斜坡）两种插值模式。
|
||
* **符合度**：这部分逻辑能够处理需求 1.2 中描述的复杂事件定义（如“条件3”中的分段变化）。
|
||
|
||
3. **影响关系计算**：
|
||
* **传播模型**：在 `ProjectServiceImpl` 的主循环（L695-717）中，实现了基于拓扑定义的影响传播。
|
||
* **计算公式**：采用了线性加权模型：`TargetValue = Bias + Σ(Coefficient * SourceValue(t - Delay))`。
|
||
* **符合度**：这部分逻辑覆盖了需求 1.3 中关于设备间、设备与物料间属性影响关系的定义。
|
||
|
||
### 1.2 存在的问题与建议
|
||
|
||
1. **数据校验缺失**：
|
||
* **问题**：当前代码在解析 `topology` 后，缺乏对关键物理属性（如 `diameter`, `height`）的强校验。如果 JSON 中缺失这些字段，后续计算可能会抛出空指针异常或产生错误的 `0` 值。
|
||
* **建议**：在 `initSimulation` 的第一步增加 `validateTopology` 逻辑，确保所有参与物理计算的属性都已正确定义且非空。
|
||
|
||
2. **初始状态一致性**：
|
||
* **问题**：当 `t=0` 时刻，静态拓扑中定义的默认值与 `Event` 中定义的初始值可能存在冲突。目前的逻辑是先加载静态值，再应用事件变化。
|
||
* **建议**：明确并文档化优先级规则：**事件设定值（t=0） > 静态默认值**。在代码中确保事件应用逻辑在静态初始化之后执行。
|
||
|
||
3. **逻辑耦合度高**：
|
||
* **问题**：`ProjectServiceImpl` 承担了过多的职责（CRUD、拓扑解析、数学计算、推理调度）。`initSimulation` 方法过于庞大（数百行），维护困难。
|
||
* **建议**：将模拟初始化的核心逻辑（特别是时间步推进和状态计算）抽取为独立的 `SimulationEngine` 或 `SimDataBuilder` 类。
|
||
|
||
## 2. `SimController` 分析
|
||
|
||
### 2.1 现状
|
||
* `SimController` 目前处于**全注释状态**，完全未启用。
|
||
* 当前的模拟相关接口（`/simulation/init`, `/simulation/run`）直接寄宿在 `ProjectController` 中，导致 `ProjectController` 臃肿。
|
||
|
||
### 2.2 建议
|
||
1. **启用 SimController**：遵循单一职责原则（SRP），应激活 `SimController` 作为模拟相关业务的统一入口。
|
||
2. **服务拆分**：
|
||
* 创建 `SimService` 接口及其实现类 `SimServiceImpl`。
|
||
* 将 `ProjectServiceImpl` 中与模拟强相关的逻辑（`initSimulation`, `runSimulation`, `loadSimInfluenceNodes` 等）迁移至 `SimService`。
|
||
* `ProjectService` 应只保留项目元数据的 CRUD 操作。
|
||
3. **重构半成品**：参考 `SimController` 的原始设计，完善其输入参数校验和异常处理，使其符合当前的 RESTful API 规范。
|
||
|
||
## 3. `runSimulation` 分析与新需求建议
|
||
|
||
### 3.1 现状分析
|
||
* **算法绑定限制**：目前代码（L1305）从 `Scenario` 对象中获取 `algorithmType`。这意味着**同一个情景下的所有设备必须使用同一种算法**。这无法满足“针对不同设备使用不同算法”的精细化需求。
|
||
* **推理调用简单**：在调用 `deviceInferService.processDeviceInference` 时，仅传递了按 `DeviceType` 分组的数据，**未透传算法类型**。这意味着推理服务可能在使用默认算法，或者需要自行再次查询配置。
|
||
|
||
### 3.2 新需求适配建议：设备级算法配置
|
||
|
||
针对“要求场景表，针对项目设备设置算法类型”的需求变更，建议方案如下：
|
||
|
||
1. **数据模型变更**：
|
||
* **方案 A（推荐 - 拓扑集成）**：在 `Project` 的 `topology` JSON 结构中，为每个 `device` 节点增加 `algorithmType` 字段。这样在建模阶段就确定了设备的算法特性。
|
||
* **方案 B（场景覆盖）**：在 `Scenario` 表中增加一个 JSON 字段（如 `device_configs`），存储 `Map<DeviceId, AlgorithmType>` 的映射关系，允许在不同情景下为同一设备指定不同算法。
|
||
|
||
2. **业务逻辑调整 (`runSimulation`)**：
|
||
* **分组策略升级**：目前的 `groupedDevices` 是 `Map<DeviceType, List<DeviceStepInfo>>`。需要调整为更细粒度的分组，键应包含算法信息。
|
||
* 新结构示例：`Map<String(DeviceType_AlgorithmType), List<DeviceStepInfo>>`。
|
||
* **参数透传**：在构建 `DeviceStepInfo` 时，必须将设备的 `algorithmType` 写入该对象。
|
||
|
||
3. **接口升级**：
|
||
* 修改 `deviceInferService.processDeviceInference` 接口签名，使其能够识别不同分组对应的算法类型。
|
||
* **路由逻辑**：在 `DeviceInferService` 内部实现路由策略，根据传入的 `algorithmType`（如 `MCNP`, `PointNet`, `Analytical`）调用不同的底层推理模型或微服务。
|
||
|
||
### 总结
|
||
当前系统已具备基本的模拟框架，但为了应对更复杂的业务需求（如设备级算法配置）和提升系统可维护性，必须进行**服务拆分（SimService）**和**数据模型升级（AlgorithmType下沉）**。
|