A Method for modeling Finite State Machines in technological processes using SQL

Full Text

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

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

В робототехнике конечные автоматы применяются для управления движением роботов и манипуляторов. Например, робот-манипулятор может последовательно выполнять команды, такие, как захват детали, перемещение по заданной траектории и размещение на нужной позиции [3]. Каждое из этих действий можно рассматривать как состояние конечного автомата, а переходы между состояниями будут определяться датчиками или другими событиями, поступающими от системы управления.

Применение реляционной модели данных, представленной в виде таблиц, для моделирования конечного автомата обладает значительными преимуществами. Реляционная модель базируется на структуре, которая идеально подходит для представления состояний и переходов (рис. 1):

 

Рис. 1. Табличное представление состояний и переходов конечного автомата

 

• таблица состояний может содержать информацию о каждом состоянии автомата, включая его идентификатор, описание, временную метку и текущий статус (активное или неактивное состояние);
• таблица переходов может представлять переходы между состояниями, храня информацию о начальном и конечном состоянии каждого перехода, а также условиях, при которых переход осуществляется.

Запросы SQL позволяют легко получать информацию о текущем состоянии системы, истории переходов и условиях, которые привели к этим изменениям. Триггеры и хранимые процедуры могут использоваться для автоматизации переходов между состояниями на основе событий, поступающих в базу данных. Это позволяет настроить логику переходов, управляя процессами в реальном времени. Добавление новых состояний и переходов осуществляется путем простого обновления или добавления новых записей в соответствующие таблицы. Это упрощает модификацию системы при изменении требований или добавлении новых этапов процесса [4, 5]. Расширение функциональности достигается за счет добавления новых атрибутов в таблицы состояний и переходов, что позволяет хранить дополнительную информацию (например, временные метки, параметры оборудования или результаты проверки) [6]. Реляционная модель обеспечивает строгую ссылочную целостность данных (использование внешних ключей), которая позволяет гарантировать корректные связи между состояниями и переходами [7]. Например, можно спроектировать модель так, чтобы переходы всегда ссылались на существующие состояния.

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

1. Описание технологического процесса и модели конечного автомата. В рамках рассматриваемого технологического процесса осуществляются две основные операции – фрезерование и сборка изделия. Процесс начинается с подачи заготовок на два фрезерных станка, где они обрабатываются для получения деталей двух типов: «крышка» и «основание». Из этих деталей формируется готовое изделие на следующем этапе процесса – этапе сборки [9].

Для выполнения операций задействованы следующие исполнительные механизмы:

• конвейерные ленты – транспортируют заготовки и готовые изделия между различными участками процесса;
• два роботизированных технологических комплекса (РТК);
• фрезерный станок для обработки заготовок (компонент РТК);
• манипулятор для перемещения деталей и их закрепления (компонент РТК);
• пульт управления (ПУ), оснащенный цифровым дисплеем и кнопками «Пуск» и «Стоп» (компонент РТК);
• позиционеры, фиксирующие детали в нужной позиции для сборки;
• двухосевой манипулятор, отвечающий за перемещение и закрепление крышки на основании (рис. 2).

 

Рис. 2. Общий вид рассматриваемого технологического процесса сборки

 

Для контроля технологического процесса установлены три оптических датчика, которые используются для:

• контроля положения деталей на конвейерах;
• отслеживания состояния сборочной области;
• проверки завершенности операций на разных этапах (рис. 2).

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

• кнопка «Старт» – при запуске системы производится передача сигнала о старте на все устройства; производство должно обеспечить выпуск 20 сборочных единиц; в случае ошибки процесс автоматически останавливается для устранения сбоев;
• кнопка «Стоп» – при получении сигнала остановки с кнопки все устройства и механизмы (конвейеры, РТК и блок управления сборкой) получают команду на остановку.

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

Алгоритм управления сборкой включает следующие этапы:

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

Алгоритм управления процессом сборки с разграничением состояний конечного автомата представлен на рисунке 3.

 

Рис. 3. Алгоритм управления процессом сборки с разграничением состояний конечного автомата

 

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

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

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

