根据您补充的业务场景，这已经涉及到了**硬件交互逻辑**和**岗亭工作流**的设计。这比单纯的计费算法更贴近实际落地。
我将针对您描述的两种主要模式（月租/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联动）
```mermaid
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小时”，则语音提醒“月租即将到期，请及时续费”。
这套逻辑梳理涵盖了您提到的硬件交互细节，您可以直接基于此流程图编写开发文档。