4. Системи збору даних

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

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

Рис. 8.8. Архітектура системи, спостереження за інтенсивністю потоку нейтронів

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

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

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

Рис. 8.9. Кільцевий буфер у системі збору даних

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

У лістингу 8.2 показана можлива реалізація буфера даних як об'єкта Java. Значення в буфері мають тип Sensorrecord (запис даних датчика). Визначено два методи -get іput: методget бере елементи з буфера, методput додає елемент у буфер. При оголошенні типуCircularbuffer (кільцевий буфер) програмний конструктор задає розмір буфера.

Лістинг 8.2. Реалізація кільцевого буфера

class Circularbuffer

{

int bufsize;

Sensorrecord [] store;

int numberofentries = 0;

int front = 0, back = 0;

Circularbuffer (int n) {

bufsize = n;

store = new Sensorrecord [bufsize];

} //Circularbuffer

synchronized void put (Sensorrecord rec) throws

Interruptedexception

{

if(numberofentries == bufsize)

wait ();

store [back] = new Sensorrecord (rec.sensorld,rec.sensorval);

back = back + 1;

if(back == bufsize)

back = 0;

numberofentries = numberofentries + 1;

notify();

}//put

synchronized Sensorrecord get () throws Interruptedexception

{

Sensorrecord result = new Sensorrecord(-1,-1);

if(numberofentries == 0)

wait ();

result = store [front];

front = front + 1;

if(front == bufsize)

front = 0;

numberofentries = numberofentries - 1;

notify();

return result;

}// get

}//Circularbuffer

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

Завдання:

1. Спроектуйте архітектуру процесів для системи спостереження, що збирає дані із групи датчиків, що вимірюють состав повітря і розташованих навколо міста. У системі 5000 датчиків, організованих у групи по 100 штук. Кожний датчик повинен перевірятися 4 рази в секунду. Якщо більше 30% датчиків у групі зафіксують, що якість повітря нижче припустимого рівня, активізується попереджуючий світловий сигнал. Усі датчики передають зібрані дані центральному комп'ютеру, який кожні 15 хв генерує звіт про состав повітря в місті.

Питання:

1. Чому системи реального часу зазвичай реалізовані як безліч паралельних процесів? Проілюструйте свою відповідь прикладами.

2. Поясніть, чому об'єктно-орієнтовані методи розробки ПЗ не завжди підходять до систем реального часу.

3. Сильні і слабкі сторони Java як мови програмування для реалізації систем реального часу.

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

Список літератури

1.  Смірнов В.В. Технологія проектування програмних систем. Лабораторні роботи / В.В. Смірнов, Н.В. Смірнова. - Кіровоград: КНТУ, 2012. - 53 с.

2.  Лешек А. Мацяшек. Аналіз і проектування інформаційних систем за допомогою UML 2.0 / Лешек А. Мацяшек. - М.: Вільямс, 2008. - 816 с.

3.  Шалыто А.А. SWITCH - технологія. Алгоритмізація і програмування завдань логічного керування / А.А. Шалыто. - Спб.: Наука, 1998. - 628 c.

4.  Карло Гецци. Основи інженерії програмного забезпечення / Карло Гецци, Мехди Джазайери, Дино Мандриоли. - Спб.: Бхв-Петербург, 2005. - 832 с.

5.  Соммервилл, Иан. Інженерія програмного забезпечення, 6-е видання, пров. з

англ. А.А. Минько. - М.: Видавничий будинок "Вільямс", 2002. - 624 с.

6.  Эдвард Йордон. Орієнтований^-орієнтований-об'єктно-орієнтований аналіз і проектування систем / Эдвард Йордон, Карл Аргила. - М.: Лорі, 2010. - 264 с.

7.Эрик Эванс. Предметно – орієнтоване проектування (DDD). Структуризація складних програмних систем / Эрик Эванс, пров. з англ. В. Бродів. - К.: Вільямс, 2010. - 448 с.

8.  Гама Є. Приймання об'єктно-орієнтованого проектування. Паттерны проектування / Є. Гама, Р. Хелм, Р. Джонсон, Дж. Влиссидес. пер. с англ. А. Слинкин. - К.: Пітер, 2007. - 366 с.

9.  Joey F. George. Object-Oriented Systems Analysis and Design. [Joey F. George, Dinesh Batra, Joseph S. Valacich, Jeffrey A. Hoffer]; (2nd Edition). - Prentice Hall; 2 edition (October 27, 2006). - 550 p.

10.  Noushin Ashrafi. Object Oriented Systems Analysis and Design / Noushin Ashrafi, Hessam Ashrafi. - Prentice Hall; 1 edition (September 20, 2008). - 648 p.

11.  Michele Lanza. Object-Oriented Metrics in Practice: Using Software Metrics to Characterize, Evaluate, and Improve the Design of Object-Oriented Systems / Michele Lanza, Radu Marinescu. - Springer; Softcover reprint of hardcover 1st ed. 2006 edition (December 2, 2010). - 220 p.

12.  Grady Booch. Object-Oriented Analysis and Design with Applications (3rd Edition) / [Grady Booch, Robert A. Maksimchuk, Michael W. Engel, Bobbi J. Young, Jim Conallen, Kelli A. Houston. - Addison-Wesley Professional; 3 edition (April 30, 2007). - 720 p.

13.  Jeffrey Whitten. Systems Analysis and Design Methods / Jeffrey Whitten, Lonnie Bentley. - Mcgraw-hill/Irwin; 7th edition (November 22, 2005). - 768 p.

14.  Alan Dennis. Systems Analysis and Design / Alan Dennis, Barbara Haley Wixom, Roberta M. Roth. - Wiley; 4 edition (December 10, 2008). - 576 p.

15. Соммервилл, Иан. Інженерія програмного забезпечення, 6-е видання.: Пер. с англ. / Соммервилл, Иан. - М.: Видавничий будинок "Вільяму", 2002. - 624 с.

16.  Смірнов В.В. Технологія проектування програмних систем. Лекції / В.В. Смірнов, Н.В. Смірнова. - Кіровоград: КНТУ, 2012. - 95 с.