Алгоритм, представленный на рис. 3, цикличен, цикл является бесконечным, последовательность переходов и входные сигналы (алфавит конечного автомата) определены, начальным является состояние q₁. Этот конечный автомат можно описать следующим образом (1):

$A=\left\{q_0, q_1, q_2, q_3, q_4, q_5, q_6, q_7\right\}, \delta , q_0, \left\{q_1\right\}$. (1)

В начале описано конечное множество состояний, далее функция переходов (таблица 1), начальное состояние и множество допускающих состояний.

 

Таблица 1. Функция переходов конченого автомата

F\q	Состояние q1	Состояние q2	Состояние q3	Состояние q4	Состояние q5	Состояние q6	Состояние q7
y1	q2	—	—	—	—	—	—
!y1	q1	—	—	—	—	—	—
y2	—	q3	—	—	q6	—	—
!y2	—	q2	—	—	q5	—	—
y3	—	—	q4	—	—	—	—
!y3	—	—	q3	—	—	—	—
y4	—	—	—	q5	—	q7	—
!y4	—	—	—	q4	—	q6	—
y5	—	—	—	—	—	—	q1
!y5	—	—	—	—	—	—	q7

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

При нажатии на кнопку «Старт» начальное состояние (q₁, «Ожидание деталей») активируется, и система ожидает выполнения условий для перехода. Каждый переход происходит при выполнении соответствующих условий (например, поступление обеих деталей, выдвижение манипулятора), которые фиксируются в триггерах. При выполнении перехода текущее состояние деактивируется, а следующее активируется, что отражается в атрибуте status. Для отслеживания истории переходов данные записываются в соответствующую таблицу, что позволяет анализировать выполненные действия и контролировать корректность работы системы.

Для удобства восприятия была выполнена декомпозиция таблиц на каждое состояние и переход конечного автомата (рис. 4).

 

Рис. 4. Физическая реляционная модель состояний и переходов конечного автомата

 

Структура таблиц будет рассмотрена на примере состояния q₂. Все состояния обладают обязательными атрибутами временной метки (datetime) и статуса (status), который может принимать значения «Active» или «Inactive». В соответствии с алгоритмом (рис. 3), в состоянии  позиционеры фиксируют детали для точного позиционирования на конвейере, после чего манипулятор выдвигается по оси OX. Таким образом, в таблице необходимо учитывать информацию о положении захватов правого и левого позиционеров (clamp_right, clamp_left), а также положение манипулятора по оси OX (axis_x). Это состояние должно быть связано как с предыдущим, так и с последующим состояниями, поэтому в таблице содержатся внешние ключи, связывающие переходы из q₁ в q₂ и из q₂ в q₃. (листинг 1).

 

Листинг 1. Создание таблицы для второго состояния конечного автомата

-- Второе состояние

CREATE TABLE State_Two (

id int auto_increment,

clamp_right tinyint(1),

clamp_left tinyint(1),

axis_x tinyint(1),

status enum (‘Active’, ‘Inactve’) default ‘Inactive’,

datetime timestamp,

transition_st1_st2_id int,

transition_st2_st3_id int,

primary key (id),

foreign key (transition_st1_st2_id) references transition_st1_st2(id)

on delete cascade

on update cascade

);

ALTER TABLE State_Two

add foreign key (transition_st2_st3_id) references transition_st2_st3(id)

on delete cascade on update cascade;

 

Для объяснения структуры таблицы переходов рассмотрим переход из состояния q₂ в состояние q₃ (рис. 3). Каждый переход включает обязательный атрибут временной метки (datetime). Согласно алгоритму, переход в состояние q₃ возможен при подаче сигнала от датчика, подтверждающего полное выдвижение манипулятора по оси OX. В связи с этим в таблице добавляется атрибут, отражающий движение манипулятора по оси OX (moving_x) (листинг 2).

 

Листинг 2. Создание таблицы для перехода из второго состояния в третье

-- Переход из второго состояния в третье

CREATE TABLE Transition_st2_st3 (

id int auto_increment,

moving_x tinyint(1),

datetime timestamp,

primary key (id)

);

 

Логика функционирования конечного автомата реализуется с помощью триггеров, созданных в системе управления базами данных (СУБД) MySQL. Они могут автоматически реагировать на изменения в таблицах состояний и переходов, что позволяет создать автономную систему управления без необходимости дополнительного программирования на внешних языках [10]. Например, триггеры типа after update или after insert могут отслеживать изменения статусов состояний и, в зависимости от этого, выполнять соответствующие переходы. Это позволяет эффективно описать логику переходов, минимизируя вероятность ошибок и снижая нагрузку на оператора. Триггеры также помогают обеспечить целостность и согласованность данных. Переходы между состояниями могут быть настроены так, что они срабатывают только при выполнении определенных условий, что исключает возможность случайного или некорректного перехода. Таким образом, триггеры позволяют гарантировать, что система всегда находится в одном из допустимых состояний и выполняет переходы в строгом соответствии с заданной логикой.

В данном примере используется триггер типа after update, который управляет переходом из третьего состояния в четвертое. Этот триггер встроен в структуру таблицы и применяет ветвление с помощью конструкции if/else. Если третье состояние завершено успешно и датчик, контролирующий состояние схвата манипулятора, подает сигнал, атрибут status в состоянии  устанавливается в значение «Active», а временная метка обновляется в соответствующей строке. В противном случае атрибут status принимает значение «Inactive». Таким образом, обеспечивается переход системы из состояния q₃ в q₄ (листинг 3).

 

Листинг 3. Создание триггера для описания логики перехода из состояния  в

CREATE TRIGGER `transition_st3_st4_AFTER_UPDATE` AFTER UPDATE ON `transition_st3_st4` FOR EACH ROW BEGIN

IF (NEW.GRAB_DETECTED=1) THEN

   UPDATE State_four

   SET STATUS = 'Active',

   DATETIME = NOW()

   WHERE NEW.ID = TRANSITION_ST3_ST4_id;

 ELSE

    UPDATE State_four

   SET STATUS = 'Inactive',

   DATETIME = NOW()

   WHERE NEW.ID = TRANSITION_ST3_ST4_id;

   END IF;

END

 

Заключение. В статье рассмотрен метод применения языка SQL для моделирования конечных автоматов в контексте управления технологическими процессами. Конечные автоматы, являясь мощной математической моделью, позволяют формализовать и структурировать последовательности операций, обеспечивая надежное управление состояниями системы и переходами между ними. Использование реляционной модели данных для представления состояний и переходов между ними позволяет создать гибкую и прозрачную систему управления, способную к адаптации и масштабированию в зависимости от потребностей производства. Реализация конечного автомата с использованием SQL в СУБД обеспечивает не только структурированное хранение и обработку данных о текущих состояниях и переходах, но и интеграцию с реальными исполнительными механизмами и датчиками. SQL-команды и структуры, такие, как таблицы состояний и переходов, а также триггеры и хранимые процедуры, дают возможность моделировать сложные технологические процессы, автоматизировать их выполнение и минимизировать ошибки, вызванные человеческим фактором.

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

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

About the authors

Vladimir A. Kholopov

MIREA – Russian Technological University

Email: Holopov@gmail.com
ORCID iD: 0000-0003-2108-8462
SPIN-code: 6007-8117

Candidate of Technical Sciences, Associate Professor, Head of the Department of Industrial Informatics

Russian Federation, 78, Vernadsky Ave., Moscow, 119454

Mark M. Klyagin

MIREA – Russian Technological University

Author for correspondence.
Email: mmklyagin@gmail.com

Senior Lecturer of the Department of Industrial Informatics

Russian Federation, 78, Vernadsky Ave., Moscow, 119454

Roman M. Ogoreltsev

MIREA – Russian Technological University

Email: ogorelcev@mirea.ru
SPIN-code: 4579-5530

Assistant of the Department of Industrial Informatics

Russian Federation, 78, Vernadsky Ave., Moscow, 119454

References

Supplementary files