GPSに基づくタクシー配車と監視システムの設計と実装

グローバルポジショニングシステム(GPS)の普及と普及により、タクシー業界ではGPSに依存して車両の緯度と経度をリアルタイムで取得し、それを車両のリアルタイム実装の基礎として使用できるようになりました。スケジューリングおよび監視システム。 国民経済の急速な発展の時代に、都市交通の重要な部分であるタクシー産業も急速な発展の時代に入りました。 継続的な開発プロセスから生じるさまざまな管理上の問題も、タクシー業界とタクシー会社の管理を管理する政府機関の前に置かれています。 タクシー業界とは、直接向き合うサービス業です。 車は都市のさまざまな地域に点在しており、社会に大きな影響を与え、広範囲に関与しています。 企業の継続的な成長に伴い、タクシー能力の配分を合理的に計画し、タクシー能力を強化する方法安全管理、ドライバーとタクシーの企業監督の強化、車両の空燃費の削減、燃料消費の削減、資源浪費の削減、および乗客へのより高速な提供より高度なサービスをサポートするためにより高度なシステムを必要とする実際的な問題を解決するためのより高品質のサービスなど。 業界の健全で安定した発展を達成するために協力し、会社自体が業界でより競争力があり、より迅速な意思決定反応を確実にするため。 政府経営の観点から、 GPSベースのシステム は、都市の交通渋滞を解決し、車両の燃料消費と大気汚染を削減し、タクシーの政府による監視を強化するために必要です。 政府の監督の包括性と均一性を最大限に満たすことができる完全なシステムを設計および構築する方法。 企業管理の科学的かつ将来を見据えた性質。 システム自体のスケーラビリティと堅牢性。 同時に、ドライバーを提供し、乗客が実用的な助けと利益をもたらすことができます。これは、GPSベースのタクシー配車と監視システムの設計で考慮および解決しなければならない問題です。

1

Roadragon の主な仕事 は
1.タクシーディスパッチ要件の完全な理解に基づいてタクシーディスパッチおよびモニタリングシステムを設計し、マルチスレッドおよび大規模な同時データ転送をサポートするイベント駆動型システム設計を実現します。 目的は、部門
Allに明確な階層構造とより強力な拡張機能を持たせることです。
2.システムの実装プロセスでは、タクシーとシステム間の多数のデータ接続を提案および解決し、データ送信の完全性と信頼性を確保します。 目的は、より経済的なサーバーリソースでシステムをより高いレベルに到達させることです
データ転送の効率と信頼性。
3.システムの実現プロセス中に、複雑な道路条件下で発送可能な車両を正確に検索するという問題を提案し、解決します。 目的は、車両の空燃費をさらに削減し、より正確な車両検索を通じて車両の燃料消費量を削減することです。
乗客の搭乗ポイントに早く到達します。
4.システム実装の過程で大量のデータを高速かつ効率的に保存および取得するという問題を提案して解決します。 そして、プロジェクトの実施プロセスで遭遇する実際の問題の解決策の分析と組み合わせて、毎日

