СПОСОБ И СИСТЕМА ДЛЯ УПРАВЛЕНИЯ ДОСТУПАМИ К РЕСУРСАМ ПРОГРАММНОЙ СРЕДЫ В ГЕОНАВИГАЦИОННЫХ СЕРВИСАХ Российский патент 2024 года по МПК G06F9/445 

Область техники, к которой относится изобретение

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

Уровень техники

Существующим на сегодняшний день геоинформационным системам (таким как, например, мобильные Яндекс Карты) присущи следующие проблемы. В системе имеется множество отображаемых на карте объектов, таких как, в качестве неограничивающего примера, метка пользователя (перемещается по координатам GPS), метки общественного транспорта (например, метка автобуса, перемещающегося по заданному маршруту), метки (пины) организаций и т.п. Также имеется ряд ресурсов или настроек, такие как, в качестве неограничивающего примера, камера (ее координаты), количество кадров в секунду (FPS) при работе приложения, стиль карты (цветовая схема), угол обзора линзы камеры (Field of View - FoV) и т.п. Кроме того, существуют различные продуктовые сценарии, такие как, в качестве неограничивающего примера, сценарии, при которых камера следит за меткой пользователя, камера следит за меткой автобуса и т.д. Также на каждом экране есть кнопки: «Где я?» (по нажатию камера перемещается к метке пользователя), «Компас» (по нажатию карта поворачивается севером наверх) и т.п.

Первая техническая проблема обусловлена тем, что различным продуктовым сценариям для работы нужны одни и те же ресурсы. Низкоуровневая синхронизация процессов и задач (взаимные исключения («мьютексы»), семафоры и т.п.) не подходит для надлежащего управления ресурсами, поскольку нужно не просто предоставить доступ к критической секции кода (ресурсу, настройке) какому-то одному объекту, а сделать это в соответствии с продуктовыми требованиями. Кроме того, в большинстве случаев требуется одновременный «захват» нескольких связанных по смыслу ресурсов (например, координаты камеры, настройки FoV и FPS) и «удержание» их некоторое время. И набор таких ресурсов может быть каждый раз разным.

Вторая техническая проблема обусловлена тем, что события нажатий на кнопки на пользовательском интерфейсе приложения геоинформационной системы являются «сквозными» (другими словами, они «пронизывают» стек насквозь, проходят по всем сценариям в стеке сценариев сверху вниз в поисках первого подходящего сценария, предназначенного для обработки данного события). В качестве иллюстративного примера, как бы далеко ни зашел пользователь в интерфейсе приложения геоинформационной системы (например, по пути «главный экран -> поиск -> карточка организации -> маршрут до организации -> ...»), по нажатию на кнопку «Где я?» всегда должен произойти переход с увеличением масштаба отображаемой карты к метке пользователя и (почти всегда) должно активироваться слежение за меткой пользователя. Такое требование порождает код, который должен описывать все возможные состояния приложения и все возможные переходы.

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

В источнике US 11507600 B2 (NetApp Inc, опубликован 22.11.2022) описана технология параллельного разделения операций с учетом зависимостей в контексте синхронной репликации данных и/или других технологий доступа к данным с их дублированием для защиты от потери данных и обеспечения клиентского доступа к данным без нарушения целостности данных в различных вычислительных средах. Например, первая нода (т.е., например, вычислительное устройство, виртуальная машина, система хранения данных, программа как сервис и т.п.) может быть выполнена с возможностью обеспечения клиентам доступа к данным, сохраняемым на устройстве хранения данных. Вторая нода может быть конфигурирована в качестве резервной по отношению к первой ноде на случай ее сбоя. Может производиться репликация (процесс синхронизации данных между несколькими нодами распределенной системы в кластере) данных с первой ноды на вторую, т.е. вторая нода может обеспечивать клиентам доступ к реплицированным данным в случае сбоя первой ноды. При этом в известной технологии отслеживается счетчик отложенных операций, выполняемых первой нодой и параллельно реплицируемых во вторую ноду. В первой ноде выполняется операция с метаданными на основании того, что значение упомянутого счетчика не превышает пороговую величину (например, значение счетчика равно нулю). Идентифицируется первый список связанных i-нод, изменяемых указанной операцией с метаданными. Определяется зависимость операции с метаданными по отношению к отложенным операциям с метаданными, реплицированным во вторую ноду. Операцию с метаданными делегируют второй ноде на основании того, что упомянутая зависимость указывает, что данная операция с метаданными независима от отложенных операций с метаданными.

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

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

