スマートシティ水道メーターソリューション: 世界の電力会社は現在何が変わっているのか?

従来のメーターの苦情は遅れて届く. スマートシティの公益事業者は問題を早期に発見, ただし、データがある場合に限ります, チーム, と現場対応が連携して機能します.

正確なメーターを組み合わせたスマート都市水道メーターソリューション, AMI通信, クラウドプラットフォーム, アラームルール, 課金の統合, およびフィールドワークフロー. 主な変更点はリモート読み取りだけではありません. NRW州全体の視認性が向上します, 顧客からの苦情, エンジニアリング上の決定, および請求データ.

グローバルプロジェクトではこの違いがはっきりとわかります. 従来の公共事業会社は、顧客が請求書の問題に気付いた後に苦情を受けることがよくあります. スマートシティの公共事業体が警報を受信, ログをアップロードする, 消費曲線, 苦情が紛争になる前のフィールドデータと.

スマートシティにおける水道メーターの役割?

スマートシティは目に見えない水を管理できない. メーターフリートがブラインドの場合, NRW州, 請求する, 苦情は常に反応します.

スマートシティの水道メーターは検証済みの消費量データを提供します, イベント記録, 遠隔読書, およびアラーム入力. 無収水削減をサポートします, 請求品質, 顧客サービス, エンジニアリング上の決定, ただし、現場での修理やネットワーク管理に代わるものではありません。.

私がメーターをデータノードとして扱う理由

スマート水道メーターを単なる請求装置として扱いません. スマートシティプロジェクトにおいて, 水道システム内のデータノードとして扱います. 消費量を測定します, イベントを保存する, 地元の情報を表示します, 通信システムが正しく準備されたら、スケジュールされたデータをプラットフォームに送信します.

住宅用超音波スマート メーターは、静的超音波測定テクノロジーを使用し、インテリジェント ユーティリティやスマート シティ アプリケーション向けの IoT テクノロジーと統合できるため、この役割をサポートできます。. 一部のスマート超音波メーターは漏水検出もサポートしています, 乾いたパイプの検出, 双方向流量測定, アラーム表示, ワイヤレス M-Bus や NB-IoT などの通信オプション.

でも私は保守的であり続けます. メーターは早期警告をサポートできます. パイプの水漏れは修理できません. 機能がサポートされていれば逆流を記録できます. すべての改ざんを阻止することはできません. データの透明性を向上させることができます. 間違った顧客マスターデータを単独でクリーンアップすることはできません.

低流量捕捉用, 始動流量は常に Q1 から分離します. 参照されている超音波メーターには、極低始動流量が記載されています。 0.001 メートル³/h. 開始流量とは、メーターが体積を記録し始める点を意味します. Q1 は、宣言された計測精度範囲内の最低流量を意味します. これらは同じではありません.

DN15 住宅用例に Q3 = がある場合 2.5 メートル³/h と R = 400, それから:

この例は計算上の仮定です, 普遍的な価値観ではない. 最終Q3を確認したいと思います, r, Q1, 入札承認前に選択した製品データシートからフローを開始します.

マニュアルの読み取りから AMI 以降へ?

手作業で読むことで次の訪問の間に問題が隠れる. AMI はデータを可視化します, ただし、可視性はユーティリティが機能する場合にのみ役に立ちます.

AMI はユーティリティを定期的な手動読み取りからスケジュールされたリモート データ収集に移行します, アラームのレビュー, 通信ログ, およびプラットフォームベースのワークフロー. メーター, ネットワーク, プラットフォーム, 請求システムは 1 つのプロジェクト システムとして機能する必要があります.

AMI 導入後の変更点

手動で読む場合, ユーティリティは多くの場合、次の読み取りサイクル後に初めて問題を認識します。. お客様に漏水があった場合, 詰まったメーター, 逆流イベント, またはパイプが乾燥している状態, 問題は数週間または数か月間見えないままになる可能性があります. AMIと, ユーティリティはスケジュールされた測定値とアラーム情報を受信できます, メーターの構成とネットワークに応じて.

レポートサイクルが本当にサポートしていない限り、AMI がリアルタイムデータを提供するとは言いません. 多くのプロジェクトは毎日アップロードを使用します, 時間ごとのアップロード, またはイベントベースのアラーム. レポートサイクルはバッテリー寿命に影響します, ネットワークコスト, およびプラットフォームのデータ量. YUNIO NB-IoTシステムマニュアル内, インストーラーは最初の読み取りとアップロードの期間を設定できます, そしてクラウドプラットフォームはそれらの設定記録を記録します. これは、構成制御が重要である理由を示しています.

