Анализ эволюции в автоматизации промышленных предприятий

Аннотация

Birgit Vogel-Heuser,Christoph Legat, Jens Folmer - Анализ эволюции в автоматизации промышленных предприятий

Промышленными установками управляют длительный период времени. Следовательно, развитие этих производственных предприятий необходимо, чтобы справиться с техническими разработками или запросами рынка. Однако циклы развития дисциплин, включенных в совместный дизайн таких производственных предприятий, отличаются. Поэтому, дальнейшее исследование должно быть изучено, чтобы предоставить интегрированный вариант и управление версией, т.е. управление развитием, таких производственных предприятий. Как первый шаг к решению этой проблемы, эта работа представляет абстрактную модель для развития промышленной установки и анализирует его, используя подробное тематическое исследование в области автоматизации промышленной установки.

I. Вступление

Промышленными предприятиями обычно управляют больше 15 лет к нескольким десятилетиям. Таким образом промышленные предприятия вынуждены развить завод из-за нескольких условий, например, новых технических разработок или запросов рынка [1]. Различные дисциплины, например, электрическая, механическая и разработка программного обеспечения, включены совместно к разработке, построению, поддержанию и совершенствованию системы автоматизации. Так как проектирование и строительство механических аспектов – интенсивный по времени процесс, физическая аппаратная часть завода, как правило, работает без изменений в течение многих лет. Однако, программное обеспечение изменяется намного более часто. Следовательно, управление развитием завода должно иметь дело с отличающимися циклами развития включенных дисциплин [2]. Экспертные обзоры, проводимые во время немецкого научно-исследовательского проекта BESTVOR1, выделяют систему управления версиями и вариантами как ключевой фактор для управления развитием в автоматизации промышленного предприятия, но упоминают отсутствие инструментальной поддержки. Следовательно, в следующем разделе, рассмотрены существующие подходы для системы управления версиями и вариантами, чтобы конкретизировать существующие недостатки. На основе этого исследования абстрактная модель для развития промышленного предприятия представлена в разделе III. Впоследствии, подробное тематическое исследование о развитии промышленного предприятия представлено и проанализировано на основе предложенной модели в разделе IV. Итоги данной статьи представлены в разделе V.

II. ИССЛЕДОВАНИЕ В ОБЛАСТИ РАЗВИТИЯ ПРОМЫШЛЕННОГО ПРЕДПРИЯТИЯ

Проанализированы далее существующие подходы, чтобы понять систему управления версиями и вариантами и предоставить управление развитием для автоматизации. Подробный анализ относительно развития для промышленных установок представлен в [3].

A. Вариативность и управление вариантами

Изменчивость для модульных систем и моделей, а также для подходов производственной линии, реализована механизмами конфигурации для создания всей системы из меньших модулей, например, [4,5]. Классическая производственная линия / разработка семейства (PLE/PFE), например, [6], создает базовую архитектуру платформы продукта организации, например, [7], на основе общих черт и запланированных изменений. Вариации продукта получают из основного семейства продуктов. Много подходов было опубликовано в области программного обеспечения PLE, например, [6], фокусируясь на общих основах управления изменчивостью. Некоторые подходы расширяют PLE к развитию производственной линии [6,7,8]. Однако эти подходы фокусируются на представлении программного обеспечения и, следовательно, меньше внимания уделяется поддержке междисциплинарных аспектов.

Чтобы решить многомерное развитие в автоматизации промышленного предприятия, системы управления версией и вариантом должны быть интегрированы в PLE. В этой области подходы фокусируются на деривации продукта [9,10] и пренебрегают переплетшимся вариантом и управлением версией между полученными продуктами и производственными линиями. Они, главным образом, рассматривают программные продукты [11], не беря механическое и электрическое представление в системе во внимание.

Б. Управление версиями и управление конфигурацией

Касательно управления версией, наиболее широко известные подходы - Конкурентная Система Версий и Сиситема Подверсий, которые стремятся идентифицировать конфликты при слиянии версий текстовых документов, разработанных параллельно. Однако разработка автоматизации включает множественные дисциплины и, таким образом, версии документов дисциплины разрабатываются одновременно. Ко всем неприятностям определенные языки моделирования и инженерные инструменты примешаны к этим дисциплинам. Таким образом, метамодель конкретных подходов таких как [12,13] не применима, поскольку она может быть применена только к одиночным языкам моделирования. Применимость подходов, независимых от метамоделей [14] для автоматизации промышленного предприятия, необходимо оцененить.

