simulink系列之汽车应用层信号处理

总目录

    第一章 simulink信号处理——debounce

    第二章 simulink接口表生成及自动连线脚本

目录

前言

一、debounce（防抖）是什么？

二、simulink模型搭建

1.常规debounce逻辑

2.问题分析

3.改进的模型

总结

前言

本系列主要围绕作者采用simulink进行日常软件开发过程中的实战和思考。话不多说，直接开干。

对于汽车应用层开发人员来说，几乎可以说日常开发接触到最多的东西就是各种报文信号了。因此，本文主要分享一下应用层软件报文信号处理之debounce，作为本系列的第一篇文章。

---

一、debounce（防抖）是什么？

简而言之，当某个应用层软件逻辑中需要处理某个信号。当信号在某个时间点发生变化时，我们认为该信号不算真的改变，而是发生变化并恒定不变保持1秒才算真的改变。这里需要注意，并不是每个信号都需要debounce，具体要根据需求来。

二、simulink模型搭建

常规的debounce采用三段式逻辑。这个我们很容易理解，即信号初始状态为A，发生变化状态变为B，如果在B状态能够维持一定时间（本文采用假定为1s，实际情况可能采用标定值），即切换到状态C。

1.常规debounce逻辑

下图为常规信号debounce逻辑，这个是按照上述常规思维翻译成simulink模型逻辑的。图中的sig表示信号，outSts表示改变的状态。看起来好像没什么问题，但实际上存在两个问题。

问题1：debounce时间需求是1s，实际上不是1s

这里需要对模型执行逻辑有一些基础或者直接从代码看才能知道原因。假设这个状态机从第0个步长开始执行，并且sig输入为1，那么具体分析时这样的：

0step：Init状态时，认为输出没有变化，即outSts仍为false。

1step：sig为1，进入wait状态，清空计数器，以便定时1s。

2-11step:sig为1，保持wait状态，开始计数，保证事件位1s。

从上述过程可以总结出，如果sig输入默认为1，那么从0step开始执行时，最终会需要1s+1step的时间。多出来的时间则是因为Wait状态带来的。

问题2： 状态冗余

这个问题和第一个问题根本原因是一样的，Wait状态带来的问题。

2.问题分析

从上述分析可以看出，只考虑问题1的话，可以让after函数的参数减去1个步长的时间。但是综合考虑两个问题的话，只能考虑干掉Wait这个状态。

如果直接去掉Wait状态，如下图这样，是绝对不行的。

 因为这种场景下，即使没有发生sig=1事件，计数器也会进行计数。等到发生sig=1时，outSts立刻为true，无法debounce。

这里我想到一个方法是使用外循环。如果不会外循环可以参考我的另一篇文章：

simulink 外循环与内循环执行流程_simulink循环模块-CSDN博客

 3.改进的模型

那么，模型可以进一步改成下面这样：

总结

以上就是今天要讲的内容，觉得有用可以关注我后续文章。