EA012934B1 - Система и способ управления удаленными приложениями - Google Patents

Abstract

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

Description

Настоящее изобретение относится к способу и системе для управления удаленными приложениями, которые обрабатывают данные.

Предпосылки создания изобретения

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

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

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

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

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

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

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

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

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

- 1 012934 решения по управлению активами.

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

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

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

В-четвертых, данные, которыми нужно управлять, объединять, преобразовывать и анализировать, обрабатываются все более и более сложными способами, чтобы получить деловой документ. Большая часть роста в реляционных базах данных в начале и середине 1990-х гг. подпитывалась деловыми документами в задачах от поддержки решения через сложные запросы 5>ОБ до аналитической онлайновой обработки (ОЬЛР) и глубокого поиска данных.

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

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

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

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

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

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

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

Различные типы сетей и условий передачи могут влиять на движение и поведение приложения, если не предпринять соответствующие меры при проектировании системы. Кроме того, можно разными способами усовершенствовать соединения сети, как в отношении аппаратных средств, так и с точки зрения программного обеспечения, что положительно повлияет на проект приложения и распределения. Системы контроля и сбора данных (8САЭА) приложения были основаны на модели клиент-сервер: централизованное средство хранит старые данные, полученные через линию связи с устройствами. Таким образом, обработка указанных данных выполняется централизованно. Если число устройств увеличивается, и объем данных, полученных от этих устройств, также достигает значительного уровня (что часто имеет место на практике), централизованное устройство быстро становится перегруженным. Добавление мощностей обработки к централизованному средству может создать большие проблемы, такие дополнительные затраты и проблемы управления. Кроме того, большая зависимость от централизованного средства делает встроенные приложения очень уязвимыми для организации сети отказов: если соединение между устройствами и централизованным средством терпит неудачу, ценные данные могут, в конечном счете, быть потеряны.

Вместе с усовершенствованиями непосредственно в устройствах (обрабатывающие устройства, емкость запоминающего устройства и агностические 08 языки высокого уровня), новые сетевые возможности приводят к переходу от модели клиент-сервер (принятой в приложениях 8САЭА) к соединению одноранговых узлов ЛВС. Этот переход приводит к высоко распределенной и расширяющейся архитектуре с устройствами, действующими как полуавтономные объекты, периодически соединяемые с потенциально многими сетями, чтобы обеспечить накопление данных (с их сохранением и обработкой), предложить услуги программного обеспечения другим устройствам и действовать как реле между устройствами - например, в случае ограниченного диапазона. Кроме того, автономия устройств дополнительно улучшается через асинхронные линии связи, где получатели сообщений освобождены от необходимости немедленно ответить на сообщения отправителей. Асинхронная модель разъединяет отправителей и получателей, повышая надежность в случае отказов сети (ответы можно послать, когда сеть становится доступной) и универсальность (устройство может сохранить запрос в местной памяти, если у него недостаточно ресурсов, чтобы обработать это сообщение). Все же иногда предпочтительно и даже необходимо использовать синхронные линии связи (например, в случае непрерывного потока данных).

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

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

Известный уровень техники

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

Типичные системы 8САЭА теперь включают четыре главных компонента: главный терминал (МТИ), дистанционный терминал (КТИ), телекоммуникационное оборудование и программное обеспечение 8САЭА. МТИ обеспечивает интерфейс человек-машина и работает как центральный пункт управления. Терминал КТИ, расположенный на удаленном участке, получает данные от региональных устройств и ждет команд, идущих от МТИ. Телекоммуникационное оборудование используется для создания линий связи между терминалами КТИ и МТИ; в системах 8САЭА непрерывные двухсторонние ли

- 3 012934 нии связи необходимы для системы в целом, чтобы функционировать должным образом. Наконец, программное обеспечение БСЛЭЛ осуществляет комплект прикладных программ для системы БСЛЭЛ.

