Передмова

           Існуючі в наш час системи графічного програмування - це інструментальні засоби, які дозволяють розробляти прикладне програмне забезпечення для  контролерів систем автоматики не прибігаючи до традиційного програмування.  Саме в області АСУ ТП  вони досягли найбільшого свого розвитку,  ставши  невід'ємною складовою частиною  так званих  SCADA- (Supervisory Control And Data Acquisition)  і   SOFTLOGIC систем.

         При традиційному програмуванні алгоритм керування, розроблений програмістом, реалізується шляхом написання їм послідовності програмних операторів. При цьому мається на увазі, що сам алгоритм попередньо був накиданий програмістом на аркуші паперу або хоча б уявлений у голові. Ідея Графічного Програмування полягає в тому, що алгоритм малюється не на папері, а  на екрані дисплея. Таким чином, розробка програм керування  полягає в “зборці” алгоритмів керування з готових “кубиків” – функціональних блоків – у середовищі графічного редактора. 

           Головною метою, при створенні таких інструментальних засобів, переслідується ідея створення   керуючих програм  для систем автоматики без участі самих програмістів.    

Чим  викликана така немилість?

Справа в тому, що найдавнішою мрією проектувальників АСУ ТП була думка про єдину специфікацію проекту в ланцюжку "замовник-технолог-програміст". Її рішення дозволило б представникам  різних  професійних груп -  Замовникові,  Технологові й Програмістові - однозначно розуміти один одного.

Як  же обстоять  справи  зараз?

Результатом спільної роботи замовника з технологом є якийсь  алгоритм, представлений у вигляді графічного малюнка або словесного опису - що виступає основою документа, називаного технічним завданням, що скріплює печатками організацій. Програмістові необхідно проробити неформальну операцію перекладу цього документа в мову машинних кодів - програмного продукту надаваного замовникові.

От отут-те  й починаються всі лиха. У більшості випадків перехід від алгоритмізації до програмування представляє певну проблему. Програмістові доводиться додумувати, як представити її обчислювачу на зрозумілому йому мові - мові програмних кодів. Власне кажучи  виходить,  що  програма  відображає те, як програміст  зміг зрозуміти вихідний алгоритм.   В остаточному підсумку,  з'являються два алгоритми: один на папері, для звітності й документування проектних рішень,  а  другий - у  лістінгу програми. 

Найчастіше виходить так, що граф алгоритму, розробленого програмістом, не збіжиться із  графом вихідного алгоритму. Інакше кажучи, графи виявляться неізоморфні. До чого це може призвести? - до того, що "місцями" програма,  розроблена програмістом,  може працювати не так,  як  то  було задумано технологом.  У чому це виражається? - у загублених  космічних  кораблях (радіоантена якого помилково була наведена  не в ту сторону),  висаджених  у повітря  цехів заводів та фабрик  і  т.д./т.п.

З  іншого  боку,  програмування, незважаючи на свою масовість, залишається  мистецтвом. Інакше кажучи, кожен програміст програмує так, як уміє.  На сьогоднішній  день всі спроби повністю формалізувати або автоматизувати процес написання програм виявилися неспроможними. Тому  ступінь витрат  часу  й  засобів,  виділених  на  проект,  перебувають  у   прямої  залежності  від    здатностей  й  амбіцій  програміста.

До того ж, Він виявляється єдиним утримачем найважливішої логічної інформації й людиною, здатним розібратися  у  своєму  утворі й від якого, в остаточному підсумку, залежить доля всього проекту. Нема чого вже й говорити про випадок,  коли людина  може просто звільнитися в розпал проекту.

Крім горезвісного "людського фактора" існує інший, не менш грізний, - це лавиноподібний ріст програмного коду в програмних продуктах, пов'язаний з ростом функціональної складності алгоритмів керування. Тому усе більше зусиль потрібно від розроблювача на написання й налагодження коду, залишаючи менше сил і часу на  пророблення  самого  завдання й оптимізацію.  Сам же  процес  виправлення помилок усе більше нагадує латаниє дір. 

