カーテンウォールが「歯の抜けたジッパー」になる現象
当初、試運転チームはモーターを疑った。
プロジェクトはちょうど最終テストに入ったところでした。ビル管理システムは、平日の毎朝午前 8 時 30 分に、居住者が到着する前に東側ファサードのブラインドを下げて日射量をカットしました。コマンドは単純でした。数百個のモーター、同じプリセット位置、同じ時間。
ファサードが一緒に動くことはありませんでした。
最初の列はほぼ瞬時に反応しました。他の人も数秒後に続きました。何人かが立ち止まり、その後追いつきました。最後のセクションが動き始めたときには、すでに最初のセクションは停止していました。
建物の中からだとほとんど気づきませんでした。通りから見ると、カーテンウォールは歯が欠けたジッパーのように見えました。
アラームはありません。すべてのモーターは個別の機能テストに合格しました。ネットワークは一日中稼働し続けました。
では、なぜ個別に機能する何百ものモーターが 1 つの同期した動きを実行できないのでしょうか?
この疑問は、ほとんどのプロジェクト仕様が予想するよりも頻繁に表面化します。シェーディングの展開が建物ごとに 50 台または 100 台を超えるモーターに拡張されると、モーターが単独で実行できることと、システムが連携して実行できることとの間のギャップが、決定的なパフォーマンス指標になります。
誤解: モーターが本当の問題であることはほとんどありません
これは、私が複数のプロジェクトで再現したパターンです。最初にモーターが非難され、2 番目に交換され、3 番目に正当性が証明されます。
個々の機能テストは、すべてのユニットで問題なく返されます。トルク曲線は仕様の範囲内です。移動速度はデータシートと一致します。騒音レベルは問題ありません。しかし、200 個のモーターすべてがグループ コマンドを受信すると、ファサードは 1 つの面として所定の位置にスナップされるのではなく、カスケードします。
その時点で、モーターに問題がなかったことを知るには、モーターを交換するのが最も高価な方法です。
調査はほとんどの場合、BMS からゲートウェイ、ゲートウェイからネットワーク、ネットワークからモーター コントローラーといった通信チェーンに移ります。グループから 12 台のモーターを取り外し、再テストします。-遅延がほとんど変わらない場合、ボトルネックは上流にあります。
ミリ秒の伝播: わずかな遅延がどのように可視化されるか
計算は規模が大きいと容赦がありません。
1 台のモーターが 100 ミリ秒遅れて始動 - 誰もそれを見ません。しかし、同じ 100 ミリ秒を 15 階の 300 個のモーターに分散すると、遅延が伝播します。コマンドは、さまざまな時点でさまざまなネットワーク セグメントにヒットします。パケットレベルではほんの一瞬だったものが、ファサードを横切る波になります。
コミッショニングエンジニアはこれに「ジッパー効果」という非公式の名前を付けています。この名前が定着しているのは、目に見えるものを正確に説明しているためです。
理解すべきことは、ジッパーの影響は症状であり、診断ではないということです。コントローラーとモーターの間のどこかで、コマンドのタイミングが不一致になっていることがわかります。実際の仕事がどこにあるのかを見つけること。
開発者がこれを真剣に受け止める理由
自動化されたファサードが同期せずに動く高級オフィスタワーには、エンジニアリングを超えた問題があります。ファサードは建物の視覚的アイデンティティの一部です。機能している場合、自動化は目に見えません。そうでなければ、15 階のすべてのテナントが最初のコーヒーを飲む前に気づきます。
同じ苦情が 2 つのまったく異なる言い方で表現されているのを聞いたことがあります。エンジニアは「マルチキャスト グループで遅延が発生している」と述べています。施設管理者らは「ブラインドが連動しなくなった」と話す。同じ問題ですが、言語が異なります。どちらも同じルートに遡ります。
開発者にとって、コストは信頼性です。入居者にとって、それは建物のテクノロジーに対する信頼です。試運転チームにとって、幽霊を追いかけるのは請求できない時間です。
エネルギーコスト: 毎秒加算されます
日光センサーは、事前に設定された放射照度のしきい値でトリガーされます。ブラインドは直ちに展開する必要があります。しかし、グループ コマンドが - を伝播するのに 800 ミリ秒かかる場合、大規模なユニキャスト ネットワーク - では珍しいことではありません。これらのミリ秒ごとに、太陽放射が最大強度で内部ガラスに当たることになります。
1 秒の遅延だけでは、冷却負荷に意味のあるものは何も追加されません。しかし、その秒数に、1 日あたりのトリガーイベントの数、冷房期間の日数、窓ガラスの平方メートルを掛け合わせると、その数は取るに足らないものではなくなります。夏場の西向きのファサードでは、太陽の角度が変化し、雲が通過するにつれて、1 日に何十回も遮光の展開が開始される可能性があります。導入が遅れるたびに、HVAC システムが熱を除去する必要があります。
LBNL によるニューヨーク タイムズ ビルディングの入居後の調査では、昼光調光制御と統合された自動シェーディングにより、周囲ゾーン全体で年間照明エネルギー使用量が 56% 削減されたことが記録されています。{0}{1}この結果は、タイムリーな展開を想定したものでした。レイト ブラインドは、シェーディングへの投資を回収するための計算を台無しにします。
ネットワーク自体の内部にも二次コストが発生します。コマンドの到着が遅れた場合、コントローラーは再送信します。再送信は、次のコマンド サイクルで使用できる通信時間を消費します。再試行率が小さいのは通常のことです - すべてのワイヤレス プロトコルが原因です。ただし、複合を再試行します。 50 個のモーターで 2% の再試行が発生するグループは、200 個のモーターで 8% になる可能性があり、トラフィック曲線は直線的ではありません。再試行のたびに生成されるトラフィックが増加し、それによって衝突も発生し、さらに多くの再試行が発生します。時間の経過とともにレイテンシーを測定するエンジニアは、ネットワークがゆっくりと飽和しつつあることに気づくことがよくあります。
モーターを追加しても遅延は直線的に増加しない
プロジェクトの議論で根強い誤解の 1 つは、モーター数が 2 倍になると遅延も 2 倍になるというものです。
私は、同じプロトコル スタック上で 100 モーターのネットワークが 60 モーターのネットワークよりも優れたパフォーマンスを発揮することを確認しました。また、別の建物にある 120 モーターのネットワークが 6 か月ごとに再稼働する必要がある一方で、250 モーターのネットワークが何年も安定しているのを見てきました。
変数はデバイス数ではありません。変数は、グループ化ロジック、コントローラのスループット、プロトコルの選択、トポロジ、ステータス更新頻度、ポーリングが有効かどうかなど、通信システムがどのように構築されるかです。同じモーター、同じゲートウェイ、同じファームウェアを備えた 2 つの建物では、一方がすべてのブラインドを 1 つのゾーンにグループ化し、もう一方がファサードの方向によって分割されている場合、まったく異なる試運転結果が生成される可能性があります。
経験豊富なインテグレーターがハードウェアに触れる前にネットワーク構成をチェックするのはこのためです。
ログは別の物語を語った
ジッパーの影響が深刻だったあるプロジェクトでは、チームは 1 週間の自動化された朝のサイクルからコミュニケーション ログを抽出しました。
パターンはすぐに決まりました。モーター 001 は 12 ミリ秒以内にコマンドを受信しました。モーター 200 は 940 ミリ秒後に同じコマンドを受信しました。モーターの応答が遅くなりました - 異なるタイミングでコマンドを受信していました。
その発見は調査全体を変えました。モーターの反応の問題ではありませんでした。コマンドの配布の問題でした。コントローラーはユニキャストで一度に 1 つずつデバイスを反復処理し、すべてのフレームは前のフレームが確認されるのを待ってから、次のフレームが送信されました。
200 モーター × フレームあたり約 4.7 ミリ秒 (通信時間、CSMA/CA バックオフ、ACK ターンアラウンドを考慮)=940 ミリ秒。計算は、観測された遅延とほぼ正確に一致しました。
通信の選択: 1 つのコマンド vs. 200 の個別の呼び出し
プロジェクトの関係者がよく抱く例えは次のとおりです。建物内の 200 人に会議に出席するよう指示する必要があります。それぞれに個別に電話することも、PA システムを通じて 1 つのアナウンスを行うこともできます。同じ結果です。完了までの時間が根本的に異なります。
グループコミュニケーションも同様に機能します。ユニキャスト ネットワークは、モーターごとに個別のパケットを生成し、それらを順番に送信します。すべてのパケットは、前のパケットがクリアされるまで待機します。遅延はグループのサイズに算術的に影響します。
マルチキャストでは、論理グループ宛てに 1 つのフレームが生成されます。そのグループ内のすべてのモーターは、同じ送信ウィンドウ内で信号を受信します。遅延は、グループ サイズ - に関係なく、N フレーム時間ではなく 1 フレーム時間一定です。
Connectivity Standards Alliance によって維持されている Matter プロトコルは、グループ クラスターを介したグループ通信を指定します。グループ ID はファブリック ノードのセットにマッピングされ、単一のマルチキャスト送信がすべてのグループ メンバーに同時に到達します。これは独自の技術ではありません - プロトコル仕様に組み込まれています。 200 個のモーターを導入した場合の実質的な違いは、1 フレームと 200 フレームの違いです。
ネットワーク トポロジ: 物理層が結果を決定する理由
マルチキャストが実際に大規模に機能するかどうかを決定するもう 1 つの変数は、物理ネットワーク層です。
スター トポロジ - では、ほとんどの WiFi と多くの従来の Zigbee 展開 - が、すべてのモーターが中央のアクセス ポイントまたはコーディネーターに直接接続されます。 1 つのモーターがコンクリートせん断壁または HVAC ライザーの後ろに設置されている場合、そのリンク品質は他のモーターとは関係なく低下します。ネットワークは、その 1 つのパスのデータ レートを再送信または低下させることで補償します。これにより、グループ コマンドに使用できるはずの通信時間が消費されます。
スレッドは別のモデルを使用しています。メッシュを構築します。主電源が供給されているデバイスはルーターとして機能し、常に無線を維持できないバッテリー駆動のデバイス-にトラフィックを転送します。-モーター 47 への直接パスがブロックされている場合、フレームはモーター 32 とモーター 18 を経由します。メッシュは、リアルタイムで更新されるリンク品質メトリックに基づいてパスを継続的に再計算します。単一障害点はありません。問題が発生している 1 つのノードへの再送信を待機している停止したコマンド ストリームはありません。
Silicon Labs のメッシュ ネットワーキング ベンチマークは、WiFi と Zigbee ネットワークがアクティブな占有オフィスで実施され、独立した基準を提供します。中程度のペイロードを持つ大規模ネットワーク: スレッドの遅延は約 100 ミリ秒未満に抑えられ、Zigbee は約 130 ミリ秒まで広がり、Bluetooth メッシュは 250 ミリ秒を超えると低下しました。この差はネットワークのサイズとペイロードに応じて拡大しますが、これはまさに商用シェーディングにとって重要な条件です。
スレッドは周波数アジリティも実装しています。1 つの 2.4 GHz チャネルが飽和した場合、ネットワークは送信の間によりクリーンなチャネルにホップします。モーター アプリケーション層はホップを認識しません。再試行はありません。遅延のスパイクはありません。これは、IEEE 802.15.4 MAC 層で指定された標準のスレッド機能です。
これは、Thread が常に正しい答えであることを意味するものではありません。建物の構造、デバイスの密度、および試運転の品質が依然として重要です。スレッドが変更するのは、負荷 - の下でネットワークがどのように低下するかということです。大規模なシェーディングのデプロイメントの場合、問題となるのは適切な低下だけです。
ファサードが遅く見える場合、最後にチェックするのはモーターです
ある先輩試運転エンジニアが私にそう言いました。そして、現場でジッパーの効果を見るたびに、それは真実でした。
彼の言いたいことは、モーターは決して故障しないということではありませんでした。それは、モーターの故障は - モーターが始動するか始動しないかの二者択一であるということでした。通信の低下は継続的です - トラフィックが増加したり、建物が満杯になったり、他のシステムがオンラインになったりすると、さらに悪化します。工場の受け入れテストではモーターの欠陥を発見します。テスト環境には、200 台のデバイス、50 台の WiFi アクセス ポイント、2 階離れたブロードバンド EMI を発生させるエレベーター モーター ルームを備えた完成した建物のような RF の複雑さがないため、通信の問題が発生することはほとんどありません。
これが、同期の問題が試運転中ではなく占有中に表面化することが多い理由です。ネットワークだけが稼働しているときは、ネットワークは正常でした。
正しいエンドポイントを測定する
遅延に関する会話は、ほとんどの場合、「モーターの速度はどれくらいですか?」ということから始まります。正しい質問のように感じますが、調査対象がシグナル チェーンの間違った 1% に限定されてしまいます。
モーターはコマンドを受信してから 8 ミリ秒以内に応答します。コマンドが到着するまでに 900 ミリ秒かかった場合、モーターの応答時間を 8 ミリ秒から 6 ミリ秒に短縮しても何の意味もありません。
重要な測定値はエンドツーエンドです。つまり、コントローラーがグループ コマンドを発行してから各モーターが物理的な動作を開始するまでの間隔です。この数値は、コントローラー、ネットワーク スタック、無線機、モーターの MCU、パワー ステージ -、BMS 命令と機械出力の間にあるすべてのものをキャプチャします。
端から端まで追跡すると、状況が変わります。{0}}-同一のモーター応答時間を仕様とする 2 つのシステムでは、ネットワークによるコマンドの分散方法により、エンドツーエンドで 800 ミリ秒の差が生じる可能性があります。--。スペックシートの比較では決してわかりません。
平均遅延は気が散る
これは、エンジニアが陥っている罠です。エンジニアは平均レイテンシーの数値を比較し、質問に答えたと思っています。
2 つのシステムでは、どちらも平均 18 ミリ秒を報告しています。紙の上では同じです。導入時には、狭い帯域内で一貫した応答を提供します。もう 1 つは、トラフィックが多いときに 80 ミリ秒または 100 ミリ秒に急増することがあります -。ファサードが動いたときに人々が目にするのは、平均ではなくこれらのスパイクです。
目は平均値を認識しません。異常値を認識します。 300 個のモーターのグループ内の単一の 100 ミリ秒のスパイクによって、ファサードの一部に目に見えるためらいが生じます。それが建物の所有者が覚えていることです。このため、コミッショニング エンジニアは、平均値よりも 99 パーセンタイル -、あるいはさらに良いのは、観測された最大レイテンシ - に注意を払うのです。予測可能性は常にピークパフォーマンスを上回ります。
現実世界の測定-: 独自のプラットフォームで測定したもの
現在の制御プラットフォームをリリースする前に、当社のエンジニアリング チームは、応答時間がグループ サイズに応じてどのように変化するかを理解するために内部検証を実行しました。
セットアップ: Matter{0}over- ネットワーク上のチューブラー モーター、安定した屋内条件、増加するデバイス数にわたってグループ コマンドを繰り返す。目的は、印象的な最小値に達することではなく、- グループが成長しても遅延が予測可能であることを確認することでした。
100 個のモーターを使用した複数のテスト サイクルにわたって、ほとんどのユニットがグループ コマンドから 20 ミリ秒以内に動き始めました。最も遅い読み取り時間は約 22 ミリ秒でした。パケットの再送信は全体を通して 0.5% 未満にとどまりました。
|
モーター |
典型的な反応 |
|
20 |
～9ミリ秒 |
|
40 |
～11ミリ秒 |
|
60 |
～13ミリ秒 |
|
80 |
～16ミリ秒 |
|
100 |
< 20 ms |
この増加はスムーズでした。- 崖がなく、パフォーマンスが突然崩れるような点もありませんでした。それは絶対的な数字よりも重要です。負荷がかかると徐々に性能が低下するシステムは、どのような規模でも安心して導入できます。モーターが 40 個の場合は良好に動作し、80 個になると機能不全に陥るシステムでは、試運転中に大惨事が待っています。
これらは制御された環境番号です。-実際の建物には、鉄骨フレーム、Low{2}} ガラス、競合する WiFi ネットワークがあり、居住者がモバイル デバイスを持って歩き回っています。フィールドの結果は異なります。検証では、アーキテクチャ - がメッシュ上でマルチキャスト - を行うことが、数学的に予測されるとおりにスケールされることを確認しただけです。
機械的な側面: 完璧なコミュニケーションでも許容範囲を隠すことはできない
コミュニケーションに注目が集まるのは、グループ遅延が最も発生する場所だからです。しかし、完璧なコマンド配信があっても - すべてのモーターが同じ瞬間に同じフレームを受信すると - 同期が機械レベルで壊れる可能性があります。
ギアボックス アセンブリの公差、ベアリングのプリロードの変動、ブレーキ リリースのタイミング、出力シャフトの同心度 - これらはすべて、電気コマンドを受け取った後にモーターが静止状態から回転状態に移行する速度に影響します。個々の違いは数ミリ秒であり、目に見えません。 1 つのファサード上に数百個のモーターがあり、それらが積み重なると、目に見える千鳥状になります。
これが、製造の一貫性が通信パフォーマンスと別個の話ではない理由です。この 2 つが複合します。当社の製造プロセスでは、主要なトランスミッションコンポーネントのベアリングシートとギアプロファイルを±0.05 mmに抑えています。その許容誤差は、ファームウェア制御ループが依存する機械的再現性に直接影響します。
許容誤差が厳しいということは、エンコーダの位置フィードバックが実際にモーターが期待する場所に到達することを意味します。許容誤差が緩いということは、制御ループが常に - のオーバーシュート、プルバック、微小振動 - を修正していることを意味します。これによりエネルギーが消費され、静かなオフィスでは限界停止時のハンティング ノイズとして聞こえるようになります。通信精度と機械的精度は、同じ問題の表裏の関係にあります。
ゾーン設計は最初のワイヤーが引かれる前に行われます
同期の失敗のほとんどは、調達が始まる前にプロジェクトに組み込まれています。
最も一般的な間違いは、建築図面がフロアごとにグループ化されているためです。自然な感じですね。しかし、太陽は床の境界を無視します。東側のファサードには朝の負荷がかかります。西側のファサードには午後から負荷がかかります。太陽が建物の側面に当たるかどうかに関係なく、フロアのすべてのブラインドがすべてのコマンドを受信すると、機能的な理由もなくネットワーク トラフィックが増大します。
より単純なアプローチ: 最初にファサードの向きでグループ化し、次に各向き内のフロアごとに細分化します。東ゾーン。西ゾーン。北ゾーン。南ゾーン。各マルチキャスト グループには、常に一緒に移動するモーターのみが含まれています - 同じ日射量、同じコマンド ロジック。グループのトラフィックが減少します。キューの圧力が低下します。レイテンシーが低下します。
スケールのしきい値: ワイヤレスに有線パートナーが必要な場合
純粋なワイヤレスでは、有線の冗長性についての議論が必要になり始めるポイントがあり、私たちの経験では、そのポイントは 1 つの建物のネットワーク上に 500 個のモーターを超えるあたりです。
300 未満では、適切に設計されたスレッド メッシュが問題なくグループ制御を処理します。- 300 ～ 500 の間ではメッシュ密度に注意が必要です。障害物がある場合でもルーティング パスの多様性が維持できるように、15 ～ 20 のエンドポイントごとに少なくとも 1 台のルーター対応デバイスを計画してください。-。
500 を超えると、操作の複雑さが変化します。このような規模のファームウェアのアップデートは、注意しないとワイヤレス ネットワークを飽和させてしまいます。デバイスのコミッショニングにはさらに時間がかかります。デバイスのサブセットが境界ルータ - への接続を一時的に失うメッシュ パーティション イベント - が発生する統計的確率は、平均リンク品質が優れている場合でも、ノード数に応じて増加します。
そのしきい値では、ファームウェア配布およびフェイルオーバー用の並列パスとして RS-485 有線バックボーンを追加することは、無線の信頼性が低いことを認めることにはなりません。これは、500 台のモーターを備えた建物において、火災警報器の統合シーケンス中のパーティション イベントは、AHJ に説明する必要のないことを認めるものです。有線パスは保険です。
病院、空港、政府の建物では、モーターの数に関係なくハイブリッド アーキテクチャを指定する傾向があります。これは、これらの環境でのダウンタイムのコストにより、有線バックアップがプロジェクトの総予算の四捨五入誤差となるためです。 Construction Industry Institute は、システムの再稼動を含む再作業コスト - - が設置プロジェクト コストの平均 12.4% であることを文書化しました。冗長通信バックボーンの費用は、占有後にネットワークの潜在的な問題が表面化した後、500 個のモーターを再稼働させる費用の数分の一で済みます。-
承認する前に重要な 5 つの質問
十分な試運転サイクルを経ても、同じ質問が繰り返し表示されます。決してトルクや回転数に関するものではありません。
「すべてのモーターは個別のテストに合格しました。なぜグループが遅く見えるのですか?」
あなたはモーターの問題ではなく、コマンド分配の問題を見ているのです。コントローラーがコマンドを一度に 1 つずつユニキャストしているかどうかを確認します。ステータスの更新頻度を確認してください。すべてのモーターが単一の特大グループに属しているかどうかを確認します。ほとんどの場合、マルチキャスト グループ アドレッシングに切り替えると、単一のモーターに触れることなく、目に見える遅延が解決されます。
「1 つのモーターが故障したら、グループは崩壊してしまうのでしょうか?」
そうすべきではありません。各モーターは同じマルチキャスト フレームに独立して応答します。単一の停止したモーター - MCU の故障、コンデンサーのショート、機械的故障 - は自動的に停止したままになります。残りの 199 は通常どおりコマンドを実行します。モーターがネットワークから完全に切断された場合、管理ダッシュボードはモーターに応答なしとしてフラグを立て、接続が回復すると自動的にグループに再参加します。-この分離は、あらゆる実稼働グレード管理プラットフォームにとって必須の要件です。{9}}
「鉄-と-ガラスの塔内でワイヤレスは実際に信頼できますか?」
はい、プロトコルとトポロジがその環境用に選択されている場合は可能です。 Thread のメッシュ アーキテクチャは、障害物を通過する 1 つのアクセス ポイントに依存するのではなく、障害物を回避してルーティングします。周波数アジリティは、アプリケーション層が関与することなく、飽和したチャネルから飛び降ります。前に引用した Silicon Labs ベンチマークは、WiFi と Zigbee が通信時間で競合するアクティブなオフィスで実行されました -、シールドされたラボではありません -、Thread はすべてのテスト条件で最も低いレイテンシーを維持しました。
とはいえ、大規模なインストール前の RF 調査の必要性を排除するプロトコルはありません。{0}金属化されたLow{2}}窓コーティングが施された建物は、透明なガラスを使用した建物とは異なる動作をします。スタッド構造の乾式壁--は、流し込みコンクリートや鉄筋とは動作が異なります。メッシュはスターよりも障害物にうまく対処します。物理学をオプションにするわけではありません。
「レイテンシが低いほど常に良いのでしょうか?」
それも一貫している場合に限ります。毎回 18 ミリ秒を配信するシステムは、目に見えて均一なファサードを生成します。理想的な条件下では 10 ミリ秒に達するシステムでも、トラフィックが増加すると 80 ミリ秒に急増するシステムは、緊張したように見えるファサードを生成します。建物の所有者にとって、予測可能性は居住者が気づくことです。スペックシートの最低値は、セールスエンジニアが入札会議で話す内容です。それらが同じものであることはほとんどありません。
次のプロジェクトが始まる前に
大規模なシェーディング プロジェクト全体で繰り返される教訓は単純です。同期の問題がモーターから始まることはほとんどありません。
ジッパーの効果が通りから見えるようになるまでに、根本原因は数週間または数か月にわたって通信システム内に静かに蓄積されています。経験豊富な試運転チームはこのことを知っています。交換用ハードウェアを注文する前に、ネットワーク構成をチェックします。
重要な 5 つの質問:
コマンドはマルチキャストで配信されますか? ユニキャストで配信されますか?
各通信パスを共有するデバイスは何台ですか?
不要なステータスポーリングはどの程度有効になっていますか?
デバイス数が増加しても遅延は予測可能ですか?
単一の通信障害を切り分けることはできますか?
これら 5 つの質問に正しく答えることは、データシート上のどのモーター仕様よりもファサードのパフォーマンスに大きな影響を与えます。
応答時間は実際にはモーターの指標ではありません。これはシステムメトリックです。商業ビルが日よけ、照明、HVAC 間の緊密な統合を推進する中、数百のエンドポイントにわたって時限コマンドを実行できるかどうかが、自動化への投資に価値があるかどうかを決定するパフォーマンス数値になりつつあります。モーターがボトルネックになることはほとんどありません。それらの間のアーキテクチャはほとんど常にそうです。