Архитектура систем БСАИА высоко централизована: терминалы КТИ управляют устройствами, которые выполняют небольшой объем работ помимо контроля актива, на котором они установлены, и контролируют состояние передаваемых данных в предопределенных интервалах. Терминалы ΚΤϋ сами по себе не зависят от своих МТИ. Вся топология чувствительна к отказам сети: при обрыве линии связи между устройствами и терминалами КТи или между терминалами КТИ и МТи, система, как и ожидается, окажется неработоспособной.

В последние годы системы БСАИА извлекли выгоду из подвижек, сделанных в организации сетей. Линии связи теперь основаны на стандартах, открытых протоколах (таких как ТСР/1Р) и форматах представления данных (ХМЬ). Беспроводная организация сети также способствует распространению систем БСАИА. Второе поколение БСАЭЛ интегрирует и беспроводные технологии, связанные с Интернетом. Патент США № 6768994 (основанный на способе сетевого поиска данных и отчете местоположения данных и системе, реализующей этот способ, Говард и другие) описывает такую систему в контексте оперативного управления: удаленные активы, соединены с беспроводным центральным шлюзом, который имеет базу данных, в которой хранятся данные устройства. Шлюз передает данные пользователям через систему сообщений, представленную, как тееЬ-страница. Система сообщений создает отчеты на основе каждого актива. Система использует различные базы данный сети Интернет и другие технологии (АБР, ХМЬ и ХБЬ, ИНТМЬ и т.д.) для управления взаимодействием между базами данных пользователей и базой данных шлюза. Патент не решает проблему интеграции информации: пользователям предоставляют данные устройства, содержащиеся в базе данных шлюза, и здесь не описана никакая сжатая архитектура, которая относилась бы к интеграции указанных данных с информацией, собранной из разнородных источников данных. В основном, система разработана по линии первого поколения системы БСАИА: высоко централизованная архитектура, в который удаленные активы действуют как простые формирователи необработанных данных, и где основной объем обработки данных выполняется центральным шлюзом. Другой патент США № 6757714 («Сообщение о состоянии устройства на удаленный компьютер», Хансен), описывает систему БСАИА, в которой используются две конкретные интернет-технологии, гарантирующие связь между схемой, встроенной в устройство и удаленным компьютером: в виде простого протокола по передаче почты (БМТР). Этот протокол используется в сети Интернет для посылки сообщений электронной почты и язык ХМЬ (расширяемый язык разметки), открытый родовой формат представления данных, который был широко использован в различных отраслях промышленности для агностических технологий обмена сообщениями. В этом патенте БМТР используется как протокол обмена сообщениями между активами (устройствами) и удаленным компьютером. Содержание сообщения кодируется, используя язык ХМЬ.

Система, описанная в вышеупомянутом патенте, заменяет прямые линии связи между активами и удаленным компьютером (здесь используется терминал МТИ в терминологии БСАИА) с косвенными связями, поскольку сообщения с активов посылаются на удаленный компьютер, используя БМТР. Почтовый сервер БМТР служит для получения и хранения сообщений до тех пор, пока они не будут получены заинтересованными сторонами - то же самое относится к сообщениям, которые идут в обратном направлении (от удаленного компьютера к активам). Этот подход позволяет отделить отправителей сообщений от получателей. Однако система, описанная в патенте США 6757714, формально не упоминает и не обсуждает проблему интеграции информации и, соответственно, решение этой проблемы. Кроме того, в случае, когда почтовый сервер становится недоступным, патент не описывает план действий при непредвиденных обстоятельствах и при этом это не описывает, как система в целом реагирует на такой случай - следует предполагать, что данные в этом случае просто теряются. К тому же, патент не описывает, как поступают с невостребованными сообщениями электронной почты. Наконец, хотя система показывает определенный уровень распределения, архитектура в целом остается высоко централизованной: обработка в активах ограничена формированием данных состояния (в виде сообщений электронной почты).

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

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

