デゞタル倉電所 LAN 内のフロヌを管理するにはどうすればよいですか?

デゞタル倉電所ぱネルギヌ分野のトレンドです。 この話題に詳しい方は、倧量のデヌタがマルチキャスト ストリヌムの圢匏で送信されるずいうこずを聞いたこずがあるでしょう。 しかし、これらのマルチキャスト ストリヌムを管理する方法を知っおいたすか? どのようなフロヌ管理ツヌルが䜿甚されおいたすか? 芏制文曞は䜕をアドバむスしおいたすか?

このトピックを理解するこずに興味がある人は誰でも猫にようこそ!

デヌタはネットワヌク䞊でどのように送信されたすか?たた、なぜマルチキャスト ストリヌムを管理するのでしょうか?

デゞタル サブステヌションず LAN 構築の埮劙な点に盎接進む前に、デヌタ転送の皮類ずマルチキャスト ストリヌムを扱うためのデヌタ転送プロトコルに関する簡単な教育プログラムを提䟛したす。 教育プログラムをスポむラヌの䞋に隠したした。

デヌタ転送の皮類
LAN 䞊のトラフィックの皮類

デヌタ転送には XNUMX ぀のタむプがありたす。

  • ブロヌドキャスト – ブロヌドキャスト。
  • ナニキャスト – XNUMX ぀のデバむス間のメッセヌゞング。
  • マルチキャスト – デバむスの特定のグルヌプにメッセヌゞを送信したす。
  • 䞍明なナニキャスト - XNUMX 台のデバむスを芋぀けるこずを目的ずしたブロヌドキャスト。

カヌドを混乱させないように、マルチキャストに進む前に、他の XNUMX 皮類のデヌタ送信に぀いお簡単に説明したす。

たず、LAN 内では、デバむス間のアドレス指定は MAC アドレスに基づいお行われるこずを思い出しおください。 送信されるすべおのメッセヌゞには、SRC MAC フィヌルドず DST MAC フィヌルドがありたす。

SRC MAC – 送信元 MAC – 送信者の MAC アドレス。

DST MAC – 宛先 MAC – 受信者の MAC アドレス。

スむッチは、これらのフィヌルドに基づいおメッセヌゞを送信したす。 DST MAC を怜玢し、MAC アドレス テヌブルで芋぀けお、テヌブルにリストされおいるポヌトにメッセヌゞを送信したす。 SRC MACも芋おいたす。 テヌブルにそのような MAC アドレスがない堎合は、新しい「MAC アドレス - ポヌト」のペアが远加されたす。

次に、デヌタ転送の皮類に぀いお詳しく説明したす。

ナニキャスト

ナニキャストは、XNUMX ぀のデバむス間でのメッセヌゞのアドレス送信です。 基本的に、これはポむントツヌポむントのデヌタ転送です。 ぀たり、XNUMX ぀のデバむスは垞にナニキャストを䜿甚しお盞互に通信したす。

デゞタル倉電所 LAN 内のフロヌを管理するにはどうすればよいですか?
ナニキャストトラフィック送信

攟送

ブロヌドキャストはブロヌドキャストメッセヌゞです。 それらの。 ブロヌドキャスト。XNUMX ぀のデバむスがネットワヌク䞊の他のすべおのデバむスにメッセヌゞを送信するこず。

ブロヌドキャスト メッセヌゞを送信するには、送信者は DST MAC アドレス FF:FF:FF:FF:FF:FF を指定したす。

デゞタル倉電所 LAN 内のフロヌを管理するにはどうすればよいですか?
ブロヌドキャストトラフィック送信

䞍明なナニキャスト

Unknown Unicast は、䞀芋したずころ、Broadcast ず非垞によく䌌おいたす。 ただし、䞡者には違いがありたす。メッセヌゞはすべおのネットワヌク参加者に送信されたすが、宛先は XNUMX 台のデバむスのみです。 これは、ショッピングセンタヌで車を再駐車するように求めるメッセヌゞのようなものです。 このメッセヌゞは党員に聞こえたすが、応答するのは XNUMX 人だけです。

スむッチがフレヌムを受信し、そのフレヌムからの宛先 MAC が MAC アドレス テヌブルで芋぀からない堎合、このメッセヌゞを受信元のポヌトを陀くすべおのポヌトにブロヌドキャストするだけです。 このようなメヌルに応答できるのは XNUMX 台のデバむスだけです。

デゞタル倉電所 LAN 内のフロヌを管理するにはどうすればよいですか?
䞍明なナニキャストトラフィックの送信

マルチキャスト

マルチキャストずは、このデヌタの受信を「垌望する」デバむスのグルヌプにメッセヌゞを送信するこずです。 りェビナヌずよく䌌おいたす。 これはむンタヌネット党䜓にブロヌドキャストされたすが、このトピックに興味がある人だけが接続したす。

このデヌタ転送モデルは「パブリッシャヌ - サブスクラむバヌ」ず呌ばれたす。 デヌタを送信するパブリッシャヌが XNUMX ぀あり、このデヌタを受信したいサブスクラむバヌがそれにサブスクラむブしたす。

マルチキャストブロヌドキャストでは、実際のデバむスからメッセヌゞが送信されたす。 フレヌム内の送信元 MAC は送信者の MAC です。 ただし、宛先 MAC は仮想アドレスです。

デバむスは、グルヌプからデヌタを受信するためにグルヌプに接続する必芁がありたす。 スむッチはデバむス間の情報フロヌをリダむレクトしたす。デヌタがどのポヌトから送信されたかを蚘憶し、このデヌタがどのポヌトに送信されるべきかを認識したす。

デゞタル倉電所 LAN 内のフロヌを管理するにはどうすればよいですか?
マルチキャストトラフィックの送信

重芁な点は、IP アドレスは仮想グルヌプずしおよく䜿甚されるずいうこずですが、 この蚘事ぱネルギヌに関するものなので、MAC アドレスに぀いお説明したす。 デゞタル倉電所に䜿甚されるプロトコルの IEC 61850 ファミリでは、グルヌプぞの分割は MAC アドレスに基づいおいたす。

MAC アドレスに関する簡単な教育プログラム

MAC アドレスは、デバむスを䞀意に識別する 48 ビットの倀です。 6 オクテットに分割されたす。 最初の 4 オクテットには補造元情報が含たれたす。 オクテット 5、6、および XNUMX は補造元によっお割り圓おられ、デバむス番号です。

デゞタル倉電所 LAN 内のフロヌを管理するにはどうすればよいですか?

デゞタル倉電所 LAN 内のフロヌを管理するにはどうすればよいですか?
MACアドレス構造

最初のオクテットの 0 番目のビットは、メッセヌゞがナニキャストであるかマルチキャストであるかを決定したす。 XNUMX 番目のビットが XNUMX の堎合、この MAC アドレスは実際の物理デバむスのアドレスです。

1 番目のビットが XNUMX の堎合、この MAC アドレスは仮想アドレスです。 ぀たり、この MAC アドレスは実際の物理デバむスに属さず、仮想グルヌプに属したす。

仮想チヌムは攟送塔にたずえるこずができたす。 ラゞオ䌚瀟はこの塔に音楜を攟送しおおり、それを聎きたい人は受信機を垌望の呚波数に合わせたす。

たた、たずえば、IP ビデオ カメラは仮想グルヌプにデヌタを送信し、このデヌタを受信したいデバむスはこのグルヌプに接続したす。

デゞタル倉電所 LAN 内のフロヌを管理するにはどうすればよいですか?
MAC アドレスの最初のオクテットの XNUMX 番目のビット

スむッチでマルチキャスト サポヌトが有効になっおいない堎合、スむッチはマルチキャスト ストリヌムをブロヌドキャストずしお認識したす。 したがっお、そのようなフロヌが倚数ある堎合、ネットワヌクはすぐに「ゞャンク」トラフィックで詰たりたす。

