CarPrice Inspectorアプリ

オークションに参加する際に車を検査する検査官は、条件を選択する必要はありません。雨、降雪、夏の暑さの中で働いています。 彼らは車を注意深く検査するだけでなく、何百ものチェックリスト項目に記入し、数十枚、または数百枚の写真を撮り、ビデオを録画します。 そして、これらすべては、たくさんの書類、カメラ、カメラなしで、ただスマートフォンと私たちの特別なアプリケーションの助けを借りて。 最近、私たちは車の検査システムの特許を取得しました。 カットの下-詳細を含むストーリー。



車を売りたい人が私たちのところに来たら、車の詳細な検査を実施し、機器を修理し、損傷や隠れた欠陥を調べ、法的な清潔さもチェックする必要があります。 これは検査官によって行われます-CarPrice支店の特別に訓練された車の専門家：数百のポイントのチェックリストによると、彼らは慎重に車を検査し、発見されたすべての欠陥を撮影し、ビデオを撮影してモーターの音を聞き、必要なすべての資格情報を入力します。 車は可能な限りすべての側面と角度から撮影する必要があるため、時には予期せず、最初に第1世代のiPad Miniが検査官用に購入されました。比較的安価で、良いカメラとかなり大きな画面で出てきました。 タブレットでは、検査官は社内サービスのウェブインターフェースに行き、そこですべてのデータを入力しました。



しかし、検査官は、Wi-Fiを備えた加熱されたオフィスの快適な環境で常に働くわけではありません。しばしば、通常の携帯電話通信が不安定になる可能性がある遠隔地の都市外、売り手の領域で車を検査します。 温室条件などのWebアプリケーションや検査官は機動性を必要とし、そのようなインターフェイスを介して大量の写真やビデオをアップロードするのは不便でした。 また、Wi-Fiでさえ常にオフィスの外で捕まえられるわけではないため、従業員は車からオフィスまで走り、まず資料をワークステーションに捨ててからWebサービスにアップロードするという二重の作業を行う必要がありました。







私たちは、検査プロセスを厳密に形式化し、すべての従業員に普遍的で、時間内に予測可能にする本格的なモバイルアプリケーションを開発することにしました。 まあ、それは車の所有者が長い時間待たずに、時計を見つめているように、検査手順をスピードアップします。

建築パターンの選択

検査官がアプリケーションを終了せずに車を検査し、それに関するすべての情報を入力できるように、アプリケーションは元々一種の「スイスナイフ」であると想定されていました。 私たちの考えによると、検査中は次のようになっているはずです。

• 並行して、ファイルの操作、写真やビデオのキャプチャ、メディア（写真、ビデオ、オーディオ）の処理、データウェアハウス、ネットワーク、外部サービスとの対話など、多くのリソース集約型プロセスが実行されます。
• 多数のデータが生成され、複雑なエンティティに結合されます。 これらのエンティティをローカルに保存し、その場で編集することを計画しました。それらはオンラインとオフラインで利用できるはずです。

人類の知識を研究した後、RxJavaを使用した事後対応アプローチに取り組みました。 データと依存関係を変更するためのサブスクリプションを作成し、動的に生成されたチェックリストとデータのビジュアルコンポーネントを確実にリンクする必要がありました。



したがって、私たちのケースでは、基本的なアーキテクチャパターンMVVMが最良の選択でした。これは、モデルと視覚要素との双方向の相互作用を提供し、視覚部分の変更は即座にデータベースに記録および更新されるためです。 開発の柔軟性を高めるために、最近人気のあるDependency Injectionを使用することにしました。これは、ある程度の透明性の喪失に目を向け、エントリーのしきい値を増やします。 その結果、視覚部分と明確に同期した対話システム、大量のデータのバックグラウンド処理システム、およびアプリケーションとフロントエンド内のバックエンド間のデータ交換メカニズムを構築することができました。



モバイルアプリケーションは、2つのノードのみと直接対話します。

• 独自のAPIを介してサーバー部分で 。 RESTの原則に基づいています。 サーバー部分は高度に分岐しており、追加のサービス（法的検証、画像やビデオのサイズ変更、ニューラルネットワークを使用した写真の処理など）にアクセスし、それらからデータを受信して​​クライアントに提供します。
• AmazonAWSを使用してメディアファイルをアップロードし、その後APIメソッドを介して同期します。

開発の開始から最初のバージョンの発売まで2.5か月が経過しました。 当初、バックエンドはチームによって作成され、クライアント自体のアルファ版はモバイル開発を専門とする会社によって作成されました。 残念ながら、この作業は見知らぬ人に任せるには難しすぎることが判明し、チームを編成しました。このチームは、自動車を検査してオークションに出品するための本格的なアプリケーションを作成することができました。