- 4 012934 ному в одном из вышеуказанных патентов, описываемое решение основано на асинхронной модели линии связи, поддерживаемой заданной очередью сообщений. Очередь сообщений действует, как центральный сервер между отправителями (издателями) и подписчиками (получателями). Очереди сообщений, которые являются программным обеспечением сервера и специализированы по асинхронной обработке сообщений, являются лучшим выбором по сравнению с почтовыми серверами для решения такой задачей: у большинства очередей сообщения есть шанс быть невостребованными сообщениями (к которым они вообще относятся при блокировке по времени) и избыточными (чтобы поддерживать дополнительную нагрузку и как защиту против выхода сервера из строя). В контексте решения, выдвинутого ΙΒΜ, сообщения кодируются, используя собственный протокол ΙΒΜ - Μφίδάρ. а не широко используемый ХМЬ.

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

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

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

Краткое содержание изобретения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Фиг. 1 - схема, демонстрирующая взаимосвязь микроядра с устройством;

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

фиг. 3 - схема, иллюстрирующая инфраструктуру управления активами;

фиг. 4 - блок-схема устройств и инфраструктуры обработки данных по настоящему изобретению;

фиг. 5 - блок-схема структуры информационной интеграции по настоящему изобретению;

фиг. 6 - блок-схема приложения клиента, использующего систему и способ по настоящему изобретению;

фиг. 7 - блок-схема микроядра системы управления;

фиг. 8 - блок-схема последовательности развертывания по настоящему изобретению;

фиг. 9 - блок-схема устройства и системы обработки данных по настоящему изобретению;

фиг. 10 - блок-схема ядра сети по настоящему изобретению;

фиг. 11 - блок-схема одного варианта настоящего изобретения в конкретной сети распределения поставок;

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

- 6 012934

Подробное описание изобретения

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

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

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

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

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

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

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

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

- 7 012934 многих микроядрах или приложениях.

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

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

Платформа интеграции информации основана на протоколах ХМЬ и Хфиегу. В контексте этой структуры разнородные источники данных, так же как и буфер данных, представлены как источники документов ХМЬ и/или Хфиегу, полученные от источников данных. Такие источники соответственно называют источниками ХМЬ и Хфиегу. Вариант источника ХМЬ может быть абстрактным источником внутренних данных или он может входить в состав других ХМЬ, Хфиегу и источников внутренних данных. Такой подход также включает варианты источников Хфиегу, которые, в свою очередь, запрашивают основные источники данных, использующие языки \У3С Хфиегу. Платформа интеграции информации может пользоваться определенным программным обеспечением, содержащим команды УП, которые решают проблемно-зависимые задачи и взаимодействуют с источниками ХМЬ и Хс.|иегу. чтобы извлечь необходимые данные. Такие прикладные программы предназначены, главным образом, для представления синтезированной информации конечным пользователям в виде апробационных карточек, отображений и отчетов. Кроме того, система позволяет создавать теЬ-службы, которые могут быть частью комплекса, обеспечивающего частичную или полную автоматизацию деловых процессов (см. фиг. 5).

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

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

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

Конкретное использование АСС требуется во время выполнения программы, передавая определен

- 8 012934 ные для выполнения параметры инициализации на фабрику АСС. Эта фабрика обеспечивает ввод в работу АСС по указанным параметрам. Таким образом, приложения клиента статически не привязаны (по времени) к данному исполнению АСС: приложение используется в определенное время действия в соответствии с указанными параметрами, которые, как правило, являются частью конфигурации клиента.

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

Способ по настоящему изобретению

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

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

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

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

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

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

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

- 9 012934 ядрам.

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

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

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

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

Как только встраиваемые приложения готовы передать свои накопленные и предварительно обработанные данные, они соединяются с АСС и асинхронно посылают данные в инфраструктуру обработки данных. Посланные сообщения содержат пересылаемые данные, а также идентификатор и имя домена, соответствующее устройству, из которого были получены данные. Формат, по которому посылают данные сообщения, является конкретным для приложения (настоящее изобретение не выдвигает условий относительно формата данных). Кроме того, в контексте большого объема данных, стратегию передачи также оставляют приложениям (см. фиг. 9).

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

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

- 10 012934 батывающие мощности, объем памяти, полоса пропускания) и, в конечном счете, стоимость обслуживания.

