66 lines
4.5 KiB
Markdown
66 lines
4.5 KiB
Markdown
|
# 情景模拟分析结果 v2
|
|||
|
|
|
|||
|
|
## 1. 模拟数据初始化的优先级分析
|
|||
|
|
|
|||
|
|
针对“设备表/物料表静态值”、“始发事件表突发值”以及“影响关系计算公式”这三者在模拟初始化中的执行顺序和优先级，我们对比了当前系统中的两套实现逻辑：
|
|||
|
|
|
|||
|
|
### 1.1 核心逻辑对比
|
|||
|
|
|
|||
|
|
| 特性 | ProjectServiceImpl (当前运行逻辑) | SimService (SimController 逻辑) |
|
|||
|
|
| :--- | :--- | :--- |
|
|||
|
|
| **逻辑流** | **静态加载 → 影响计算 → 事件覆盖** | **事件预设 → 影响计算** |
|
|||
|
|
| **优先级** | **事件最高** (Final Override) | **影响公式最高** (Calculation Override) |
|
|||
|
|
| **输入读取** | 计算公式优先读取事件值，无事件时读静态值 | 计算公式读取上下文当前值（即事件预设值） |
|
|||
|
|
| **典型场景** | 强制干预（如：强制设定液位为 100，忽略进出水计算） | 初始条件设定（如：设定初始液位，随后随公式变化） |
|
|||
|
|
|
|||
|
|
### 1.2 详细执行顺序建议
|
|||
|
|
|
|||
|
|
基于业务场景的合理性（通常事件代表外部强制变更或设定），建议采用以下**混合优化的优先级策略**，并在重构时予以实施：
|
|||
|
|
|
|||
|
|
1. **Step 1: 加载基础静态值 (Static)**
|
|||
|
|
* 作为所有属性的默认“底色”。
|
|||
|
|
* *来源*：设备表、物料表。
|
|||
|
|
2. **Step 2: 应用 T=0 时刻的事件值 (Event Initial)**
|
|||
|
|
* 将所有在 T=0 时刻生效的事件值应用到状态中。
|
|||
|
|
* *目的*：设定系统的初始状态（Initial Conditions），供 T=1 的计算使用。
|
|||
|
|
3. **Step 3: 执行影响关系计算 (Influence)**
|
|||
|
|
* 基于当前状态（可能是静态值，也可能是被 Step 2 修改过的值）执行公式计算。
|
|||
|
|
* *注意*：如果是 T=0 时刻，通常不执行动态计算，或仅执行静态平衡计算。
|
|||
|
|
4. **Step 4: 强制事件覆盖 (Event Override - Optional)**
|
|||
|
|
* 对于那些标记为“强制锁定”类型的事件，在计算结束后再次覆盖结果。
|
|||
|
|
* *目的*：模拟传感器故障、手动超控等场景。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 2. SimController 及相关接口深入分析
|
|||
|
|
|
|||
|
|
`SimController` 及其配套的 `SimService` 代表了系统的演进方向，尽管目前未启用，但其设计模式优于当前的 `ProjectServiceImpl`。
|
|||
|
|
|
|||
|
|
### 2.1 架构设计意图
|
|||
|
|
* **外观模式 (Facade)**：`SimController` 充当了数据组装者的角色，负责从 `Project`、`Event` 等多个异构数据源获取数据，并将它们转换为统一的仿真领域模型（`SimContext`, `SimUnit`）。
|
|||
|
|
* **解耦计算与存储**：`SimService` 被设计为一个纯粹的计算引擎，它不关心数据来自数据库还是 JSON，只关心 `SimContext` 中的 KV 对。这与 `ProjectServiceImpl` 中深度耦合数据库查询的逻辑形成鲜明对比。
|
|||
|
|
|
|||
|
|
### 2.2 接口与模型问题
|
|||
|
|
虽然架构较好，但 `SimController` 的实现存在以下具体问题，导致无法直接使用：
|
|||
|
|
|
|||
|
|
1. **优先级逻辑倒置**：
|
|||
|
|
* 如前所述，`SimService` 先应用事件，后执行计算。这会导致：如果一个属性既有事件设定（如 `u_concentration=20`），又有上游影响（如 `u_concentration = source * 0.5`），最终结果会被计算值覆盖，导致事件设定失效。
|
|||
|
|
* **修正建议**：需要在计算循环结束后，再次检查是否有“持续生效”的事件，并重新应用覆盖。
|
|||
|
|
|
|||
|
|
2. **数据模型缺失**：
|
|||
|
|
* `SimService` 目前主要面向通用的 KV 计算，缺乏对“设备-物料”层级关系的显式支持。
|
|||
|
|
* **修正建议**：增强 `SimContext`，使其能感知属性所属的实体类型（Device vs Material），以便正确处理如 `injectDeviceSize` 这类特定逻辑。
|
|||
|
|
|
|||
|
|
3. **推理接口对接**：
|
|||
|
|
* 代码中包含 `InferenceConverter`，意图对接 AI 推理。但目前的逻辑是“先计算物理公式，再打包给 AI”。
|
|||
|
|
* **优化建议**：明确物理计算与 AI 推理的边界。是物理计算的结果作为 AI 的输入？还是 AI 的推理结果修正物理计算？当前逻辑倾向于前者。
|
|||
|
|
|
|||
|
|
### 2.3 结论与行动路线
|
|||
|
|
|
|||
|
|
**结论**：`SimController` 是正确的重构方向，但其核心计算逻辑（优先级处理）需要修正以符合业务直觉。
|
|||
|
|
|
|||
|
|
**建议行动**：
|
|||
|
|
1. **废弃 `ProjectServiceImpl` 中的模拟逻辑**，将其迁移至 `SimService`。
|
|||
|
|
2. **修正 `SimService` 的计算流**：采用 `Static -> Event(Init) -> Influence -> Event(Override)` 的标准管线。
|
|||
|
|
3. **标准化接口**：将 `SimController` 的 `/simulation/run` 确立为唯一入口，统一管理同步/异步调用。
|