Эта статья написана под влиянием исследования Джима Брауна (Jim Brown) “Как передовые компании осуществляют, используют и поддерживают PLM-интеграцию” (Observer #1/2017). Поднятые в этой работе вопросы наглядно показывают, что успешная организация так называемого электронного производства достигается обеспечением связи между разнородными рабочими процессами на предприятии и эффективным использованием данных, создаваемых в различных корпоративных программных системах.
Внедрение информационной системы, обеспечивающей концентрацию данных и управление ими в рамках производственных процессов, является актуальной задачей для широкого круга предприятий. Сегодня информационный ландшафт большинства компаний определяется “зоопарком” практически не связанных между собой систем, выполняющих свои функции в соответствующих производственных нишах. Следствия такой лоскутной автоматизации – многократный ввод одинаковой информации, несогласованность между службами – определяют временные и финансовые потери, нивелируют рост эффективности от применения Ай-Ти. Многие предприятия признают проблему, но это еще не означает понимания ими путей её решения.
В качестве общего решения для интеграции разнородных конструкторско-технологических, производственных, финансовых систем при организации “безбумажного” опытно-серийного производства сложных инженерных изделий мы предлагаем рассмотреть систему APS-Инфосфера, созданную коллективами нескольких украинских компаний.
Предпосылки создания системы
Система APS-Инфосфера стала ответом на существующие запросы промышленных предприятий. В период 2012–2014 гг. ряд крупных предприятий, занимающихся проектированием и производством сложных инженерных изделий, сформировал задачу качественного повышения эффективности подготовки и запуска в производства новых образцов техники, а также организации их дальнейшего серийного выпуска.
Сложность выполнения такой задачи повышалась за счет целого ряда факторов:
• сроки создания и внедрения предлагаемых программных решений были конечными и предельно сжатыми;
• внедрение новых технологий не должно было приводить к снижению существующего уровня производства;
• спектр систем автоматизации различных разделов проектирования, производства, материально-финансового управления формировался на предприятиях на протяжении десятилетий. При этом часть систем, морально устаревших с технической точки зрения, свои функциональные задачи как-то выполняла, обслуживалась обученным персоналом и, по мнению руководства, их замена не была первоочередной задачей;
• современная идеология сопровождения жизненного цикла изделий (ЖЦИ) и организации постпродажного обслуживания требовала создания и отслеживания информации по каждому экземпляру производимой продукции;
• ужесточение требований к сокращению сроков и повышению экономической эффективности производства определяло необходимость многосторонней интеграции деятельности конструкторских, технологических, производственных и материально-финансовых подразделений для организации оптимальных процессов планирования.
Удовлетворение перечисленного списка пожеланий не выглядело тривиальной задачей. Первой естественной реакцией с наше стороны была попытка убедить предприятия, что эликсиром успеха может стать внедрение очередной системы, способной охватить весь объем существующих задач. Однако длительное глубокое обсуждение с представителями заказчика алгоритмов функционирования создаваемых решений привело нас к пониманию, что существующие коммерческие решения обеспечат “бег по кругу” с крайне печальными перспективами достижения необходимого результата в обозримом будущем. Схожесть запросов различных компаний подталкивала к мысли о необходимости создания специализированного интеграционного решения для нового обширного пласта задач. Важным фактором, способствующим системности при создании решения, была изначальная необходимость стыковки нескольких PDM/PLM-систем, различных систем технологической подготовки, разновозрастных и разноформатных информационных программ и баз данных, а также самостоятельно разработанных предприятиями систем.
Принцип построения – управляющий Web-концентратор
Современный уровень развития информационных технологий однозначно определил платформу для создания нового решения – Web-среда консолидации и управления данными и процессами в рамках полного комплекса задач, решение которых необходимо для успешного конструирования, технологической подготовки производства (ТПП), производства и сопровождения изделия.
По сути, такую систему можно назвать управляющим веб-концентратором.
Техническая реализация такого решения предполагает:
• опору на XML-форматы для обеспечения межсистемного (и, зачастую, межмодульного) согласования.
Для внутреннего хранения данных предусмотрена смешанная модель, в рамках которой, в основном, используется XML-формат, но для атрибутов, которые часто задействуются при формировании выборок, применены традиционные реляционные таблицы;
• широкое использование веб-сервисов для реализации необходимой функциональности сложного распределенного решения. Для координации и синхронизации работы сервисов служит событийный механизм;
• принципиальный отказ от непосредственной передачи объемных данных при межсистемном согласовании;
• использование трехзвенной структуры приложений и современных методов создания экранных веб-интерфейсов.
На каждом из этих моментов стоит остановиться подробнее и рассмотреть, каким образом эти факторы сказываются на эффективности и гибкости системного решения.
Использование для межсистемного согласования XML-форматов обеспечивает необходимую “гибкость” и “прозрачность” интерфейсов передачи данных.
“Гибкость” интерфейсов предоставляет службам предприятия уникальную возможность самим выбирать, в каких специализированных системах им работать. В итоге, все службы работают с теми инструментами, которые им привычны и удобны.
“Прозрачность” интерфейсов заключается в том, что любой заинтересованный пользователь имеет возможность, в случае необходимости, проконтролировать данные, которые были приняты из смежной системы.
Сделать это он может в удобной для него форме, без обязательного использования специального программного инструментария и без обязательного обладания навыками программирования. Как следствие, необычайно быстро отыскиваются ошибки передаваемых данных и источники их возникновения, шлифуются модели данных и бизнес-правила их обработки, что позволяет обеспечить совмещение промышленной эксплуатации систем с процессами их доработки.
Опора на XML
Использование XML-форматов для внутреннего представления позволяет относительно легко вносить изменения в модель данных, причем, делать это “на лету”, не выводя систему из режима промышленной эксплуатации.
Применение традиционной реляционной базы данных вынуждает, даже в случае незначительных изменений состава и структуры атрибутов (а это означает изменение структуры базы данных), вносить многочисленные правки в исходный код. Однако XML-файлы база данных сохраняет в виде относительных независимых объектов, и изменение структуры и/или состава этих объектов минимально сказывается на функционировании системы в целом, что позволяет делать необходимые правки без риска потери её работоспособности.
Web-сервисы
Использование веб-сервисов обеспечивает одно из основных преимуществ современных технологий веб-программирования. При этом подходе функциональные модули сложной системы могут быть “разбросаны” по различным веб-серверам корпоративной сети предприятия, разрабатываться и поддерживаться различными группами (службами) программистов.
Для прикладного программиста абсолютно необязательно знать внутреннее устройство сервиса. От него требуется грамотная организация взаимодействия сервисов на уровне “вход – выход” (вернее, “запрос – результат”).
Такой подход использования стандартных средств разработки и сопровождения системы гарантирует возможность предприятию-заказчику самостоятельно поддерживать, модернизировать созданное решение, снимает зависимость от разработчика.
Отказ от передачи объемных данных
Отсутствие необходимости пересылать объемные данные при межсистемном согласовании означает следующее. Вместо того чтобы гонять собственно объемные данные из системы в систему и из модуля в модуль, передаются исключительно ссылки на них. Универсальность и “объектность” веб-ссылок делают этот механизм особенно эффективным и привлекательным.
Яркий и очень показательный пример – работа со всевозможными 3D-моделями в электронном виде. Общеизвестно, что объем сложной 3D-модели может достигать нескольких десятков гигабайт, и массовая передача такого объема информации из системы в систему может съесть все вычислительные и сетевые ресурсы предприятия.
Как обстоят дела при передаче ссылки на 3D-модель?
Этот объемный объект постоянно “живет” там, где ему положено быть – в той системе, в которой был порожден. Чаще всего для этих целей используются “файловые хранилища”, но в принципе веб-ссылка может быть организована на информационный объект любого типа.
Вместо передачи огромного файла (файлов) передается небольшая ссылка на эту 3D-модель – размер ссылки составляет несколько десятков байт. Как говорится, почувствуйте разницу!
Если у пользователя, например, технологической системы возникла потребность посмотреть 3D-модель, он активизирует переданную ему ссылку (например, двойным “кликом” мыши). При этом автоматически запускаются программные средства доступа к этому объекту. Обычно, это облегченные программы-просмотрщики (Viewers), но за неимением таковых (или когда фирме некуда девать деньги) может быть использована полнофункциональная система.
Результатом такого подхода является экономное расходование вычислительных ресурсов (а это – деньги, работоспособность и быстродействие системы в целом) и гарантия того, что пользователю всегда предоставляются действительно актуальные данные (c учетом всех проведенных изменений).
Трехзвенная структура приложений
Использование многозвенной структуры приложений и современных методов построения экранных веб-интерфейсов относится к категории лучших практик веб-программирования.
Отметим основные преимущества такого подхода:
• для работы с системой на рабочем месте пользователя не требуется устанавливать специализированное клиентское ПО;
• все доработки, производимые разработчиком, мгновенно становятся “видны” всем пользователям (естественно, в зависимости от их прав доступа);
• инструментальные средства интерфейсов системы узнаваемы для пользователей, так как используются обычные веб-компоненты, знакомые многим по повседневной работе в интернете;
• графическое представление данных отделено от процедур их обработки, что делает технически возможным организовать разные экранные интерфейсы для разных групп пользователей.
Важно отметить, что веб-ориентированная система является корпоративной в полном смысле этого слова. Любой авторизованный пользователь может войти в эту систему с любого рабочего места, подключенного к корпоративной вычислительной сети предприятия.
Количество одновременных подключений практически не ограничено (его ограничивают только мощности веб- серверов, и при необходимости количество можно увеличить до нескольких тысяч). А это означает, что система может использоваться любыми службами предприятия в любом месте и в любое время, когда им это понадобится.
Резюмируя, можно утверждать, что в веб-среде, выполняющей роль “концентратора”, накапливается актуальная информация в соответствии со всеми этапами жизненного цикла изделия. Сопровождается каждый экземпляр производимых изделий. При этом хранятся не файлы (объемные данные), а только актуальные ссылки (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”)