Главная страница Случайная страница КАТЕГОРИИ: АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника |
Характеристика модулів комплексу програм
Партії деталей з наявної множини претендентів на завантаження основного технологічного устаткування вибираються виходячи з набору правил переваги і стратегій транспортного обслуговування. При цьому з різних варіантів розкладів, побудованих у результаті імітаційного моделювання за кожним правилом, вибирається варіант, що задовольняє критерію мінімуму загальної тривалості виробничого циклу. Даний критерій забезпечує безупинне і рівномірне завантаження основного технологічного устаткування, мінімізацію загального терміну виготовлення і комплектування деталей, розміру і вартості незавершеного виробництва, а також можливих відхилень від встановленого плану за обсягом і номенклатурою. Модуль працює циклічно в три етапи. Перший етап – підготовка вихідних даних для проведення імітаційного експерименту. При цьому за інформацією про процес функціонування й за вибраними для даного експерименту правилами переваги формується сіткова модель процесу управління ГВС, що враховує тимчасові параметри виконуваних операцій. На другому етапі роботи модуля проводиться, власне, планування і побудова розкладу роботи одиниць виробничого устаткування за допомогою трансляції сіткової управляючої моделі (УМ). При цьому моменти запуску/випуску деталей на деякій одиниці виробничого устаткування визначаються за модельним часом моменту Gk* (tj) – k- го спрацьовування переходу сіткової моделі процесу управління ГВС, а розклад представляється як множина часових рядів Gk* = {(Gk* (tj) | k Î {1, 2, 3,...}, j = 1, т } моментів спрацьовувань переходів сітки. Конфлікти на переходах вирішуються за допомогою вибраного правила переваги на першому етапі. На третьому етапі роботи модуля відбирається варіант плану змінімальним часом виробничого циклу з усіх складених розкладів, що відповідають визначеним правилам переваги зі встановленого набору. Кожний знову побудований розклад порівнюється з тим, що вважався найкращим. При цьому час виробничого циклу побудованого розкладу визначається як максимум модельного часу моментів останніх спрацьовувань усіх переходів сіткової моделі процесу управління ГВС. За найкращим варіантом розкладу, з огляду на оптимальне правило переваги і зв’язок входів і виходів об’єкта управління з елементами сіткової моделі, будується сіткова управляюча модель ГВС. Модуль РLАN завершує свою роботу записом результатів оперативного планування (розклад роботи і сіткова управляюча модель) у визначені блоки інформаційної бази ГВС. Модуль МDМР диспетчеризації матеріальних потоків призначений для обробки інформації про хід виробничого процесу, вибору чергових претендентів (носіїв з деталями) на обслуговування, формування і передачі управляючих впливів до нижнього рівня управління. Модуль працює в два етапи: 1) опитування гнучких виробничих модулів, транспортних засобів, робота-штабелера автоматизованого складу і формування черги претендентів на завантаження виробничих засобів; 2) вибір і посилання чергового носія на обслуговування. На першому етапі роботи модуля визначається поточний стан виробничого устаткування за станом М маркування сіткової управляючої моделі і вектора V сигналів зворотного зв’язку з об’єктом управління. Далі серед усіх справних і незайнятих одиниць устаткування визначається та, яка на поточний момент часу має найвищий пріоритет відповідно до вибраного в модулі РLАN правила переваги. У сітковій моделі ці дії пов’язані з пошуком збуджених переходів TM і вибором того з них, котрий у даній ситуації може спрацювати. На другому етапі роботи модуля формується новий стан управляючої моделі, що є наслідком спрацьовування вибраного на першому етапі збудженого переходу. У новому стані маркування визначається вектор управляючих впливів Y і видається завдання роботу-штабелеру автоматизованого складу чи автономному транспортному засобу на транспортування носія, або гнучкому виробничому модулю на виконання необхідної виробничої операції. Потім робота модуля МDМР циклічно повторюється. Алгоритм функціонування модуля МDМР зображений на рис. 4.7. Модуль КNТR оперативного контролю призначений для диспетчерської діагностики ходу виконання розкладу роботи, обробки інформації диспетчера про хід виробничого процесу і прийняття рішення про порядок подальшої роботи. Рис. 4.7. Алгоритм диспетчеризації за управляючою моделлю Контрольованими параметрами служать терміни запуску/випуску носіїв деталей відповідно до розкладу, побудованого в модулі РLАN, а також параметри поточного стану одиниць виробничого устаткування ГВС. Вихідними даними модуля є розклад роботи виробничого устаткування G *, управляюча модель і локальні резерви часу виконання операцій виробничого процесу Dдоп, k . Відхиленнями в роботі ГВС від передбаченого розкладу вважаються збій (аварія) у роботі виробничої системи, відхилення D kj від планового моменту часу виконання виробничої операції. У тих випадках, коли зафіксоване відхилення, модуль КNТR діагностує ситуацію і приймає рішення про її ліквідацію наявними засобами в складі модуля корегування KORR. Контроль і діагностика ситуацій ведеться безупинно протягом усього періоду функціонування модуля МDМР (періоду управління в реальному часі). Алгоритм функціонування модуля КNТR показаний на рис. 4.8. Модуль КОRR оперативного корегування призначений для відпрацьовування аварійних ситуацій і відхилень ходу виробництва додаванням у систему ресурсів чи зміною планового завдання. Модуль коригує інформацію про стан виробничих потужностей і планове завдання у діалоговому режимі з диспетчером ГВС. За своїми функціональними можливостями модуль КОRR подібний модулю ВLDТ, оскільки в модулі оперативного корегування модифікуються параметри і структура управляючої моделі на підставі введених диспетчером даних. Однак модуль KORR може викликатися за необхідності диспетчером і виконувати додаткову функцію включення фонових завдань виробничої підсистеми. Рис. 4.8. Алгоритм оперативного контролю Використовуючи локальні резерви, диспетчер ГВС може включити додаткові замовлення на обслуговування фонових робіт, виконання транспортних операцій і операцій завантаження складу через дану функцію модуля KORR. Тому модуль оперативного корегування має дві точки входу: з модулів МАІN і KNTR. Робота модуля завершується передачею управління модулю МАIN чи модулю РLАN. Алгоритм функціонування модуля KORR зображений на рис. 4.9. Модуль МDIР призначений для обробки запитів диспетчера ГВС і формування диспетчеру системних повідомлень. При роботі з комплексом програм у період управління в реальному часі диспетчеру ГВС подаються різні повідомлення, у відповідь на які він повинен виконати визначені дії. Усі повідомлення формуються в результаті інтерпретації стану управляючої моделі ГВС мовою, зрозумілою диспетчеру. Повідомлення, що видаються в ході диспетчеризації, поділяються на запитальні та синхронізуючі. Синхронізуючі повідомлення інформують оператора про стан виробничого устаткування, предметів виробництва і про важливі з погляду контролю події, що не ідентифікуються інформаційними засобами на об’єкті управління. За допомогою запитальних повідомлень модуль МDIР запитує необхідну інформацію для роботи модулів МDМР, КNTR, КОRR. Рис. 4.9. Алгоритм функціонування модуля оперативного корегування Модуль запускається в роботу одночасно з модулями МDМР, КNТR і взаємодіє з ними за допомогою посилання повідомлень у ході диспетчеризації матеріальних потоків ГВС. Алгоритм функціонування модуля МDMР показаний на рис 4.10. Модуль DОС призначений для обліку стану виробництва і формування довідкової інформації диспетчеру ГВС. Він представляє собою діалоговий комплекс програм видачі необхідних інформаційних повідомлень. Облік стану виробництва ведеться за показниками, серед яких можна виділити наступні: змінно-добове завдання, виконання змінно-добового завдання, простої устаткування через транспортування, переналагодження та аварії, сумарні простої, модель стану складу, модель стану виробничого устаткування, стан оперативних нагромаджувачів, незавершене виробництво на поточну добу, оперативний розклад запуску/випуску деталей, інформація про носії з деталями, що виготовляються в поточну зміну. Модуль запускається в міру необхідності диспетчером ГВС незалежно від задіяних в конкретний момент модулів комплексу. Модуль АВND призначений для відтворення інформаційного стану системи при аварійному виході модулів з комплексу програм чи збоях устаткування, у тому числі й ЕОМ. Модуль виконує наступні функції: встановлення наявності та можливості доступу до даних файлів системи; визначення можливої точки входу для продовження роботи системи. Робота модуля АВND ініціюється вказівкою режиму роботи комплексу програм у модулі МАІN і здійснюється в автономному режимі з видачею діагностичних повідомлень і рекомендацій диспетчеру ГВС по продовженню роботи з комплексом програм. У випадку аварійного виходу із системи необхідно запустити модуль АВND і привести устаткування ГВС у вихідний стан. Рис. 4.10. Алгоритм функціонування модуля диспетчиризації запитів і системних повідомлень Модуль ТЕSТ призначений для перевірки працездатності модулів комплексу СОУ ГВС. Тестування проводиться відповідно до встановлених в системі контрольних прикладів, що задаються визначеними програмами (протоколами роботи) системи, вибраними диспетчером ГВС за своїм розсудом.Потім робота здійснюється, як і в нормальному режимі функціонування СОУ, але над тестовою інформаційною базою даних. Модуль ОВМ призначений для обміну інформацією комплексу програм з нижчим рівнем управління виробничими модулями і є модулем міжрівневого обміну даними каналами зв’язку. Модуль ОВМ виконує наступні функції: передачу повідомлень каналами зв’язку; чекання підтвердження прийому переданого повідомлення; прийом символів, що підтверджують зміну стану ГВС; прийом управляючих повідомлень. Даний модуль слугує для передачі даних (команд управління) транспортним автономним засобам і роботам-штабелерам автоматизованого складу, а також управляючих програм для пристроїв ЧПУ гнучких виробничих модулів. Модулі обміну, що функціонують на нижчому рівні в складі програмних модулів управління GРМ, АS, АТМ, виконують наступні функції: прийом повідомлень (управляючих команд); передача інформаційних повідомлень. Ці модулі, здійснюючи зв’язок з верхнім рівнем і приймаючи командні вказівки, реалізують власне управління одиницями виробничого устаткування ГВС. Управління організується на основі сіткових моделей алгоритмів управління гнучкими виробничими модулями, роботами-штабелерами, автоматизованими складами і електроробокарами, отриманими у результаті декомпозиції управляючої моделі ГВС на алгоритми нижчих рівнів управління. Повідомлення, передані від ЕОМ верхнього рівня до пристроїв ЧПУ, поділяються на інформаційні та управляючі. Від пристрою ЧПУ до верхнього рівня передаються тільки інформаційні повідомлення. Для ЕОМ верхнього рівня управління встановлені наступні види повідомлень процедури обміну: інформаційні (D – дані, U – вказівки); управляючі (S – ініціалізація обміну, Е – кінець повідомлення). Для пристрою ЧПУ нижнього рівня управління встановлені тільки інформаційні повідомлення наступних видів: N – заперечення прийому; С – підтвердження прийому; F – кінець виконання операції на устаткуванні; A – аварія на устаткуванні. Комплекс модулів міжрівневого обміну на основі наведених повідомлень реалізує єдину мову обміну, тобто деякий формат ідентифікації тексту повідомлень, що надходять по каналах зв’язку між ЕОМ верхнього рівня і пристроями ЧПУ нижнього рівня ГВС. Інтерфейс комплексу і подання даних у пакеті програм СОУ ГВС. В основі програмного забезпечення СОУ ГВС лежить управляючий модуль МАІN, що ініціює початок функціонування комплексу програм, управляє порядком проходження програмних модулів і виконує діалог між диспетчером і програмним забезпеченням СОУ ГВС (рис. 4.11). Диспетчер ГВС у діалоговій формі вводить у вихідні дані для оперативного планування і дані про початковий стан устаткування, тобто створює інформаційний стан СОУ, використовуючи для цього модуль ВLDТ. Потім диспетчер передає управління модулю оперативного планування РLАN, що складає розклад і підготовляє дані до процесу диспетчеризації. Після завершення планування запускається модуль диспетчеризації матеріальних потоків ГВС, що через модуль міжрівневого обміну ОВМ власне і здійснює управління транспортом (АТМ), складом (АS), технологічним устаткуванням (GРМ). Коли на об’єкті управління відбувається яка-небудь подія, аналізується ситуація, що створилася(КNТR), і в залежності від результатів аналізу управління повертається до МDМР чи передається модулю КОRR. Якщо в результаті аналізу виявлене порушення нормального функціонування виробництва, то в діалоговому режимі корегується оперативна інформація і формуються вихідні дані для оперативного редагування розкладу функціонування ГВС (за допомогою модуля РLАN) на період роботи, що залишився. Диспетчер управляє ходом функціонування системи в період диспетчеризації через модуль МDIР і може одержувати довідкову інформацію про стан виробництва в будь-який момент часу через модуль DОС. Оскільки комплекс програм побудований за модульним принципом, то процес функціонування програмного забезпечення представляється у вигляді сукупності підпроцесів взаємодії диспетчера ГВС із кожним модулем окремо. Рис. 4.11. Схема взаємодії програмних модулів комплексу програм СОУ ГВС Реалізація функцій, покладених на СОУ ГВС, вимагає передачі, прийому, збереження та перетворення великого обсягу інформації. Виходячи з модульного принципу побудови комплексу програм з організацією управління на основі управляючої моделі ГВС, усі вхідні та вихідні дані програмних модулів організовані у вигляді блоків єдиної інформаційної бази даних ЕОМ верхнього рівня. Дані блоки поділяються на чотири групи: основні, службові, допоміжні, інформаційні. До групи основних відносяться блоки, що відповідають за стан одиниць виробничого устаткування ГВС, матеріальних та інформаційних потоків, тобто описують управляючу модель ГВС. До групи службових відносяться блоки, що містять маршрутні карти технологічного процесу виготовлення всіх допустимих для даної ГВС типів деталей, блоки управляючих програм технологічного устаткування. Наявність службових блоків у системі обов’язкова для початку функціонування комплексу програм. До групи допоміжних відносяться блоки, що створюються і використовуються під час роботи комплексу програм для збереження і передачі проміжних результатів і знищуються по закінченні роботи. До групи інформаційних відносяться блоки, що відповідають за виробничу діяльність ГВС і призначені для інформування диспетчера ГВС. Отже, програмне забезпечення СОУ ГВС, спроектоване із врахуванням ряду вимог, виконання яких дозволило уніфікувати програмні засоби управління, забезпечує їх незалежність від змісту предметної області виробничої системи. Досягнута уніфікація програмного забезпечення дозволяє тиражувати і супроводжувати його у виробничих системах без принципових змін в організації програмних засобів управління шляхом реорганізації єдиної інформаційної бази даних.
Контрольні запитання 1. Розкрийте складові сіткової моделі виробничого процесу ГВС. 2. Поясніть вміст формалізованого подання і процедури вирішення конфліктних ситуацій, що утворюються в ході виконання виробничого процесу під час оперативно-диспетчерського управління ГВС. 3. Наведіть відмінності сіткової моделі управляючого процесу від сіткової моделі алгоритму управління. 4. Сформулюйте етапи методу синтеза сіткової моделі алгоритмів управління ГВС. 5. Розкрийте задачі і особливості побудови програмних засобів системи оперативного управління ГВС. 6. Визначте базові модулі системи оперативного управління ГВС 7. Поясніть порядок застосування програмних модулів і структур даних системи оперативного управління ГВС.
«Необхідність є нещастя, але немає ніякої необхідності жити з необхідністю» (Епікур)
|