Ця стаття написана під впливом дослідження Джима Брауна (Jim Brown) “Як провідні світові компанії здійснюють, використовують і підтримують PLM-інтеграцію” (Observer # 1/2017). Підняті в цій роботі питання наочно показують, що успішна організація так званого електронного виробництва досягається забезпеченням зв’язку між різнорідними робочими процесами на підприємстві та ефективним використанням даних, що створюються в різних корпоративних програмних системах.
Впровадження інформаційної системи, що забезпечує концентрацію даних та управління ними в рамках виробничих процесів, є актуальним завданням для широкого кола підприємств. Сьогодні інформаційний ландшафт більшості компаній визначається “зоопарком” практично не пов’язаних між собою систем, що виконують свої функції у відповідних виробничих нішах. Наслідки такої клаптикової автоматизації – багаторазове введення однакової інформації, неузгодженість між службами – визначають часові та фінансові втрати, нівелюють зростання ефективності від застосування Ай-Ті. Багато підприємств визнають проблему, але це ще не означає розуміння ними шляхів її вирішення.
Як загальне рішення для інтеграції різнорідних конструкторсько-технологічних, виробничих, фінансових систем при організації “безпаперового” дослідно-серійного виробництва складних інженерних виробів ми пропонуємо розглянути систему APS-Інфосфера, створену колективами кількох українських компаній.
Передумови створення системи
Система APS-Інфосфера стала відповіддю на існуючі запити промислових підприємств. В період 2012-2014 рр. ряд великих підприємств, що займаються проектуванням і виробництвом складних інженерних виробів, сформував завдання якісного підвищення ефективності підготовки та запуску в виробництво нових зразків техніки, а також організації їх подальшого серійного випуску.
Складність виконання такого завдання підвищувалася за рахунок цілого ряду факторів:
- терміни створення та впровадження пропонованих програмних рішень були кінцевими та гранично стислими;
- впровадження нових технологій не повинно було призводити до зниження існуючого рівня виробництва;
- спектр систем автоматизації різних розділів проектування, виробництва, матеріально-фінансового управління формувався на підприємствах протягом десятиліть. При цьому частина систем, морально застарілих з технічної точки зору, свої функціональні завдання якось виконувала, обслуговувалася навченим персоналом і, на думку керівництва, їх заміна не була першочерговим завданням;
• сучасна ідеологія супроводу життєвого циклу виробів (ЖЦВ) та організації пост продажного обслуговування вимагала створення та відслідковування інформації за кожним примірником виробленої продукції; - посилення вимог до скорочення термінів і підвищення економічної ефективності виробництва визначало необхідність багатосторонньої інтеграції діяльності конструкторських, технологічних, виробничих і матеріально-фінансових підрозділів для організації оптимальних процесів планування.
Задоволення перерахованого списку побажань не виглядало тривіальним завданням. Першою природною реакцією з нашого боку була спроба переконати підприємства, що еліксиром успіху може стати впровадження чергової системи, здатної охопити весь обсяг існуючих завдань. Однак тривале глибоке обговорення з представниками замовника алгоритмів функціонування створюваних рішень привело нас до розуміння, що існуючі комерційні рішення забезпечать “біг по колу” з вкрай сумними перспективами досягнення необхідного результату в осяжному майбутньому.
Схожість запитів різних компаній підштовхувала до думки про необхідність створення спеціалізованого інтеграційного рішення для нового великого пласта завдань. Важливим фактором, що сприяє системності при створенні рішення, була початкова необхідність стикування декількох PDM / PLM-систем, різних систем технологічної підготовки, різновікових та різноформатних інформаційних програм і баз даних, а також самостійно розроблених підприємствами систем.
Принцип побудови – керуючий Web-концентратор
Сучасний рівень розвитку інформаційних технологій однозначно визначив платформу для створення нового рішення – Web-середовище консолідації та управління даними і процесами в рамках повного комплексу завдань, вирішення яких необхідне для успішного конструювання, технологічної підготовки виробництва (ТПВ), виробництва та супроводу виробу.
По суті, таку систему можна назвати керуючим веб-концентратором.
Технічна реалізація такого рішення передбачає:
- опору на XML-формати для забезпечення міжсистемного (і, найчастіше, міжмодульного) узгодження.
Для внутрішнього зберігання даних передбачена змішана модель, в рамках якої, в основному, використовується XML-формат, але для атрибутів, які часто задіюються при формуванні вибірок, застосовані традиційні реляційні таблиці;
- широке використання веб-сервісів для реалізації необхідної функціональності складного розподіленого рішення. Для координації та синхронізації роботи сервісів служить подієвий механізм;
- принципова відмова від безпосередньої передачі об’ємних даних при міжсистемному узгодженні;
• використання триланкової структури додатків і сучасних методів створення екранних веб-інтерфейсів.
На кожному з цих моментів варто зупинитися докладніше та розглянути, яким чином ці фактори позначаються на ефективності та гнучкості системного рішення.
Використання для міжсистемного узгодження XML-форматів забезпечує необхідну “гнучкість” і “прозорість” інтерфейсів передачі даних.
“Гнучкість” інтерфейсів надає службам підприємства унікальну можливість самим вибирати, в яких спеціалізованих системах їм працювати. У підсумку, всі служби працюють з тими інструментами, які їм звичні та зручні.
“Прозорість” інтерфейсів полягає в тому, що будь-який зацікавлений користувач має можливість, у разі необхідності, проконтролювати дані, які були прийняті з суміжної системи.
Зробити це він може в зручній для нього формі, без обов’язкового використання спеціального програмного інструментарію та без обов’язкового володіння навичками програмування. Як наслідок, надзвичайно швидко відшукуються помилки переданих даних і джерела їх виникнення, шліфуються моделі даних і бізнес-правила їх обробки, що дозволяє забезпечити поєднання промислової експлуатації систем з процесами їх доопрацювання.
Опора на XML
Використання XML-форматів для внутрішнього представлення дозволяє відносно легко вносити зміни в модель даних, причому, робити це “на льоту”, не виводячи систему з режиму промислової експлуатації.
Застосування традиційної реляційної бази даних змушує, навіть у разі незначних змін складу та структури атрибутів (а це означає зміну структури бази даних), вносити численні правки в вихідний код.
Web-сервіси
Використання веб-сервісів забезпечує одне з основних переваг сучасних технологій веб-програмування. При цьому підході функціональні модулі складної системи можуть бути “розкидані” по різним веб-серверам корпоративної мережі підприємства, розроблятися та підтримуватися різними групами (службами) програмістів.
Для прикладного програміста абсолютно необов’язково знати внутрішній устрій сервісу. Від нього вимагається грамотна організація взаємодії сервісів на рівні “вхід – вихід” (вірніше, “запит – результат”).
Такий підхід використання стандартних засобів розробки та супроводу системи гарантує можливість підприємству-замовнику самостійно підтримувати, модернізувати створене рішення, знімає залежність від розробника.
Відмова від передачі об’ємних даних
Відсутність необхідності пересилати об’ємні дані при міжсистемному узгодженні означає наступне. Замість того, щоб ганяти власне об’ємні дані з системи в систему та з модуля в модуль, передаються виключно посилання на них. Універсальність і “об’єктність” веб-посилань роблять цей механізм особливо ефективним і привабливим.
Яскравий та дуже показовий приклад – робота зі всілякими 3D-моделями в електронному вигляді. Загальновідомо, що обсяг складної 3D-моделі може досягати декількох десятків гігабайт, і масова передача такого обсягу інформації з системи в систему може з’їсти всі обчислювальні та мережеві ресурси підприємства.
Як ідуть справи при передачі посилання на 3D-модель?
Цей об’ємний об’єкт постійно “живе” там, де йому належить бути – в тій системі, в якій був породжений. Найчастіше для цих цілей використовуються “файлові сховища”, але в принципі веб-посилання може бути організоване на інформаційний об’єкт будь-якого типу.
Замість передачі величезного файлу (файлів) передається невелике посилання на цю 3D-модель – розмір посилання становить кілька десятків байт. Як то кажуть, відчуйте різницю!
Якщо у користувача, наприклад, технологічної системи виникла потреба подивитися 3D-модель, він активізує передане йому посилання (наприклад, подвійним “кліком” миші). При цьому автоматично запускаються програмні засоби доступу до цього об’єкта. Зазвичай, це полегшені програми-переглядачі (Viewers), але через брак таких (або коли фірмі нікуди дівати гроші) може бути використана повнофункціональна система.
Результатом такого підходу є економне витрачання обчислювальних ресурсів (а це – гроші, працездатність і швидкодія системи в цілому) і гарантія того, що користувачеві завжди надаються дійсно актуальні дані (з урахуванням всіх проведених змін).
Триланкова структура додатків
Використання багатоланкової структури додатків і сучасних методів побудови екранних веб-інтерфейсів відноситься до категорії кращих практик веб-програмування.
Відзначимо основні переваги такого підходу:
- для роботи з системою на робочому місці користувача не потрібно встановлювати спеціалізоване клієнтське ПЗ;
- всі доопрацювання, вироблені розробником, миттєво стають “видимими” всім користувачам (звичайно, в залежності від їх прав доступу);
- інструментальні засоби інтерфейсів системи впізнавані для користувачів, так як використовуються звичайні веб-компоненти, знайомі багатьом за повсякденною роботою в інтернеті;
- графічне представлення даних відокремлено від процедур їх обробки, що робить технічно можливим організувати різні екранні інтерфейси для різних груп користувачів.
Важливо відзначити, що веб-орієнтована система є корпоративною в повному розумінні цього слова. Будь-який авторизований користувач може ввійти в цю систему з будь-якого робочого місця, підключеного до корпоративної обчислювальної мережі підприємства.
Кількість одночасних підключень практично не обмежена (її обмежують тільки потужності веб-серверів, і при необхідності кількість можна збільшити до кількох тисяч). А це означає, що система може використовуватися будь-якими службами підприємства в будь-якому місці та в будь-який час, коли їм це знадобиться.
Резюмуючи, можна стверджувати, що в веб-середовищі, яке виконує роль “концентратора”, накопичується актуальна інформація у відповідності з усіма етапами життєвого циклу виробу. Супроводжується кожен екземпляр виробів, що виробляються. При цьому зберігаються не файли (об’ємні дані), а тільки актуальні посилання (URL) на них. Самі ж об’ємні дані зберігаються та відслідковуються в тих системах, в яких вони були створені. Механізм посилань дозволяє надавати користувачеві виключно актуальну інформацію: змінив конструктор об’єкт – змінилося і посилання.
В процесі проведення конструкторської зміни це посилання оновлюється в усіх пов’язаних системах, і всі “учасники” процесів ЖЦВ бачать цю зміну.
Як це працює?
Керуючий веб-концентратор в рамках єдиного рішення інтегрує:
- конструкторські PDM / PLM-системи;
- технологічні системи рівня служб головного технолога;
- технологічні та виробничі системи рівня служб цеху;
- системи підтримки випробувань і ВТК;
- АСУВ і / або ERP-системи.
1. Етап конструювання
У більшості конструкторських підрозділів в останні роки закріпилася культура роботи в PDM / PLM-системах. Конструктори проектують вироби та компоненти виробів (деталі иа збірні одиниці – ДЗО) в середовищі PDM / PLM за затвердженими методиками й уточнюють їх шляхом випуску повідомлень про зміни (ПЗ). Формується база даних проекту, в якій зберігається вся необхідна для виготовлення та приймання виробу інформація, з урахуванням варіативності виконань – опціонності.
Наявність всієї цієї інформації дозволяє сконфігурувати будь-який екземпляр виробу або серію однакових примірників.
Будь-яка сучасна PDM-система володіє стандартною функцією для вивантаження даних проекту в форматі PLM-XML. Цей формат надлишковий і містить повну інформацію про всі без винятку об’єкти проекту та їхні зв’язки. Це величезні обсяги інформації з дуже складною структурою. Спеціальна “утиліта публікації” виокремлює з усього обсягу даних PLM-XML тільки ті дані, які дійсно потрібні для наступних етапів ЖЦВ, спрощує їх шляхом використання посилань і публікує спрощені дані в узгодженому форматі XML – відправляє в керуючий веб-концентратор.
В результаті:
- конструктор працює в звичному для себе середовищі;
- проект містить всю необхідну інформацію по виробу;
- актуальність виробу конструктор підтримує шляхом випуску ПЗ.
2. Етап технологічної підготовки виробництва
Наповнення компонентів конструкторської структури технологічними даними може здійснюватися двома способами.
Перший варіант (на наш погляд, більш правильний) – технологічні дані вносяться технологами в середовищі PLM-системи. У цьому випадку служба конфігурації публікує (відправляє в керуючий веб-концентратор) вже сконфігуровані конструкторсько-технологічні дані.
Однак на підприємствах такий підхід поширений мало. Значно популярнішим є варіант з використанням існуючої на підприємстві технологічною САПР. В цьому випадку для консолідації структури конструкторсько-технологічних даних залучається модуль нашої системи під назвою “Запуск КД у виробництво”. Його функція – доповнити, на основі сформованих в САПР ТП підприємства даних, всі компоненти конструкторського складу технологічними атрибутами.
Сервіс модуля “Запуск КД у виробництво” викликається після публікації на ресурсі APS-Інфосфера конструкторського документа випуску зі пов’язаної з ним структурою виробу або його частини.
При цьому генеруються необхідні замовлення засобів технологічного оснащення (ЗТО) і обробки на верстатах з ЧПУ, які потім публікуються (шляхом виклику відповідних сервісів) у самостійні обліково-реєстраційні системи ЗТО та ЧПУ, де й організовані відповідні процеси. У паспорті замовлення присутні актуальні посилання на конструкторсько-технологічні файли, необхідні для проектування ЗТО або ЧПУ-обробки.
В результаті технологічного опрацювання кожен елемент опублікованої структури доповнюється атрибутами: расцеховка, умови поставки, зразки, технологічні припуски, трудові та матеріальні норми, посилання на необхідні файли (включаючи створені запити виробництва (ЗВ) та ін.), посилання на ЗТО, ЧПУ. При відсутності на підприємстві необхідних систем автоматизації, для створення комплексного рішення можна використовувати модулі САПР-Т системи APS-Підприємство, а також модулі Уіст та УіЧПУ, тісно інтегровані з системою APS-Інфосфера.
В результаті (при будь-якому варіанті) в архіві “концентратора” накопичується актуальна “концентрована” конструкторсько-технологічна інформація по кожному окремому екземпляру виробу. Як було зазначено вище, об’ємні дані (сукупність файлів) не вивантажуються, а формуються актуальні посилання на них.
Модуль формування виробничого складу (МФВС) пов’язаний з архівом концентратора. Виходячи з вказівок директивного планування, формується документ запуску (д / з) у виробництво (замовлення, вказівка, службова записка і т.п.) і пов’язана з ним електронна структура “що виготовити по д / з”. Вона створюється на основі наявної в архіві “концентратора” структури “що спроектовано” та враховує випереджаючий запуск, “недобудову” і т.д.
Для організації матеріально-технічного забезпечення проводиться опрацювання сформованої “порції” документа запуску. За допомогою спеціального сервісу для відповідної системи готується вся необхідна інформація. Після опрацювання отриманих даних система забезпечення повертає (засобами відповідного сервісу) по кожній ДЗО інформацію про забезпеченість цієї ДЗО матеріалами.
Аналогічним чином здійснюється інтеграція з системами оперативного планування виробництва.
3. Етап виробництва
На цьому етапі в APS-Інфосфера використовується спеціальна обліково-реєстраційна цехова система (ОРСЦ). Розглянемо її роботу докладніше.
Після формування документа запуску у виробництво та доповнення його планово-диспетчерськими й постачальними атрибутами, система сервісів викликає сервіс ОРСЦ і передає в неї через узгоджений формат XML всю атрибутивну інформацію по д / з. В першу чергу, це загальна частина д / з (паспорт) з загальними атрибутами – позначення д/ з, фін. замовлення, номер (а) виробу, останні ПЗ і т.п.
Крім того, до д / з приєднується відомість всіх ДЗО, які необхідно виготовити за цим д / з. Кожна ДЗО цієї відомості має всі конструкторсько-технологічні атрибути,
включаючи актуальні посилання на конструкторсько-технологічні файли. Позначення ДЗО – це посилання на актуальний об’єкт конструкторського проекту. Подвійний клік дозволить перейти на цю ДЗО в структурі проекту: там сконцентрована вся актуальна інформація по ній, включаючи посилання на електронні моделі, технічні вимоги, посилання, що дозволяють отримати повну інформацію по ЧПУ, ЗТО та ін.
Таким чином, через звичайний мережевий комп’ютер виробництво має доступ до всієї актуальної інформації по ДЗО, що виготовляються. Система ОРСЦ надає користувачам конкретного цеху всю інформацію згідно “расцеховки”, а також дозволяє долучити створені виробничі дані до конкретної ДЗО (ТП, ТУ, технологічні ескізи і т.п.).
Система ОРСЦ складається з декількох підсистем, що відповідають структурним підрозділам цехів: ТБ (технологічне бюро), ПДБ (планово-диспетчерське бюро), БТК (бюро технічного контролю), ПРОСК.
Розглянемо принцип роботи підсистем на прикладі підсистеми ОРСЦ-ТБ. Основне завдання техбюро цеху – розробити повний комплект робочої технологічної документації (поняття “комплект документації” трансформується з переходом до електронного вигляду, але це предмет окремої розмови). ОРСЦ-ТБ надає фахівцям ТБ всю актуальну інформацію по ДЗО, що виготовляються в цеху. В рамках д / з начальник ТБ на кожну ДЗО призначає відповідальних технологів і термін виконання роботи. Отримавши своє завдання (завдання він бачить на екрані комп’ютера), технолог починає проектувати опис техпроцесу, дозамовляти ЗТО і т.д.
Система, з одного боку, надає йому всю необхідну інформацію, з іншого – дає можливість причепити створену ним інформацію до “об’єктного” посилання ДЗО, для якої вона призначена. Наприклад, проектування техпроцесу може відбуватися вручну (за допомогою текстового редактора) або з використанням САПР ТП. У першому випадку ОРСЦ-ТБ автоматично генерує для технолога необхідні форми із заповненими полями, на які є атрибутивна інформація в системі, і дозволяє зберегти вже розроблений документ в свій архів – при цьому автоматично створюється посилання на нього, пов’язане з тією ДЗО, на яку проектувався техпроцес.
Точно так само формуються пов’язані посилання на інші документи – в тому числі на операційні ескізи, створені технологом по анотованій електронної моделі ДЗО.
У разі використання технологом будь-якої САПР ТП, підсистема ОРСЦ-ТБ передає в неї необхідну інформацію через сервіс. Вся робота виконується в середовищі цієї САПР ТП, і створена інформація зберігається в її архіві – до ДЗО, для якої ця технологічна інформація створювалася, приєднується тільки посилання (наприклад, у вигляді позначення ТП).
Спроектована технологія, після її затвердження начальником ТБ, приєднується до проекту та стає доступна з будь-якого робочого місця обчислювальної мережі підприємства – відповідно до прав доступу. Для подальшої роботи ПДБ досить накопиченої в проекті інформації. При цьому підсистема надає в ПДБ тільки ту інформацію, яка необхідна конкретному ПДБ, автоматизує отримання певних форм, дозволяє приєднувати свої документи (наприклад, завдання майстру і т.п.), вводити додаткові атрибути.
Точно так само працюють і підсистеми БТК і ПРОСК.
4. Облік змін
З вищевикладеного видно, що в системі веб-концентратора для будь-якої ДЗО є вся актуальна інформація на конкретний екземпляр, накопичена на різних етапах життєвого циклу. Система відстежує всі зміни. Якщо конструктор, шляхом випуску ПЗ, змінив ДЗО (випустив нову її ревізію), то за подією “твердження ПЗ” відбувається переконфігурування конструкторської частини проекту.
У структурі даних зникає “об’єктне” посилання на ДЗО з ревізією “0” і з’являється нова – з ревізією “1”. Система сервісів переопубліковує (тобто посилає за заздалегідь описаним сценарієм в усі використовувані на різних етапах життєвого циклу системи) це актуальне на даний момент посилання (старе зникає), із зазначенням ПЗ. Природно, в д / з до нового “об’єктного” посилання будуть приєднані тільки конструкторські атрибути, а атрибути з інших етапів (в тому числі операційні ескізи) будуть відсутні – вони зберігаються в архівах тих систем, де створювалися, але в проекті посилань на них не буде.
Всім учасникам проекту доведеться заново ввести свою інформацію, або “приєднати” стару, якщо вона актуальна і для цієї ревізії. Але, по суті, це автоматизована проводка ПЗ. Інтерфейс дозволяє побачити всі основні дані по етапах і забезпечує, через відповідні веб-посилання, перехід у будь-яку систему для отримання докладної інформації. Наприклад, якщо технологічне оснащення ще не виготовлене, то, при переході за відповідним посиланням ЗТО, можна побачити, на якій стадії воно знаходиться. У будь-який момент часу можна отримати будь-який об’єктивний звіт про стан проекту, окремого агрегату, окремої ДЗО.
5. Етапи випробовувань, ВТК
Функціонал представленого програмного комплексу дозволяє підключати підсистеми з обліку випробувань виробів та взаємодії зі службою ВТК. Надається можливість “прикріплювати” свої документи: акти, протоколи, запити. Якщо в веб-середовищі концентратора будуть актуальні посилання на експлуатаційну документацію (неважливо, за допомогою якого інструментарію вона отримана), то доступ до неї буде забезпечений з будь-якої точки.
6. Взаємодія з ERP-системами
Інтеграція з широким класом ERP-систем забезпечується за тим же принципом, що і з перерахованими вище системами. Підсистеми ERP отримують необхідну для їх роботи актуальну інформацію про вироби з “концентратора” – шляхом відповідного запиту, через узгоджений формат XML. Результати своєї роботи віддають назад у вигляді атрибутів (якщо вони необхідні в проекті або якщо до них необхідно організувати доступ через веб-посилання з будь-якого робочого місця в мережі підприємства).
Як наслідок:
- у “концентраторі” інтегрується вся актуальна інформація на кожен екземпляр виробів;
- доступ до цієї інформації надається (з урахуванням прав користувача) з будь-якого комп’ютера обчислювальної мережі підприємства (інтранет) за допомогою актуальних веб-посилань;
- засобами системи сервісів надає учасникам проекту можливість долучити до проекту свої атрибути;
- реалізуються процедури підтримки актуальності проекту – в нього включаються тільки актуальні дані на конкретний екземпляр виробів;
- стає можливим організувати бізнес-процес переходу з етапу на етап життєвого циклу вироби.
В цілому, рішення на платформі APS-Інфосфера дозволяє в стислі терміни забезпечити інтеграцію інформаційних процесів і ресурсів підприємства для створення ефективної системи електронного виробництва та супроводу виробів.
М.О. Ляшенко (ДП “Антонов”), О.Г. Парамонов (ПАТ “Аркада”), О.Ю. Попов (ДП “Антонов”), О.В. Петренко (ТОВ “A-Prosystem”)