Разработка системы тестирования для отработки действий в нештатных ситуациях сотрудниками Иркутской нефтяной компании

Popkov S., Sychov P. Development of a testing system for processing actions in an emergency situations by employees of the Irkutsk Oil Company. System Analysis in Science and Education, 2021;(2):9–17(In Russ). Available from:

Основным месторождением Иркутской нефтяной компании (ИНК) является Ярактинское нефтегазоконденсатное месторождение, расположенное в Иркутской области. В этом месторождении добывается примерно 80 % углеводородного сырья компании [1]. Технологический комплекс данного месторождения состоит из дожимной насосной станции (ДНС), установки подготовки нефти (УПН) и системы очистки нефти (СОН). Управление оборудованием осуществляется системой на базе концепции SCADA . Рассматриваемая система тестирования предназначена для сотрудников Ярактинско-го месторождения [2].

Система тестирования сотрудников ИНК представляет собой веб-приложение, которое предоставляет возможность обучить персонал компании последовательности действий в различных чрезвычайных ситуациях.

В основе системы лежит такая концепция программных продуктов, как SCADA . Принципиальным решением в рамках данной концепции является сбор, обработка, отображение и архивирование информации в режиме реального времени [3]. Такой подход к управлению информацией применяется во всех отраслях хозяйства, где требуется обеспечить операторский контроль за технологическими процессами в реальном времени. SCADA -система может являться частью автоматизированной системы управления технологическими процессами (АСУТП), системы экологического мониторинга, научного эксперимента, автоматизации задания и т. д.

Применительно к нефтегазовой отрасли промышленности, SCADA -система выполняет функции мониторинга оборудования в режиме реального времени, управления оборудованием, отображения текущего состояния ресурсов в виде мнемосхемы , регистрирования нештатных ситуаций и записи журнала произошедших событий [4].

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

Математическая модель

Сценарий нештатной ситуации создается на базе выбранной мнемосхемы (или нескольких мнемосхем), либо на базе существующего сценария. Прогресс изменений всех показателей на схеме фиксируется с помощью графа состояний. В рамках одного сценария Администратор задает несколько «узловых точек» на данном графе, а также ребра, которые связывают эти узловые точки [ Ошибка! Источник ссылки не найден. ]. Каждый узел графа представляет собой совокупность параметров всех элементов, расположенных на мнемосхеме (значение, цвет, анимация), а также уведомление на панели статусов в определенный временной «срез». Каждое ребро представляет собой промежуток времени, проходящий между «срезами». Администратор добавляет/редактирует/удаляет элементы графа состояний и параметры элементы мнемосхемы для каждого узла.

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

• -    Указать количество возможных вариантов причины аварии, заполнить поля ответов (свои или из справочников) и указать правильный вариант.

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

• -    Указать критерии оценивания (таблица: количество ошибок - оценка).

Расчёт дискретного времени

Так как рассмотренное понятие «узловых» точек на графе состояний системы не имеет привязки ко времени, необходимо ввести понятие расчета дискретного времени. С помощью введения этой формулы будет возможно проведение математического моделирования. Укажем минимальный возможный момент времени : ■ , количество кадров в секунду :":: и запишем формулу расчёта интерва ла обновления (1):

■ = —-                                       (1)

/Р5

Для : ■ , равного 1000 мс (1 секунда), интервал обновления с шагом в 1 кадр в секунду будет ра вен 1000 мс. Интервал обновления является шагом моделирования. Введем также понятие скорости воспроизведения моделирования - -" .w . . Запишем итерационную формулу расчета времени воспроизведения (2):

:=:_-. .■ .—:.'                                    ⁽²⁾

где требуется указание начального момента времени :_:. Примем его равным 0. Общее модельное время обозначим через : ■ ■   (3) .

^р ^min — ®t — ^тах

Введем понятие количества датчиков системы Г (4) :

SjJ < 5

Для датчика _ ; ; _" возникает событие _ : , при котором меняются величины показателей датчика .■ . Таким образом, состояние системы з; в момент времени : , с учетом рассмотренных ранее формул 1 и 2 может быть рассчитано по формуле 5:

Полученная формула представляет собой искомый процесс моделирования показателей датчиков оборудования во время сценария. Рассмотрим далее более подробно механизм расчета показателя датчика Sj в момент времени ti .

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

Для расчета текущего состояния показателей датчика Sjto введем понятия предыдущего состояния датчика: зАЧ-к) , и последующего: Sj№+i). Таким образом, требуется также задать граничные значения показателей. Будем считать нулевое (стандартное) значение показателей начальным условием. Обозначим его как Sj(tmin). Рассмотрим на формуле 6 случай, если для показателей датчика больше не задано событий, а модельное время еще не закончилось.

Sj^ = SjC^,).

Так, даже если для показателей датчика не задано ни одного события, то по формуле 6 для каждого временного отрезка оно будет считаться как значение в момент завершения моделирования, которое в таком случае равно нулевому значению датчика (7) :

$Д) = s,(tmln) = s,^), еслиvti$i – не задано.