В некоторых случаях некоторые устройства (например, те, с которыми очень часто сталкиваются в случае телеметрии) не могут позволить инсталляцию виртуальной машины и всей инфраструктуры (микроядро, встраиваемые приложения), описанные как часть системы по настоящему изобретению. В таких случаях используется концентратор в качестве посредника между такими микроустройствами и другие компоненты архитектуры (разработанные как часть настоящего изобретения). Создание концентратора состоит из начальной установки устройства, на котором установлены УМ и микроядро, которые воплотит концентратор. Микроядро встраивает приложение, которое связано с прокси-сервером, который также установлен на концентраторе. Прокси-сервер, в свою очередь, связан с определенным набором микроустройств, работающих по внутреннему протоколу, который использует упомянутое микроустройство и действует как мост между этими устройствами и встраиваемыми приложениями концентратора. Эта установка напоминает периферийные терминалы (ВТИ) в традиционных системах 8СЛЭЛ: концентратор обеспечивает дистанционную связь с устройствами, имеющими ограниченную мощность и не способные поддерживать программную инфраструктуру описанного выше типа в соответствии с настоящим изобретением (см. фиг. 10).

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

Такая виртуальная интеграция сначала осуществляет формирование всех источников данных таким образом, что они появляются как источники документов ХМЬ. Типы документов, которые создает каждый источник, должны быть точно определены (через схемы ХМЬ, ΌΤΌ, определения ВОР, или различные другие форматы моделирования, связанные с ХМЬ). Кроме того, конкретные запросы, которые поддерживает каждый источник, также должны быть документированы. Часто необходимо приобретение документов, которые основаны на конкретных критериях: платформа интеграции информации поддерживает использование ХРиегу для выбора конкретных документов.

Конкретно, представление источников данных в виде документов ХМЙ фактически требует преобразования выходных данных источников данных в документы ХМЬ. Каждый виртуальный источник ХМЬ, кроме того, сам по себе может быть интегрирован как часть другого фактического источника: ХМЬ хорошо приспособлен к методикам соединения частей, когда документы ХМЬ объединяются, чтобы сформировать новые документы. Таким образом, данный источник ХМЬ может быть просто внедрен в вершину других источников ХМЬ для создания виртуального сводного содержания ХМЬ.

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

Таким образом, платформы интеграции информации ХМЬ и Хс.|иегу используются в интегрированных разнородных репозиториях путем создания ХМЬ-ориентированную виртуальную базу данных, которая опрашивается, используя язык ХОиегу. в результате чего получают документы ХМЬ. Виртуальная база данных опрашивается, чтобы определить название программы для выполнения и критерии для прохода к запросу. Результатом является набор документов ХМЬ, которые соответствуют данному запросу, и данные о которых собраны в реальном времени из основных интегрированных источников данных.

Приложения интеграции информации используют платформу интеграции информации для обеспечения конкретных функциональных возможностей конечным пользователям и другим приложениям. Например, один вариант приложения интеграции информации может быть адресован к источникам ХМЬ и ХРиегу, выходные документы которых могут быть преобразованы в НТМЬ, используя Х8Ь, для отображения в теей-браузерах.

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

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

- 11 012934 функционирования передней части на вершине источников ХМЬ и ХОиегу. Эта передняя часть состоит из различных вызовов теЬ-службы, сгруппированных по их цели или по домену. Каждый запрос имеет ряд параметров в виде ввода и передает эти параметры (и любые дополнительные) на основной слой ХМЬ/ХОиегу. Слой ХМЬ/ХОиегу возвращает комплект документов ХМЬ, соответствующий данным параметрам, для исполнения теЬ-службами. Блок выполнения передает комплект документов назад вызывающей стороне в ожидаемом формате.

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

Пример варианта воплощения изобретения Назначение

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

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

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

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

Процессы

Склад (фиг. 11, позиция 8) получает товары ежедневно. Каждая партия мяса, которая поступает в холодильник на складе, маркируется тэгами РЕШ. Поступающие партии мяса имеют свою информацию (код, тип, оптовая цена, вес и т.д.), записанную в базе данных инвентарной записи продуктов, хранящихся на складе. Каждый раз, когда партия мяса покидает холодильник, его РЕШ считывается считывающим устройством РЕШ (фиг. 11 позиция 5с).

