Введение

В условиях цифровой трансформации промышленности и активного внедрения технологий Индустрии 4.0 возрастают требования к подготовке инженеров в области автоматизации технологических процессов и производств. Современный специалист должен обладать не только теоретическими знаниями о принципах функционирования автоматизированных систем управления, но и навыками моделирования технологических объектов, разработки алгоритмов управления, программирования промышленных контроллеров и анализа работы создаваемых систем [1–3].

Использование цифровых двойников и виртуальных производственных сред сегодня является одним из направлений развития инженерного образования. Они позволяют моделировать работу оборудования, проверять алгоритмы управления и разбирать производственные ситуации без постоянного доступа к реальным промышленным установкам [4–6]. Студенту это дает возможность увидеть последствия ошибки, изменить алгоритм и снова проверить работу системы.

Отдельно стоит моделирование программируемых логических контроллеров. Просто изучить команды контроллера недостаточно – важно видеть весь процесс целиком: поступление сигнала, его обработку, управляющую команду и реакцию механизма. Поэтому виртуальная производственная среда и моделирование контроллера хорошо дополняют друг друга [7–9].

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

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

В научных работах цифровые двойники, виртуальные лаборатории и проектное обучение рассматриваются как перспективные инструменты подготовки инженерных кадров [10–12]. При этом чаще они описываются отдельно. Вопрос о том, как объединить модель технологического объекта, программирование контроллера, поиск ошибок и защиту решения в одну последовательную учебную работу, представлен заметно меньше.

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

Научная новизна исследования состоит в объединении учебного цифрового двойника, моделирования программируемого логического контроллера и проектной работы в одну последовательную методику. Студент проходил весь путь: анализировал технологическую задачу, определял входные и выходные сигналы, составлял алгоритм, программировал контроллер, запускал систему, находил ошибки и защищал полученное решение.

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

Цель исследования – разработка и экспериментальная проверка проектно-лабораторной методики формирования профессиональных компетенций студентов направления 15.03.04 «Автоматизация технологических процессов и производств» с применением учебного цифрового двойника и моделирования ПЛК.

Материалы и методы исследования

Исследование проводилось в течение 2025/2026 учебного года на кафедре «Автоматизация технологических процессов и производств» ФГБОУ ВО «Казанский государственный энергетический университет» в рамках дисциплины «Программное обеспечение систем управления». Использовались педагогический квазиэксперимент, тестирование, экспертная оценка и статистическая обработка данных. Сначала по входной диагностике проверяли, насколько группы сопоставимы между собой, а потом уже сравнивали результаты до и после формирующего этапа.

Всего участвовали 46 студентов третьего курса направления 15.03.04 «Автоматизация технологических процессов и производств». В контрольной группе было 23 чел. и в экспериментальной тоже 23.

Полной рандомизации не было, потому что работали с уже сформированными учебными группами. При этом условия старались оставить одинаковыми: занятия вел один преподаватель, использовалась одна рабочая программа, объем аудиторной и самостоятельной работы не отличался. То есть основное различие между группами было именно в организации практической работы, а не в количестве занятий или содержании дисциплины.

Исходную сопоставимость групп оценивали по результатам входной диагностики. Формирующий этап продолжался 12 недель: 36 ч аудиторной и 18 ч самостоятельной работы. В контрольной группе студенты выполнили шесть традиционных лабораторных работ в CODESYS Control Win V3 по готовым схемам и инструкциям. Задания включали работу с входными и выходными сигналами, команды запуска и остановки, таймеры и счетчики, последовательный алгоритм, аварийный останов и поиск ошибок.

В экспериментальной группе те же по содержанию и сложности действия соединялись в один проект. Здесь использовались Factory I/O [13], CODESYS Control Win V3 [14] и обмен данными по протоколу Modbus TCP [15]. Студент работал уже со всей системой: анализировал объект, составлял алгоритм, программировал контроллер, запускал модель и разбирался с ошибками.

