Діаграми системи технічної експлуатації

Діаграма варіантів використання відображає концептуальну модель системи TEA і описує функціональне призначення системи, а як «актор» тут виступає віртуальна ІТС (рис. 3.11), яка згідно роботам, виконує в процесі свого функціонування наступні загальні функції:

• — контроль PC технічний;
• — контроль втрати горючого і ін. матеріалів;
• — контроль процесів КЕ;
• — формування звітних рапортів і іншої документації по ЖЦ процесу експлуатації PC;
• — ін. функції.

Рис. 3.11. Діаграма варіантів використання

Всі перераховані функції ІТС є прецедентами. На діаграмі варіантів використання ці прецеденти зв’язані відношенням асоціації. Це означає, що прецедент, який пов’язаний з актором, повинен реалізовувати всі операції, необхідні для даного інтерфейсу.

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

У відповідності з аналізом статики, на АТЗК необхідно розглянути процес технічного контролю PC.

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

• — «РС» :
• — «трекер (сканер комунікатор)» ;
• — «Web-сервер» :
• — «ІТС» ;
• — «Диспетчер» .

" РС" здійснює перевезення вантажів і пасажирів згідно завданню.

" Трекер" отримує сигнали від супутників системи космічної радіонавігації, визначає географічні координати знаходження РС і фіксує час отримання сигналу, отримує інформацію з бортових датчиків і контролерів систем управління робочими процесами вузлів, агрегатів систем автомобіля, і через задані проміжки часу за допомогою сучасних засобів радіозв'язку передає отриману інформацію у вигляді пакетів даних на сервер системи моніторингу. Таким чином він здійснює збір, формування і передачу даних процесу експлуатації ЖЦ РС.

" Web-сервер" системи моніторингу — комп’ютер, що працює цілодобово і постійно підключений в мережу Internet, приймає інформацію з борта РС. сортує, заздалегідь обробляє, зберігає і пересилає інформацію за запитом «Диспетчеру» через Web — інтерфейс або у вигляді електронних звітів.

" Диспетчер" на основі даних «Web-серверу», здійснює аналіз діяльності РС, а саме визначає наявність порушень правил КЕ (відхилення РС від маршруту або графіка). Також «Диспетчер» стежить за виконанням графіків ТО і Р, причинами простоїв в ІТС, наявністю працівників і режимом їх роботи. Раніше це здійснювалося «Диспетчером» шляхом безпосереднього контролю за паперовими носіями інформації, що на сьогоднішній день неможливе через дві головні причини:

• — наявність Закону № 8397. який ліквідовував путьові листи і позбавив ІТС інформації щодо пробігів РС;
• — обслуговування РС на підприємствах ІТС, які не є структурними підрозділами комплексних АТП.

Саме через цс «Диспетчер» сьогодні не в змозі виконувати свої функції повною мірою, що фактично і обумовлює на АТЗК відсутність технічного контролю РС.

Діаграма класів реальної моделі представлена на рис. 3.12.

Клас «РС» пов’язаний з класами «Диспетчер» і «ІТС» відношенням асоціації, тобто класи є рівноправними. Клас «РС» пов’язаний з класом «Трекер» відношенням композиції, а це означає, що на реальному РС встановлено телематичний пристрій — комунікаційний контролер.

Класи «Web-сервер» і «Трекер» зв’язані між собою відношенням залежності, тобто деяка зміна одного з елементів моделі вимагає зміни іншого залежного від нього елементу моделі. Класи «Диспетчер» і " Web-сервер" також зв’язані між собою відношенням залежності.

З метою удосконалення системи технічного контролю за ЖЦ процесу експлуатації PC створена віртуальна модель діаграми класів. У віртуальній моделі відсутній клас «Диспетчер», оскільки сьогодні він не має можливості в повному об'ємі виконувати свої завдання. Замість цього були додані класи «Діспетчер ІТС» і «ПЗ «Virtual mechanic» «.

Рис. 3.12. Діаграма класів. Модель реальна

" Диспетчер ІТС" здійснює функції, які були віднесені до класу «Диспетчер», а також має можливість проводити оперативний технічний контроль і регулювання діяльності PC за допомогою класу «ПЗ «Virtual mechanic» «. Клас «ПЗ » Virtual mechanic» « значно прискорює процес обробки вхідної інформації і спрощує роботу диспетчера ІТС, крім того він дає можливість працювати за точнішими і важливішими на сьогоднішній день показниками. Графічно віртуальна модель діаграми класів представлена на рис. 3.13.