В источнике WO 2020190436 A1 (NetApp Inc, опубликован 24.09.2020) описана технология синхронной репликации данных между нодами с обеспечением последовательности по временным меткам. В частности, в данном известном решении предложены способы отслеживания (по времени) обращений к хранилищу данных, причем в данном известном решении нодам присваиваются соответствующие флаги политики разрешений. Объектам хранения данных и/или обновлениям, производимым нодами при выполнении операций, в том числе по репликации, с упомянутыми объектами хранения, присваиваются временные метки (такие как, например, временная метка создания или изменения). Сущность известного решения сводится к следующим основным этапам: а) синхронизации доступов нод к хранилищам данных, б) работы с временем обращения (временными метками), и в) контроле доступов к ресурсам. В известном решении предлагается отслеживать «статус» ноды (сервера) на основании статуса репликации и типов совершаемых операций (например, чтение/запись). В случае отсутствия отграничений ноду можно синхронизировать или заполнять новыми данными, и т.д.

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

Раскрытие изобретения

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

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

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

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

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

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

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

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

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

Краткое описание чертежей

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

На Фиг. 1 схематично проиллюстрирован принцип управления доступом к ресурсам для сценариев из стека сценариев, ограничиваемого прокси-объектами;

На Фиг. 2 схематично проиллюстрирована проблема одновременного доступа к критическим ресурсам для разных сценариев из стека сценариев;

На Фиг. 3 приведена принципиальная схема системы управления доступом к критическим ресурсам согласно одному или более вариантам выполнения изобретения.

Осуществление изобретения

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

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

Различным процессам/программам/сервисам/модулям необходимы разные вычислительные мощности, объем памяти, или определенные датчики для получения данных, называемые в общем в контексте настоящего документа критическими ресурсами. При этом упомянутые критические ресурсы совместно используются упомянутыми процессами/программами/сервисами/модулями (в общем в контексте настоящего документа - «сценариями»). Критические ресурсы в контексте заявляемого изобретения являются субъектом деления ресурса доступа, другими словами - субъектом управления доступами к критическим ресурсам.

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

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

Критические ресурсы в контексте настоящего изобретения можно рассматривать также в качестве объектов или настроек, которыми, для достижения продуктовой консистентности, на некотором промежутке времени может управлять только один сценарий из стека сценариев. В данном случае понятие «продуктовая консистентность» следует понимать как непротиворечие с точки зрения продукта, в качестве неограничивающего иллюстративного примера, применительно к пользовательскому интерфейсу приложения геоинформационной системы - условие, чтобы стиль подложки карты всегда соответствовал требуемому стилю и не «мелькал», постоянно переключаясь из одного стиля в другой по команде от различных сценариев, пытающихся одновременно получить доступ к данному совместно используемому критическому ресурсу. В качестве неограничивающего примера, критическими ресурсами могут быть координаты камеры, FoV (field of view), FPS (frames per second, количество кадров в секунду, рендеринг), стиль карты (например, «пешеходный» или «автомобильный») и т.п.

Функция сценария - набор действий, которые сценарий совершает с тем или иным критическим ресурсом. Если сценарию для работы какой-то из ресурсов не требуется, соответствующая функция отсутствует. В качестве неограничивающего примера, в контексте геоинформационной системы функциями сценария могут быть позиционирование камеры, настройка FoV, настройка FPS и т.п.

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

