衛星航法データを使用した自動車充電システムのビジネスアーキテクチャ

Breton Bonnets Rougesは、Ecotaxeコントロールポータルを利用しています。 写真Europe1.fr



衛星充電システムに関する最後の発表から1年以上が経過しました。 この間、多くの変化があり、概念的にも変化しました。 新しい業界標準がリリースされ、料金徴収を整理するビジネスロジックが変更されました。 これは、多くの場合、新しい領域で発生します。 したがって、技術的なニュアンスについての話を続ける前に、新しいビジネスモデルとその出現の前提条件について簡単に説明したいと思います。

歴史的背景

現在、ヨーロッパでは、ドイツ（ TollCollect ）、スロバキア（ SkyToll ）、ハンガリー（ Hu-Go ）の3つの完全に機能するGPS充電システムしかありません。



ドイツのシステムは最も古いもので、2005年に委託されたものであり、スケジュールよりも大幅に遅れています。 システムは40,000 kmを超えるデータを収集します。 150万台のオンボードデバイスがトラックに搭載されている道路。 現在、システムは道路やその他の種類の車両を対象に拡大しています。 ちなみに、機内機器（電子チケット）のない旅行の宣言的な性質を規定しているものの、利益の90％を提供するのは機内デバイスのユーザーだけです。



スロバキアのシステムは2010年に委託され、2500 kmを超えるデータ収集を提供します。 232,000の航空機搭載デバイス（3.5トンを超えるトラック）のある道路。 昨年10月、電子チケットはキャンセルされました。現在、各トラックはオンボードデバイスをオンにしてスロバキアを走行する必要があり、国境またはサービスポイントのいずれかで無料で入手できます。 現在、システムは道路の数に関しても拡大しています。



この三位一体のハンガリーのシステムは最年少で、昨年7月に6,500kmで運用されました。 地元の高速道路によって選択された道路。 ハンガリーでは車内デバイスを使用する必要はありません。旅行の支払いの主な手段は「電子チケット」の購入です。電子デバイスを使用すると、事前にルートを計画して厳密に遵守する必要がなくなるため、支払いの便宜上のみ導入されます。



特別な場所の道路での充電に関する規則の実施を監視するために、ドイツでは300、スロバキアでは46ほど、ハンガリーでは25の地域に制御ポータルが設置されました。 驚きの要因を導入するために、制御ポータルのモバイル類似物も道路に沿って移動しています-特別に装備されたバンは、2〜3個の固定支持体ごとに1つあり、スロバキアのバンには、その場でペナルティを受ける銃を持つ地元の交通警官がいます。



フランスでは、トラックから環境税を徴収するためのシステムを作成する同様の範囲のプロジェクトが考案されました。 しかし、昨年8月の実施段階で、ブルターニュ出身のinするトラック運転手が変な帽子をかぶって道路に足を踏み入れ、高価な路上機器を燃やして捨て始めました。 フランス政府は、このプロジェクトを1年間肩をすくめ、凍結しました。 このプロジェクトは再び明らかになりましたが、限られた数の道路でボリュームが削減されています（もちろん、南部地域はボリュームから除外されています）。



ロシアに関しては、ここでロサヴトドルは、スロバキアのものとイデオロギー的に類似したシステムを作成するための競争も発表しました。 この記事を書いている時点では、コンテストの運命は非常にあいまいでした。 しかし、一つのことは明らかです-ロシアの同様のシステムが遅かれ早かれ現れるでしょう。 ここでは（そしてコメントでも）道路でお金を集めるという考え方の社会的および経済的側面については議論しませんが、このクラスの自動化問題を解決するためのアプローチの正しい技術的見解を形成しようとします。 「正しい」とは、欧州規格で定められた充電システムのコンポーネントのアーキテクチャと機能の最新の理解に基づいて、ビューを理解することを提案します。

建築に取り組みましょう

まず、収集プロセスの参加者の役割を特定します。 役割を決定するプロセスは過去15年間EUで解決されており、この方向での分析的思考の変動の分析は別の投稿に値するものであるとすぐに言わなければなりません。 交渉の戦いで多くの熊手を踏み、100部のコピーを破って、技術コミュニティは、現代の要件を満たす単純で理解可能なロールモデルを開発しました。 ばかげているように聞こえるかもしれませんが、ヨーロッパでは現在、料金システムの分野で、パッチワークの自動化に封建的不和を乗じた典型的な例があり、それにビジネス、政府機関、道路利用者の利益の重ね合わせが乗じられています。



したがって、1つのシステムを導入しようとしても、ユーザーが1つのオンボードデバイスでヨーロッパ中を移動できるという試みがこれまで連続して失敗したことは驚くことではありません。 ブリュッセルは相互運用性の問題を解決するために定期的に多額の資金を割り当てています。そのために、彼らは無限のパイロットプロジェクトを実施し、大量の紙を書きます。 今年だけ、トンネルの終わりに光が灯りました.EUのプロファイル委員会は、ゴーディアンの結び目を非常に不快な方法で切断することを決定しました-自発的に導入することができなかったものを導入することで指示する-ウォッシュビジネスのすべての参加者間の情報交換のまさに基準。



標準の最新バージョンの役割は、機能のレベルで定義されています。

• 料金徴収（TC） -「道路の所有者」の役割。道路を建設したか、経営陣に道を譲り、道を通る車からお金を引き裂こうとする組織。
• Toll Service Provisioning（TSP）は、自動化ツールを使用して料金徴収サービスを直接提供する役割です。

警告が1つあります（課金システムの専門家は嘘をつかないようにしています）。 西側では、資産（道路）の所有者が直接関税計算の機能を実行することが非常に多くあります。 つまり、TCとTSPの間で次のようなことが起こります。



TSP：ほら、ユーザーが有料道路で150キロメートル走った、ここに料金表のデータがある

TC：OK、すべてが正しいようです。 （レジの音）。 彼から5ユーロを受け取り、アカウントの詳細を以下に示します。

TSP：ユーザーよ、運賃のお金を運転してください、これは道路の所有者からのアカウントです



リソースの所有者は情報処理チェーンに直接関与しているため、西洋人は異なるシステム間で請求機能とCRM機能を頑固に分散しています。 それどころか、ロシアでは、契約、支払い、さらには「課金」という名前の加入者機器との連携機能を非常に気に入っています。 課金オペレーターは従来からユーザーにサービスを提供し、料金を計算するため、これらの機能を論理的に分離する必要はありません。 原則として、エンティティを結合するほうがエンティティを分離するよりも簡単なので、これは問題ではありません。



しかし、実際の設計では、一般的な哲学的定義では十分ではありません。 地域の特異性と専門家の考え方の両方を考慮する必要があります。 アーキテクチャを設計する際に安全に信頼できる客観的な現実があります-衛星測位データを処理してお金に変える技術的なチェーンです。 これは素晴らしい本「Road User Charging and Electronic Toll Collection」（ Amazonへのリンク ）から引き裂かれた写真です





衛星測位データに基づくSVPでのデータ処理の段階



位置決めはオンボードデバイスで行われます。 この場合、追加情報が収集される場合があります。 多くの場合、3軸加速度計がコントロールユニットに取り付けられますが、ジャイロスコープはあまり使用されません。 車のCANバスに接続して、コンピューターにデータを取り込む機能を追加することはあまりありません。 充電の目的で、ドライバーは通常、自分用にコントロールユニットを設置します（ドイツでは、認可されたセンターがこれを行います）。 したがって、インストール中に複雑な操作は提供されません-フロントガラスに貼り付けられ、シガーライターに貼り付けられて追い出されました。



コントロールユニットからのデータはフロントエンドシステムに入ります。その主なタスクは、有料道路セグメント（および橋、トンネル、交差点など）の使用時に座標シーケンスを証明書に変換することです。 家庭用ナビゲーターが行うように、道路グラフの端にトラックを取り付けることができます。また、セグメントを使用する決定は、車が特定のエリア（仮想ゲートウェイ）を通過するという事実に基づいて行うことができます。 スロバキアとドイツでは、トラックの主要な処理はコントロールユニット（いわゆる「スマートコントロールユニット」）で直接行われます。 現代のアーキテクチャでは、座標と一部のサービス情報のみを送信するライトコントロールユニットの使用がより重視されており、すべての処理は中央システムで行われます。



ルート分析機能は、セグメント検出エラーを隠すように設計されています。 たとえば、トラックを失った場合、またはデータが間違って入った場合、テレポートがまだ発明されていないことがわかっている場合、利用可能なポイントでルートを完了し、静かにユーザーをアカウントに追加できます。 もちろん、このような分析データには請求のための特別なマークがあり、個別のKPIで評価されます。



使用状況データは、車両識別子に関連付けられたセグメントの識別子によって簡素化されます。 これらは、通信サービスの使用に関するデータと同様の請求システムで処理されます。 原則として、このパートでは、eTomビジネスモデルを安全に使用できます。 各セグメントは関税に関連付けられており、時間、車種などによる修飾子があります。



次の図は、SVPを設計するときに信頼できる情報処理の各段階で使用される欧州標準を示しています。





有料道路の使用に関する情報を処理するプロセス



ご覧のとおり、標準化されているのはチェーンの中心的な技術部分のみです。 コントロールユニットからフロントエンドシステムに送られるデータの形式は標準化されていません。 ヨーロッパでは、伝統的に、この部分は独自のプロトコルを使用し、多くの場合コントローラーのセットと対応するフロントエンドを提供するコントローラーのサプライヤーに任されていました。 この部分のインターフェースの標準化はまだ行われていると思います。



本質的に少し。

• 料金レポート -使用済みの道路セグメントに関する情報と関連情報を含む、フロントエンドから送信される標準形式のデータ構造。
• 通行料申告 -料金レポートに基づいて確立されたタイプの定期的に生成されるTSP文書。TCが関税額を計算するために必要な情報が含まれています。 TSPとTC間の公式文書フローの要素（ロシア連邦では一般的ではありません）。 欧米のビジネススキームでは、多くの場合、関税計算機能はTCレベルで直接実行されます。 TSPは、TCが関税額を計算することに基づいて、関税を計算するためのデータを準備し、この請求書に基づいてユーザーに請求する公式TSP文書の形式でそれを返します。
• 請求詳細 -TC側で請求額を決定するために必要かつ十分なデータセット。
• 支払請求は、支払金額を含む請求明細に基づいて定期的に生成される文書です。 通行料申告と同様に、反対方向のみ-TCからTSPへ

役割間の相互作用は非常に単純かつ論理的であることが判明したため、エンドツーエンドおよび各ステップごとに個別に課金プロセス全体のビジネスKPIを測定するための標準を開発および適用できました（ISO 17444を参照）。



基本的な充電プロセスを中心に、ISO 17573に記述されているSVPアーキテクチャ全体が構築されていますが、ローカルの現実に理論を当てようとすると、次の画像が得られました。





課金プロセスの参加者の情報相互作用のスキーム



プロビジョンレベルをTSP =「SVPオペレーター」と別のロール「情報収集サービスBUのプロバイダー」に直接分割しました。 ユーザーサービスの機能（個人データ）とテレマティクスBUの収集機能を分離することは論理的に思えるので、分離は基本です。 さらに、使用済み機器のサプライヤが多数存在する場合があります。 たとえば、ハンガリーでは、約20のコントロールユニットのサプライヤがあり、各サプライヤには独自のデータ処理システムがあります。 それらはすべて、単一の状態システムですでに処理されている標準化された使用状況レポート（Toll Declaration）を生成します。



充電レベルは3つの役割で表されます。 「有料道路オペレーター」はTC（Toll Charger）です。 ロシアでは、SVPに関するTCの機能は、財務管理、課金ルールの形成、およびその実装の直接管理に限定されています。



制御データを分析する機能は、「支払い制御システムのオペレーター」という別の役割に含まれています。 TCが望む場合、彼は違反を分析するための部門を自分で作成できますが、多くの場合、この機能は、制御フレームワークから写真とビデオの記録データを収集し、認識されない番号を検証し、債権回収文書を生成する別の専門会社に任されます



「交通情報収集サービスプロバイダー」の役割には、制御ポータルの直接操作の機能が含まれます。 私の国は広く、私の家であり、多くのポータルが必要であり、それらはすべての主要道路に設置されます。 センターからこの経済すべてにサービスを提供することは困難であるため、全国の複数の企業が実行できるホテルの役割でこれらの機能を選択することは論理的です。 単一の形式で解析データが提供されます。



今日は以上です。 そのような声明の後、1年以上が経過したので、私は次の資料のトピックを宣言しません。 親愛なる行商人、この問題に関するあなたの意見をよく聞いてください。 このトピックは新しいので、どんなアイデアでもその具体化を見つけることができます。 もう一度お願いします-社会的および政治的分野を掘り下げてみましょう。 私は個人的には世界平和のために、渋滞や速度制限のない無料のアウトバーンのためです:)