Интеграция — «костыль» автоматизации
Формализация конструкторского состава
Формализация технологического состава
Интеграция и жизненный цикл подсистем
В настоящее время в сфере построения КИС на отечественных предприятиях наблюдается устойчивая тенденция к построению корпоративных решений, охватывающих, в том числе, процессы управления инженерными данными.
Идея действительно замечательная — получать наиболее полные и актуальные данные непосредственно от инженерных служб, что в целом положительно влияет на эффективность использования КИС.
Отдавая дань этой тенденции, многие поставщики на рынке информационных технологий дополняют свои комплексы подсистемами управления инженерными данными собственной разработки либо выступают с интегрированным решением совместно с партнерами.
В последнем и наиболее типичном случае неизбежно приходится разрабатывать сложные модули по интеграции различных приложений. При этом в лучшем случае поставщик решения умалчивает о возможных проблемах, а в худшем — сам бренд системного интегратора возводится в ранг конкурентного преимущества.
В данной статье читателю предлагается ознакомиться с некоторыми аспектами интеграции на стыке инженерных данных и убедиться в том, что это есть и будет «костыль», без которого, впрочем, в некоторых случаях не обойтись.
Формализация конструкторского состава
Конструкторский состав определяется прежде всего утверждаемым документом — спецификацией на изделие. Данный документ имеет очень сложную структуру, включающую, помимо перечня элементов и их атрибутивных признаков, описание их взаимосвязей, элементы графического оформления и комментарии разработчика. Спецификация на изделие в значительной мере позволяет реализовать конструктору его творческие способности, кратко и доступно изложить другим участникам свой проект.
Однако с точки зрения обработки данных конструкторская спецификация формализуется проблематично, даже если строго следовать требованиям соответствующих ГОСТов. Например, весьма сложно формализовать в графе «Примечание» такие записи, как «доп. зам. поз. 4 на поз. 13, 14 с доработкой диам. 20», или разбор сокращенных записей крепежа. Некоторые сложности представляет собой внедрение спецификации на поле чертежа, а также практика отступления многими предприятиями от общепринятых стандартов.
Для подготовки спецификаций в большинстве случаев используется специализированное приложение, поставляемое с системой CAD/CAM. Казалось бы, это должно улучшить ситуацию, но на деле этого не происходит, потому что задача подобного приложения — обеспечить комфортную работу конструктора, и любые вводимые ограничения приводят к снижению востребованности такого редактора, а отчасти и всего решения, что, разумеется, сказывается на продажах.
Проблема в том, что традиционно общепринятые стандарты не учитывали машинную обработку инженерных данных, а теперь сложившаяся практика очень сложно преодолевается, даже несмотря на происходящие в последнее время прогрессивные изменения в стандартах, касающиеся ведения электронных документов.
Поэтому на предприятиях при ОАСУ или ОГТ традиционно существуют службы, транслирующие «инженерную мысль» в данные для планирования и производства. Возникает вопрос: кто несет ответственность за введенную информацию в случае ошибки?
Следующая попытка формализации конструкторских данных — использование PDM-системы. Поставщики и системные интеграторы при помощи рекламных листовок позиционируют интеграцию со всеми известными CAD-системами как конкурентное преимущество, опуская подробное обсуждение данного вопроса.
Чаще всего интеграция CAD c PDM-системой подразумевает отработку лишь простых ситуаций, когда есть 3D-сборка или спецификация (или сборочный чертеж, содержащий объекты спецификации) и посредством вызова API можно получить записи из документа.
При этом в процессе интеграции остаются нерешенными следующие вопросы:
- комментарии и примечания, содержащие данные для технологов, производственников и планирования;
- объекты, которые явно по тем или иным причинам не указаны в 3D-сборке (потеря производительности или незначительные детали);
- возможные конфигурации и исполнения сборок (групповые спецификации);
- конфликт версий между существующими конструкторскими данными в PDM-системе и данными в CAD-системе;
- вложенная обработка спецификаций от головы изделия к конечным деталям.
Всё это приводит к тому, что передача данных из CAD в PDМ носит вспомогательный характер и ни один специалист не будет брать на себя ответственность за правильность состава, переданного в PDM-систему без окончательного его изучения в интерфейсе. Поэтому рекомендуется выполнять печать (если речь идет о твердом носителе) и утверждение только из интерфейса системы, в которой эти данные будут далее обрабатываться.
Важно понимать, что нет идеальной интеграции с CAD-системой. Ее исключительность надумана, и она играет вспомогательную роль. Но благодаря этому многие вендоры «продавливают» свои решения через конструкторские службы. Да, конструктор получает наиболее удобный, адаптированный к локальным нуждам инструмент, однако при этом нагрузка на остальные подразделения многократно возрастает. Выигрывая здесь «копейку», далее по информационной цепочке предприятие начинает терять «рубли».
Пример конструкторского документа
 |