Свойство сценария описывает способность данного сценария обрабатывать те или иные события. В качестве неограничивающего примера, в контексте настоящего описания свойства сценария обозначены как «Да» или «Нет» в зависимости от того, может или не может данный сценарий обрабатывать данное событие.

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

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

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

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

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

Для реализации изобретения авторы предлагают использовать концепцию так называемого «дырявого стека», содержащего один или более сценариев, ранжированных по времени входа в стек. Характеристика «дырявый» для стека означает, что для одного или более сценариев в стеке установлены не все параметры (есть «пропуски» в заданных параметрах, как будет проиллюстрировано ниже прочерками в графах таблиц 1-4).

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

Таблица 1. Общий случай стека сценариев

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

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

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

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

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

Таблица 2. Структура стека в примерном варианте выполнения изобретения

В таблице 2 штриховкой выделены ресурсы, используемые сценариями, в том числе и активной функцией сценария из середины стека. В примере по таблице 2 последовательно создаются и помещаются в стек три сценария. Верхнему сценарию («Показ пина на карте») достается управление камерой. Стиль карты для сценария «Показ пина на карте» не важен, поэтому настройку стиля карты осуществляет следующий сценарий («Слежение за автобусной меткой»). Управление настройкой FPS осуществляет третий сценарий - «Слежение за меткой пользователя».

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

Далее, в случае возникновения другого события - в качестве неограничивающего примера, если пользователь нажмет «Где я?» на пользовательском интерфейсе приложения геоинформационной системы, два верхних сценария (в примерном варианте по таблице 2 - сценарии «Показ пина на карте» и «Слежение за меткой автобуса») окажутся неспособны обработать соответствующие события. Поэтому эти два сценария будут вытеснены из стека, а у сценария «Слежение за меткой пользователя» активируется функция управления камерой f(GPS) (функция настройки FPS f(60) уже была активирована ранее). Для управления стилем карты активируется функция по умолчанию (f(default)).

После этого у сценария будет вызван обработчик нажатия на кнопку «Где я?»: камера переместится к метке пользователя.

Таблица 3. Стек по примерному варианту выполнения изобретения после удаления двух верхних сценариев

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

Архитектура «дырявого» стека сценариев в соответствии с изобретением позволяет создавать, с одной стороны, независимые сценарии (реализуемые в разных модулях, вызываемые разными людьми), а с другой стороны - взаимозаменяемые сценарии (например, для проведения А/Б экспериментов), поскольку для разных сценариев используются единые интерфейсы взаимодействия с критическими ресурсами и обработки событий. С точки зрения каждого единого интерфейса взаимодействия обеспечивается единая точка входа, которая распределяет каждый критический ресурс, что обеспечивает распределяемый ресурс, которым можно управлять.

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

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

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

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

В качестве неограничивающего иллюстративного примера, активными могут считаться все функции, и в таком случае сценарии по своему усмотрению будут записывать в прокси-объекты желаемые числа. После этого все числа из всех прокси-объектов суммируются, определяя настоящее значение соответствующего ресурса (в качестве неограничивающего примера - счетчика LogLevel, суммирующего числа, присвоенные функциям f(0), f(1), f(2), f(3), которые показывают, сколько важных сценариев активно в стеке сценариев на данный момент), как проиллюстрировано ниже в таблице 4. В других неограничивающих вариантах выполнения изобретения вместо суммы может использоваться минимальное или максимальное число, или любая другая агрегирующая функция.

Таблица 4. Стек сценариев в одном или более вариантах выполнения изобретения

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

В соответствии с примерным аспектом изобретения предложена система 100 управления допусками к критическим ресурсам в компьютерной системе, содержащая по меньшей мере один сервер 110, реализующий стек из по меньшей мере одного сценария, причем каждый из по меньшей мере одного сценария выполнен с возможностью вызова по меньшей мере одного обработчика 120 сценариев; по меньшей мере одно приложение 130, содержащее пользовательский интерфейс 140, который может содержать одно или более средств 150 ввода-вывода; модуль-супервизор 160, выполненный с возможностью управления стеком сценариев. Система может дополнительно содержать модуль 170 формирования прокси-объектов, выполненный с возможностью формирования прокси-объектов, инкапсулирующих соответствующие критические ресурсы для передачи их сценариям, а также выполненных с возможностью блокирования неактивных сценариев на уровне упомянутых прокси-объектов.

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

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

