約1年前、交通信号から車に情報を送信する実験であるTravolutionについて最初に読みました。 要するに、実験のアイデアは、信号機が切り替わるタイミングと推奨速度を運転手に伝えて、「緑の波」に入る、つまり信号機で止まることなく移動することです。 この実験については、Habréに関する記事がありました 。 実験の結果は驚くべきことではなく、肯定的なものでした。 しかし、それにもかかわらず、この技術の実用化に疑問の余地はありません。
明らかに、これは実装の複雑さによるものです。システムを機能させるには、特別装備の信号機と特別装備の車、つまりインフラストラクチャの根本的な変更が必要だからです。
しかし最近、既存のインフラストラクチャでグリーンウェーブを実現する方法が思いつきました。
私の考えでは、このテクノロジーを実装するには3つの主要なコンポーネントが必要です。
- 信号機を運転手に切り替える際のデータを視覚化するツール。
- 信号機からデータを取得する方法。
- このデータを最初のメディアに転送する方法。
明らかに、データ視覚化ツールはスマートフォンです。 これまでのところ誰もがスマートフォンを持っているわけではありませんが、それだけです。
データ転送の方法はモバイルインターネットです。 はい、ここでも、すべてがスムーズであるわけではなく、カバレッジがどこにでもあるわけではありませんが、この方向に進歩があります。
しかし、信号機からデータを取得する方法は？
オプション1は、CISにとっては非常に高価であり、外国にとっては非常に現実的です。
当局に同意し、信号機のデータをモバイルインターネット経由でデータセンターに送信するように、信号機にセンサーを配置します。オプション2-CISで多少リアル：
必要な信号機からそれほど遠くない建物を所有している企業と調整し、外部のビデオ監視がある場合は、適切な信号機を見る1台のカメラからのビデオがデータセンターに送信されるようにします。ビデオカメラのある建物が近くにない場合は、たとえば、データセンターにデータを転送するように 、自律IPカメラを設置することに同意できます。 はい、これは「既存のインフラストラクチャを使用する」とは言えませんが、大規模であっても非常に現実的であるように思えます。
データセンターでは、結果の画像の信号機とその色を認識する必要があります。 固定カメラからの写真の場合、タスクは完全に簡単です。 また、データセンターに転送する場合でも、全体像は必要ありません。信号機のある小さなエリアに限ります。
信号機の切り替え時間に関するデータがどのように受信されても、それらはスマートフォンに送信されます。 ただし、インターネットを介してリアルタイムでデータを送信することはできません。 必然的に何らかの遅延が発生します。 そのため、前回の信号機切り替え時のデータをスマートフォンに送信する必要があります。 スマートフォンでは、受信したデータと以前の信号機の切り替えに関する一連のデータに基づいたアプリケーションは、次の信号機の切り替えの時間を予測し、この情報をドライバーに提供する必要があります。
もちろん、これらの予測はすべて、定期的な間隔で切り替わる通常の信号機でのみ機能し、切り替えモードは1日に数回しか変更されません。 つまり、 スマートな信号機では、このようなシステムは役に立たない。 特に、データがカメラを通してキャプチャされる場合。 しかし、「残念ながら」CIS諸国では、スマートな信号機はほとんどありません。 モスクワに約3000の信号機があり、そのうち50のみが制御されている場合、小さな都市ではおそらくスマートな信号機はさらに少なくなります。
スマートな信号機がある国では、まず、信号機から直接データを削除することに同意することは十分に可能です。次に、信号機からではなく、交通管制センターから直接データを取得することもできます。 さらに、この方法では、信号機の切り替え時間を予測することはできませんが、 ASUDDのデータセンターから次に計画されている信号機の切り替えに関する実際のデータを取得することができます。
その後、これらのデータを視覚化して、スマートフォンの画面に表示する必要があります。
ここで私はこのようなアイデアに出会いました：
「高速道路に沿って、セクションで緑または赤に光るランプまたはガス放電管のテープを設置することが提案されています。 輝くエリアは、「グリーンウェーブ」の速度と同じ速度で高速道路に沿って移動する必要があります。 ドライバーがそのような速度を維持して、グリーンゾーンにいるだけで十分です。」
これは緑の波を視覚化するための非常に良いアイデアであるように思えます。
この考えを現代の現実に適用すると、投稿タイトルから写真が得られます。
ゾーンごとの道路標示：
- 赤い部分は、車が信号機の前にある領域です（赤と黄色の信号機）。
- 黄緑-「緑の波」の前の危険な部分。信号の前に立っている車の前で止まる危険があります。
- 緑-最も収益性の高い「緑の波」の裏側。
その他の指定
- 赤い六角形で、次の信号が切り替わるまでの時間。
- 緑色の円では、緑色の波を走行し続けるための推奨速度。
- 青い三角形は乗り物です。
このようなサービスは、既存のインフラストラクチャで実現できるだけでなく、それを引き受ける開発会社にとっても有益であると思います。 しかし、小さな会社ではできません。 信号の時間に関する情報を収集するためのインフラストラクチャを作成するには、多額の投資が必要です。 しかし、ナビゲーションサービスを専門とする大企業や、単に独自のナビゲーションサービスを所有している大企業は、このアイデアを実践し、車内のナビゲーション用ソフトウェアの他のサプライヤーから際立っているかもしれません。
そして、私には、これは本当に便利なサービスであり、お金を求めるのは恥ではありません。 もちろん、このシステムはラッシュアワーには機能しませんが、他の場合には本当に便利で便利です。 公共交通機関専用の路線がある都市のバスには特に便利です。
PSモスクワにとって、このシステムはどんな形であれ、まったく役に立たない。
Update1： izmalkからのコメントに基づきます。
システムは潜在的に危険な可能性があります。実際、信号機の切り替え時間に関するアプリケーションの予測が実現しない可能性があるためです。 したがって、緑の波の前部は、特定の天候と速度で特定の車のブレーキ距離まで押し戻され、安全率が乗算されます。 そして、アプリケーションは「緑の波」に乗っても安全な場所に情報を表示します。 問題は、何かが同時に緑の波に残るかどうかです。
はい、このためには、気象情報をデバイスに転送する必要もあります。
inborn_killerからのコメントに基づきます。
また、アプリケーションに社会的責任のコンポーネントを導入することもできます。
ドライバーがアプリケーションを使用して赤い波を飛び越え、スピードを上げて緑色になった場合、アプリケーションはしばらくオフになり、ユーザーに過剰な罰を与えます。 一方で、これは「ネガティブフィードバック」であり、通常は開発者にとってタブーですが、一方で、命を救うことができます。 そして、速度を超えると、制動距離が増加するため、「緑の波」は単純に制動距離に食われていると想定できます。