マルチキャストの本質ずは䜕でしょうか?

マルチキャストの䞻な考え方は、デバむスからトラフィックのコピヌが XNUMX ぀だけ送信されるずいうこずです。 スむッチは、サブスクラむバがどのポヌト䞊にあるかを刀断し、送信者からサブスクラむバにデヌタを送信したす。 したがっお、マルチキャストを䜿甚するず、ネットワヌク経由で送信されるデヌタを倧幅に削枛できたす。

これは実際の LAN ではどのように機胜するのでしょうか?

最初のオクテットの 1 番目のビットが XNUMX である MAC アドレスにトラフィックのコピヌを XNUMX ぀送信するだけでは十分ではないこずは明らかです。加入者はこのグルヌプに接続できる必芁がありたす。 たた、スむッチは、デヌタがどのポヌトから来お、どのポヌトにデヌタを送信する必芁があるかを理解する必芁がありたす。 そうしお初めお、マルチキャストによっおネットワヌクの最適化ずフロヌの管理が可胜になりたす。

この機胜を実装するには、マルチキャスト プロトコルがありたす。 最も䞀般的な

  • IGMP。
  • ピム。

この蚘事では、これらのプロトコルの䞀般的な動䜜原理に぀いお少し話したす。

IGMP

IGMP 察応スむッチは、マルチキャスト ストリヌムがどのポヌトに到着するかを蚘憶したす。 加入者はグルヌプに参加するには IMGP Join メッセヌゞを送信する必芁がありたす。 スむッチは、IGMP Join の送信元ポヌトをダりンストリヌム むンタヌフェむスのリストに远加し、そこでマルチキャスト ストリヌムの送信を開始したす。 スむッチは、ダりンストリヌム ポヌトに IGMP ク゚リ メッセヌゞを継続的に送信しお、デヌタの送信を継続する必芁があるかどうかを確認したす。 IGMP Leave メッセヌゞがポヌトから受信された堎合、たたは IGMP Query メッセヌゞに察する応答がなかった堎合、そのポヌトぞのブロヌドキャストは停止されたす。

PIM

PIM プロトコルには XNUMX ぀の実装がありたす。

  • ピムDM。
  • ピム・SM

PIM DM プロトコルは IGMP の逆に動䜜したす。 スむッチは最初に、マルチキャスト ストリヌムをブロヌドキャストずしお、受信元のポヌトを陀くすべおのポヌトに送信したす。 次に、䞍芁であるずいうメッセヌゞが送信されたポヌト䞊のフロヌを無効にしたす。

PIM SM は IGMP に近い状態で動䜜したす。

マルチキャスト操䜜の䞀般原理を非垞に倧たかに芁玄するず、パブリッシャは特定の MAC グルヌプにマルチキャスト ストリヌムを送信し、サブスクラむバはこのグルヌプぞの接続芁求を送信し、スむッチはこれらのストリヌムを管理したす。

マルチキャストに぀いお衚面的に説明したのはなぜでしょうか? これを理解するために、デゞタル倉電所 LAN の詳现に぀いお説明したしょう。

デゞタル倉電所ずは䜕ですか?なぜそこでマルチキャストが必芁なのでしょうか?

デゞタル倉電所 LAN に぀いお話す前に、デゞタル倉電所ずは䜕かを理解する必芁がありたす。 質問を答えお

  • デヌタ転送には誰が関䞎したすか?
  • どのようなデヌタが LAN に転送されたすか?
  • 兞型的な LAN アヌキテクチャずは䜕ですか?

その埌、マルチキャストに぀いお説明したす...

デゞタル倉電所ずは䜕ですか?

デゞタル倉電所は、すべおのシステムが非垞に高床な自動化を備えおいる倉電所です。 このような倉電所のすべおの二次および䞀次機噚は、デゞタル デヌタ䌝送に重点を眮いおいたす。 デヌタ亀換は、IEC 61850 暙準に蚘茉されおいる䌝送プロトコルに埓っお構築されたす。

したがっお、すべおのデヌタはここでデゞタル送信されたす。

  • 枬定。
  • 蚺断情報。
  • 制埡コマンド。

この傟向はロシアの゚ネルギヌ郚門で倧きく発展し、珟圚どこでも実斜されおいたす。 2019 幎ず 2020 幎に、開発のすべおの段階でデゞタルサブステヌションの䜜成を芏制する倚くの芏制文曞が登堎したした。 たずえば、STO 34.01-21-004-2019 PJSC "Rosseti" では、䞭倮サヌビス ステヌションに぀いお次の定矩ず基準を定矩しおいたす。

定矩

デゞタル倉電所は、デゞタル情報ず単䞀タむム モヌドで盞互䜜甚する制埡システムを備えた自動倉電所で、垞勀芁員の存圚なしで動䜜したす。

基準

  • 勀務および保守の操䜜担圓者が垞駐するこずなく、通垞の操䜜に必芁な機噚およびシステムのパラメヌタおよび操䜜モヌドを遠隔から芳察できるこず。
  • 勀務および保守の操䜜員が垞駐するこずなく、倉電所を操䜜するための機噚およびシステムの遠隔制埡を提䟛する。
  • 機噚およびシステムの動䜜モヌドに察するむンテリゞェント制埡システムを䜿甚した、機噚およびシステム管理の高床な自動化。
  • 単䞀時間モヌドでのすべおの技術プロセスの遠隔制埡。
  • すべおの技術システム間の単䞀フォヌマットでのデゞタルデヌタ亀換。
  • 電力ネットワヌクおよび䌁業管理システムぞの統合、ならびに関連するむンフラストラクチャ組織関連斜蚭ずのデゞタル察話の確保。
  • 技術プロセスのデゞタル化における機胜セキュリティず情報セキュリティ。
  • 必芁な量のデゞタルデヌタ、制埡されたパラメヌタ、信号を送信しお、䞻芁な技術機噚ずシステムの状態をオンラむンで継続的に監芖したす。

デヌタ転送には誰が関䞎したすか?

デゞタル倉電所には次のシステムが含たれたす。

  • リレヌ保護システム。 リレヌ保護は実質的にデゞタル倉電所の「心臓郚」です。 リレヌ保護端子は、枬定システムから電流倀ず電圧倀を取埗したす。 このデヌタに基づいお、端末は内郚保護ロゞックを蚈算したす。 端末は盞互に通信し、䜜動した保護機胜やスむッチング装眮の䜍眮などの情報を送信したす。 端末は、発生したむベントに関する情報も ICS サヌバヌに送信したす。 合蚈するず、いく぀かのタむプの通信を区別できたす。
    ▞暪の぀ながり – 端末間の通信。
    ▞垂盎接続 – 自動プロセス制埡システムサヌバヌずの通信。
    ▞枬定倀 – 枬定装眮ずの通信。

  • 商甚電力蚈量システム。保管蚈量システムは枬定デバむスずのみ通信したす。

  • 配車制埡システム。郚分デヌタは、自動プロセス制埡システムのサヌバヌず商業䌚蚈サヌバヌからコントロヌル センタヌに送信する必芁がありたす。

これは、デゞタル倉電所の䞀郚ずしおデヌタを亀換するシステムの非垞に単玔化されたリストです。 このトピックに぀いおさらに詳しく知りたい堎合は、コメントに曞き蟌んでください。
こちらに぀いおはたた別途ご玹介させおいただきたす😉

どのようなデヌタが LAN に転送されたすか?

説明したシステムを盞互に結合し、枬定倀の転送だけでなく氎平および垂盎通信を組織するために、バスが組織されたす。 珟時点では、各バスは産業甚むヌサネット スむッチ䞊の個別の LAN にすぎないこずに同意したしょう。

デゞタル倉電所 LAN 内のフロヌを管理するにはどうすればよいですか?
IEC 61850に準拠した電力蚭備のブロック図

ブロック図はタむダを瀺しおいたす。

  • 監芖/制埡。
  • リレヌ保護信号の送信。
  • 瞬時電圧ず電流の䌝送。

保護リレヌ端子は氎平通信ず垂盎通信の䞡方に参加し、枬定も䜿甚するため、すべおのバスに接続されたす。

「リレヌ保護信号の送信」バスを通じお、端末間で情報を送信したす。 それらの。 ここでは氎平接続が実装されおいたす。

枬定倀の送信は、「電圧ず電流の瞬時倀の送信」バスを通じお実行されたす。 枬定デバむス (倉流噚、倉圧噚、リレヌ保護端子など) はこのバスに接続されおいたす。

たた、ASKUEサヌバヌは「電圧・電流の瞬時倀の送信」バスに接続されおおり、課金のための蚈枬も行っおいたす。

そしお、「監芖/制埡」バスは垂盎方向の通信を行いたす。 それらの。 これを通じお、端末はさたざたなむベントを ICS サヌバヌに送信し、サヌバヌは制埡コマンドも端末に送信したす。

自動プロセス制埡システムのサヌバヌからコントロヌルセンタヌにデヌタが送信されたす。

兞型的な LAN アヌキテクチャずは䜕ですか?

抜象的でかなり埓来的な構造図から、より日垞的で珟実的なものに移りたしょう。

以䞋の図は、デゞタル倉電所のかなり暙準的な LAN アヌキテクチャを瀺しおいたす。

デゞタル倉電所 LAN 内のフロヌを管理するにはどうすればよいですか?
デゞタル倉電所のアヌキテクチャ

6 kV たたは 35 kV の倉電所では、ネットワヌクはより単玔になりたすが、110 kV、220 kV 以䞊の倉電所や発電所の LAN に぀いお蚀えば、アヌキテクチャは図に瀺したものに察応したす。

アヌキテクチャは XNUMX ぀のレベルに分かれおいたす。

  • 駅/倉電所レベル。
  • 参加レベル。
  • プロセスレベル。

駅/倉電所レベル ワヌクステヌションずサヌバヌが含たれたす。

参加レベル すべおの技術機噚が含たれたす。

プロセスレベル 枬定機噚が含たれたす。

レベルを結合するための XNUMX ぀のバスもありたす。

  • 駅/倉電所バス。
  • プロセスバス。

駅倉電所バスは、「監芖・制埡」バスず「リレヌ保護信号䌝送」バスの機胜を兌ね備えおいたす。 そしお、プロセスバスは「電圧・電流瞬時倀の送信」バスの機胜を実行したす。

デゞタル倉電所におけるマルチキャスト䌝送の特城

マルチキャストを䜿甚しお送信されるデヌタは䜕ですか?

デゞタルサブステヌション内の氎平通信ず枬定倀の送信は、パブリッシャヌ/サブスクラむバヌ アヌキテクチャを䜿甚しお実行されたす。 それらの。 䞭継保護端末はマルチキャスト ストリヌムを䜿甚しお端末間でメッセヌゞを亀換し、枬定倀もマルチキャストを䜿甚しお送信されたす。

゚ネルギヌ分野におけるデゞタル倉電所以前は、端末間のポむントツヌポむント通信を䜿甚した氎平通信が実装されおいたした。 銅ケヌブルたたは光ケヌブルがむンタヌフェむスずしお䜿甚されたした。 デヌタは独自のプロトコルを䜿甚しお送信されたした。

この接続には非垞に高い芁求が課されたした。 これらのチャネルは、保護のアクティブ化、スむッチングデバむスの䜍眮などの信号を送信したした。 端末を動䜜的にブロックするためのアルゎリズムは、この情報に䟝存しおいたした。

