基于Matlab的汽车出入库计时计费系统设计：状态机与规则引擎实践

去年做课程设计时，我选了“基于Matlab的汽车出入库计时计费系统设计”这个题目。一开始觉得这项目太简单了——记个入场时间，再记个出场时间，拿出去减一下乘个单价，完事。可真动手才发现，这套系统里最麻烦的从来不是“怎么算钱”，而是“怎么准确地确定该算多少钱”：重复刷卡、跨天停车、免费时段、封顶价格、同一辆车在库里停了两天却只刷了一次入场……这些边角情况才是真正吃时间的地方。这篇文章就把我完整做完这套系统的设计思路、状态机设计、计费规则抽象、界面搭建和联调踩坑过程全部梳理一遍，适合正在做课程设计，或者想用Matlab快速搭一个小型管理系统的同学参考。

1. 需求拆解：一个“记时间乘单价”的系统为什么值得仔细设计

1.1 从需求文档里挖出真正的功能点

题目叫“汽车出入库计时计费系统”，听起来功能边界很清楚：车辆进库记时间，出库算费用。但如果你真的按这个理解去设计，做到一半必然返工。因为任何一套真实的计时计费系统，它的需求都比表面多一层。

我把这类系统的共性需求拆成五块：

• 车辆入场登记：记录车辆标识和入场时刻。
• 车辆出场结算：根据入场时刻和出场时刻计算停车时长。
• 计费规则计算：支持免费时长、按小时计费、封顶费用、夜间优惠等不同规则。
• 记录查询与管理：能够查看当前在库车辆、历史出入库记录、累计费用。
• 界面交互：管理人员可以手动输入车牌、触发入场和出场、查看费用结果。

这里有一个容易被忽略的点：计费规则不是一成不变的。有的停车场前15分钟免费，有的按30分钟一个计费单元，有的夜间有固定价，有的每天有封顶。如果一个系统把计费规则写死在代码里，那它只能算作业，不能算系统。所以从需求分析阶段就要把“规则可配置”作为设计目标。

1.2 Matlab选型的理由与代价

很多人会问，做一个进出场计时计费系统，用C#、Java、Python不都行吗？为什么非要用Matlab？

我的回答是：看场景。如果是生产级停车场管理系统，确实不会选Matlab。但如果是课程设计、Matlab课程综合实践、或者快速原型验证，Matlab的优势非常明显：App Designer拖拽式做GUI，datetime类型处理时间差很顺手，表格和结构体天然适合存车辆记录，一行代码就能读写Excel，而且所有东西都打包在一个环境里，不需要搭前后端。

代价也有。Matlab的GUI在并发处理上很弱，不适合做高并发的车牌识别加闸机联动；打包成独立exe需要额外装运行时环境；视觉识别相关工具箱虽然强大但价格不菲。所以我的结论是：Matlab适合做演示级、教学级、单机单入口的出入库管理系统，适合把核心逻辑讲清楚，但不适合直接上生产。认清这一点，后面设计的时候就不会硬往不适合的方向使劲。

1.3 数据流与模块划分

整个系统的数据流可以这样理解：事件触发（入场/出场）→ 更新车辆记录 → 计算费用 → 刷新界面显示。围绕这条线，系统可以拆成四个模块：

• 交互层：App Designer界面，负责接收输入和展示结果。
• 业务层：入场登记、出场结算、计费规则计算。
• 数据层：车辆记录的存储、修改、查询、持久化。
• 时间服务：负责统一获取当前时间。

模块划分的核心原则是单向依赖：界面调业务层，业务层读写数据层，时间服务被业务层调用。实际在Matlab里做不到非常严格的架构分层，App Designer的回调函数天然会把界面和业务粘在一起，但只要你有意识地控制逻辑，把“算钱”的代码独立成函数，后边调试会省很多事。

2. 出入库状态的识别与状态机设计

2.1 手动登记是起点，状态机才是核心

