По дефиниция системата за автоматизация е система, работеща в режим на Реално Време. Тъй като това понятие е подложено на множество интерпретации, нека първо да го дефинираме.

Дефиницията за Реално Време (РВ) е съгласно DIN 443000 и гласи:

„Режим на работа в реално време е режимът на работа на компютърна система, при който програмите за сбор и обработка на спорадично възникващи данни са в постоянна готовност за изпълнение, така че резултатите от обработките да са на разположение в рамките на предварително зададен интервал от време.“

 

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

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

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

С други думи, системата трябва да може да приема и отработва информацията своевременно, т.е. докато тя е налична и актуална. Дефинираните по-горе критерии се наричат „твърди критерии“.

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

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

Съществуват и т.нар. „меки критерии“ за Реално Време, при които времето за реакция, респ. за отговор, се определя на базата на статистически показатели, т.е. усреднено то се движи в определени рамки. Такива критерии се прилагат например при функциите за визуализация, протоколиране, архивиране и пр. Тук времето за извеждане на картината спокойно може да се движи между 1 и няколко секунди и това не се отразява върху работоспособността на системата. Същото се отнася и до функциите за архивиране и протоколиране, тъй като при системите данните от обекта пристигат с времето си на възникване.

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

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

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

От друга страна, системата и в най-лошия случай (worst case) трябва да реагира адекватно и детерминирано по критериите за РВ.

 

 

Системни мерки

 

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

 

Много йерархична и модулна структура на системата. Основните системни нива са:

• Процесно, на което се извършва сбора на информацията от технологичните съоръжения/обектите (процесна информация), която постъпва паралелно, директно на цифрови и аналогови входове и изходи и по комуникационен път от Intelligent Electronic Devices – IED, чрез различни видове мрежи, среди и комуникационни протоколи.
• Обектно. На това ниво се извършва обмена на данни между обектите на системата и Командните Станции – КС. КС може да са разположени на различни системни нива, напр. локално, регионално и/или централно.
• Системно. На това ниво се осъществява комуникацията на нивото на командните станции, както и между системата и „външни“ системи.

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

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

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

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

 

Децентрализация на функциите

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

 

Програмна система, изградена на базата на „паралелни процеси“ и “Event-Driven“ Architecture – ЕDA

Системата се характеризира със своята комплексна функционалност, реализирана предимно от програмната ѝ система. Тя се състои от широк набор универсални програмни модули, като критерия за разпределение на функциите по модули е, модулите да са функционално завършени/независими и обмена на данни между тях да е минимален.

След инсталацията, модулите се трансформират в програмни процеси, разположени в отделните системни структури/компютри.

Програмната архитектура на всички нива е съставена от паралелно работещи процеси и е организирана като “Event-Driven“ Architecture.

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

Активирането на процесите се извършва спонтанно, на базата на външни и/или вътрешни събития (events), предизвикани от промяна на процесната информация или от такива, предизвикани от междинни резултати, формирани от различните видове обработки на данните.

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

 

Минимизиране и структуриране на информационните потоци

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

Съществена за системата информация са промените. Затова функциите за сбор на информацията и нейното предаване към по-високите системни нива, са ориентирани към установяването на промените, регистриране на времето на възникването им при източника и предаването им с висок приоритет към съответните абонати.

Непроменената информация също се предава с цел периодичното актуализиране на Базите Данни, но това може да става при възможност и с по-нисък приоритет. Дефиницията на понятието „промяна на сигнализация“ е ясно. То се състои в установяването на промяна на състоянието на определено съоръжение.

По-сложен е въпросът с понятието „промяна на меренията“. Те са в състояние на перманентна промяна и тяхното непрекъснато предаване води до прекомерно натоварване на каналите за връзка и разход на изчислителен ресурс за обработването им. Поради тази причина на всяко мерене се присвоява своя Δ (делта), която е съобразена с теглото на съответната величина, върху технологичния процес и неговите характеристики. В крайна сметка стойността на една измервана величина се предава, когато нейната Δ е надвишена.

Δ – та, освен със зададена абсолютна стойност, отразяваща разликата между две поредни четения на величината, може да се определя и по различни други математически зависимости.

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

 

Комуникационен софтуер, изграден на базата на паралелни и независими комуникационни процеси

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

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

С тази цел комуникационната програмна система е изградена на базата на паралелни и независимо действащи комуникационни процеси, поддържащи физически и/или логически „точка-точка“ топологии.

Различните източници на информация поддържат комуникацията с един или няколко абоната. Връзката с всеки от тях е отделна и се поддържа от двойка Master/Slave, респ. Client/Server от двете страни.

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

Смущения или отпадане на комуникацията по определен канал/канали водят обикновено до загуба на процесната информация, възникнала в обекта по време на липсата на комуникация. Затова всеки канал разполага със собствени информационни и програмни структури, които архивират тази информация и я предават към съответния абонат след възстановяването на връзката с него.

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

 

Управление на данните

Управлението на данните се обезпечава от следните видове Бази Данни:

• Off-line База Данни;
• База Данни за Реално Време – БДРВ и
• База Данни – Архиви.

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

Адаптирането на информационното пространство към конкретен обект се извършва посредством конфигуриране на БД със специфичните за обекта данни.

Off-line Базата Данни представлява стандартизирана, универсална, релационна БД, която съдържа статичната информация за обекта (коефициенти, параметри, изображения и пр.). Тя работи предимно в Off-line режим и служи за конфигуриране на системата и генериране на БДРВ.

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

БДРВ е разпределена по цялото протежение на системната йерархия и обезпечава програмните процеси с необходимите им данни.

Базата Данни – Архиви съдържа, обработва, форматира, филтрира и извежда архиви на промените на процесната информация, алармени състояния, действия на диспечера и пр. към съответните потребители.

 

Реализацията на посочените по-горе принципни постановки се постига чрез:

• Използване на подходяща Операционна Система за Реално Време (ОСРВ);
• Разработване на База Данни за Реално Време (БДРВ);
• Създаване на подходяща структура на Приложното Програмно Осигуряване (ППО) и др.

 

Избор на системен софтуер, Операционна Система за Реално Време (ОСРВ)

Софтуерът на системата трябва да е изграден на базата на Операционна Система за Реално Време (ОСРВ). Динамичните качества на компютъра, респ. на системата за Реално Време, се определят от вида и организацията на програмното осигуряване и възможностите на операционната система.

За да се постигнат желаните кратки времена за реакция, при вариращи в широки граници информационен обем, обработки, а оттам и натоварване на компютъра, програмната му система трябва да е организирана като „паралелни“ процеси, активирани спорадично, в зависимост от възникналите събития и необходимите обработки (Event-Driven Architecture – EDA).

Операционната Система за Реално Време (ОСРВ) трябва да разполага с широка гама от системни средства, обезпечаващи:

• многозадачния режим;
• синхронизацията и координацията на работата на програмните модули (ПМ) и/или процесите в рамките на целия изчислителен ресурс и
• обмена на информация и събития на ниво програмни модули, микрокомпютри и подсистеми.

 

Информационно осигуряване – База Данни за Реално Време (БДРВ)

Частта от Информационното осигуряване, обезпечаваща режима на работа в РВ, е Базата Данни за Реално Време (БДРВ). Тя трябва да работи под управлението на Операционната Система за Реално Време.

Предназначението на БДРВ е:

• Да буферира информацията, постъпваща от процеса, като по този начин да „развързва” динамиката на технологичния процес от комуникацията на Командната Станция (КС) на Централния Пост (ЦП) с неговите обекти;
• Да извършва проверка на достоверността на информацията;
• На базата на установените външни и/или вътрешни събития да активира последователности от вътрешни функции с цел цялостното отработване на технологичната ситуация;
• Да „захранва” с информация SCADA-, HMI- и HIS подсистемата и др.

Основно изискване към БДРВ е да позволява въвеждането и обработката на голям обем технологична информация за кратко време, т.е. за времето, през което информацията е валидна и налична.

При постъпване на промяна от процеса, редом с проверката за достоверност и записа на тази промяна в Информационния Модел (ИМ), БДРВ трябва да изпълнява и редица вътрешни функции и манипулации по всички останали обекти в ИМ, свързани технологично и/или функционално с елемента, генерирал промяната, с цел цялостната обработка на събитието.

Мерките, определящи високата динамика и бързодействие на БДРВ са:

• БДРВ се основава на информационни модели, описващи изцяло статиката и динамиката технологичните връзки на обектите;
• Информационният модел е статичен и инсталиран постоянно в паметта на компютъра;
• Всички връзки между обектите в БДРВ са реализирани на ниво Информационен Модел и са изчислени още при създаването на модела, т.е. offline.

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