Многие подходы работают на синтаксическом уровне, сравнивающем синтаксическую структуру образцовых версий для слияния. Дальнейшие подходы основаны на работе и исследовании атомарных операций, приводящие к модификациям в модели. Эти операции рассматривают для обнаружения трассировки и конфликта изменения; таким образом может быть достигнута более высокая степень автоматизации во время слияния, например, [15,16].

III. МОДЕЛЬ РАЗВИТИЯ ЗАВОДА

Для исследования развития промышленной установки модель развития производственного предприятия предложена подробно в этом разделе. Во-первых, мы описываем кратко драйверы, вынуждающие промышленные предприятия построить и скорректировать их производственные оборудования и идентифицировать роль требований к производственному предприятию. Во-вторых, междисциплинарная техническая перспектива и ее отношения в развитии производственного предприятия представлены на рисунке 1.

A. Эволюция драйверов и требований на заводе

Так как развитие промышленной установки сфокусировано, начальное развитие производственного предприятия как новый проект не рассматривается, таким образом, предполагается, что производственное предприятие уже существует. Как определено в [1], существуют всевозможные драйверы для развития производственного предприятия, например, новые технические разработки, динамика рынка, и т.д. С технической точки зрения, эти драйверы развития подразумевают миграцию требования: указанные требования для выполнения их существующей системой производства, изменены на ряд требований, которые должно выполнить разрабатываемое производственное предприятие. Во время разработки детализированы эти требования.

Б. Междисциплинарная разработка: размеры заводов

Как описано в разделе I, применяются различные дисциплины во время разработки завода. В дальнейшем мы применяем терминологию, предложенную в [3]. Сама техническая система адресуется существенно машиностроением и называемая размерностью измерений. В дальнейшем различные электрические аппаратные средства завода, состоящие из контроллеров, датчиков и приводов, будем называть размерностью платформы. Третья размерность упоминается как размерность программного обеспечения, которая фокусируется на разработке программного обеспечения, например, разработкой управления и автоматизации. В дальнейшем категории всех частей завода, состоящего из определенного измерения, упоминаются как урегулирование. После разработки завода, как проект зеленого поля (новый проект), контекст устанавливающий AC, урегулирование платформы AP и программное обеспечение устанавливающее AS создают завод. Эти параметры настройки зависят друг от друга из-за междисциплинарных модулей и составов между модулями.

C. Особенности перспектив: свойства завода

В соответствии со множеством работ, например, [17], мы именуем свойства завода как функции. Начиная с каждой размерности фокусирования на определенных частях всего завода каждая размерность обеспечит ряд специфичных для размерности функций. Пример для функции размерности – максимальный вес рабочей части, которую может транспортировать конвейер, так как это зависит в основном от конструктивных аспектов. Точность и задержки установленных датчиков – образцовые функции платформы. Функциями программного обеспечения могут быть реализованные интерфейсы или временное поведение программного обеспечения контроля (например, наихудший случай или минимальное время выполнения).

Таким образом гранулярность функций может быть любой определенной размерностью (в случае обеспеченных интерфейсов) или абстрактной. Все эти функции соответствуют функциям полного завода, например, минимальной пропускной способности, максимальному размеру рабочих частей, которые будут обработаны и т.д. Аналогично к специфичным для размерности функциям, функции завода могут также измениться по гранулярности. Набор всех возможных функций в каждой гранулярности огромен, в отличие от ряда соответствующих функций. Актуальность функции определяется ее вкладом в соответствующие функции целого завода. И, в свою очередь, соответствующие функции завода предопределены требованиями.

Рассматривая образцовый конвейер завода как объект, требования могут быть расстоянием транспортировки и минимальной пропускной способностью. В результате максимальная пропускная способность конвейера, а также длина ленточного конвейера (характеристики измерений) соответствуют характеристикам завода. Следовательно, в некоторых случаях, особенности завода могли бы быть равны особенностям измерения в зависимости от степени детализации требований. В случае характеристики минимальной пропускной способности должны быть приняты во внимание различные определенные для измерения особенности.

Г. Развитие завода: модификация параметров настройки и функций

