Построение имитационной модели системы дистанционного банковского обслуживания Текст научной статьи по специальности «Компьютерные и информационные науки»

УДК 336.71:004.67

ПОСТРОЕНИЕ ИМИТАЦИОННОИ МОДЕЛИ СИСТЕМЫ ДИСТАНЦИОННОГО БАНКОВСКОГО ОБСЛУЖИВАНИЯ

© 2010 г. А.А. Никитенко, Д.В. Гринченков

Южно-Российский государственный South-Russian State

технический университет Technical University

(Новочеркасский политехнический институт) (Novocherkassk Polytechnic Institute)

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

Ключевые слова: дистанционное банковское обслуживание; имитационная система.

This article describes one approach to the formation of possible configurations of remote banking service (DBS). Configuration is a set of software and hardware that make up the payment system. Today the problem of choosing a suitable configuration is solved in most cases by subjective expert assessments of IT-professionals outside organizations. The article proposes an approach to formalize the process of selecting the best configuration based on the mathematical apparatus of queuing systems and expertise.

Keywords: remote banking; simulation system.

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

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

Целью моделирования является анализ возможных конфигураций систем дистанционного банковского обслуживания (ДБО), оценка эффективности обслуживания заявок и выбор наиболее подходящей схемы для той или иной коммерческой организации. Под конфигурацией будем понимать набор программно-аппаратных средств, из которых состоит платежная система. До настоящего времени проблему выбора подходящей конфигурации решали путем субъективных экспертных оценок группы /Г-специалистов сторонних организаций. Основной задачей научного исследования является формализация процесса выбора наилучшей конфигурации путем использования математического аппарата систем массового обслуживания и экспертных оценок.

Рассмотрим обобщенную схему платежной банковской системы (рис. 1).

БАНК

Сервер БД Сервер приложений

1=1 1=1 =1 =1

п 1- -1 п

Организация-поставщик услуг

АРМ кассира-операциониста

Платежный терминал

Процессинговый центр

Клиенты

Рис. 1. Обобщенная схема системы дистанционного банковского обслуживания (ДБО)

Обслуживание заявки от клиента делится за следующие этапы:

- этап 1: клиент, желающий произвести оплату какой-либо услуги, вносит свои идентификационные данные;

- этапы 2 и 3: персональный компьютер или любое другое программно-аппаратное устройство (POS-терминал, кассовый аппарат) пункта приема платежей по защищенному Интернет-протоколу SSL пересылает запрос на проверку идентификационных данных;

- этап 4: одновременно с третьим этапом посылается запрос на сервер банка о наличии либо недостатке средств на счете клиента (либо дилера);

- этап 5: организация-поставщик услуг проверяет данные клиента по своей базе и дает разрешение на оплату услуги;

- этап 6: если на расчетном счете достаточно средств для проведения платежа, в процессинг отправляется разрешение на выполнение операции. В противном случае отправляется отказт от операции с указанием причины;

- этап 7: процессинговый центр (ПЦ) отправляет разрешение выполнить платеж на рабочее место операциониста в пункт приема платежа дилера;

- этап 8: операционист пункта приема платежей принимает от абонента денежные средства в размере суммы платежа и подтверждает платеж, после чего он отправляется в процессинговый центр;

- этап 9: процессинг отправляет на сервер расчетного банка команду (электронный платежный документ) на списание внесенной в кассу суммы со счета дилера;

- этап 10: в процессинговый центр отправляется подтверждение о снятии денежной суммы;

- этап 11: подтверждение о получении средств приходит на пункт приема платежа дилера;

- этап 12: абонент получает подтверждение о приеме платежа в виде фискального чека или специального сообщения в зависимости от типа пункта обслуживания;

- этап 13: денежные средства со счета компании-дилера в расчетном банке переводятся на счет оператора.

При моделировании работы системы ее можно рассмотреть как «черный ящик», на вход которого подаются исходные данные, а на выходе снимаются результаты работы. Q-схема такой системы массового обслуживания (СМО) выглядит так (рис. 2):

Ожидание О^уживдние

Приход заявок

Накопитель (очередь)

Уход заявок

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

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

Графическое представление СМО с неоднородной нагрузкой представлено на рис. 3.

На рисунке Хь Х2,..., Хн - интенсивности поступления заявок; vab va2,..., vaH - коэффициент вариации (КВ) интервалов поступления, Н - количество классов заявок; ц2,..., цн - интенсивность обслуживания каждого класса заявок.

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

1) Л= k - интенсивность объединенного по-

k=1

тока (простейшего);

н (X ]

2) B = £ \ — I bk - усредненное время обслужи-

k=1

Л

к

Обслуживающий прибор Рис. 2. Общая схема СМО

вания заявок объединенного потока, где — - доля

_Л

заявок класса к в суммарном потоке (к = 1,Н);

^1, V„

о

H1, H2, ..., Hh (или b1, b2, ..., bH), Vi, V2, ... , Vh

^1, Va

или

и-1, H2, ..., Hh

(или b1, b2, ..., bH), V1, V2, ... , Vh

Рис. 3. СМО с неоднородной нагрузкой входного потока заявок

• • •

• • •

VaH

Vан

3) AB2(1 + v2) = ^Хkbk2(1 + v2) - из этого выра-

k=1

жения определяется КВ V длительности обслуживания заявок объединенного потока.

После преобразований исходная модель примет вид рис. 4.

A

О