Клас «Діспетчер ІТС» і «РС» зв’язані відношенням асоціації, тобто класи є рівноправними. Клас «ІТС» пов’язаний з класами «Діспетчер ІТС» і «ПЗ » Virtual mechanic" « відношенням композиції. Клас «ПЗ «Virtual mechanic» « пов’язаний з класом «Діспетчер ІТС» відношенням композиції, а з класом » Webсервер» відношеннями залежності. «Диспетчер ІТС» пов’язаний з «вебсервером » відношенням залежності. Логічним продовження статичного аналізу системи є динамічний аналіз системи, який проводиться на основі діаграми послідовності, станів об'єкту і системи, діяльності.

На діаграмі послідовності зображуються виключно ті об'єкти, які безпосередньо беруть участь у взаємодії. Такими є: «Диспетчер» — він же ініціатор взаємодії, яка зображується крайньою зліва, «Web-сервер», «РС», «ІТС». Всі об'єкти на діаграмі послідовності утворюють порядок, обумовлений їх ступенем активності.

Рис. 3.13. Діаграма класів. Модель віртуальна

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

Рис. 3.14. Діаграма послідовності. Модель реальна

Дії, які виконуються в системі технічного контролю в реальній моделі:

• — 1 — «Диспетчер» запрошує у «Web-сервера» інформацію (місце розташування, пробіг, середня швидкість, час руху, час простою час знаходження PC в географічних зонах);
• — 2 — сервер системи моніторингу надає інформацію диспетчерові ІТС, яка стає доступною через Web-інтерфейс або у вигляді звітів формату MS Excel;
• — 3 — «Диспетчер» аналізує дані, отримані від сервера, і ухвалює управлінське рішення щодо діяльності PC;
• — 4 — «Диспетчер» дає управлінські команди щодо плану маршруту, графіка руху і ін. оперативних дій водієві або власникові PC в процесі контролю ЖЦ експлуатації його PC;
• — 5 — «РС» звертається в «ІТС» для здійснення дій ТО і Р.

Графічно віртуальна модель діаграми послідовності представлена на рис. 3.15.

Рис. 3.15. Діаграма послідовності. Модель віртуальна

Дії, які виконуються в системі технічного контролю у віртуальній моделі:

• — 1 — «Диспетчер» запрошує у " Web-сервера" необхідну інформацію (місце розташування, пробіг, середня швидкість, час руху, час простою, час знаходження РС в географічних зонах);
• — 2 — «Web-сервер» системи моніторингу надає інформацію «Диспетчерові ІТС», яка стає доступною у вигляді електронних звітів;
• — З — «Диспетчер ІТС» звертається до ПЗ " Virtual mechanic" для обробки отриманих даних;
• — 4 — ПЗ " Virtual mechanic" обробляє отримані звіти, а також проводить наступні дії: проводить оцінку параметрів стану парка РС, а саме розраховує пробіг РС до ТО і трудомісткість дій ТО і Р; визначає вірогідність перебування РС в роботі і в ТО і Р, тобто розраховує інтенсивність вхідних заявок на ТО і Р; здійснює технологічний розрахунок ІТС, визначаючи пропускну спроможність ІТС, точку насичення ІТС, кількість постів, необхідних для повноцінної роботи ІТС, мінімальну і оптимальну продуктивність ІТС; оцінює надійність PC;
• — 5 — ПЗ «Virtual mechanic» надає диспетчерові результати проведених розрахунків;
• — 6 — проаналізувавши отриману інформацію від сервера і ПЗ, «Диспетчер ІТС» ухвалює управлінське рішення щодо діяльності «РС» і «ІТС» ;
• — 7 — «Диспетчер ІТС» дає управлінські команди «РС» щодо плану, маршруту, графіка руху і ін. оперативних дій водієві, власникові РС в процесі контролю ЖЦ експлуатації його РС;
• — 8 — «Диспетчер ІТС» дає управлінські команди «ІТС» щодо здійснення дій по ТО і Р на РС;
• — 9 — «ІТС» впливає на «РС» по командах «Диспетчера ІТС» .

У віртуальній моделі на діаграмі послідовності існує альтернативний потік роботи системи у разі виявлення некоректної роботи " Web-сервера". Графічно віртуальна модель (потік альтернативний) діаграми послідовності показана на рис. 3.16.

Рис. 3.16. Діаграма послідовності. Модель віртуальна (потік альтернативний)

