Схемы, платы, компоненты

волокита) допускается использовать торговую марку, ну и получаешь Vendor-Code. Для применения же датчиков в реальных измерительных системах, обычно достаточно поддержки одной-двух команд: получить данные по первичной переменной (команда 1, ЕМНИП) и получить данные по всем измерительным величинам (команда 3, ЕМНИП). Иногда команды чтения идентификации объекта и/или девайса. Для сервиса необходима поддержка ещё нескольких открытых команд: получить длинный адрес, перевести в режим multidrop или обратно, поменять порядок переменных, смена единицы измерения. Из Vendor-Specific/Device-Specific нужны команды установки границ диапазона, а также "установка монтажного нуля" на объекте, иногда подкалибровка, может ещё какие. Из описания девайса данные о Vendor-Specific/ Device-Specific квазицентрализованно должны попадать в обновления прошивок коммуникаторов, ну и во всякие библиотеки для всяких SCADA, Plant-Web и тп. Так вот по Vendor-Code (который содержится в "длинном адресе") и далее командам идентификации коммуникатор выбирает набор Vendor-Specific/Device-Specific команд и позволяет проделать нужное. Но срок службы коммуникаторов вроде как ограничен, и в них естественной выглядит поддержка девайсов от той же фирмы производителя, соответственно, далеко не всегда можно что-то сделать с девайсами других фирм, особенно более новыми, даже после всех апгрейдов прошивки. Для нас платить за то, что у конкурента будет слабовероятная поддержка моих девайсов в их коммуникаторах, выглядит несколько странным. Перспектива же того, что где-нибудь в Австралии, например, кто-то из-за цены, например, возьмёт наши датчики, а не, например, Emersson, выглядит просто нереальной. И даже перспектива того, что кто-то купит контроллер Emersson и будет при этом покупать датчики других производителей, особенно наши, тоже ни разу не подтвердилась:) Потому, раз есть Generic Vendor-Code, мы его в датчиках и используем. А в контроллерах, собирающих данные, никаких Vendor-Specific/Device-Specific для собственно сбора и не нужно. Для сервиса наших датчиков в наших контроллерах Device-Specific команды поддерживаются, но используются, естественно, в "режиме обслуживания". Для некоторых, популярных у наших заказчиков, датчиков у нас в сервисном ПО имеется поддержка (скромно получено реверс-инжинирингом) некоторых"не наших" Vendor-Specific/Device-Specific команд, ибо мы любим заказчика:) Сервисные программы, работающие через HART-модем, поддерживающие Vendor-Specific/ Device-Specific команды, от известных "богатых" фирм практически не встречал. Но интересовался довольно давно - возможно что-то поменялось. Сами HART-модемы у нас берут не очень часто (выпускаем с RS232 и питанием HART-линии с установкой на DIN-рельс, и c USB - питание линии тоже может включаться) - они-то не требуют смены встроенного ПО. А заказчики, если покупают датчики определенного производителя, вместе с ними покупают и необходимое количество коммуникаторов, ибо Vendor-Specific/Device-Specific команды нужны для работы их КиПовцам, а не нам.

Мы ещё делаем датчики с другими интерфейсами, но заодно оставляем поддержку протокола HART:), хотя там уже могут не учитываться известные требования к Parity, скорости по интерфейсу, ну и расстояния/тайминги другие. Например, выпускаем датчики с другим интерфейсом, но тоже с передачей данных по линии питания (12 В), - там скорость номинально 19200 бод, 8N1, но только до 300 м@19200 или до 100 м@38400.