次に、デバイスとアプリケーションのいくつかの側面について詳しく説明します。

スマートフォンの選択

スマートフォンを優先してタブレットを放棄することにしました。 これにはいくつかの理由がありました。 第一に、タブレットではカメラは通常高価なスマートフォンよりも劣っており、撮影の品質は重要な要素でした。なぜなら、それらは衣服で満たされているためです。潜在的な買い手は写真からロットを評価します。 そして、第二に、タブレットはサイズがはるかに大きいため、検査官はしばしばタブレットを落としたり壊したりします。 検査官が車を検査するとき、彼と一緒に：

• 懐中電灯。
• 汚染された部品を拭くためのワイプ。
• 塗装を測定するための厚さゲージ。
• OBDスキャナー

これらはすべて手元にある必要があり、ツールはアイレットの手首によく掛かっています。 さらに、検査員は、静電容量スクリーンの操作に適した手袋、フィラメント、または絶縁体を着用している場合があります。 これをすべて使用するには、チェックリストに記入し、目立って価値のあるデバイスを落とさずに、もう1つまたは2つの手を持っている必要があります。







そして、スマートフォンに切り替えることにしたので、将来のアプリケーションのインターフェースを適切なサイズの画面に適合させる必要がありました。 次の基準に従って、検査官用のデバイスを選択しました。

1. 最も重要なことは、撮影の品質です。
2. バッテリー
3. 保護カバー。
4. +30〜-50の温度範囲で作業します。
5. SDKがサポートおよび開発されるように。
6. 時々雨が降るので、防湿があったこと。

www.techradar.comやwww.cnet.comなどのサイトでスマートフォンの評価とレビューを調査し、パラメーターを分析して、いくつかの異なるモデルを購入しました。 その後、彼らは写真とビデオの機能を綿密にテストし始めました。 降雨時の低照度でのオートフォーカスの動作を確認しました。 射撃の結果に基づいてブラインドテストを実施しました。 結果の写真とビデオのサイズ、マトリックスのノイズレベルを調査しました。 彼らは信頼性をチェックしました：彼らはそれを落とし、凍結し、水をやり、そして一般的に本当に強力なものを選ぶためにあらゆる方法でそれをoffしました。



障害物コース全体は、Sony Z3のみでした。 ところで、私たちが調べた他のスマートフォンよりも多くの反破壊的事件が彼のために生み出されました。

カメラ

写真とビデオの処理量を考えると、標準カメラの機能では不十分であることがすぐに明らかになりました。 少なくとも、そのインターフェイスはアプリケーションに調和して統合されている必要があります。つまり、新しいインターフェイスを作成する必要があります。 そのため、Android SDKのカメラモジュールに基づいてソリューションを開発しました。



検査員は厳密にチェックリストで写真を撮ります。 誰もが写真家として生まれたわけではないので、アプリケーションはスマートフォンを保持する方法に関するヒントを表示します-垂直または水平。 カメラのインターフェイスを離れることなく、検査官は車の次の部分の撮影に進むことができます。







特定の詳細を撮影する際にヒントシステムも実装しました。 たとえば、検査官がVINを撮影すると、検査員がすべてが正常であるかどうかをすぐに確認できるように、テキストでさらに表示されます。 また、写真では車の番号がぼやけていたり、ステッカーが表示されたりしています。











エンジンと排気システムのビデオの撮影を開始したとき、ハードウェアレベルでは、Sony Z3ファームウェアは解像度の変更に対応していなかったという事実に直面しました。 ビデオは、Sony SDKで規定されている標準解像度（フルHD、60フレーム/秒）でのみ作成されました。 また、独自のコーデックを使用しましたが、1分間のファイルには100〜150 MBかかりました。 当然、これはネットワーク、特に3Gでの伝送速度に影響を与えました。 また、SDKはカメラモジュールへのハードウェアアクセスを許可しませんでした。 私は自分自身を苦しめ、送信する前にオンザフライでデコードし、ビットレートとフレームレートを拾うなど、いくつかの後処理ソリューションを試しました。 後処理には少し時間がかかりましたが、大量のバッテリーを「食べて」しまい、アプリケーションが重くなりました。 ソニーはユーザーの嘆願に留意し、ビデオ解像度を変更できるアップデートをリリースするまで、これに失敗しました。

インターフェースとセキュリティ

車両の状態を正式に説明することは簡単なことではありません。 実際、私たちのオークションでは、車だけでなく、オートバイ、ATV、モペット、トラックなども販売できます。 明らかに、各クラスには独自の技術的特徴があります。 そのため、構造要素と車両アセンブリ、機器と損傷の3つのタイプのチェックリストを作成しました。 これらのチェックリストは、アプリケーションの基礎であり、それらのためにすべてが開始されました。



