Б) Склад програмного забезпечення АСУ ТП

Поняття «програмне забезпечення (ПЗ) АСУ ТП» охоплює сукупність всіх програмних засобів, що беруть участь у функціонуванні АСУ ТП. Спеціалістам по програмному забезпеченню відомо велике число елементів ПЗ і складна логічна схема їх взаємодії. Однак збільшена схема ПЗ АСУ ТП (рис. 2.8) виглядає досить просто і базується на тих поняттях, які були введені вище.

Рис. 2.8. Збільшена схема програмного забезпечення АСУ ТП

Природно, що основними елементами цієї схеми є програми і дані. Як було зазначено раніше, на пристрій виконання програм, окрім власне виконання команд, покладаються, по-перше, завдання, пов'язані з виконанням великої кількості програм по різноманітним регламентам, і, по-друге, функції підготовки даних до обробки. Зазначені функції в більшості сучасних систем реалізовані програмно (а не апаратурно) і являють собою частину програмного забезпечення АСУ ТП. Одну частину цього програмного забезпечення можна назвати «Управління програмами», а другу - «Управління даними». В документації на програмне забезпечення ЕОМ поняттю «Управління програмами» відповідає термін «Операційна система» (ОС). Функції реальних операційних систем значно ширші, ніж власне управління програмами. Однак інші можливості ОС орієнтовані на кваліфікованих програмістів і для розуміння функціонування ЕОМ в АСУ ТП нічого не додають.

Основні режими взаємодії ОС з програмами показані на рис. 2.9. На малюнку умовно показано, ініціювати (включати) в роботу програму А може тільки ОС. Вона ж дізнається про завершення її виконання. Причинами для включення програми можуть бути наступ заданого моменту часу (наприклад, 14 год. 16 хв.), закінчення заданого інтервалу (періоду) тривалістю Т, надходження вимоги оператора.

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

Рис. 2.9. Взаємодія програм з операційною системою і між собоюAlpha

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

Поняттю «Управління даними» в сучасних ЕОМ відповідає програмне забезпечення, іменоване «Система управління базою даних» (СУБД). Основним завданням СУБД є організація збереження даних в пристроях пам'яті декількох видів і видача функціональним програмам даних в тій формі, в якій вони потрібні для обробки. Роль СУБД останнім часом значно зросла. Це пов'язано з тим, що забезпечити інформаційний взаємозв'язок десятків програм в АСУ ТП дуже складно. Збільшені дані можна розділити (рис. 2.10) на локальні (для однієї програми) і глобальні (загальні для декількох програм). Такий розподіл дозволяє раціонально обслуговувати кожний вид даних; зокрема, воно дає можливість програмісту програми А не знати про даних програми В; дані можуть зберігатися в пам'яті того виду, який по швидкості доступу (тобто читання і запису) відповідає вимогам, що пред'являються до програм А чи В.

Рис. 2.10. Локальні дані програм і глобальні дані АСУ ТП

Зазвичай СУБД (як і операційна система) володіють набором функцій, якими можна скористатися, звертаючись до СУБД з програми або з пульта оператора. Типовими функціями є:

оголосити про існування нового елемента даних, повідомивши його ім'я і технічні характеристики, що дозволяють СУБД відвести для нього місце;

дізнатися значення елемента по його імені;

змінити значення елемента;

дізнатися характеристики елемента даних (тип, місце зберігання, достовірність).

Рис. 2.11. Схема зв’язку оператора з даними

Ще однією частиною програмного забезпечення АСУ ТП (див. рис. 2.8) є програми, що обслуговують зв'язок людей з операційною системою і з даними. Цей розділ програмне забезпечення має велике значення в АСУ ТП, так як в роботі системи управління бере участь людина. Схема зв'язку оператора з даними показана на рис. 2.11. Для представлення даних операторам в АСУ ТП є великий набір технічних засобів: друкуючі пристрої, дисплеї, мнемосхеми і т. д. Так як з АСУ ТП взаємодіють люди різних спеціальностей і різного рівня знань в області ЕОМ і програмування, то до програм зв'язку операторів з операційною системою і з даними пред'являються різноманітність вимоги зручності спілкування людини з ЕОМ.

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

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

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

У § 2.3 було наведено приклад алгоритмізації задачі регулювання температури теплообмінника. Продовжуючи розгляд цього прикладу, припустимо, що на етапі програмування в результаті структуризації цього алгоритму виникло п'ять програм (табл. 2.1), між якими розподілився весь алгоритм. Кожна з цих програм по-своєму взаємодіє з операційною системою: має свій пріоритет, режим виконання і періодичність виклику. В описуваному прикладі чотири програми (П1, П2, ПЗ і П4) працюють (виконуються) періодично, а програма П5 на вимогу оператора. Взаємодія між зазначеними програмами за викликом відсутня, тобто одна програма не викликає іншу. Однак інформаційний взаємозв'язок між програмами з передачі даних існує (табл. 2.2). Елемент даних може бути для програми вхідним чи вихідним.. Перше означає, що програма використовує результат обробки іншої програми, а вихідними є дані, одержувані в результаті виконання даної програми.

