Реферат системы работы с очередями задач

Обновлено: 18.05.2024

Прежде чем изучить, зачем нужна очередь, представим ситуацию, что у нас есть две какие-то задачи и мы хотим из одной задачи в другую передать какие-то данные. Но так как входные параметры в задаче не предусмотрены, кроме параметров, которые передаются только при создании задачи для обеспечения её уникальности, то в нашу голову (если мы конечно ничего не знаем про очереди) придёт мысль использовать глобальные переменные. Только делать этого при использовании FreeRTOS категорически нельзя. Так как планировщик устроен так, что он может в любой момент переключить задачи и ответственность он несёт только за сохранение локальных переменных, используя стек задачи, а за то, что в этот момент может происходить запись значения глобальной переменной, он абсолютно не отвечает, и поэтому там могут оказаться абсолютно непредсказуемые данные. Вот для этого и нужны очереди.

Очередь — это своего рода массив значений как правило одного типа, в который мы можем сохранять значения из одной задачи или нескольких, а выбирать их из другой задачи или других задач. Только данный массив представляет собой такой буфер, в который доступ мы получаем не к любому элементу, а именно к определённому, поэтому данное свойство очереди мы должны учитывать. Данный буфер чаще всего используется по типу FIFO (первым пришел — первым вышел), реже этот буфер может быть использован как LIFO или стек (магазин), где принцип уже другой (последним пришёл — первым вышел). Данный тип очереди используется гораздо реже и для этого используется другая функция выборки. Думаю, что нам такая функция (по крайней мере в рамках данного занятия), не потребуется, и голову мы забивать себе не будем.

Размер очереди (или данного буфера) не ограничен, но только эту возможность также нужно использовать с умом. Если мы сделаем слишком большой размер очереди, то мы можем долго ждать того, когда функция-приёмник (или получатель) получит данные от функции-источника (или провайдера).

Когда используются очереди в системе реального времени FreeRTOS? Да очень часто, когда есть риск перепутывания данных, например, при печати на принтер, либо при выводе в порт. Мы в этом случае организовываем отдельную задачу передачи в порт информации, а данные для неё черпаем из очереди, в которую они придут из других задач.

В очереди кроме данных можно также передавать целые массивы и даже структуры. Как это делать, мы также сегодня научимся.

Давайте немного отдохнём от моих заумных фраз, чтобы у нас не закипели головы, и перейдём к проекту.

Проект мы создадим на основе проекта урока 110 TASK_PRIOPITIES и назовём его TASKS_QUEUES.

Откроем наш проект в проектогенераторе Cube MX, и, вообще ничего не трогая сгенерируем проект для SystemWorkbench, откроем его там, настроим оптимизацию 1 и уберём отладочную конфигурацию, если таковая будет иметь место в проекте.

Откроем файл main.c, закомментируем строки с ошибками в инициализации DMA2D, соберём проект, если всё нормально собралось, то продолжаем дальше нашу работу над проектом.

Исправим немного вывод шапки для актуальности

TFT_DisplayString( 0 , 10 , ( uint8_t *) "Queues" , CENTER_MODE );

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

osThreadId Task01Handle,Task02Handle,Task03Handle,TaskStringOutHandle;

Создадим для функции задачи прототип

void Task01( void const * argument);

void TaskStringOut( void const * argument);

Добавим для задачи функцию выше функции Task1

void TaskStringOut( void const * argument)

for (;;)

sprintf (str1, "task %lu" , osKernelSysTick());

TFT_DisplayString( 120 , 60 , ( uint8_t *)str1, LEFT_MODE );

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

В функции main() создадим нашу задачу и присвоим ей более высокий приоритет, чем наши подопытные три задачи, причём даже выше, чем мы им присваиваем после, а не при создании. Стек тоже назначим побольше, так как строки могут быть разные

arg03. delay_per = 439 ;

osThreadDef(tskstrout, TaskStringOut, osPriorityBelowNormal , 0 , 1280 );

TaskStringOutHandle = osThreadCreate(osThread(tskstrout), NULL);

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

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

