dex-embedded 的工作原理
网关（dex-gateway）是一个用 Rust 编写的单一程序，作为服务运行在 MDVR 上。它通过蓝牙监听手表，
判断操作员是谁，在本地保存所有数据，并把事件交给合作伙伴的软件。
手表 ──BLE──▶ dex-gateway ──▶ 本地 API（gRPC） ──▶ 合作伙伴的软件
│ └──▶ MQTT（可选）
└─────────▶ Dersalis 云端（事件和遥测）
四个设计决策
1. 蓝牙只监听，从不连接
手表在每个蓝牙广播中已经带有网关所需的一切：班次、事件、状态。网关只是观察这些广播（被动扫描）。 这避免了为每个设备维持连接的开销和脆弱性，也不需要任何配对。
2. 操作员在设备内部完成识别
手表的广播只带有员工标识符的前缀，单靠它无法确定是谁。网关会从云端下载公司的员工和监控列表并保存在内存中； 每个事件都立即在本地对照该列表解析，无需联网。
因此，即使断网，设备仍能处理操作员状态：只有列表的更新依赖云端，并且在操作员开始班次时触发，而不是持续进行。
3. 您的软件收到的是已解析的事件
您的软件从不接触蓝牙和内部标识符。接口是一个本地 API（gRPC，127.0.0.1，仅设备内部可访问），
字段已经解析好：操作员的工号和监控名称。接口有版本管理：在 v1 版本内只会新增字段。
不想在设备上编译 gRPC 库的用户可以使用 dex-events，它把相同的事件以每个事件一行 JSON 的形式输出。
更喜欢消息总线的用户可以通过 MQTT 发布。
4. 先写入，再交付
每个事件在解码和解析后，立即写入持久的本地队列（SQLite），并去重：手表在事件处于活动状态时每隔几秒就会重复发送同一个事件， 这些会合并为一条记录，并随事件的演变而更新。
这个队列把蓝牙采集与本地 API 和云端发送解耦：断网或合作伙伴的软件停机都不会丢失任何数据。
设备上保存什么
- 网关班次： 事件、状态和注意力测试所属的容器。合作伙伴的软件通过指定要跟踪的操作员以及班次何时结束来控制它。
- 保留： 数据随班次存在。班次结束后，网关会删除已送达云端并且已被合作伙伴确认的数据，避免设备存储无限增长。
- 隐私： 不保存操作员的姓名。注意力测试结果属于健康数据：只通过本地 API 流转，如果合作伙伴开启遥测，也会经由云端，且绝不写入日志。
云端呢？
网关在后台以轻量方式把（已完成识别的）事件发送到 Dersalis 云端。另有可选的遥测（车辆位置、网关和手表的状态），默认关闭。 网关向您的软件交付事件并不依赖云端。