Как ранее определено, драйверы развития завода инициировали миграцию требования, которая приводит к адаптированному набору требований к заводу. В свою очередь, соответствующие функции завода определены требованиями к заводу. Следовательно, миграция функции требуется, чтобы адресовать требуемую миграцию. Если существующий завод может обеспечить набор функций, следующий из миграции функции, никакой корректировки системы и, таким образом, никакое развитие завода не требуется. В большинстве случаев, если процесс развития инициирован, не, все скорректированные функции могут быть выполнены непосредственно. Поэтому некоторые модификации завода требуются. В каждой размерности, т.е. контексте, платформе и программном обеспечении, (вероятно, пустой) набор специфичных для размерности действий модификации поняты, чтобы преобразовать данный настройки в трех измерениях в измененные настройки. Каждая размерность включает определенные наборы возможных действий модификации. Например, дополнение или демонтаж цифро-аналоговых устройств – типичное действие модификации размерности платформы, тогда как замену типа PLC (например, обновление PLC) можно рассмотреть как последовательность удаления и добавления действий в размерности платформы. Другое типичное действие в этой размерности - конфигурация PLC, например, определение постоянного времени цикла. Действия модификации домена контекста могли бы быть дополнением и удалением модулей контекста (например, механические детали). В отличие от этих размерностей, которые имеют дело непосредственно с физическими элементами и, следовательно, определены стандартными блоками материального мира, программное обеспечение структурировано независимо от телесности. Поэтому действия модификации размерности программного обеспечения адресуют специфичные для размерности стандартные блоки, например, части кода, методов, функций, функциональных блоков, интерфейсов, и т.д. При заключении, в каждой размерности, определенные проявления действий модификации имеют дело со стандартными блоками, которые они адресуют. Кроме того, каждое из этих действий может рассматриваться как специализация дополнения, удаления, или сконфигурировать действия. Последний может быть замечен как параметризация, корректировка, установка, и т.д. в зависимости от соответствующей размерности.

IV. ТЕМАТИЧЕСКОЕ ИССЛЕДОВАНИЕ: СЦЕНАРИИ РАЗВИТИЯ

В этой секции развитие завода описано согласно модели развития, введенной ранее. Мы полагаемся на лабораторный завод, называемый «взял-положил» (устройство для простых (по кинематике) погрузочных работ) (PPU) в Институте AIS, рисунок 2. Чтобы связать наше исследование с промышленной практикой, мы выдвинем на первый план отношение между PPU и случаем использования в перерабатывающей промышленности бака, всюду по этой секции. Сценарии развития, которые обсуждены подробно в дальнейшем, его драйверах и действиях модификации, сведены в таблицу I.

A. Начальная ситуация

Первоначально, фиктивная компания TRC управляет рабочей ячейкой переработки для корпусов – впредь названный TRM – для того, чтобы автоматически транспортировать корпуса между двумя полуавтоматическими рабочими положениями. Следующие требования были заданы при вводе в действие TRM:

1. по крайней мере три корпуса должны быть обработаны параллельно
2. только металлические корпуса используются.

В лабораторном PPU установки TRM представлен стеком для загрузки корпуса, скат как выходное хранение и подъемный кран для выбора и операций места между ними. Корпуса представлены металлическими чурбанами в PPU. У стека есть максимальная мощность пяти корпусов (функция контекста). После запуска TRM разделяет корпус, содержавшийся в стеке, перемещая пневматический цилиндр, который включает два двоичных позиционных датчика (вытесненный или отрекшийся). Вытесняя, часть работы продвинута к позиции погрузки. В позиции погрузки двоичный датчик обнаруживает присутствие корпуса. Если часть работы доступна, подъемный кран перемещает в позицию погрузки и потребления корпус, используя вакуумный механизм захвата. Тогда подъемный кран перемещается вверх, повороты против часовой стрелки на 90° к скату, где корпус выпущен. Корпус подсовывает вниз скат, посредством чего скат имеет вместимость три корпуса (функция контекста). В этой точке TRM прекращает обрабатывать, если никакой дальнейший корпус не доступен в стеке. Иначе процесс перезапускается автоматически, и подъемный кран пятится к стеку. Полным заводом управляет PLC. Датчики и приводы соединены с клеммными колодками, где цифровые входные и выходные сигналы распознаны и отправлены в PLC. Программное обеспечение управления реализовано, используя IEC 61131-3 стандарта. TRM включает функцию контекста, т.е. максимальную способность три (функции контекста стека и ската). Так как никакие другие специфичные для размерности функции не способствуют максимальной полной функции TRM, эта функция контекста равна своей соответствующей функции завода. Все датчики могут обнаружить каждый твердый материал (функция платформы). Поэтому эта функция способствует непосредственно функции завода, которая выполняет требование, чтобы могли быть обработаны металлические корпуса.

Б. Добавление штамповочного модуля

По причинам трассируемости (драйвер) было решено, что опасные материалы должны быть маркированы (миграция требования). Поэтому штамп добавлен, чтобы маркировать металлические корпуса (чурбаны). Штамп расположен в позиции 180° (против часовой стрелки) подъемного крана и состоит из двух цилиндров. Один из них первоначально вытеснен так, чтобы подъемный кран был в состоянии поместить корпус на него, а именно, журнал. Цифровой микро переключатель в журнале обнаруживает, если корпус доступен или нет. Как только корпус доступен, журнал отрекается, чтобы расположить корпус под штампом. Штамп перемещается вниз (экструзия), нажимает корпус некоторое время и отрекается (маркирующий законченный процесс). Как только процесс маркировки закончен, экструзия журнала и подъемный кран выбирает корпус, помещающий его в скате. Из-за нового контекста модуля штампа, платформа и программное обеспечение затронуты. Для подъемного крана дополнительный цифровой позиционный датчик добавлен, чтобы обнаружить, расположен ли подъемный кран в штамп. Это приводит к модификации действий во всех размерностях подъемного крана.

В. Индуктивный датчик положения подъемного крана

Для определения позиции крана используются микро переключатели. Когда подъемный кран касается такого микро переключателя, цифровой сигнал указывает определенную позицию. Из-за загрязнения, эти механические контакты характеризуются вероятностно. Это приводит к пропавшим без вести сигналов датчика и, следовательно, подъемный кран не останавливается в требуемой позиции. Управляемый идеей увеличить доступность TRM (требование и функция завода), установлены дополнительные индуктивные датчики, которые более устойчивы против загрязнения. Даже если индуктивные датчики грязны, электромагнитное поле все еще происходит, чтобы обнаружить металлическое содержание в подопочном щитке подъемного крана. Индуктивные датчики обеспечивают те же характеристики цифрового сигнала (рабочее напряжение, управляющее напряжение) как старые позиционные датчики. Следовательно, программное обеспечение не должно быть адаптировано. Кроме того, геометрический размер и механическое монтирование идентичны микро переключателям, таким образом, размерность контекста не затронута. Замена, используя индуктивные датчики только влияет на платформу. Следовательно, эта соответствующая функция, используя индуктивные датчики, удовлетворяет те же требования последнего развития завода и еще больше требование доступности.

Г. Механический буфер на штамповочном модуле

Из-за дополнительно смонтированного механического буфера, другой металлический корпус может быть помещен рядом со штампом, даже если штамп обрабатывает металлический корпус. Во время маркировки металлического корпуса в штампе, стек проверяет, какой вид корпуса доступен. Если есть другой металлический корпус, кран поднимает и помещают его в механический буфер. Затем стек изменяется, чтобы проверить следующий корпус. В случае, если есть пластмассовый корпус, подъемный кран тянет пластмассовый корпус к скату и если есть металлический корпус, кран должен ожидать, пока процесс маркировки не закончен. Реализованные функции влияют на каждую размерность завода, потому что механическое монтирование (контекст) буфера должно быть понято, новый позиционный датчик для подъемного крана должен быть интегрирован (платформа), и реализованное поведение подъемного крана должно быть изменено (программное обеспечение), чтобы повернуться к механическому буферу. Миграция функции удовлетворяет данное требование увеличивающейся пропускной способности.

Д. Приспособленная сортировка частей работы

В этом сценарии порядок сортировки частей работы изменен в скатах. Теперь, во всех скатах должны быть смешанные корпуса. Этот сценарий влияет только на программное обеспечение, потому что поведением всей системы управляет PLC-код.

Е. Потенциометр в крановой установке

До этого сценария расположение подъемного крана реализовано при помощи цифровых позиционных датчиков. Чтобы увеличить точность и избежать траты кабелей и клеммных колодок, цифровые датчики заменены единственным аналоговым датчиком (потенциометр), который влияет на контекст. У потенциометра есть определенный аналоговый диапазон значений. Следовательно, изменения в платформе должны быть внесены, чтобы обработать этот сигнал клеммными колодками. Кроме того, PLC -код (программное обеспечение) должен быть адаптирован, изменив программный модуль для расположения крана. Программное обеспечение должно быть в состоянии обработать аналоговое значение.

Ж. Сопротивление ЭMC

