АРХИТЕКТУРА СТАНДАРТА CEN/XFS НА ОСНОВЕ ОПЕРАЦИОННОЙ СИСТЕМЫ LINUX И СПОСОБ ЕЕ РЕАЛИЗАЦИИ Российский патент 2018 года по МПК G06F9/44 

ПЕРЕКРЕСТНЫЕ ССЫЛКИ НА РОДСТВЕННЫЕ ЗАЯВКИ

[001] Данная заявка притязает на приоритет патентной заявки Китая №201410728132.6, «LINUX SYSTEM-BASED CEN/XFS STANDARD ARCHITECTURE AND IMPLEMENTATION METHOD», поданной в Государственное ведомство интеллектуальной собственности Китая 3 декабря 2014 года, содержание которой целиком включено сюда по ссылке.

ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ

[002] Настоящее изобретение относится к технической сфере устройств финансового самообслуживания и, в частности, касается архитектуры стандарта CEN/XFS на основе операционной системы LINUX и способа реализации для стандарта CEN/XFS на основе операционной системы LINUX.

УРОВЕНЬ ТЕХНИКИ

[003] Большинство вариантов программного обеспечения в банкоматах (АТМ) в настоящее время работает в системе Windows, и только несколько вариантов программного обеспечения банкоматов работает в системе LINUX. Организация финансовых услуг 11 февраля 1996 года выпустила стандарт WOSA/XFS (версия 2.0) и передала этот стандарт в Европейский комитет по стандартизации (CEN) 11 мая 1998 года в Брюсселе (Бельгия). Shenzhen Zuin стала базовым элементом указанной организации в качестве первой корпорации Китая. Согласно последним данным рабочая группа WOSA/XFS Комитета CEN опубликовала версию 3.0 указанного стандарта. Протокол WOSA/XFS также называют Протоколом CEN/XFS. Архитектура открытой системы для Windows (сокращенно WOSA) представляет собой архитектуру программного обеспечения, предложенную Microsoft Corporation на основе операционной системы Windows, а WOSA/XFS (расширения архитектуры открытой системы для Windows для финансовых услуг) представляют собой расширения для финансовых услуг на основе WOSA. Архитектура WOSA/XFS предложена Microsoft Corporation для программного обеспечения индустрии финансовых услуг, где в архитектуре программного обеспечения WOSA выполнены некоторые модификации применительно к глобальной индустрии финансовых услуг.

[004] Многие эксперты годами предупреждали, что операционная система Windows недостаточно надежна для выполнения банковских услуг, например, из-за навязывания автоматических модификаций и обновлений без запросов на них, и уязвима в отношении возможности дистанционного мониторинга в любое время и даже кражи информации. Однако в настоящее время отсутствуют программы или программное обеспечение, реализующие Протокол CEN/XFS в системе LINUX. Таким образом, имеется насущная необходимость безотлагательной разработки банкомата на основе операционной системы LINUX. Вдобавок, поскольку система LINUX нашла свое применение в большинстве областей, она развивается также как система Windows. Главным условием для развития прикладного программного обеспечения в банкомате на основе системы LINUX является реализация Протокола CEN/XFS в системе LINUX. Таким образом, неотложной проблемой, подлежащей решению специалистами в данной области техники, является отсутствие стандарта CEN/XFS системы LINUX в известной на сегодняшний день технологии.

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

[005] Согласно вариантам осуществления настоящего изобретения, предложены архитектура стандарта CEN/XFS на основе операционной системы LINUX и способ реализации для стандарта CEN/XFS на основе операционной системы LINUX для решения технической проблемы, заключающейся в отсутствии в обычной технологии реализации стандарта CEN/XFS в системе LINUX.