由于不依赖摄像头与车牌识别硬件，这个系统的出入库触发方式一般是人工操作：管理人员在文本框输入车牌号，点击“入场”或“出场”按钮。你可能会觉得这太原始了，但正是这种人工触发方式，反而能暴露出状态设计的必要性。

试想一个场景：车A进场后，管理员不小心又在入场按钮上点了两次，系统是不是会生成两条入场记录？再比如车A出场结算时，管理员先点了“出场”，系统把在库记录删掉了，但闸机没抬，管理员又点了第二次“出场”，系统是不是会报错？

这些问题表面上是操作失误，本质上是系统缺少状态约束。所以我在设计时引入了一个简单的状态机，把所有车辆在系统中的生命周期划分为三种状态：

• 不在场（Out）：库里没有该车的记录。
• 在场（In）：已经登记入场，但尚未出场。
• 结算中（Settling）：已经触发出场，正在计算费用。

对应到操作上，状态转移规则如下表：

状态	触发操作	合法动作	到达状态
不在场	入场按钮	新增记录、记录入场时间	在场
在场	出场按钮	计算时长与费用	结算中
在场	入场按钮	拒绝操作，提示重复入场	在场
结算中	出场按钮	拒绝操作，提示已在结算中	结算中
结算中	确认结算	移除在场记录、写入历史	不在场

这个状态机不一定需要写成一堆类，用一个if判断加一个状态字段就能实现。但设计阶段必须先把这张表想清楚，否则后面写回调函数时，你会不停地遇到“这个按钮到底允不允许在这个状态下被点击”的疑问。

2.2 唯一记录ID和跨天策略

每一辆车可能有多次出入库记录，所以单靠车牌号作为主键是不够的。必须给每条出入库记录生成唯一ID。

我的做法是用车牌号 + 入场时间联合生成记录标识。Matlab里可以直接拼字符串：

recordID = [vehID, '_', datestr(now, 'yyyymmdd_HHMMSS')];

这样即使同一辆车多次入场，也能区分开。实际存储时我会额外用一个自增序号字段，方便后续索引和调试。

跨天处理是另一个容易忽略的点。很多人第一次写这个系统，会下意识认为“入场时间和出场时间都在同一天”。但真实停车场里过夜车是常态。Matlab的datetime类型自带日期，datetime('now')返回的是包含年月日时分秒的完整时间对象，所以比较两个datetime相减的结果是duration类型，天然是精确的。如果你用了datenum或者now，得到的是带小数的天数，也不是不能用，但可读性差很多。统一使用datetime类型是避免跨天bug最简单的方法。

2.3 重复入场与漏登记的处理

重复入场的问题上面已经说了，通过查询在库记录就能拦截。漏登记的问题更隐蔽：一辆车根本没有入场记录，直接点出场结算，系统应该提示“未找到入场记录”，而不是报数组越界。

这两种异常处理后端逻辑上写出来都很简单，但没有框架支撑时，很容易被忘掉。我的习惯是，每个回调函数的第一步都先做数据校验，再写业务逻辑。校验失败就弹提示框，不继续执行。

3. 计费规则引擎：把“灵活收费”从需求翻译成代码

3.1 规则抽象与参数化设计

计费是整个系统最核心的业务逻辑，也是最容易写出“硬编码味儿”的地方。我给自己定的目标是：改计费规则时，不修改业务代码，只调整参数。

我抽出来的参数包括：

• freeMinutes：免费停车时长（分钟），默认15。
• baseFee：首小时基础费用，默认5元。
• hourlyRate：超过首小时后，每小时费用，默认3元。
• maxDailyFee：单日封顶费用，默认20元。
• nightDiscount：夜间时段折扣系数，默认0.5，可配置为固定金额。

有了这些参数，计费函数就能统一处理大多数需求。如果要改成“前两小时10元”，就把baseFee改成10、把免费时长改成120，业务代码不用动。这就是参数化设计的意义。