Згідно даним звіту  Національного інституту по стандартах і технології, обсяг економічних втрат через помилковий ПО тільки в США досягає декількох мільярдів доларів у рік, що становить близько 1% національного валового внутрішнього продукту.  (Research Triangle Institute, NIST Planning Report 02-3, May 2002). 

Сучасні SCADA  системи - чи  все так добре?

У наш час серед IT- фахівців широко розповсюджена  думка,   що  поява всякого роду SCADA- і SoftLogic  систем дозволило дозволити  згадані  вище проблеми.  

 Насправді все  далеко не так. 

 Хоча кожна така система може й не зажадати глибоких знань апаратного забезпечення контролерів, однаково - це  досить складні системи, що вимагають чималих зусиль  і  часу на освоєння.  Це томи документації, і знову ж  мови програмування, нехай й іншого толку, наприклад -  послідовних функціональних схем, релейної логіки, функціональних блокових діаграм.  Та й від універсальних мов (BASIC, C, Pascal)  ще ніхто не відмовлявся.  Більш того, будь-який поважаючий себе програміст при розробці серйозної АСУ  ТП  віддасть перевагу саме  універсальним мовам, оскільки  графічне проектування поки ще залишається  більше  іграшкою  й  гарним рекламним упакуванням   існуючим системам  проектування.

Таким чином,  ще рано говорити,  що за такі системи  вже можна посадити безпосередньо  технолога. А значить ще рано говорити, що сучасні засоби графічного програмування  вже дозволяють розробляти єдину (наскрізну) проектну документацію для ланцюжка: "замовник - технолог - програміст".

Не зайва річ також буде згадати, що успішне впровадження  таких систем  практично неможливо  без попередньої закупівлі у фірм-постачальників  дослідницьких полігонів,  інтеграція  яких намічається на об'єкті. У противному випадку є ризик одержати непрацездатну систему або, як мінімум,  неоптимізовану.

До функціональної складності варто додати ще й проблему ресурсів. Адже для більшості відомих систем потрібні ресурси PC, що в умовах промисловості автоматично припускає використання дорогих промислових комп'ютерів,  а не  більш  дешевих  мікропроцесорних контролерів.

Не слід забувати також про проблему мультипроцесорної обробки, коли  всю "графіку" доводиться відкладати убік і вручну приступати до проектування інтерфейсів міжпроцесорного обміну. А, полазивши по Всесвітній Мережі, ми виявимо численні матеріали, що свідчать на користь того, що проблема ця в цілому ще далека від остаточного  розв'язання навіть на теоретичному рівні.

Для того ж,  щоб повніше побачити переваги системи графічного програмування,  побудованої на принципах схемної емуляції,  у  порівнянні з   величезним  числом  вже відомих  на  сьогодні  систем,   необхідно розібратися - а в  чому ж  полягає  ідеологія  роботи  останніх?

А для цього,  насамперед,  треба чітко усвідомити, що будь-яка відома Система  Графічного Програмування  будується на трьох китах:  графічному редакторі (редакторі малювання схем), графічному  компіляторі  й  системи  виконання.

Що стосується  редакторів малювання, те отут проблем начебто  б немає:  навіть спроектувати таку "штуку"  під силу  практично будь-якому  програмуючому студентові (правда, який  вчиться,  а не  стоїть  в черзі за дипломом).

А от графічні компілятори - речі набагато  серйозніші. 

В "обов'язку"  цієї компоненти  входить  перегляд  графічного  малюнка  проекту  й  генерація  вихідного коду програми,  що  інакше  програмістові  довелося  набирати  б  "ручками".   Потім вихідний  код  компілюється  в  деякий проміжний код.  Вся ця робота виконується  програмістом  на  робочій  станції  (ПК).

Після цього  файл проміжного коду  вже можна завантажувати  у  вбудовуємий  контроллер.  Туди ж завантажується  й  спеціальний  інтерпретатор проміжного коду – система  виконання.

          Для  чого потрібний проміжний код?  Так лише для того,  щоб максимально спростити  інтерпретатор  (систему виконання).  Робиться це з єдиною  метою -  мати  можливість  "всунути" її  в  яку-небудь  мікропроцесорну  платформу.