В качестве виртуального технологического объекта использовался конвейерно-сортировочный участок Sorting by Height (Advanced) в Factory I/O. Коробки поступали на линию и распределялись в зависимости от высоты. Для работы участка требовалось согласованное управление датчиками, конвейерами и поворотным столом.

Управляющая программа разрабатывалась в CODESYS Control Win V3. Связь между CODESYS и Factory I/O выполнялась через Modbus TCP: виртуальный датчик передавал сигнал программному контроллеру, программа его обрабатывала и возвращала управляющую команду в модель. Если алгоритм был написан неправильно, ошибка проявлялась в поведении участка, а не только в коде.

К входным сигналам относились запуск, остановка, сброс и аварийный останов, а также сигналы датчиков наличия и высоты коробки, положения поворотного стола и состояния выходных участков. Такой набор позволял студенту видеть текущее состояние объекта и учитывать его в алгоритме управления.

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

Кроме обычного режима сортировки задавались ситуации, в которых студенту нужно было разбираться с нарушением работы системы: занятость поворотного стола или выходного конвейера, аварийный останов, сбой датчика и блокирование коробки. Коробки поступали на линию и дальше распределялись по высоте. На первый взгляд задача простая, но для нормальной работы участка нужно было согласовать датчики, конвейеры и поворотный стол. Если хотя бы один элемент отрабатывал не вовремя, вся последовательность уже нарушалась. Управляющая программа создавалась в CODESYS Control Win V3, а связь с Factory I/O выполнялась через Modbus TCP. Работало это так: виртуальный датчик передавал сигнал в программный контроллер, программа его обрабатывала и возвращала команду обратно в модель. Если алгоритм был написан неправильно, ошибка сразу была видна уже на самом участке. Например, коробка могла уйти не туда, стол не повернуться или конвейер включиться не в тот момент. То есть проблема проявлялась не только в коде, а в поведении всей системы. К входным сигналам относились запуск, остановка, сброс, аварийный останов, а также сигналы датчиков наличия и высоты коробки, положения поворотного стола и состояния выходных участков. По этим сигналам студент понимал, что сейчас происходит с объектом и какое действие должно выполняться дальше.

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

Условия реализации и масштабирования методики. Для работы нужны компьютерные рабочие места с Factory I/O и CODESYS Control Win V3 и возможностью настроить обмен по Modbus TCP. Подключение к реальной промышленной установке не требуется. Учебная работа строится последовательно: анализ задачи, определение сигналов, алгоритм, программирование, запуск модели, диагностика ошибок и защита проекта. Занятия может проводить преподаватель профильной дисциплины; итоговые проекты в исследовании дополнительно оценивали три преподавателя профильной кафедры. При переносе методики можно использовать другой виртуальный технологический объект, если сохраняется указанная последовательность работы.

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

Диагностика включала четыре части по 25 баллов: теоретическую, алгоритмическую, программно-практическую и проектно-диагностическую. Максимальный итоговый результат составлял 100 баллов.

Теоретический блок включал вопросы по устройству программируемого логического контроллера, входным и выходным сигналам, последовательным алгоритмам, Modbus TCP и требованиям безопасности.

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

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

Проектно-диагностическая часть уже объединяла все предыдущие действия. Студент разрабатывал управление сортировочным участком целиком: определял высоту коробки, выбирал нужный конвейер, управлял поворотным столом, задавал аварийный останов и последующий сброс. То есть здесь уже было видно, может ли он связать отдельные команды и состояния в одну нормально работающую систему.

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

Каждый из четырех критериев оценивался максимум в 25 баллов. 0–6 баллов – задание фактически не выполнено или имеются критические ошибки. 7–12 – выполнено частично. 13–18 – основная логика правильная, но остаются ошибки или слабое объяснение. 19–25 баллов – решение полное, и студент может его самостоятельно обосновать.

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

По общей сумме результаты делили на три уровня: 0–49 баллов – низкий, 50–74 – средний, 75–100 – высокий.

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