З табл. 2.2 видно, наприклад, що значення витрати пара розраховується в програмі П1, а використовується програмами ПЗ і П5.

Ще раз відзначимо, що в багатьох випадках не існує однозначної відповідності між розподілом алгоритму на етапі алгоритмізації на підалгоритми або укрупнені блоки і діленням того ж алгоритму на частини, що виділяються в самостійні програми при структуризації програм. Для ілюстрації сказаного на рис. 2.12 показана укрупнена блок-схема програми П1. Вона об'єднує в собі блоки А1 і А2 укрупненої блок-схеми підалгоритма А, показаного на рис. 2.5.

г) Проектування й виготовлення програмного забезпечення АСУ ТП

Ще 10-15 років тому, коли зароджувалося застосування ЕОМ для управління технологічними процесами, все по АСУ ТП розроблялося індивідуально для кожного об'єкта. У міру накопичення досвіду і розуміння вимог до ПЗ АСУ ТП розвивалася уніфікація окремих елементів ПЗ. Сучасний стан проблеми створення ПО АСУ конкретними об'єктами можна охарактеризувати таким чином.

Операційні системи. Випущені нашою промисловістю ЕОМ для АСУ ТП (наприклад, типів М-6000, М-7000, СМ-1, СМ-2, СМ-3, СМ-4) поставляються з набором операційних систем. У відповідності з вимогами, що пред'являються в конкретній системі управління до складу пристрої ЕОМ та регламенту виконання програм при проектуванні АСУ ТП, вибирається та чи інша ОС з безлічі можливостей.

Система управління базою даних. Уніфікація СУБД для АСУ ТП в даний час не завершена. Поряд з використанням СУБД, наявних у складі ПЗ ЕОМ, для окремих об'єктів (або груп об'єктів) продовжуються розробки індивідуальних СУБД. По-видимому, в найближчі роки буде створено набір СУБД, що дозволяє скоротити індивідуальні розробки і використовувати в більшості випадків готові рішення.

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

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

Процес розробки і виготовлення ПО АСУ ТП є дуже трудомістким і відповідальним. У цьому процесі широко використовуються можливості ЕОМ для автоматизації окремих етапів робіт. Наявність трансляторів дозволяє вести програмування окремих модулів на тій чи іншій мові програмування. Програма генерації ОС дозволяє скомпонувати (забезпечити) для конкретного об'єкта потрібний набір функцій операційної системи. Є засоби генерацій функціональних програм з окремих модулів і ін Схема виготовлення програмного забезпечення АСУ ТП показана на рис. 2.13.

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

Роботи зі створення функціональних програм проводяться в два етапи. На першому етапі створюється необхідний набір програмних модулів, а на другому здійснюється збірка (компонування) функціональних програм з модулів. Для виготовлення модулів використовуються мови програмування (Асемблер, фортан, АЛГОЛ, Кобол) і відповідні транслятори. Використання модуля на другому етапі припускають наявність відомостей про модуль. Ці дані зазвичай оформляються у вигляді так званих паспортів, які, по-перше, містять характеристики модуля в цілому: ім'я модуля, тип ЕОМ і операційної системи, для яких він призначений, число параметрів на будівництва і т. д. По-друге, паспорти відображають характеристики кожного параметра настройки: призначення (вхідний або вихідний), тип (цілий, речовинний або символьний) і т. д.

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

Роботи з формування бази даних включають в себе етапи проектування структури даних, форми вхідних документів, тобто форм бланків, на яких будуть записані дані, власне заповнення бланків, контроль даних та їх завантаження в ЕОМ.

До недавнього часу, як правило, в якості інструментальної машини використовувалася та ж ЕОМ, що і в якості об'єктної, наприклад М-6000, М-7000, СМ-1 та ін. Однак в останні роки різко зросла (і продовжує рости) число розроблюваних АСУ ТП. Накопичений досвід розробок показує, що більшу частину підготовчих робіт з виготовлення ГЮ можна виконати не на об'єктної, а на універсальній ЕОМ середньої або великої потужності, наприклад, типів ЕС-1022, ЄС-1033, М-4030 та ін Це дозволяє підвищити продуктивність праці фахівців науково-дослідницьких і проектних організацій.

2.5. ПЕРСПЕКТИВИ РОЗВИТКУ «ІНДУСТРІАЛЬНИХ» МЕТОДІВ СТВОРЕННЯ МАТЕМАТИЧНОГО І ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

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

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