[006] Согласно варианту осуществления настоящего изобретения, предложена архитектура стандарта CEN/XFS на основе операционной системы LINUX, которая применима к устройству финансового самообслуживания, в котором принят стандарт CEN/XFS. Система устройства финансового самообслуживания включает в себя прикладной программный уровень, уровень управления XFS, уровень SP и уровень драйверов устройств. В этой архитектуре уровень управления XFS разделен на: уровень специальных приложений, интерактивно связанный с прикладным программным уровнем через интерфейс API и используемый для вызова интерфейса SPI с уровнем SP и направления операционной команды прикладного программного уровня путем вызова интерфейсов уровня универсальных приложений и уровня системных служб; уровень универсальных приложений, используемый для приема сообщения о событии уровня SP и передачи сообщения о событии; и уровень системных служб, используемый для реализации системных служб управления журналами регистрации, управления реестрами, управления памятью, управления потоками и управления связью и обеспечения интерфейсов для уровня специальных приложений и уровня универсальных приложений.

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

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

[009] Как возможный вариант, системную службу управления реестрами используют для считывания информации о конфигурации путем считывания файла TingXml, а системную службу управления памятью используют для управления распределением памяти с последовательным доступом и распределения памяти с цепным доступом.

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

[0011] Согласно варианту осуществления настоящего изобретения, предложен способ реализации для стандарта CEN/XFS на основе операционной системы LINUX, причем этот способ реализации применим к архитектуре стандарта CEN/XFS на основе операционной системы LINUX по п. 1. Данный способ реализации включает в себя: S01, вызов уровнем специальных приложений интерфейса SPI с уровнем SP; S02, вызов уровнем специальных приложений управления журналами регистрации уровня системных служб для записи в журнале о вызове интерфейса SPI; S03, определение уровнем специальных приложений на основе вызванного имени функции прикладного программного уровня того, является ли вызванная команда синхронной командой или асинхронной командой,; переход к этапу S04 в случае синхронной команды и разблокировка и возврат уровнем специальных приложений в случае асинхронной команды; S04, прием уровнем универсальных приложений сообщения о событии, возвращенного с уровня SP; S05, возврат уровнем универсальных приложений сообщения о событии на уровень специальных приложений; S06 возврат уровнем специальных приложений указанного сообщения о событии на прикладной программный уровень через выходной параметр; и S07, разблокировка и возврат, выполняемые уровнем специальных приложений.

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

[0013] Как возможный вариант, в случае асинхронной команды на этапе S03 данный способ реализации кроме того включает в себя: S031, прием уровнем универсальных приложений указанного сообщения о событии, возвращенного с уровня SP; и S032, передачу уровнем универсальных приложений указанного сообщения о событии на прикладной программный уровень.

[0014] Как возможный вариант, этап S04 или S031 включает в себя: регистрацию уровнем универсальных приложений на уровне драйверов устройств при инициализации для регистрации указателя класса интерфейса модуля на уровне драйверов устройств, где класс интерфейса наследуется из виртуального базового класса интерфейса уровня драйверов устройств; вызов функции-члена виртуального базового класса интерфейса в том случае, когда сообщение о событии создано уровнем SP (300), где параметр функции-члена включает в себя структурные данные сообщения или структурные данные события; и перенос структурных данных сообщения или структурных данных события на уровень универсальных приложений через параметр функции-члена, где сообщение о событии, возвращенное с уровня SP, принимается уровнем универсальных приложений.

[0015] Как возможный вариант, этапы S04 и S05 включают в себя: инициализацию уровнем универсальных приложений обработчика сообщений при инициализации путем вызова управления связью уровня системных служб для создания очереди сообщений; предоставление уровнем универсальных приложений уровню SP идентификатора (ID) очереди сообщения через некоторый параметр в том случае, когда уровень специальных приложений вызывает интерфейс SPI с уровнем SP; передачу с помощью функции API очереди сообщений, встроенной в систему LINUX, структурных данных сообщения или структурных данных события на уровень специальных приложений в том случае, когда сообщение о событии создано уровнем SP, для получения уровнем специальных приложений упомянутого сообщения о событии. Этапы S031 и S032 включают в себя: инициализацию обработчика сообщений путем вызова управления связью уровня системных служб с помощью уровня универсальных приложений при инициализации для создания очереди сообщений; предоставление уровнем универсальных приложений уровню SP идентификатора (ID) очереди сообщения на основе некоторого параметра в том случае, когда уровень специальных приложений вызывает интерфейс SPI с уровнем SP; передачу с помощью функции API очереди сообщений, встроенной в систему LINUX, структурных данных сообщения или структурных данных события на прикладной программный уровень в том случае, когда сообщение о событии создано уровнем SP, для получения прикладным программным уровнем упомянутого сообщения о событии.

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