上記の分析によると、システムは次のように分類できます
。1.基本情報メンテナンスサブシステム:オペレーターの基本情報、車両の基本情報、ドライバーの基本情報、および基本的なマップデータのメンテナンスを主に担当します。
2.乗用車予約注文メンテナンスサブシステム:主にコールセンターとのデータインターフェースと乗客注文のメンテナンスを担当し、バックグラウンドディスパッチシステムに車予約情報を送信します。
3.自動注文発送サブシステム:主に、車両の基本的なリアルタイム情報を維持し、受信した注文情報に従って車両を照合します。 メッセージゲートウェイとのメッセージの対話。
4.メッセージゲートウェイサブシステム:システム内のメッセージ形式と端末とシステム間で定義されたメッセージとの間の変換と送信を主に担当します。
5. 地図監視システム:ディスパッチサブシステムとのデータのやり取りを主に担当し、車両の地図表示とリアルタイムの動的表示を担当します。 そして、制御コマンドを車両に送信します。
ボトムアップのデータフローは次のとおりです。1.車両がリアルタイムデータをメッセージゲートウェイサブシステムに送信します。 2.メッセージゲートウェイは、解析済みデータをディスパッチサブシステムに転送します。 3.自動ディスパッチサブシステムは、注文に基づいています
。車両は、車両の緯度と経度によってスクリーニングされます。 4.自動ディスパッチサブシステムは、車両のリアルタイム情報や車両の状態などの追加情報をマップサービスサブシステムに送信します。 5.マップサービスサブシステムは、車両の履歴データを記録し、それをマップ監視クライアントのリアルタイム表示に送信します。
トップダウンのデータフローは2つの主要な部分に分かれてい
ます。1.ディスパッチングサブシステムによって開始されるデータフロー:1.ディスパッチングクライアントは、車の使用要求を受け取り、自動ディスパッチングサブシステムに送信します。 2.自動ディスパッチサブシステムは、実際の状況に基づいて適切な車両を見つけます。
適切な車両とメッセージゲートウェイサブシステムを介してこれらの車両に車両使用要求を送信します。 3.メッセージゲートウェイサブシステムがメッセージを受信すると、メッセージプロトコルを変換して特定の車両に送信します
。2.マップ監視クライアントによって開始されたデータフロー:1.監視クライアントがマップサーバーへの監視要求を開始します。 2.マップサーバーは、ディスパッチサーバーを介してメッセージゲートウェイに転送します。 3.メッセージゲートウェイはプロトコルを変換し、それを特定の車両に転送します。
上位および下位のデータフローから、サブシステムの分析は主に、メッセージを介して開始された要求を互いに通知することです。 システムの対応する適時性とデータの高い同時実行性を考慮して、システムの設計プロセスの各サブシステムは主に、全体的な設計に「生産消費」モデルを採用します。最も重要なのは、オブザーバーモデルを使用して分離する。 このモードの考え方は、スレッドの異なるグループからのリクエストをカットして、データを非同期に処理することです。 「プロデューサー」は処理する必要のあるリクエストを生成するスレッドであり、「コンシューマー」はそれらのリクエストを受け入れてそれに応答するスレッドです。 利点は、それが明確な分離を提供するため、スレッドをより適切に設計し、疎結合の設計哲学とより一致させることができることです。 また、開発者が実際の使用中に発生する問題を見つけて解決するのにも役立ちます。 システムのモジュラー設計と実装は、システムのメンテナンスと拡張にも役立ちます。 同時に、モジュール式の設計と実装は、各モジュールの独立した単体テストを支援してチーム内の並行開発を改善し、システムのその後の再構成のリスクを十分に保証します。 各サブシステム設計の主な機能は次のとおりです
。1.メッセージゲートウェイサブシステム:メッセージの受信と転送、およびメッセージプロトコルの変換を主に担当します。 メッセージの受信と転送では、大規模な同時実行状況での接続の維持と、アプリケーション層がネットワークの輻輳下で送信されるデータの整合性をどのように保証できるかを考慮する必要があります。 端末とシステム間の分離は、プロトコル変換によって保証されます。 端末プロバイダーのディスパッチおよび監視システムが置き換えられた場合でも、整合性は保証され、ゲートウェイサブシステムのプロトコル変換モジュールのみを変更する必要があります。
2.自動ディスパッチサブシステム:乗用車の基本情報と都市の道路の基本情報を組み合わせて、車両の位置とステータス情報に基づいて、どの車両が乗客に適しているかを自動的に判断します。 主なモジュールには、メッセージ受信および送信モジュール、メッセージおよびタスク(タスク)変換モジュール、スレッドプールモジュールが含まれます。 サブシステムの分離の重要な部分は、メッセージおよびタスク変換モジュールです。 このモジュールを通じて、さまざまなメッセージが1つ以上の独立したタスクに変換され、タスクはさまざまなスレッドプールに送信されて処理されます。
3.マップサーバーサブシステム:リアルタイム車両を監視し、車両のリアルタイムデータを記録して履歴分析を行います。
全体的なシステムアーキテクチャの設計
このシステムは、開発言語としてJavaを採用しています。 設計プロセスでは、システム全体がモジュール設計によっていくつかのサブシステムに分割され、システムとシステム間のデータのやり取りにはソケットが使用されます。 サブシステムは、主に生産モードと消費モードを採用して、タスクと操作の分離を実現し、マルチスレッドテクノロジーをより柔軟に使用して、システムの同時処理能力を向上させます。 各サブシステム間の共通機能モジュール(ネットワーク接続管理および保守モジュール、スレッドプールモジュールなど)のシステム設計では、サブシステム内での不要な反復的な開発を回避するために、プロセス内でパブリックおよび独立機能モジュールが事前に設計されています。 サブシステムは、実際のビジネスロジックにのみ直面しています。
生産および消費モードの設計と実現
サブシステムとサブシステム間のメッセージの相互作用、およびサブシステム内のタスクシステムの同時処理要件を考慮に入れると、設計プロセスにおけるシステムの最も基本的なものは、生産と消費モデル。 この記事では、このモードの紹介を使い尽くしません。 この記事では、主にこのシステムの生産と消費モードの設計構造を紹介し、タクシー配車注文のビジネスプロセスの詳細な分析と、生産と消費モードの特定のアプリケーションを紹介します。 このシステムの生産モードと消費モードの全体的な設計構造は、スレッドプールとタスクオブジェクトに基づいています。 スレッドプールによって提供される主な機能には、スレッドの保守と管理、およびバッファキューの保守と管理が含まれます。
生産および消費モデルでより重要なのは、スレッドプールの設計です。 たとえば、OrderThreadPoolは、カスタムの並べ替え順序に従って実行するためのものです。 オペレーターがタイプとして分類され、New Order_Taskが処理オブジェクトであるとすると、OrderThreadPoolは各オペレーターのタスクに従って順番に実行され、各オペレーターに対して1つのNew Order_Taskのみがスレッドプールで実行されるようにします。 設計の原則は2つのHashMapを維持することであり、1つのHashMapは分類標準と対応するタスク間の管理を維持するために使用され、キーは分類タイプ、値はLinkedListタスクリストです。 そのカテゴリのタスクを維持するために使用される別のHashMapが実行されています。 getTaskの実行中に同じタイプのタスクが実行されていると判断されると、取得されたタスクが進行中でなく、実行のためにスレッドプールに返されるタイプのタスクになるまで、別のタイプのタスクが比較のために選択されます。 同時に、システムはJavaによって1.5以降に提供された、読み取り/書き込みロック、セマフォ、ペアの交換のためのスレッド同期など、高性能の同時実行ツールの使用にも焦点を当てています。
車両監視およびディスパッチシステムは主にシステムと車両間の直接接続を実現するため、車両派遣部門のみが関与し、リアルタイムの基本車両データを取得する機能は、会社の洗練された管理の強固な基盤を築きました。 したがって、設計プロセスでは、企業の上級管理者の管理アイデアを十分に考慮し、柔軟な管理アイデアを比較的固定されたスケジューリングシステムと組み合わせる必要もあります。 車両のスケジューリングと監視システムが企業情報構築の先駆けとなり、企業と協力して独自の戦略的方向性を実現できるようにしましょう。
車両履歴データの維持

2

車両の履歴データを維持することは、車両を分析および監視するための鍵です。 車両の履歴データには、主に車両の過去の軌跡ファイル情報、車両の過去の運転データなどが含まれる。 車両の過去の軌跡データは、主に車両の過去の運転ルートを見つけるために使用されます。これは、乗客の苦情を解決し、交通事故を分析し、乗客の遺失物を見つけるために使用されます。 実際の申請プロセスでは、車両の軌跡が地図上でスムーズに描画されるようにするために、車両の緯度と経度の軌跡点の報告頻度が十分に密であることを確認する必要があります。 車両が10秒ごとに位置レポートをアップロードすると、1日に8640になります。 位置レポートデータは、1つの位置レポートデータとして計算されます[4バイトの車両識別番号+ 8バイトの緯度と経度+ 4バイトの時間+ 1バイトの速度+ 1バイト(方向、測位)+ 1バイトの車両ステータス+ 4バイトのアラームタイプ]合計23バイト、1日に1つ車のトラックデータは最大194Kです。 1日に1万台の車が1Gのデータに到達できます。 このデータを保存する方法は? ユーザーに便利で迅速なクエリを提供するには? これらのデータに基づいて有用な情報を分析し、管理のための新しいアイデアを提供する方法は? これらの問題は、システムの設計と実装のプロセスで考慮する必要があります。 車両の過去の稼働データは、主に各車両の1日の収益を分析するためのものです。 収益データの分析は、現在の料金が妥当かどうか、容量入力が飽和しているかどうか、およびその他の管理データを管理者が分析するのに役立ちます。 運転データには基本的に、ナンバープレート番号、車両識別番号、開始時刻、終了時刻、走行距離、運転量などの基本データが含まれます。1日1台の車両につき80のトランザクションで1日あたり10,000台の車両の800,000レコードを分析します。 運用データの整合性、運用データの保存と分析を保証する方法、およびこれらの基本的な運用データから管理分析に役立つデータを掘り出し、ユーザーがそれを便利かつ迅速に使用できるようにする方法は、すべて、システム設計プロセス。
 GPS Vehicle historical data
