DEKF对偶扩展卡尔曼滤波原理与Simulink建模实践：电池SOC与参数联合估计

DEKF这三个字母，搞过电池估算或者状态观测的工程师应该都不陌生：Dual Extended Kalman Filter，对偶扩展卡尔曼滤波，专门用来把系统状态和模型参数同时估计出来。我在做实时估算项目时，最常用的验证工具就是Simulink——建模直观、能可视化调参、后面还能直接走代码生成下到硬件上跑。这篇文章我把从原理到建模，再到实际跑通DEKF的完整过程整理出来，重点放在用Simulink落地时那些容易被“原理讲解”跳过的坑。内容适合正在做算法验证的工程师，也适合研究生阶段刚开始接触状态估计、想在仿真环境里把DEKF跑明白的同学。

1. 项目概述：DEKF到底是什么，为什么值得花时间验证

1.1 核心问题：状态和参数同时在线辨识

很多实际系统都存在同一个尴尬：状态变量需要知道模型参数才能算准，而模型参数本身又会随着环境、老化、工况发生变化。

拿动力电池举例子。我们想知道SOC（荷电状态），但SOC的动态方程里有一个“容量Q”——这个Q会随着电池老化慢慢衰减，不是恒定的。而我们拿到手的端电压测量值，又受到另一个参数“欧姆内阻R0”的影响，这个小伙子随温度和充放电倍率变化相当明显。如果用固定参数去做SOC估计，刚开始还行，跑一段时间误差就会越滚越大。

DEKF的思路非常直接：既然状态和参数互相影响，那就准备两套EKF，一套估状态，一套估参数。每一拍，状态EKF用上一拍估出来的参数来计算SOC；参数EKF用当前拍的状态估计值来修正参数。二者交替执行、互喂结果，最后状态和参数一起收敛。

1.2 为什么选对偶结构而不是联合EKF

有人会问：既然要同时估状态和参数，把状态向量和参数向量拼成一个大的联合状态向量，用一套EKF不就行了？这就是Joint EKF，理论上完全可行。

但我在实践中发现，联合EKF有两个让人头疼的问题。

第一是维度灾难。状态有状态的空间维度，参数有参数的维度，拼在一起后协方差矩阵的规模平方增长。对电池这种低阶系统还好，换成车辆动力学模型、电机模型，联合EKF的矩阵运算量会让实时仿真变得很重。

第二是动态时间尺度差异。状态量通常变化快，参数变化慢，两者放在同一个滤波器里，调Q矩阵的时候很难兼顾——把Q调大了，状态跟得快但参数噪声大；调小了，参数平滑但状态滞后。换句话说，联合EKF把两个特性完全不同的估计问题强行绑在了一起，工程调参极其痛苦。

DEKF把这两件事拆开了。状态EKF的Q主要决定状态跟踪的快慢，参数EKF的R决定参数收敛的力度，各自调各自的，物理意义清楚，调试体验天差地别。这也是我为什么在项目中基本都是直接选DEKF而不是联合EKF的根本原因。

1.3 用Simulink做验证的边界在哪里

Simulink本身的强项是建模、仿真、代码生成，不是用来“推导公式”的。所以我个人的工作流是：先用MATLAB脚本把DEKF算法快速实现，确认算法逻辑没问题；再搬进Simulink模型里，搭出带输入输出接口的验证平台。这样一来，Simulink验证的是“实现一致性”和“模块化集成能力”，而不是拿它去debug算法本身。

本文后边的实现方案，就是按照这条“脚本先行、Simulink跟进”的思路来的。你在看的时候可以把这个模型当成一个可复用的DEKF验证台架：换一套状态方程、换一组测量方程，就能搬到别的对象上去用。

2. 从原理到模型：DEKF的数学流程与Simulink建模策略

2.1 DEKF的数学框架

DEKF本质上是两套EKF在同一时间轴上的交替运算。为了让你看到全貌，我把单步流程写成下面这样。