Дії, які виконуються в системі технічного контролю у віртуальній моделі альтернативного потоку подій, коли виявлена некоректна робота сервера системи моніторингу:

• — 1 — «Диспетчер ІТС» запрошує у " Web-сервера" необхідну інформацію (місце розташування, пробіг, середня швидкість, час руху, час простою, час знаходження РС в географічних зонах) і виявляє некоректну роботу сервера системи моніторингу;
• — 2 — «Диспетчер ІТС» звертається до резервного " Web-сервера" , який є складовою головного " Web-сервера" ;
• — 3 — «Web-сервер» системи моніторингу надає інформацію «Диспетчер ГГС», яка стає доступною через ІРеб-інтерфейс, а також у вигляді електронних звітів;
• — 4 — «Диспетчер ГГС» звертається до ПЗ " Virtual mechanic" для обробки даних;
• — 5 — ПЗ «Virtual mechanic» обробляє отримані звіти, а також проводить наступні дії: проводить оцінку параметрів стану парка PC, а саме розраховує пробіг PC до ТО і трудомісткість дій ТО і Р, визначає вірогідність перебування PC в роботі і в ТО і Р, здійснює технологічний розрахунок ІТС, оцінює надійність PC;
• — 6 — ПЗ «Virtual mechanic» надає «Диспетчеру ІТС» результати розрахунків;
• — 7 — проаналізувавши отриману інформацію від «Web-сервера» і ПЗ «Virtual mechanic» , «Диспетчер ІТС» ухвалює управлінське рішення щодо діяльності «РС» і «ГГС» ;
• — 8 — «Диспетчер ІТС» дає управлінські команди РС щодо плану, маршруту, графіка руху і ін. оперативних дій водієві або власникові РС в процесі контролю ЖЦ експлуатації його РС;
• — 9 — «Диспетчер ІТС» дає управлінські команди ІТС щодо здійснення дій по ТО і Р на РС;
• — 10 — «ІТС» впливає на «РС» у відповідності з командами «Диспетчер ГГС» .

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

технічний контроль автомобіль діаграма.

Рис. 3.17. Діаграма станів і переходів об'єкту «Диспетчер IТС»

Як об'єкт виступає «Диспетчер IТС». Диспетчер протягом свого ЖЦ знаходиться в стані процесу проведення технічного контролю за діяльністю PC який складено. Даний складений стан складається з двох послідовних складених станів: процесу збору і збереження вихідних даних і процесу аналізу параметрів технічного контролю над діяльністю PC, які складаються з послідовних вкладених станів.

Діаграма діяльності (рис. 3.18) використовується для моделювання процесу виконання операцій.

Рис. 3.18. Діаграма діяльності

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

Фізичне представлення системи ТЕА-АСУ і її особливості описує діаграма компонентів. Вона дозволяє визначити архітектуру системи, встановивши залежність між програмними компонентами. У прийнятому середовищі розробки модуль відповідає файлу ASU_ControlOJMT.exe (рис. 3.19).

Рис. 3.19. Діаграма компонентів

Цей компонент реалізує деякий набір інтерфейсів і служить для загального позначення елементів фізичного представлення моделі. В рамках проекту ТЕААСУ він є наступним класом: загальний опис таких об'єктів, для яких характерна наявність безлічі загальних особливостей дій і які можуть виконати ці об'єкти.

Кожен клас відповідає тим об'єктам, які були виділені в рамках функціонування реальної системи:

• — «Диспетчер ІТС» (Class_DispetcherITS),
• — «ІТС» (Class_ITS),
• — «Web-сервер» (ClassJVebServe),
• — «PC» (Class_TZ),
• — «ПЗ «VirtualMeehan» «(Class_PZ_VirtualMeehan).

Завершує процес ООП діаграма розгортання (рис. 3.5). Її розробка є останнім етапом специфікації моделі. Вона призначена для візуалізації елементів і компонентів програми, які існують лише на етапі її виконання (runtime).

Цілі, що переслідуються при розробці діаграми розгортання:

• — визначити розподіл компонентів системи по її фізичних вузлах;
• — показати фізичні зв’язки між всіма вузлами реалізації системи на етапі її виконання.

Графічно діаграма розгортання представлена на рис. 3.20.

Рис. 3.20. Діаграма розміщення

Для побудови програмної моделі доцільно визначити специфікації класів. Побудова специфікацій класів — це процес документування атрибутів класів, метою якого є підготовка до кодування програмної моделі системи. Специфікація класів приведена в додатку «Б» .

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