この技術の本質は、専用の車載デバイスを使用して車両の動きに関する情報を収集し、この情報を分析して有料道路の運賃を計算することです。
多くの場合、道路での充電プロセスを監視するために、前の記事で説明した MLFF機器と技術的に同一の固定制御システム（CCK）の特別な機器が設置されます 。
料金徴収プロセスおよびSVPの主要なビジネスプロセスにおける参加者の役割
先ほど詳しく説明した西洋の機能指向アプローチでは、基本的なビジネスプロセスからシステムアーキテクチャの設計を開始する必要があります。基本的なビジネスプロセスから機能へ、そして機能から技術ソリューションへとスムーズに移行します。
既存のプロジェクトの経験と分析の一般化により、すべての参加者の関係を何らかの形で説明する多くのビジネスモデルが出現しました。 この記事では、ヨーロッパの経験に限定することを提案します。
欧州連合の支援を受けてASECAP（有料道路事業者とその機器のメーカーのコミュニティ）によって開発されたCESAREモデルは、有料高速道路市場のすべての参加者に料金を徴収する一般的なアプローチを開発および実装するように設計されています。
代替モデル「 GNSS対応サービスコンバージェンス（GSC） 」は、欧州連合の積極的な支援を受けて、欧州のハードウェアおよびソフトウェア市場の多数の参加者によって推進されており、GNSSおよびEGNOS（GPS精度を改善するための欧州システム）に基づく料金徴収システムを構築するための一般的なアーキテクチャアプローチを開発するように設計されています。
CESAREモデルの役割
CESAREモデルは、3つの主要な役割を想定しています。
- ユーザー（サービスユーザー） -SVPに登録された車両所有者。
- オペレーターSVP（Toll Charger） -ユーザーとの正しい決済の実装を担当します。
- サービスプロバイダー（サービスプロバイダー） -1つ以上のサービスレベル契約（SLA）を通じてオペレーターの情報および技術サポートを担当します。
ダイアグラムには4番目の役割もあります。InteroperabilityManagerは、さまざまなSVPの技術的な互換性を提供し、オペレーター間の決済のためのクリアリングサービスを提供します。 この役割は、SVPが並行して開発されたヨーロッパの典型的な役割であり、統合の問題は長い間非常に深刻でした。 このような複雑な回路を作成する必要性を回避できることを本当に願っています。
SVPプロバイダーは、サービスの実装手段であるハードウェアとソフトウェアの複合体であるプラットフォームの所有者です。
プロバイダーは、次の3つのタイプに分類できる多くのビジネスプロセスも実装します。
- 商業プロセス -ユーザーの連絡、請求、機内デバイスのロジスティクスなど 一般に、商業部門のビジネスプロセスモデルは、通信eTOMと非常によく似ています。 しかし、それにもかかわらず、このモデルを直接借りることはお勧めしません。 SVPのニーズに対しては、冗長性が高すぎると同時に、多くの最も重要なニュアンスを考慮していません（これについては、個別に詳しく説明できます）。 SVPの注文が私たちの兄弟インテグレーターに届くと、彼の専門家（通常は電気通信に精通している）がすぐに関連プロジェクトからeTOMモデルと自動化機器を取ります（紳士の肩からの請求、またはさらに悪いことに箱入りモンスター大手ベンダーから）。 近くの顧客にプロジェクトを持ち込み、予算を削減するために、これは非常に簡単です。 しかし、あなたが正直に働くビジネスを構築する必要があるなら、通信を忘れてください！ この経験は間違いなくあなたの役に立つでしょうが、この分野では大幅に充実させる必要があります。
- 運用（技術）プロセス -有料道路の使用、関税計算、不正管理などに関する情報の収集と調整 ビジネス固有のプロセス。 以下で詳細に説明します。
- すべてのITエコノミーに共通する技術的な運用プロセス ：定期的なメンテナンス管理、道路での修理作業の安全性を確保するための特定のプロセスなど、「古典的な」ITSMプロセスのブロック
オンボードデバイスについて少し
スロバキアで使用されるオンボードデバイス
ユーザーへの請求書発行の基礎は、有料道路（またはその要素）を使用するという確立された事実です。 テレコムの同様の機能は、通信機器の使用に関する異種情報を収集するプリビリングモジュールによって実行されます。
道路の使用に関する情報は、車に搭載された車載デバイスによって提供されます。 最近まで、これらは車のフロントガラスに取り付けられた別個の「ボックス」でしたが、ナビゲーションと対応するアプリケーションを制御ユニットとして使用する従来のスマートフォンの使用について真剣に話し始めました。
使用の事実を計算するためのアルゴリズムは異なります。 例：
- 車は有料区間で一定のキロメートル走行しました-走行距離に対して請求書が発行されます。
- 車は有料区間の半分以上を運転しました-有料道路区間が請求されます。
- 車は有料セグメント（コントロールポイント）の選択されたエリアを走行しました-セグメント全体が請求されます。
- 車は2つのエリアを走りました-「エントリー」と「出口」。 請求書は、古典的な有料道路区間の乗り物として発行されます。
使用の事実を計算するためのデータソースは、GPSまたはGLONASS座標です。
制御ユニットがセルラーネットワークを介して中央システムにこれらの座標を送信し、そこで使用事実が計算される場合、この制御ユニットは「シン」と呼ばれます。 安価ですが、大量のトラフィックを生成するため、携帯電話のカバレッジが不十分な場合にはあまり適していません。
制御ユニット自体が使用の事実を決定し、座標ではなく、たとえば通過したセグメントの識別子を中央システムに転送する場合、そのような制御ユニットは「インテリジェント」と呼ばれます。 メモリ要件（セグメントまたは検出領域のパラメーターを保存する必要があります）、プロセッサー（座標シーケンスを処理する必要があります）が増えましたが、チャネルをあまりロードせず、かなりの時間自律的に動作することができます。
しかし、「インテリジェント」クライアントの最も楽しいボーナスは、短波通信を介して、通過したセグメントのリストをその場でオフラインで受信できることです。これは、不正と戦うための最良の実用的なツールです。
中央システムから制御ユニットへ、またはその逆に機能を転送することにより、広範囲の操作が可能になり、地域の通信プロバイダーの機能と価格、課金ルール、個人データ保護に関する地域の法律などを柔軟に調整できます。
たとえば、ドイツでは、運転手は口座残高の不足を通知されない場合でも運転を続けることができます。 したがって、ドイツの制御装置は残高をカウントできます。セグメント識別子とともに、現在の料金表がメモリにロードされます。
ドイツのオンボードトラック税
スロベニアには、移動に関する情報を含むPDの保護に関する厳しい法律があるため、そこに搭載されているデバイスは、引き落とされる金額と一部の加入者識別子のみをセンターに送信でき、セグメント、トラック、名前、姓はありません！
スロベニアでの使用が計画されていた搭載デバイス。 パイロットを超えていませんでした。
フランスでは、有料道路の外で座標を転送することは禁止されています。したがって、処理のために座標を駆動する「薄い」制御ユニットのモデルを選択したという事実にもかかわらず、制御道路グラフは、ここで座標ストリームが送信される出口で制御メモリに格納されますしかし、停止します。
フランスで環境税を徴収するための車載デバイス
ニュージーランドでは、トラックの所有者はすべての道路で環境料金を支払う必要がありますが、常にそれらを使用するわけではなく、州は未使用地の控除を行う必要があります。 最近まで、彼らはそこで車輪の機械式メーター（ハブメーター）を使用していましたが、次第にオンボードデバイスへの切り替えを開始しました。
ニュージーランド 機械式ハブメーター（高度なモデル）。
ニュージーランド 機械式ハブメーターを交換するためのコントロールユニット
つまり、さまざまな国に多くのニュアンスがあり、建築上のソリューションもあります。
鉄に関しては、オプションもあります。 誰かがCとC ++のプログラミングで軽量で生産的なデバイスを作り、誰かがもっと重いJavaプロセッサーを使用しています。 最近、JVM、メモリ、3つのプロセッサ、セキュリティモジュール、GSMモデム、GPS受信機、および自動車CANを含む多数のインターフェイスが小さなケースに詰め込まれたときに、NXP ATOPなどの単一チップ上の統合ソリューションの影響が強まりました。
NXP ATOPチップの外観
NXP Atop Architecture（ ソース ）
記事の第2部では、SVPテレマティックプラットフォームの要素間の情報交換の編成に対する一連の標準と一般的なアプローチを検討します。