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

ОБЛАСТЬ ТЕХНИКИ

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

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

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

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

Также известны способы вспомогательного использования для поддержки работы предприятия различных автоматизированных систем управления и баз данных, такие решения именуются аббревиатурами CRM (customer relation management) и ERP (enterprise resource planning).

Так, известна унифицированная система управления информационными потоками предприятия, включающая блок модулей сбора и первичной обработки информации с различных информационных систем и передающий информацию в транспортную подсистему, которая по одностороннему каналу связи передает информацию в блок передачи и обработки данных, соединенный двухсторонними каналами связи с блоком передачи данных автоматизированных систем управления технологического процесса в единое хранилище данных и блоком внесения изменений в базу данных системы, отличающаяся тем, что дополнительно блок передачи и обработки данных по двухсторонним каналам связи обменивается информацией с блоком перекодировки нормативно-справочной информации и блоком передачи данных в информационные системы, блок внесения изменений в базу данных системы по двухстороннему каналу связан с блоком мониторинга и администрирования, блок перекодировки нормативно-справочной информации по двухстороннему каналу связан с системой согласования нормативно-справочной информации, информация, получаемая и обрабатываемая блоком передачи данных автоматизированных систем управления технологического процесса, передается в единое хранилище данных, информация из блока передачи данных в информационные системы по односторонним каналам связи поступает в различные информационные системы предприятия. Блок модулей сбора и первичной обработки информации собирает информацию, которая может быть как структурированным набором данных, получаемым из функционирующих на предприятии корпоративных информационных систем, так и первичными показателями с систем телеметрии. Единое хранилище данных, содержащее информацию в унифицированном формате, реализует единую точку доступа к данным с возможностью получения данных за предыдущий период [RU 123562G06Q 50/04G06F 17/40 Опубл. 27.12.2012].

Сущность изобретения

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

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

Технический результат состоит в оптимизации операционной деятельности предприятия, а именно:

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

- снижении транзакционных издержек предприятия,

- стандартизации процессов,

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

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

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

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

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

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

• многомерные структурные проекции модели, они же mface (mfaces), - многомерные проекции всей модели для структурирования информации по различным показателям. Хранят текущее состояние определяющих показателей предприятия, а также историю их эволюции;

• бизнес-транзакции, они же business-transactions, - отдельные дельты  (этапы) истории эволюции для mfaces. Получаются путем вычисления проецирующего алгоритма для каждого mpack;

• зип-транзакции, они же  zip-transaction (zip-transactions), - примитивные компоненты business-transaction определяющие изменение каждого отдельного параметра для каждого mface описываемых business-transaction.

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

Система обработки транзакций применяет полученный набор zip-transaction к mfaces изменяя историю и (возможно) текущее состояние модели.

Каждому mpack соответствует набор business-transactions (физически сохраненных или вычисляемых по необходимости) которые описывают эволюцию модели с соблюдением принципа сохранения баланса. Все zip-transactions составляющие business-transaction имеют жесткую связь в парах. Business-transactions имеют жесткую связь между собой естественным образом относясь к одному mpack.

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

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

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

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

Для целей оптимизации процесса допускается предвычисление business-transactions по схеме реакции на изменения (что практически эквивалентно вычислению на лету при условии детерминизма проецирующего алгоритма относительно данных mpack). Это делается для оптимизации: чтобы не тратить ресурсы на вычисление при каждом запросе, можно вычислить и сохранить результат

Накладывая специальные ограничения на отдельные параметры mfaces (простейшими случаями могут быть текущее состояние, где параметр >= 0), задаются естественные ограничения на возможность отклонения от стандартной модели предприятия, а высокая связанность транзакций приводит к невозможности внесения недостоверных данных. Так, область возможных изменений начального mpack  цепочки при наличии ограничения из примера выше сужается только до достоверных значений (при этом сам по себе параметр в mpack может оставаться положительным и даже на первый взгляд допустимым для данного отдельного mpack).

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

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

• Запрос на поставку товаров и/или услуг,

• Запрос на предоставление товаров и/или услуг,

• Уведомление о сервисном обслуживании ранее поставленных товаров,

• Уведомление о необходимости проведения расчетных операций,

• Уведомление о изменении характеристик товаров и/или услуг,

• Запрос обновлений характеристик товаров и/или услуг.

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

Агенты сети реализуют специальные машиночитаемые интерфейсы взаимодействия в автоматическом режиме. К таким интерфейсам относятся механизмы взаимодействия через протокол HTTP с сериализацией в формате JSON (REST API), однако могут быть другие варианты (WebSocket, Binary .NET Remoting)

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

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

К таким измеряемым показателям относятся в частности:

• Баланс и объем взаимодействия контрагента

• Сумма накопленных бонусных баллов в валюте учета.

• Сумма и количество товара находящегося на гарантийном обслуживании и объем гарантийного обслуживания

• Сумма и количество товара на складе

• Сумма и количество товара проданного/закупленного у контрагента

• Объем оплат произведенных по расчетным счетам (в том числе виртуальным) от/к контрагенту

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

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

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

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

Пример. Есть mface с долгом контрагента и есть mface с остатками на складе. Как указано выше, mface это некие многомерные сущности. У первого измерение одно - это контрагент. У второго - два: склад и товар. При приходе товара управляющая система предприятия (так называемая, IEM-система) на основе данных в mpack, содержащих информацию от кого, что, в каком количестве и куда пришло, вычисляет пары транзакций. Например от контрагента 10 пришли товары а,б, в каждый пункт доставки на сумму 100 рублей: тогда будет 3 пары транзакций. Транзакции будем записывать в форме M(D1..Dk, V) где

M - сокращенное название mface (для долгов можно писать D, для остатков S  и т.п.)

Dk - значение к-го измерения.

V - параметр транзакции.

Пары транзакций будем писать как M1(D1..Dr,V) -> M2(D1..Dn. V)

В этом случае всегда считаем, что в первой транзакции используется значение -V а во второй +V

И вот три пары:

1. D(10, 100) -> S(1,a, 100)

2. D(10, 100) -> S(1.b, 100)

3. D(10. 100) -> S(1, c, 100)

Итого, на D будет долг контрагента 10 = -300 а на складе станет на 300 рублей товаров больше. И никак иначе быть не может, это и есть контроль.