[0017] В вариантах осуществления настоящего изобретения архитектура стандарта CEN/XFS на основе операционной системы LINUX применима к устройству финансового самообслуживания, в котором принят стандарт CEN/XFS. Система устройства финансового самообслуживания включает в себя прикладной программный уровень, уровень управления XFS, уровень SP и уровень драйверов устройств. В этой архитектуре уровень управления XFS разделен на: уровень специальных приложений, интерактивно связанный с прикладным программным уровнем через интерфейс API, и используемый для вызова интерфейса SPI с уровнем SP и направления операционной команды прикладного программного уровня путем вызова интерфейсов уровня универсальных приложений и уровня системных служб; уровень универсальных приложений, используемый для приема сообщения о событии уровня SP и обеспечения уровня специальных приложений интерфейсом для приема сообщения о событии и передачи сообщения о событии; и уровень системных служб, используемый для реализации системных служб управления журналами регистрации, управления реестрами, управления памятью, управления потоками и управления связью и обеспечения интерфейсов к уровню специальных приложений и уровню универсальных приложений. В вариантах осуществления настоящего изобретения, где использована архитектура стандарта CEN/XFS на основе операционной системы LINUX, в которой уровень управления XFS разделен на уровень специальных приложений, уровень универсальных приложений и уровень системных служб для реализации соответствующих функций, заложена основа для выполнения программ или программного обеспечения протокола CEN/XFS в системе LINUX в устройстве финансового самообслуживания, что решает техническую проблему, заключающуюся в отсутствии в обычной технологии реализации стандарта CEN/XFS в системе LINUX.

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

[0018] Фиг. 1 - структурная схема системы устройства финансового самообслуживания;

[0019] Фиг. 2 - структурная схема архитектуры стандарта CEN/XFS на основе операционной системы LINUX согласно варианту осуществления настоящего изобретения;

[0020] Фиг. 3 - блок-схема способа реализации для стандарта CEN/XFS на основе операционной системы LINUX согласно варианту настоящего изобретения; и

[0021] Фиг. 4 - схема взаимодействия согласно способу реализации для стандарта CEN/XFS на основе операционной системы LINUX.

ПОДРОБНОЕ ОПИСАНИЕ ИЗОБРЕТЕНИЯ

[0022] Согласно вариантам осуществления настоящего изобретения, предложены архитектура стандарта CEN/XFS на основе операционной системы LINUX и способ реализации для стандарта CEN/XFS на основе операционной системы LINUX для решения технической проблемы, заключающейся в отсутствии реализации стандарта CEN/XFS в системе LINUX в обычной технологии.

[0023] Чтобы прояснить цели, признаки и преимущества настоящего изобретения, далее вместе с чертежами детально описано техническое решение в вариантах осуществления настоящего изобретения. Очевидно, что описанные ниже варианты осуществления не представляют собой все возможные варианты осуществления настоящего изобретения. На основе указанных вариантов осуществления настоящего изобретения все другие варианты осуществления, полученные специалистами в данной области техники без креативных усилий, не выйдут за рамки объема защиты настоящего изобретения.

Первый вариант осуществления

[0024] Согласно настоящему изобретению предложена архитектура стандарта CEN/XFS на основе операционной системы LINUX для реализации стандарта CEN/XFS в устройстве финансового самообслуживания в системе LINUX. Поставщик услуг (сокращенно SP), предусмотренный производителем устройства финансового самообслуживания, удовлетворяет стандарту CEN/XFS. Для нивелирования различий в аппаратных средствах, обеспечиваемых разными изготовителями устройств финансового самообслуживания, стандарт CEN/XFS задает унифицированный интерфейс поставщика услуг (сокращенно SPI), который должен быть обеспечен каждым изготовителем устройств финансового самообслуживания, и унифицированный прикладной интерфейс (сокращено API), который должен вызываться каждой прикладной программой устройств финансового самообслуживания. Интерфейсы SPI и API взаимодействуют друг с другом через уровень управления XFS (XFS-MANAGER), обеспеченный в CEN/XFS. Таким образом, как показано на фиг. 1, устройство финансового самообслуживания включает в себя прикладной программный уровень 100, уровень 200 управления XFS, уровень SP 300 и уровень 400 драйверов устройств. Прикладной программный уровень 100 соединен с уровнем 200 управления XFS через интерфейс (API) прикладных программ, уровень управления XFS соединен с уровнем SP 300 через интерфейс SPI, и уровень SP 300 соединен с уровнем 400 драйверов устройств через интерфейс драйверов устройств.

