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

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

Ще слід зазначити, що в даний час вже існує  велика кількість  систем графічного програмування,  які є неодмінній складовій так званих  SCADA-  Softlogic програм,  таких як  ISAGRAF,  LABVIEW,  Delta V  і ін.

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

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

Сам факт відсутності генерації яких-небудь кодів – служить джерелом величезних  переваг ідеї Емуляції перед  поширеними сьогодні  системами  компіляції і (або)  інтерпретації (Системами Програмування).

В той же час,  Know-how  пропонованої ідеї полягає в тому,  що  авторський Модуль Емуляції настільки малий (менше 30 кб),  що з успіхом може бути розміщений у вбудовуваній мікропроцесорній платформі спеціальної архітектури – якій я дав назву – Універсальна Емулююча Платформа.

Такий модуль має бути розміщений в постійній пам'яті мікропроцесора і  закритий від зовнішнього доступу бітом секретності.

Це дозволить продавати таку платформу як закінчений аппаратно-программний  виріб з необхідним набором утиліт для ПК: графічним редактором,  редактором компонент,  візуалізатором  процесів  і так далі).

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

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

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

Але це ще не все!

У моїх статтях присвячених  ідеї Емуляції  я провожу думку,  що  створення графічних схем  проектів  на рівні  схем алгоритмів (наприклад, на рівні FBD – функціональних блокових діаграм – мови найбільш високого рівня графічного програмування для Систем Програмування) на сьогоднішній день морально застаріло.

За допомогою  опису такого  рівня  звичайно можна  реалізовувати алгоритми управління  для  систем автоматики і АСК ТП,  але для  вирішення  нових завдань, що вже встали перед технікою,  наприклад таких як – проектування  нейронних мереж,  систем ухвалення рішень,  систем розуміння,  експертних систем (у справжньому розумінні цього слова, а не нинішніх "іграшок"),  машин без знань – і інших розділів  Штучного Інтелекту – годиться лише проектування на рівні Систем.

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

Можна сказати,  що Рівень Систем  по складності  відповідає  рівню  проектування  електронних  систем  на рівні  структурних   схем. 

Таким чином,  процес комерціалізації  запропонованої до розгляду ідеї  емуляції складається з етапів:

1)  "перепісати"  модуль емуляції під  вбудовувану  мікропроцесорну платформу;

2)    розробити   саму  платформу;

3)    розробити  всі  необхідні  утиліти  під ПК;

4)    організувати  виробництво  самих платформ,  плат  ввода-вивода ("апаратних кубіків") та "напрограмувати"  бібліотеку компонентів для сторонніх виробників   популярного   "заліза";

5)   запустити сайт,  присвячений цій всій тематиці; 

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

6)   велика користь бачиться мною,  якщо   емулюючу платформу  спроектувати не лише  у  варіанті  мікропроцесорного ядра – це для завдань автоматики, АСК ТП..., але і  у варіанті   ядра на  мікросхемі програмованої   логіки   (ПЛІСС) – для  серйозних швидкісних   застосувань.

Переваги  Системи Емуляції  перед  відомими  Системами Програмування.

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

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

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

На основі  Системи Емуляції  можна створити  найдоступніший для  користувачів  продукт; 

     Наприклад,  вартість лише базового пакету Labview на сьогоднішній день складає 1300 $,  вартість всіляких утиліт до неї – знаходиться в такому ж ціновому діапазоні. Вартість "заліза" – також розрахована  на досить "жирного клієнта",  якщо,  наприклад,  вартість  процесорної  плати з  елементами аналого-цифрового введення  Pci-7041 досягає  4252 $;

У  Системі ж Емуляції,  через  просту  функціональну її організацію (відсутність всякого роду систем компіляції і інтерпретації), – за пропоновані користувачам інструментальні утиліти – і грошей соромно брати!

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

Вартість  Емулюючої Платформи (простий  варіант з виконання ядра на мікропроцесорному кристалі)  передбачається на рівні всього декількох сотен доларів.  Вся  периферійна  номенклатура  повинна виконуватися  з розрахунку на вартість до 100 $.

Досягненню такої мети сприяє два чинники: 

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

Ці норми – прерогатива великих заводів і фабрик  рівня  корпорацій,  але ніяк не малого бізнесу!

б)  виробництвом "малоканальных"  апаратних систем  "ввIд-вивiд".  Як показує практика –  звичайному споживачеві украй  рідко потрібна,  наприклад,   відразу одна плата аж з  16-тью  аналоговими  каналами,  8-мью цифровими,  двома таймерами  і так далі.

До  нашого щастя,  ідеологія  крупних міжнародних корпорацій (наприклад, National      Instruments  -  в особі плати  Pci-7041) – якраз в  тому  і полягає,  щоб виробити як можна більш універсальну плату шляхом розташування  на ній, як периферію до  головного мікропроцесору,  як можна більшого числа  і  типів  каналів  “вводу-вивiду”.

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

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

Система Емуляції  дозволяє реалізовувати  просте масштабування  проектованої системи 

з  ефективністю  недосяжної  для  відомих  систем програмування;

Під масштабуванням  слід розуміти можливість  нарощування сумарної потужності системи емуляції  шляхом звичайного  додавання до неї числа однотипних плат – Універсальної  Емулюючої  Платформи.

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

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

За допомогою  опису такого  рівня  звичайно можна  реалізовувати алгоритми управління  для  систем автоматики та АСК ТП,  але для  вирішення  нових завдань, що вже встали перед технікою,  наприклад таких як – проектування  нейронних мереж,  систем ухвалення рішень,  систем розуміння,  експертних систем (у справжньому розумінні цього слова, а не нинішніх "iграшок"),  машин баз знань – і інших розділів  Штучного Інтелекту – підходить лише проектування на рівні Систем.

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

При створенні застосувань в Системі Емуляції  істотно підвищується надійність керуючої системи.

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

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

   Система Емуляції  дозволяє емулювати системи  із заздалегідь  невідомим алгоритмом поведінки;

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

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

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

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

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

 

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

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

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

Місто: Київ, 02192

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

Фотографії: