Що е то Автоматизация и има ли тя почва у нас?

[Mateev]

Ами в цялата тема и дори в целия раздел само за това се говори, но ти явно не си го изчел, и все още в главата си имаш базовите представи, които има един "начинаещ" автоматизатор. Явно ще трябва да започна да обяснявам отново.

Най-елементарната автоматизация, която обикновенно си представят специалистите по електроника, е следната:
ВХОДОВЕ <--> КОМПЮТЪР С ПРОГРАМА <--> ИЗХОДИ

Когато се позамислят малко повече, стигат до извода, че всъщност схемата е:
КАНАЛИ С ДАННИ <--> КОМПЮТЪР С ПРОГРАМА <--> УПРАВЛЯВАНИ ПРОЦЕСИ

Следващото ниво е когато устройствата са раздалечени едно от друго. Тогава ще се наложи да вмъкнем и комуникация между тях:
КАНАЛИ С ДАННИ <--> ОТДАЛЕЧЕНА КОМУНИКАЦИЯ <--> КОМПЮТЪР С ПРОГРАМА <--> ОТДАЛЕЧЕНА КОМУНИКАЦИЯ <--> УПРАВЛЯВАНИ ПРОЦЕСИ

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

[Mateev]

КОМПЮТЪР С ПРОГРАМА

Това е най-лесния аспект. Всеки си го представя, защото всеки го има. На най-високо ниво е ПРОГРАМАТА. В нея може да се реализират всякакви логики, от типа на:
- ЧЕТЕНЕ НА ДАННИ ЗА ПРОТИЧАЩИТЕ ПРОЦЕСИ
- ЗАПИС НА ДАННИТЕ В НЯКАКВА БАЗА ДАННИ
- ВИЗУАЛИЗИРАНЕ В РЕАЛНО ВРЕМЕ НА ТЕЗИ ДАННИ - Текстово и/или графично
- ВИЗУАЛИЗИРАНЕ НА ИЗТОРИЧЕСКИТЕ ДАННИ ОТ БАЗАТА С ДАННИ - Текстово или Графично
- УПРАВЛЯВАЩА ЛОГИКА, която обикновенно се състои от дълъг списък с логически правила, обединение с логическите оператори AND, OR, XOR, NOT и комбинации между тях
- УПРАВЛЕНИЕ НА НЯКАКВИ ПРОЦЕСИ - щракат се релета, въртят се мотори и т.н.

Компютъра с програмата може да бъде един, а може и да са много, които да си комуникират помежду си. Процесора може да е мощен, а може и да е по-слаб (в контролерите). Тука ясно се отличават две основни схеми на управление:

ЕДИН КОМПЮТЪР С ЕДНА ПРОГРАМА <--> КОМУНИКАЦИЯ <--> МНОГО НА БРОЙ ПАСИВНИ ВХОДОВЕ И ИЗХОДИ

КОМПЮТЪР С ПРОГРАМА И ВХОДОВЕ И ИЗХОДИ <--> КОМУНИКАЦИОНЕН ПРОТОКОЛ <--> ВТОРИ КОМПЮТЪР <--> КОМУНИКАЦИОНЕН ПРОТОКОЛ <--> ТРЕТИ КОМПЮТЪР..............

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

[Mateev]

КОМУНИКАЦИЯ

С развитието на автоматизацията нуждата от комуникация и съвместимост между устройствата е наложило създаването на редица СТАНДАРТНИ ПРОТОКОЛИ за обмен на информация, и именно те в един момент от време се оказаха ПО-ВАЖНИ от конкретния хардуер или софтуер. За да може човек да си построи някаква си собствена схема за автоматизация, той първо трябва да си подбере хардуерни устройства, поддържащи един и същи ПРОТОКОЛ ЗА КОМУНИКАЦИЯ. Именно затова аз ти отговорих няколко постинга по-горе, че MODBUS е един от най-масовите протоколи по света, и че специално за нашите цели (енергетиката) няма как да се разминем без него предвид факта, че всички електромери са направени да комуникират именно по MODBUS.

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

[Mateev]

ВХОДОВЕ, ИЗХОДИ И ВЪТРЕШНИ РЕГИСТРИ

Ами това е физическата периферия на устройствата за автоматизация. Някакви сигнали (аналогови или цифрови) постъпват на ВХОДОВЕТЕ на контролерите, има някакви ВЪТРЕШНИ РЕГИСТРИ, които променят стойността си в резултат на работата на някаква програма, и някакви ИЗХОДИ (аналогови или цифрови), посредством които се управляват процесите.