According to the implementation of the system, the system is implemented in JAVA programming language, deployed on the server of the Linux operating system, and the database uses Oracle11g. Regarding the massive amount of data and the operating frequency of the data, the system is stored in two ways: file disk storage and database storage. For the vehicle trajectory file, a data system with a high upload frequency, it mainly uses file disk storage to store basic data. For vehicle operating data, data that is relatively infrequently uploaded, is stored in the form of database storage. The following will introduce solutions for processing two kinds of data. The main purpose of the vehicle trajectory file is to trace the historical driving situation of the vehicle and to statistically analyze the number of historical vehicles in each time period in different areas.
Scenarios for retrospecting the historical driving situation of the vehicle include: 1) Lost and found by passengers: Passengers left their belongings in the vehicle, but cannot provide specific vehicle information, and can only provide a certain place during a certain period of time. The system needs to find out all the vehicles that have passed the locations recalled by the passengers based on the historical trajectory information of all vehicles in a certain period of time for investigation. 2) Passenger detour complaints: Passengers provide information about the vehicle they are in, and the system queries the vehicle's driving route during the service period to determine whether the vehicle is detouring illegally. 3) Vehicle statistics for each time period in different areas: Generally used to monitor whether the number of vehicles in the area is abnormal, so as to determine whether the vehicles in the area have stopped or went on strike. In practical applications, the monitored city needs to be divided into multiple monitoring areas, and the number of vehicles in the area is counted according to the 24 hours a day. The number of vehicles in the area is divided into 24 hours a day to form weekly averages, monthly averages and other reference data, combined with the real-time number of vehicles on the day The situation is compared to draw a reference conclusion whether there is any abnormality. According to the above three common scenarios in the actual business process, it can be found that the main analysis and query conditions for vehicle historical trajectory data are: time, latitude and longitude, and specific vehicle. According to the analysis in the previous question, the number of trajectories of a car in a day can reach up to 8,640, and the amount of data can reach 194K, so it is not an ideal solution to store these data in a database. Because each vehicle reports a position in 10 seconds, 10,000 vehicles will have 1,000 database insertions in one second. Frequent database table operations will definitely affect the performance of the system. From the perspective of query analysis, a car has a maximum of 8,640 position report data a day, and 10,000 cars equals 864 million position report data. Even if the database partition table or sub-table is used and the key fields are indexed, if the vehicle trajectory is used The playback operation query will generate various I/O waits at the database level, leading to a sharp drop in system performance. Therefore, when the system is designed, the storage of the vehicle trajectory file adopts the file disk for direct storage. Choose the file storage structure. According to the actual business reference analysis and the determined storage method, the system design needs to consider how to store it to be more efficient. The most common is to use the storage structure of the hash file. Hashing files is similar to the Hash table in the data structure, that is, according to the characteristics of the keywords in the file, a hash function and a method to handle conflicts are designed to hash the records on the storage device. The difference from the Hash table is for the file , File records on the disk are usually stored in groups. Several records form a storage unit, which is also called a "bucket". Since our development language is Java, we can find from the HashMap structure implemented in the Java language API that the data structure of the hash table is composed of an object array and multiple object linked lists. The object array is similar to the concept of "bucket". Each bucket is identified by a hash value. If there are objects with the same hash value, they are stored in the object linked list of the "bucket". The search time of the data structure hash table is complicated. The ideal situation can reach O(1), that is, each "bucket" has only one object, and the worst may be only one "bucket". All data is put into the object list of this "bucket", so the worst The search time complexity will reach O(n). Of course, in the HashMap implementation process, there is a function of judging the total number of objects and the number of "buckets" and regenerating the correspondence between the new distribution "buckets" and objects. Understanding the data structure implementation of an actual hash table structure helps us design our own hash file based on the hash table data structure. Hash distribution of trace files. According to the use of the trajectory file and the attributes of the file itself, the system divides the file into storage levels according to the hierarchical structure of year, month, day, and vehicle license plate. Considering the scalability of the system, it is convenient to access more vehicles in the future. Use the last character of the license plate number for hash processing.
The principle and design of dispatching to find a car

4

GPSベースのタクシーディスパッチおよび監視システムでは、システムを実現する方法によって、乗客にアイデアと設計スキームを提供するのに適した車両が自動的に検出されます。 このシステムのディスパッチ機能の目的は、乗客に最もタイムリーな車両を提供し、タクシーに最も近い乗客を提供して、ドライバーの走行距離を削減し、省エネと排出削減の目標を達成することです。 ドライバーのお金を節約し、乗客に利便性を提供します。

発送のための車の発見の設計プロセスで考慮すべき最初の2つの目標:高速かつ正確。 まず、車の需要を提供するために電話をかける乗客の基本的な属性を理解しましょう。 1)乗客がダイヤルした電話番号。 2)乗客が車を使用した時間。 3)乗客が乗車しようとした場所。 これら3つの基本属性の電話番号は、コールシステムから直接取得できます。また、誰かが代理で車を予約した場合は、乗客に電話番号にコールバックするように依頼することで取得できます。 乗客はまた、車の時刻をディスパッチャに通知するためのイニシアチブを取ります。 キーは搭乗場所の3番目のポイントです。 乗客は通常、次のような物理的な住所のみを伝えます。特定の道路に近い道路とその他のテキストによる説明。 ディスパッチシステムの場合、システムはテキストの道路状況情報を特定の経度と緯度の情報に変換して車両を検索し、経度と緯度の情報を使用してディスパッチに適した車両があるかどうかを判断する必要があります。 したがって、正確な車両検索の最も基本的な作業は、乗客の搭乗場所の経度と緯度の情報を取得する方法です。