[0025] Обратимся к фиг.2, где в архитектуре стандарта CEN/XFS на основе операционной системы LINUX уровень управления XFS имеет трехуровневую структуру, которая включает в себя сверху вниз: уровень 201 специальных приложений, уровень 202 универсальных приложений и уровень 203 системных служб.

[0026] (1) Уровень 201 специальных приложений в качестве уровня интерфейса стандарта CEN/XFS интерактивно соединен с более высоким прикладным программным уровнем через интерфейс API прикладных программ и используется для вызова интерфейса SPI с уровнем SP и направления рабочей команды прикладного программного уровня путем вызова интерфейсов уровня 202 универсальных приложений и уровня 203 системных служб.

[0027] (2) Уровень 202 универсальных приложений используют для приема сообщения о событии с уровня SP и обеспечения уровня 201 специальных приложений интерфейсом для приема сообщения о событии и передачи сообщения о событии.

[0028] Предпочтительно, чтобы уровень 202 универсальных приложений использовался кроме того для прямой передачи указанного сообщения о событии с уровня SP на прикладной программный уровень.

[0029] (3) Уровень 203 системных служб используют для реализации системных служб управления журналами регистрации, управления реестрами, управления памятью, управления потоками и управления связью, и для обеспечения интерфейсов к уровню 201 специальных приложений и уровню 202 универсальных приложений.

[0030] Системную службу управления журналами регистрации можно использовать для обеспечения записи в журнал и поддержки журнала.

[0031] Системную службу управления реестрами можно использовать для считывания информации о конфигурации, и, в частности, системную службу управления реестрами также можно использовать для считывания информации о конфигурации путем считывания файла TingXml.

[0032] Системную службу управления памятью можно использовать для управления памятью, в частности, включая распределение памяти с последовательным доступом и распределение памяти с цепным доступом.

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

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

[0035] Как возможный вариант, интерфейс для приема сообщения о событии и передачи сообщения о событии, обеспеченного уровнем 202 универсальных приложений для уровня 201 специальных приложений можно реализовать с использованием функции обратного вызова.

[0036] Как возможный вариант интерфейс для приема сообщения о событии и передачи сообщения о событии, обеспеченного уровнем 202 универсальных приложений для уровня 201 специальных приложений, можно реализовать в виде межпроцессной связи или в виде межпотоковой связи системы LINUX.

[0037] В данном варианте осуществления архитектура стандарта CEN/XFS на основе операционной системы LINUX применима к устройству финансового самообслуживания, в котором принят стандарт CEN/XFS. Система устройства финансового самообслуживания включает в себя прикладной программный уровень, уровень управления XFS, уровень SP и уровень драйверов устройств. В этой архитектуре уровень управления XFS разделен на: уровень 201 специальных приложений, интерактивно связанный с прикладным программным уровнем через интерфейс API, и используемый для вызова интерфейса SPI с уровнем SP и направления операционной команды прикладного программного уровня путем вызова интерфейсов уровня 202 универсальных приложений и уровня 203 системных служб; уровень 202 универсальных приложений, используемый для приема сообщения о событии уровня SP и обеспечения уровня 201 специальных приложений интерфейсом для приема сообщения о событии и передачи сообщения о событии; и уровень 203 системных служб, используемый для реализации системных служб управления журналами регистрации, управления реестрами, управления памятью, управления потоками и управления связью и обеспечения интерфейсов к уровню 201 специальных приложений и уровню 202 универсальных приложений. В вариантах осуществления с архитектурой стандарта CEN/XFS на основе операционной системы LINUX, в которой уровень управления XFS разделен на уровень 201 специальных приложений, уровень 202 универсальных приложений и уровень 203 системных служб для реализации соответствующих функций, заложена основа для выполнения программ или программного обеспечения Протокола CEN/XFS в системе LINUX в устройстве финансового самообслуживания, что решает техническую проблему, заключающуюся в том, что в обычной технологии отсутствует реализация стандарта CEN/XFS на основе операционной системы LINUX.