У світлі сказаного стає зрозумілим,  що принципової різниці між SCADA системами  й звичайними системами візуального програмування, такими як DELPHI, Visual C, Visual Basic (і ін.)  немає.  Тому як в  обох випадках  вихідні тексти програм генеруються по візуальних компонентах,  що були використані в проекті.    

Класичним прикладом сказаному може бути  всенародно відома програма IsaGRAF   (від ICS Triplex ISAGRAF Inc.).  Тут  при компіляції файлу графічного проекту генерується проміжний, так званий TIC-код, що потім  завантажується у вбудовує контроллер, що. Туди ж довантажується т.зв. TIC-інтерпретатор,  що  і виконує функцію  системи  виконання.

 У  не менш народній  програмі  LabVIEW (від National Instruments)  згенеровані вихідні тексти  кодуються в так званий проміжний G-код, що потім інтерпретується (виконується) безпосередньо на  PC  із середовища LabVIEW.

Можна виявити чітку аналогію, що TIC-інтерпретатор для TIC-коду, це те ж саме, що середовище LabVIEW для G-коду.  Різниця полягає тільки в тім, що LabVIEW у вбудований  контролер  не вмістиш,  а TIC-інтерпретатор - можна!

Справедливості заради, слід зазначити, що такого "фокуса" імовірно з легкістю могли б досягти й розроблювачи  LabVIEW,  досить їм тільки реалізувати можливість вивантаження у керуючу систему (контролер) G-інтерпретатор, що поки "намертво" вбудований у саме середовище. І мені доводилося навіть чути,  що в останніх версіях програми  ця  функція  навіть  вже реалізована.

На таких же принципах побудована  широко відома  SCADA   Delta V.

Паралельно вище розглянутої ідеології існує трохи відмінна, що  полягає в тім,  що  ще на етапі роботи графічного компілятора  генерується не проміжний код,  а  виконавчий відразу, котрий  і завантажується в  промисловий комп'ютер.  Правда говорити, у цьому випадку, про систему виконання  не доводиться, оскільки  в цьому випадку вона підмінюється  т.зв. середовищем виконання - "залізо"+операційна система,  для чого,  щоправда,  вже  потрібні  ресурси  PC.

 Така ідеологія,  як правило,  також  пропонується  відомими  системами  графічного програмування. 

В LabVIEW  для цього є  додаток Application Builder for LabVIEW,  що дозволяє згенерувати оптимізованый код,   подібний програмному коду C-компілятора. Такий   код ще  прийнято  називати - RUN-TIME модулем.

Система IsaGRAF також дозволяє проводити генерацію звичайного C-вихідного  коду, відкомпілювавши  який  звичайним C-компілятором ми одержуємо "класичний"  RUN-TIME модуль.  

 Ідея  RUN-TIME  модулів знайшла застосування й в інших системах класу HMI  й  SCADA, наприклад в LookOut for Windows, (тієї ж фірми). А також широко відомої  UltraLogic (UltraLogic), в  якій файл, що виконується  розташовується в  PC-сумісних контролерах типу ADAM.

Аналогічно, яку б іншу систему ми далі не  розглядали -  ми побачимо всі те ж саме.

Не  є виключенням і програмування мовою сходових діаграм (LD) для всіх відомих лінійок  ПЛК   - MODICON, Siemens,  Allen-Bradley  й  ін. 

А все по одній простій причині:   ні інтерпретацію, ні компіляцію в програмуванні поки ще ніхто не скасовував. 

От чому ідеологія  всіх сучасних SCADA – SOFTLOGIC систем заснована на  прагненні  їхніх розроблювачів від графіки перейти до звичайних програмних кодів, чим автоматично викликається до життя  увесь той геморой, яким страждає програмування як ідеологія. Проте,  незважаючи на те, що  тема ця  вже з області проблем, властивим  самим  компіляторам/ інтерпретаторам -  у  наступних параграфах  її  доведеться  торкнутися  в  мінімально-необхідному обсязі.