インストールを受け入れる前に通信もチェックします. NB-IoT マニュアルには、メーターを検証するためのモバイル CRM プロセスが含まれています, NB-IoT信号をテストする, デバイスのオンラインログを確認します. また、信号テストには約 1 分かかる場合があることにも注意してください。. これは実用的な詳細です. 信号テストがスキップされた場合, プロジェクトは後で「読み取り不可」を受け取る可能性があります” 実際にはネットワークまたは設定の問題である苦情.

AMI によりチームの責任も変更される. 計測チームは依然として精度を重視しています. IT 部門はデバイス ID を重視します, クラウドレコード, サイバーセキュリティ, プラットフォームの安定性. 請求では顧客アカウントの照合が考慮されます. 現場スタッフは設置と信号に気を配る. 1つのチームが単独で作業する場合, プロジェクトが脆弱になる.

データがNRW州と苦情パターンをどのように変えるか?

従来のNRW州の苦情は感情的で遅いことが多い. スマートシティのデータにより、より具体的な情報が得られます, しかし、さらに多くの運用上のギャップも明らかになります.

データは実際の損失を分離することでNRWの仕事を変える, 見かけの損失, メーター未登録, アラーム, アップロードがありません, 顧客の使用パターン. スマート ユーティリティでは、漠然とした苦情が減り、例外ケースの追跡が可能になります.

スマート ユーティリティにさまざまな苦情が寄せられる理由

従来のユーティリティでは, 顧客が苦情を言うのは、請求額が高すぎる場合のみです, 低すぎる, または行方不明. 次にユーティリティはメーターをチェックします, 読書記録, そして時々パイプ. 苦情は広範囲にわたる. 「メーター問題」と呼ばれることもある” たとえ根本原因が漏れだったとしても, 間違ったアカウントデータ, 不正接続, 推定請求額, または取り付けが悪い.

スマートシティプロジェクトにおいて, 苦情構造が変化する. より具体的なケースが見られる. お客様は、なぜポータルに夜間の流れが表示されるのか尋ねるかもしれません。. 請求では、1 つのメーターが 3 日間アップロードされなかった理由を尋ねられる場合があります. 工学部は、なぜ地区の夜間最低流量が上昇しているのかを尋ねるかもしれない. IT 担当者は、デバイスに異常なログが存在する理由を尋ねる場合があります。. これらは同じ苦情ではありません. それらはデータ駆動型の例外です.

スマート超音波メーターは漏水検出をサポートする可能性がある, 乾いたパイプの検出, 双方向流量測定, 逆流警報表示, そして無線通信. これらの機能は、ユーティリティが異常なイベントを早期に発見するのに役立ちます。. ただし、現場での確認が不要になるわけではありません. 漏れアラームは継続的な流れを示している可能性があります, しかし、電力会社は顧客の配管をチェックする必要がある, 給水管の状態, またはプラットフォーム アラーム ルール.

NRW州の場合, 私はメーターを唯一の解決策として扱いません. NRW には実際の漏洩が含まれる, 見かけの損失, メーター未登録, 不正な接続, 請求エラー, 顧客データベースのエラー, そして修理が遅れた. スマート都市水道メーターソリューションは、低流量の回収を改善することで無収水削減をサポートできます, リモートデータ収集, アラーム, 地区の可視性と. メーターが作業をサポート, しかし、それは圧力管理に代わるものではありません, 漏れ修理, 不正接続制御, またはデータクリーニング.

部門を超えたコラボレーション (エンジニアリング, それ, 請求する)?

部門が別の部屋で作業しているとスマート メーター プロジェクトが失敗する. データはチームを横断する, したがって、プロジェクトは複数のチームにまたがる必要もあります.

スマートシティのメーターにはエンジニアリングが必要, それ, 請求する, 顧客サービス, フィールドチームとデバイスデータを共有する, 設置記録, アラームルール, 請求ロジック, および苦情ワークフロー. AMI はオペレーティング モデルです, メーターの購入だけではなく.

各部門は真実の 1 つのバージョンを共有する必要がある

私は通常、AMI の計画中に簡単な質問を 1 つします。: メーターのアップロード後のデータの所有者? 答えが不明瞭な場合, プロジェクトの準備ができていません.