Следует отметить, что помимо того, что какие-то задачи посылают данные в очередь, а какие-то получают из неё, существует некий порядок работы с очередями или даже особенности. Что касается принимающей задачи, то если в очереди нет данных, то задача уйдёт в блокированное состояние и будет в нём пребывать то количество системных квантов, которое мы укажем в таймауте во входных параметрах функции. Таким образом, если не будет данных в очереди, то мы даём возможность выполниться задачам с меньшим приоритетом, что очень неплохо. Также есть ещё одна особенность. Существует ещё два способа выборки данных из очереди. Первый — это когда задача считает данные из очереди и запишет их в некую переменную либо куда-то в память, и после этого считанные данные из очереди удаляются автоматически. А есть второй способ, когда мы можем использовать такую функцию, что данные у нас из очереди скопируются в переменную или буфер, а в очереди они останутся. Но данный способ мы рассматривать не будем.

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

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

Теперь опять вернёмся к практике и, следовательно, к нашему проекту.

Сначала мы попробуем более простой тип очереди — это обычные данные (не массивы и не структуры).

Создадим специальную глобальную переменную для очереди

osMessageQId pos_Queue;

Добавим макрос для размера очереди

struct_arg arg01, arg02, arg03;

Мы будем создавать очередь, состоящую всего из одного элемента для простоты. Вы, в свою очередь (опять эта очередь!), можете поиграть с другими размерами.

Создадим очередь в функции main() в специально отведённом для этой цели месте

/* USER CODE BEGIN RTOS_QUEUES */
/* add queues, . *//* USER CODE END RTOS_QUEUES */

osMessageQDef(pos_Queue, QUEUE_SIZE, uint16_t );

pos_Queue = osMessageCreate(osMessageQ(pos_Queue), NULL);

/* USER CODE END RTOS_QUEUES */

Код для создания очереди чем-то напоминает код для создания задач и семафоров.

То есть, здесь мы объявили очередь количеством в один элемент типа шестнадцатибитного беззнакового целого числа.

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

osMessagePut(pos_Queue, arg-> y_pos , 100 );

Таймаут установим в 100 системных квантов (в нашем случае 100 милисекунд). Думаю, этого будет достаточно, чтобы дождаться опустошения очереди.

Теперь перейдём в функцию задачи вывода строки на дисплей TaskStringOut и добавим там переменную специального типа структуры, предназначенной для свойств и событий очереди

void TaskStringOut( void const * argument)

osEvent event;

event = osMessageGet(pos_Queue, 100 );

if (event. status == osEventMessage )

sprintf (str1, "task %lu" , osKernelSysTick());

TFT_DisplayString( 120 , event. value . v , ( uint8_t *)str1, LEFT_MODE );

Соберём код, прошьём контроллер и проверим результат. Я не буду показывать все шесть этапов изменения приоритетов, покажу только последний этап, когда все задачи будут работать с одинаковым приоритетом. Можете поверить мне на слово, что таким образом (без артефактов) они теперь работают всегда

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

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

Отладочную плату можно приобрести здесь 32F746G-DISCOVERY

Очередь (queue) и стеки; структура данных, обработка (удаление) её элементов и порядок их поступления (добавления). Массивы и переменные указатели, реализация очереди с помощью массива, операции над очередями и их реализация, усовершенствования процедур.

Рубрика	Программирование, компьютеры и кибернетика
Вид	реферат
Язык	русский
Дата добавления	12.12.2009
Размер файла	73,4 K

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Выполнила Майдобурова С.А.

Введение

Очереди

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

в очередь из очереди

Есть несколько способов реализации такой структуры. Простейшей является реализация при помощи массива и двух переменных-указателей, один из которых определяет то место массива, куда элемент будет добавляться, и называется концом очереди (УК), а другой - определяет то место массива, откуда элемент будет удаляться, и называется началом очереди (УН). Если УК<>УН, то в очереди есть элементы, при этом элемент с меньшим номером считается поступившим в очередь раньше, чем элемент с большим номером.

Допустим, в очередь помещён элемент А, потом В, потом С. Тогда очередь имеет вид:

УН УК

Когда потребуется удалить элемент, то первым обязан будет удалиться элемент А.

УН УК

Теперь первым элементом в очереди будет В, а последним - С. Удаление происходит путём перемещения указателя УН, при этом элемент А остаётся в массиве (но не в очереди).

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

УН УК

Если нужно будет удалить какой-нибудь средний элемент очереди (например, С), сначала нужно удалить элементы, идущие до него (элемент В).

Очередь, где нет ни одного элемента, называют пустой. В этом случае УК=УН.

Реализация очереди с помощью массива.