Справедливості заради відзначу, що в доповненні до двох вище розглянутих ідеологій, розроблювачі системи MasterSCADA (фірма ИнСАТ, м. Москва) якийсь час назад запропонували третій, "оригінальний" шлях: на мікропроцесорній платформі, що вбудовує, розташували не символьний інтерпретатор проміжного коду (як в усіх) , а безпосередньо графічний інтерпретатор... і навіть заявили мені, що це і є та сама емуляція, ідею  якої я так завзято популяризую вже котрий рік поспіль.

На це можу відповісти,  що людині,  яка уважно прочитала усе вище написане мною, імовірно, не важко буде зрозуміти, що всі ці комбінації із компілюючими/інтерпретуючими компонентами скоріше нагадують совання кроватями в публічному будинку. Але ж ще років тридцять тому назад  мій дід роз'яснив  мені,  що якщо в публічному будинку падають доходи - те не кроваті треба совати, а міняти керівництво. Ідея схемної емуляції саме  і є той новий керівник для вбудовуючих мікропроцесорних платформ!

У  той же час,  присутність мов програмування, а також компіляторів/інтерпретаторів у відомих системах графічного програмування  робить такі системи досить складними й дорогими продуктами. Ну як, приміром, LabVIEW prof можна вважати "настільною" системою інженера, якщо в Москві за неї "просили"  4900$ (2005 рік), а в Києві - 7000$ (щоправда ще три роки тому це було аж 10000$,  так  що   прогрес звичайно спостерігається!).

Що ж говорити про системи рівня Delta V? Ясно, що всі вони розраховані на автоматизацію заводів і фабрик, але ніяк не на рівень малих впроваджувальних фірм і тим більше рівень приватного підприємця. Про вартість "заліза" до таких систем я взагалі мовчу. Можна  тільки  представити  скільки сотень мільярдів доларів "крутиться" по усьому світу в сфері впровадження АСУ ТП. Це, звичайно ж, не може не подобатися самім впроваджувальним  фірмам. А куди подітися замовникам? Так нікуди! Ну, щось ненабагато дорожче, щось  - дешевше, але в цілому альтернативи    однаково немає!

Якось працюючи на одній малій фірмі, що спеціалізується на автоматизації виробничих процесів мені "пощастило" спостерігати спробу  автоматизації лінії по виробництву макаронів на  ADAM-ах. Порахували, розплакалися... і впровадили "самопальні" контролери на основі мікропроцесорів MSC-51. І дешево вийшло, і сердито.

Система графічного програмування, в основу якої покладений принцип схемної емуляції, саме й надає унікальний шанс відмовитися від  вихідних кодів, а значить і від компіляції/інтерпретації також.

 

Принцип схемної емуляції  лежить тільки в основі системи  виконання   нового типу (скажемо так).   Це   дозволяє досягти відразу двох  важливих  моментів: 

   перший –  таким компонентам,  як  "графічному компілятору" (кит  №2)  та   інтерпретатору (кит №3)  -   у новій ідеології  місця немає! Що, у свою  чергу,  веде  до   разючого спрощення всієї  системи  в функціональному плані, а  значить і ціновому.  Такій системі не потрібні потужності PC.  Вона проста в  освоєнні  навіть для "чайників"   (якими є, приміром, ті ж технологи);

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

         Все  що написано нижче - служить меті  роз'яснення  цих двох моментів.

 

Що таке схемна емуляція?

Отже,  в основі нової ідеології лежить авторська "програма Схемної Емуляції".  Що варто розуміти  під  цим словосполученням?  Адже будь-який электронщик  заперечить,  що  немає в природі програм такого класу,  і  він буде абсолютно правий.

Відомі так звані   програми-сімулятори, такі як  Micro-CAP від "Spectrum SoftWare",  PSpice  від  "MicroSim Corp."  і т.п.  Ті,  що в радянську епоху  в нас прийнято було називати програмами моделювання  електронних  пристроїв. 