Склад оборудован беспроводной локальной сетью (^ЬЛ№), которая обеспечивает сетевое обеспечение связи с различными приложениями в своей среде. Концентратор (описанный выше в описании изобретения, фиг. 11 позиция 5) установлен на компьютере около холодильника и служит для сбора различных данных. Например, данные, зафиксированные считывающим устройством РЕШ в холодильнике, прослеживаются встраиваемыми приложениями (в концентраторе), который корректирует имеющиеся в базе данных учетные записи по мясу (когда партия мяса поступает в холодильник, в базе данных создается отчет, поскольку база данных имеет идентификатор партии мяса. Введенный флажок устанавливается на отчет). Кроме того, холодильник потребляет конкретное количество электроэнергии, цена которого также учитывается. Датчик (фиг. 11, позиция 5Ь) включен в цепь источника питания холодильника для измерения потребления электроэнергии. К датчику дистанционно обращаются встроенное приложение, которое составляет часть концентратора. Приложение хранит данные потребления электроэнергии (время, количество) во встроенной базе данных концентратора.

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

- 12 012934 складом принимает заказ. Заведующий отвечает за выполнение заказов: за соответствующие количества и сорта мяса, которые берутся из холодильника и загружаются в грузовик, который был выбран и утвержден программным обеспечением диспетчера и самим диспетчером. Когда партия мяса выгружается из холодильника, ее отметка КЕШ считывается, и встроенное приложение учета запасов мяса корректирует свою учетную запись соответствующим образом (устанавливает флажок отправлено, на отчете, соответствующем данной партии мяса). Периодически приложение синхронизирует свое состояние с централизованным приложением учета запасов, которое является частью узла службы перевозок. Синхронизация состоит из обнаружения партий мяса, у которых есть оба состояния - получено и отправлено, маркированные во встроенной базе данных, так же как любая ситуация сбоя (состояние отправлено, не может существовать без состояния получено; у данной партии мяса не может быть только своего полученного состояния, отмеченного после заданного времени, т.е. указание на то, что у продукта истек определенный срок хранения). О ситуациях нарушения рабочего режима сообщается как часть процедуры синхронизации. Партии мяса, которые были доставлены на склад и отгружены со склада, имеют соответствующие отметки в централизованной базе данных учета запасов.

Каждый грузовик (фиг. 11, позиция 9) оборудован бортовым компьютером, в котором микроядро установлено в процессе монтажа концентратора (как описано выше в соответствии с настоящим изобретением - фиг. 11, позиция 7). Микроядро имеет идентификатор, который также служит идентификатором грузовика. Кроме того, каждый грузовик также имеет считывающее устройство КЕШ (фиг. 11, позиция 7с), которое считывает каждую метку КЕШ, которая входит в грузовик и выходит из него. Когда происходят такие события, встроенное приложение синхронизации учета запасов (размещенное в микроядре) получает уведомление и хранит данные, соответствующие этим событиям, в местной базе данных. Способом, аналогичным способу работы приложения учета складских запасов, продукты, которые поступают в грузовик и выгружаются из него, имеют соответствующую запись, которая создается и обновляется в базе данных. Запись, соответствующая продукту, отмечается состояниями входа и выхода в зависимости от контекста.

Используется еще одно встроенное приложение, которое контролирует общее состояние транспортного средства. Это состояние включает скорость, число оборотов в минуту вала двигателя, состояние механизма передач и другие механические параметры, которые фиксируются системой ввода/вывода водителя (фиг. 11, позиция 7Ь). Это приложение связано с системой ввода/вывода водителя для получения данных; она не сохраняет каждый отдельный элемент данных, а скорее вычисляет, в предопределенном интервале и для каждого проверяемого параметра, коэффициенты, которые используются для определения изменения состояний. Каждое изменение состояния сохраняется в местной базе данных, контролируемой приложением. Все данные, сохраненные приложениями в транспортном средстве, имеют отметки времени и места, и приложения связаны с другими встраиваемыми приложениями, которые самостоятельно связаны с глобальной системой навигации и определения местоположения транспортного средства (СР8) (фиг. 11, позиция 7а), целью которой является выявление текущего географического положения транспортного средства.

Данный грузовик может поставлять продукты по более чем одному адресу. На каждом месте назначения из грузовика выгружается соответствующий груз. Каждый выгруженный продукт делает отметку ΚΕΈΌ (как описано выше). Данные о событии (время, КЕШ и местоположение) хранятся во встроенной базе данных, которая управляется приложением учета запасов. После завершения поставки водитель (фиг. 11, позиция 10) приступает к выписыванию накладных: работник магазина подписывает электронный счет через клавиатуру, которая связана с карманным компьютером водителя. Карманный компьютер сам связан с модулем учета и выписки накладных (фиг. 11, позиция Ό) через беспроводную связь. Приложение выписки накладных в карманном компьютере использует абстрактный слой сети (АСС) для посылки своих данных. Если сеть в данный момент недоступна, подтверждение хранится в базе данных карманного компьютера до тех пор, пока оно не будет передано. Таким же способом приложение выписки накладных посылает сообщение о завершении доставки диспетчеру. Оба сообщения (выписка накладной и подтверждение поставки) включают идентификатор грузовика, которому они соответствуют.

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

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

- 13 012934 сети (АСС).

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

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

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

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

Решение

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

1. Каждая партия мяса учитывается по базе данных учета запасов (узла службы перевозок).

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

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

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

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

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

(а) каждая отдельная база данных извлекается как источник документов ХМЬ;

(б) виртуальные источники документов ХМЬ запрашиваются по точным критериям, используя язык ХОиегу;

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

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

- 14 012934

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

- 15 012934

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

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

1.1. Основной процесс состоит из подготовки доклада оценки расходов, охватывает конкретный данный период времени.

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

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

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

1.1.4. Следующая стадия относится к расходам, связанным с водителями (заработная плата и дорожные расходы).

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

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

- 16 012934 ние на мясо цены расходы предприятия.

Преимущества и выгоды изобретения

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

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

(b) на данных активах может быть размещено множество приложений;

(c) приложения могут периодически соединиться сетью; они выполняют свои задачи автономным способом - постоянное подключение, таким образом, не является необходимым и не приводят к потере данных;

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

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

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

Claims (26)

1. ФОРМУЛА ИЗОБРЕТЕНИЯ

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

   (a) инфраструктуру для размещения, пуска в действие, контроля и обновления приложений, встроенных в устройства;

   (b) абстрактный слой сети, который обеспечивает связь между приложениями в системе и (c) платформу интеграции информации, которая обеспечивает интеграцию указанных данных, полученных от встроенных приложений с информацией, полученной из разнородных источников данных, чтобы обеспечить интегрированное представление актива организации.
2. 2. Система по п.1, в которой устройства дополнительно включают микроядро, которое управляет временем существования встроенных приложений.
3. 3. Система по пп.1 и 2, в которой встроенные приложения дополнительно включают приложения, которые собирают, обрабатывают и хранят данные об активах.
4. 4. Система по п.1, в которой абстрактный слой сети обеспечивает одноранговую асинхронную связь, а также открытие, публикацию и поиск программного обеспечения.
5. 5. Система по любому из пп.1-4, в которой инфраструктура обработки данных состоит из асинхронного программного обеспечения сервера обмена сообщениями, кэша данных и приложений для обработки данных.
6. 6. Система по п.1 или 2, которая дополнительно включает инфраструктуру управления, которая используется для управления микроядрами и приложениями в удаленных устройствах.
7. 7. Система по п.3, в которой встроенные приложения могут состоять из концентратора приложений, взаимодействующего с прокси-сервером, который непосредственно общается с одним или устройствами по внутренней связи.
8. 8. Система по п.5, при этом система включает функциональные требования, которые выполняются через сеть.
9. 9. Система по п.7, в которой инфраструктура управления включает модуль обновления приложения, который позволяет размещать встроенные приложения на удаленных устройствах.
10. 10. Система по п.9, в которой модуль обновления приложения включает сервер и ряд команд программирования, при этом сервер взаимодействует с базой данных, используемой для хранения новых приложений и обновления старых приложения, и клиентскую часть, которая находится во встроенном приложении, которое размещено в микроядре.
11. 11. Способ управления удаленными приложениями, который обеспечивает обработку данных, чтобы интегрировать указанные данные с разнородными информационными системами предприятия и деловыми процессами, содержащий следующие стадии:

    (a) размещение, пуск в действие, управление и обновление приложений, встроенных в устройства;

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

    - 17 012934 чения интегрированного вида актива организации и для запуска автоматизированных деловых процессов.