На основі узагальнення даних по вже існуючим і проектованим АСУ ТП створюється алгоритмічна структура узагальненої системи. При цьому існуюча раніше монолітна документація по математичному забезпеченню конкретних АСУ ТП (образно висловлюючись, їх «алгоритмічні портрети») розчленовується на окремі, функціонально закінчені елементи - 80 алгоритмічні модулі (монолітний «алгоритмічний портрет» даної АСУ ТП При цьому замінюється «мозаїчним портретом»). Отримані шляхом узагальнення досить численних розробок конкретних АСУ ТП алгоритмічні модулі сортуються, і на їх основі створюється типова алгоритмічна база АСУ ТП (формується як би абстрактний мозаїчний «алгоритмічний портрет» узагальненої АСУ ТП). Така алгоритмічна база в даний час створена в вигляді збірників алгоритмічних модулів, типових для АСУ ТП провідних галузей промисловості. В алгоритмічній базі АСУ ТП, утвореною всією сукупністю алгоритмічних модулів, можна виділити «загальнопромислове ядро», в яке входять алгоритмічні модулі, що повторюються в більшості АСУ ТП незалежно від їх галузевої приналежності.

Алгоритмічна база АСУ ТП є основою для побудови відповідної програмної бази АСУ ТП, створюваної у вигляді єдиної бібліотеки програмних модулів (або сукупності таких бібліотек за галузями промисловості). Структура програмної бази відповідає структурі алгоритмічної бази АСУ ТП: алгоритмічному модулю (або їх окремої групи) відповідає один або кілька програмних модулів. Образно висловлюючись, будується «мозаїчний програмний портрет» узагальненої АСУ ТП, повторюючий риси «алгоритмічного портрета», і хоча окремі елементи алгоритмічної та програмної «мозаїк» можуть строго не збігатися, «програмний портрет» в цілому є відображенням «алгоритмічного портрета». Загальна схема програмної бази повторює схему алгоритмічної бази АСУ ТП, тому першою (і найбільш важливою) завданням є побудова загальнопромислового «ядра» програмної бази. Програмна база АСУ ТП створюється відразу на машинних носіях у вигляді бібліотеки, забезпеченою сервісними програмами, що дозволяють здійснювати введення. Редагування і заміну програмних модулів, встановлювати зв'язки між ними, здійснювати документування і т. д.

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

Слід зазначити специфіку задачі автоматизації процесу підготовки ПЗ АСУ ТП. Оскільки АСУ ТП надзвичайно різноманітні (переважна більшість їх відрізняється один від одного функціональної, алгоритмічного, технічної та іншими структурами, тобто практично не зустрічається строго однакових АСУ ТП), відповідно різноманітні і конфігурації їх програмних комплексів. Тому завдання автоматизованої генерації ПО не схожа на задачу, вирішувану автоматичної потокової лінією при масовому виготовленні однотипних деталей або їх складанні у однакові вироби. Скоріше це аналог задачі, розв'язуваної верстатами з числовим програмним керуванням (ЧПК). Аналогічно тому, як верстату з ЧПК можна задати програму виготовлення потрібної деталі (і потім верстат відпрацює завдання), системі генерації можна задати програму збірки функціональної програмної системи, відповідну функцій проектованої АСУ ТП і прийнятої конфігурації її УВК; система генерації при цьому здійснить збірки СПО проектованої АСУ ТП і узгодження її із заданою ОС.

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

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

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

Загальна схема функціонування САПР математичного забезпечення (МЗ) та програмного забезпечення (ПО) наведена на рис. 2.14 Початкове завдання на проектування вводиться в систему за допомогою підсистеми формалізації завдання з пульта інженера-проектанта. Базою САПР є банк даних і методів (БДМ), в якому зберігаються бібліотеки алгоритмічних і програмних модулів, а також програмні реалізації математичних методів, використовуваних при аналізі, дослідженні та налаштування алгоритмів і програм АСУ ТП.

Система автоматизованого проектування дозволяє вирішувати наступні завдання:

1) за заданою у технічному завданні (ТЗ) функціональній схемі проектованої АСУ ТП формувати її алгоритмічну структуру з набору алгоритмічних модулів, що зберігаються в БДМ; при необхідності формувати відсутні алгоритмічні модулі з математичного опису відповідної задачі, запроваджуваному в систему інженером-проектантом (при цьому одночасно проводиться доповнення бібліотеки алгоритмічних модулів в БДМ);

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

3) проводити аналіз, відпрацювання та апроксимацію спроектованої алгоритмічної структури АСУ ТП для подальшого формування робочої моделі програмного забезпечення АСУ ТП;

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

5) здійснювати настройку робочої програмної моделі проектованої АСУ ТП і перевірку її функціонування;

6) здійснювати документування спроектованих алгоритмів і програмного забезпечення АСУ ТП.

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

Дата добавления: 2015-07-18