Уточнюся відразу, програми схемної симуляції традиційно діляться на дві групи:  моделювання аналогових пристроїв і моделювання дискретних, простіше говорячи, цифрових пристроїв.  Математичний  апарат моделювання аналогових пристроїв, на мій погляд, навряд чи торкається до  завдань,  які  можна віднести до предмета даної статті, тому надалі  розглядатися мною не буде. Якщо ж чийсь допитливий розум догляне корисність й у даному класі програмних  продуктів - ну що ж, з  інтересом почитаю й Ваші міркування.

Поки ж я буду апелювати винятково до  систем  моделювання  дискретних   пристроїв.  Алгоритми, які використовуються в основі програм моделювання таких пристроїв - тема самостійна й досить цікава. Про це написано досить велику кількість книжок (навчальних посібників) і якщо хтось все це у свій час пропустив, є  сенс  все-таки звернутися до відповідної літератури для усунення пробілу в знаннях, хоча б через більш повне розуміння суті  освітлюваної  в цій статті   ідей.

Більш точно такі програми  називалися  "програмами логічного моделювання дискретних пристроїв".  Були ще програми фізичного моделювання, що перевіряють навантажувальну здатність кожного виводу мікросхеми, струмів витоку, паразитних  ємностей і т.д.  Але програми такого класу не мають відношення  до предмета даної статті, по одній простій причині:  алгоритми, які ми збираємося надалі емулювати, якими б складними вони не були,  завжди  будуть залишатися  програмними моделями,  а  в  програмної моделі не буває ні струмів витоку, ні паразитних ємностей.

Історично сімулятори з'явилися у відповідь на законне бажання розроблювачів цифрових пристроїв - перевіряти роботу спроектованої схеми ще до того, як вона буде реалізована за допомогою паяльника. Адже не дуже приємно  знову й знову за нього братися, щоб виправити помилки, допущені на етапі проектування.  Але ж мова йшла про дослідницькі промислові зразки, що містили  до 70  і  більше  корпусів інтегральних мікросхем на платі.

Моделювання можна вважати виконаним правильно у випадку, якщо отримані правильні часові співвідношення між рівнями сигналів в абсолютно всіх ланцюгах пристрою.  Результатом  моделювання в кожному разі стане деякий  масив станів рівнів сигналів у ланцюгах  схеми, якому можна потім вивести на принтер або дисплей у вигляді графіків. 

Тільки такі графіки  відображають всю динаміку  змін сигналів у ланцюгах моделі, а не реальної схеми. Тому  можуть розглядатися як  "мертвий" відбиток подій у реальному пристрої, так до того ж сильно й сильно розтягнутим у часі.   За одиницю  умовної часової шкали  приймається затримка на тому компоненту схеми, якому згідно довідковим даними вона є найменшою.  Якщо ж  виразиться точніше - як правило, береться значення найменшого кратного для значень затримок сигналів для всіх типів компонентів.

Рівні вхідних сигналів програма моделювання крок за кроком "подає" на вхід програмної  моделі, вибираючи їх з так називаного масиву вхідних впливів.  Зрозуміло, що саме слово "масив" - це атрибут програмістських "штучок" і не має ні найменшого відношення до реальних сигналів.

Це і є моделювання!

А що ж тоді є емуляція? 

Емуляція – це імітація  поводження реального пристрою в режимі реального часу. Тут доречна аналогія "чорного ящика" -  умовно говорячи, дійсно ящика, на якому перебуває електричний роз'ом  для підключення реальних вхідних і вихідних сигналів від об'єкта керування.  При цьому зовнішній спостерігач не зможе сказати (не плутати з - угадати), що в цьому ящику перебуває:  реальний електронний пристрій або мікропроцесорний пристрій (ПК), на якому  в  режимі  реального часу  його  робота  імітується.

Тепер  уточнимо, - а що варто розуміти під  "режимом реального часу"?  У самому загальному випадку під цим варто розуміти випадок, коли швидкість імітації (емуляції) порівнянна  зі швидкістю зміни процесів у реальному об'єкті керування. Інакше кажучи, чи буде відгук (зняті  сигнали)  із програмної моделі  поспівати  за мінливими  процесами в  реальному об'єкті керування.

