Содержание к диссертации
Введение
Глава 1. Анализ архитектурных решений в области современных систем управления технологическими процессами 12
1.1 Особенности применения систем управления технологическими объектами и процессами 13
1.2 Анализ архитектурных решений систем ЧПУ и PAC систем
1.2.1 Анализ архитектур построения современных систем числового программного управления 18
1.2.2 Анализ архитектуры построения промышленных контроллеров автоматизации
1.3 Анализ систем ЧПУ и контроллеров автоматизации представленных на рынке 26
1.4 Специфика управления ключевыми технологическими процессами машиностроения 33
1.5 Выводы по главе 1 38
Глава 2. Разработка структурной модели компонентов кроссплатформенного контроллера автоматизации и архитектурной модели по принципу виртуальной машины 39
2.1 Формализация компонентов системы управления технологическим оборудованием на основе технического задания 42
2.2 Разработка структурной модели кроссплатформенного контроллера автоматизации 46
2.3 Структура и организация компонентов варианта автономного решения 49
2.4 Структура и организация компонентов варианта встраиваемого решения 53
2.5 Разработка обобщенной архитектуры модели автономного и встраиваемого решений
2.6 Разработка матрицы базовых модулей и алгоритма выбора минимально необходимого набора модулей для синтеза контроллера автоматизации...63
2.6.1 Обязательные модули 66
2.6.2 Выбираемые модули 69
2.7 Выводы по главе 2 71
Глава 3. Разработка способа синтеза кроссплатформенного контроллера автоматизации технологических процессов 72
3.1 Способ синтеза кроссплатформенного контроллера автоматизации .72
3.2 Определение вычислительных возможностей программно-аппаратной платформы 74
3.3 Механизм выстраивания взаимосвязей между модулями контроллера автоматизации 85
3.4 Выявление функций граничных условий по количеству модулей и компонентов программы управления 88
3.5 Алгоритм проверки работоспособности синтезированного контроллера автоматизации 94
3.6 Создание специализированного набора нагрузочных тестов для определения возможностей программно-аппаратной платформы 96
3.7 Выводы по главе 3 111
Глава 4. Прикладные решения на базе моделей и алгоритмов синтеза кроссплатформенного контроллера автоматизации для встраиваемого и автономного решений 113
4.1 Синтез контроллера автоматизации, встраиваемого в систему ЧПУ «АксиОМА Контрол» для гаммы резьбошлифовальных станков 114
4.2 Синтез автономного контроллера автоматизации при управлении гидроцилиндром 127
4.3 Выводы по главе 4 135
Заключение 137
Список сокращений 139
- Анализ архитектуры построения промышленных контроллеров автоматизации
- Разработка обобщенной архитектуры модели автономного и встраиваемого решений
- Выявление функций граничных условий по количеству модулей и компонентов программы управления
- Синтез автономного контроллера автоматизации при управлении гидроцилиндром
Введение к работе
Актуальность темы исследования. Сокращение времени разработки специализированных средств автоматизации технологических процессов обусловлено необходимостью скорейшего выпуска новой продукции на рынок.
Большинство современных производителей АСУ ТП (Schneider Electric, Rockwell Automation, Fagor Automation) используют набор решений, которые покрывают определенные секторы на рынке автоматизации. Крупные европейские производители (Siemens, Robert Bosch) ориентируются на создание собственных платформ для систем управления, где применяется аппаратное обеспечение с различной вычислительной мощностью и конфигурируемое прикладное программное обеспечение, ориентированное на разные ценовые диапазоны. Другие производители, такие как ICP DAS, «Балт-Систем», зачастую подбирают максимальную комплектацию других производителей и добавляют свое прикладное программное обеспечение (ПО). Перечисленные подходы приводят к избыточности решений, что выливается в дополнительные финансовые затраты.
В настоящее время на российских промышленных предприятиях
наблюдаются тенденции перехода к использованию систем управления,
построенных на основе отечественной программной и аппаратной базы.
Российские производители (АО «Байкал Электроникс», АО «МЦСТ»)
предоставляют возможность разработчикам систем управления переносить
свой программный продукт на отечественные платформы разных
вычислительных мощностей и конфигураций (при этом стоимость может существенно варьироваться).
Проблема заключается в том, что на сегодняшний день отсутствует системный подход, позволяющий подобрать минимально достаточную конфигурацию программно-аппаратной платформы и прикладного ПО в зависимости от технического задания (ТЗ) на объект управления с учетом вычислительных возможностей платформы исполнения.
В результате исследования была выявлена необходимость разработки
способа синтеза кроссплатформенного контроллера автоматизации в
зависимости от вычислительных возможностей программно-аппаратной
платформы , предоставляя конечному пользователю, с одной стороны, выбор из
всего многообразия технических решений одного, полностью
удовлетворяющего требованиям поставленной задачи, с другой – варианты исключения внештатных ситуаций, связанных с невозможностью программно-аппаратной платформы выполнять поставленные задачи.
Степень разработанности исследования. Проблемам построения систем
управления в области промышленного сектора посвящены труды
В.Л. Сосонкина, Г.М. Мартинова, М.М. Аршанского, В. Болтона (W.Bolton),
Г. Олссона (G. Olsson), Й. Брюля (J. Brhl), М. Намие (M. Namie),
В.Г. Митрофанова и др. Работы перечисленных авторов содержат
теоретические основы разработки различных видов систем управления
технологическими процессами. В трудах вышеперечисленных ученых
проведен обширный анализ имеющихся на рынке решений, четко прописаны методы построения, описаны принципы работы распределенных систем управления, имеющих открытую модульную архитектуру и базирующихся на кроссплатформенных решениях. Описаны тенденции развития в данной области. Рассмотрены основные принципы построения систем управления технологических процессов и производств, их программирования, настройки и конфигурации. Показано, что для определенного класса сложных задач применяются системы с расширенными аппаратными возможностями для поддержания дополнительных программных модулей.
Однако зависимости структуры систем управления и особенности их функционирования от возможностей вычислительных платформ исследовались не в полном объеме: не рассматривался систематизированный подход, позволяющий сопоставить сложность задачи с необходимостью применения того или иного решения и максимальным количеством программных модулей, которые могут быть использованы для конкретной технологической задачи.
Цель работы: сокращение времени разработки специализированных средств автоматизации технологических процессов и производств на основе синтеза кроссплатформенного контроллера автоматизации в зависимости от конкретного технического задания на объект управления.
Задачи исследования. Для достижения поставленной цели в работе необходимо решить следующие научные задачи:
-
разработать структурную модель компонентов кроссплатформенного контроллера автоматизации для работы в виде автономного устройства (автономное решение) или в составе системы ЧПУ (встраиваемое решение);
-
разработать обобщенную архитектурную модель автономного решения и встраиваемого решения;
-
разработать способ синтеза кроссплатформенного контроллера автоматизации технологических процессов;
-
реализовать на базе предложенных моделей и комбинированного алгоритма синтеза кроссплатформенного контроллера автоматизации прикладные решения для управления электроавтоматикой гаммы резьбошлифовальных станков в составе системы ЧПУ и при управлении гидроцилиндром в качестве автономного решения.
Научная новизна. В диссертационной работе получены следующие новые научные результаты:
-
установлены взаимосвязи между технологической задачей производственного оборудования и нагрузкой на вычислительное ядро системы управления, позволяющие определить необходимый состав и количество модулей для синтеза ядра кроссплатформенного контроллера автоматизации;
-
на основе установленных взаимосвязей построена структурная модель кроссплатформенного контроллера автоматизации для автономного решения и встраиваемого решения в систему управления, отличающаяся
выделением набора обязательных и выбираемых модулей, привязанных к программно-аппаратной платформе исполнения;
-
разработан и реализован комбинированный алгоритм нахождения граничных условий по количеству модулей для синтеза кроссплатформенного контроллера автоматизации и количеству компонентов программы управления, учитывающий техническое задание на объект управления, а также программно-аппаратную платформу исполнения;
-
предложен способ синтеза кроссплатформенного контроллера автоматизации технологических процессов на основе матрицы выбора модулей;
-
разработан инструментарий определения вычислительных возможностей программно-аппаратной платформы и проверки работоспособности синтезируемого контроллера автоматизации.
Теоретическая значимость заключается в разработанных моделях,
алгоритмах и предложенном способе синтеза кроссплатформенного
контроллера автоматизации технологических процессов на основе набора обязательных и выбираемых модулей, компонентов программы управления в зависимости от технического задания на объект управления и вычислительных возможностей программно-аппаратной платформы исполнения.
Практическая значимость работы заключается в:
-
Созданной методике определения набора модулей для синтеза кроссплатформенного контроллера автоматизации технологических процессов на основе технического задания на объект управления.
-
Разработке базового набора обязательных и выбираемых модулей и программных компонентов, обеспечивающих синтез кроссплатформенного контроллера автоматизации.
-
Наборе специализированных оценочных тестов для определения вычислительных возможностей программно-аппаратной платформы исполнения.
-
Разработанном программном инструментарии определения вычислительных возможностей программно-аппаратной платформы и проверки работоспособности синтезируемого контроллера автоматизации.
Методы исследования. Теоретические исследования в диссертации
базируются на основных положениях метода системного анализа, методах
синтеза и декомпозиции, теории множеств, концепции объектно-
ориентированного программирования.
Положения, выносимые на защиту:
-
Структурная модель кроссплатформенного контроллера автоматизации для работы в виде автономного и встраиваемого решений, отличающаяся выделением набора обязательных и выбираемых модулей.
-
Обобщенная архитектурная модель автономного решения и встраиваемого решения.
-
Способ синтеза кроссплатформенного контроллера автоматизации на основе матрицы выбора модулей.
4. Комбинированный алгоритм нахождения граничных условий по
количеству модулей для синтеза кроссплатформенного контроллера
автоматизации и количеству компонентов программы управления,
учитывающий техническое задание на объект управления, а также программно-аппаратную платформу исполнения.
Достоверность полученных результатов подтверждается
согласованием теоретических и экспериментально полученных данных, апробацией разработанных моделей и алгоритмов в рамках разработки автономного решения и в варианте встраивания в систему ЧПУ.
Апробация работы. Теоретические и практические результаты,
полученные автором, докладывались на заседаниях кафедры компьютерных
систем управления ФГБОУ ВО «МГТУ «СТАНКИН», IV Всероссийской
мультиконференции по проблемам управления (МКПУ – 2011),VII
Международной научно-образовательной конференции «Машиностроение –
традиции и инновации» (МТИ – 2014), XI Всероссийской научно-практической
конференции «Современные информационные технологии в науке,
образовании и практике» (СИТ – 2014), XIV и XV Международных
конференциях «Системы проектирования, технологической подготовки
производства и управления этапами жизненного цикла промышленного продукта» (CAD/CAM/PDM – 2014, 2015). Разработанный инструментарий в составе системы ЧПУ используется в учебном процессе на кафедре «Компьютерные системы управления» ФГБОУ ВО «МГТУ «СТАНКИН» по дисциплинам «Проектирование автоматизированных систем» и «Проблемы управления технологическими процессами в машиностроении».
Работа выполнена при поддержке Минобрнауки России в рамках
государственного задания № 2.1237.2017/4.6, а также в рамках ФЦП «Научные
и научно-педагогические кадры инновационной России» на 2009-2013 годы по
теме «Создание открытой модульной платформы взаимодействия средств
промышленной электроавтоматики на основе синтеза компонентных решений»
(ГК № 16.740.11.0267), гранта Президента РФ по теме «Создание
кроссплатформенного программно-реализованного логического контроллера
для управления технологическим оборудованием» (№ МК-323.2011.9), гранта
на выполнение НИР по программе «УМНИК» ФГБУ «Фонда содействия
развитию малых форм предприятий в научно-технической сфере» по теме
«Создание программно реализованного контроллера автоматизации
технологических процессов» (№ 7165ГУ/2015), НИОКР по теме «Создание гаммы резьбошлифовальных станков особо высокой точности», договор ФГБОУ ВО «МГТУ «СТАНКИН» № 62М от 11.10.2011 совместно со станкостроительным предприятием ЗАО «МСЗ-Салют» (подтверждено справкой об использовании результатов диссертационного исследования).
На основе результатов работы создано 8 объектов интеллектуальной собственности в виде свидетельств о государственной регистрации программ для ЭВМ. Практические и теоретические разработки по данной теме отмечены Премией Правительства Москвы молодым ученым за 2015 г. в номинации
«Передовые промышленные технологии», серебряной медалью и дипломом XVIII Московского международного Салона изобретений и инновационных технологий «Архимед – 2015», дипломом Победителя Молодёжного конкурса на лучшую предпринимательскую инициативу «Московский молодёжный старт – 2014» (Весенний финал) по программе «Участник молодежного научно-инновационного конкурса» («УМНИК») Фонда содействия малых форм предприятий в научно-технической сфере, золотой медалью 1-го Российско -Британского Форума изобретений и инновационных технологий (2013 г.), дипломами XIV и XII Международной Специализированной выставки Передовые Технологии Автоматизации «ПТА – 2014, 2012», диплом за II место 4-ой Всероссийской мультиконференции по проблемам управления (МКПУ – 2011) локальной конференции «Мехатроника и эргатические системы».
Соответствие диссертации паспорту специальности. Диссертационная
работа соответствует формуле научной специальности 05.13.06 –
«Автоматизация и управление технологическими процессами и производствами (технические системы)» в части п.п. 8, 10, 15 в области исследования паспорта специальности.
Публикации. По теме диссертации опубликовано 25 печатных работ (из них 6 в журналах, входящих в перечень ведущих рецензируемых научных журналов и изданий, рекомендованных ВАК, 1 в журнале, индексируемом Web of Science и Scopus), включая тезисы докладов, опубликованные в рамках международных и региональных научно-технических конференций.
Структура и объем диссертации. Диссертационная работа состоит из введения, четырех глав, заключения, списка литературы из 96 наименований. Работа изложена на 157 страницах машинописного текста, содержит 52 рисунка, 14 таблиц.
Анализ архитектуры построения промышленных контроллеров автоматизации
Фирмы, выпускающие системы управления для автоматизации технологических процессов, можно разделить на крупных, средних и мелких производителей.
Крупные (Siemens, Fanuc) – системы управления этих фирм суммарно покрывают более 80% процентов рынка систем ЧПУ и промышленных роботов. Разработки данных фирм являются закрытыми, что означает невозможность встраивания сторонних решений различных производителей.
Средние (Bosch Rexroth, Fagor Automation) – уступают лидерам рынка, поэтому создают различные возможности для удержания на рынке. Их продукты обладают возможностью работы со сторонним оборудованием, а также допускают встраивание ПО в собственные разработки для возможности поддержания расширенной функциональности.
Мелкие (ICP DAS, Балт-Систем) – зачастую занимают определенную нишу за счет низкого ценового диапазона и предоставления малой функциональности.
В рамках диссертационного исследования был проведен анализ систем ЧПУ и PAC систем различных производителей, а также системы ЧПУ, разрабатываемой в МГТУ «СТАНКИН».
Системы ЧПУ Fanuc. Компания Fanuc (Япония) является одним из лидеров производства систем ЧПУ для станочного оборудования ( 30% мирового рынка) и систем управления промышленным роботом ( 60% мирового рынка) [34].
Система ЧПУ представляет собой однокомпьютерный вариант по типу PCNC4, с программно-реализованным контроллером электроавтоматики.
Производитель поставляет свои системы только в комплектном виде (ЧПУ, двигатели, датчики, входы/выходы, моторы). Для работы с датчиками используется собственный протокол обмена SPDUinit, контроллеры приводов и входы/выходы работают по закрытым протоколам FSSB и Genius соответственно. Системы ЧПУ Fanuc являются полностью закрытыми, работа со сторонними устройствами также невозможна. В случае необходимости, компания заключает договор на изготовление стороннего оборудования, которое будет работать только с их системами управления (например, измерительные линейки Fagor). Линейка систем ЧПУ весьма обширна и поставляется в зависимости от необходимости решения конкретной технологической задачи. Величина и лидерство компании Fanuc позволяет поддерживать системы, выпущенные 30 лет назад [35].
Системы ЧПУ Fagor. Компания Fagor Automation (Испания) производит различные средства автоматизации производственного процесса, от измерительного оборудования и другого оборудования до станкостроительной промышленности. Системы ЧПУ Fagor распространены в большей степени в Европе, Северной Америке и части Азии.
Системы ЧПУ Fagor относятся к системам с открытой архитектурой, выполненные в реализации PCNC4 с программно-реализованным контроллером электроавтоматики. Открытость системы управления обеспечивается подходом к разработке использованием стандартизованных протоколов обмена (Sercos II, CANOpen), а также специальным модулем для использования сторонних приложений, но работающих без обращения к аппаратной части (встраивание стороннего CAM модуля). Конечным пользователям доступны опции изменения интерфейса под себя, создание собственных технологических циклов или режимов управления. Управление движением происходит за счет реализации Motion Control в приводах.
Системы ЧПУ Fagor не имеют обширной линейки, поэтому каждая система выполняет ровно заявленный набор функций, который может меняться только в сторону уменьшения.
Выбор одной из 4-х возможных систем (8037, 8055, 8065, 8070) происходит на основе технического задания на объект управления. При этом, если появится необходимость добавить дополнительный модуль или использовать дополнительную опцию – необходимо менять всю систему управления. Проведение тестирования функций программно-реализованного контроллера возможно только в режиме трассировки, когда при выполнении программы происходит определение несоответствий конфигураций.
Системы ЧПУ Балт-Систем. Компания Балт-Систем (Россия) производит системы многопрофильного применения. Является одним из лидеров России по модернизации фрезерных и токарных групп станков без применения многокоординатной обработки. Представляет собой вариант системы, направленный на бюджетный рынок промышленной автоматизации.
Системы ЧПУ ниже версии NC-400 (вышла в серию в 2016 г.) не обладают поддержкой цифровых протоколов. Являются закрытыми, без возможности интеграции сторонних модулей.
Например, УЧПУ NC-301 с управлением входами/выходами по цифровой шине SSB. Наиболее оптимально для управления станками токарно-фрезерных групп. Сочетает в себе входы/выходы в пульте оператора и удалённые входы/выходы по цифровой шине. Позволяет распределить элементы электроавтоматики станков. Наличие цифрового канала SSB позволяет по одному кабелю (4 витые пары) управлять входами/выходами в количестве 64/48. Внешние модули входов/выходов с релейной коммутацией позволяют в кратчайшие сроки подключить управляющие элементы станка к ЧПУ. Система основана на итальянской разработке Olivetti 8600, что накладывает некоторые ограничения в ее модернизации и распространению. До 2016 г. системы ЧПУ Балт-Систем являлись двухкомпьютерным вариантом управления, но с программнореализованным контроллером электроавтоматики. Системы не обладают полноценной кроссплатформенностью – при изменении платформы необходимо вносить изменения не только в программный код, но и разрабатывать дополнительные платы для поддержки старых вспомогательных модулей.
Разработка обобщенной архитектуры модели автономного и встраиваемого решений
Системы управления, представленные на рынке АСУ ТП, зачастую являются полностью закрытыми, с проприетарным ПО, как было отмечено выше. Но существующей тренд в области масштабируемости и возможности предоставления конечному потребителю гибкости настройки, а также вопросы конкуренции, заставляют некоторые компании пересмотреть свои взгляды на подход в данном вопросе [55]. При том какие-то системы могут быть расширяемы за счет своих собственных разработок, другие могут быть масштабированы за счет сторонних решений. Например, некоторые компании (ОВЕН, Fastwell и т.д.) разрабатывают аппаратную часть, а в качестве программного ядра используют программный комплекс промышленной автоматизации CoDeSys [56, 57]. Это позволяет каждой компании сосредоточиться на определенной области разработок.
Вариант, когда другие производители систем управления позволяют встраивать сторонние модули для расширения функциональности при необходимости решения специфических задач, начинает появляться на рынке [58, 59]. Как было сказано выше в разделе 2.2 главы настоящего диссертационного исследования, такие системы управления должны обладать открытой модульно архитектурой построения.
На рисунке 2.7 представлен вариант расширения функциональности системы ЧПУ для реализации функций смены инструмента и работы со вспомогательными панелями управления. Это достигается за счет поддержки во встраиваемом варианте контроллера автоматизации промышленных протоколов связи и модулей работы с электроавтоматикой и движением. При этом вся вычислительная мощность для расчета траектории движения инструмента остается на системе ЧПУ (построение интерполяционных путей, сплайнов). По протоколу EtherNet в представленном варианте происходит общение со специализированными выносными панелями. Поддержка EtherCAT и модуля электроавтоматики позволяет поддерживать электроавтоматику смены инструмента. ModBus и модуль работы с движением обеспечивают функциональность поворота барабана магазина в заданное положение. Поддержка этих протоколов обеспечивается наличием уже имеющихся плат и интерфейсов в сторонней системе ЧПУ (порты Ethernet и RS-485).
При этом стоит учесть, что используемые на сегодняшний момент свойства инкапсуляции строго разграничивают доступ программных решений. Этот принцип объектно-ориентированного программирования позволяет использовать сторонние решения в системах с повышенным уровнем безопасности.
Для встраиваемого варианта, в синтезируемом контроллере автоматизации необходимо наличие модуля связи с ЧПУ, с другой стороной и в самой ЧПУ необходим модуль связи со встраиваемым вариантом контроллера автоматизации.
Интеграция разрабатываемого программного контроллера в систему ЧПУ с открытой модульной архитектурой потребовала разработку модуля, включающего в себя различные подуровни, необходимые для работы как с самой системой ЧПУ, так и с внешней аппаратной частью.
Модуль связи с NС частью ЧПУ и модуль связи с контроллером автоматизации обмениваются информацией по типу командных и текущих значений, оформленных в виде структуры данных, передаваемых в коммуникационном пакете.
Основными параметрами являются скорость, положение, момент, готовность устройств, адресация. Командные данные (CMD_DATA_T) передаются из модуля связи ЧПУ во встраиваемый модуль, обратно же от устройств получается структура текущих данных (CUR_DATA_T). Обмен данными происходит через постоянный цикл (функция OnTick()) или по запросу (функция OnPoling()). В первом случае обмен значениями происходит на основе срабатывания таймера с заданным периодом, во втором случае – по запросу с одной или другой стороны.
Если встраиваемый контроллер автоматизации применяется для расширения функциональности системы ЧПУ с использованием промышленного протокола связи, то весь расчет траектории производится в модуле интерполяции системы ЧПУ, полученные данные передаются через структуру CMD_DATA_T непосредственно в модуль связи с NC частью ЧПУ, откуда через прослойку драйверов протоколов попадает в контроллер привода. Обратно по той же цепочке приходит структура CUR_DATA_T, далее в ядре системы ЧПУ при необходимости происходит корректировка траектории (использование регуляторов) и данные передаются в контроллеры приводов. Использование операционной системы реального времени позволяет добиться жестких тактов исполнения управляющих сигналов, при этом используя для передачи один из многочисленных промышленных протоколов. Возможен вариант, когда встраиваемое решение контроллера автоматизации применяется для управления вспомогательным оборудованием с использованием модуля электроавтоматики, который использует те же самые структуры: данные приходят с датчиков (датчики подачи воздуха, наличия питания, подачи СОЖ и т.д.), а управляющие команды в виде сигналов поступают на исполнительные устройства. В таком случае, вычислительная нагрузка по управлению электроавтоматики перекладывается непосредственно на сам контроллер автоматизации [60].
Рисунок 2.8 - Фрагмент программы электроавтоматики станка
На рисунке 2.8 приведен фрагмент программы для управления механизмом зажима инструмента, на котором выделены последовательности этапы работы программы: после поступления сигнала на вход «СОЖ» сигнал переносится на пользовательский блок «станция СОЖ», в котором реализуется логика подачи СОЖ (проверяется возможность включения, вспомогательные сигналы, наличие аварийных ситуаций и т.д.) после чего в случае положительных сигналов выходов, приходит сигнал на выход подачи СОЖ.
Выявление функций граничных условий по количеству модулей и компонентов программы управления
Для минимизации нагрузки на канал передачи данных XData в модуле связи с терминальной частью реализован механизм, который позволят получать только актуальную информацию.
Основная идея заключается в заполнении блока данных полностью для каждой отправки в ядро контроллера, а не отдельно по компонентам программы, а также в запросе только тех данных, которые именно сейчас необходимы пользователю (программисту) и находятся в области его видимости. По схожим принципам реализуется обмен данными и при конфигурировании оборудования – в один пакет помещается сразу несколько модулей и данные об оборудовании.
Модуль selfest необходим для проверки работоспособности получаемого синтезированного решения. При этом используемый подход отличается от существующих аналогичных вариантов, применяемых в различных системах управления.
Следует учитывать, что заявленная кроссплатформенность контроллера автоматизации предполагает возможность его портирования на различные программно-аппаратные платформы, которые могут отличаться своей производительностью. Возможна ситуация, когда программно-аппаратная платформы не удовлетворяет конкретным условиям технического задания на объект управления. Модуль selfest (рисунок. 2.12) предусмотрен для отлова этой ситуации. Входными данным для этого модуля являются таблица максимально допустимых параметров (ОЗУ, ЦП и т.д.) и параметры программы управления.
Применяемый стандартный подход по оценке работоспособности создаваемой системы управления подразумевает использование различных watchdog, которые в случае невыполнения какого-либо критерия (выход за допустимый такт цикла, превышение уровня расходуемой памяти и т.д.) выдает сообщение пользователю и настройщику системы управления. Т.к. разрабатываемый контроллер автоматизации является синтезируемым, это означает, что большинство вариантов нагрузки системы можно просчитать заранее на этапе настройки системы, снизив таким образом вероятность возникновения нештатных ситуаций, связанных с ресурсоемкими задачами. Более подробно работа master-модуля и алгоритм работы модуля selfest будут рассмотрены в главе 3.
Master-модуль является также обязательным модулем конечного синтезируемого решения и служит для сборки модулей и их подмодулей в единое ядро контроллера автоматизации (встраиваемое или автономное) и выстраивание между ними логических взаимосвязей.
Следует отметить, что при варианте встраивания в стороннюю систему управления, модуль связи с этой системой управления также будет являться обязательным, т.к. ядру контроллера автоматизации необходимо получать через него данные и передавать текущее состояние работы. В варианте автономного решения этот модуль является выбираемым и может служить связью автономного контроллера автоматизации и сторонней системы управления.
Выбираемые модули зависят от конкретной технологической задачи, их набор может варьироваться даже в рамках одной системы управления для аналогичных объектов. Модуль управления движением может применяться как в автономном варианте управления, так и во встраиваемом. В варианте автономного решения модуль управления движением выполняет простые интерполяций, необходимые для вспомогательных задач [66]. Модуль управления движения состоит из подмодулей: решение геометрический задачи, работа с синхронными/асинхронными двигателями, работа с шаговыми двигателями и другими различными типами приводов по промышленным протоколам связи. В диссертационной работе не рассматривается реализация модуля управления движением (реализация различных видов интерполяций). Данный модуль может быть предоставлен сторонними разработчиками, но также оттестирован и добавлен в обобщенную матрицу модулей.
Наличие модуля верификации данных позволяет на начальном этапе проследить корректность составленных программ управления и конфигурации системы. Программы управления проверяются на корректность использования типов данных (к примеру, перевод int в bool, что может вести к потере данных), привязки к конкретным областям памяти, корректное использование области распределяемой памяти (к примеру, запрет на использование для записи одной и той же ячейки памяти для избежание коллизий), проверка на соответствие используемых модулей входов/выходов к реально привязанным устройствам (для задач электроавтоматики). Также при загрузке программы управления в контроллер автоматизации проверяется ее целостность.
Модуль верификации данных также отлавливает ситуацию, когда пытаются загрузить программу управления, использующую компоненты, которые не относятся ни к одному из модулей контроллера (например, попытка загрузить компоненты для управления движением при учете, что синтезированное решение используется лишь для обслуживания датчиков температуры, приведет к ошибке, которая будет выведена в терминальную часть).
Модуль верификации состоит из подмодулей: верификация программы управления, протоколы связи, загружаемые конфигурации устройств.
Модуль диагностики используется для проверки состояния устройств (приводы, датчики и др.) на наличие каких-либо ошибок, возникающих в процессе работы (ошибки питания, статус соединения, готовность работы и т.д.) или в процессе проведения целенаправленного тестирования. При обнаружении ошибок, ранжированные предупреждения выводятся через терминального клиента IODiag пользователю, который принимает дальнейшие решении о продолжении или приостановке работы системы. Сам модуль состоит из подмодулей: диагностика работы внешних устройств, канала обмена данными, периферийные вспомогательные устройства.
Модуль работы с электроавтоматикой выполняет функции программно-реализованного контроллера, у которого в отличии от стандартных ПЛК, все вычисления происходят в ядре системы управления, а управляющие сигналы обрабатываются с помощью устройств ввода/вывода. Работа модуля сводится к решению логической задачи управления. Модуль состоит из подмодулей: решение логической задачи, работа с дискретными входами/выходами, работа с аналоговыми входами/выходами, работа со специальными (SSI, Sin/Cos и др.) входами/выходами.
Синтез автономного контроллера автоматизации при управлении гидроцилиндром
Предлагаемый вариант определения работоспособности контроллера автоматизации отличается от традиционного расположением во времени возможных срабатываний сторожевого таймера watchdog, при превышении какого-либо параметра (цикл ПУ, загрузка ОЗУ и т.д.) (рисунок 3.11).
В традиционном подходе на первом этапе происходит подготовительная настройка параметров для последующей конфигурации системы управления. После корректного завершения этого шага, выполняется загрузка программы управления в ядро СУ. На втором этапе осуществляется запуск программы управления и начинается цикл ее работы. На третьем этапе, происходит проверка работоспособности решения, а именно определяется, не выходит ли какой-то из параметров, заданных в конфигурации за допустимые границы. Если такое имеет место быть, то срабатывает сторожевой таймер watchdog и далее происходят действия в соответствии с заданным сценарием для такого случая (в общем случае - останов работы с выводом причин). После этого необходимо заново скорректировать параметры конфигурации.
В предлагаемом варианте проверки работоспособности решения, алгоритм работает несколько по-другому. На первом этапе, как и в традиционном подходе, происходит подготовительная настройка параметров. Но после этого шага осуществляется загрузка программы управления в ядро СУ и оценка работоспособности решения. Данную проверку можно произвести на основе результатов нагрузочных тестов, получаемых на втором шаге способа синтеза кроссплатформенного контроллера автоматизации технологических процессов. На втором этапе происходит определение работоспособности решения с последующей конфигураций системы. На третьем этапе осуществляется работа СУ.
Стоит отметить, что с помощью данного алгоритма можно уменьшить количество срабатываний сторожевых таймеров watchdog, за счет изначального отсеивания параметров, которые выходят за допустимые значения при работе СУ на целевой программно-аппаратной платформы вычисления, но как было сказано выше, в данной работе не рассматриваются случаи стресс-тестирований, при котором система управления изначально работает при условиях, в которых параметры работы находятся очень близко к максимальным.
Таким образом, в традиционном подходе после загрузки программы управления в ядро СУ, происходит начало работы и, в случае выхода за предел, к примеру, времени цикла обработки компонентов программы управления, программа может завершиться с ошибкой.
В предлагаемом же варианте, до запуска работы происходит проверка возможности работы синтезированного контролера на основе результатов тестов, полученных на втором шаге предлагаемого способа.
Для того, чтобы определить возможности программно-аппаратной платформы, необходимо произвести тестирование с помощью специального набора программ.
Создание программ для нагрузочного тестирования вычислительных возможностей программно-аппаратных платформ является необходимым условием шага 2 предлагаемого способа синтеза кроссплатформенного контроллера автоматизации. Необходимо создать такие условия, в которых система управления (как автономное решение или вариант встраиваемого решения) будет максимально приближенна к реальным рабочим условиям [88]. Для этого следует разработать пакет программ управления, которые включали бы в себя различные компоненты, позволяющие моделировать нагрузку ядра системы управления (встраиваемого или автономного решения) в реальном времени. Также необходим специальный инструментарий, который будет обрабатывать получаемые данные. В качестве инструментария можно использовать или готовые решения или разработать свой собственный модуль, что будет являться оптимальным подходом, обеспечивающим гибкость и возможность быстрой модификации процесса тестирования [89].
Программы разрабатываются и загружаются в ядро контроллера автоматизации с использованием терминального клиента FBRedactor, ранее разработанного на кафедре компьютерных систем управления МГТУ «СТАНКИН» (рисунок 3.12)
Разработка программ ведется с использованием подхода «Plug-and-Play»: необходимые функциональные компоненты помещаются в рабочую область и соединяются между собой линиями связи [90]. Существуют стандартные компоненты и пользовательские. К стандартным относятся: входы и выходы (в том числе с синхронизацией), компоненты арифметических операций, компоненты таймеров, триггеров и счетчиков, компоненты логических операций, компоненты для реализации управления движением. К пользовательским компонентам программы управления относятся созданные программистами специальные наборы элементов, состоящие из стандартных, т.е. появляется возможность создавать и реализовывать свои функциональные необходимости на базе предлагаемых примитивов.
Таким образом, при создании программ для проведения нагрузочных тестирований необходимо охватывать всевозможные сущности, предлагаемые средой разработки программ управления.
Стоит отметить, что предлагаемое тестирование будет относится к нефункциональным видам тестирования и задействовать при этом следующие его подвиды: конфигурационное тестирование и, как уже было отмечено раньше, нагрузочное тестирование. Использование конфигурационного тестирования позволит провести направленную проверку работоспособности решения при различных конфигурациях СУ в зависимости от целевой вычислительной платформы исполнения (вид ЦП, ОЗУ и т.д.), а нагрузочное тестирование, в частности направление тестирования производительности, позволит определить возможную масштабируемость ядра контроллера автоматизации под нагрузкой (количество компонентов программы управления) [91].
Для успешного проведения тестирования, необходимо решить следующие задачи: получить значение показателей использования ресурсов вычислительной платформы при увеличении количества компонентов ПУ; обработать полученные данные и представить в виде табличных данных.
Проводимое тестирование представляет собой подход, при котором тестовые задания имитируют нагрузку на вычислительную платформу контроллера автоматизации, подобную той, которая в будущем будет создаваться при использовании системы управления. При этом стоит учесть, что набор компонентов - отдельные элементы и специальные пользовательские библиотеки - программы управлении при тестировании не несут какой-либо смысловой нагрузки.