logo
ТППС / Магистры / ТППС-лаб

3. Системи спостереження і керування

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

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

Розглянемо наступний приклад.

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

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

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

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

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

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

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

Таблиця 8.1. Тимчасові обмеження на вхідні і відповідні сигнали системи

Сигнал

Тимчасові обмеження

Відключення електроживлення

Перемикання на живлення від батарей повинне відбутися протягом 50 мс

Сигналізація на двері

Кожний сигнальний датчик на дверях перевіряється двічі в секунду

Сигналізація на вікнах

Кожний датчик на вікні перевіряється двічі в секунду

Датчик руху

Кожний датчик руху опитується двічі в секунду

Звуковий сигнал

Звуковий сигнал повинен пролунати через півсекунди після сигналу датчика

Включення світлової сигналізації

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

Зв'язок

Виклик у поліцію повинен початися протягом 2 с після сигналу датчика

Синтезатор мови

Синтезоване повідомлення повинне бути готове через 4 с після сигналу датчика

Рис. 8.6. Архітектура процесів системи охоронної сигналізації

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

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

Частота виконання процесів визначається кількістю датчиків і тимчасовими вимогами, що пред'являються системі. Припустимо, що в системі є 30 дверних датчиків, які потрібно перевіряти двічі на секунду. Отже, пов'язаний із дверним датчиком процес повинен виконуватися 60 раз у секунду (частота 60 Гц). Також 400 раз на секунду виконується процес, контролюючий датчик руху.

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

Усі представлені процеси можна реалізувати мовою Java як потоки. Лістинг 8.1 містить код Java реалізації процесу Buildingmonitor (моніторинг будинку), що опитує датчики системи. У випадку сигналу тривоги програма активізує систему сигналізації. Нехай у прикладі система відповідає тимчасовим вимогам. У мові Java немає засобів для завдання частоти виконання потоків.

Лістинг 8.1. Реалізація процесу моніторингу будинку

class Buildingmonitor extends Thread {

Buildingsensor win, door, move;

Siren siren = new Siren ();

Lights lights = new Lights ();

Synthesizer synthesizer = new Synthesizer ();

Doorsensors doors = new Doorsensors(30);

Windowsensors windows = new Windowsensors(50);

Movementsensors movements = new Movementsensors(200) ;

Powermonitor pm = new Powermonitor();

Buildingmonitor()

{

//ініціалізація датчиків і запуск процесів

siren.start ();

lights.start();

synthesizer.start();

windows.start();

doors.start()movements.start();

pm.start();

}

public void run ()

{

int room = 0;

while (true)

{

//перевірка датчиків руху два рази в секунду (400 Гц) move =

//movements.getval();

//перевірка віконних датчиків два рази в секунду (100 Гц)

win = windows.getval();

//перевірка дверних датчиків два рази в секунду (60 Гц)

door = doors.getval();

if(move.sensorval==li door.sensorval==l|win.sensorval==l)

{

//датчик зареєстрував порушення

if(move.sensorval == 1) room = move.room;

if (door.sensorval == 1) room = door.room;

if(win.sensorval == 1) room = win.room;

lights.on(room);

siren.on();

synthesizer.on(room);

break;

}

}

lights.shutdown();siren.shutdown();

synthesizer.shutdown();

windows.shutdown();doors.shutdown();

movements.shutdown();

)//run }

//Buildingmonitor

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

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

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

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

Архітектура процесів такої системи показана на рис. 8.7; у загальному вигляді вона виглядає подібно системі сигналізації.

Рис. 8.7.Архітектура процесів системи в правління опаленням