В программе для реализации структуры очередь будем использовать массив Q. В качестве указателя УН возьмём переменную n, а в качестве УК - переменную k. В самом начале переменным n и k присваивается значение 1. Условие n=k говорит о том, что очередь пуста.

Для работы с очередью определим четыре элементарные операции:

Pusto - создаёт пустую очередь.

Proverka - возвращает значение true, если очередь пуста, и false в противном случае.

Dobav - добавляет элемент в конец очереди.

Udalen - удаляет элемент из начала очереди.

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

1. Т.к. будет использоваться массив, то в переменную max лучше описать в разделе констант (задать её значение).

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

Система на основе обобщенной очереди задач

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

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

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

Интерфейс контейнера-источника

Любая очередь задач функционирует на основе набора задач, требующих обработки. В зависимости от конкретного приложения, реализованного на базе очереди задач, существует множество источников задач, в нее попадающих. Но после получения набора задач схема работы очереди оказывается довольно простой. Следовательно, мы можем отделить специфичную для приложения логику работы источника задач от обобщенной схемы обработки очереди задач. Вспомнив ранее рассмотренные паттерны групп контейнеров, здесь можно разглядеть реализацию паттерна Ambassador. Контейнер обобщенной очереди задач является главным контейнером приложения, а специфичный для приложения контейнер-источник является послом, транслирующим запросы контейнера-диспетчера очереди конкретным исполнителям задач. Данная группа контейнеров изображена на рис. 10.2.

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

URL /items/ возвращает список всех задач:

URL /items/ предоставляет подробную информацию о конкретной задаче:

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

Из этого API мы получаем сведения о конкретной задаче, а затем передаем значение поля item.data интерфейса контейнера-исполнителя.

Интерфейс контейнера-исполнителя

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

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

Общая инфраструктура очередей задач

Что остается внедрить в повторно используемой реализации очереди, если реализации двух ранее описанных интерфейсов контейнеров у вас уже есть? Базовый алгоритм работы очереди задач довольно прост.

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

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

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

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

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

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

Практикум. Реализация генератора миниатюр видеофайлов

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

Для реализации миниатюр понадобится два контейнера. Первый — для источника задач. Проще всего будет размещать задачи на общем сетевом диске, подключенном, например, по NFS (Network File System, сетевая файловая система). Источник задач получает список файлов в этом каталоге и передает их вызывающей стороне.

Приведу простую программу на NodeJS:

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

Можно создать контейнер, запускающий такую команду:

Команда извлекает один из каждых 100 кадров (параметр -frames:v 100) и сохраняет его в формате PNG (например, thumb1.jpg, thumb2.jpg и т. д.).

Подобного рода обработку можно реализовать на основе существующего Docker-образа ffmpeg. Популярностью пользуется образ jrottenberg/ffmpeg.

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

Динамическое масштабирование исполнителей

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

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

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

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

Наконец, рассмотрим систему, в которой поступает одно задание в минуту, а обработка задания занимает две минуты. Такая система будет постоянно терять производительность. Длина очереди задач будет расти вместе с задержкой между поступлением и обработкой задач (и степенью раздраженности пользователей).

За значениями этих двух показателей необходимо постоянно следить. Усреднив время между поступлением заданий за длительный период времени, например на основе количества заданий за сутки, получим оценку межзадачного интервала. Необходимо также следить за средней продолжительностью обработки задания (без учета времени, проведенного им в очереди). В стабильной очереди задач среднее время обработки задачи должно быть меньше межзадачного интервала. Чтобы обеспечить выполнение такого условия, необходимо динамически подстраивать количество доступных очереди вычислительных ресурсов. Если задания обрабатываются параллельно, то время обработки следует разделить на количество параллельно обрабатываемых заданий. К примеру, если одно задание обрабатывается минуту, но параллельно обрабатываются четыре задачи, то эффективное время обработки одной задачи составляет 15 секунд, а значит, межзадачный интервал должен составлять не менее 16 секунд.

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

Паттерн Multi-Worker

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

Возможности такого рода повторного использования можно добиться путем применения паттерна Multi-Worker, который фактически является частным случаем паттерна Adapter, описанного в начале книги. Паттерн Multi-Worker преобразует набор контейнеров в один общий контейнер с программным интерфейсом контейнера-исполнителя. Этот общий контейнер делегирует обработку нескольким отдельным, повторно используемым контейнерам. Данный процесс схематически изображен на рис. 10.4.

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

