What protection engineers need to know about networking
Notice bibliographique
Résumé
The communications infrastructure of the electric grid has been evolving rapidly in the last decades due to the need for transporting ever more sophisticated information, both data and control. More recently Ethernet based networks have been added into the picture, as modern relays need to communicate with control and dispatch centers and centralized management systems over local and wide area networks. Notably, the need to support IEC 61850 standards encouraged relay vendors into speeding up the development of Ethernet as a preferred method of communication. The benefits of Ethernet networking are huge. Flexibility and easy deployment are only two of them. However Ethernet networking comes with features that protection engineers need to be aware of, if they wish to take full advantage of its capabilities. It also comes with new challenges that protection engineers need to be aware of. Network latency and availability must be carefully considered for. Cybersecurity must be planned, the risk of cyberattacks evaluated and protection measures implemented. This paper explores the network architecture of the modern protection and control (P&C) systems including protective relays themselves. It discusses aspects such as the use and benefits of routing, the need and solutions for maximum availability and real time response, as well as security measures that can be taken to reduce the risk of cyberattacks inherent when connecting over Ethernet. The paper also highlights some of the best practices when using Ethernet networking in the grid, providing examples drawn from the protective relaying and cybersecurity practice. It offers simple solutions to typical security challenges possibly encountered during the commissioning phase and in the daily operations of relay devices.
Récupéré en direct depuis OpenAlex et désinversé. Les résumés ne sont pas conservés dans cette base de données : les index inversés représentent 8,6 Go des 9,3 Go de texte de la base, et le serveur dispose de 13 Go libres.
Comment cette classification a été obtenuedéplier
Prédiction distillée sur la base complète
Imitation des enseignantsNi prévalence calibrée, ni vérité terrain. Validation humaine à venir. Apprise à partir de 10 348 étiquettes directes de Codex et de 10 348 étiquettes directes de Gemma. Le mode candidate est l'union des têtes enseignantes seuillées; le consensus est leur intersection. Ces sorties portent le statut machine_predicted_unvalidated et ne sont ni des étiquettes humaines ni des étiquettes directes de modèles de pointe.
Scores Codex et Gemma par catégorie
| Catégorie | Codex | Gemma |
|---|---|---|
| Métarecherche | 0,000 | 0,000 |
| Méta-épidémiologie (sens strict) | 0,000 | 0,000 |
| Méta-épidémiologie (sens large) | 0,000 | 0,000 |
| Bibliométrie | 0,000 | 0,000 |
| Études des sciences et des technologies | 0,000 | 0,000 |
| Communication savante | 0,000 | 0,000 |
| Science ouverte | 0,000 | 0,000 |
| Intégrité de la recherche | 0,000 | 0,000 |
| Charge utile insuffisante (le modèle a refusé de juger) | 0,000 | 0,000 |
Scores machine (provisoires)
Les deux têtes enseignantes du modèle étudiant, lues sur ce travail. Un score ordonne la base pour la relecture; il n'affirme jamais une catégorie, et le statut de validation accompagne chaque rangée tel quel.
Scores de référence d'un modèle non mature (critères de maturité non atteints, 7 itérations). Un score ordonne; il n'affirme jamais une catégorie.
score_only:v0-immature-baseline · tel quel depuis la passe de notation : score_only signifie que le nombre peut ordonner les travaux, et qu'aucune étiquette de catégorie n'en découleClassification
machine, non validéePrédiction automatique; un appel candidat d’une seule tête enseignante, pas un consensus.
Le détail, modèle par modèle et score par score, se trouve en fin de page sous « Comment cette classification a été obtenue ».