3.2 计费核心函数实现

计费函数的输入是入场时间和出场时间，输出是应收费用。核心逻辑分四步：

第一步，计算总停车分钟数：

totalMinutes = minutes(outTime - inTime);

注意，minutes()函数返回的是double类型的数值，如果不足一分钟，结果是小数。但现实中计费一般按分钟或小时取整，所以后面要处理进位。

第二步，扣除免费时长：

billableMinutes = max(totalMinutes - freeMinutes, 0);

第三步，按计费单元向上取整。我采用“按小时计费，不足一小时按一小时算”的规则，所以要用ceil：

billableHours = ceil(billableMinutes / 60);

第四步，计算阶梯费用：

fee = baseFee + max(billableHours - 1, 0) * hourlyRate;

最后加上封顶判断：

fee = min(fee, maxDailyFee);

组合成一个完整函数：

function fee = calcParkingFee(inTime, outTime, params) totalMinutes = minutes(outTime - inTime); billableMinutes = max(totalMinutes - params.freeMinutes, 0); if billableMinutes <= 0 fee = 0; return; end billableHours = ceil(billableMinutes / 60); fee = params.baseFee + max(billableHours - 1, 0) * params.hourlyRate; fee = min(fee, params.maxDailyFee); end

这里有一个容易出错的细节：免费时长和基础费用的关系。我的设定是“先免费15分钟，然后首小时内5元，之后每小时3元”，也就是说停1小时10分钟，扣除免费15分钟后剩55分钟，按一个小时计5元，这是没问题的。但如果你把免费时长和首小时做叠加，逻辑就会变得很混乱，写之前最好在白纸上画清楚规则。

3.3 跨时段与封顶费用怎么合并计算

前面那个函数是最简版本，处理单一时段费率没问题，但夜间优惠、跨天封顶它就没法覆盖了。我在课程设计中增加了夜间折扣规则，做法是：把停车时间段按天切片，每一天单独计算当天费用，再累加。

思路是：

1. 从入场时刻inTime开始，循环到出场时刻outTime。
2. 每一天设置一个起止时间，例如当天00:00到24:00，但第一天的起点是入场时刻，最后一天的终点是出场时刻。
3. 对每一天的时间段，判断是否覆盖夜间区间（比如22:00到次日06:00）。
4. 有覆盖就按折扣规则计算，没覆盖就按白天的阶梯费率计算。
5. 每天的封顶费用单独应用。

这个逻辑用循环写：

dayStart = inTime; fee = 0; while dayStart < outTime dayEnd = min(dateshift(dayStart, 'start', 'day') + days(1), outTime); segMinutes = minutes(dayEnd - dayStart); if isNightSegment(dayStart, dayEnd) fee = fee + calcNightFee(segMinutes, params); else fee = fee + calcDayFee(segMinutes, params); end dayStart = dayEnd; end

dateshift(dayStart, 'start', 'day')会把时间归一化到当天零点，这是Matlab里处理跨天很实用的函数。按天切片的方式保证了跨多天的停车不会被单日封顶限制整个账单。

我这个版本的夜间计费没有做得太复杂，因为再复杂就超出课程设计的范围了。但你要知道，计费规则的可扩展性直接决定这个项目是“作业”还是“作品”。哪怕当前需求只需要最简单的按小时计费，我也建议把计费写成独立函数，把参数集中放在一个结构体里。后续加规则时，只需要加函数分支，而不需要动主流程。

4. App Designer界面与数据存储设计

4.1 GUI方案对比：为什么选App Designer

Matlab做界面有三种常见方案：GUIDE、App Designer、纯代码figure+uicontrol。很多老教程还在用GUIDE，但MathWorks官方早在R2020a之后就宣布GUIDE不再推荐使用，新项目建议全部迁移到App Designer。原因很实际：