Рассмотренные математические выкладки определяют значения показателей датчиков только в тех случаях, если для t^Sj . Однако по такой логике необходимо для каждого момента времени задать значение показателей датчика. Например, моделирование линейного увеличения показателей датчика на большом объеме модельного времени не представляется возможным. Решением данной проблемы может быть введение линейной зависимости значений показателей датчиков между соседними событиями на модельном времени. Введем понятия времени предыдущего события 4 rev и времени последующего события ^next , которые были заданы как начальные условия для определенного датчика Sj . То есть, для этих величин были заданы Sj(tprev) и ^si(^n#xrJ. В том случае, если для датчика задано всего одного событие в момент времени ^next , то ^nrev ^min . Если следующее событие не определено, ^next ^max . Рассмотрим измененное представления события на формуле 8, учитывающее возможность линейного изменения показателей:

SjCt^At), где At вычисляется по формуле 9.

^nexr — ^prer

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

Проектное решение

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

Мнемосхема отображает все задействованные объекты, показания их датчиков и цветовую индикацию. Цветовая индикация изменяется в зависимости от показателей датчиков, относительно настроек, указанных при настройке сценария. Цветовая индикация клапанов/арматуры отображает статус элемента:

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

• -    Зеленый цвет - нормальное значение параметра; технический агрегат исправен и включен;

• -    Желтый цвет - используется для предупредительной сигнализации значений параметров, вывода предупреждающих сообщений;

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

Значения уровней в Системе отображаются в виде столбчатых диаграмм, высота которых соответствует текущему значению уровня в диапазоне 0-100%.

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

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

Все сообщения разбиты на несколько классов:

• -    Аварийные - превышение параметром аварийной границы, неисправность механизма и т.д. Цвет фона сообщения - красный.

• -    Предупредительные - превышение параметром предупредительной границы. Цвет фона -желтый.

• -    Диагностические - сообщения о неисправностях модулей, датчиков, ошибках работы программного обеспечения и пр. Цвет фона - черный.

• -    Каждое сообщение состоит из нескольких текстовых полей:

• -    дата - дата фиксирования сообщения системой;

• -    время - время фиксирования сообщения системой;

• -    элемент - элемент, к которому относится зафиксированное событие;

• -    событие - описание события (текст сообщения);

• -    класс - класс сообщения (аварийное, предупредительное и т.д.).

Показания датчиков, список событий и цветовая индикация задаются Администратором при со-здании/настройке сценария мнемосхемы.

Диаграммы вариантов использования

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

Тренажёры ИНК

__          {Если было выбрано .        «обучение»}

Пройти тестирование^- -«расширить»- -

<<включить>>

<<включить>>

Выбрать датчик

<<включить>>

Выбрать пользователя

Просмотреть статистику

Администрато

Выбрать сценарий

_ .«расширить»

Редактировать сценарий

Пройти тестирование с показом ошибок

{Если было выбрано   .—""'                  1—._,

«добавить»}    ^Добавить сценарий

■  «расширить»—

{Если было выбрано Удалить сценарий

«удалить»}          ----------

{Если было выбрано -х----- "-.

«добавить»}    (^Добавить датчик

, _«расширить»

Редактировать датчик

«расширить» _

{Если было выбрано «удалить»}

Удалить датчик

<<включить>>

{Если было выбрано «добавить»}

______•                       - «расширить»

Редактировать пользователя

----------- <<расш ирить>>_

{Если было выбрано «удалить»}

Добавить пользователя

Удалить пользователя

Рис. 1. Диаграмма вариантов использования для Администратора

Рассмотрим диаграмму вариантов использования для Пользователя (см. рис. 2) .

На диаграмме (рис. 2) показаны следующие прецеденты использования: «Пройти тестирование», «Выбрать сценарий» и «Пройти тестирование с показом ошибок». Выполнение прецедента «Пройти тестирование» требует обязательного выполнения прецедента «Выбрать сценарий». Прецедент «Пройти тестирование с показом ошибок» расширяет прецедент «Пройти тестирование» при выполнении логического условия «Если было выбрано “обучение”».

Ролевая модель программной системы

Доступность функций системы в ролевой структуре представлена на таблице 1.

Табл. 1. Ролевая модель системы

Сценарий                     Пользователь	Администратор
Пройти тестирование                         +	+
Пройти экзамен                           + Пройти сценарий в режиме обучения                  +	+ +
Редактировать сценарий	+
Редактировать сценарий	+
Редактировать датчик Редактировать мнемосхему	+ +
Просмотреть статистику прохождений	+

Внедрение системы

Ввод в эксплуатацию

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

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

Рис. 3. Настройка сценария

В зависимости от выбранного режима прохождения система отображает соответствующий вид страницы сценария (см. рис. 4, 5) .

Рис. 4. Прохождение сценария в режиме обучения

Рис. 5. Прохождение сценария в режиме экзамена

Заключение

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

Уникальность исследования заключается в новом способе проведения тестирования специалистов по ликвидации аварий в среде веб-приложения, моделирующего поведение реального оборудования ЯНГКМ. В итоге была разработана уникальная система, целью использования которой ставится повышение количества успешно ликвидированных нештатных ситуаций.