Статистику проводили в несколько этапов. Сначала проверяли сами данные: нормальность распределения – критерием Шапиро – Уилка и по Q–Q графикам, однородность дисперсий – критерием Левена. Затем сравнивали группы. Итоговый балл между контрольной и экспериментальной группами оценивали t-критерием Уэлча и дополнительно U-критерием Манна – Уитни. Динамику внутри каждой группы до и после обучения – парным t-критерием.

Для четырех отдельных сравнений по критериям использовали поправку Холма – Бонферрони, чтобы не получить значимость просто из-за большого количества проверок. Значимым считали p < 0,05. Дополнительно рассчитывали d Коэна, то есть смотрели не только на то, есть ли статистическая разница, но и на то, насколько она вообще большая.

Этические аспекты исследования

Участие студентов именно в исследовательской части было добровольным. До начала сбора данных им объясняли цель работы и получали информированное согласие. Если студент не хотел, чтобы его результаты использовались в исследовании, это никак не влияло на оценку по дисциплине.

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

Перед статистической обработкой фамилии и имена заменялись кодами. В статье приводятся только общие результаты по группам, без раскрытия персональных данных.

Результаты исследования и их обсуждение

Сначала посмотрели входные результаты. Контрольная и экспериментальная группы на старте были практически одинаковыми по уровню подготовки. Распределение студентов по низкому, среднему и высокому уровням статистически значимо не различалось: χ² = 0,10; df = 2; p = 0,951. То есть явного преимущества у одной из групп изначально не было. После завершения экспериментального модуля результаты выросли в обеих группах, но уже по-разному. В контрольной группе средний балл увеличился с 42,8 ± 11,2 до 57,8 ± 10,5. Плюс 15 баллов. В экспериментальной было 43,7 ± 11,1, а стало 74,7 ± 9,2 балла. Здесь уже плюс 31 балл – практически в два раза больший прирост. Наиболее заметная разница получилась по алгоритмическому, программно-практическому и проектно-диагностическому критериям, то есть там, где студенту нужно было не просто ответить на вопрос, а самому составить алгоритм, написать программу, запустить систему и разобраться с ошибкой. Эти результаты представлены в табл. 1.

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

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

Изменилось и распределение студентов по уровням подготовки – здесь разница между группами тоже стала заметной. В экспериментальной группе доля студентов с высоким уровнем выросла с 13,0 до 52,2 %, а с низким уровнем – снизилась с 39,1 до 8,7 %. В контрольной группе высокий уровень изменился с 13,0 до 17,4 %.

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

При этом связывать полученный результат только с Factory I/O или только с моделированием программируемого логического контроллера было бы неправильно. В экспериментальной группе менялся весь способ организации работы: проект, программирование, самостоятельная отладка, поиск ошибок и защита решения. Поэтому эффект относится к комплексной проектно-лабораторной методике.

Для проверки устойчивости различий отдельно сравнивали итоговые результаты контрольной и экспериментальной групп и динамику внутри каждой группы. Результаты представлены в табл. 2.

Таблица 1

Динамика критериальных результатов студентов, M ± SD, баллы

Примечание: составлена автором на основе полученных данных в ходе исследования.

Таблица 2

Статистическая проверка результатов педагогического эксперимента

Примечание: составлена автором на основе полученных данных в ходе исследования.

Применение поправки Холма – Бонферрони к четырем дополнительным сравнениям не изменило выводов исследования: различия между группами по каждому критерию сохранили статистическую значимость (скорректированное p < 0,001). Результаты t-критерия Уэлча и U-критерия Манна – Уитни также совпали по направлению вывода.

Размер эффекта составил

d Коэна = 1,71.

Различие получилось крупным, но здесь важно учитывать условия самого исследования. Всего участвовали 46 студентов, а полной рандомизации не было. Поэтому результат выглядит убедительно, но переносить его без дополнительной проверки на другие группы было бы слишком прямолинейно.

При выполнении и защите проектов встречались и типичные ошибки. Например, неправильный приоритет аварийного останова, путаница во входных и выходных сигналах, пропуск состояния ожидания или сброса. Иногда студент находил ошибку в программе, но не мог аргументированно объяснить, почему она вообще появилась.

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

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

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

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

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

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

Заключение

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

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