• App Designer基于现代uifigure体系，界面观感比GUIDE好一个时代。
• 自带组件齐全：文本框、按钮、表格、对话框、定时器都有对应封装。
• 回调和组件访问方式统一，都是app.组件名.属性，不需要手动维护handles结构体。
• 自动生成类定义，可以直接在类里加自定义属性和方法，天然适合OOP思路。

所以我的建议很直接：新项目一律用App Designer，不要为了学旧技术浪费时间在GUIDE上。

4.2 界面布局与组件选型

我设计的界面分为四个区域：

• 顶部是标题栏和当前时间显示。
• 左侧是操作区：车牌输入框、入场按钮、出场按钮、费用显示标签。
• 中间是在库车辆表格，用uitable实时展示当前车库内的车辆。
• 右侧或底部是历史记录表格，展示已完成结算的出入库记录。

设计时重点考虑的是操作流顺畅：管理员输入车牌号后，按回车应该默认执行“出场结算”还是“入场登记”？我的方案是提供两个并列按钮，入场按钮和出场按钮分开，避免出错。回车默认触发入场，因为在实际场景中，入场的操作频率往往高于出场。

界面组件选型上，有几个细节值得一说：

• 车牌输入框用EditField，回车事件绑定入场回调。
• 费用显示用Label组件，结算后将费用格式化为字符串写入。
• 在库车辆表用UITable，数据直接传入table类型，显示效果最好。
• 历史记录表同样用UITable，通过切换按钮决定显示哪一张表，或者直接分页显示。

4.3 数据持久化：从struct到.mat文件

程序运行过程中的数据都存在内存里，但程序一关就全丢了。课程设计一般要求数据能保存下来，最简单的方案是用save/load读写.mat文件。

我的数据结构是：

% 每条记录字段 newRecord.vehID = vehID; newRecord.inTime = inTime; newRecord.outTime = NaT; newRecord.fee = 0; newRecord.status = 'in'; % 'in' 在库, 'done' 结算完成

全部记录放在一个struct数组里，records的每个元素就是一条记录。为什么不用多个变量分别存？因为struct数组可以通过records(idx)索引，配合arrayfun、strcmp可以很方便地做筛选。比如查询某辆车在库记录：

idx = find(strcmp({records.vehID}, vehID) & strcmp({records.status}, 'in'));

保存数据也很简单：

save('parking_data.mat', 'records', 'params');

程序启动时在startupFcn回调中：

if isfile('parking_data.mat') load('parking_data.mat', 'records', 'params'); else records = struct('vehID', {}, 'inTime', {}, 'outTime', {}, 'fee', {}, 'status', {}); params = struct('freeMinutes', 15, 'baseFee', 5, 'hourlyRate', 3, 'maxDailyFee', 20); end

.mat文件的好处是读写快、不需要额外工具箱、保留原生Matlab类型。缺点是没法被其他系统直接读取。如果需要给外部系统用，可以加一个导出Excel的功能，Matlab里用writetable就能一键搞定。我在项目中同时做了.mat持久化和Excel导出，这样既方便程序自动恢复，也方便人工查看明细。

5. 核心代码实现：入场、出场、计费的完整链路

5.1 入场登记回调：校验、查重、写入记录

入场回调函数是用户点击“入场”按钮后执行的事件。完整逻辑分四步：

第一步，读取输入并检查格式。

vehID = strtrim(app.VehicleIDEditField.Value); if isempty(vehID) uialert(app.UIFigure, '请先输入车牌号', '提示'); return; end

这里用strtrim去掉首尾空格，避免用户不小心敲了空格导致同一辆车被识别成两个不同ID。

第二步，查重。查询该车是否已经在库内：

inIdx = find(strcmp({records.vehID}, vehID) & strcmp({records.status}, 'in')); if ~isempty(inIdx) uialert(app.UIFigure, '该车辆已在库内，不能重复入场', '提示'); return; end

这个查重本质是状态机里的“在场”状态约束。没有这一步，连续点两次入场就会生成两条在库记录，结算时就会出现一条车对应多笔账单的问题。

第三步，创建新记录并追加。

newRecord.vehID = vehID; newRecord.inTime = datetime('now'); newRecord.outTime = NaT; newRecord.fee = 0; newRecord.status = 'in'; records(end+1) = newRecord;

这里有一个容易踩的坑：如果records一开始是空struct数组，直接records(1) = newRecord会报错。所以初始化时要用struct('vehID', {}, ...)创建空结构并保证字段一致。

第四步，刷新表格和状态显示。

app.CurrentTable.Data = getInTable(records); app.TimeLampLabel.Text = datestr(datetime('now'), 'yyyy-mm-dd HH:MM:SS');

getInTable是我写的一个辅助函数，从records里筛出status == 'in'的记录，转成table类型供UITable显示。

5.2 出场结算回调：查找、计时、计费、移除

出场结算回调比入场稍复杂，因为要计算费用。逻辑如下：

第一步，查找在库记录。

idx = find(strcmp({records.vehID}, vehID) & strcmp({records.status}, 'in'), 1, 'last'); if isempty(idx) uialert(app.UIFigure, '未找到该车辆的入场记录', '提示'); return; end

第二步，计算停车时长和费用。

outTime = datetime('now'); app.records(idx).outTime = outTime; params = getParams(app); % 从界面读取计费参数 fee = calcParkingFee(records(idx).inTime, outTime, params); records(idx).fee = fee;

第三步，更新记录状态并展示结果。

records(idx).status = 'done'; app.FeeLabel.Text = sprintf('%.2f 元', fee);

这里有个设计选择：结算完成后，这条记录应该从在库列表里直接删除，还是保留在同一个数组里并标记为“done”？我的方案是保留并标记，这样历史记录和当次单据都有据可查。在库表格筛选status == 'in'，历史表格筛选status == 'done'，两份数据都来自同一个records数组，不会出现数据不一致的问题。

5.3 用OOP思路整理代码结构

App Designer自动生成的是一个继承matlab.apps.AppBase的类。在这个类里，除了组件回调，我还会写几个自定义方法：

• getInTable()：把在库记录转成table。
• getHistoryTable()：把结算记录转成table。
• refreshAll()：统一刷新两个表格和状态标签。
• resetOperation()：结算后清空输入框和费用标签。

这样做的原因很实际：随着功能增多，回调函数之间往往需要重复调用“刷新表格”的逻辑。如果把刷新代码复制三遍，后面改动字段时很容易漏改一处，造成两个表格显示不一致。用OOP思路把这些操作收敛为类方法，调用方只需要一行代码，维护成本低很多。

整体的代码结构是：

classdef ParkingApp < matlab.apps.AppBase properties records % struct数组，存储全部记录 params % 计费参数配置 end methods (Access = public) function refreshAll(app) % 统一刷新界面 end end methods (Access = private) function result = getInTable(app) end function result = getHistoryTable(app) end end % 回调函数区域 methods (Access = private) function EntryButtonPushed(app, event) end function ExitButtonPushed(app, event) end end end

这种写法在课程设计答辩时也特别加分。老师问你“代码架构是什么样”，你可以直接说“我用了面向对象的方式，把界面回调、业务逻辑、数据存储做了分层”，然后展示这个类的结构。这比甩出一段几百行的大脚本要有说服力得多。

6. 联调实测与典型问题定位

6.1 测试用例设计与计算结果核对

系统做完之后，联调阶段最重要的工作是设计测试用例。我把测试分成正常流程和异常流程两组。

正常流程测试用例：

场景	入场时间	出场时间	期望费用	说明
免费时长内出场	10:00:00	10:12:00	0	15分钟内免费
整1小时	10:00:00	11:00:00	5	首小时基础费
1小时20分钟	10:00:00	11:20:00	5	扣除免费15分钟后，不足一小时按一小时
3小时	10:00:00	13:00:00	11	首小时5元+后两小时每小时3元
跨天停车	18:00:00	次日08:00:00	20	触发单日封顶或夜间规则

