17 августа 2012, 16:17
Количество просмотров 884

Софт для АТМ: время перемен

Максим Рожков, руководитель службы разработки ПО компании «ДОРС» В последнее время значительно увеличился масштаб и накал...
Софт для АТМ: время перемен

Максим Рожков, руководитель службы разработки ПО компании «ДОРС»
В последнее время значительно увеличился масштаб и накал дискуссий, связанных с особенностями программного обеспечения для устройств банковского самообслуживания и, в частности, для банкоматов. Сейчас свое мнение о софте для ATM высказывают буквально все, начиная с ветеранов bankomatchik.ru, блогеров LiveJournal.ru и заканчивая «Цитатником Рунета» bash.org.ru. Подобные обсуждения иногда излишне эмоциональны, а сделанные заключения далеко не всегда подкреплены фактами, но высокая активность вовлеченных в процесс специалистов позволяет утверждать, что тема адекватности возможностей банкоматов реалиям современного общества крайне высока. Попробуем разобраться, связаны ли эти обсуждения с реальным появлением новых требований к функционалу устройств самообслуживания, и если да, то каких именно.


Рождение банкоматов
Согласно общепринятой версии, идея банкомата родилась у англичанина Джона Шепарда-Бэррона. Однажды, не успев получить наличные до закрытия банка, он пришел к осознанию необходимости нового банковского сервиса: «Я вдруг понял, что есть возможность получить свои деньги в любом месте в Великобритании или во всем мире. Я подумал об автомате, который продает шоколадки, и решил заменить шоколадки деньгами». Первый банкомат был установлен в отделении «Барклайз» на улице Энфилд в северном Лондоне 27 июня 1967 года. Сейчас в мире действуют почти 2 миллиона банкоматов, ATM оборудована даже станция «МакМердо» в Антарктиде.

Софт для АТМ: время перемен - рис.1

Появление Direct Connect-протоколов Подавляющее большинство банкоматов работают по одному из управляющих Direct Connect-протоколов, концептуально очень схожих, но имеющих ряд технических нюансов. Управляющий протокол NDC (NCR Direct Connect Protocol) обязан своим рождением корпорации National Cash Register Company (NCR). Корпорация NCR являлась производителем кассовой техники и выпустила свой первый банкомат в конце 70-х годов двадцатого века, заключив договоры с National Westminster Bank и Barclays Bank. По-настоящему массовые поставки банкоматов начались в 1983 году, после выпуска Model 5070. Протокол NDC, в том виде, в котором мы его знаем сейчас, начал разрабатываться в конце 1980-х годов. Сейчас еще достаточно легко вспомнить уровень развития технологий того времени и понять причины, по которым NDC получился таким, каким мы его знаем: 1982 год – появился стандарт передачи данных по аналоговым каналам связи V.32 (19,2 Кб/s); 1985 – представлен процессор Intel 80386; 1990 – появился стандарт видеорежима VGA с разрешением 640х 480 точек; 1994 – представлен 80486 процессор с частотой процессора 33 МГц и внутренним утроением частоты; 1994 – ратификация V.34 (33,6 Кб/s). Можно смело утверждать, что в конце восьмидесятых вычислительный ресурс был ограниченным, каналы связи – мед- ленными, а разрешение экрана – низким. Следует учесть, что разработка банкомата тогда занимала несколько лет и его «начинка» отставала от headliner-ов как минимум на 1–2 года. Легко понять, какие именно ограничения стояли перед разработчиками NDC: банкомат не должен выполнять операций с высокой вычислительной нагрузкой, в том числе не нагружать пользовательский интерфейс и не выполнять сложных криптоопераций. Также было необходимо минимизировать количество и размер сообщений, передаваемых от банкомата к управляющей системе. Кроме этого, сообщения должны были быть человеко-читаемыми. Также необходимо было учесть ограниченный пользовательский опыт держателей банковских карт, многие из которых тогда еще не были знакомы с такими концепциями, как «фокус ввода», «строка редактирования с горизонтальным скроллированием», и т. д. Если добавить к этому ключевое бизнес-решение, состоящее в отделении бизнес-правил (на управляющем компьютере) от модуля управления аппаратными узлами (ATM), то становится достаточно легко воспроизвести видение технического решения того времени. Его ключевыми особенностями являются: Минималистичный пользовательский интерфейс, в котором для взаимодействия с клиентом используется клавиатура, подобная простейшему калькулятору, и дополнительные четыре или восемь функциональных кнопок. Вывод сообщений осуществляется крупным шрифтом в символьной матрице размером 32×16 или 40×20 позиций. Банкомат должен работать автономно до момента принятия критичных технических и финансовых решений: все необходимые для автономной работы инструкции банкомат получает при запуске. У банкомата отсутствует «воля к принятию решений» – он должен безоговорочно выполнять команды управляющей системы. В случае возникновения проблемных ситуаций ПО банкомата должно сразу же оповестить управляющую систему. Банкомат не принимает решение о финансовых операциях (выдача наличных) – он использует «легковесные» сообщения, посредством которых запрашивает право на выполнение операции, а решение принимает управляющая система. Поскольку криптооперации выполнялись отдельным устройством (криптомодулем), ограниченным в вычислительных ресурсах, шифруемые последовательности должны были быть очень короткими (десятки байт). Кроме этого, ограничения касались и используемых крипто-алгоритмов – приходилось использовать симметричные крипто-алгоритмы (DES/3DES), что позволяло минимизировать сетевой график.

