IoT プロバイダーからのメモ。 都市照明における LoRaWAN の技術と経済性

最終話では…

XNUMX年ほど前、私は 私が書きました ある都市における都市照明の管理について。そこではすべてが非常にシンプルでした。スケジュールに従って、SHUNO（外部照明制御キャビネット）を介してランプの電源がオンまたはオフになりました。 SHUNOにはリレーがあり、その指令により一連のライトが点灯しました。おそらく唯一興味深い点は、これが LoRaWAN 経由で行われたことです。

ご記憶のとおり、私たちは当初、Vega 社の SI-12 モジュール (図 1) をベースに構築されました。パイロット段階でもすぐに問題が発生しました。

図 1. — モジュール SI-12

1. 私たちは LoRaWAN ネットワークに依存していました。重大な電波障害やサーバーのクラッシュがあり、街の照明に問題があります。可能性は低いですが、可能性はあります。
2. SI-12はパルス入力のみです。電気メーターを接続して、そこから現在の測定値を読み取ることができます。しかし、短期間（5 ～ 10 分）では、ライトを点灯した後に起こる消費量の急増を追跡することは不可能です。これがなぜ重要なのかを以下で説明します。
3. 問題はもっと深刻です。 SI-12 モジュールがフリーズし続けました。およそ20回の手術にXNUMX回程度です。ベガと連携して原因の解消に努めました。パイロット中に、XNUMX つの新しいモジュール ファームウェアとサーバーの新しいバージョンがリリースされ、いくつかの重大な問題が修正されました。最終的に、モジュールはハングしなくなりました。それでも私たちは彼らから遠ざかりました。

そしていま...

現在、私たちはさらに高度なプロジェクトを構築しています。

これは、IS-Industry モジュールに基づいています (図 2)。ハードウェアは当社の外注業者によって開発され、ファームウェアは自分たちで作成されました。これは非常に賢いモジュールです。ロードされているファームウェアに応じて、照明を制御したり、大量のパラメータを使用して計測デバイスに問い合わせたりすることができます。たとえば、熱計や三相電力計などです。
実装された内容について少し説明します。

図 2. — IS-Industry モジュール

1. これからも、IS-Industry には独自の記憶があります。ライト ファームウェアを使用すると、いわゆるストラテジーがリモートからこのメモリにロードされます。要するに、一定期間SHUNOをオン・オフするスケジュールです。ラジオのオン/オフを切り替えるときに、ラジオ チャンネルに依存する必要はなくなりました。モジュール内には、何があっても動作するスケジュールがあります。各実行には必ずサーバーへのコマンドが伴います。サーバーは状態が変更されたことを認識する必要があります。

2. 同じモジュールが SHUNO の電力メーターに問い合わせることができます。消費量を含むパッケージと、メーターが生成できる大量のパラメーターが XNUMX 時間ごとにメーターから受信されます。
しかし、それは問題ではありません。状態変化の 3 分後、瞬間的なカウンターの読み取り値とともに異常なコマンドが送信されます。これらから、ライトが実際にオンになったかオフになったかを判断できます。または、何か問題が発生しました。インターフェースには XNUMX つのインジケーターがあります。スイッチはモジュールの現在の状態を示します。電球は消費の有無に関係しています。これらの状態が互いに矛盾する場合（モジュールの電源はオフだが消費は継続している、またはその逆）、SHUNO の行が赤色で強調表示され、アラームが作成されます（図 XNUMX）。秋には、このようなシステムがスターターリレーの詰まりを発見するのに役立ちました。実際、問題は私たちのものではなく、私たちのモジュールは正しく動作しました。しかし、私たちは顧客の利益のために仕事をします。したがって、照明に問題を引き起こす可能性のある事故を彼に見せなければなりません。

図 3. — 消費量はリレーの状態と矛盾します。そのため、その行は赤で強調表示されています

グラフは時間ごとの測定値に基づいて作成されます。

