Система управления РБУ

(3.16) 
 
 
 
Діаметр критичного перерізу і зрізу каналу:

(3.17) 

 

4. СПЕЦІАЛЬНА ЧАСТИНА

4.1. Оспис середовища розробки  системи СКАДА.

 

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

Просто для кожної програми існує  своя ненульова вірогідність її прояву. Виявлення помилок в мікрокоді Pentium і в ПО марсохода NASA, а також і багато інших прикладів це підтверджують.

Чому ж ми можемо говорити про  те, що одна програма або сукупність програм є надійнішою, а інша менш ?

Що б спробувати знатися на цьому, давайте розглянемо два довільні фрагменти коди без різниці КТО написані і на якій мові програмування. Які ж питання можна поставити, що б скласти уявлення про їх надійність ?

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

Озброївшись цими нехитрими висновками, розглянемо архітектуру ОС спільного  призначення (GPOS):

 

Рис. 4.1. Архітектура ОС загального призначення.

 

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

Якщо ж узяти декілька десятків кілобайт коди, яка тестувалася впродовж багатьох років і помістити його в ядро, а всі останні драйвери і додатки винести в окремі процеси, захистивши адресний простір  кожного апаратними засобами захисту процесора, ми отримаємо ОС підвищеної надійності з мікроядерною архітектурою (рис 2) :

Рис. 4.2. Архітектура ОС QNX.

 

Одній з найперших і відомих  реалізацій системи з мікроядерною архітектурою є ОС РВ QNX, яка використовувалася для створення найрізноманітніших mission-critical застосувань, від систем управління озброєннями, до автоматизації ядерних реакторів (наприклад проект CANDU в Канаді).

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

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

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

Ну і звичайно, не можна не відзначити той факт, що QNX є ОС жорсткого реального часу, що володіє гарантованим часом реакції на зовнішні події, лежачим в субмикросекундной області. Так, високопріоритетний процес управління, витіснить в гарантованих 7-8 сотень Наносекунди будь-який інший, більш низькопріоритетний процес, наприклад СУБД, видасть дію, що управляє, і поверне управління перерваним процесам. Іншою особливістю QNX є черезвычайно низькі накладні витрати, в порівнянні з іншими ОС, що дозволяє обробляти в 4-5 разів більше тегов при рівній обчислювальній потужності.

Сетвиє комунікації в QNX можуть бути дубльовані, причому в різних  мережах.

Наприклад зв'язок на UTP/STP Ethernet може бути продубльована резервним каналом RS-232/RS-485.

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

Файлова система QNX стійка до збоїв і не руйнується при натисненні на Reset або пропажах живлення, що дозволяє використовувати апаратний сторожовий таймер, що перезапускає систему при аномальному перевищенні часу циклу (зависанні системи).

Все це робить QNX ідеальною платформою для Softlogic.

Більшість наведених вище ідей знайшли  своє віддзеркалення в S3, яка використовує QNX як платформи реального часу для реалізації завдань управління, а так само, при необхідності, відображення (HMI) і зберігання критичних даних в СУБД.

 

Широке поширення QNX в АСУ ТП стримують (1) необхідність купувати досить дорогі засоби розробки і (2) високі вимоги до кваліфікації розробника.

Завдяки SCADA/Softlogic S3 тепер про це можна не турбуватися. По-перше QNX зі всіма своїми ньюансами диспетчеризації і тонкого налаштування тепер прихована в "чорному ящику" контроллера, РС сумісного комп'ютера, модуля RISC (дивитеся повний, постійно поповнюваний список драйверів, і платформ). З таким контроллером можна працювати точно так, як і з будь-яким іншим, видалено завантажуючи і відладжуючи проект, не виходячи з єдиної IDE S3.

У других, завдяки оригінальним технологіям S3, Вам більше не потрібний компілятор і дорогі бібліотеки, що входять в комплект розробника, а ціна повністю легального QNX Runtime входить у вартість продукту, яка дуже конкурентоздатна.

Витісняюча багатозадачність з  гаранитрованными і дуже малими часом  затримки, одна з кращих в світі  реалізація диспетчеризації процесів, дозволяють безболісно на одному процесорі поєднувати завдання регулювання, аварійних защит, комунікацій, інтерфейсу оператора, і, навіть, СУБД. Іншою особливістю QNX є черезвычайно низькі накладні витрати, в порівнянні з іншими ОС, що дозволяє обробляти в 4-5 разів більше тегов при рівній обчислювальній потужності.

У результаті вартість системи на S3 може бути у декілька разів нижче, ніж при "класичному" контроллерном  підході, не поступаючись, а часто  і перевершуючи класику в зручності розробки і супроводу.

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

S3 завжди може відповісти на  питання, КТО винен в тій  або іншій нестандартній ситуації, оскільки протоколює всі дії  і оператора і системи.

S3 періодично зберігає знімок  всіх змінних в незалежній  пам'яті (Flash диску ) які можуть бути відновлені згідно заданій політиці в разі аварійного перезавантаження.

Зручність використання

• По справжньому інтегрована, єдина середа розробки завдань інтерфейсу і управління для Windows і не Windows операційних систем, таких як QNX, Linux, Solaris
• Єдине поле самореплицирующихся змінних (тегів) для гетерогенної мережі робочих станцій і контроллерів, що мінімально навантажує комунікаційні канали

Рис. 4.3. Схема взаємодії системи з технологічними процесами

 

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