Следует отметить, что вышеописанные модули и другие технические средства могут быть реализованы в виде различных сочетаний аппаратных и программных элементов, а также в виде сочетания аппаратных элементов под управлением микропрограммного обеспечения и т.п. В зависимости от конкретной реализации заявляемого способа и системы вышеописанные этапы способа и модули и другие элементы системы могут быть реализованы с использованием специализированного аппаратного обеспечения, а также аппаратного обеспечения, способного исполнять программное обеспечение и связанного с надлежащим программным обеспечением. В частности, они могут быть реализованы одним специализированным процессором и/или сервером, одним совместно используемым процессором и/или сервером, или множеством отдельных процессоров, некоторые из которых могут быть совместно используемыми. В некоторых неограничивающих вариантах осуществления настоящей технологии процессор, реализующий этапы способа и/или модули системы, может быть процессором общего назначения, таким как центральный процессор (CPU), или процессором, специализированным для конкретной цели, таким как графический процессор (GPU). Кроме того, этапы способа и/или модули системы могут быть реализованы с использованием аппаратного обеспечения цифрового сигнального процессора (DSP), сетевого процессора, специализированной интегральной схемы (ASIC), программируемой пользователем вентильной матрицы (FPGA), постоянной памяти (ROM) для хранения программного обеспечения, оперативной памяти (RAM) и энергонезависимой памяти.

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

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

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

В системе согласно изобретению пользовательское устройство соединено с другими элементами системы через интерфейс связи (не показан) для обеспечения двусторонней связи по меньшей мере с одной сетью связи по меньшей мере через одну линию связи. В некоторых неограничивающих вариантах осуществления настоящего изобретения сеть связи может быть реализована в виде сети Интернет, либо в виде глобальной сети связи, локальной сети связи, частной сети связи и тому подобного. То, каким образом реализована линия связи, не ограничено конкретно. В качестве неограничивающего примера, упомянутая по меньшей мере одна линия связи может быть реализована в виде линии беспроводной связи (такой как, не ограничиваясь, линия сети связи 3G, линия сети связи 4G, Wireless Fidelity или сокращенно Wi-Fi®, Bluetooth® или тому подобное) или линии проводной связи (такой как соединение Ethernet). Вышеуказанные подробности реализации аппаратных и программных компонентов системы, реализующей способ согласно изобретению, приведены лишь в качестве иллюстративного примера материально-технических средств, реализующих изобретение, и не ограничивают объем изобретения какими-либо конкретными реализациями. Специалисты в данной области техники смогут предусмотреть другие конкретные подробности реализации компонентов системы и соединений между ними.

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

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

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

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

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

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

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

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

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

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

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

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

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

- в ответ на принятое внешнее событие формируют в стеке по меньшей мере одно событие;

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

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

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

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

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

2. Способ по п. 1, в котором внешнее событие представляет собой пользовательский ввод.

3. Способ по п. 1, в котором критические ресурсы представляют собой по меньшей мере одно из секции кода, элемента данных, датчика.

4. Способ по п. 1, в котором в стеке активируется самая верхняя доступная функция для каждого критического ресурса.

5. Способ по п. 4, в котором предыдущая активная функция для того же критического ресурса деактивируется.

6. Способ по п. 1, в котором управление одним или более совместно используемыми критическими ресурсами принадлежит активной функции.

7. Способ по п. 1, в котором неактивная функция блокируется на уровне прокси-объекта.

8. Система управления допусками к ресурсам в компьютерной системе, содержащая:

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

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

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

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

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

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

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

модуль-супервизор выполнен с возможностью:

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

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

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

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

9. Система по п. 8, в которой пользовательский интерфейс содержит одно или более средств ввода-вывода.

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

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