Изисквания към комуникацията

 

Комуникацията на различните системни нива – системно, обектно и процесно, е в основата на всяка система. Поради тази причина системата трябва да може да се напасва към съществуващите дадености, като налична комуникационна инфраструктура, преносна среда, комуникационна технология и пр.

Режимът на работа в Реално време предполага изпълнението на определени изисквания по отношение на комуникацията в системата, а именно:

  • Обменът на данни между обектите и КС на различните системни нива трябва по възможност да се осъществява паралелно и независимо;
  • Обменът на данни трябва да е детерминиран във времето, т.е. да има гарантирано време за отговор на обекта, определено за най-лошия случай и надвишаването на това време да е еднозначен критерий за отпадане на връзката;
  • Между обектите и КС да има установена постоянна връзка, а не динамична, която се изгражда при появата на събитие и след това се разпада;
  • Заложените в технологичните изисквания времена за обмен на данните трябва да се гарантират независимо от:

              –   скоростта на обмена;

              –   разстоянията между обекта и КС;

              –   информационния обем на обекта;

              –   динамиката на промените в технологичния процес и други фактори;

Обменът на данни да е защитен с Hamming дистанция = 4 за информационния тракт и с Hamming дистанция = 6, за командния;

  • Комуникационната инфраструктура за нуждите на системите за автоматизация трябва да е физически отделена от тази на корпоративните и публичните информационни услуги.

Стриктното спазване на посочените по-горе изисквания може да се постигне чрез:

  • използването на директни телемеханични канали между обектите и съответните КС по топология „точка-точка” и/или „линия”, реализирани на базата на медни, оптични или безжични канали, с или без уплътнителни уредби и
  • използването на специализирани телемеханични протоколи, в т.ч. IEC 60870-5-101.

От изложеното по-горе следва, че от гледна точка на стриктното спазване на критериите за Реално Време, най-подходяща се явява директната физическа свързаност между обектите и Централния Пост.

Предвид наложилите се понастоящем комуникационни технологии, базирани на:

  • IEEE 802.3 Ethernet или 11 (WLAN);
  • „Carrier Sense Multiple Access with Collision Detection“ (CSMA/CD) – алгоритъм за достъп до мрежата, и
  • TCP/IP (Transmission Control Protocol/Internet Protocol) – мрежов протокол, наричани за кратко TCP/IP мрежи,

прилагането на тази свързаност е нереалистично и следователно телемеханичните системи трябва да се напасват към възприетите комуникационни технологии.

За да се определят мерките и подходите, които следва да се предприемат, е необходимо да се дефинират недостатъците и предимствата на тези мрежи по отношение на изискванията за работа в Реално време. Основните проблеми тук се коренят в принципите на изграждането на тези мрежи, а именно:

  • Средата не допуска пряка връзка между абонатите. Връзката се изгражда динамично при необходимост и след това се разпада. Времето за изграждане на връзка зависи от броя на абонатите, трафика и др. фактори, и е неопределено. Същото се отнася и до времето за пренос на информацията.
  • Този вид мрежи допускат възникването на конфликти при достъп до средата. В CSMA/CD алгоритъма решаването на конфликтите е предвидено, но при интензивен обмен и опити за достъп до мрежата може да се стигне до състояние, при което абонатите се блокират взаимно.
  • За преодоляване на по-големи разстояния се налага вплитането и прехода през различни мрежи и среди, т.е. използването на 3-ия и 4-ия слой на ISO-модела – Network Layer, за маршрутизация на пакетите. На това ниво пътят и поредността на изпратените пакети са неопределени, т.е. възможността за нарушаване на поредността на пакетите при приемника, както и за загуба на пакети, т.е. на информация, се допуска по дефиниция.
  • Вплитането на различни мрежи означава и смесването на потоците от технологична информация с тези от обичайния трафик и липса или ограничена възможност за физическо или поне логическо отделяне на информацията, предавана в Реално време от останалите информационни потоци, чийто обем е многократно по-голям.
  • Времето за „доставяне” на информацията до адресанта е неопределено и зависи от моментния трафик по мрежата. Приемането на информацията не се квитира/потвърждава. Оттук и отсъствието на ясно дефинирани времеви или други критерии за наличие или отсъствие на връзка, което в случая може да доведе до заблуда на оператора, като му се извежда неактуална информация, без указание за отпаднала или нарушена връзка с обекта.

 