У нашому випадку можна дати й більше конкретне  визначення:   якщо швидкість емуляції буде порівнянна (і навіть вище) швидкості виконання програми  керування, що програміст звичайним способом написав би в  якості керуючої  для  даного  об'єкта – можна говорити про режим реального часу. 

Під "звичайним" способом мається на увазі  реалізація програмного циклу "зчитування сигналів з датчиків > обробка вхідних сигналів по певному алгоритмі > формування керуючих сигналів на виконавчі органи" на якій-небудь мові програмування.   Саме  в такий  спосіб пишуться програми для систем автоматики.

Тепер спробую показати: які умови треба виконати, щоб програму моделювання перетворити в програму схемної емуляції.  

Насамперед - про вхідні сигнали. 

Уже підкреслювалося, що в програмах схемної симуляції рівні сигналів, що подаються на програмну модель цифрового пристрою, крок за кроком вибираються з  так називаного масиву  вхідних  впливів.  Це означає, що "сигнали" які подаються на програмну модель  якого-небудь електронного пристрою мають не фізичну, а програмну природу.

Упевнен, що розроблювачам цих самих симуляторів, не склало б великих труднощів доповнити свої програми модулями стикування  із "зовнішнім світом". Для цього всього-на-всього треба  використати так називані порти комп'ютера. Завдання це абсолютно тривіальне, але це ще не перетворить  їхні  програми  на  емулятори.

Чому?  Тому що така програма повинна працювати ще й  і  у режимі реального часу.

От отут-те й починаються проблеми. Адже всі відомі на сьогоднішній день схемні сімулятори працюють винятково в умовній часовій шкалі, та  іншого від них поки й не вимагалося!  Це означає, що моделювання процесів, що протікають у реальному електронному пристрої за декілько мікро- або миллисекунд,  на  PC можуть досягати  декількох  хвилин.

Але представимо, що й цю проблему Ви  все-таки побороли. Це добре! Але й цього мало!  Чому?

         Тому, що  сучасним сімуляторам потрібні ще й ресурси ПК, та бажано ще і як можна більш сучасного. Під ресурсами варто розуміти обсяг дискового простору й обсяг оперативної пам'яті. Ну й, звичайно ж - потужність процесора.

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

          І, нарешті,  усяка  відома на сьогодні програма цифрового моделювання працює із двома  дискретними значеннями  рівнів логічних сигналів у ланцюгах схеми:   логічним  нулем (0) і логічною одиницею (1).  Але  на практиці,  в  самій звичайній   АСУ ТП,  ми маємо справу не тільки з дискретними сигналами, але й аналоговими.  Це можуть бути   сигнали, що, знімаються  з аналогових датчиків  (швидкість, оберти у хвилину, температура тощо).  Тому система повинна бути здатної виконувати змішане, аналого-цифрове  моделювання.

 

  Якщо Вам удалося створити програму, у якій дотримані всі перераховані мною  вище  вимоги,   то таку програму з усією справедливістю  вже  можна назвати  емулятором!  

Тут мені  хочеться відзначити, що метою даної статті є популяризація  ідеї  застосування принципів схемної емуляції в основі систем  графічного програмування, а не виклад  своїх власних алгоритмів.  Хоча особисто мені, у свій час, удалося реалізувати усе вище викладені ідеї в програмі, що назвав ПУЛЬС.

 Залишилося тільки відповісти на останнє запитання:  а який взагалі може бути зв'язок між програмою схемної емуляції   й   Системою  Графічного Програмування?

А вся справа тільки в тім, що розуміти під словом "схема". Адже це дійсно може бути принципова схема деякого електронного пристрою,  який апаратно реалізує деякий алгоритм керування. Але це може бути й безпосередньо функціональна схема алгоритму керування деякої системи: приміром, АСУ ТП, системи керування літальним апаратом,  алгоритму функціонування біологічної або фізичної моделі.

Це може бути малюнок  релейних  (LD) або  функціональних блокових діаграм (FBD).

Це може бути малюнок нейронної мережі, що стає усе більше популярної сьогодні  для систем АСУ ТП верхнього рівня  або  граф переходів цифрового автомата для випадку автоматного програмування.