Очередь – это структура данных , представляющая собой последовательность элементов, образованная в порядке их поступления. Каждый новый элемент размещается в конце очереди; элемент, стоящий в начале очереди, выбирается из нее первым. В очереди используется принцип доступа к элементам FIFO ( First Input – First Output, "первый пришёл – первый вышел") ( рис. 30.2). В очереди доступны два элемента (две позиции): начало очереди и конец очереди. Поместить элемент можно только в конец очереди, а взять элемент только из ее начала. Примером может служить обыкновенная очередь в магазине.

Описание очереди выглядит следующим образом:

где информационное поле – это поле любого, ранее объявленного или стандартного, типа;

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

1 способ: адресное поле ссылается на объявляемую структуру.

2 способ: адресное поле ссылается на ранее объявленную структуру.

Очередь как динамическую структуру данных легко организовать на основе линейного списка. Поскольку работа идет с обоими концами очереди, то предпочтительно будет использовать линейный двунаправленный список . Хотя для работы с таким списком достаточно иметь один указатель на любой элемент списка , здесь целесообразно хранить два указателя – один на начало списка (откуда извлекаем элементы) и один на конец списка (куда добавляем элементы). Если очередь пуста, то списка не существует, и указатели принимают значение NULL .

Описание элементов очереди аналогично описанию элементов линейного двунаправленного списка. Поэтому объявим очередь через объявление линейного двунаправленного списка:

Основные операции , производимые с очередью:

создание очереди;
печать (просмотр) очереди;
добавление элемента в конец очереди;
извлечение элемента из начала очереди;
проверка пустоты очереди;
очистка очереди.

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

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

Ключевые термины

FIFO (First Input – First Output) – это метод доступа к элементам очереди по принципу , "первый пришёл – первый вышел".

LIFO (Last Input – First Output) – это метод доступа к элементам стека по принципу "последним пришел – первым вышел"

Вершина стека – это доступный элемент стека.

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

Начало очереди – это позиция доступного для извлечения из очереди элемента.

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

Стек – это структура данных , в которой новый элемент всегда записывается в ее начало (вершину) и очередной читаемый элемент также всегда выбирается из ее начала.

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

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

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

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

Система электронной очереди при грамотном внедрении и использовании помогает кредитной организации решить следующие задачи:

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

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

Составные элементы системы управления очередью

Итак, из каких элементов состоит СУО? Выделяются следующие компоненты решений.

Терминал для выбора услуг - имеет сенсорный экран и осуществляет печать талонов с номером очереди (встроенный диспенсер). Для печати талонов электронной очереди в терминалах используются термопринтеры. Такой терминал обычно расположен у входа во внутреннее структурное подразделение (далее - ВСП).
Центральное информационное табло системы - предназначено для отображения движения очереди. На табло вместе с информацией о движении очереди могут отображаться рекламный ролик, бегущая строка и т.д. Табло размещают в зоне ожидания таким образом, чтобы транслируемая информация была отчетливо видна с любого места ожидания.
Индивидуальные табло системы - монтируются непосредственно над рабочим местом и служат для дублирования номера очереди вызываемого клиента .

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

Основные производители систем управления очередью

В настоящее время на рынке СУО работает целый ряд компаний, предлагающих программные и технические решения для управления очередью. Однако наиболее востребованными оказались решения СУО, получившие право на внедрение в крупнейших кредитных организациях России (топ-40), трех компаний-производителей: Qmatic, "Дамаск" и "ДИИП 2000".

Базовые принципы работы системы управления очередью во внутреннем структурном подразделении

Рассмотрим алгоритм работы СУО.

Настройка и подключение сотрудников к системе управления очередью

Руководитель ВСП, его заместитель (при наличии) и сотрудник, исполняющий обязанности администратора , также должны быть подключены к СУО. Данной категории присваивается статус "администратор".

Под администратором понимается консультант/сотрудник, который встречает/провожает клиентов. Рабочее место администратора, как правило, находится прямо у входа в ВСП.

Сотрудник ВСП, занимающийся непосредственным обслуживанием клиентов, должен всегда четко соблюдать правила работы с СУО. Особенно это касается включения, выключения и постановки на паузу. Что касается включения пульта СУО, то его следует включать за 2 - 3 минуты до начала обслуживания клиентов, а не тогда, когда клиенты уже входят в операционный зал .

К примеру, если ВСП открывается в 9:00, то СУО следует включать уже в 8:57 или 8:58.