Част от посочените по-горе недостатъци могат да се смекчат чрез подходящи системни мерки, но радикално не могат да се отстранят поради факта, че посочените по-горе принципи са в основата на изграждане на TCP/IP мрежите.

От изложеното по-горе следва, че основното изискване за обмен на информация в Реално време, а именно изискването за „детерминираност във времето”, при описаните мрежи не е обезпечено.

Съществуват и други типове мрежи, изградени на други принципи, напр. Token Ring – механизма. Такива са PROFIBUS – мрежите и др. подобни, чиито принципи на изграждане се доближават в значителна степен до изискванията за обмен на информация в Реално време, но поради слабото си разпространение са неприложими.

Ethernet, респ. TCP/IP – мрежите, имат и редица предимства:

  • Те се използват масово;
  • Реализацията им е сравнително бърза и не изискват големи капиталовложения;
  • Конфликти и зацикляния възникват главно при висок трафик и претоварване, а иначе поддържат много високи скорости на обмен на данни;
  • Притежават богати възможности за конфигуриране, а оттам и за приспособяване към конкретни изисквания и условия и др.

 

Системните мерки, които следва да се предприемат за пригаждане на системата към наложилата се комуникационна технология, са:

  • Инсталиране на телемеханичния протокол по IEC 60870-5-104 на 7-то (приложно) ниво на OSI-модела и пълноценно използване на механизмите, заложени в него, в т.ч. възможностите му за контролиране на комуникацията, квитирането на съобщенията и др.

Чрез квитирането се осигурява възможността за установяване на липсващи пакети в двете посоки, а чрез способността на Client-а да контролира комуникационния процес, става възможно да се следи таймингът му и да се формулират временни параметри, служещи за обективен критерий за:

              –  наличие и отпадане на връзката;

              –  натовареността на канала;

              –  качеството на обмена и пр.

  • Предаване на технологичната информация от обекта с времената на възникване на събитията. Така се преодолява проблемът с неопределеността на времето за предаване на информацията по мрежата.
  • Отделяне на информационните потоци, носещи технологичната информация от обектите, от всички останали. Това се постига чрез логическо сепариране на мрежата, при което трафикът по създадената „логическа“ мрежа се определя единствено от динамиката на процесната информация.
  • Организиране на програмната структура на комуникационния софтуер в много на брой паралелно и независимо работещи клона (процеси), като за целта за всяка създадена „връзка“ се създава съответната двойка „Client – Server“ процеси. Така се получава логическа „точка-точка“ топология.
  • Създаване на механизми, обезпечаващи актуалността, достоверността и пълнотата на информацията.

 

 

Комуникация и достоверност на данните

 

Системата поддържа паралелна и независима комуникация по различни комуникационни среди, технологии и протоколи.

Комуникацията на нивото на RTU се извършва на 3 нива:

  • На процесно ниво, където се осъществява обменът на данни с IDE;
  • На обектно ниво, където се осъществява обменът на данни с други периферни постове – Концентратор на Данни (КД) и
  • На системно ниво, където се осъществява обменът на данни със системни структури, разположени на по-високи системни нива, каквито са локалната Командна Станция – ЛКС, SCADA,–HMI и HIS Server-ите на КС на системата и „външни“ системи.

Обвръзката с процеса се осъществява паралелно или серийно. Паралелно се въвеждат цифровите и аналоговите сигнали от реле-повторители, датчици и цифровите вход/изходи. Серийно се въвеждат данните от IED.

RTU поддържа следните физически интерфейси:

  • RS 232;
  • RS 485;
  • RS 422;
  • Ethernet и други стандартни интерфейси.

Така то може да използва за комуникацията следните физически среди:

  • Меден кабел;
  • Оптика;
  • TCP/IP мрежи;
  • PLC – канали;
  • Радиомрежи;
  • GPRS – мрежи;
  • VLAN – мрежи, и др.

На процесно ниво RTU поддържа и следните локални мрежи:

  • CAN-BUS;
  • MODBUS;
  • I²C-Bus;
  • SPI-Bus;
  • При необходимост могат да се използват и други Bus-ове като напр. PROFIBUS и пр.

За обмен на данни с IED могат да се използват и следните протоколи:

  • IEC 61107, IEC 62056;
  • IEC 60870-5-101/104;
  • IEC 60870-5-103;
  • IEC 61850 Client;
  • MODBUS и др.

На системно ниво, в т.ч. и в КС на ЦП, се използват следните протоколи:

  • IEC 60870-5-101;
  • IEC 60870-5-104;
  • Собствен протокол, както и др.

Комуникационните модули, могат да се инсталират в необходимото количество в зависимост от конкретната конфигурация и териториално разположение на КС, RTU и други обекти. Всеки комуникационен модул притежава собствен комуникационен стек, чрез който същия може да се адаптира към конкретната комуникационна инфраструктура, в т.ч.:

  • Комуникационна среда;
  • Комуникационна технология;
  • Физически интерфейс;
  • Протокол и пр.

От своя стана, както КС, така и RTU, могат да работят паралелно и независимо като Server за произволен брой Client-и, и като Client-и за произволен брой Server-и.

Параметрите на комуникацията и протоколите за обмен на информация за всеки Server, респ. Client са самостоятелни и независими един от друг.

Същото се отнася и за използваните комуникационни протоколи.

В ролята си на Server, RTU поддържа отделни Data Images за всеки Client, в който се съдържа необходимата за него информация като количество и състав.

 

 

Консистентност на данните

 

В последните години, когато комуникацията между обектите и Централния Пост (ЦП) във все по-голяма степен се базира на TCP/IP протокола, и когато като източник на технологична информация се явяват и Intelligent Electronic Devices – (IED), проблемът с консистентността на данните, т.е. с достоверността и актуалността на информацията от обектите в Командната Станция (КС) на ЦП става все по-важен и сложен за решаване.

Проблемът възниква от нарушаване на комуникацията на различните нива. Смущения в комуникацията възникват при краткотрайно или продължително прекъсване на връзката, както и в случаите, когато връзката не е прекъсната, но каналът е претоварен.

Тъй като TCP/IP не поддържа функции за потвърждаване на приемането на съобщенията – квитиране на съобщенията, тази функционалност е прехвърлена на приложния 7-и слой на OSI модела, т.е. на протокола IEC 60870-5-104. От изпратените от Server-а към Client-а съобщения, достигат всички, част от тях или никакви, и той квитира броя на получените съобщения. Неприетите съобщения трябва да се идентифицират и изпратят наново и в зависимост от състоянието на канала това може да се повтаря многократно.

Същевременно от процеса възникват нови събития, които под формата на ASDU също трябва да се изпратят към ЦП и то с приоритет, по-висок от този на неквитираните.

Другият проблем е този, когато комуникацията на системно ниво, т.е. между RTU и КС, е изправна, но е прекъсната и/или смутена комуникацията на процесно и/или обектно ниво, т.е. между RTU и IED, респ. прилежащите обекти (RTU). В тези случаи технологичната информация от съответните устройства, респ. обекти, се губи. При възстановяване на връзката някои от засегнатите устройства са в състояние да предадат възникналата междувременно информация с времената на възникването ѝ, която се явява „стара” информация. Непостъпването на „старата“ информация в ЦП води до „дупки“ в архива на КС на ЦП.

Във всеки случай, нарушаването на консистентността на данните води до загуба на информация в ЦП, изразяваща се в това, че изобразяваната там информация от обектите е неактуална и/или има загубена информация в архивите.

Проблемът се усложнява и от това, че описаното по-горе се отнася практически до всеки Client, респ. до всяка връзка, установена с RTU-то, а това ще рече, че първо трябва да се вземат мерки за избягване на неконсистентността на данните и, че тези мерки трябва да се прилагат към всички връзки.