乗車地点の緯度と経度の情報を保持する

ピックアップポイントの経度と緯度の情報を維持することは、都市の道路ライブラリ情報を維持することです。 主に、道路交差点の緯度と経度のデータ、ランドマークの建物の緯度と経度のデータ、番地セクションの緯度と経度のデータなどが含まれます。さまざまな都市の道路特性に応じて、さまざまなデータを使用して緯度と経度のソースをディスパッチできますピックアップポイントのデータ。 たとえば、上海のような標準化された成熟した家番号を持つ都市では、車両の乗車地点の経度と緯度のデータのソースとして、家番号セグメントの緯度と経度を好む場合があります。 一部の小都市では、ランドマークの建物の緯度と経度を乗客搭乗地点の経度と緯度のソースとして使用できます。 一般都市は、乗客搭乗地点の経度と緯度の情報源として、道路交差点の緯度と経度に適しています。

番号セクション、ランドマーク的な建物、道路の交差点に応じて、これらの各方法には長所と短所があります。 通常、実際の使用時に組み合わせて使用​​します。 家番号セグメントの適用範囲は比較的狭く、市の家番号分布は標準化され、継続的でなければなりません。 しかし、番地セグメントの方法は、乗客の搭乗場所の経度と緯度をすばやく正確に見つけることができます。 原理は次のとおりです。道路を家の番号に従っていくつかの小さな道路に分割し、その小さな道路を経度と緯度のポイントとして使用します。 ドアの数をいくつに分割するかは、道路情報を収集するスタッフが道路の実情に合わせて決める。 ドア番号セグメントの経度と緯度を収集する方法は、コレクターが特定の道路のドア番号セグメントに車で行き、GPSデバイスを介して経度と緯度をアップロードして、最も正確な道路の経度と緯度のデータを取得する方法です。 実際の運用では、乗客が自動車電話をかけて乗車先の道路・家屋番号を知らせると、道路・家屋番号から家屋番号が属する家屋区画を見つけ、家のセクションの対応する番号。 経度と緯度の情報。たとえば、乗客が電話をかけて車の住所が第10中山路であることを伝えると、システムは第10中山路が第2から第50中山路の範囲にあることを検出します。 、システムは2番から50番の中山路に戻ります。 乗客搭乗地点の経度・緯度情報としては、道路区間に対応する経度・緯度情報を用いる。 搭乗場所の緯度と経度を取得するこの方法は比較的正確で、誤差は500メートルを超えません。 不利な点は、番地データを取得するための比較的大きなワークロードが、初期段階で困難で詳細な基本データ収集の期間を必要とすることです。 さらに、都市住宅の数の標準化の度合いは比較的高いです。 都市の道路の緯度と経度を取得する主な方法は、都市の地図データを分析して交差道路の緯度と経度の情報を取得することです。 乗客が電話すると、搭乗地点のおおよその緯度と経度を取得するために、特定の道路が特定の道路に近いことが記載されています。 緯度と経度を取得するこの方法はより便利ですが、欠点は、測位の精度が保証されないことです。 乗客が道路から数キロ以内に交差点のない長い道路に入ると、システムは交差点の経度と緯度の情報に基づいて乗客の正確な搭乗緯度と経度を正確に取得できなくなります。

車を見つけるためのスケジューリング

3

乗客搭乗地点の経度と緯度のデータを管理することにより、システムが車両を自動的に派遣して車両を見つけるための強固なデータ基盤が提供されます。 車の発見の実現は、地方都市の道路特性と派遣に参加するタクシーの数と組み合わせて検討する必要があります。
緯度と経度の直線距離に従って車
を見つけるこの車を見つける方法は、実装するのに比較的便利で実用的であり、実際のアプリケーションで最も頻繁に使用されます。 実現原理:乗客搭乗地点の経度と緯度を車の検索距離の中心とする半径を円として描画します。円内の車両がコーディネーターが探している車両である限り、一度に車両、半径は特定の範囲に従って車両と比較され続けます。車両が見つかるか、半径がシステムによって設定された最大値に達するまで。 この方法は実装が比較的簡単ですが、すべての車両と円の中心との間の距離を計算する必要があるため、効率はそれほど高くありません。 科学的で効率的ではありません。 10,000台の車両が車を呼び寄せるプラットフォームの乗客を想像してみてください。 実際には、乗客搭乗地点の周囲には20台以下の車両があり、乗客に提供される車両は1台だけです。 ただし、プラットフォーム上の10,000台の車両すべての距離を計算する必要があります。 基本的に9,980回の計算は無駄な計算です。 現在のサーバーのパフォーマンスは継続的に改善されているため、実際に使用する場合、10,000台を超える車両があるタクシーディスパッチプラットフォームでこの方法を使用することは、依然として高速で正確な実装方法です。 特に上海のように道路計画が合理的な都市では、乗客の乗車場所が乗客をピックアップするために方向転換する前に、車両が長距離を走行する必要があるという現象を考慮する必要はありません。 経度と緯度の直線距離に従って車を見つけることによってもたらされる膨大で役に立たない計算を考慮すると、システム設計にはさらに最適化の方向があります。
グリッドカー検索
グリッド検索は、直線距離にある自動車を見つけるプロセスで膨大な無駄な計算を避け、検索プロセスのパフォーマンスを最適化することです。 原則は次のとおりです。まず、都市は緯度と経度に従ってグリッドに分割されます。 第二に、グリッド内の車両の位置は、車両のリアルタイムの緯度と経度に従って記録されます。 乗客搭乗地点の位置に従って、周囲のグリッド内の車両が取得され、これらのグリッド内の車両間の距離と乗客の搭乗緯度および経度が比較されて、乗客にとって最適な車両が取得されます。
車を正確に見つけるためのGPSマップデータ

5