Один мій знайомий, працюючи з ПУЛЬСом, віддавав перевагу реалізації алгоритмів керування  винятково  на цифрових компонентах:  йому, як колишньому цифровіку,  нічого не було миліше  й зрозуміліше рідних вентилів, лічильників,  тригерів і мультиплексорів.  І до того ж фантазувати можна без обмежень: плати  ж  за компоненти не потрібно  було – бо  вони всі віртуальні!

Емуляція принципових схем - це, звичайно, окремий випадок. Хоча ніщо не забороняє користувачеві реалізовувати алгоритм керування шляхом проектування електронної схеми, просто даний приклад наочно демонструє всю міць методу.

         Тому можна сказати, що вид графічного програмування  (метод  проектування малюнка) буде визначатися  тільки тим, якими компонентами із загальної  бібліотеки компонентів системи  Ви будете користуватися.

         Головне, щоб ці компоненти вже входили в так називану бібліотеку компонентів.  Фірма, що займається супроводом такої системи,  природно, повинна буде постійно відслідковувати питання  розширення бібліотек  компонентів для різних областей, і   передбачити  можливість їхнього завантаження з фірмового сайту.

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

До думки про використання алгоритму схемотехнічного моделювання в основі системи виконання мене  підштовхнуло (у тому числі) – і зовнішня подібність графічних проектів: ті ж "квадратики", "ромбики"…і безліч ліній  (ланцюгів), що з'єднують між собою компоненти  малюнка. 

От і народилася ідея,  навіщо ж малювати алгоритм керування (наприклад), щоб потім так над ним "поглумитися"? - розробляти спеціальні графічні компілятори, щоб от так відразу взяти й знищити всю графіку, перетворивши її у файли якихось (TIC,G й ін.) кодів. А потім ще розробляти компілятори або інтерпретатори, які почнуть розшифровувати всі закодовані інструкції, що перебувають у цих файлах і крок за кроком виконувати на цільовій системі (контролері).

Адже давньою мрією розроблювачів програмного забезпечення була та, щоб програми працювали так само надійно, як електронні пристрої. Схемна емуляція саме й дозволяє розглядати програму (представлену в графічному вигляді) як  схему, але в той же час дозволяє "не братися за паяльник", а просто імітувати її роботу за допомогою програми схемної емуляції.

 

           Універсальна  эмулююча платформа    

Отже, система графічного програмування, побудована на принципах схемної емуляції, складається  тільки  із  двох основних компонентів:  графічного редактора  та  системи виконання, робота якої  саме і заснована на принципах схемної емуляції. 

Ідея  використання графічного редактора рівно нічим не відрізняється  від уже відомих систем. Процес проектування якої-небудь системи керування виглядає звичайно:  з бібліотеки компонентів  вибирається  графічний образ якого-небудь компонента й переноситься на робочу область малюнка графічного редактора.  Потім компоненти з'єднуються між собою необхідними ланцюгами (лініями зв'язку).  От і всі "програмування"!

Графічний компілятор (кит №2) у такій системі відсутній, оскільки в генерації яких-небудь кодів й  у  подальшої  їхньому  компілюванні  необхідності немає.

