Архитектура: снапшоты, состояния, события

Поток данных

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

Снапшот (snapshot) - представляет набор данных, считанных с ЧПУ или контроллера. Как правило, этот набор данных объединяет логически связанные данные и соответствует одной транзакции чтения данных с ЧПУ или контроллера.

Состояние (state) - отвечает за обработку "сырых" данных из снапшота и приведение к нормализованному виду, понятному системе.

Событие (event) - описывает то, как данные должны передаваться из DPA сервера в DPA хост, по какому событию и с использованием какого транспорта.

Транспорт - отвечает за пересылку данных по событиям драйверов от DPA сервера в DPA хост, определяет протокол и способ доставки. Подробнее можно прочитать тут: Архитектура Транспорта DPA.

Индикатор - логический объект данных для оборудования. Как правило, связан со структурной единицей (канал, шпиндель, ось и т.д.). Определяет способ хранения данных, а так же способ использование данных в аналитиках.

Снапшоты

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

Для доступа к снапшотам драйвера:

=> => DPAhost \ DPAserver \ Драйвера \ <Драйвер> \ Snapshots\ <Снапшот>

Набор снапшотов определяется не только типом драйвера, но и конфигурацией оборудования, может зависеть от количества каналов, осей, шпинделей. Например, для 1-канального SIEMENS SINUMERIK c 3-мя осями и 1-м шпинделем может использоваться такой набор снапшотов:

• Actual feedrate (channel 1)
• Axis load (axis 1)
• Axis load (axis 2)
• Axis load (axis 3)
• Feedrate override (channel 1)
• Machine mode (channel 1)
• Machine state (channel 1)
• Machine statistics (channel 1)
• Messages (channel 1)
• NC program (channel 1)
• NC sub program (channel 1)
• Rapid traverse override (channel 1)
• Spindle load (spindle 1)
• Spindle override (spindle 1)
• Spindle speed (spindle 1)

Настройки снапшота Machine mode для 1-го канала SIEMENS SINUMERIK могут выглядеть следующим образом:

Этот снапшот содержит 4 элемента данных (opMode, machFunc, trialRunActive, singleBlockActive). Так же для снапшота определяется частота чтения и таймаут чтения.

Текущее значение данных снапшота можно увидеть в узле :

Cостояния

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

На уровне DPA сервера определены глобальные типы состояний. Они задают "контракт" или "сигнатуру", которую должны обеспечивать состояния, определенные для каждого конкретного драйвера. Например, если на уровне DPA сервера определен тип состояния "Управляющая программа", и в нем содержатся два элемента данных ("Main program" и "Status"), то каждое состояние каждого драйвера, которое возвращает данные по управляющим программа, обязано следовать этим требованиям.

Для доступа к типам состояний DPA сервера:

=> => DPAhost \ DPAserver \ Состояния

Для доступа к состояниям, сконфигурированным для конкретного драйвера:

=> => DPAhost \ DPAserver \ Драйвера \ <Драйвер> \ States

Пример настройки типа состояния "Управляющая программа":

Пример настройки состояния "NC program" для 1-го канала драйвера:

Обратите внимание, поле "Состояние" ссылается на тип состояния "Управляющая программа". Класс устройства и номер устройства определяют привязку к 1-му каналу. Состояние активно.

Состояния могут использовать один из двух механизмов формирования данных:

1. Simple - это копирование данных из снапшота или другого состояния.
2. Script - выполнение скрипта для формирования данных состояния.

Момент срабатывания состояния определяют триггеры. Возможны следующие варианты:

1. Триггер Snapshot - состояние будет вычисляться при изменении данных в указанном снапшоте.
2. Триггер State - состояние будет вычисляться при изменении данных в указанном состоянии.
3. Триггер Timer - состояние будет вычисляться по таймеру.

Если состояние не активно, то срабатывание триггеров не будет приводить к его вычислению.

Как и для снапшотов, текущее значение данных состояния можно увидеть в узле .

Cобытия

События определяют: когда, какие данные и по какому транспорту должны быть отправлены.

Для доступа к событиям, сконфигурированным для конкретного драйвера:

=> => DPAhost \ DPAserver \ Драйвера \ <Драйвер> \ Events

Событие может быть активно, тогда по нему происходит отправка данных. Либо не активно.

Так же, как и для состояний, для событий задаются триггеры.

Данные для отправки определяются привязкой события. Привязка может быть трех видов:

1. Snapshot - событие отправит данные указанного снапшота.
2. State - событие отправит данные указанного состояния. Это стандартный и рекомендуемый вариант.
3. Script - событие отправит данные, сформированные скриптом.