最も原始的な距離の直線自動車検索であるか、それともグリッド検索であるかに関係なく、最も基本的な原則は、乗客の経度と緯度の比較に基づいて、自動車が代替のディスパッチ車両として適しているかどうかを判断することです。搭乗と車両の直線距離。 道路データを組み合わせて正確な車の発見を実現する方法は、現在のディスパッチシステムでは一般的ではありません。 その理由は、一般に国内の都市道路網構造の車両が向きを変える方が便利だからです。 高速道路が高架になっている大都市でも、空の車両の高架は許可されていません。 したがって、中国では、乗客の搭乗地点と車両の経度および緯度の地点との間の直線距離で車を見つけるだけで、顧客の基本的なニーズを満たすことができます。
しかし、インドネシアのジャカルタのようないくつかの特別な都市。 この都市の道路にある車両は、多くの場合、方向転換するために数キロ以上運転する必要があります。 インドネシアは地震の多い地域にあるため、市には地下鉄がなく、高速バスを走らせるために道路の真ん中に2つの特別道路が開かれています。 真実は、分離された車両がまったく向きを変えることができないということです。 このような不便な都市では、乗客の搭乗地点の経度と緯度を車両の経度と緯度と比較して車を見つけると、人と車両が異なる側にあるか、または乗客の位置がちょうど運転するため、車両は広い範囲を移動する必要がある場合があります。 サークルは乗客をピックアップするために戻ってきます。 これは、ドライバーの燃料消費を節約するというGPSディスパッチシステムの本来の目的とは矛盾しています。 この矛盾を解決するために、システムは、車両と乗客搭乗間の距離と道路情報を使用して適切な車両を見つけることを考慮する必要があります。
デザインアイデア:地図に描かれた道路は、通常「セグメント」で表されます。 道路は連続した「セグメント」に分割されます。 そして各セクションの幅に応じて「バンド」を形成します。 このようにして、完全な道路パターンを地図上に表示できます。 各交差点が曲がることができるかどうか、道路が一方通行かどうかなどに応じて、まず道路情報が有向グラフに結合されます。 そして、車を探す距離に応じて、乗車地点から最も遠い道路地点がどこであるかを計算し、道路の緯度経度データを得る。 道路の有向グラフから取得した道路の緯度と経度の線データと、道路の「ベルト」の緯度と経度の範囲を取得するための道路の各セクションの幅に加えて。 次に、車両が道路「ベルト」上にあるかどうか、車両の実際の緯度と経度で判断します。 車両の緯度と経度が道路の「ベルト」の範囲内にある場合、車両は適格な道路を走行していることを意味します。 グラフトラバーサルとトラバーサルの最大距離を組み合わせることで、車両の探索は実現できますが、結局、道路の「地図」上に出発地を設定する方法、つまり、乗車地点を道路に落とす方法は、多くの乗客が車両に乗り込む道路の位置はシステムによって維持されている道路上にある必要があり、緯度と経度がコミュニティ内にあることも可能です。 この状況は、非常に詳細な都市の緯度と経度のデータなしでは対処することが困難です。乗客の搭乗の緯度と経度を乗客の緯度と経度として道路に移動することはできないため、乗客がコミュニティにいる可能性が高いためです。 、乗客が最も近い緯度と経度で車両に搭乗できるようにします。道路はコミュニティウォールで区切られています。 最寄りの道路を判断するには、非常に詳細な地図データが必要であり、コミュニティのゲートに対して正確である必要があります。 プロジェクトへの投資を削減するために、システムは、乗客搭乗地点の経度と緯度が道路の経度と緯度に基づいていることにのみ同意できます。
基本的な道路ライブラリデータプロセスでは、道路ライブラリデータを実際の道路に配置する必要があります。 システムが乗客の搭乗の緯度と経度を受け取り、システムが都市の道路データから乗客の搭乗の緯度と経度が配置されている道路の「セグメント」にすばやく移動する必要があるシナリオを想像してみてください。 そして、この道路「セクション」によれば、道路「セクション」に接続された道路「セクション」を取得するには、もちろん、車の経度と緯度の直線距離を取得する必要があるだけで、車、2点間の直線距離が最も短いので、直線距離が車を見つける最大距離を超えている場合、道路の実際の曲線距離は車を見つける最大距離を確実に超えます。 車を見つける最大距離を満たし、乗客が乗車した道路方向に接続されているすべての道路「セクション」によれば、道路「ベルト」は、各道路「セクション」によって定義された道路幅に従って取得されます。 。 したがって、実装プロセスの主な作業は、道路モデルを構築し、搭乗する乗客の経度と緯度に関連する道路をすばやく取得する方法です。 道路データ構造については、まず実際の道路データを「セグメント」に分割することを検討してください。 最も長い「セクション」を1 kmの長さで割ったとすると、上海市全体が例として取り上げられます。 上海高速道路の総延長は約11,000キロメートル、都市道路の総延長は約4,400キロメートルです。 道路セグメントのデータ量を1 kmで割ったとしても、道路の「セグメント」を考えると、桁が小さいという重要な属性です。
結論
車両スケジューリングの最も基本的で最も重要な機能は、適切な車両を迅速かつ正確に見つけることです。 この章では、カーファインディングの基本原理と、いくつかのカーファインディング方法の実現、長所と短所を紹介し、分析します。 車を見つけるための最も一般的な距離から、車を見つけるためのグリッドまで、そして最後に、正確な車の検索の設計と実装を都市の道路情報と組み合わせます。 道路情報と組み合わされた正確なカーファインディング設計プロセスでは、都市の基本的な道路データの大量の面倒な保守と管理がありますが、このカーファインディングの方法は、道路情報と顧客の要件によりますます完璧になります。発送精度はますます高くなっています。 結局のところ、車の検索が正確になればなるほど、車の空燃費が減り、不必要な燃料消費が減り、ドライバーの熱意がますます高まるでしょう。 道路の地理情報と組み合わせた正確なカーファインディングによるカーファインディングのスケジューリング方法は、今後ますます広く使用されるようになります。
データ分析とアプリケーション
タクシー駐車問題

6