B, v

Рис. 4. Преобразованная модель СМО: Л - интенсивность потока заявок; В — пропускная способность канала обслуживания; V - КВ длительности обслуживания

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

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

Рг{N(0 = к} = *, * ^ 0, - = 0,1, 2,... .

Для определения необходимых параметров канала обслуживания СМО следует заглянуть внутрь «черного ящика» и проанализировать его составные части, каждая из которых является отдельным блоком обслуживания со своими характеристиками.

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

Первая СМО - проверка реквизитов платежа показана на рис. 5.

Результат обработки данных плательщика

Рис. 5. Q-схема проверки реквизитов платежа

Опишем предназначение каждого элемента:

1) очередь поступивших от клиентов заявок на проверку возможности проведения платежей. Здесь имеют место две проверки: первая - наличие достаточного количества средств на лицевом банковском счете дилера, вторая - проверка правильности заполнения информации о плательщике (эта проверка осуществляется по БД организации-поставщика услуг при наличии online-канала с процессингом; если такого канала нет, то проверка делается в самом процес-синге);

2) ПЦ - процессинговый центр, отвечающий за обработку поступающих от клиентов заявок и перенаправление их в следующие блоки обработки. Также процессинг принимает ответы от других блоков и передает их клиентам;

3) очередь ответов от блоков обработки, отличных от ПЦ, и готовых к обработке для передачи клиенту;

4) СУБД - банковский сервер БД, куда поступает запрос на проверку наличия средств на счете дилера для совершения платежей.

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

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

По данным компании Интерфейс, более 80 % рынка СУБД в течение долгих лет контролируется тремя гигантами - IBM, Oracle и Microsoft. Причем, существенное перераспределение долей рынка в обозримом будущем не предвидится [1].

Проведя анализ крупнейших российских автоматизированных банковских систем (АБС), можно убедиться, что большинство из них используют СУБД Oracle, это: «Банк XXI век» компании Инверсия, «RS-Bank» фирмы R-Style SoftLab, «ЦФТ-Банк» компании Центр Финансовых Технологий, АБС таких фирм, как Диасофт, РФК-Финансовые Коммуникации, BSS и др. [2 - 7].

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

Рассмотрим общую схему потоков информации СУБД Oracle [8] (рис. 6).

Видно, что очередь запросов к БД и очередь ответов находятся непосредственно в области SGA (структура памяти, системная глобальная область System Global Area), поэтому правильно выбранный размер этой области также влияет на производительность

платежной системы (ПС). Данный параметр настраивается в конфигурационном файле инстанса БД тИ-SID.orG.

Рис. 6. Схема потоков информации СУБД Oracle

Вторая СМО - собственно проведение платежа системой - имеет приведенный на рис. 7 вид.

Результат процедуры регистрации платежа

Рис. 7. 0-схема регистрации платежа

На рисунке представлено следующее:

1) очередь заявок на регистрацию платежа в системе (уже после проверки реквизитов платежа);

2) ПЦ, имеющий то же предназначение, что и в первой СМО;

3) очередь ответов от банковского сервера с положительными или отрицательными результатами совершения операции по счету дилера;

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

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

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

- блокировка остатка на счете дилера (а значит и самого счета);

- вставка новой записи в таблицу бухгалтерских документов и ее дальнейшее изменение;

- обновление дополнительной информации о плательщике (показания счетчиков, остаток долга, пеня и др.).

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

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

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

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

Следующим этапом моделирования является выбор инструментального средства для имитации работы спроектированной СМО. Одним из таких достаточно распространенных средств является GPSS/PS -язык программирования, используемый для имитационного моделирования различных систем. Исходными данными при этом будут входной поток заявок (стационарный или нестационарный) и пропускная способность каждого канала обслуживания. Перечисленные параметры были получены опытным путем при работе систем компании Инверсия «Интернет Банк-

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

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

Литература

1. Статьи компании Интерфейс. URL: http://www.interface.ru

2. Информация компании ЗАО «Инверсия». URL: http: //www. inver- sion.ru

3. Информация фирмы R-Style SoftLab. URL: www.r-style.ru

4. Информация компании «Центр Финансовых Технологий». URL: http://www.cft.ru

5. Информация фирмы «Диасофт». URL: http://diasoft.ru

6. Информация компании РФК-Финансовые Коммуникации. URL: http://www.rfc.ru

7. Информация компании BSS. URL: http://www.bssys.com

8. Кайт Т. Oracle для профессионалов: кн. 1, М., СПб., Киев, 2005.

Поступила в редакцию 22 сентября 2010 г.

Никитенко Антон Александрович - аспирант, Южно-Российский государственный технический университет (Новочеркасский политехнический институт). Тел. 8-908-505-23-03. E-mail: Nikan_mail@inbox.ru

Гринченков Дмитрий Валерьевич - канд. техн. наук, доцент, профессор, кафедра «Программное обеспечение вычислительной техники», Южно-Российский государственный технический университет (Новочеркасский политехнический институт).

Nikitenko Anton Aleksandrovich - post-graduate student, department «Software of Computing», South-Russian State Technical University (Novocherkassk Polytechnic Institute). Ph. 8-908-505-23-03. E-mail: Nikan_mail@inbox.ru

Grinchenkov Dmitriy Valerievich - Candidate of Technical Scince, assitant professor, department «Software of Computing», South-Russian State Technical University (Novocherkassk Polytechnic Institute).