Софт для АТМ: время перемен - рис.2

20 лет, которые изменили мир Очевидно, что за прошедшие 20 лет прогресс достиг невиданных высот. Применительно к устройствам самообслуживания можно говорить о том, что существовавшие ранее ограничения исчезли. Вычислительной мощности банкомата хватает для распознавания образов, управления искусственными спутниками Земли и даже для компьютерных игр. Стоимость каналов связи уже практически не зависит от объема информации, хотя в определенных ситуациях необходимости оптимизации сетевого трафика избежать не удается. Накопители информации способны хранить видео, трансляция которого потребует 100 и более часов. Еще одно кардинальное изменение произошло в пользовательском опыте. В «Аngry Birds» на любимом смартфоне сейчас не играют только ортодоксальные поклонники игровых приставок «PlayStation 3» и «XBOX 360». Такие парадигмы пользовательского интерфейса, как Multi-touch, композитные приложения и «тело как контроллер», вошли в жизнь современного человека, и об- ратного хода уже быть не может. Очевидным представляется, что не осталось никаких причин придерживаться устаревших подходов и технологий, кроме одной, выраженной принципом: «Работает? Тогда отойди и не трогай». И даже этот самый последний принцип дрожит перед натиском новых бизнес-возможностей, открывающихся перед банковскими устройствами самообслуживания (УС).

Софт для АТМ: время перемен - рис.3

