Инструмент для разработки ОРС сервера

Здравствуйте.
Прошу Вас обсудить программу ASUTP OPC Toolkit,а главным образом указать на недостатки программы.

Скачать программу можно отсюда: http://www.asutp-plus.com/DownloadFile/counter/counter.php?book=1

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

Функуции программы:
реализация функциональности OPC сервера;
опрос устройств подключенных к СОМ порту компьютера (любой протокол обмена данными);
опрос устройства с заданным периодом опроса;
поддержка пользовательских драйверов (*.dll);
отображение свойств и текущих значений переменных (период опроса, метка времени, качество);
поддержка фунций для работы с SQL серверами;
при использовании SQL переменных, пользователь сам определяет SQL скрипт чтения/записи переменной;
ведение лога работы программы (обмен с устройствами, БД);
можно создавать свои формы со свойствами устройств и перемнных(например: адрес устройства, адрес переменной);
конфигурирование иерархического адресного пространства переменных;

Для написания пользовательской DLL, необходимо знание основ языка Delphi, наличие соответствующей среды разработки (Borland Delphi 7).
В комплекте программы поставляется драйвер Sample.dll с исходным кодом (проектом).Для отладки драйвера устройства поставляются утилиты с помощью которых, можно отладить работу драйвера без физического подключения устройства.

А софтина позиционироваться будет как платная в будующем?

К сожалению о присутствии Fastwel UNI OPC, я не знал хотя и использую их клиент.
На первый взгляд отличия следующие:
1.Поддержка различных пользовательских драйверов *.dll(т.е. различных устройств с произвольными протоколами,а их может быть много)
2.В Драйвере не так "жестко" прописываются устройства.
Есть возможность настройки параметров устройств и их переменных (адрес,тип устройства) с помощью форм, разрабытываемых разработчиком dll. Т.е. в сервере могут быть задействованны несколько устройств (с разными параметрами:адрес,тип подключения т.д.) но использовать они будут один и тот же драйвер.
3.Разработчику dll необходимо описать только правила разбора/создания данных (просто работа с массивом байт пришедших/отправляемых в порт) и свойства устройств(так же работа с массивом).
Т.е. нет необходимости работы с СОМ портами и TCP соединениями (открытие/закрытие/инициализация).
4.Поддержка работы с SQL серверами (правда пока протестированна толька на MS SQL Server)
5.Подержка большего количества типов данных (у Fastwel UNI OPC их 6)

Опять же повторюсь, данное сравнение было проведенно после быстрого изучения Fastwel UNI OPC.

Благодарим за сравнение Вашего продукта с uniopc. Имеем сказать пару слов в ответ.

Первоначально опубликовано АСУТП 1.Поддержка различных пользовательских драйверов *.dll(т.е. различных устройств с произвольными протоколами,а их может быть много)

Из интерфейсной dataserv.dll, разрабатываемой пользователем, можно загрузить хоть сотню других своих dll, реализующих разные протоколы и логику работы с устройствами, SQL-серверами и чем угодно.

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

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

Первоначально опубликовано АСУТП 3.Разработчику dll необходимо описать только правила разбора/создания данных (просто работа с массивом байт пришедших/отправляемых в порт) и свойства устройств(так же работа с массивом). Т.е. нет необходимости работы с СОМ портами и TCP соединениями (открытие/закрытие/инициализация).

На наш взгляд, универсальному OPC-серверу не нужно знать о "портах" (кстати, какой порт имеется в виду?), поскольку типов "портов" и интерфейсов (помимо последовательных RS-232, которые, видимо, подразумеваются в данном случае) в природе имеется довольно много: tcp/ip, ввод-вывод через ISA или PCI, USB, CAN-адаптеры, PROFIBUS-адаптеры, MIL-STD-1553-адаптеры и т.д.

Спрашивается, реально ли общей (не пользовательской) части универсального OPC-сервера знать о них заранее, особенно если они еще не разработаны и не выпущены на рынок?

И удастся ли разработчику универсального OPC-сервера, желающему поддержать неисчислимое разнообразие интерфейсов, используемых в АСУТП, в обозримые сроки охватить его в своем продукте, при этом предоставив пользователю удобное API?

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

Кстати, если Вы собираетесь на уровне своего универсального OPC-сервера абстрагировать COM-порты, то придется учесть некоторые особенности протоколов, реализуемых поверх них. Например, протоколы MODBUS RTU и MODBUS ASCII отличаются принципиально, поскольку первый из них является потоковым, а второй -- символьным.
Кроме того, пользователю, которому потребуется в своей специфической части OPC-сервера работать с COM-портом, вместо стандартного API доступа к COM-порту, представляемого операционной системой, придется изучать Ваше API.

С уважением,
Локотков Александр

А что же вы так над интерфейсом то не поработали? Студенческими поделками на Борланде разит за версту. Темы XP не поддерживаются, было бы хоть чуть симпатичнее. В окнах настройки кнопки Ок-Отмена называются по разному, размещены не как принято в приложениях Windows, на форме лежат неровно, реакции в них на Esc нет, окна изменяемого размера, с кнопкой минимизации, на формах настройки зачем-то лежит ПэйджКонтрол с одной вкладкой. Ужас, полный ужас, ребята!