Архів на базі PDM

1. У цій статті нам хотілося б поділитися з читачами деякими напрацюваннями, отриманими в ході практичного...
2. Вимоги до системи «Електронний Архів»
3. Вимоги до системи «Документообіг з підтримкою життєвого циклу»
4. Вимоги до системи PDM
5. Вимоги до системи управління конфігурацією
6. Концепція об'єктів поліетиленових пакетів

17.10.2002 В'ячеслав Климов, Володимир Краюшкин, Марина Пирогова

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

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

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

Значно підвищуючи продуктивність праці на кожному окремому робочому місці, системи проектування зборок дозволяли об'єднувати результати роботи конструкторів в рамках єдиної інформаційної тривимірної моделі збірки. Однак в подальшому приріст ефективності інформаційного забезпечення та автоматизації процесів виробництва нової техніки зв'язувався вже з системами PDM (product data management - «управління даними про виріб»), що виходять за рамки конструкторських підрозділів. Сьогодні намічається перехід від PDM до корпоративних систем PLM (product lifecycle management - «управління життєвим циклом вироби»), що враховує процеси, виконавців, етапність виробництва і відкритим для інтеграції даних з інших систем і інших підприємств. У цих нових умовах «вартість» кожного кроку значно зростає, зростає і відповідальність за рішення на кожному з них. При цьому посилюється прагнення підприємства вибирати таку послідовність кроків створення корпоративної інформаційної системи ( «стратегію впровадження»), при якій кожен крок, починаючи з першого, мав би самостійну цінність і достатню приватну функціональність.

Строго кажучи, виникає наступна проблема: «зайти» на підприємство з розробленою стратегією впровадження корпоративної інформаційної системи, щоб і підприємство було зацікавлене, і постачальник міг запропонувати гідне приватне рішення, і рішення було б повністю в руслі задуманої і реалізованої стратегії. До початку XXI століття на вітчизняних підприємствах вже склалися ті чи інші «переваги» по САПР, СУБД, операційним системам і структурам даних, тому «візит» з цих позицій втратив свою новизну і ефективність. З одного боку, постачальники в цих областях можуть запропонувати досить обмежений набір рішень корпоративного рівня, які часом, через ринкової війни розробників, вимагають заміни нехай застарілих, але працюють приватних рішень. З іншого боку, підприємства «самі з вусами», не звертають уваги на резони розробників. В таких умовах важливо, безпомилково і за згодою обох сторін, зробити перший крок до побудови дійсно сучасної розподіленої корпоративної інформаційної системи.

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

Вимоги до системи «Електронний Архів»

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

Архів Технічної Документації забезпечує зберігання, інвентаризацію, облік видачі і контроль використання технічної документації, отриманої в результаті використання цієї функції. До такого роду додатків відносяться системи автоматизованої підготовки даних та системи автоматизованого проектування. САПР можуть готувати електронне подання креслярсько-конструкторської документації або в своїх внутрішніх форматах, або в форматах, стандартизованих для різних САПР: IGES, STEP для тривимірних моделей і dwg для двовимірних даних. Автоматизовані системи підготовки даних можуть використовувати СУБД, офісні додатки, текстові формати, формати позиціонуються полів виводу (звіти баз даних, електронні таблиці).

Архів розпорядчої документації забезпечує зберігання, інвентаризацію, облік видачі і контроль використання розпорядчої документації, отриманої в результаті роботи офісних додатків. До такого роду додатків відносяться Word, Access, Excel, Outlook, Adobe Acrobat, локальні системи розпорядчої документації в текстовому вигляді (АСУ РД). Системи такого роду можуть використовувати СУБД, офісні додатки, текстові формати, формати позиціонуються полів виводу (звіти баз даних, електронні таблиці), формат Postcrypt.

Науково-Технічний Архів забезпечує зберігання, інвентаризацію, облік видачі і контроль використання розпорядчої документації, отриманої в результаті роботи офісних додатків і додатків роботи зі сканованими документами (сканування, очищення, оцифровка і т.д.). До такого роду додатків відносяться Word, Access, Excel, Outlook, PowerPoint, Paint, CorelDraw, Adobe Photoshop. Автоматизовані системи підготовки такого роду даних можуть використовувати СУБД, офісні додатки, текстові формати, формати позиціонуються полів виводу (звіти баз даних, електронні таблиці), формати сканованих зображень (JPEG, GIF, TIFF, BMP), формат Postcript.

Необхідно відзначити також, що у всіх трьох випадках в перспективі потрібно орієнтуватися на необхідність архівування мережевих даних.

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

Ще одна важлива вимога до Електронного Архіву полягає в наступному: він повинен автоматично або автоматизовано розподіляти зберігаються виробничі дані відповідно до їх призначення. У нашому випадку це означає, що дані можуть передаватися в Електронний Архів і братися з нього автоматично і безпосередньо з третіх систем. В першу чергу це відноситься до САПР. Можливість розрахованої на багато користувачів роботи з масовими даними САПР, наприклад, робота колективу конструкторів із створення збірки, в сучасних технологіях називається WorkGroupManagement. Якість реалізації або універсальність поліетиленових пакетів тим вище, ніж з великим набором прикладних САПР він може взаємодіяти безпосередньо в такому режимі.

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

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

Електронний Архів повинен реалізовувати методику розподіленого зберігання. Ця вимога виникає при мережевої організації зберігання даних архіву і при постійному зростанні обсягу збережених даних.

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

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

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

Вимоги до системи «Документообіг з підтримкою життєвого циклу»

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

Сучасна система електронного документообігу та інтегрована з нею система підтримки життєвого циклу виробу повинна реалізовувати наступні основні функції:

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

Вимоги до системи PDM

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

Cистема PDM повинна реалізовувати наступні функції.

• Функція управління складом вироби, яка може бути представлена ​​сукупністю наступних можливостей: ведення специфікацій; багаторівневі специфікації, що відображають як дерево складання виробу, так і повний набір конструкторських, технологічних і інших атрибутів; динамічний перегляд ієрархічно організованою інформації; відстеження приналежності кожної деталі, збірки, вузла, вироби модельному ряду; визначення умов застосовності і відображення обмежень застосовності; ведення протоколів зміни версій аж до версій кожної деталі; відстеження дії внесених змін і модифікацій.
• Функція відстеження посилань на документи електронного архіву, відповідних кожної деталі, збірці, вузлу, виробу. Отримання даних безпосередньо з електронного архіву або безпосередньо з САПР збірок.
• Функція порівняння структур виробів, супровід і обслуговування інформації про виріб з урахуванням специфіки різних підрозділів, включаючи підприємства-співвиконавці (постачальники комплектуючих, субпідрядники) і зовнішні торговельні майданчики.
• Додаткові сервісні функції представлення тривимірних даних (геометричні електронні моделі вироби, деталі, збірки). Можливості візуалізації в системі PDM не повинні залежати від типів і форматів вихідних даних, що особливо актуально для підприємств, що використовують різнотипні САПР. Сама візуалізація повинна підтримувати рендеринг, анімацію, побудова перетинів і розрізів, ведення коментарів на зображенні і т.д.

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

Система управління конфігурацією вироби (configuration management - CM) забезпечує обмін даними про структуру вироби і вносяться в нього зміни, дозволяє створювати і підтримувати безліч взаємопов'язаних специфікацій на модифікації і виконання вироби ( «замовні специфікації»). Завдяки цьому користувач отримує узгоджене уявлення про всі зміни вироби по ходу роботи над ним. Система СM дає можливість різним корпоративних систем і користувачам визначати і контролювати дії по внесенню змін до виріб, тим самим спрощуючи процеси вдосконалення і модифікації вироби. Без сучасної системи СМ неможлива робота великого підприємства, що випускає широку номенклатуру виробів під різноманітні замовлення.

Система CM повинна реалізовувати наступні функції:

• создания и ведення Бази Даних по конструктивним рішенням базової лінійкі модельного ряду (базові КОМПЛЕКТАЦІЇ, базовий склад вироби и т.д.);
• создания и ведення керованих наборів взаємопов'язаніх спеціфікацій (конструкторських, технологічних и других) на всі Виконання и модіфікації вироби;
• автоматизовану систему проводки змін (Попереднє Повідомлення, Повідомлення, Бюлетень і т.д.) з повною підтримкою проводки зміни в структурі специфікацій і бази даних про склад виробу;
• автоматичне відстеження обмежень застосовності після затвердження внесеного зміни, автоматична генерація зміненої бази даних про склад виробу після внесення змін без перевипуску всього комплекту документації;
• відстеження приналежності до модельного ряду, можливість отримання актуального зрізу за списком деталей і документів з визначенням тих з них, які мають ключове значення для структури вироби;
• функцію порівняння і видачі розбіжностей за складом вироби в різних конфігураціях.

Концепція об'єктів поліетиленових пакетів

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

Для відображення посилань, які можуть мати документи архіву, об'єкт типу Документ поліетиленових пакетів (рис. 1) повинен мати можливість посилатися на інші об'єкти типу Документ поліетиленових пакетів. Так, документ «Інструкція по збірці» може мати посилання на зберігається окремо і навіть, можливо, в складі іншої структури документів, документ «Стандарти підприємства».

Для зберігання вмісту архівів 3D-моделей деталей, зборок, вузлів і агрегатів служить об'єкт «Деталь». У повнофункціональної реалізації концепції поліетиленових пакетів контент Деталі є власне тривимірну модель. Об'єкт Деталь може входити в структури, утворені такого роду об'єктами. Наприклад, Деталь «Складальна одиниця ААА» архіву технічної документації може складатися з декількох Деталей - «підзборки ААА1», «Деталь B1», «Деталь B2» і т.д., а кожна з цих Деталей, в свою чергу з Деталей більш нижнього рівня (Деталь «підзборки ААА1» може являти собою структуру, що включає в себе Деталі «підзборки АААА1», «Деталь С1», «Деталь С2» і т.д.). Входження такого роду повинні мати кількісний ознака, що відображає реальний склад збірок: стільки-то таких-то деталей в складі однієї збірки, стільки-то таких-то збірок в складі вироби і т.д.

Щоб отримати додаткову описову інформацію, не що ні в 3D-моделі, ні в структурі збірки, об'єкти типу Деталь повинні асоціюватися з об'єктами типу Документ поліетиленових пакетів, контент яких містить уточнення та роз'яснення для повного опису власне деталі.

Для відображення посилань, які можуть мати документи архіву, об'єкт типу Деталь поліетиленових пакетів повинен мати можливість посилатися на інші об'єкти типу Документ поліетиленових пакетів. Так, Деталь «Гвинт М4х1.5» може мати посилання на зберігається окремо і навіть, можливо, в складі іншої структури документів, документ «ГОСТ 14.876-78», контентом якого, в свою чергу, може бути опис стандартизованих різьбових з'єднань. Схематично вид об'єкта Деталь в концепції сучасного поліетиленових пакетів виробничих даних можна змалювати таку картину, як зображено на рис. 2.

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

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

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

В'ячеслав Клімов ( [email protected] ) - генеральний директор представництва PTC (Москва); Володимир Краюшкин ( [email protected] ) - провідний спеціаліст представництва РТС (Москва); Марина Пирогова ( [email protected] ) - доцент МЕІ.