От изложеното по-горе е видно, проблемите, с елементарни средства, като напр. „кръгов буфер“ и пр. не могат да се решат, въпреки че този подход се използва упорито.

В предлаганото решение, комуникационният софтуер на всички нива включва в себе си и сложна структура от „опашки“  и др. системни инструменти за обезпечаване на консистентността на данните, независимо от броя на връзките и състоянието на комуникационните пътища. Последното трябва да се разбира в смисъл, че при липса на комуникация, RTU разполага със структури с достатъчно разнообразие и дълбочина, позволяващи съхраняването на данните и предаването им след възстановяване на връзката.

Въпросът за това, какво количество данни могат да се възстановят или за какъв период от време, е количествен и касае обема на предвидената за целта памет, което е въпрос на конфигуриране.

 

При предлаганото решение, при наличие или поява на връзка, актуалните промени се предават веднага. Неквитираните съобщения, в резултат от претоварване на канала, се съхраняват в опашки, структурирани по типове данни и други критерии, и се предават с по-нисък приоритет към ЦП.

В зависимост от това кои от предадените съобщения са приети от ЦП, опашките се пренареждат (актуализират) като в тях, от една страна, остават само неприетите до момента съобщения, но от друга, те се попълват и с нови неприети съобщения от предишни сесии. Процесът се повтаря, докато всички опашки се изпразнят.

При отпадане на връзката, актуалните данни се записват директно в съответните архивни структури. При възстановяване на връзката:

  • първо тече инициализацията,
  • след това се предават актуалните промени,
  • следвани от непредадените, поради претовареност на канала данни, и
  • данните от архивите.

Предвид различната значимост на различните типове данни за потребителя, описаните по-горе структури се повтарят за различните типове данни, в т.ч. Инициализация, Сигнализации, Измервания, Броячни стойности и пр.

Изложеното по-горе се отнася поотделно, независимо и паралелно за всяка връзка и Client.

 

 

Паралелни структури и структура на комуникационната конфигурация

 

Изграждането на комуникационната структура е частен случай на принципа за изграждане на структури – апаратни и програмни, които в максимална степен са децентрализирани и организирани в паралелни клонове. Този подход намалява обхвата на пораженията, породени от появата на неизправност в дадено устройство, а също така води до по-добри динамични качества на системата.

Принципно, на всички системни нива комуникацията трябва да е изградена чрез паралелно и независимо работещи клонове.

На процесно ниво комуникацията между RTU и IED се осъществява по Ethernet за IEC 61850 или по RS 232/485/422 и 20 mA токов кръг за тези, работещи по останалите протоколи.

Предвид особеностите на комуникационните линии, базирани на RS 485/422, изразяващи се в това, че повреда в един от абонатите не води до отпадане на цялата линия, разпределението на IED по линии трябва да се извършва, както следва:

  • ЦРЗ, работещи по протокол IEC 60870-5-103, през които преминават команди за управление на комутационни съоръжения, да са в режим „точка – точка“, т.е. линия с един абонат;
  • IED, представляващи P,Q,U,I метри и/или електромери, да се групират в не повече от 4 устройства в линия. Така броят на линиите се увеличава, но получените паралелни структури обезпечават по-високата надеждност.

 

 

Резервираност на възловите системни структури

 

Препоръчително е Комуникационните Server-и (Front-End, FE-Server), инсталирани в КС на ЦП, да се дублират и да работят паралелно. Те следва да са равностойни. При отпадане на някой от тях или на връзка с него, абонатът му следва автоматично да се превключва към другия.

Всеки от двата комуникационни Server-а трябва да поддържа връзка с всеки от обектите по два канала – основен и резервен. Обменът на информацията с всеки един от Server-ите трябва да е постоянен. Така всеки от двата Server-а ще поддържа актуална База Данни за всички обекти и в случай на превключване, ще е в състояние да поема работата, без да се налага инициализация и другите процедури при смяна на Server.