Fix Update – 開発状況

1.1.8 リリース済み

なぜバージョン1.1.8はこれほど大規模なのですか？

車両と画面表示の間には、Bluetooth通信、データフラグメント、デコード、状態管理、ユーザーインターフェースがあります。そのためバージョン1.1.8では、データの経路全体を見直しています。

進捗

1. 1

   現状を理解する

   完了

   車両への問い合わせ、Bluetooth通信、Tespit での更新を、一連のデータパスとして調査しました。

2. 2

   データパス全体を計測可能にする

   完了

   内部の計測チェーンが、問い合わせからアプリでの表示までの更新を追跡します。

3. 3

   応答駆動の更新

   完了

   新しい問い合わせは、車両の応答が実際に完了したタイミングにより強く合わせて行われます。

4. 4

   走行データを単独でテストする

   完了

   速度、出力、シフトポジションを、追加情報とは独立して調査しました。

5. 5

   走行データを優先する

   完了

   タイミングが重要な値を優先し、空調、メディア、充電などの追加データはサイクル全体に公平に分配します。

6. 6

   診断とログ記録

   完了

   ローカルでの開発・テスト走行向けに、技術的なイベントを時系列で追跡できる診断システムを構築しました。

7. 7

   自動トランスポートリカバリー

   完了

   まれに未完了のまま残るBluetooth書き込み処理に対して、制御された復旧の仕組みを開発しました。

8. 8

   まれな途切れを調査する

   完了

   一部の応答で不完全なデータパケットが確認されました。繰り返し現れる時間的パターンの正確な原因は、明確には裏付けられていません。

9. 9

   リカバリーを完全に分離する

   完了

   古い不完全な応答が、新しい復旧の試行に入り込んではなりません。

10. 10

    途切れをより早く検出する

    完了

    有効だが遅い応答を早まって中断することなく、不完全なデータパケットをより早く検出します。

11. 11

    遅い応答を正しく判別する

    完了

    有効だが遅い応答は検出され、そのまま処理が続けられます。リカバリーが作動するのは、それよりかなり後になってからです。

12. 12

    すべての車両データでの日常利用

    完了

    現在、高速な走行データパスを、通常の利用状況でメディア、空調、充電、タイヤ空気圧、ドア、位置情報とあわせて検証しています。

13. 13

    一貫した車両状態

    完了

    関連する値は、一貫した状態としてインターフェースに渡されるようにします。

14. 14

    独自のテレメトリー処理

    完了

    通信、データ処理、インターフェースを、技術的により明確に分離します。

15. 15

    パフォーマンスの最終調整

    完了

    不要な切り替え、古いWorkItem、冗長な処理を改めて見直します。

16. 16

    最終リリース承認

    完了

    新しいデータパスを、車両ハードウェア、iPhone、iPadで一体として検証します。