Второй вариант осуществления

[0038] Согласно варианту осуществления настоящего изобретения, обеспечен способ реализации для стандарта CEN/XFS на основе операционной системы LINUX (смотри фиг. 1). На фиг. 2 и фиг. 3 указанный способ реализации согласно данному варианту осуществления включает в себя этапы с S01 по S07.

[0039] На этапе S01 уровень 201 специальных приложений вызывает интерфейс SPI с уровнем SP.

[0040] На этапе S02 уровень 201 специальных приложений вызывает управление журналами регистрации уровня системных служб для записи в журнале о вызове интерфейса SPI.

[0041] На этапе S03 уровень 201 специальных приложений определяет, является ли вызванная команда синхронной командой или асинхронной командой на основе вызванного имени функции прикладного программного уровня. В случае синхронной команды выполняется этап S04, а в случае асинхронной команды уровень 201 специальных приложений выполняет разблокировку и возврат.

[0042] На этапе S04 уровень 202 универсальных приложений принимает сообщение о событии, возвращенное с уровня SP.

[0043] На этапе S05 уровень 202 универсальных приложений возвращает сообщение о событии на уровень 201 специальных приложений.

[0044] На этапе S06 уровень 201 специальных приложений возвращает указанное сообщение о событии на прикладной программный уровень 100 на основе выходного параметра.

[0045] На этапе S07 уровень 201 специальных приложений выполняется разблокировку и возврат.

[0046] В данном варианте осуществления при реализации способа для стандарта CEN/XFS на основе операционной системы LINUX, в котором уровень управления XFS разделен на: уровень специальных приложений, уровень универсальных приложений и уровень системных служб для реализации соответствующих функций, заложена основа для выполнения программ или программного обеспечения Протокола CEN/XFS в системе LINUX в устройстве финансового самообслуживания, что решает техническую проблему, заключающуюся в том, что в обычной технологии отсутствует реализация стандарта CEN/XFS на основе операционной системы LINUX.

Третий вариант осуществления

[0047] Для лучшего понимания изобретения ниже подробно описан весь поток обработки способа реализации для стандарта CEN/XFS на основе операционной системы LINUX. Обратимся к фиг. 1, фиг. 2 и фиг. 4, где другой вариант осуществления включает следующее.

[0048] На фиг. 4 представлена схема взаимодействия согласно способу реализации стандарта CEN/XFS на основе операционной системы LINUX. Как показано на фиг. 4, данный способ реализации включает в себя этапы с S1 по S7.

[0049] Этап S1 включает в себя блокировку, анализ команды, считывание информации о конфигурации, запись в журнал регистрации, инициализацию обработчика сообщений, регистрацию класса обратного вызова на уровне SP или т.п.

[0050] На этапе S2 уровень 201 специальных приложений вызывает интерфейс SPI с уровнем SP для направления указанной команды; и уровень 201 специальных приложений вызывает управление журналами регистрации уровня 203 системных служб для записи в журнал о том, что вызван интерфейс SPI.

[0051] На этапе S3 уровень 201 определяет, является ли вызванная команда синхронной или асинхронной, на основе имени вызванной функции прикладного программного уровня 100. Этап S4 выполняется в том случае, когда команда является синхронной, и уровень 201 специальных приложений выполняет разблокировку и возврат в случае, когда команда является асинхронной.

[0052] На этапе S4 уровень 202 универсальных приложений принимает сообщение о событии, возвращенное с уровня SP 300.

[0053] На этапе S5 уровень 202 универсальных приложений возвращает сообщение о событии на уровень 201 специальных приложений.