|
Формализация технологического состава
Конструкторский состав — это стержень для подготовки производственно-технологического состава, который представляет собой главную ценность для планирования производства и деятельности предприятия в целом.
Кроме того что элементы конструкторского состава постепенно дополняются технологическими элементами, такими как маршруты изготовления, операции, оборудование, нормы времени и материалов, происходит изменение и дополнение первоначального конструкторского замысла вследствие его технологической проработки:
- замена ДСЕ на другие;
- замена используемых материалов;
- ввод новых позиций, таких как технологические ДСЕ, образцы для испытаний и т.д.;
- встречающийся метод реструктуризации конструкторского состава с помощью комплектовочных карт или технологических сборок.
При этом данные изменения могут носить временный либо частичный характер.
Пример технологического документа
Необходимо также упомянуть ситуацию, когда специфика продукции предполагает, что характеристики выпускаемого изделия изначально не ясны. Это определяется нестабильностью технологического процесса (например, производство конденсаторов).
Ссылки в техпроцессах на другие техпроцессы, в которых есть ссылки на другие техпроцессы, в которых есть ссылки на другие техпроцессы, в которых есть ссылки на другие техпроцессы…
Технологический процесс представляет собой текстовый документ, который с точки зрения формализации вполне доступен для разбора (в случае автоматизированного заполнения описания). Проблема лишь в существовании вложенных ссылок на другие техпроцессы, из которых заимствуются технологические последовательности (операции, переходы, оборудование и т.д.).
Это влечет необходимость формализации таких ссылок:
- где расположен искомый технологический документ;
- какой объем заимствованных данных;
- исключения.
Полноценная формализация технологических данных требует, чтобы разработка шла в специализированной САПР ТП, поддерживающей работу с базой ДСЕ и другими общезаводскими справочниками для формальной работы с групповыми и типовыми ТП. А это уже необходимость интеграции с PDM-системой или совместного использования БД о составе изделия в качестве подсистемы (встроенная в PDM САПР ТП).
Если предприятие планирует использовать САПР ТП, не встроенную в PDM, то следует «проверить на зуб» заявленную между ними интеграцию и, конечно, формирование технологических документов максимально выполнять из интерфейса PDM-системы.
Если рассматривать разработку технологии еще глубже, то мы выходим на процессы проектирования оснастки, что опять же связано с формализацией конструкторских данных.
Всё описанное ранее относится прежде всего к традиционному «отечественному» подходу управления КТПП. Многие системные интеграторы предлагают использовать импортные продукты, рассчитанные на несколько иные бизнес-процессы. При полном внед-рении в любом случае приходится предлагать решения, закрывающие «отечественную специфику», в результате чего получается некий суррогат, интеграция продуктов внутри которого должна быть подвергнута еще более тщательному исследованию.
|
|
Интеграция и изменения
Одновременно с вопросом формализации инженерных данных возникает задача поддержания их актуальности.
Актуальность данных определяет, насколько быстро введенные владельцем данных изменения станут доступны для других участников ЕИП, а следовательно, для различных интегрированных решений.
На актуальность инженерных данных влияют:
- конструкторские изменения;
- технологические изменения.
Инициировать изменения можно в любой службе, задействованной в ЖЦ изделий. Изменения оформляются в виде документов: извещений (ИИ, ДИ, ПИ, ДПИ, ПР) и разрешительных карточек.
Следует отметить, что в большинстве случаев изменения касаются очень многих участников ЕИП. Поэтому возникает необходимость обеспечения процесса изменения сложными согласованиями и утверждением. Вопрос согласования может осложняться тем, что владельцем или получателем документации является другое предприятие, находящееся вне доступа по электронной связи, либо предприятие, работающее по кооперации.
Следовательно, при интеграции продуктов требуется решить вопрос о том, как согласовать изменения с другими участниками ЕИП, что делать с существующими данными (удалить, перевести в старую версию, отменить), как поступить со связанными данными.
Таким образом, при интеграции нужно обеспечить:
- передачу согласования изменения;
- получение обратной связи;
- создание новых версий в стыкуемых подсистемах.
На практике это сводится к безверсионной замене существующих данных без согласования, что влечет за собой:
- несогласованные изменения в ведомой подсистеме;
- потерю истории изменений, что в дальнейшем делает невозможным формирование сложных многофакторных отчетов, учитывающих, например, качество и степень влияния изменения конструкции на стоимость.
|
|
Интеграция и жизненный цикл подсистем
Интеграция представляет собой отдельный программный продукт, который, как и любое программное обес-печение, требует постановки задачи, разработки, тестирования и сопровождения, например при обновлении одной из подсистем. На протяжении всего жизненного цикла этого программного продукта приходится решать вопросы взаимодействия различных разработчиков и их весьма неконкретно регламентированной ответственности, что для предприятия оказывается ресурсоемким, особенно после сдачи проекта. Для вендора развитие продукта интеграции всегда остается на втором плане, поскольку он считается менее значимым продуктом. Для предприятия же, наоборот, «интеграционная составляющая» законченного проекта выходит на первый план и становится головной болью. И чем больше у предприятия этих «костылей», тем более масштабными будут результаты и в трудовом, и в стоимостном исчислении. Обычно они в геометрической пропорции зависят от количества сопрягаемых систем.
Интеграция разбивается на несколько этапов, которые, в свою очередь, подразделяются на организационную и техническую составляющие.
Можно долго обсуждать эти этапы. Связанные с ними вопросы очень сложны, а пути их решения всегда уникальны. Если остановиться даже на самой простой с точки зрения влияния технической составляющей, то необходимо отметить следующее:
- хранение метаданных может различаться в системах по организации структур данных (когда различаются не только структуры таблиц, но вся организация базы, например справочник оснастки в одной системе распадется на 14 справочников оснастки в другой);
- метаданные могут различаться по взаимосвязи с БД (клиент-сервер, двухзвенная, трехзвенная и т.д.) и используемым СУБД.
Любая интеграция приводит к ограничению передаваемых данных по полноте и актуальности, что в целом пагубно влияет на функционал и эффективность принимающей и передающей систем.
|
|
Резюме
На данный момент все созданные на предприятии КИС являются интегрированными, так как пока нет поставщиков, предлагающих полноценно охватывающее все бизнес-процессы решение. Кроме того, программные продукты одного и того же поставщика, выдаваемые за единое целое, зачастую в реальности разработаны как отдельные решения и в дальнейшем в той или иной мере интегрированы между собой.
Интеграция представляет собой лишь часть системы решения комплексных задач по автоматизации предприятия. Целесообразно руководствоваться прежде всего эффективностью работы предприятия в целом и анализировать обоснованность внедрения стороннего решения для последующего ограничения функционала базовой платформы.
Утверждения поставщиков следует воспринимать с осторожностью, проверяя их решения на самых сложных производственных примерах.
|
|
