dex-embeddedの仕組み
ゲートウェイ（dex-gateway）はRustで書かれた単一のプログラムで、MDVR上のサービスとして動作します。Bluetoothでウォッチをリッスンし、オペレーターを特定し、すべてをローカルに保存して、パートナーのソフトウェアにイベントを届けます。
ウォッチ ──BLE──▶ dex-gateway ──▶ ローカルAPI（gRPC）──▶ パートナーのソフトウェア
│ └──▶ MQTT（任意）
└─────────▶ Dersalisクラウド（インシデントとテレメトリ）
4つの設計判断
1. Bluetoothは聞くだけで、接続しない
ウォッチは、Bluetoothの各アドバタイズに、ゲートウェイが必要とする情報（勤務、インシデント、状態）をすでに含めて送信しています。ゲートウェイはこのアドバタイズを観測するだけ（パッシブスキャン）です。これにより、デバイスごとの接続を維持するコストと脆弱性を避けられ、ペアリングも不要です。
2. オペレーターは機器の内部で特定する
ウォッチのアドバタイズには従業員識別子の先頭部分しか含まれず、それだけでは特定できません。ゲートウェイはクラウドから会社の従業員とモニタリングの一覧をダウンロードしてメモリに保持し、各イベントをその一覧と照合してその場で、ネットワークを使わずに特定します。
そのため、接続が切れていても機器はオペレーターの状態を処理し続けます。クラウドに依存するのは一覧の更新だけで、それもオペレーターが勤務を開始したときに実行され、常時ではありません。
3. お客様のソフトウェアは特定済みのイベントを受け取る
お客様のソフトウェアがBluetoothや内部識別子を目にすることはありません。契約はローカルAPI（gRPC、127.0.0.1、機器の内部からのみアクセス可能）で、オペレーターの登録番号とモニタリング名が解決済みのフィールドとして含まれます。契約にはバージョンがあり、v1の範囲ではフィールドの追加のみが行われます。
機器にgRPCライブラリをビルドしたくない場合は、同じイベントを1イベント1行のJSONとして出力するdex-eventsを使えます。バスを使いたい場合はMQTTで配信します。
4. 配信の前にすべてを書き込む
各イベントは、デコードと特定が終わり次第、重複排除付きの耐久性のあるローカルキュー（SQLite）に入ります。ウォッチは、インシデントが有効な間、同じインシデントを数秒ごとに繰り返し送信しますが、それは1件のレコードにまとめられ、インシデントの進行に合わせて更新されます。
このキューにより、Bluetoothの取得がローカルAPIやクラウド同期から切り離されます。ネットワーク障害やパートナーのソフトウェアの停止があっても、何も失われません。
機器に残るもの
- ゲートウェイの勤務（ジャーニー）： インシデント、状態、注意力テストが属するコンテナです。パートナーのソフトウェアが、どのオペレーターを追跡するか、いつシフトが終わるかを指示して制御します。
- 保持： データは勤務とともに存在します。勤務の終了後、ゲートウェイは、クラウドに配信済みでかつパートナーが確認済みのデータを削除し、機器のストレージが無制限に増えないようにします。
- プライバシー： オペレーターの氏名は保存されません。注意力テストの結果は健康データです。ローカルAPI、およびパートナーがテレメトリを有効にした場合はクラウドのみを経由し、ログには決して書き込まれません。
クラウドは？
ゲートウェイは、特定済みのインシデントをバックグラウンドで軽量にDersalisクラウドへ送信します。任意のテレメトリ（車両の位置、ゲートウェイとウォッチの状態）もありますが、初期状態では無効です。ゲートウェイは、お客様のソフトウェアへイベントを届けるためにクラウドに依存しません。