デヌタの送信が遅い、たたは保蚌されおいない堎合、端末の XNUMX ぀が珟圚の状況に関する最新情報を受信できない可胜性が高く、次のような堎合にスむッチング デバむスをオフたたはオンにする信号を送信する可胜性がありたす。 、それにいく぀かの䜜業が行われたす。 たたは、ブレヌカヌの故障が間に合わず、短絡が他の電気回路に広がりたす。 これらすべおは倚額の経枈的損倱ず人呜ぞの脅嚁を䌎いたす。

したがっお、デヌタを送信する必芁がありたした。

  • 信頌性のある。
  • 保蚌されおいたす。
  • すばやく。

珟圚では、ポむントツヌポむント通信の代わりに、駅/倉電所バスが䜿甚されおいたす。 LAN。 デヌタは、IEC 61850 暙準 (より正確には IEC 61850-8-1) で蚘述されおいる GOOSE プロトコルを䜿甚しお送信されたす。

GOOSE は General Object Oriented Substation Event の略ですが、このデコヌドにはあたり関連性がなく、セマンティックな負荷もかかりたせん。

このプロトコルの䞀郚ずしお、䞭継保護端末は盞互に GOOSE メッセヌゞを亀換したす。

ポむントツヌポむント通信から LAN ぞの移行によっおアプロヌチは倉わりたせんでした。 デヌタは䟝然ずしお確実、安党、迅速に送信される必芁がありたす。 したがっお、GOOSE メッセヌゞは、やや特殊なデヌタ送信メカニズムを䜿甚したす。 圌に぀いおは埌で詳しく説明したす。

すでに説明したように、枬定倀はマルチキャスト ストリヌムを䜿甚しお送信されたす。 DSP 甚語では、これらのストリヌムは SV ストリヌム (サンプル倀) ず呌ばれたす。

SV ストリヌムは、特定のデヌタセットを含むメッセヌゞであり、䞀定の呚期で連続的に送信されたす。 各メッセヌゞには、特定の時点での枬定倀が含たれおいたす。 枬定は特定の呚波数、぀たりサンプリング呚波数で行われたす。

サンプリング呚波数は、時間連続信号をサンプリングするずきのサンプリング呚波数です。

デゞタル倉電所 LAN 内のフロヌを管理するにはどうすればよいですか?
サンプリングレヌト 80 秒あたり XNUMX サンプル

SV ストリヌムの構成は IEC61850-9-2 LE に蚘茉されおいたす。

SV ストリヌムはプロセス バスを介しお送信されたす。

プロセスバスは、枬定デバむスず接続レベルのデバむス間のデヌタ亀換を提䟛する通信ネットワヌクです。 デヌタ (瞬時電流倀ず電圧倀) を亀換するためのルヌルは、IEC 61850-9-2 芏栌に蚘茉されおいたす (珟圚は IEC 61850-9-2 LE プロファむルが䜿甚されおいたす)。

SV ストリヌムは、GOOSE メッセヌゞず同様、迅速に送信する必芁がありたす。 枬定倀の送信が遅い堎合、保護を䜜動させるのに必芁な電流たたは電圧を端末が時間内に受信できない可胜性があり、短絡が電気ネットワヌクの倧郚分に広がり、倧きな損害を匕き起こす可胜性がありたす。

なぜマルチキャストが必芁なのでしょうか?

前述したように、氎平通信のデヌタ送信芁件をカバヌするために、GOOSE はやや特殊な圢で送信されたす。

たず、デヌタ リンク レベルで送信され、独自の Ethertype – 0x88b8 を持ちたす。 これにより、高いデヌタ転送速床が保蚌されたす。

ここで、保蚌ず信頌性の芁件を解決する必芁がありたす。

もちろん、確実にメッセヌゞが配信されたかどうかを理解する必芁がありたすが、たずえば TCP で行われるように、受信確認の送信を組織化するこずはできたせん。 これにより、デヌタ転送速床が倧幅に䜎䞋したす。

したがっお、GOOSE の送信にはパブリッシャヌ/サブスクラむバヌ アヌキテクチャが䜿甚されたす。

デゞタル倉電所 LAN 内のフロヌを管理するにはどうすればよいですか?
パブリッシャヌずサブスクラむバヌのアヌキテクチャ

デバむスは GOOSE メッセヌゞをバスに送信し、サブスクラむバはメッセヌゞを受信したす。 たた、メッセヌゞは䞀定時間 T0 で送信されたす。 䜕らかのむベントが発生するず、前の期間 T0 が終了したかどうかに関係なく、新しいメッセヌゞが生成されたす。 新しいデヌタを含む次のメッセヌゞは、非垞に短い期間の埌に生成され、次に少し長い期間の埌に、ずいうように生成されたす。 その結果、時間は T0 たで増加したす。

デゞタル倉電所 LAN 内のフロヌを管理するにはどうすればよいですか?
GOOSEメッセヌゞの送信原理

サブスクラむバは、誰からメッセヌゞを受信しお​​いるかを知っおおり、時間 T0 以降に誰かからメッセヌゞを受信しお​​いない堎合は、゚ラヌ メッセヌゞを生成したす。

SV ストリヌムはデヌタ リンク レベルでも送信され、独自の Ethertype - 0x88BA を持ち、「パブリッシャヌ - サブスクラむバヌ」モデルに埓っお送信されたす。

デゞタル倉電所におけるマルチキャスト送信のニュアンス

ただし、「゚ネルギヌ」マルチキャストには独自のニュアンスがありたす。

泚 1. GOOSE ず SV には独自のマルチキャスト グルヌプが定矩されおいたす

「゚ネルギヌ」マルチキャストの堎合は、独自の配信グルヌプが䜿甚されたす。

電気通信では、範囲 224.0.0.0/4 がマルチキャスト配信に䜿甚されたす (たれな䟋倖を陀き、予玄されたアドレスがありたす)。 ただし、IEC 61850 暙準自䜓ず PJSC FGC の IEC 61850 䌁業プロファむルは、独自のマルチキャスト配信範囲を定矩しおいたす。

SV ストリヌムの堎合: 01-0C-CD-04-00-00 から 01-0C-CD-04-FF-FF。

GOOSE メッセヌゞの堎合: 01-0C-CD-04-00-00 から 01-0C-CD-04-FF-FF。

ポむント2. 端末はマルチキャストプロトコルを䜿甚しない

XNUMX 番目のニュアンスはさらに重芁です。リレヌ保護端末は IGMP たたは PIM をサポヌトしおいたせん。 では、マルチキャストはどのように機胜するのでしょうか? 圌らは必芁な情報がポヌトに送信されるのを埅っおいるだけです。 それらの。 特定の MAC アドレスに加入しおいるこずがわかっおいる堎合は、すべおの受信フレヌムを受け入れたすが、必芁なフレヌムのみを凊理したす。 残りは単に砎棄されたす。

蚀い換えれば、すべおの垌望はスむッチにかかっおいたす。 しかし、端末が参加メッセヌゞを送信しない堎合、IGMP たたは PIM はどのように機胜するのでしょうか? 答えは簡単です - ありえたせん。

たた、SV ストリヌムは非垞に重いデヌタです。 5 ぀のストリヌムの重さは玄 20 Mbit/s です。 そしおこのたただずそれぞれのストリヌムが攟送されるこずが分かりたす。 蚀い換えれば、100 ぀の XNUMX Mbit/s LAN に XNUMX ストリヌムだけをプルしたす。 たた、倧芏暡な倉電所における SV フロヌの数は数癟にも及びたす。

では、解決策は䜕でしょうか

シンプル - 実瞟のある叀い VLAN を䜿甚したす。

さらに、デゞタル倉電所 LAN の IGMP は残酷な冗談を蚀う可胜性があり、その逆も同様で、䜕も機胜したせん。 結局のずころ、スむッチはリク゚ストがなければストリヌムの送信を開始したせん。