Просте і інтуїтивно зрозуміле  створення і зміни змінних  з будь-якого редактора будь-якого  рівня АСОВІ ТП - там, де це зручно розробникові.

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

Сервер, що самоконфигурирующийся, OPC, який автоматично шукає контроллери і завантажує з кожного список тегов.

Зручний редактор технологічних мов MЭК 61131, що дозволяє створювати власні функціональні блоки на базі тих, що існують.

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

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

 

5 ОРГАНІЗАЦІЙНО-ЕКОНОМІЧНА ЧАСТИНА

5.1 Організаційна частина

5.1.1 Характеристика технічного рівня проектованої системи

 

Система керування – це пристрій, побудований на мікропроцесорній техніці, вхідними і вихідними сигналами  являється послідовність імпульсів  Меандра. Складовим елементом системи  керування являється система  контролю, яка може працювати незалежно.

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

Склад показників технічного рівня і якості проектованого  виробу обумовлені положеннями, які  приведені в ГОСТ 22.851-77, а також таблицею застосовності показників якості продукції (СПЯП).

Комплексний показник якості:

           (5.1)

де  П_к – комплексний показник якості проектного пристрою;

К_і – відносний показник якості;

Д_і – коефіцієнт вологості і-го одиничного показника якості;

 

Таблиця 5.1 – Показники технічного рівня і якості проектованого пристрою.

Показники	Одиниця показника	Значення показника		Результати диференціаль-ної  оцінки
		Проектова-ного пристрою	Замі-рюваль-ного прис-трою
Показник призначення	-	-	-	1,0
Показник надійності	%	98	92	1,06
Показник продуктивності	шт./год	146	135	1,08
Ергономічні показники	-	8,0	7,5	1,07
Естетичні показники	-	1,2	1,0	1,2
Показник транспортабель-ності	-	-	-	1,0
Показник уніфікації і стандартизації	%	94	92	1,15
Екологічні показники	-	-	-	1,0
Показник безпеки	%	96	90	1,07
Показник точності	%	95	89	1,08

 

Отже: П_к=(1+1,06+1,08+1,07+1,2+1,0+1,15+1+1,07+1,08)^.1=10,71

5.1.2 Визначення трудомісткості і обсягу робіт конструкторської підготовки виробництва

 

Перелік етапів конструкторської підготовки виробництва визначений ГОСТ2103-68. До них відносяться: технічне завдання, технічна пропозиція, ескізний проект, технічний проект, розробка робочої документації.

Трудомісткість окремого етапу конструкторської підготовки виробництва:

Т_кі=Н_чк^.О_п^.К_с^.К_г^.К_ф;                (5.2)

де Т_кі – трудомісткість виконання і-го етапу конструкторської підготовки виробництва;

Н_чк – норма часу на одну облікову одиницю;

О_п - об¢єкт конструкторської підготовки виробництва;

К_с – коефіцієнт серійності виробництва проектованих виробів;

К_г – коефіцієнт габаритності;

К_ф – величина поправочних коефіцієнтів.

Визначаємо значення коефіцієнтів:

Н_чк=87,3(40.с.33,табл.6), К_с=1,1(40.с.38,табл.7), К_г=2,1(40.с.38,табл.8),

К_ф=1,00(40.с.38,табл.9), О_п=1.

Т_кі=87,3^.1,1^.2,1^.1,00^.1=201,663

Отже трудомісткість технічного завдання: Т_ктз=201,7 люд/год, цю роботу виконують робітники 1 розряду.

Н_чк=568, К_с=1,1, К_г=2,1, К_ф=1,00, О_п=1.

Т_кі=586^.1,1^.2,1^.1,00^.1=1312,08 люд/год

Трудомісткість технічної пропозиції становить Т_ктп=1312,08 люд/год. Цю роботу виконують робітники першого розряду.

Н_чк=720, К_с=1,1, К_г=2,1, К_ф=1.

Т_кі=720^.1,1^.2,1^.1=1663,2 люд/год

Трудомісткість ескізного  проекту становить Т_кеп=1663,2 люд/год. Цю роботу виконують робітники першого розряду.

Н_чк=6,8, К_с=1,1, К_г=2,1, К_ф=1, О_п=1.

Т_кі=6,8^.1,1^.2,1^.1^.1=15,708 люд/год

Трудомісткість технічного проекту становить Т_ктп=15,708 люд/год. Цю роботу виконують робітники другого розряду.

Н_чк=7,9, К_с=1,1, К_г=2,1, К_ф=1, О_п=1.

Т_кі=7,9^.1,1^.2,1^.1^.1=18,249 люд/год

Трудомісткість розробки робочої документації становить  Т_крд=18,249 люд/год. Цю роботу виконують робітники третього розряду.

Результати розрахунку зводимо в таблицю.

Таблиця 5.2 – Трудомісткість окремих етапів конструкторської підготовки виробництва.

Назва конструкторської документації	Стадії проек-туван-ня	Кіль-кість обліко-вих  одиниць	Норма часу на одну облікову одиницю, люд-год	Трудоміст-кість загального обсягу робіт, люд-год	Кваліфі-кація виконав-ців
Технічне завдання	-	1	87,3	201,7	І
Технічна пропозиція	-	2	568	1312,08	І
Ескізний проект	-	6	720	1663,8	І
Технічний проект	-	8	6,8	15,708	ІІ
Робоча документація	-	8	7,9	18,249	ІІІ
Разом	-	-	-	3210,937	-