Замість цього в графічному редакторі використається програмний модуль, що  "переглядає"  графічний  малюнок проекту й по ньому формує так званий  "Файл Опису Проекту" (ФОП) - звичайний текстовий файл, що  містить усього лише список  всіх ланцюгів (ліній зв'язку) графічного проекту якої-небудь системи керування. 

У принципі, все   так само, як це робиться в будь-якому програмному симуляторі.

Потім файл ФОП  необхідно завантажити у  вбудовану мікропроцесорну платформу по мережі або через спеціальний порт.

 Оскільки кожен компонент,  використовуваний розроблювачем у проекті,  крім графічного образа  в середовищі графічного редактора має ще  й програмний модуль  у  середовищі  виконання, - те  всі  задіяні  в  проекті  модулі  необхідно також  завантажити  у  контролер.

А от  в  якості системи виконання (кит №3) використовується програмний модуль схемної емуляції,  що доцільно попередньо розмістити в постійній пам'яті мікропроцесорної   платформи. 

На самому початку своєї роботи модуль емуляції "переглядає"  ФОП й, використовуючи коди готових програмних бібліотечних модулів компонент малюнка,  розвертає в оперативній пам'яті  контролера   програмну модель  системи  керування.

Вхідні впливи для такої моделі  знімаються з реальних датчиків АСУ ТП, а відгук із програмної моделі подається на реальні виконавчі пристрої через порти платформи.

Всю бібліотеку компонентів, використовувану в середовищі графічного редактора на етапі проектування малюнка проекту, можна умовно розбити на два класи. До першого  відносяться  ті, які  відображають реальне встаткування: різні датчики й виконавчі органи, наприклад реле.  До другого – не мають "залізного" аналога. Це чисто функціональні елементи, такі як нормалізатори сигналів, частотні фільтри,  суматори, компаратори, логіка й т.д.

Тому,  якщо  на схемі проекту розроблювач використав графічний образ, приміром, датчика температури, те тоді потрібно не забути  підключити відповідний йому реальний датчик до  інтерфейсу  контролера.

Обсяг модуля емуляції становить менш 30 кбайт і тому він з успіхом може бути розміщений у емулюючій платформі.  Має сенс розмістити його в постійній пам'яті мікропроцесора,  закрити бітом таємності  й  продавати платформу як закінчений апаратно - програмний виріб.

Хочу відразу підкреслити, що для того щоб максимально оптимізувати  роботу модуля емуляції - необхідна спеціальна архітектура самої мікропроцесорної платформи,  що й дає всі підстави  дати їй назву  -   Эмулюючої.

Така платформа буде універсальної,  тому що по своїх цінових і функціональних можливостях, а також можливостям масштабування, вона буде годитися для використання  в  самому широкому спектрі областей: від лабораторного студентського  або  інженерного стенду – до АСУ ТП масштабу підприємства.

Принцип емуляції просто й ефективно підтримує ідеологію розподіленого  керування - DCS-систем (дослівно - розподілених систем керування) і мультипроцесорної обробки! Причому, зовсім не потрібна розробка яких-небудь програмних кодів для організації  міжпроцесорного обміну, розпараллєлювання  потоків,  їхньої синхронізації   й т.п. 

Реалізація эмулюючої платформи на основі недорогого мікропроцесора (наприклад, серії AVR) буде являти собою недорогий комерційний варіант, доступний самому широкому колу користувачів. Застосовувати її можна буде в тих системах  керування, де можливе застосування мікропроцесорів саме по собі, виходячи з умов зовнішніх електричних  перешкод і часу відгуку системи.

Не менш цікавим представляється варіант  "апаратної"  реалізації  алгоритму емуляції на основі мікросхеми програмувальної логіки - ПЛИСС для емуляції швидких  алгоритмів,  наприклад -  обробки сигналів  або  реалізації  швидкісних  обчислювачив (аналогів супер-ЦВМ).

Залишилася тільки справа за фірмою,  що візьметься  за   комерціалізацію  такого  проекту.

Принцип схемної емуляції дозволяє просто й ефективно організувати процедуру візуалізації протікають в отлаживаємій АСУ ТП процесів.  Для цього досить буде приєднати ПК до платформи на час налагодження. Візуалізація  може проводитися як у режимі реального часу, так й у покроковому режимі - у т.зв. режимі циклів.

Програма-візуалізатор, яка установлена на такому ПК,  буде  виконувати роль многоканального осцилографа, що дзеркально відображає рівні сигналів у відповідних  ланцюгах алгоритму керування АСУ ТП. 

Для випадку дворівневої (багаторівневої) АСУ ТП,  де наявність ПК оператора  передбачено по  штатній конфігурації,  візуалізатор   представляється  у  вигляді  картинок  технологічного процесу.

Контактний email: simula@ukr.net

Контактний телефон: 8(044) 543 36 07

Країна: Україна

Місто: Київ

Адреса: вул. Малишка 21-Б, кв.73

Фотографії: