логика работы OPC сервера

Здравствуйте Уважаемые господа и дамы.
Хочу у Вас спросить вот о чем. Передо мной встала задача написать ОРС сервер для нестандартного оборудования (контроллер, который управляет этим оборудованием, собственной разработки). Проблем с написанием самого ОРС сервера, т.е реализации всех интерфейсов стандарта DA2, нет (есть конечно подводные камни, но они потихоньку решаются ). Вопрос в другом, я не пойму как организовать обмен между моим сервером и контроллером.... подробнее: у контроллера есть какой то набор команд, которые формируются в виде, ну например [A][N][D0..Dn] где А - адрес контроллера, N - номер команды, D - набор данных (все в байтах), так вот, есть команда настройки каких-либо параметров контроллера, в этой команде передается сразу множество параметров (это необходимо для минимизации трафика, т.к. обмен происходит по радиоканалу), судя по документации по OPCDA (или как я ее понимаю) изменение какого-либо параметра, должно повлечь за собой рано или поздно его запись непосредственно в контроллер, но я не могу записывать отдельно каждый параметр, в данном случае можно записать только совокупность параметров, так вот я не пойму, как лучше, или как надо организовать работу ОРС сервера в этом случае ?
На данный момент у меня это сделано так: сначала с клиентской части должен прийти запрос на чтение этих параметров, а затем, когда пользователь изменит какие-либо параметры (тэги), он изменяет дополнительный тэг, который заставляет ОРС сервер послать команду непосредственно в контроллер. Прав ли я ? ....... и попутно... судя по документации OPCDA, в метод Write (IOPCSync, IOPCSync2) можно с клиента передать сразу множество значений параметров (тэгов) в одной транзакции, как такое можно организовать на клиенте, из диалоговых форм, например в Genesis?
Заранее спасибо!

[QUOTE=kill]

Может, я не правильно вопрос понял?

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

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