ロジックは前回と同じです。電力消費量を増加させることでスイッチがオンになることを監視します。私たちは消費量の中央値を追跡します。消費量が中央値を下回っている場合は、一部の照明が切れていることを意味し、中央値を上回っている場合は、電柱から電力が盗まれていることを意味します。

3. 消費量に関する情報とモジュールが正常であることを示す標準パッケージ。彼らはさまざまな時間に登場し、放送中に混雑を引き起こすことはありません。

4. 前と同様に、いつでも SHUNO を強制的にオンまたはオフにすることができます。たとえば、緊急隊員がチェーン内の切れたランプを探す必要があります。

このような改善により、耐障害性が大幅に向上します。
この管理モデルは現在、おそらくロシアで最も人気がある。

そしてまた...

私たちはさらに歩きました。

実際のところ、古典的な意味での SHUNO から完全に離れて、各ランプを個別に制御できるということです。

これを行うには、懐中電灯が調光プロトコル (0-10、DALI またはその他) をサポートし、Nemo ソケット コネクタを備えている必要があります。

Nemo-socket は標準の 7 ピン コネクタ (図 4) であり、街路照明でよく使用されます。電源およびインターフェース接点は懐中電灯からこのコネクタに出力されます。

図 4. — Nemo ソケット

0-10 はよく知られた照明制御プロトコルです。もう若くはありませんが、十分に実績があります。このプロトコルを使用したコマンドのおかげで、ランプのオン/オフを切り替えるだけでなく、調光モードに切り替えることもできます。簡単に言えば、照明を完全に消すのではなく、照明を暗くします。特定のパーセント値で暗くすることができます。 30とか70とか43とか。

それはこのように動作します。当社の制御モジュールは Nemo ソケットの上部に取り付けられます。このモジュールは 0 ～ 10 プロトコルをサポートします。コマンドは無線チャネル経由で LoRaWAN 経由で届きます (図 5)。

図 5. — 制御モジュールを備えた懐中電灯

このモジュールで何ができるのでしょうか?

彼はランプのオンとオフを切り替えたり、一定の明るさまで暗くしたりできます。また、ランプの消費量を追跡することもできます。調光の場合は消費電流が下がります。

現在、私たちは一連のランタンを追跡しているだけではなく、すべてのランタンを管理し、追跡しています。そしてもちろん、ライトごとに特定のエラーが発生する可能性があります。

さらに、戦略のロジックを大幅に複雑にすることもできます。

例えば。ランプ 5 番に、18 時から 00 時に点灯し、3 時から 00 時 50 分まで 4 パーセント暗くし、その後 50 パーセントで再び点灯し、9 時 20 分に消灯するように指示します。これらすべてはインターフェースで簡単に設定でき、ランプにとって理解可能な動作戦略に形成されます。この戦略はランプにアップロードされ、他のコマンドが到着するまでそれに従って動作します。

SHUNO用モジュール同様、無線通信が途切れるという問題はありません。重大な問題が発生した場合でも、照明は機能し続けます。さらに、たとえばXNUMX個のランプを点灯する必要があるときに、急いで放送する必要はありません。状況を読み取って戦略を調整しながら、それらを XNUMX つずつ簡単に回避できます。さらに、デバイスが稼動していて通信の準備ができていることを示すシグナリング パケットが一定の間隔で設定されます。
予定外のアクセスは緊急の場合にのみ行われます。幸いなことに、この場合、私たちは常に食料を得ることができ、クラスCを買う余裕があります。

重要な質問ですので、もう一度提起します。私たちがシステムを紹介するたびに、彼らは私に尋ねます - 写真リレーはどうですか?そこにフォトリレーをねじ込むことはできますか？

純粋に技術的には何の問題もありません。しかし、現在私たちがやり取りしている顧客は全員、フォトセンサーから情報を取得することを断固として拒否しています。彼らはスケジュールと天文学的な公式だけを使って行動することを要求します。それでも、都市照明は非常に重要かつ重要です。

そして今、最も重要なことです。経済。