エンジニアリングは圧力関連のデータを必要とする場合があります, 消費動向, 地区の不均衡, 漏れ信号. 一部の超音波スマートメーターは、オプションで圧力検出を統合できます。, 構成に応じて. IT 部門はデバイスのセキュリティを求めています, サーバーアクセス, APIの安定性, データベースのバックアップ, そして通信状況. 請求には検証済みの測定値が必要です, アカウントマッチング, 料金ロジック, と例外処理. カスタマーサービスはユーザーへの明確な説明を求めています.

NB-IoT インストール ワークフローは、このコラボレーションが重要である理由を示しています. 設置者はモバイル CRM アプリを使用して水道メーターを確認する場合があります, テスト信号, オンラインログを確認する, 初期読み取り値を設定する, アップロード期間を設定します. インストーラが間違った初期値を設定した場合, 請求時に不正なデータが受信される. IT部門がデバイスログを確認しない場合, 請求では測定値が欠落している可能性があります. クラウドプラットフォームが設​​定変更を記録する場合, その場合、ユーティリティには、誰がパラメータを変更できるか、およびそれらの変更がどのように監査されるかについてのルールが必要です.

導入前に共有の苦情ワークフローを定義することを好みます. 例えば, 「高額な請求書」” 苦情は消費曲線の見直しのきっかけとなるべきである, アラームのレビュー, メーターデータチェック, 請求先アカウントの確認, 必要に応じて現場検査も行います. 「読まないでください」” 苦情はメーターを交換する前に信号ログのレビューをトリガーする必要があります. これにより、不必要な交換が回避され、電力会社が問題が計測にあるのかどうかを特定するのに役立ちます。, コミュニケーション, プラットフォーム, または顧客データ.

ケーススタディ: 飛躍を遂げた都市?

都市はスマートメーターを購入したからといって飛躍するわけではない. データの移動方法とデータの使用者が変わるため、改善されます。.

手動検針からスマートシティメーターへの移行に成功する公益事業は、通常、パイロットから始まります。, 通信を確認する, 苦情を分類する, 請求を接続する, 完全な展開の前に、部門を越えた対応ルールを構築します.

成功したプロジェクトに見られるもの

これらを機密の顧客名ではなくフィールド パターンとして説明します。. 最初のパターンはパイロットファーストユーティリティです. このユーティリティはインストールされません 100,000 すぐにメートル. 異なる建物がある複数のゾーンを選択します, 水圧, 顧客のタイプ, および信号状態. チームはメーターの読み取り値をテストします, 信号, デバイスログ, アップロード期間, 請求インポート, および顧客の苦情処理. これは、1 つの結果がどこにでも当てはまると仮定するよりも信頼性が高くなります。.

2 番目のパターンは、データ透過性ユーティリティです。. このユーティリティによりエンジニアリングが可能になります, それ, 請求する, と顧客サービスが同じメーターのステータスを確認できる. 顧客から苦情があったとき, チームは読書履歴をチェックします, アラームステータス, オンラインログ, および請求記録. NB-IoTシステムマニュアルでは、機器のログ確認やクラウドに記録された設定変更などの操作をサポートしています。.

3 番目のパターンは、NRW に焦点を当てた公益事業です。. メーターが無収水地域をなくすことは期待していない. スマートメーターを活用して地区分析をサポート, 夜の流れのチェック, 低流量捕捉, 漏洩警報器, より迅速な現場応答. 漏水検出機能を備えたスマート超音波メーター, 乾いたパイプの検出, 双方向の流れ, IoT 通信は、このワークフローに有用な入力を提供できます。.

4 番目のパターンはライフサイクルを考慮したユーティリティです. 設計変更を追跡します, ファームウェアのバージョン, バッテリーの状態, アラームカテゴリ, と苦情曲線. これは、電力会社がいつ仕様を調整するかを決定するのに役立ちます. 設計またはプロセスの改善後に特定の種類の苦情が減少した場合, 電力会社は今後の入札でもその要件を維持する.

これらの電力会社は「さらなるテクノロジー」を購入しているわけではありません。” それ自体のために. 彼らはデータを中心とした運用モデルを変えています.

建築: IoT, クラウドおよび顧客ポータル?

アーキテクチャのないスマートメーターは単なる電子メーターです. システムはデータを現場から意思決定まで安全に移動する必要があります.

スマート シティのメーター アーキテクチャにはメーター ハードウェアが含まれます, 通信モジュール, ネットワークまたはゲートウェイ, ヘッドエンドシステム, クラウドプラットフォーム, 課金インターフェース, カスタマーポータル, アラームルール, およびフィールドサービスのワークフロー.

システムをマッピングする方法