После реорганизации всего завода, расположение крана характеризуется неожиданными внезапными отказами. Так как потенциометр для расположения подъемного крана не электромагнитно-совместимый (EMC), и TRM теперь расположен рядом с преобразователем частоты, драйвер для развития - техническая причина, независимая от самого TRM. Чтобы понять EMC стойкое расположение подъемного крана, потенциометр заменен инкрементальным энкодером, который также имеет аналоговый сигнал, но использует оптические механизмы, чтобы определить позицию крана. Монтирование инкрементального энкодера отличается от потенциометра и, следовательно, контекст должен быть изменен. Новая клеммная колодка должна быть добавлена к платформе, потому что у инкрементального энкодера отличается электрический сигнал. В конце должно быть изменено программное обеспечение, потому что у инкрементального энкодера более высокое разрешение и более высокий диапазон значений в отличие от прежнего потенциометра.

V. Вывод

В этой статье была представлена модель развития для автоматизации промышленного предприятия. Эта модель включает, формулировку шагов развития, инициируемые драйверами, которые инициировали миграции требования и последующие миграции функции. Это предлагает разделить техническую перспективу на контекст, платформу и размерность программного обеспечения, чтобы отличить атомарные действия модификации во время развития промышленного предприятия. Используя подробное тематическое исследование, была показана применимость предложенной модели.

Литература

1. E. Westkamper, “Adaptable Production Structures,” in Manuf. Techn. for Machines of the Future. Springer-Verlag, 2003, pp. 87–120.
2. F. Li et al., “Specification of the Requirements to Support Information Technology-Cycles in the Machine and Plant Manufacturing Industry,” in IFAC Symp. Inform. Control Problems Manuf., Bucharest, Romania, 2012, pp. 1077–1082.
3. S. Braun et al., “Requirements on evolution management of product lines in automation engineering,” in Int. Conf. Math. Modelling, Vienna, Austria, 2012, pp. 340–345.
4. M. Svahnberg, J. van Gurp, and J. Bosch, “A taxonomy of variability realization techniques: Research Articles,” Softw. - Practice and Experience, vol. 35, no. 8, pp. 705–754, 2005.
5. K. Pohl, F. van der Linden, and A. Metzger, “Software Product Line Variability Management,” in Int. Softw. Product Line Conf., Baltimore, US-MD, 2006, pp. 219–219.
6. K. Pohl, G. Bockle, and F. van der Linden, Software Product Line Engineering: Foundations, Principles and Techniques. Berlin, Heidelberg, Germany: Springer-Verlag, 2005.
7. E. A. de Oliviera et al., “A variability management process for software product lines,” in Conf. Centre Adv. Stud. Collab. Research, Toronto, Canada, 2005, pp. 225–241.
8. P. Knauber, “Managing the Evolution of Software Product Lines,” in Int. Conf. Softw. Reuse, Madrid, Spain, 2004.
9. J. van Gurp and C. Prehofer, “Version management tools as a basis for integrating Product Derivation and Software Product Families,” in Int. Softw. Product Line Conf., Baltimore, US-MD, 2006, pp. 48–58.
10. R. Laqua and P. Knauber, “Configuration Management for Software Product Lines,” in Deutscher Software-Produktlinien Workshop, Kaiserslautern, Germany, 2000, pp. 49–53.
11.L. Bendix, J. Graden, and A. Stahl, “A configuration management perspective on composing software product lines,” Department of Computer Science, Lund University, Lund, Sweden, Tech. Rep., 2009.
12. U. Kelter, J. Wehren, and J. Niere, “A Generic Difference Algorithm for UML Models,” in Softw. Eng., Essen, Germany, 2005, pp. 105–116.
13. L. Murta et al., “Odyssey-SCM: An integrated software configuration management infrastructure for UML models,” Sci. Comput. Programming, vol. 65, no. 3, pp. 249–274, 2007.
14. C. Bartelt, “Kollaborative Modellierung im Software-Engineering,” Ph.D. dissertation, Technical Unversity Clausthal, 2011.
15. M. Koegel et al., “Comparing State- and Operation-Based Change Tracking on Models,” in IEEE Int. Enterprise Distributed Object Computing Conf., Vitoria, Brazil, 2010, pp. 163–172.
16. E. Lippe and N. van Oosterom, “Operation-based merging,” ACM SIGSOFT Soft. Eng. Notes, vol. 17, no. 5, pp. 78–87, Nov. 1992.
17. K. Czarnecki, S. She, and A. Wasowski, “Sample space and feature models,” in Int. Softw. Product Line Conf., Limerick, Ireland, 2008, pp. 22–31.