Софт для АТМ: новое поколение На этом фоне логичным представляется вопрос: а какие требования к УС и соответствующему ПО актуальны сейчас? Давайте попробуем формализовать эти требования, сделав особый акцент на практической пользе реализующего его функционала. Ничего лишнего: аппаратным узлом, кандидатом № 1 на устранение из УС, является старичок «аппаратный журнальный принтер». Основная цель, для которой используется журнальный принтер, – хранение информации, необходимой для разбора апелляций. Журнальную ленту сложно разорвать таким образом, чтобы никто ничего не заметил, но работать с ней неудобно, хранить сложно, менять дорого. Гораздо лучшей альтернативой представляется «электронный журнал», в котором каждая запись подписана ЭЦП циклически, с тем чтобы так же, как и с бумагой, было невозможно незаметно удалить компромат из середины ленты. С электронным журналом легко работать – его можно забирать удаленно, индексировать, просматривать наиболее удобными инструментами. Конечно же, крайне важной остается тема интеграции терминального ПО с сервисными службами банка, в зоне ответственности которых находятся вопросы, связанные с восстановлением работоспособности УС, инкассацией и т. д. Средства мониторинга, которые могут быть реализованы в рамках Direct Connect протоколов, все же носят ограниченный характер, и для преодоления существующих ограничений более разумно использовать специализированную подсистему финансового и технического мониторинга. Отдельный от DC- протоколов агент мониторинга может существенно повлиять на дешевизну сбора информации и ее полноту, в частности, за cчет точной настройки правил доставки событий серверу мониторинга (приоритеты, альтернативные каналы, пакетирование и т. д.). В отличие от 1990-х годов современные устройства банковского самообслуживания являются исключительно инновационными. Как пример, в нынешнем 2011 году актуальными темами являются: NFC, Pay- Pass, PayWave, Contactless EMV, УЭК, транспортные и локальные социальные карты, считыватели 2D-штрих-кодов, биометрия, coin dispensing, cash recycling. Большинство из подобных технологий разработчикам приходится встраивать в прикладное ПО УС в авральном режиме, что существенно повышает вероятность возникновения программных ошибок. Таким образом, можно утверждать, что современное ПО должно быть адаптировано к авральному режиму внесения изменений в кодовую базу с целью добавления новых функциональных возможностей. Одним из способов подобной адаптации является встраивание в ПО «черных ящиков», накапливающих информацию о ключевых решениях, принимаемых прикладным ПО, а также об отклонениях от основного потока выполнения. Основываясь на эмпирических оценках, такого рода события могут происходить 50–100 раз каждую секунду. Подобная информация может быть очень полезной разработчикам при анализе причин различного рода сбоев. Современное ПО УС должно не только уметь надежно накапливать эти данные, в минимальной степени расходуя доступный вычислительный ресурс, но и хранить эти данные в хорошо структурированном виде. Для разбора сбойных ситуаций представляется идеальным использование специального инструментария, допускающего выборку данных с использованием SQL-подобного языка с вспомогательным графическим интерфейсом, упрощающим формирование запросов. Еще одним трендом, который было бы совершенно ошибочно игнорировать, является появление композитных приложений, различные части которых работают по разным протоколам, с использованием разных технологий. Жизненным примером подобного совмещения может быть предоставление на УС доступа как к осуществлению коммунальных платежей, так и к получению госуслуг. Довольно часто «платежи» и «социалка» – разработки разных коллективов, которые необходимо бесшовно соединить. Тема объединения разных пользовательских приложений на одном УС связана с целым рядом технических проблем, в частности, с ведением статистики по на- личным. Решением может быть выделение уровня технических сервисов (ядра), которым на паритетной основе будут пользоваться все используемые на УС приложения. При этом, несмотря на наличие различных сценариев обслуживания плательщиков, чек закрытия операционного цикла содержит корректную консолидированную информацию и даже, возможно, в разрезе операций. Говоря про принципы построения пользовательских интерфейсов, необходимо отметить доминирование web-под- хода, который очень быстро вытесняет DC-ориентированные пользовательские интерфейсы. Небанковским платежным системам удалось наглядно доказать, что графический дизайн имеет значение, и игнорировать web-формы уже нельзя. Кроме красоты, web-формы при- внесли в пользовательский интерфейс УС динамическое поведение, позволяющее не допустить клиентом выполнения неверных действий, таких как ввод за- ведомо ошибочных значений, нарушения формата вводимых данных и т. д. Подобные ошибки влекут за собой не толь- ко издержки, связанные с обработкой рекламаций клиентов, но и увеличение времени обслуживания клиента. Таким образом, можно говорить о том, что web- интерфейсы позволяют снижать издержки банка, увеличивают оборот и привлекают новых потребителей. Хорошим примером увеличения скорости обслуживания клиентов является платежное приложение УС банка УРАЛСИБ. Главное меню этого приложения содержит как классификатор поставщиков ус- луг, так и строку поиска, в которой можно ввести известные реквизиты поставщика, например, название организации или ИНН. Так как найти поставщика ус- луг можно разными способами и сделать это, в общем случае, удается быстро, количество т. н. «незавершенных операций» в банке существенно меньше, чем у конкурентов, при том что затрачиваемое плательщиком время на оформление платежа минимально. Теме MultiVendor Solutions исполнилось уже более 20 лет, и ее сложно обозначить как новую, тем не менее важной кажется поддержка свежих спецификаций CEN/XFS. Новые версии спецификаций не только добавляют новые классы устройств, но и позволяют унифицировать работу с существенно более широким на- бором оборудования, предлагая использовать опыт других разработчиков в тех областях, где стоимость получения опыта еще очень высока. Как пример, можно отметить гораздо более проработанные механизмы сбора статистики оборота на- личных в CEN/XFS 3.10, чем в предыдущих версиях спецификации. Последней в данном списке, но не последней по значению является реализация в ПО УС комплексной модели информационной безопасности. Здесь необходимо отметить как минимум работу ПО из-под учетной записи с ограниченными правами и ролевую модель режима оператора. Несомненно, нельзя пренебрегать выполнением требований PCI DSS. Также важным является внедрение в коллективе разработчиков ПО специальных процессов, направленных на постоянный рост степени защищенности ПО от действий злоумышленников, хорошим примером которого является Microsoft Security Development Lifecycle.

Вместе против общего врага В современном мире все сложнее конкурировать, используя закрытые модели. Более того, мы все чаще сталкиваемся с примерами эффективного следования модели «конкуренция/сотрудничество», в соответствии с которой разные компании могут конкурировать в одном сегменте рынка, но взаимовыгодно сотрудничать в другом. По сути, у всех разработчиков ПО для УС есть только один общий враг – высокая сложность задач, которые нам, разработчикам, приходится решать каждодневно. По этой причине кажется разумным и полезным вести открытую и откровенную дискуссию о лучших практиках и подходах, связанных с разработкой управляющего ПО банкоматов и информационно-платежных терминалов. Наступило время, когда нужно меньше думать об ограничениях «железа» и больше – о тех возможностях, которые стремятся получить люди, находящиеся перед экраном банкомата. Правильный шаг в этом направлении – полноценный набор высокоуровневых функций и хороший конструктор, позволяющий эффективно интегрировать их в банковскую инфраструктуру. Кажется логичным, что подготовка подобного базиса является одной из ключевых задач поставщиков устройств банковского самообслуживания. Именно по этой причине компания «ДОРС» работает над интеграционными платформами уже более десяти лет. Разделяя принцип «практика – критерий истины», мы приглашаем все заинтересованные стороны к практическому знакомству с ПроАТМ – программным продуктом, отражающим видение ГК ДОРС того, каким должен быть современный софт для ATM.

Рубрика:
{}
Теги:
#

PLUSworld в соцсетях:
telegram
vk
dzen
youtube