假设系统的离散状态方程和输出方程为：

code复制x(k+1) = f(x(k), u(k), θ(k))  
y(k)   = h(x(k), u(k), θ(k))

其中x是要估计的状态，θ是要估计的参数。DEKF每一步执行以下操作：

1. 状态EKF时间更新：用上一拍的状态估计值 x̂(k-1) 和上一拍的参数估计值 θ̂(k-1)，预测当前拍状态

2. 状态EKF测量更新：用端电压测量值 y_meas 修正状态预测结果

3. 参数EKF时间更新：用当前拍的状态估计值 x̂(k) 和上一拍的参数值预测当前参数

4. 参数EKF测量更新：用同一个端电压测量值修正参数预测结果

写成伪代码大概是这样：

matlab复制% 状态EKF
[x_pred, P_pred] = ekf_predict(x_hat, P_x, u, theta_hat, ...);
[y_pred, H_x]    = h_with_jacobian(x_pred, u, theta_hat);
K_x  = P_pred * H_x' / (H_x * P_pred * H_x' + R_x);
x_hat = x_pred + K_x * (y_meas - y_pred);
P_x   = (eye(nx) - K_x * H_x) * P_pred;

% 参数EKF
[theta_pred, Ptheta_pred] = ekf_predict(theta_hat, P_theta, u, x_hat, ...);
[y_pred_theta, H_theta]   = h_with_jacobian(x_hat, u, theta_pred);
K_theta  = Ptheta_pred * H_theta' / (H_theta * Ptheta_pred * H_theta' + R_theta);
theta_hat = theta_pred + K_theta * (y_meas - y_pred_theta);
P_theta   = (eye(nt) - K_theta * H_theta) * Ptheta_pred;

这里最关键的耦合在于：状态EKF的预测依赖 θ̂，参数EKF的更新依赖 x̂。有人说这是近似处理，严格来说应该在同一步内多次迭代，但工程实践中“互用上一拍/当前拍结果”已经够用，而且这种交替结构实现简单、稳定性好。

2.2 建模对象：以锂电池一阶RC模型为例

因为DEKF要验证总得有一个具体对象，我用电池一阶RC等效电路模型作为案例。系统状态向量选为：

code复制x = [SOC, V_RC]'

其中 V_RC 是极化电压。输入是负载电流 I（规定放电为正），输出是端电压 U_t。

离散状态方程：

code复制SOC(k+1)   = SOC(k) - I(k)*dt / (3600 * Q)
V_RC(k+1)  = exp(-dt/(R1*C1)) * V_RC(k) + R1*(1 - exp(-dt/(R1*C1))) * I(k)

端电压输出方程：

code复制U_t(k) = OCV(SOC(k)) - R0*I(k) - V_RC(k)

其中OCV可以用多项式拟合，也可以用lookup table。参数向量我建议先简化为θ = [R0, Q]，因为R1、C1和极化电压V_RC之间存在强耦合，辨识条件不如R0、Q清晰。先在简单配置下跑通，再加复杂度，这个习惯能帮你省下大量排查时间。

2.3 建模方案取舍：MATLAB Function块还是S-Function

DEKF在Simulink里的实现方式有好几种，我先讲清楚各自优缺点。

第一种是用Simulink原生模块搭建EKF的每一步，比如加法器、乘法器、矩阵求逆模块、Unit Delay。这种方式在教科书演示里见过，但一旦涉及两个EKF的相互耦合，模型画出来密密麻麻，维护起来非常痛苦，我不推荐用于DEKF这种算法。

第二种是S-Function。灵活、适合封装成可复用模块，但需要用C或MATLAB语言编写，而且调试不方便，建模前期的排查成本较高。如果你后续打算做代码生成，S-Function确实是一条路子，但在验证阶段容易绊住手脚。

第三种是我个人最推荐的做法——用MATLAB Function块。它可以直接写类似MATLAB代码的逻辑，支持仿真，也支持Embedded Coder生成嵌入式C代码。使用MATLAB Function块配合persistent变量或者Unit Delay保存协方差矩阵和估计值，可以很轻量地实现DEKF。唯一的代价是，如果之前没用过MATLAB Function块，需要花十几分钟了解它和普通脚本的语法差异，比如输入输出必须显式声明、persistent变量要小心初始化。

我把三种方式的对比如下：

3. 实操过程：在Simulink里搭建并跑通DEKF

3.1 搭建模型的具体步骤

我的建议是把模型分三块：被控对象模型、DEKF算法模块、数据记录与显示。下面按步骤写。

第一步：建立电池仿真模型作为“真实系统”。这一步是为了生成带正确物理特性的端电压测量值。可以在Simulink里用离散模块搭，也可以直接用MATLAB脚本生成数据后通过From Workspace导入。我在验证阶段更喜欢用From Workspace，因为可以批量跑多种工况，不用回回改Simulink模型。

第二步：写DEKF核心模块。新建一个MATLAB Function块，命名为DEKF_update，内部按2.1的流程写。为了避免协方差矩阵在调用之间丢失，可以把它们定义为persistent变量：

matlab复制function [x_hat, theta_hat, P_x, P_theta] = DEKF_update(u, y_meas, dt)
    persistent x_persist theta_persist Px_persist Ptheta_persist
    
    if isempty(x_persist)
        x_persist = [0.8; 0];       % 初始SOC假设80%
        theta_persist = [0.005; 2.5]; % [R0; Q]，注意单位
        Px_persist = eye(2) * 100;   % 初始协方差设大，让滤波器自己收敛
        Ptheta_persist = eye(2) * 10;
    end
    
    % 这里放状态EKF和参数EKF的交替递推
    % ...
    
    x_hat = x_persist;
    theta_hat = theta_persist;
    P_x = Px_persist;
    P_theta = Ptheta_persist;
end

第三步：把输入信号接好。u是电流，y_meas是端电压测量值，dt用仿真步长或常量模块给定。为了方便调试，我习惯把x_hat、theta_hat、P_x、P_theta都引出模型，直接接到To Workspace里。

第四步：加一个Unit Delay或者用persistent变量保持状态。我实际用的是persistent变量，因为这样整个滤波器在同一个函数块内闭环，省掉了外部Unit Delay带来的代数环麻烦。如果你希望滤波器的中间量可视化，可以把它们额外输出，再接Scope。

第五步：设置求解器。因为是离散模型和离散滤波器，求解器一定要选discrete，固定步长。采样时间我习惯用1秒，这样既符合电池BMS的典型采样率，也让仿真不用跑太慢。

第六步：初始化回调。在模型属性Callback里配置初始参数，比如初始SOC、OCV拟合系数、真值参数等。这样就不用在函数块里写死，后面换工况、换电池也更灵活。

3.2 关键参数设置：Q、R、P0的选择方法与调参经验

DEKF里最影响效果的三个“旋钮”是Q、R和P0。P0好理解，初始协方差矩阵，设大一些代表“我对初始状态很没谱”，滤波器会自动用第一组数据把状态拉回来。一般P0设到100量级没什么问题，但不要设成inf，数值上会炸。

Q和R的物理意义需要讲清楚。Q表示你对模型的信任程度，Q越大代表“模型噪声大、模型不可信”，滤波器会更多地依赖测量值；R表示对测量的信任程度，R越大代表“传感器噪声大、测量不可靠”，滤波器会更多地依赖模型预测。这两个值的相对大小，比绝对大小更重要——它们的比值基本决定了卡尔曼增益的尺度。

对于电池模型，R可以从传感器精度估算。比如电流和电压传感器的误差都在10mV/10mA量级，R就可以先设在1e-4到1e-3之间。Q则只能靠实验和观察调。我的调参建议是：

1. 先把R调到一个合理值；
2. 然后调状态EKF的Q，看SOC跟踪是否跟得上工况变化，如果估计值太震荡就减小Q，太迟钝就增大Q；
3. 收敛之后再去调参数EKF的Q和R，参数R调小一些会让参数收敛更快，但太小会导致参数估计出现高频抖动，这个要从曲线上判断。

这里要特别强调，Q和R的最终取值只对某个特定工况和特定电池成立，换个电池或者环境温度变了，往往需要重新标定。仿真验证的价值就是用大量工况把参数包络摸出来。

3.3 运行与结果分析：工况选择与结果评价

验证DEKF不能拿恒定电流工况跑，否则你会看到SOC估计还行，但参数完全不收敛。原因很简单：恒流工况下，端电压中R0压降和OCV变化混叠在一起，系统不可观，参数EKF根本区分不出“电压变低是因为SOC变了还是内阻变了”。

我通常用两种工况。一种是HPPC脉冲工况，短时脉冲配合静置，用来观察R0估计是否准确；另一种是动态工况，比如UDDS转换成功率加载到电池上，更接近真实使用场景，用来评估整体估计效果。

跑完之后重点看三样东西：SOC估计误差、R0估计收敛曲线、Q估计收敛曲线。我举个例子，同一套DEKF参数，不同工况的结果如下：

这个表能很直观地说明问题：激励条件决定了参数是否可辨识，算法再漂亮也救不了无激励的系统。所以每一次跑结果，都要先问一句：我这个工况给参数EKF提供了足够的“信息量”吗？

4. 常见问题与排查技巧实录

4.1 协方差矩阵非正定、矩阵奇异

这是EKF家族最经典的问题。你可能会在仿真跑到中途看到NaN，或者某个协方差矩阵元素变成负数。原因通常是几个：数值精度不够、Q或R设置过小导致卡尔曼增益计算中分母接近零、模型长时间不可观导致信息矩阵退化。

排查方法很简单，把P矩阵和卡尔曼增益K引出来打成曲线，看到某一拍P开始失控就能定位。解决手段有三个层次：第一，检查协方差更新公式，改用Joseph形式( I - K H ) P (I - K H)^T + K R K^T，数值稳定性会好很多；第二，状态若存在上下界，要加饱和和修正；第三，如果问题出在可辨识性上，那就不是数值问题，要回到激励和参数选取本身去解决。

4.2 参数EKF不收敛或收敛到错误值

这种情况在刚开始做DEKF时几乎一定会遇到。去年我在验证一个容量估计场景时，R0估计收敛得很快，但Q误差一直在3%左右下不来。排查一圈发现，问题出在OCV曲线的拟合精度上——高SOC区和低SOC区OCV斜率差异很大，而我的多项式拟合在低SOC区误差偏大，直接带偏了Q更新。

经验是：先检查测量方程中每一项的梯度，找出参数影响最大的输出区域。如果某个参数对输出的影响很小，那无论滤波算法多强，它都很难被精确辨识。对电池模型来说，R0的辨识需要电流脉冲，Q的辨识需要SOC大范围摆动，缺了对应“激励”，收敛失败属于正常现象。

另一个常见问题是初值给得太远。DEKF整体上对初值有一定的鲁棒性，但如果参数初值与真值差了一个数量级，滤波器很容易在一开始的几步把协方差阵搞大，然后又很快锁定到局部错误值。解决方法是把参数初值设置在一个合理范围，同时给P_theta初始值设置得足够大，让参数在前期有充分修正空间。

4.3 MATLAB Function块编译报错和维度问题

MATLAB Function块和脚本的一个不同点是它需要对输入输出做类型推断。如果你的输入电流u在仿真过程中是行向量还是列向量老变，或者输入端口维度不确定，就会出现编译错误。

我处理起来有几个习惯：一是每个输入输出端口都写清楚维度，比如单标量就直接声明为1x1；二是如果要处理数组，用reshape和squeeze先固定方向；三是persistent变量在初次使用时强制转换一次维度。还有一个和Selector/Convert模块相关的点，如果你的模型里用了总线数据或数组切换，记得在连入MATLAB Function之前就把数据维度捋顺，很多诡异报错都是维度不匹配导致的。

4.4 仿真步长和离散化误差

EKF的时间更新是从离散模型来的，如果你的真实对象是连续系统，而仿真步长太大，离散化误差会让滤波器“一本正经地往错误方向更新”。典型的症状是步长5ms跑出来收敛正常，换成50ms步长结果完全发散。

解决办法是：确认你的状态方程本身就是离散形式的，而不是用连续系统去套离散滤波器；同时将EKF的更新周期与仿真步长解耦。比如仿真步长用0.1s，EKF每10步更新一次，这样既保证系统动力学精度，又不让滤波器更新得太频繁。

4.5 快速排查工具：新息序列

最后分享一个我从调试EKF中收获很大的工具——新息序列。所谓新息就是测量值减去预测值，即 y_meas - y_pred。如果滤波器工作正常，新息序列应该是一个近似零均值的白噪声序列。

我每次跑完仿真都会把新息画出来：如果新息均值一直偏在零上边，说明模型存在系统偏差，不是随机噪声的问题；如果新息方差特别大，说明Q或R的比值不对；如果新息在某个时间段突然跳变，往往对应输入工况的可辨识性变化。这个指标比单纯看估计误差更前置、更敏感，强烈建议纳入你的结果分析流程。

我把上面这些常见问题整理成速查表，方便你调试时对照：

5. 实操心得与扩展建议

5.1 踩坑后的几点体会

整个DEKF仿真验证做下来，我觉得最重要的一条体会是：可辨识性永远排在算法前面。很多同学拿到DEKF第一反应就是调Q、调R，恨不得把协方差矩阵的每一个元素都调一遍。但如果你跑的是一个没有充分激励的工况，或者参数之间本身强耦合，那不管怎么调，结果都是白搭。

第二条体会是，一步一步往上加复杂度。我建议你先用一个参数、一个固定激励去跑通闭环，确认所有模块都正常工作，再逐步加入第二个参数、换更复杂的模型。Simulink模型的排查本来就很费时，如果一开始就是把R0、R1、C1、Q四个参数全扔给DEKF，出问题以后你会面对一个自由度爆炸的调试空间。

第三条是关于初始化和调参的，我把初始协方差设大一些其实是在给新息“让路”。如果P0取得太小，滤波器会认为初始估计非常可信，新息带来的修正很小，收敛会很慢。这与很多人第一直觉相反——以为初值越准越好，实际上仿真验证阶段给一个“适度自信”的初值，反而让滤波器行为更健康。

5.2 从仿真验证到工程落地的扩展路径

Simulink验证DEKF只是第一步。模型跑通以后，通常紧接着要做的事情就是代码生成。MATLAB Function块配合Embedded Coder可以直接生成C代码，可以很顺利地移植到嵌入式控制器上去。如果你想做更进一步的车辆级联合仿真，把DEKF模块和Carsim、负载模型做联合仿真也很自然；如果目标跑HIL测试，那dSPACE RT工程和外部模式就是下一步要考虑的方向。

需要提醒的是，仿真环境里噪声是加出来的，协方差阵的初值也相对“宽容”，到了实际硬件上会面临传感器噪声特性变化、通信延时、时间步长抖动等一系列新问题。所以仿真验证的意义在于把核心算法逻辑和参数基线定下来，真正到工程部署时还要再做一轮台架或整车标定。我个人习惯是在代码生成之前，先在Simulink里把算法封装成标准输入输出接口的函数块，这样后面无论是Carsim联建、FMU导出还是生成DLL，都只需要做端口适配，不用再动核心逻辑。DEKF这种对偶结构只要接口设计得好，往不同应用场景迁移只是换模型的事。