目录
This commit is contained in:
269
temp.md
269
temp.md
@@ -1,256 +1,57 @@
|
||||
你这个问题问得很“论文落地导向”:MCM/ICM 评委最在意的不是你有没有真实手机数据,而是——**你说的参数怎么来、仿真怎么跑、结果怎么验证**。下面我按你现在的论文结构,把「哪些地方需要数据 / 需要什么字段 / 代码和图片放哪 / 怎么检验模型」一次讲清楚(不需要你改模型)。
|
||||
### 0. Summary Sheet(1页)
|
||||
|
||||
---
|
||||
* 闭环链条一句话
|
||||
* 关键结果数字 + 建议
|
||||
|
||||
## 1)模型建立(Model Formulation)需要提供数据吗?
|
||||
### 1. Introduction & Problem Restatement
|
||||
|
||||
**严格来说:不必。**
|
||||
模型建立那一章的任务是:给出变量、假设、方程、机理闭环(功耗映射 + ECM + CPL + 热 + 老化 + 停机判据)。这些可以不靠数据完成。
|
||||
* 目标:TTE + 连续时间 + 欠压/风险
|
||||
|
||||
但有一个例外:
|
||||
如果你在模型建立里写了“我们选取 (z_{\min}=0.02)、(\gamma=1.6)、(\kappa=1.2)”这类**具体数值**,那评委会自然追问“这些数怎么来的”。
|
||||
所以建议做法是:
|
||||
### 2. Model Overview & Assumptions(很重要)
|
||||
|
||||
* **模型建立**:只写“参数待识别/可由实验/日志获得”,不在这一节塞一堆数值;
|
||||
* **参数辨识(第6节)**:再用数据主题/字段说明这些参数怎样拟合;
|
||||
* **结果(第8节)**:才给“最终一套参数表 + 范围”。
|
||||
* 给一张框图:(\mathbf{u}\to P_{\text{tot}}\to I\to \dot{\mathbf{x}}\to) TTE
|
||||
* **先定义**:(P_{\text{tot}}(t)) 是“负载对电池的等效功率需求”(细节后面再展开)
|
||||
* 输出:TTE + 风险时间(如 (t_\Delta))
|
||||
|
||||
---
|
||||
### 3. Battery-side Model(先讲电池)
|
||||
|
||||
## 2)哪些模块“需要数据”?
|
||||
3.1 First-order Thevenin ECM((V_{\text{term}}))
|
||||
3.2 极化支路动力学
|
||||
3.3 热模型(耗散项)
|
||||
3.4 老化/SOH(强调短时标可冻结、长时标再更新)
|
||||
|
||||
你们现在的整篇,真正需要“数据支撑”的地方主要有四块(按重要性):
|
||||
### 4. Load-side Power Model(再讲功耗来源)
|
||||
|
||||
### A. 参数辨识(第6节)——最需要数据
|
||||
4.1 组件功耗分解:屏幕/CPU/网络/后台
|
||||
4.2 网络弱信号惩罚 + tail 状态 (w(t))
|
||||
4.3 场景表(Standby/Video/Gaming/Navigation/Weak signal 等)→ 映射到 (P_{\text{tot}}(t))
|
||||
|
||||
你要证明:参数不是拍脑袋,是可以从可复现数据得到。
|
||||
### 5. Coupling & Governing Equations(最后把闭环收口)
|
||||
|
||||
### B. 结果与验证(第8节/第9节)——需要“对比数据”或“合理性检验”
|
||||
5.1 CPL 闭环:由 (P_{\text{tot}}(t)=V_{\text{term}}(t)I(t)) 解 (I(t))(含判别式 (\Delta))
|
||||
5.2 “(\Delta)”的物理意义(负阻抗/崩溃风险)
|
||||
5.3 总耦合 ODE(把电池 + tail + 热 + 老化拼成最终系统)
|
||||
5.4 终止条件:TTE 与 (t_\Delta) 的区分(避免逻辑矛盾)
|
||||
|
||||
不一定要真实手机数据,但至少要有:
|
||||
### 6. Numerical Method & Parameter Strategy
|
||||
|
||||
* 典型输入曲线(场景化);
|
||||
* 对比:仿真输出 vs 常识/基准(比如同类手机续航范围、温升范围)。
|
||||
* 求解器、步长控制、事件检测、参数分组/标定思路
|
||||
|
||||
### C. 不确定性/MC/Sobol(第7节)——需要“分布假设”的依据
|
||||
### 7. Results & Insights
|
||||
|
||||
如果你说“亮度是 OU 过程”,那 OU 的均值/方差/相关时间最好来自:
|
||||
* 各场景曲线 + TTE
|
||||
* (t_\Delta) vs TTE(“突然关机风险”亮点)
|
||||
* 策略建议(用户/系统)
|
||||
|
||||
* 历史使用日志统计(最好),或
|
||||
* 你给出合理范围并做敏感性(也能过)。
|
||||
### 8. Uncertainty Quantification & Sensitivity
|
||||
|
||||
### D. 策略建议(降频/限流)——需要阈值/触发条件(可用假设范围)
|
||||
* OU/切换 OU、Sobol、置信区间、相对不确定度等
|
||||
|
||||
比如 (I_{\max}(T_b)) 的阈值、降频比例,可用行业常识范围/简化设定,再做敏感性说明其影响。
|
||||
### 9. Discussion / Limitations / Extensions
|
||||
|
||||
---
|
||||
* 2-RC 放这里或附录(主文不强上)
|
||||
|
||||
## 3)如果要提供数据:分别需要哪些“数据主题”?每个主题要哪些字段?
|
||||
|
||||
下面给你一套“最小可用数据清单”(MCM 很吃这一套:字段明确、可复现、不会让你真去做重实验也能写得像真的)。
|
||||
|
||||
> 你不一定全都有。没有真实数据时,用**合成数据 + 合理范围 + 可复现生成规则**也可以,但字段设计要完整。
|
||||
|
||||
---
|
||||
|
||||
### 主题 1:系统使用日志(最关键,驱动输入 (\mathbf{u}(t)))
|
||||
|
||||
**用途:** 给 (L(t),C(t),N(t),\Psi(t),T_a(t)) 的统计/场景;也可给功耗映射拟合。
|
||||
|
||||
**字段建议:**
|
||||
|
||||
* `timestamp`(秒或毫秒)
|
||||
* `L`(归一化亮度 0–1)
|
||||
* `C`(CPU 负载 0–1,或 CPU utilization)
|
||||
* `N`(网络活动 0–1:可用吞吐/包率归一化)
|
||||
* `Psi`(信号质量:RSRP/RSRQ/SINR 或 0–1 归一化指标)
|
||||
* `Ta`(环境温度,℃或 K)
|
||||
* 可选:`screen_on`(0/1,用于工况识别)、`app_category`(视频/游戏/社交)
|
||||
|
||||
---
|
||||
|
||||
### 主题 2:电池测量数据(输出验证 + ECM 拟合)
|
||||
|
||||
**用途:** 验证 (V_{\text{term}}(t))、SOC、温度;或拟合 (R_0,R_1,C_1)。
|
||||
|
||||
**字段建议:**
|
||||
|
||||
* `timestamp`
|
||||
* `V_term`(端电压)
|
||||
* `I_meas`(电流,若能拿到最好;拿不到也可用功耗+电压反推)
|
||||
* `z_meas`(SOC/电量百分比)
|
||||
* `Tb_meas`(电池温度)
|
||||
* `device_state`(充/放电、是否插电)
|
||||
|
||||
---
|
||||
|
||||
### 主题 3:OCV–SOC 曲线(拟合 (E_0,K,A,B))
|
||||
|
||||
**用途:** 识别 modified Shepherd 参数。
|
||||
|
||||
**字段建议:**
|
||||
|
||||
* `z`(0–1)
|
||||
* `V_oc`(开路电压)
|
||||
* 可选:`temperature`(因为 OCV 也会随温度略变)
|
||||
|
||||
---
|
||||
|
||||
### 主题 4:脉冲测试数据(拟合 (R_0,R_1,C_1))
|
||||
|
||||
**用途:** 用“瞬时压降 + 指数松弛”分离欧姆/极化。
|
||||
|
||||
**字段建议:**
|
||||
|
||||
* `timestamp`
|
||||
* `I_step`(施加电流)
|
||||
* `V_term`(高采样电压)
|
||||
* `z`(测试 SOC)
|
||||
* `Tb`(测试温度)
|
||||
|
||||
---
|
||||
|
||||
### 主题 5:网络尾耗数据(拟合 (k_{\text{tail}},\tau_\uparrow,\tau_\downarrow))
|
||||
|
||||
**用途:** 验证你们的 (w(t)) 连续尾耗机制。
|
||||
|
||||
**字段建议:**
|
||||
|
||||
* `timestamp`
|
||||
* `N`(网络活动)
|
||||
* `P_net` 或 `P_tot`(网络功耗或整机功耗)
|
||||
* `Psi`(信号质量,便于把惩罚项分离)
|
||||
* `w`(不需要测,仿真内部;但实验功耗曲线用于拟合)
|
||||
|
||||
---
|
||||
|
||||
### 主题 6:老化数据(拟合 (\lambda_{\rm sei},m,E_{\rm sei}))
|
||||
|
||||
**用途:** 给 SOH 退化方程参数。
|
||||
|
||||
**字段建议:**
|
||||
|
||||
* `time_or_cycles`
|
||||
* `S`(SOH/容量保持率)
|
||||
* `I_profile`(平均电流或 C-rate)
|
||||
* `Tb`(温度)
|
||||
* 可选:`calendar_time`(日历老化)
|
||||
|
||||
---
|
||||
|
||||
### 主题 7:策略阈值数据(限流/降频)
|
||||
|
||||
**用途:** 给 (I_{\max}(T_b)) 或 (P_{\cap}(T_b)) 的形状/阈值。
|
||||
|
||||
**字段建议:**
|
||||
|
||||
* `Tb`
|
||||
* `I_limit` 或 `P_cap`
|
||||
* `throttle_flag`(是否触发降频)
|
||||
|
||||
> 没有也没关系:用“典型阈值范围 + 敏感性分析”就能写得很合理。
|
||||
|
||||
---
|
||||
|
||||
## 4)代码应该出现在论文哪个模块?
|
||||
|
||||
MCM 论文一般不贴大段代码。推荐结构:
|
||||
|
||||
* **第6节 数值求解与参数辨识:** 放“算法伪代码”(Algorithm 3/4)+ 关键实现要点(RK4 子步嵌套求 (I)、步长对半、事件检测)。
|
||||
* **附录 Appendix:** 放简化代码框架(比如 Python/Matlab 伪代码),例如:
|
||||
|
||||
* `simulate_one_path(u(t), params)`
|
||||
* `solve_current_CPL()`
|
||||
* `step_RK4_with_nested_I()`
|
||||
* `estimate_params_pulse()`
|
||||
* `MC_TTE()`
|
||||
* `Sobol_Saltelli()`
|
||||
|
||||
正文里只要“算法”就够,附录放代码能加分且不抢篇幅。
|
||||
|
||||
---
|
||||
|
||||
## 5)图片应该出现在哪个模块?
|
||||
|
||||
按你们的叙事链条放:
|
||||
|
||||
* **第5节 模型建立**:
|
||||
|
||||
* 模型结构框图(输入→功耗→CPL→电流→ODE→输出)
|
||||
* 子系统示意(网络尾耗 (w) 机制图也行)
|
||||
|
||||
* **第8节 结果与讨论**(最核心):
|
||||
|
||||
* 输入样例((L,C,N,\Psi,T_a))
|
||||
* SOC/电压/温度轨迹束(MC)
|
||||
* TTE 分布(直方图/CDF/生存曲线)
|
||||
* Sobol 指数条形图
|
||||
-(可选)策略前后对比图(有限流 vs 无)
|
||||
|
||||
* **附录**:
|
||||
|
||||
* 参数拟合曲线(OCV 拟合、脉冲松弛拟合、尾耗指数拟合)
|
||||
* 误差收敛图(步长对半、MC 采样收敛)
|
||||
|
||||
---
|
||||
|
||||
## 6)你的模型如何检验(Validation / Verification)?
|
||||
|
||||
这部分你要写得“像工程论文”,我给你一套评委很买账的四层检验法:**V&V(verification & validation)**。
|
||||
|
||||
### 6.1 数值正确性(Verification)
|
||||
|
||||
证明“代码没算错”:
|
||||
|
||||
1. **步长对半收敛**:你们已有
|
||||
(|z_{\Delta t}-z_{\Delta t/2}|_\infty<10^{-4}),TTE 变化 <1%
|
||||
2. **物理约束检验**:
|
||||
|
||||
* (z(t)) 单调下降(放电时)
|
||||
* (S(t)) 单调不增
|
||||
* (w(t)\in[0,1])
|
||||
3. **能量一致性检查(推荐加分项)**:定义交付能量
|
||||
[
|
||||
E_{\rm del}(t)=\int_0^t V_{\rm term}(\tau)I(\tau),d\tau
|
||||
]
|
||||
与 SOC 下降对应的可用能量规模一致(不要求完全相等,但量级要对得上)。
|
||||
|
||||
### 6.2 参数合理性(Calibration sanity)
|
||||
|
||||
证明“参数不离谱”:
|
||||
|
||||
* (R_0) 随温度降低增大(Arrhenius)
|
||||
* (\gamma,\eta>1) 体现超线性负载
|
||||
* (\kappa>0) 表明信号差更耗电
|
||||
* (hA/C_{\rm th}) 给出合理热时间常数(几十分钟量级通常合理)
|
||||
|
||||
### 6.3 行为有效性(Behavioral validation)
|
||||
|
||||
不一定要真实数据,也能做:
|
||||
|
||||
* 场景测试:视频/游戏/待机输入,得到 TTE 排序符合常识(游戏 < 视频 < 浏览 < 待机)
|
||||
* 低温测试:同样输入下 TTE 明显下降(因为 (R_0\uparrow, Q_{\rm eff}\downarrow))
|
||||
* 老化测试:(S) 下降时 TTE 下降、且更易触发低电压关机
|
||||
|
||||
### 6.4 对比验证(External validation)
|
||||
|
||||
如果有一点点真实数据最好(哪怕公开数据/文献图):
|
||||
|
||||
* 用文献中“某负载功耗范围、温升范围、续航区间”做对比,证明你输出落在合理区间
|
||||
* 或者用手机系统导出的 battery log 做一段短时对比(10–30 分钟也足够)
|
||||
|
||||
---
|
||||
|
||||
## 你现在应该怎么做(最省力的落地路线)
|
||||
|
||||
如果你不想真的去找很多实验数据,我建议“最小闭环”是:
|
||||
|
||||
1. **合成/场景化输入数据**(主题1):自己生成 (L,C,N,\Psi,T_a) 的典型曲线(每个场景 2–4 小时)。
|
||||
2. **给一套参数表 + 合理范围**:参数辨识写“可按以下数据拟合”,再给出“采用文献/经验的标称值+范围”,并在敏感性里证明结论稳健。
|
||||
3. **结果章用 MC + Sobol + 策略对比**,会非常像 O 奖文章。
|
||||
|
||||
---
|
||||
|
||||
如果你愿意,我可以把你这段“数据需求说明”直接写成论文里一个小节(例如 **“Data Requirements and Validation Protocol”**),并且帮你把每个数据主题写成表格(字段、单位、来源、用途、对应参数)。你只要告诉我:你们打算走 **真实日志** 还是 **场景合成** 路线即可。
|
||||
### References + Appendices
|
||||
|
||||
* 完整假设、推导、参数表、伪代码
|
||||
|
||||
|
||||
Reference in New Issue
Block a user