車種ごとに個別のレイアウトを作成しないために、検査対象の車両のタイプに応じて、チェックリストに基づいてインターフェイスを「オンザフライ」で作成する必要があります。 これを行うために、構成ファイルを作成しました。構成ファイルは、クライアントの起動時に現在のバージョンが読み込まれます。 これらのファイルに基づいて、特定の車両のチェックリストインターフェイスが動的に生成されます。 また、自動車に関する情報を入力する特定の段階に移行すると、構成ファイルからデータ構造を取得し、それに基づいてフィールドセットを動的に生成するビジネスロジックのセットを作成しました。 構成ファイルのデータ構造には、入力するフィールドのセット、数、およびタイプだけでなく、これらのフィールド間の依存関係も示されます。 つまり、インスペクターがチェックリストに記入すると、パラメーターが変更されたときに追加のフィールドが表示される場合があります。







たとえば、「車両タイプ」フィールドで「車両」を選択すると、オートバイには表示されないパワーステアリングを選択するためのフィールドが表示されます。 当然、トップレベルの依存関係を変更するとき-たとえば、VAZ-2109に関する会議に記入し、突然Harley-Davidsonを選択することに決めました-インターフェイスが再構築されています。



これは機動のための途方もない部屋を提供します。 たとえば、チェックリストの順序を変更したり、追加オプションを導入したりするために、フロントエンドを変更する必要さえありません。 そのため、アプリケーションを再構築したり、市場に投入したり、他の操作を台無しにしたりする必要はありません。 レルムORMは、構成ファイルの保存に使用され、読み取り速度の点で最速のORMの1つです。



アプリケーションは非常に珍しい承認です。 検査官は自分のアカウントの下でのみ入力できるという事実に加えて、彼は勤務時間中に自分の支店の下でのみこれを行うことができます。



また、アプリケーションはGoogle Playで企業ドメインのみに配布されるため、インストールAPKファイルをアプリケーションを使用するパートナーに転送します。

バックエンド

バックエンドは、いくつかの論理部分で構成されています。



構成ファイルジェネレーター：ファイルを作成するサービス。これに基づいて、アプリケーションの起動時にユーザーインターフェイスが生成されます。



自動チェックボックス：これは、車と所有者に関するデータ（VIN、STS、PTS、登録番号、所有者の名前など）がHTTP要求を介して検査官のアプリケーションから転送される別個のサービスです。 Avtochekはさまざまなサービスでこのデータを自動的にチェックします。現在約15のサービス（オートコード、交通警察、AVInfo、FMS、FNPなど）で各チェックのスクリーンショットを撮り、罰金の数、金額、登録アクションの制限に関する情報を保存します、TCPのVIN番号、事故への自動車の参加、最後のMOTの時点での走行距離による。 すぐに、検査官は車に関する完全なレポートを受け取ります。 車が「問題がある」場合、検査官はそれ以上の検査を拒否し、売り手に別れを告げることができます。



スター：これは、4つのカテゴリ（ボディ、サロン、技術的条件、関連要因）で自動車を自動的に評価するためのサービスです。 それらのそれぞれに対して、1〜5個の星の評価規則が構成されます。 「付随要因」を除くすべてのカテゴリは、損傷の数と範囲に基づいて計算されます。 付随する要因は、TCPの所有者の数、車が保証期間中かどうか、サービスブックがあるかどうか、走行距離などのパラメーターによって評価されます。 合計で、車は20個以下の星を獲得できます（各カテゴリで5個）。 ほとんどのロットには10​​〜15個の星が付いており、オークションで9個以下の星で「殺された」車を獲得することは非常にまれです。 15を超える-これはほぼ完璧な状態であり、そのような車は最高のオークション評価に含まれています。



すべてのバックグラウンドタスクとプロセス（データのチェック、ロード、送信）は、非同期に処理される別個のスレッドとして実装されます。 RXコンポーネントの基礎となるObserverパターンのおかげで、このデータはすべて1か所で収集されます。 すべてのタスクが完了すると、バックグラウンドスレッドの結果をいつでも取得できます。



ネットワークを操作するには、クラシックバンドルRetrofit 2 + OkHttp 3を使用します。1回の検査で、合計で約300 MBの写真が40〜300枚、さらにはビデオまで届くため、非常に大量のデータをネットワーク経由で送信する必要があります。 ご存知のように、車が古くて粗末なほど写真が多くなり、大部分の車では70〜150枚で十分です。 マシンが非常に古く、「死んでいる」場合、単純化されたスキームに従って検査され、損傷は記録されません。



メディアストレージにAmazon AWSを選択しました。 バックエンドは新しいファイルを時間通りに認識する必要があるため、各ファイルのメタデータを含む通知は、ストレージへのアップロードと同時にサーバーに送信されます。



すでに述べたように、インターネットは検査中に常にアクセスできるとは限りません。 また、高速インターネットはほとんど贅沢品です。 したがって、アプリケーションにはオフラインおよびオンラインの操作モードがあります。 接続されていない間、検査官は安全にデータを収集し、フォームに記入し、写真やビデオを撮ります。 情報はスマートフォンのデータベースに蓄積されます。 また、ネットワークが表示されるとすぐに、スレッドプールを介した段階的なデータ送信が開始されます。これは、チェックリストがすでにいっぱいになっているかどうかに関係なく、複数のスレッドで非同期に行われます。 そして、検査官が検査を完了して「送信」ボタンを押すと、ほとんどの情報はすでにリポジトリにあります。 タスクのシーケンスを管理し、その実装を制御するために、一連のJobQueryツールを開発しました。

OBD（オンボード診断）

ジャックとドライバーを備えたキーのセットだけで車を修理できる時代はもはや過ぎ去りました。 現代の車には、OBDセンサーなどの電子機器が詰め込まれています。これは、オンボード診断バスです。 そして、このツールを使用しないことは私たちにとって罪でした。 しかし、パブリックドメインでは、OBDに関する技術資料はほとんどありませんでした。 さまざまなOBDモジュールとの基本的な相互作用を確立できる小さなオープンソースプロジェクトはわずかです。 当初は、これらのプロジェクトの1つを基礎として、その過程で機能を拡張しましたが、多くの困難がありました。



特定のエラー（エアバッグなど）を診断できるデータ交換用の汎用プロトコルはありません。各メーカーには独自のプロトコルがあります。 メタデータ付きの追加プロトコルも使用されますが、これはブランドによって異なります。 異なるメーカーの同じエラーコードであっても、意味が異なる場合があります。 このような混乱により、各メーカーのエラーコードの基本セットに関する情報が必要になり、どの車があなたに来たかに応じて、コード、モデル、ブランドを比較する必要があります。



しかし、顧客（車のディーラー）がエラーコードの復号化が必要かどうかを質問し始めたとき、彼らはすでに暗記してキーコードを知っており、その内容によっては、車自体にどんな問題があるかを推測できることがわかりました。 したがって、復号化せずにエラーコードのみを提供するという事実に落ち着きました。 ところで、もし誰かがobd2を操作するための強力なライブラリを知っているなら-コメントの情報に感謝します！

結果は何ですか？

モバイルアプリケーションは、検査官の生活を大いに促進しました。 そのため、4時間ではなく、1台の車を検査するのに平均で1〜1.5時間かかります。 チェックリストとヒントシステムの開発のおかげで、検査官はより多くの欠陥を特定し始めました。つまり、ディーラーは車の状態のより正確な説明を取得しました。 最後に、検査官はもはやWi-Fiに縛られておらず、文字通り世界中のどこにでも検査に出かけることができます。

今後の計画

アプリケーションのアーキテクチャを開発する観点から、アプリケーションの新しいリリースをリリースせずに車両を検査するための新しい指示を迅速に追加するために、損傷ディレクトリの統合に取り組んでいます。



また、ファッションに負けており、検査員が撮影した不適切な写真を識別するために、後処理処理にニューラルネットワークを使用して実験しています。もちろん、ニューラルネットワークの品質は向上しませんが、少なくとも次の時間に注意を払うように、少なくとも焦点を追跡できなかった場所を検査員に遡及的に示すことができます。すぐに、人工知能が検査官に作曲の技術を教え始め、光で動作するようになります。



そして、アプリケーションを改善するための3番目の方向性：特定のメーカーの特定のモデルの機能と欠点に関する知識ベースを作成しています。たとえば、このモデルでは体のVINがそこにあり、そのようなエンジンを備えた別のモデルでは、一定の走行距離後にバルブがノッキングを開始します。3番目のモデルでは、トランクの蓋が常に錆びます。次に、そのようなデータセットが存在する車を検査する検査官は、さまざまな段階で、注意を払う必要のある手がかりを受け取ります。



そして、Huaweiスマートフォンに切り替えています。Sony Z3は使用できなくなりました。信頼性に関係なく、遅かれ早かれすべてが機能しなくなります。そこで、レビューと野barなテストを読むことを繰り返した後、Huawei P10 Liteを選択しました。