Тука е мястото да споменем, че дадения контролер, притежаващ входове и изходи, обикновенно може да работи в два режима на работа - Master и Slave.

MASTER
При този режим на работа контролера е активен. В него работи някаква автономна програма, която чете входовете, анализира ги, взема решения и управлява изходите.

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

Има и още две понятия, които внимателно трябва да се осмислят и да не се бъркат - Сървър и Клиент.

СЪРВЪР
Сървъра обикновенно предоставя ресурси за външно ползване.

КЛИЕНТ
Клиента се свързва към сървъра и иска или дава данни (клетки от паметта). В случая активната страна е Клиента, а пасивната - Сървъра. Вземането на решения се извършва от КЛИЕНТА. Главният компютър обикновенно се явява КЛИЕНТА. Този аспект много често въвежда в заблуждение разработчиците на системи и често срещам хора, които бъркат горните 4 понятия, написани с дебели букви.

[Mateev]

Когато човек започне да измисля схемата на някаква автоматизация, трябва да си изясни какви хардуери ще използва, какви протоколи за комуникация ще има, и къде ще работи логиката (програмата) - на един компютър или на повече. Тoест ще има ли, колко на брой ще са, и как ще са свързани горните 4 думички - Master, Slave, Server и Client.

Предполагам че вече разбра, че под АВТОМАТИЗАЦИЯ се разбират най-различни видове схеми на свързване на компютри, програми, канали за данни и протоколи за обмен. В по-горните постинги намекнах и за едно междинно хардуерно и/или софтуерно устройство, наречено OPC сървър. Може да го включваш в схемата, но може да се размине и без него. Необходимостта от един OPC сървър нараства с нарастване на сложността на схемата и броя на каналите с данни. Точно когато говорим за електромери имаме хиляди канали с данни, които е доста трудно да бъдат организирани в единно дърво, ако се опитваш да го правиш без OPC сървър. Също така когато имаш много на брой различни хардуерни устройства, говорещи си по различни канали за данни и с различни протоколи за обмен, тогава именно OPC сървъра е нещото, което може да въведе ред в целия хаос, и да предостави на програмата за управление единен стандартизизран интерфейс към всичката шарения в сложната ти схема.

[Mateev]

По конкретното ти задание - искаш да наблюдаваш и управляваш много на брой слънчеви централи:

Ами аз бих могъл да ти дам идеи само за централите с инвертори на SMA, защото ги познавам най-добре. Предполагам обаче че и другите производители на инвертори са си направили труда да предоставят някакъв стандартен интерфейс, подобен на Sunny WebBox-a на SMA. Просто трябва да ги проучиш.

Та ако говорим за SMA, най-простата схема е следната:
КОМПЮТЪР <--> ПРОГРАМА <--> API на SMA <--> КОМУНИКАЦИЯ ПО TCP/IP <--> WebBox-ове <--> ИНВЕРТОРИ

Алтернативна схема е:
КОМПЮТЪР <--> ПРОГРАМА <--> MODBUS драйвер <--> КОМУНИКАЦИЯ MODBUS over TCP/IP <--> WebBox-ове <--> ИНВЕРТОРИ

Програмата по втората схема ще я напишеш по-бързо и по-лесно. Ако добавиш и OPC сървър, ще стане още по-лесно, защото схемата тогава ще бъде:
КОМПЮТЪР <--> ПРОГРАМА <--> OPC СЪРВЪР
Какво се случва от другата страна на OPC сървъра въобще не те интересува. Той си е направен коректно, комуникира си когато трябва, с когото трябва и по какъвто протокол трябва. Ти просто нямаш абсолютни никакви грижи за това, освен първоначалната конфигурация, която става много бързо когато придобиеш опит.

[Mateev]

По принцип една от най-лесните схеми за направа на АВТОМАТИЗАЦИЯ С ПРОИЗВОЛНА СЛОЖНОСТ е следната:

КОМПЮТЪР <--> NI LabView програма <--> NI LabView OPC Server <--> MODBUS мрежи <--> MODBUS пасивни контролери

Преимуществата са следните:
1. Схемата на автоматизацията е силно опростена - използва се един единствен софтуер, при това най-добрия в света
2. Изключително лесно се автоматизират хиляди устройства, разположени в целия свят
3. Всичко зад OPC сървъра си работи и комуникира без твое участие и без да се наложи да напишеш и един програмен ред
4. Ти се концентрираш върху една единствена програма, разположена на един единствен компютър
5. Изключително лесно се дебъгват всякакви проблеми в логиката на управление

Недостатък на тази схема е това, че ненадеждните канали за връзка (Internet) могат да доведат до проблеми с управлението на някои критични процеси. Ако има такива в твоята автоматизация, то тогава няма как - ще трябва да има и локално работещи програми на локални контролери, но това насложнява схемата, програмите, комуникациите, дебъгването и загубеното време не 2 пъти, а поне 100 или 1000 пъти.

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

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

[dancho]

Само 8 години се занимавам с мрежи и комуникации знам как да се защитават или дублират мрежи .
Благодаря за изчерпателния отговор .
Опитвам се да разбера на кой какво му е нужно и да предизвикам интерес за това някой да попита нещо конкретно .




Power BOX na SMA също подлежат на управление в посочената от мен схема в предния пост .
Мога на личен да поясня повече при интерес .

[Foton]

Г-н Матеев,
Не искам да влизам в спор с Вас, но според мен сте твърде далече от тези проблеми.
Не съм убеден, че този софтуер е най-добрия в света. И не само аз не съм убеден ами и тия дето твърдят, че когато хората говорят за SCADA, то най-често споменаваната дума е WinCC. Не ме разбирайте погрешно - въобще не съм любител на Siemens, но това са фактите.
Виждам че любимото ви занятие е да слгате някъде OPC. Мисля, че вече споменхме някъде, че за решаване на по-прости задачи (да кжем до около 1024 точки) използването на OPC не само не е наложително, но и в много от случаите е вредно.
Според моя опит решението за сравнително малък брой обекти (да кажем до около 50) би изглеждало така:
1. На обекта: PLC осигуряващо събиране на данните и обработка на командите, както и комуникация със системата като цяло. В случая WebBox не е много добро решение.
2. Преносна среда: интернет с резервиране по GSM (GPRS).
3. Самата SCADA вече може да се реши по няколко начина в зависимост от конкретните изисквания (например само за вас ли е решението или трябва да се ползва от няколко потребителя/собственика...). Останалите глезотии като статистики, графики и т.н. са само въпрос на софтуер и желание.

[Mateev]

Аз пън не знам защо ти отричаш OPC-то, след като то е най-лесният и най-евтиният начин да организираш няколко хиляди канала с данни да си текат в двете посоки безпроблемно, без при това да ти се наложи да използваш и един ред програма. Определено пък ти си много далеч от OPC-тата и дори си нямаш представа какво голямо облегчение са те.

Както и да е - не сме тука да си мерим пи.....ките. Нека всеки да си казва какво знае и да си мълчи за това, което не го знае. Това е технически форум и материята е огромна, така че няма начин всеки да знае всичко. Въздържайте се от коментари кой колко знае и кой колко не знае. Ако толкова много искате да се самовъзхвалявате, начина е друг - седнете, напишете 1000 постинга с информация и след това оставете другите да ви оценят.

[dancho]

Г-н Матеев,
Не искам да влизам в спор с Вас, но според мен сте твърде далече от тези проблеми.
Не съм убеден, че този софтуер е най-добрия в света. И не само аз не съм убеден ами и тия дето твърдят, че когато хората говорят за SCADA, то най-често споменаваната дума е WinCC. Не ме разбирайте погрешно - въобще не съм любител на Siemens, но това са фактите.
Виждам че любимото ви занятие е да слгате някъде OPC. Мисля, че вече споменхме някъде, че за решаване на по-прости задачи (да кжем до около 1024 точки) използването на OPC не само не е наложително, но и в много от случаите е вредно.
Според моя опит решението за сравнително малък брой обекти (да кажем до около 50) би изглеждало така:
1. На обекта: PLC осигуряващо събиране на данните и обработка на командите, както и комуникация със системата като цяло. В случая WebBox не е много добро решение.
2. Преносна среда: интернет с резервиране по GSM (GPRS).
3. Самата SCADA вече може да се реши по няколко начина в зависимост от конкретните изисквания (например само за вас ли е решението или трябва да се ползва от няколко потребителя/собственика...). Останалите глезотии като статистики, графики и т.н. са само въпрос на софтуер и желание.

някой работи ли в тази посока в крайна сметка

[Foton]

Г-н Матеев, моля да бъда извинен ако съм Ви засегнал. Просто исках да обърна внимание, че решенията с OPC освен дето са скъпи са и безпредметни за малки системи. OPC сървърът е прекрасно решение за огромни системи, но води след себе си редица неудобства (в случая цената му е най-малкия проблем). Като начало наличието му предполага PC, което да контактува с контролерите в обектите. Както можете да се досетите това PC обикновено работи под Win-нещо-си и си има характерната нестабилност. Какво се случва със системата като цяло когато това PC сдаде багажа по някаква причина (например спре тока) ? Предполагам не предлагате да организираме сървър със всичките му защити, резервирани захранвания и т.н. само за да осигурим мониторинг и управление на стотина обекта ? Просто тогава цената става безумна. Иначе сте безспорно прав - OPC е голяма глезотия и много улеснява нещата. Използвал съм го многократно при визуализации на конкретен обект, когато искам да избегна конфликтите м/у софтуерите на различни производители.

[Foton]

До dancho:
Нещо системата за ЛС се е сбъгясала и казва, че не съществуваш като потребител.
Както ти казах, работим по тази тема. Кажи какво точно те интересува?

[Mateev]

Г-н Матеев, моля да бъда извинен ако съм Ви засегнал. Просто исках да обърна внимание, че решенията с OPC освен дето са скъпи са и безпредметни за малки системи. OPC сървърът е прекрасно решение за огромни системи, но води след себе си редица неудобства (в случая цената му е най-малкия проблем). Като начало наличието му предполага PC, което да контактува с контролерите в обектите. Както можете да се досетите това PC обикновено работи под Win-нещо-си и си има характерната нестабилност. Какво се случва със системата като цяло когато това PC сдаде багажа по някаква причина (например спре тока) ? Предполагам не предлагате да организираме сървър със всичките му защити, резервирани захранвания и т.н. само за да осигурим мониторинг и управление на стотина обекта ? Просто тогава цената става безумна. Иначе сте безспорно прав - OPC е голяма глезотия и много улеснява нещата. Използвал съм го многократно при визуализации на конкретен обект, когато искам да избегна конфликтите м/у софтуерите на различни производители.

Прав си по отношение на сървъра. В нашата фирма има над 50 сървъва и всичките са на UPS захранване, което трябва да издържи само 7 секунди, докато се запали дизелов генератор. Тази система я изградих още преди десетина години, когато имах FOREX брокер, при който спирането на тока беше недопустимо. От тогава до ден днешен моите сървъри наистина не са оставали без захранване дори и за 1 секунда. Проблема със сриването на някой компютър се разрешава посредством една или друга форма на дублиране или триплиране. Например за файловете сървъри използвам DFS - всеки един фирмен файл е реплициран на наколко сървъра и клиентите дори и не разбират, когато рестартирам някой от тях. Проблема с OPC-тата е още по-лесен. В тях по стандарт има заложена функцията REDUNDANCY. Това означава, че един и същи промишлен контролер може да бъде разпитван от два или 3 сървъра, като само един от тях е активен в даден момент от време. На клиентския компютър също има OPC сървър с включено REDUNDANCY и той автоматично превключва между другите OPC сървъри, ако някой от тях се замота и не му отговори 2-3 секунди.

Цялата тази система на мене ми излиза 100% без пари, защото сървърите така или иначе си ги има във фирмата и така или иначе в момента изпълняват някаква друга полезна фирмена фунция. Слагането на един допълнителен OPC сервис с нищо не ги натоварва - те продължават да си работят по основната си функция и на майтап и между другото осигуряват и OPC потока от данни. Но това би трябвало да е така и във другите големи фирми, които искат някаква автоматизация. Със сигурност и те си имат някакви съществуващи сървъри, които със сигурност си имат и някаква форма на защита на захранването - най-малкото UPS-и.

[Mateev]

Според мене без OPC може само ако каналите с данни са сравнително малко и могат да бъдат обхванати от човешка намеса - може би когато са под 100 на брой. Тогава да, съгласен съм, че е достатъчно едно единствено exe на клиентския компютър. Опре ли обаче до логване на SQL сървър, това автоматично означава че вече е замесен даден компютър-сървър, и слагането на OPC на същия този компютър вече е детска играчка.

Колкото до парите - всичко е без пари, защото братята руснаци вече са се погрижили да разбият цялото секюрити на NI LabView и на целия Siemens софтуер, в това число и на WinCC.