异常流程测试用例包括：空车牌入场、已有在库记录重复入场、无记录直接出场、连续两次点出场按钮。这些用例的目的不是验证“能不能算对”，而是验证**“算不对时系统能不能给出明确提示，而不是崩溃”**。

联调时我的方法是把入场和出场按钮做成可连点，然后用一个模拟车牌反复测试，同时观察在库表格和历史表格的数据变化。只要发现某一次操作后两张表的数据对不上，马上停下来查代码——这通常意味着某个分支没有处理到位。

6.2 我踩过的四个坑和排查思路

坑一：minutes()返回的是double，直接用于计费产生了小数。停1小时1分钟，总分钟是61，扣除免费15分钟后剩46分钟，ceil(46/60)=1小时，费用5元，没出问题。但如果不做ceil，直接按46/60的处理就会出现0.76小时这种可笑的计费结果。排查思路是：在计费函数入口打印三组数值——totalMinutes、billableMinutes、billableHours，一眼就能看出进位有没有落实。

坑二：空struct数组追加记录报错。这个问题看起来很基础，但第一次运行时确实会被绊住。排查思路是查一下records初始化的写法，确保struct的字段顺序和追加记录完全一致。后来我改用了一个习惯性做法：先用一条假数据初始化，再在程序启动时清空它，这样能保证所有字段都被Matlab正确识别。

坑三：跨天计费时费用偏低。一开始我的计费函数没有按天切片，直接用总分钟数去套单日封顶，结果过夜车只收了封顶价，等于停一天一夜和停一个白天一个价。排查思路是把时间段按天拆分，逐段计算，最后累加。这里的关键是想到“封顶应该作用在每一天，而不是整个账单”。这个逻辑不画图很难发现，所以我在白板上画了跨天时间轴才定位到问题。

坑四：UITable的Data赋值报维度不匹配。排查思路是检查转出的table变量行数是否和表格当前显示行数一致。因为UITable的Data属性赋值时要求新旧数据维度一致，如果之前有10行，现在只剩3行，就需要先清空再赋值。最简单的做法是直接给Data赋一个空的table再赋新数据，或者用Data = {}先清空。

6.3 可以继续扩展的方向

如果这个系统要继续往下做，我觉得有三个方向值得考虑：

第一，接入图像识别。Matlab的Computer Vision Toolbox可以检测车牌区域并用OCR识别车牌号，这样入场登记就不需要人工输入车牌。但要注意，这需要额外的摄像头设备和硬件联调，复杂度会上升一个量级，优先级应该排在所有核心功能稳定之后。

第二，数据存储升级。当记录超过几千条时，.mat文件的读写效率会下降。可以考虑用sqlite数据库，Matlab从R2021a开始内置了sqlite接口，不需要额外安装驱动。这个改动能把系统从“单机Demo”往“真正可用的小系统”推进一步。

第三，费用统计报表。基于历史记录做按天、按周的营收统计，用bar或plot函数绘制图表，展示停车场的使用率和收入趋势。这个功能在答辩时展示效果很好，而且实现难度不高，核心就是把结算记录按日期分组后聚合。

最后分享一点个人体会

做完这个项目，我最大的感觉是：一个系统难的不是主流程，而是异常分支。入场登记、出场结算、费用计算这些主干逻辑，几乎所有教程都会教；但重复入场怎么拦、查不到记录怎么提示、跨天怎么算、封顶怎么叠——这些才是真正决定系统能不能用的地方。如果你也在做类似的设计，建议一开始就画好状态表和规则表，把“正常情况”和“异常情况”分两栏列出来，代码只是把表格翻译成Matlab而已。另外，测试的时候不要只测正常流程，尽量用脏数据去折腾它——把能想到的误操作都试一遍，系统扛得住这些折腾，才算真正做完。