По окончании смены сотрудник должен выключать пульт СУО - строго после завершения обслуживания последнего клиента. Важно помнить, что не выключенные вовремя пульты искажают статистику/отчетность по времени ожидания и обслуживания клиента.

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

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

Фальсификация данных, получаемых из отчетности

Известно, что многие кредитные организации устанавливают предельное время ожидания клиента в очереди, а также время обслуживания клиента, например 10 минут, 15 минут и т.д. . Предельные значения, устанавливаемые для ВСП и связанные, например, со временем обслуживания клиента, после установки СУО могут быть сильно "ужаты" (опять же ради достижения благой цели - сокращения очередей). При этом сотрудники, которые не успевают/не могут обслужить клиента в обозначенное время, будут прилагать определенные усилия, чтобы уложиться в предложенный норматив времени .

Ряд кредитных организаций ставят для себя задачу, что 90% клиентов не должны ожидать обслуживания более 10 минут.
Сотрудники будут стремиться уложиться в установленный норматив по причине того, что в "мотивационной формуле" несоблюдение данного критерия повлечет за собой снижение премиального вознаграждения.

Здесь возникает новая проблема - fraud (англ. "мошенничество").

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

А теперь представьте, что будет, если подобные манипуляции начнутся повсеместно. Какие данные в итоге получит сотрудник, который работает с аналитическим материалом из СУО? Все операционисты банка укладываются в отведенное на обслуживание клиентов время? Да, отлично. Но почему стало расти количество жалоб на проблемы с очередью?

В целях сокращения/предотвращения случаев фальсификации данных СУО и снижения мошенничества могут проводиться следующие мероприятия.

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

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

Третий пример манипуляции с СУО: для выравнивания среднедневных данных по обслуживанию клиентов и в ряде случаев - для повышения значений производительности труда сотрудники в конце операционного дня, по окончании обслуживания клиентов, могут осуществлять множественную печать талонов СУО, которые фиксируются и влияют на результат. Итог - дополнительное количество вызванных для обслуживания клиентов за 1 - 2 минуты . Понимая, что операционисты могут быть наказаны за подобные манипуляции, некоторые обращаются с просьбой к обслуживающему персоналу, например к уборщицам, в чьи обязанности входит в том числе ежедневная протирка сенсорного экрана после окончания обслуживания клиентов. В результате помимо очистки экрана сотрудник клининговой фирмы осуществляет множественную печать талонов.

В среднем выбор операции в меню СУО, печать талона и его выход через диспенсер занимают около трех секунд. Таким образом, за одну минуту возможна генерация 15 - 20 талонов, имитирующая последующее обслуживание такого же количества клиентов. Данная манипуляция довольно легко проверяется в случае сопоставления данных СУО (время печати талонов) и времени проведения операций в АБС банка.

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

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

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

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

Сокращение очередей в операционном зале

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

правильно настроить саму СУО, разделив услуги, оказываемые ВСП, на "длинные" и "короткие". Под "короткими" операциями подразумеваются операции, при которых время обслуживания клиентов составляет 5 - 10 минут . "Длинные" операции занимают более 10 минут;
правильно организовать перерывы для операционистов. Руководству ВСП следует организовать обеденные перерывы таким образом, чтобы исключить закрытие работающих окон в час пик;
разрешить освобождающимся операционистам "перехватывать" очередь - это позволит обслуживать большее количество клиентов с "короткими" операциями и сократить время ожидания в очереди;
составить адекватный график работы. Для исключения большого наплыва клиентов, особенно в момент открытия, имеет смысл выводить больше сотрудников в такие периоды. В результате доступность услуг может повыситься;
организовать работу консультантов на входе в операционный зал. Важно, чтобы сотрудники, которые стоят на входе и выясняют потребности клиентов, правильно перераспределяли клиентские потоки. Надо иметь в виду, что ряд категорий клиентов, особенно лица пожилого возраста, могут выбрать в меню СУО не тот пункт, в результате итоговое время обслуживания будет значительно выше прогнозных значений.

Выводы

Внедрение СУО позволяет кредитной организации решить сразу несколько задач.

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

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

ОАО "Сбербанк России"

Мы используем файлы Cookie. Просматривая сайт, Вы принимаете Пользовательское соглашение и Политику конфиденциальности. --> Мы используем файлы Cookie. Просматривая сайт, Вы принимаете Пользовательское соглашение и Политику конфиденциальности.

Читайте также: