Система управления устройствами и ее способ планирования команд управления устройствами

Иллюстрации

Показать все

Изобретение относится к системам управления. Техническим результатом является создание системы управления устройствами, в которой сервер может динамически управлять планированием управления устройствами клиента. Результат достигается тем, что сервер передает клиенту контекст планирования, содержащий команду управления устройствами и план выполнения команды управления устройствами, а клиент формирует дерево управления устройствами с использованием контекста планирования управления устройствами, выполняет команду, когда удовлетворено заданное условие планирования и, в случае необходимости, сообщает результат выполнения команды серверу, посредством чего сервер выполняет такое управление устройствами, как запрос на выполнение команды при заданном условии, динамическое изменение условия планирования. 4 н. и 52 з.п. ф-лы, 15 ил.

Реферат

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

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

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

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

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

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

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

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

Техническая проблема

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

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

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

Техническое решение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Описание чертежей

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

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

фиг.2 - изображение, показывающее структуру документа команды в формате XML (расширяемого языка разметки), показанного на фиг.1;

фиг.3 - изображение, показывающее шаблон DTD (определения типа документа) документа команды в формате XML;

фиг.4 - изображение, показывающее структуру документа информации планирования в формате XML, показанного на фиг.1;

фиг.5 - изображение, показывающее шаблон DTD документа информации планирования в формате XML;

фиг.6 - изображение, показывающее вариант воплощения для элемента Dur продолжительности;

фиг.7 - изображение, определяющее информационное содержание порогового элемента Th;

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

фиг.9 - изображение, показывающее формат элемента Th;

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

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

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

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

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

фиг.15 - подробное изображение потока сигналов на этапе удаления планирования управления устройствами в способе планирования управления устройствами в системе управления устройствами в соответствии с настоящим изобретением, показанном на фиг.12.

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

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

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

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

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

Фигура 1 является блок-схемой, показывающей систему управления устройствами в соответствии с настоящим изобретением.

Как показано на фигуре 1, система управления устройствами в соответствии с настоящим изобретением включает в себя: сервер 100 управления устройствами для формирования контекста планирования управления устройствами и его передачи на устройство (например, терминал); и клиент 200 управления устройствами для формирования дерева управления устройствами в терминале с использованием контекста планирования, переданного от сервера 100 управления устройствами, и выполнения соответствующей команды управления устройствами, когда удовлетворено условие выполнения команды (то есть условие для выполнения команды).

Клиент 200 управления устройствами включает в себя: модуль 20 обработки команд для приема контекста планирования от сервера 100 управления устройствами; модуль 30 планирования для формирования дерева 40 управления устройствами с использованием контекста планирования, переданного от модуля 20 обработки команд, уведомления модуля 20 обработки команд об удовлетворении условию выполнения команды для выполнения соответствующей команды управления устройствами, когда удовлетворено условие выполнения команды, и приема результата обработки команды управления устройствами от модуля 20 обработки команд, чтобы таким образом выборочно сообщать его серверу управления устройствами.

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

Фиг.1 показывает пример дерева управления устройствами, сформированного клиентом управления устройствами.

На фиг.1 дерево 40 управления устройствами включает в себя, по меньшей мере, одно или несколько поддеревьев 41 планирования управления устройствами, каждое из которых включает в себя множество узлов планирования, а именно узел Sched_1 плана, узел SchedID, узел Condition, узел Commands, узел UserInter, узел Gating и т.п.

Узел Sched_1 плана указывает каждое планирование управления устройствами (Sched_1) и соединяет узел Commands и узел Condition друг с другом. Главным образом, узел Sched_1 плана используется как "шаблон" (то есть базисный узел позиции). Узел Condition указывает условие, при котором команда управления устройствами должна быть выполнена. Узел Commands указывает запланированные команды управления устройствами, которые должны быть выполнены клиентом управления устройствами, когда удовлетворено условие выполнения команды (то есть в заданный момент времени или при заданном состоянии). Кроме того, узел UserInter указывает, должно ли быть принято пользовательское подтверждение относительно выполнения соответствующей команды, когда удовлетворено условие выполнения команды. Узел Gating указывает, нужно ли уведомлять сервер 100 управления устройствами о результате выполнения команды управления устройствами. Кроме того, поддерево 41 планирования управления устройствами может также выборочно (факультативно) включать в себя узел Mgmtsvr сервера управления устройствами. Предпочтительно узел Mgmtsvr хранит адрес сервера для сообщения результата выполнения команды управления устройствами. Например, если результат обработки нужно сообщить другому серверу, отличному от соответствующего сервера управления устройствами, или сервер управления устройствами, которому нужно сообщить результат обработки, различается соответственно каждому результату обработки, узел Mgmtsvr включает в себя информацию о списке управления доступом (ACL), указывающую сервер, имеющий полномочия управления, для каждого узла.

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

Общая база 50 данных, в которой хранится различная информация, которой сервер 100 управления устройствами может управлять, используется для хранения фактического значения каждого узла в поддереве 41 планирования управления устройствами. В частности, узел Commands и узел Condition соответствуют документу команды в формате XML (расширяемого языка разметки) и документу планирования в формате XML, соответственно.

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

Фигура 2 показывает структуру документа команды в формате XML, и фигура 3 показывает шаблон определения типа документа (DTD) документа команды в формате XML. Как показано на фигурах 2 и 3, корневой элемент документа команды в формате XML относится к элементу Command. Элемент языка команд, определенный в соответствующем протоколе управления устройствами, включен в содержание элемента Command.

Когда поддерево 41 планирования управления устройствами создано, клиент 200 управления устройствами принимает команды управления устройствами от сервера 100 управления устройствами и сохраняет их в общей базе 50 данных. После этого команды управления устройствами могут быть изменены или удалены в другом сеансе управления устройствами.

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

На фигурах 4 и 5 документ планирования в формате XML является правильным документом в формате XML, в котором элемент <Sched> является корневым элементом. Каждый информационный элемент описывает условия планирования. Когда поддерево 41 планирования управления устройствами создано, клиент 200 управления устройствами принимает информацию планирования от сервера 100 управления устройствами и сохраняет ее в общей базе 50 данных. Впоследствии информация планирования может быть изменена или удалена в другом сеансе управления устройствами.

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

Элемент SimpSched определяет одну простую спецификацию планирования и один или несколько триггеров. Определительная спецификация планирования определяется посредством соединения нескольких простых спецификаций планирования. Определительная спецификация планирования определяется элементом Sched. Элемент SimpSched составлен из единичных спецификаций планирования, определяемых посредством одного или нескольких элементов Dur продолжительности, элементов Per периода и пороговых элементов Th. Для назначения условия, при котором триггер, сформированный из каждого элемента, должен быть доставлен клиенту управления устройствами, формируется взаимосвязь между единичными спецификациями планирования. Таким образом, если логическим значением отдельного единичного элемента является "ложь", триггер, сформированный из другого единичного элемента, может быть никогда не доставлен клиенту управления устройствами.

Элемент Dur является единичной спецификацией планирования для определения периода времени или заданного момента времени. Период времени одновременно определяет и логическое значение, и триггер, а заданный момент времени определяет только триггер.

Фигура 6 является вариантом воплощения элемента Dur продолжительности.

На фигуре 6 содержание элемента продолжительности как обычный текст со специальным синтаксисом, который будет описан ниже, конфигурирует начальный момент и конечный момент диапазона времени посредством использования специального оператора '..'. Элемент продолжительности представлен датой и временем. Когда и дата, и время используются вместе, дата ставится перед временем, и дата отделяется от времени символом 'T'. Например, 26 июля 2004 года 23 часа 59 минут 59 секунд выражено как '2004-07-26T23:59:59'. Кроме того, минимальное значение элемента продолжительности ограничено 10 секундами, и символы '*', 'im', и '˜' определяют 'каждый час', 'немедленно' и 'непрерывно', соответственно по порядку. Здесь '˜' может использоваться вместе с 'im'.

Элемент Per периода как единичный элемент планирования для определения периода времени используется вместе с другим единичным элементом планирования и периодически формирует последовательные триггеры, пока условие является 'истиной'.

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

Пороговый элемент Th как единичный элемент планирования для определения диапазона значения может определить два различных типа диапазонов и заданное значение, в котором формируется триггер. Элемент Th может быть использован вместе с другими единичными элементами планирования, такими как другой элемент Th, элемент Dur или элемент Per. Элемент Th имеет значение атрибута 'Hyst', которое указывает значение гистерезиса для заданного порога. Элемент Th также имеет значение атрибута 'MgmtObj' и URI (унифицированный идентификатор ресурса) объекта управления, связанного с элементом Th. Содержанием порогового элемента является строка обычного текста, составленная на основе заданного синтаксиса, который будет описан ниже.

Фигура 7 является изображением, определяющим содержание порогового элемента Th, описанное на основе расширенной формы Бэкуса-Наура (ABNF), определенной в RFC2234.

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

Содержание элемента Th представлено как элемент 'ThContent', составленный из более чем одного элемента 'ThContentltem', которые разделены оператором 'IS'. Здесь элемент 'ThContentItem' определяет один из элементов 'ThGroup', 'ThRange' и 'EventRange'.

Элемент ThGroup определяет один или несколько триггеров, которые представлены комбинацией из 'Threshold' и 'Delta' или комбинацией из 'TW(*)' и 'ThExc'. Триггер, который является индикатором для информирования клиента о том, что связанная команда должна быть обработана, может быть сформирован из элемента Th, элемента Dur и элемента Per. Здесь триггер, сформированный из элемента триггера, имеет отношение к изменению значения связанного объекта управления.

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

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

Элемент 'ThExc' определяет порог, исключенный из другой группы порогов, и обычно используется вместе с групповым символом порога.

Элемент 'Delta' составлен из одного или нескольких порогов, каждый из которых представляет каждое приращение. Здесь граничное значение диапазона события представлено элементами события, которые указывают начало события и конец события. Когда наступает начало события из диапазона события, логическим значением условия, обозначенного элементом 'EventRange', становится 'истина'. Когда наступает конец события из диапазона события, логическим значением условия становится 'ложь'. Элемент 'Event' обозначает событие, при котором значение объекта управления имеет заданное значение или находится в пределах некоторого диапазона. Поэтому, чтобы представить элемент 'Event', могут быть использованы порог, группа порогов и пороговый диапазон. Например, случай, при котором значение объекта управления имеет заданное значение или находится в пределах диапазона значения по умолчанию, может быть элементом 'Event'. Одна или обе стороны диапазона события могут быть открытыми, и диапазон, обе стороны которого открыты, именуется как групповой символ диапазона события.

Элемент 'ThRange', который определяет пороговый диапазон, используется для определения условия и для формирования триггера. Некоторая из сторон порогового диапазона может быть открытой. Специальный диапазон, обе стороны которого открыты, именуется как групповой символ порогового диапазона. Групповой символ порогового диапазона не может использоваться независимо, но может быть полезен при его использовании вместе с элементом 'ThRangeExc'. Триггер формируется, когда логическое значение условия, определенного пороговым диапазоном, первый раз изменяется на 'истину'. Впоследствии триггер также формируется всякий раз, когда логическое значение условия изменяется.

Элемент 'ThRangeExc' составлен из более чем одного элемента TREP, с тем чтобы представить исключение из заданного порогового диапазона. Здесь элемент TREP является компонентом, который используется только в элементе 'ThRangeExc'.

Элемент 'EventRange', который указывает диапазон события, может определять условие и триггер как элемент 'ThRange'. Здесь граничное значение диапазона события представлено элементами события, которые указывают начало события и конец события. Когда наступает начало события из диапазона события, логическим значением условия, обозначенного элементом 'EventRange', становится 'истина'. Когда наступает конец события из диапазона события, логическим значением условия становится 'ложь'. Событие обозначает событие, при котором значение объекта управления имеет заданное значение или находится в пределах некоторого диапазона. Таким образом, чтобы представить событие, могут использоваться порог, группа порогов и пороговый диапазон. Например, событие, при котором значение объекта управления имеет заданное значение или находится в пределах диапазона значения по умолчанию, может быть событием. Одна или обе стороны диапазона события могут быть открытыми, и диапазон, обе стороны которого открыты, именуется как групповой символ диапазона события.

Фигура 8 показывает определения операторов и специальных символов, используемых в элементе Th, фигура 9 показывает свойства элемента Th, и фигура 10 показывает вариант воплощения для создания контекста планирования управления устройствами с использованием элемента Th.

Вариант воплощения, показанный на фигуре 10, указывает контекст планирования управления устройствами для элемента 'Get', который отдает распоряжение обработать команду 'Get' значения узла, когда оно равно 1200, 1400, 3000 или каждые 60 секунд, пока значение находится между 1800 и 3000.

Фигура 11 является изображением, подробно показывающим структуру системы управления устройствами, показанной на фигуре 1.

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

Функциональный блок 10 формирования/изменения контекста планирования, обеспеченный в сервере 100 управления устройствами, формирует контекст планирования управления устройствами и обращается к модулю 20 обработки команд клиента 200 управления устройствами с запросом на установку или изменение контекста планирования управления устройствами.

Функциональный блок 31 установки/восстановления контекста планирования формирует поддерево планирования управления устройствами, чтобы, таким образом, формировать дерево управления устройствами, когда сервер 100 управления устройствами делает запрос на установку/изменение контекста планирования через функциональный блок 21 передачи запроса модуля 20 обработки команд. Если требуется, функциональный блок 31 установки/восстановления контекста планирования может принимать пользовательское подтверждение перед установкой контекста планирования.

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

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

Функциональный блок 22 выполнения команды выполняет запланированные команды управления устройствами в поддереве планирования управления устройствами в соответствии с запросом на выполнение команды управления устройствами от функционального блока 32 подтверждения условия выполнения команды. Функциональный блок 22 выполнения команды передает результат выполнения команды (состояние/результат/общее предупреждение) модулю планирования 30 посредством ответного сообщения. Ответное сообщение, например, включает в себя коды результата выполнения команды относительно того, что команды были полностью выполнены, по какой причине произошла ошибка, каково состояние устройства после выполнения команды и т.п.

Функциональный блок 34 фильтрования отчета о состоянии фильтрует данные, которые должны быть сообщены серверу 100 управления устройствами. Функциональный блок 34 фильтрования отчета о состоянии определяет, нужно ли сообщать серверу 100 управления устройствами результат выполнения команды (состояние/результат/общее предупреждение), переданный от функционального блока 22 выполнения команды.

Функциональный блок 35 отчета о состоянии контекста планирования сообщает серверу управления устройствами результат выполнения команды (состояние/результат/общее предупреждение), пере