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

Аннотация

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

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

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], мы именуем свойства завода как особенности. Начиная с каждого измерения внимание на определенные части полного завода каждое измерение обеспечивает ряд определенных для измерения особенностей. Пример для особенности контекста - максимальный вес части работы, которую может транспортировать конвейер, так как это зависит в основном от конструктивных аспектов. Точность и времена ожидания установленных датчиков - образцовые особенности платформы. Характеристиками программного обеспечения могли бы быть осуществленные интерфейсы или временное поведение программного обеспечения контроля (например, худший случай или минимальное время выполнения).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.