В версии OPC Data Access 2.0 формат данных используемых в операциях обмена на уровне клиент-сервер ограничивался существующими форматами OLE. Безусловно, для передачи комплексных данных, можно было использовать обезличенные массивы данных, при этом в клиенте для понимания структуры этих данных надо знать структуру массива или строк. 

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

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

Обработка и мониторинг команд

  Спецификация OPC Data Access 2.x предлагала для выдачи управляющих воздействий на устройства управления использовать обычную операцию запись в тег, причем результат такой операции можно было наблюдать через вспомогательный тег связанный c каналом ввода, отражающим текущее состояние канала вывода. Такой вариант выдачи команд был (впрочем, пока и остается) очень неудобным, и в спецификацию 3.0 был добавлен набор интерфейсов специально предназначенных для выдачи команд, а также, что наиболее важно, для отслеживания хода выполнения заданных команд.

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

Доступ к каналам ввода-вывода

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

  Предполагается отказ от использования старого механизма просмотра содержимого сервера (имен тегов), взамен предлагается классификация ItemID основанная на модели используемой в IEC-61131-3. Эта модель, несомненно, упростит понимание структуры содержимого OPC-сервера разработчиков ПО контроллеров.

  Для данных каналов ввода-вывода предлагается использовать раздельное кэширование, и соответственно разделение внутренних механизмов сервера ответственных за обработку каналов ввода и каналов вывода.

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