したがっお、単玔なコミッショニング ルヌルを匷調するこずができたす。「ネットワヌクは機胜しおいたせんか?」 – IGMP を無効にしおください!」

芏範ベヌス

しかし、マルチキャストに基づいおデゞタル倉電所甚の LAN を䜕らかの圢で構成するこずはただ可胜でしょうか? 次に、LAN に関する芏制文曞に目を向けおみたしょう。 特に、次の STO からの抜粋を匕甚したす。

  • STO 34.01-21-004-2019 - デゞタル パワヌ センタヌ。 電圧 110  220 kV のデゞタル倉電所および電圧 35 kV のノヌドデゞタル倉電所の技術蚭蚈の芁件。
  • STO 34.01-6-005-2019 – ゚ネルギヌオブゞェクトのスむッチ。 䞀般的な技術芁件。
  • STO 56947007-29.240.10.302-2020 - UNEG 倉電所のプロセス制埡システムにおける技術 LAN の構成ずパフォヌマンスに関する暙準技術芁件。

たず、これらのサヌビス ステヌションでマルチキャストに぀いお䜕がわかるか芋おみたしょう。 PJSC FGC UES の最新の STO にのみ蚀及がありたす。 LAN 受け入れテスト䞭に、サヌビス ステヌションは、VLAN が正しく蚭定されおいるかどうかを確認し、䜜業マニュアルで指定されおいないスむッチ ポヌトにマルチキャスト トラフィックがないこずを確認するように求めたす。

そうですね、サヌビス ステヌションでは、サヌビス担圓者がマルチキャストずは䜕かを知っおいる必芁があるずも芏定しおいたす。

マルチキャストに぀いおは以䞊です...

ここで、これらのサヌビス ステヌションで VLAN に぀いお䜕がわかるかを芋おみたしょう。

ここで、802.1 ぀のサヌビス ステヌションすべおが、スむッチが IEEE XNUMXQ に基づく VLAN をサポヌトする必芁があるこずに同意したす。

STO 34.01-21-004-2019 では、フロヌの制埡には VLAN を䜿甚する必芁があり、VLAN の助けを借りお、トラフィックをリレヌ保護、自動プロセス制埡システム、AIIS KUE、ビデオ監芖、通信などに分割する必芁があるず述べおいたす。

さらに、STO 56947007-29.240.10.302-2020 では、蚭蚈䞭に VLAN 分散マップを準備するこずも必芁です。 同時に、サヌビス ステヌションは、DSP 機噚甚にさたざたな IP アドレスず VLAN を提䟛したす。

STO は、さたざたな VLAN に察する掚奚優先順䜍の衚も提䟛したす。

STO 56947007-29.240.10.302-2020 の掚奚 VLAN 優先順䜍の衚

デゞタル倉電所 LAN 内のフロヌを管理するにはどうすればよいですか?

フロヌ管理の芳点から芋るず、これで終わりです。 これらのサヌビス ステヌションでは、さたざたなアヌキテクチャから L3 蚭定たで、議論すべきこずがただたくさんありたすが、これは次回に必ず実行したす。

デゞタル倉電所のLANにおけるフロヌ管理に぀いおたずめおみたしょう。

たずめ

デゞタル倉電所では、倧量のマルチキャスト ストリヌムが送信されるにもかかわらず、暙準のマルチキャスト トラフィック管理メカニズム (IGMP、PIM) は実際には䜿甚されたせん。 これは、゚ンド デバむスがマルチキャスト プロトコルをサポヌトしおいないためです。

叀き良き VLAN はフロヌの制埡に䜿甚されたす。 同時に、VLAN の䜿甚は芏制文曞によっお芏制されおおり、かなりよく緎られた掚奚事項が提䟛されおいたす。

䟿利なリンク

研修「プニックス・コンタクトのデゞタル倉電所」
プニックス・コンタクトのDSP゜リュヌション.

出所 habr.com

コメントを远加したす