12. 12. Способ по п.11, используемый для управления удаленными приложениями и обработки данных, указанный способ содержит следующие стадии:

    (a) установку виртуальной машины и микроядра в пределах устройства;

    (b) установку устройств на данных активах;

    (c) размещение встраиваемых приложений на устройствах;

    (ά) обработку и хранение связанных с активом данных во встроенные приложения;

    (е) передачу указанных связанных с активом данных в централизованную инфраструктуру обработки данных;

    (ί) хранение относящихся к активу данных в кэше данных, который является частью централизованной инфраструктуры обработки данных;

    (д) постобработка указанных кэшированных данных в соответствии с проблемно-зависимой логикой;

    (H) создание ХМЬ-ориентированной виртуальной базы данных, интегрируя относящиеся к активу данные с данными из разнородных источников данных;

    (I) запрос виртуальной базы данных для получения результатов и (ί) использование результатов для запуска автоматизированных деловых процессов.
13. 13. Способ по п.12, в котором размещение встроенных приложений включает загрузку ресурсов приложения в сервер обновления, используя пульт администратора.
14. 14. Способ по п.12, в котором размещение встроенных приложений требует клиента обновления для опроса сервера обновления для новых размещений и их установки.
15. 15. Способ по п.13, в котором установка размещений состоит из загрузки их из сервера обновления, используя абстрактный слой сети и уведомляя микроядро с тем, чтобы оно перешло к горячему размещению приложений.
16. 16. Способ по п.15, в котором горячее размещение состоит из пуска нового приложения или обновления существующего приложения, используя соответствующие ресурсы загрузки, не прерывая работы операционной системы.
17. 17. Способ по п.16, в котором обновление существующего приложения включает остановку его действия и пуск нового приложения, соответствующего вновь размещенным ресурсам на месте старого приложения.
18. 18. Способ по п.12, в котором обработка и хранение относящихся к активу данных во встроенных приложениях состоит в их местной обработке и хранении до тех пор, пока они не будут переданы в централизованную инфраструктуру обработки данных.
19. 19. Способ по п.12, в котором передача относящихся к активу данных включает дистанционное соединение с централизованной инфраструктурой обработки данных, используя абстрактный слой сети и посылая данные в указанную инфраструктуру через указанное соединение.
20. 20. Способ по п.19, в котором данные получаются централизованной инфраструктурой обработки данных через асинхронное программное обеспечение сервера обмена сообщениями и передаются в кэш данных.
21. 21. Способ по п.12, в котором интеграция данных состоит из представления разнородных источников данных в виде источников документов ХМЬ.
22. 22. Способ по п.12, в котором разнородные источники данных интегрированы в реальном времени без создания виртуальной базы данных или информационного хранилища.
23. 23. Способ по п.12, в котором виртуальная ХМЬ представляет собой ориентированную базу данных, запросы на которую поступают на языке ХОыегу.
24. 24. Способ по п.23, в котором результат запроса представляет собой ряд документов ХМЬ, которые далее могут быть самостоятельно интегрированы, объединены и сделаны доступными для дальнейшего запроса.
25. 25. Способ по п.24, в котором результат запроса сделан доступным для приложений-клиентов в виде ^еЬ-служб, ^еЬ-страниц НТМЬ или любого другого выхода, требуемого приложениями клиента.
26. 26. Способ по п.12, в котором запуск автоматизированного делового процесса включает управление интеграцией информации ^еЬ-служб с языками определения делового процесса высокого уровня типа БРЬЬ для размещения проблемно-зависимой логики.