メーターリストを承認する前にアーキテクチャを描きます. メーターは最初のレイヤーのみです. 測定体を含む場合があります, 電子モジュール, バッテリー, 画面, メモリ, アラーム, 必要に応じてバルブ, および通信モジュール. 参考にした超音波スマートメーターは、無線M-BusやNB-IoTなどの通信技術をサポート. それは選択肢を与えます, ただし、プロジェクトは現地の報道範囲に適したオプションを選択する必要があります, 料金, そしてプラットフォームのニーズ.

NB-IoT用, メーターは通常、オペレーターの対応範囲によって異なります, SIM または通信のセットアップ, デバイスの登録, アップロード期間, およびクラウドプラットフォーム処理. YOUNIO マニュアルには NB-IoT 信号のテストについて説明されています, デバイスのオンライン ログを確認する, 初期値の設定, モバイル CRM アプリを通じてアップロード期間を設定する. これらの手順は、スマート メーターには現場での試運転が必要であることを示しています, 工場出荷だけでなく.

LoRa または LoRaWAN システムの場合, ゲートウェイの配置を確認します, 電源, バックホール, 障害物, 地下室, とプラットフォーム接続. M-BusまたはRS485の場合, ケーブル設計をチェックします, コンセントレータの電力, 住所登録, およびメンテナンスアクセス. すべての都市に 1 つの通信方法が最適であるとは言いません.

顧客ポータルは透明性を向上させることができます, しかし、苦情のパターンも変化します. 顧客が日次または時間ごとのデータを確認する場合, 彼らはより詳細な質問をします. ユーティリティに適切な説明があり、明確なアラーム ルールがある場合、これは肯定的です。. ポータルに請求では説明できないデータが表示される場合は危険です.

スマートシティプロジェクトを開始する公益事業のための実践的なロードマップ?

スマートシティプロジェクトは巨額の発注書から始めるべきではありません. 境界線から始めるべきだ, パイロット, と運用ルール.

電力会社は目標を定義することから始める必要があります, メーターパラメータ, 通信方法, パイロットゾーン, プラットフォームの統合, 課金ルール, 苦情のカテゴリ, フィールドレスポンス, および調達書類. 完全な展開は検証済みのパイロット結果に従う必要があります.

私のステップバイステッププロジェクトメソッド

問題文から始めます. ユーティリティは推定測定値を減らそうとしていますか, 無収水削減を支援する, 顧客の透明性を向上させる, 苦情処理時間を短縮する, または請求を最新化する? 答えはメーターのタイプに影響します, 通信方法, データ周波数, プラットフォーム設計, とフィールドワークフロー.

次に、メータリング境界を定義します. 入札ではメーターサイズを指定する必要があります, Q3, R値, Q1, 開始流量, 設置位置, 温度クラス, 圧力条件, 保護レベル, バッテリー寿命, 通信方法, 報告サイクル, アラーム機能, プラットフォームインターフェース, そしてテスト書類. ISO 4064-2 ISOに接続されています 4064-1 計量および技術的な水道メーター要件に関する OIML R49-1. また、水道メーター全体のテストと、該当する場合には測定トランスデューサーと計算機の個別のテストも対象となります。.

次, 私はパイロットを経営しています. パイロットにはさまざまな建物を含める必要があります, パイプ材, 部屋, 圧力ゾーン, および信号状態. インストールを確認します, 定義された条件下での読み取り精度, 信号強度, デバイスログ, アップロード期間, 請求インポート, カスタマーポータルの表示, およびアラーム応答. NB-IoTマニュアルの信号テスト, デバイスログ, アップロード期間の設定手順は、フィールドで何を確認する必要があるかを思い出させるのに役立ちます。.

成功の意味も定義します. スマートシティ水道メータープロジェクトの成功は、読み取り率が高いだけではありません. 回避可能な手動訪問が減るはずです, 苦情診断を迅速化する, 請求データの品質を向上させる, 無収水分析をサポート, 部門間で共有されるデータビューを作成します.

最後のステップは調達フィードバックです. パイロットが地下室で弱い信号を示した場合, 通信プランを変更する. お客様が漏水警報器について質問がある場合, ポータルの説明を改善する. 請求時にアカウントの不一致が見つかった場合, 展開前に顧客データベースをクリーンアップする. メーターはスマートシティの仕事をサポートします, ただし、ユーティリティはそれを中心にオペレーティング システムを構築する必要があります.

結論

スマートメーターを指定する, コミュニケーション, プラットフォームのルール, 課金の統合, アラームのワークフロー, パイロット検証も一緒に. スマートシティの価値はデータ利用から生まれる, メートルだけではない.