無線モジュールを介して SHUNO を使用すると、明らかな利点があり、比較的低コストです。照明器具の制御性が向上し、メンテナンスが簡素化されます。ここではすべてが明確であり、経済的メリットは明らかです。

しかし、各ランプの制御が難しくなる。

ロシアでも同様の完成したプロジェクトがいくつかある。同社のインテグレータは、調光によって省エネを達成し、プロジェクトの費用を支払ったと誇らしげに報告しています。

私たちの経験から、すべてがそれほど単純ではないことがわかります。

以下に、調光による利益を年間ルーブル単位とランプ 6 個あたりの月単位で計算した表を示します (図 XNUMX)。

図 6. — 調光による節約額の計算

30 日に照明が点灯している時間を月ごとに平均して示します。この時間の約 50% は 30% の出力でランプが点灯し、残りの 30% は XNUMX% の出力で点灯すると考えられます。残りはフル稼働です。小数点以下を四捨五入して表示します。
簡単にするために、50 パーセントの電力モードでは、光の消費量が 100 パーセントのときの半分になると考えます。ドライバーの消費量は一定であるため、これも少し間違っています。それらの。実際の節約額は表よりも少なくなります。しかし、理解を容易にするために、そのようにしましょう。

電力 5 キロワットあたりの価格を法人の平均価格である XNUMX ルーブルと仮定します。

合計すると、313 年間で実際には 1409 つのランプで XNUMX ルーブルから XNUMX ルーブルを節約できます。ご覧のとおり、低電力デバイスでは利点は非常にわずかですが、強力なイルミネーターを使用すると、さらに興味深いものになります。

費用についてはどうですか？

LoRaWAN モジュールを追加すると、各懐中電灯の価格が約 5500 ルーブル高くなります。そこでは、モジュール自体は約3000で、ランプのNemo-Socketのコストはさらに1500ルーブルで、さらに設置と構成作業が必要です。このようなランプの場合、ネットワークの所有者に加入料を支払わなければならないことはまだ考慮していません。

最良の場合 (最も強力なランプを使用した場合)、システムの投資回収期間は XNUMX 年弱であることがわかりました。返済。長い間。

ただし、この場合でも、受信料によってすべてが無効になります。それがなければ、依然として LoRaWAN ネットワークの維持コストも含まれなければなりませんが、これも決して安くはありません。

救急隊員の作業も若干節約され、より最適に作業を計画できるようになりました。しかし、彼女は救わないだろう。

すべてが無駄だったことが判明しましたか？

いいえ。実は、ここでの正解はこれです。

すべての街灯を制御することはスマートシティの一部です。この部分は実際にはお金の節約にはならず、さらに少し追加料金を支払わなければなりません。しかし、その代わりに私たちは重要なものを手に入れました。このようなアーキテクチャでは、各極で XNUMX 時間常に一定の電力が保証されます。夜だけではありません。

ほぼすべてのプロバイダーがこの問題に遭遇しています。メイン広場でWi-Fiを作る必要があります。あるいは公園のビデオ監視。行政はゴーサインを出し、支援を割り当てます。しかし問題は、照明柱があり、そこでは電気が夜しか利用できないことです。サポートに沿って追加の電力を供給したり、バッテリーやその他の奇妙なことを取り付けたりするなど、トリッキーなことを行う必要があります。

ランタンごとに制御する場合、ランタンと一緒にポールに別のものを吊るすことも簡単にできて「スマート」になります。

そしてここでも経済性と適用性の問題が生じます。街の郊外のどこかにあるSHUNOだけで十分です。中心部では、より複雑で管理しやすいものを構築するのが合理的です。

重要なことは、これらの計算には実数が含まれており、モノのインターネットに関する夢ではないということです。

PS この一年間、照明業界に携わる多くのエンジニアとコミュニケーションを取ることができました。そして、それぞれのランプの管理には依然として経済性があることを私に証明してくれた人もいました。私は議論に応じます、私の計算は示されています。そうでないと証明できれば、必ずそれについて書きます。

出所： habr.com