lc_garage/doc/收费流程.md

根据您补充的业务场景，这已经涉及到了硬件交互逻辑和岗亭工作流的设计。这比单纯的计费算法更贴近实际落地。

我将针对您描述的两种主要模式（月租/VIP、临时车），梳理成详细的进出场业务流程图，供开发对接使用。

一、 月租车 / VIP车 流程梳理

核心逻辑： 身份识别 -> 权限校验（有效期） -> 自动放行。

1. 进场流程

• 触发方式 A：车牌识别（摄像头）
  1. 车辆驶入入口，触发地感/红外。
  2. 摄像头抓拍，系统识别车牌号。
  3. 系统查询数据库：
     • 查询 确认是否为月租车/VIP。
     • 检查 Expire_Date（过期时间）。
  4. 判断逻辑：
     • 有效： 语音播报“欢迎光临，月租有效”，自动开闸。
     • 过期： 语音播报“月租已过期”，转为临时车流程（视策略：拒绝入场 或 按临时车入场）。
  5. 记录入场日志（车牌、时间、快照）。

• 触发方式 B：刷卡/RFID（非车牌识别）

  1. 车主在入口票机/读卡器处刷卡/RFID卡。
  2. 系统读取卡片ID，通过ID查询绑定的车辆信息。
  3. 校验有效期（逻辑同上）。
  4. 有效： 开闸放行。

  5. 注意：此类进场通常需要人工辅助确认车辆身份，或配合视频录像留存。

     2. 出场流程

• 流程：

  1. 车辆驶入出口，触发识别（车牌或刷卡）。
  2. 系统校验状态：
     • 是否有入场记录？
     • 月租是否在有效期内？
  3. 判断逻辑：
     • 有效： 语音播报“一路顺风”，自动抬杆放行。
     • 过期：
       • 策略1：拒绝出场，需去岗亭缴费续费后放行。
       • 策略2：自动转为临时车计费，需缴纳临时停车费。

  4. 记录出场日志，销除在场车辆记录。

     二、 临时车 流程梳理

     核心逻辑： 取票进场 -> 扫码计费 -> 支付确认 -> 放行。

     1. 进场流程（统一取票）

• 动作：

  1. 车辆驶入入口，驾驶员按下票机按钮（或自动感应出票）。
  2. 票机动作：
     • 打印二维码小票（包含：入场时间、流水号、二维码）。
     • 系统后台： 生成一条“无车牌”或“待关联”的入场记录。
  3. 道闸开启，车辆进场。

  4. 痛点提示： 此时不识别车牌，出场时完全依赖小票。若小票丢失，需人工核对入场记录（通过入场抓拍图片）。

     2. 出场流程（非人工自助缴费）

• 场景： 票机自带扫码枪 + POS机连接

• 流程：

  1. 驾驶员在出口票机处，将小票二维码对准扫码窗。
  2. 系统计算：
     • 解析小票获取入场时间 ($T_{in}$)。
     • 获取当前时间 ($T_{out}$)。
     • 调用计费引擎，算出金额 Amount。
  3. 交互：
     • 屏幕/语音提示：“请缴纳费用 XX 元”。
     • 票机连接的POS机进入待支付状态。
  4. 支付：
     • 驾驶员在POS机上刷卡（银行卡/会员卡）。
     • POS机返回“交易成功”信号给票机/系统。

  5. 结果：

     • 系统接收到支付成功信号 -> 下发开闸指令 -> 道闸抬杆。

     • 票机打印/吐出收据凭证（可选）。

       3. 出场流程（人工收费）

• 场景： 现金支付，需岗亭保安协助

• 流程：

  1. 驾驶员到达出口，将小票交给保安，或自己在票机扫码。
  2. 系统计算：
     • 屏幕显示计费金额（保安岗亭端可见）。
  3. 人工交互：
     • 保安收取现金（纸币/硬币）。
     • 保安在管理软件界面点击“现金收款”或“确认放行”。

  4. 结果：

     • 系统记录“现金支付”流水。

     • 软件下发开闸指令 -> 道闸抬杆。

       三、 系统交互逻辑图解 (开发梳理)

       为了方便您开发，我将上述逻辑转化为系统的模块交互序列：

       场景：临时车非人工出场（票机+POS联动）

       sequenceDiagram
       participant User as 驾驶员
       participant Machine as 出口票机(硬件)
       participant Server as 管理服务器
       participant POS as 刷卡POS机
       User->>Machine: 扫描小票二维码
       Machine->>Server: 上报票号/入场ID
       Server->>Server: 查询入场时间，计算费用
       Server-->>Machine: 返回金额 (例如: 15元)
       Machine->>User: 屏幕显示/语音播报金额
       Machine->>POS: 发送扣款指令 (金额15元)
       User->>POS: 刷卡支付
       POS->>POS: 银行卡扣款处理
       POS-->>Machine: 返回扣款成功信号
       Machine->>Server: 上报支付成功
       Server->>Server: 更新订单状态为“已支付”
       Server-->>Machine: 下发开闸指令
       Machine->>Machine: 触发道闸抬杆
       

       ---

       四、 关键技术点与开发建议

       在实现这套逻辑时，请重点关注以下几个技术细节： 1. 票机与服务器的通信协议

• 票机通常通过 TCP/IP 或串口与服务端通信。

• 建议： 采用心跳包机制。服务器需要知道票机是否“在线”。如果票机断网，应立即报警，避免车辆堵在出口。 2. 小票二维码的数据安全

• 小票上的二维码是进出的唯一凭证。

• 建议： 二维码内容不要直接写“时间:20231010”，容易被伪造。建议生成一个加密的UUID或动态Token，服务器端通过Token反查入场记录，防止逃票。 3. POS机支付的异步回调

• 刷卡支付可能有延迟（网络波动）。

• 建议： 票机端应设置“支付等待状态”（比如等待30秒）。如果POS机返回成功，但票机没收到信号，需要有“重试机制”或“人工干预按钮”，避免道闸不开导致堵车。 4. 无牌车/无票车的兜底逻辑

• 进场： 取票进场，但进场时摄像头没拍到车牌。

• 出场： 用户票丢了。

  • 解决方案： 保安端软件需提供“查询入场记录”功能，通过时间范围查找入场记录，并匹配摄像头抓拍的图片，确认后手动补交费放行。 5. 月租车“过期”的临界点处理

• 如果月租车在进场时有效，出场时过期了怎么办？

• 逻辑建议： 通常允许出场（因为在场内过期不应惩罚），或者在进场时检查如果“距离过期少于1小时”，则语音提醒“月租即将到期，请及时续费”。 这套逻辑梳理涵盖了您提到的硬件交互细节，您可以直接基于此流程图编写开发文档。