各地の交通機関にとって最も厄介なのは、管轄区域のタクシーがストライキを送り、事件の運転をやめることです。 それは市民の旅行に影響を与えるだけでなく、より大きな理由は、影響の悪い範囲が社会の安定と団結に大きく影響することです。 交通局の安定維持は、タクシーの停車が最優先事項と言える。 近年、諸事情により、タクシーストライキや停車が随時発生しています。 タクシーの停車を解決する方法は基本的に政府の行政介入方法であり、GPS監視プラットフォームは基本的に事故発生時に補助的な役割を果たします。 タクシー停車の問題を解決するプロセスに従って分析します。 政府は一般的にタクシー会社を抑制する方法しかとることができません、そしていくつかの会社は運転手のイデオロギー的な仕事をすることを楽しみにしています。 ドライバーが運転を停止する主な理由は、低所得と過度の労働集約度にすぎません。 GPSシステムは監視の役割を果たすだけであり、政府は依然として多数のスタッフを訪問する必要があります。 しかし、GPSベースのタクシー配車と監視プラットフォームは、監視の役割の一部しか果たしませんか? 分析と思考の後、実用的かつ理論的な分析。 GPSベースのタクシー配車および監視システムは、事前予防、事前通知、イベント中の監視、およびイベント後の要約を完全に実行できます。
事前
政府から運転手までの国内タクシー業界の一般的な構造は基本的に同じです。 基本的に、政府はその管轄内でのタクシー会社の運営を管理する行政上の権限を持っています。 タクシー会社は、毎月一定の管理費を運転手に請求することにより、タクシーを運転し、タクシーの日常業務を運転手に譲渡する権利を有します。 ドライバーは運転を担当します。 燃料費、修理費、規則違反の罰金は基本的にドライバーが負担します。 タクシー会社に支払う管理費は、基本的にドライバーの月収の約2/3を占めています。 政府職員とのコミュニケーションと、いくつかの事故の一時停止に対処する過程でのタクシー運転手からの理解を通じて、タクシーの一時停止には、おおよそ2つの理由があることがわかりました。

ドライバーの収入が低すぎます。
2.組織化されたリーダーがいます。停止イベントの原因とGPSベースのタクシー配車および監視システムの実際の状況を組み合わせることにより、システムは関連部門に事前にリマインダーを与えることができます。 実際の状況を分析してみましょう。タクシーは街の通りや路地を走っています。 管理の複雑さをもたらすのは、その機動性によるものです。 タクシー内の最も重要なデバイスはメーターです。メーターは、ドライバーの各ビジネスの詳細情報を記録します。 金額、開始時刻、終了時刻、走行距離などが含まれます。タクシーに設置されたGPS端末は、端末の無線通信を介して、タクシーと車内のタクシーメーターとシステムの間のリアルタイム接続を確立します。 管理者はこれらのタクシーを制御および管理できます。 端末の通信モジュールシステムにより、各車両のメーター記録や日収を把握できます。 これら2つのインデックスシステムを通じて、各ドライバーの月次ベーシックインカムを分析できます。 毎月の収入に基づいて、どのドライバーが扇動されそうかを判断でき、管理部門はさまざまな対策を講じて隠れた危険や出芽を排除できます。 たとえば、企業は、従業員を気遣う方法で低所得のドライバーにインタビューしたり、ドライバーの困難を時間内に知り、特定の困難な補助金を提供したり、優れた労働経験を与えてドライバーの実際の収入を増やしたりできます。 予防策の考え方は明らかでした:ドライバーの実際の収入の統計分析を通じて、ドライバーが停止する可能性があるかどうかを判断します。 低所得のドライバーと事前に顔を合わせてコミュニケーションするなどの方法で、ドライバーの実際の困難を解決し、低所得のドライバーの世話をし、ドライバーが会社の注意を示してから問題を未然に防ぐ効果を得る発生する。 このプロセスでは、システムが面接先を事前に正確に判断し、会社の目的を回避し、会社の仕事をより目的的かつ効果的なものにする役割を果たします。 実現方法の主なデータベースは、タクシーのタクシーメーターの収益データとタクシーメーターレコードです。 したがって、メーターはGPS車両端末へのデータインターフェイスを提供する必要があり、データは各サービス後に車両端末に「吐き出される」可能性があります。 データを受信した後、車載端末は確認し、確認フィードバックメッセージをメーターに送信します。 車載端末は、無線通信モジュールを介してメーターデータをシステムにアップロードします。 システムはデータを受信すると、データベースに保存し、受信を確認するフィードバックメッセージを車載端末に送信します。 理論的には、確認フィードバックメッセージを送信することにより、データの整合性が保証されます。 一方、システムは、さまざまな場所の実際の状況に応じてさまざまなデータしきい値を設定して、データが「信頼できる」かどうかを判断するために、アップロードされたデータと実際の状況とのずれの程度を判断する必要があります。 たとえば、「メータリング」の日次平均数、単一の差の最大操作量などを設定します。管理者が判断するために、システムはさまざまな設定データしきい値に従って比較結果を生成します。
タクシーの収益データに関する膨大な量のデータを考慮すると、10,000台の車両の毎日の運転データレコードを計算するために、1台の車両につき1日あたり80件の収益データは800,000です。 設計プロセスを実現するために、パーティションテーブルの採用を検討してください。 つまり、月に1つのパーティションテーブルです。 アップロードした稼働データの実際の発生時刻をパーティションテーブルとパーティションテーブルのキーとする。 自動統計は1日に1回行われ、各車両の1日の総収益、および1日あたりの計測数、走行距離、空の走行距離が計算されます。 メーターの数は、ドライバーの収益が実際の状況と一致しているかどうかを判断するために使用され、走行距離と空の走行距離が比較され、空の走行距離を減らすことで燃料消費の目標を節約できるかどうかが判断されます。
事前にリマインダー
ドライバーが集合インシデントを停止したときに、できるだけ早く管理者に
エリア内の車両の数をランダムに監視するという考えは、都市の任意の1 km以内の車両の数が特定のしきい値を超えているかどうかを判断することです。 判定の対象となる領域は任意の組み合わせであるため、実装プロセスでは小さな領域を大きな領域に組み合わせて統計的な判定を行う必要があります。 たとえば、1キロメートルの領域は、100メートルの9つの小さな領域に分割されます。 1キロメートルのエリアの車両のしきい値が30の場合、100メートルのエリアごとの車両の数が4を超えると、100メートルのエリアの車両の合計数は合計で30台の車両のしきい値になります。 したがって、システムの監視範囲は、100メートルの小さな領域での監視に変換されます。 ランダム監視領域の設計と実装は次のとおりです。システムは、都市の場所と地理的な緯度と経度の範囲に従って、都市全体を100メートルごとの領域に分割します。 細分化されたエリアは、車両数のしきい値を設定します。 狭いエリアの車両台数で判定を行い、しきい値に達したら、周辺の車両の総数が監視車両台数の警報しきい値に達したかどうかを判定します。 タクシーの運転手によるGPS端末の理解の向上に伴い、監視プラットフォームは、異常なGPSデータのアップロードを早期に警告する必要もあります。 例えば、車両の通信異常の発生件数は時間の経過とともに急激に増加し、監視マップ上の車両の数は、測位のために急増しています。また、管理部門が警戒する必要があるデータ指標でもあります。
イベント内監視イベント
を停止・収集する過程で、監視エリアをシステムで指定でき、エリア内の車両数や会社・車両の運転手などの基本情報をリアルタイムでカウント。 企業を通じてドライバーを呼び戻します。
その後のまとめ
収集の中断は通常、数日または1週間以上続きます。 その後、集会に参加したドライバーとユニットの統計分析を行う必要があります。 システムは、車両の過去の軌道情報に基づいて、集合駐車の期間中の駐車エリアの累積滞在時間を計算して、駐車へのドライバーの参加の深さを決定することができます。 集約停止中に車両オンライン速度の統計を収集することにより、車両が車載端末の通信を中断したかどうかを判断できます。 政府と企業が中断イベントの主催者を見つけて集めるためのデータサポートを提供します。
都市の安定維持の焦点として、タクシーの停車と集まりは多くの都市の注目を集めています。 GPSベースのタクシー配車および監視プラットフォームの監視機能は、主に停止運転の収集イベントの予防および事前警告機能を提供します。 運転停止のギャザリングインシデントの発生に基づく紛争の主な原因は、GPSディスパッチの機能によって運転者の空の運転率を減らし、運転者の空の運転燃料消費を減らし、支援を提供するための運転者の支出を減らすこともできます。
道路の混雑と燃料消費の削減
国内経済の急速な発展に伴い、さまざまな都市の交通渋滞はますます深刻化しています。 北京、上海、広州などの国内一流都市の交通渋滞による矛盾は、ますます顕著になっています。 さらに深刻なのは、都市の交通渋滞が第1層の都市から第2層および第3層の都市に広がったことです。 多くの大都市は、北京の奇数と偶数、上海のナンバープレートオークションなど、都市の道路の混雑を緩和する目的を達成するために、車両の移動を減らすためのいくつかの制限的な措置を模索し始めています。 いくつかの都市は、都市の混雑料金を徴収することを計画し始めました。 しかし、都市の交通渋滞の現象はまだ改善されていません。 逆に、国民経済の発展と国民の生活水準の向上により、自動車購入に対する国民の需要が高まり、都市道路の混雑の矛盾が顕著になっている。 道路の混雑を緩和する方法は、車両のスケジュールを設定することにより、路上タクシーの呼びかけ方法を徐々に置き換えることを検討することです。 統計によると、上海を例にとると、タクシーの空の走行距離は総走行距離の40%以上を占めます。 つまり
、タクシーのオイルの半分近くが1日で無駄になり、車のほぼ半分が道路を走行していると言われています。 これはガス代を浪費するだけでなく、ドライバーの労働集約度を増加させるだけでなく、貴重な都市道路資源も消費します。 現在の国内のタクシー配車システムが公衆電話から電話応対のディスパッチ方式に変更された場合、タクシーは乗客がいないときに休憩することを想像してください。つまり、ガソリンを節約し、労働力を減らし、市のタクシーを解放します。道路資源。 コンセプトの変化は段階的なプロセスです。 タクシー道端の募集は、タクシー業界の創業以来形成されてきたモデルであり、国内外で共通のビジネスモデルとなっています。 採用から電話での派遣に段階的に移行するには、ドライバーの作業習慣を変えるだけでなく、乗客の思考習慣を変える必要があります。 現在、国内および一部の都市では、無錫、南昌、温州などの都市ベースのタクシー配車プラットフォームの確立が始まっています。 また、タクシーにLED広告スクリーンを設置して、国際収支を達成し、政府の資金を最小限に抑えます。 さらに、無錫や南昌などの都市にある都市レベルのタクシー配車プラットフォームは、基本的に人員からシステムのメンテナンスまで自給自足を実現できます。 この観点から、市レベルのタクシー配車プラットフォームは、設備投資の面で完全に実現可能です。 無錫を例にとります。 無錫には約4,000台のタクシーがあります。 派遣プラットフォームは2年前に構築されました。 1日あたり数十人の乗客がタクシーを呼びに来てから、2010年末までに、1日あたり平均6,000人以上の派遣が成功しました。 8000以上。無錫市民の旅行を大幅に促進するだけでなく、より重要なことに、電話をかけることができます。
車の新しいカーハイリングモデルが根付き始めています。 電話の増加と成功したディスパッチの数を送信することができます
車を呼び出す現在のモードは一般に受け入れられており、ドライバーは喜んで協力します。
データ分析を通じてタクシーの容量を合理的に配分する方法も、タクシーの採用からESCへの転換を徐々に実現する唯一の方法です。 タクシーがESCに主に依存している場合、つまり、道路での空運転を減らすことは、矛盾をもたらします。つまり、ドライバーが乗客を見る機会が少なくなり、ドライバーの収入が減少します。 車を使用するエリアでタクシーを維持する方法、つまり、ディスパッチセンターから注文を受け取った後、できるだけ早く乗客の搭乗位置に到着して、空の走行距離を減らし、ドライバーが車を運転することを検討する方法そのエリアに乗客を送った後に待つ新しいビジネス。 つまり、ドライバーの乗り換えからESCモードへの移行を実現するには、ドライバーの2つの問題を最初に解決する必要があります。1)タクシーESCのビジネスをある程度確実に行う方法。 2)車両の通常の駐車エリアを合理的に分割する方法。 これら2つの問題が解決されない場合、ビジネスモデルの変革という目標を達成することは不可能です。 上海、フォルクスワーゲン、晋江、バスの3つのタクシー会社の統計データ分析に基づいて、車両あたり2トランザクション以上の毎日のディスパッチビジネスを達成できるバスを除いて、成功したディスパッチの平均数フォルクスワーゲンと晋江の操作は約1ペンのみです。 フォルクスワーゲンの1日の派遣成功数は約12,000人、晋江は約4,000人、バスは8,000人に達します。 3社に対応する車両数で割ると、現在のESCサービスの数はドライバーの日常のビジネス指標を満たすことができないことがわかります。 これが、ドライバーがメインの操作モードとして採用を選択する根本的な原因です。 また、これら3つのタクシー会社のESC事業は、5年以上の実績があります。 このESC事業のスピードを考えると、基本的には、行政の介入がなければ、募集募集からESCへの自動切り替えが不可能になると予想されます。 ビジネスモデルが登場した。 では、このビジネスモデルの転換を促進するために、GPSベースのタクシー配車プラットフォームは何ができるのでしょうか。
プラットフォームのデータ分析の利点を通じて、ドライバーの心を深めるというプラットフォームの目標を達成するために、ドライバーに役立つ合理的な車の使用領域やその他の方法をドライバーに提供できます。 つまり、システムは、マネジメントの観点からのディスパッチとモニタリングの役割を果たすだけでなく、ドライバーの観点からの分析とガイダンスの役割も果たす必要があり、ドライバーの収入とドライバーの安全を確保します。 乗客の乗車地点と乗車時間のデータ分析を通じて、ドライバーは、それらの時間帯に乗用車の量が比較的多いエリアを示し、各エリアと時間帯で使用された車両の履歴数は、毎日の履歴を形成しますデータ比較。 実際の運用プロセスでは、これらの期間中にこのエリアのタクシー車両の数が一定の割合を超えると、システムは警報を発してすべての車両にメッセージを送信し、車両が飽和状態になったことをエリアに通知し、車両は移動を検討できます空の運転を防ぐために他のエリアに。 そして、その地域と時間帯の履歴データとその日のエリア内の車両数に基づいて、どのエリアがまだ車両不足の状態にあるかが判断され、ドライバーはにメッセージを送信することでガイドされます近くの車両。 ドライバーの視点からの分析とガイダンスを通じて、ドライバーの間で発送プラットフォームの信頼と名声が徐々に確立され、ドライバーは発送プラットフォームに依存することに疑いから信頼へと転向します。 車載端末は、車両とシステムを密接にリンクしています。 ドライバーのアイデアを理解するために経営者がドライバーよりもコミュニケーションを取り、経営の観点から合理的なソリューションと管理方法を提案している限り、ドライバーは実際的な利益を達成するためのプラットフォームにいると思います。 同時に、企業や政府の投資には、実体的な見返りも得られます。 自動車の1日あたりのトランザクション数が2未満である現在のESCビジネスは、初期の段階でシステムの構築に多額の投資をした企業にとっては高くありません。 タクシーの派遣を通じて都市道路の混雑と燃料消費を減らすことは、長い道のりです。 困難なのは、習慣的な作業方法と、管理や実用化がまだ不可能である新しい作業方法の変換にあります。 アドボカシーに基づく古い作業方法を置き換えることができることを証明します。 ただし、システムは、ドライバーの空運転を減らし、燃料消費量を減らす上で、特定の役割を果たすことができます。 現在、楊肇の位置をESCで置き換えることはできませんが、上海、無錫、南昌、温州などの国内都市のESCデータの分析から、ESCの方法はゆっくりと乗客や運転手に受け入れられ始めています。 ヤン・チャオをさらに拡大し、乗客を引き付ける主要な手段として取り替えるには、まだ長い道のりがあります。
GPS-based taxi dispatching and monitoring system  technology is not a new set of technologies. As an application in the taxi industry, it has slowly begun to enter the use stage on a large scale. The realization of a taxi dispatch and monitoring platform has gradually become a must on the road of enterprise and government management and information construction.
Today, the number of vehicles connected to the platform is increasing, and the function of calculating the degree of road congestion can be gradually achieved through the platform. The investment in calculating whether the city road traffic is congested is very expensive. Taking the speed measuring coil laid on the high-speed driving road as an example, not only the investment is huge, but the maintenance workload is also huge. Through the real-time running speed of the taxis connected to the platform and the road where the latitude and longitude are located, as long as the connected vehicles reach a certain proportion, it can be used to achieve the basis of real-time road conditions of urban roads. This technology that relies on the basic data of the taxi dispatching and monitoring platform to access vehicles to determine the real-time road conditions of urban roads is currently in the research and preliminary use stage. It is believed that the application of this technology will be more perfect and popular in the future. Of course, this kind of road condition analysis also has certain limitations. After all, the distribution of taxis on urban roads does not reach the various roads of the city. Therefore, the data of road congestion analysis cannot be complete, but it is an economical The basic data source method of road analysis, the data source and analysis of GPS-based taxi dispatch and monitoring system are still trustworthy and cannot be ignored.
In the future with the continuous development and improvement of mobile communication technology, GPS-based taxi dispatch and monitoring systems can achieve many things that are currently desired but cannot be achieved through high-speed and high-bandwidth wireless communication networks. For example, real-time monitoring of the actual situation in the car, real-time monitoring of the actual situation in the car, and other tasks that require network bandwidth. At present, the monitoring of the situation in the car basically uses a camera to take pictures, such as taking pictures when passengers get in the car, take pictures when passengers get off, and take pictures when the vehicle is alarmed. And transmitted to the server through the wireless communication network. Due to the limitation of bandwidth, the sharpness of photos taken will be limited. If a 4G network is adopted, the network bandwidth will be able to withstand the upload of video surveillance data, and the system can achieve real-time viewing of every move in the car. With the continuous development of smart phones, it is very common for mobile phones to support GPS positioning. The GPS-based taxi dispatch system can even be developed in the direction of online car booking. Passengers can directly use a mobile phone with GPS positioning function to book a vehicle, the system can directly obtain GPS positioning data on the passenger's mobile phone, and generate passenger car orders, which can more accurately obtain passengers' boarding latitude and longitude.


投稿時間:2020年9月4日