[0054] На этапе S6 уровень 201 специальных приложений возвращает сообщение о событии на прикладной программный уровень 100 через выходной параметр.

[0055] На этапе S7 уровень 201 специальных приложений выполняет разблокировку и возврат.

[0056] Заметим, что этап S1 может дополнительно включать в себя этапы с S11 по S15 в реальном процессе реализации.

[0057] На этапе S11 уровень 201 специальных приложений выполняет блокировку посредством вызова управления потоками уровня 203 системных служб.

[0058] На этапе S12 уровень 201 специальных приложений получает вызванную команду через входной параметр интерфейса вызова прикладного программного уровня 100. Имя вызванной команды представляет собой имя вызванной функции.

[0059] На этапе S13 уровень 201 специальных приложений считывает информацию о конфигурации путем вызова управления реестрами уровня 203 системных служб.

[0060] На этапе S14 уровень 201 специальных приложений вызывает управление журналами регистрации уровня 203 системных служб для записи в журнал о том, что вызван интерфейс функции.

[0061] На этапе S15 уровень 202 универсальных приложений инициализирует обработчик сообщений посредством вызова управления потоками уровня 203 системных служб, или регистрирует класс обратного вызова на уровне SP 300.

[0062] Необходимо заметить, что в случае асинхронной команды на этапе S3 способ реализации кроме того включает в себя этапы S31 и S32 в реальном процессе реализации.

[0063] На этапе S31 уровень 202 универсальных приложений принимает сообщение о событии, возвращенное с уровня SP 300.

[0064] На этапе S32 уровень 202 универсальных приложений передает сообщение о событии на прикладной программный уровень 100.

[0065] Вдобавок, уровень 202 универсальных приложений принимает сообщение о событии, возвращенное с уровня SP 300, на обоих этапах S4 и S31 в данном варианте осуществления, который на практике может быть реализован двумя путями. Можно выбрать любой из этих двух путей.

[0066] Первый путь - это обратный вызов (callback) C++, который включает в себя этапы с S41 по S43.

[0067] На этапе S41 уровень 202 универсальных приложений выполняет регистрацию на уровне 400 драйверов устройств при инициализации. То есть, уровень 202 универсальных приложений регистрирует указатель класса интерфейса (класс интерфейса наследуется из виртуального базового класса уровня драйверов устройств) модуля на уровне 300 драйверов устройств.

[0068] На этапе S42 в случае, когда сообщение о событии создается уровнем SP 300, осуществляется вызов функции-члена виртуального базового класса интерфейса. Функция-член реализуется классом интерфейса уровня 202 универсальных приложений. Параметр функции-члена включает в себя структурные данные сообщения или структурные данные события.

[0069] На этапе S43 выполняется отбор данных на уровень 202 универсальных приложений через параметр функции-члена, и уровень 202 универсальных приложений принимает сообщение о событии, возвращенное с уровня SP 300.

[0070] Второй путь связан с использованием межпроцессного взаимодействия или межпотокового взаимодействия в системе LINUX. В этом случае интерфейс уровня 202 универсальных приложений напрямую вызывает механизм межпроцессного взаимодействия или механизм межпотокового взаимодействия системы LINUX, включая очередь сообщений, совместное использование процессов и другие механизмы связи. В качестве примера указанный второй путь описывается с использованием этапов S44-S46 для очереди сообщений.

[0071] На этапе S44 уровень 202 универсальных приложений инициализирует обработчик сообщений при инициализации путем вызова управления связью данными, относящегося к уровню 203 системных служб, для создания очереди сообщений.

[0072] На этапе S45, в том случае, когда уровень 201 специальных приложений вызвал интерфейс SPI с уровнем SP 300, уровень 202 универсальных приложений предоставляет идентификатор (ID) очереди сообщения на уровень SP 300 через параметр.

[0073] На этапе S46 в том случае, когда сообщение о событии создается уровнем SP 300, на уровень 201 специальных приложений или на прикладной программный уровень 100 передаются структурные данные сообщения или структурные данные события с помощью функции API очереди сообщений, встроенной в систему LINUX, так что уровень 201 специальных приложений и прикладной программный уровень 100 получает указанное сообщение о событии.

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

[0075] Подводя итог вышесказанному, следует отметить, что архитектура стандарта CEN/XFS на основе операционной системы LINUX и способ ее реализации для стандарта CEN/XFS на основе операционной системы LINUX обеспечены согласно настоящему изобретению для реализации стандарта CEN/XFS в системе LINUX посредством функционального разделения и совместного функционирования в трехуровневой структуре.

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

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

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

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

[0080] Интегрированный блок может храниться на машиночитаемом носителе, если этот блок реализован в виде функционального блока программного обеспечения и может продаваться или использоваться как отдельный продукт. Исходя из указанных принципов, существенная часть технического решения настоящего изобретения, либо часть технического решения изобретения, связанная с обычной технологией, либо техническое решение в целом или его часть может быть воплощена в виде программного продукта. Компьютерный программный продукт хранится на носителе данных, который включает в себя ряд команд для инициирования выполнения компьютерный устройством (которым может быть персональный компьютер, сервер, сетевое устройство или т.п.) всех или части этапов способа согласно каждому варианту осуществления настоящего изобретения. Вышеописанный носитель информации включает в себя различные носители, на которых могут храниться программные коды: например, USB диск, съемный жесткий диск, память только для считывания (ROM), память с произвольной выборкой (RAM), диск и компьютерный диск.

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

Изобретение относится к технологиям сетевой связи. Технический результат заключается в повышении скорости обработки данных. Архитектура стандарта CEN/XFS на основе операционной системы LINUX подходит для устройства финансового самообслуживания, в котором принят стандарт CEN/XFS; система устройства финансового самообслуживания содержит: прикладной программный уровень (100), уровень (200) управления XFS, уровень (300) SP и уровень (400) драйверов устройств; причем в указанной архитектуре уровень управления XFS разделен на: уровень (201) специальных приложений, уровень (202) универсальных приложений и уровень (203) системных служб. Также обеспечен способ реализации стандарта CEN/XFS на основе операционной системы LINUX для решения технической проблемы, заключающейся в отсутствии реализации стандарта CEN/XFS системы LINUX в известном уровне техники. 2 н. и 8 з.п. ф-лы, 4 ил.

1. Архитектура стандарта CEN/XFS на основе операционной системы LINUX, которая применима к устройству финансового самообслуживания, в котором принят стандарт CEN/XFS, при этом система устройства финансового самообслуживания содержит прикладной программный уровень, уровень управления XFS, уровень SP и уровень драйверов устройств; причем в данной архитектуре уровень управления XFS разделен на:

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

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

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

2. Архитектура по п. 1, в которой уровень универсальных приложений дополнительно используется для прямой передачи сообщения о событии с уровня SP на прикладной программный уровень.

3. Архитектура по п. 1, в которой

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

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

системная служба управления памятью используется для управления памятью;

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

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

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

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

5. Архитектура по любому из пп. 1-4, в которой

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

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

6. Способ реализации стандарта CEN/XFS на основе операционной системы LINUX, применимого к архитектуре стандарта CEN/XFS на основе операционной системы LINUX по п. 1, при этом способ реализации содержит этапы, на которых:

S01, вызывают, посредством уровня специальных приложений, интерфейс SPI с уровнем SP;

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

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

S04, принимают, посредством уровня универсальных приложений, сообщение о событии, возвращенное с уровня SP;

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

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

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

7. Способ реализации по п. 6, в котором перед этапом S01 способ реализации дополнительно содержит этапы, на которых:

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

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

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

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

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

8. Способ реализации по п. 7, в котором в случае асинхронной команды на этапе S03 данный способ реализации дополнительно содержит этапы, на которых:

S031, принимают, посредством уровня универсальных приложений, сообщение о событии, возвращенное с уровня SP; и

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

9. Способ реализации по п. 8, в котором этап S04 или S031 содержит этапы, на которых:

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

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

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

10. Способ реализации по п. 8, в котором

этапы S04 и S05 содержат этапы, на которых:

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

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

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

этапы S031 и S032 содержат этапы, на которых:

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

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

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