Программа управления дизельными электростанциями DSE

Программа предназначена для мониторинга и управления дизельными электростанциями под управлением контроллеров DSE (Deep See Electronics) (одновременно до 500 штук) с использованием протокола Modbus (TCP/IP или RS-485 через преобразователи Ethernet-RS-485) . 

 Программа предназначена для решения следующих задач:

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

2. Графического отображения территориального расположения или схемного соединения ДЭС с использованием статических карт-схем с возможностью перехода с карты на карту или с карты в окно состояния/управления ДЭС.

3. Отображения окна состояния/управления ДЭС по выбору пользователя с актуальными (с учетом цикла опроса) значениями параметров.

4. Ведения журнала аварийных состояний ДЭС, c автоматической очисткой и экспортом в папку пользователя по окончании суток в виде файлов.

5. Редактирования конфигурации программы:

• внешнего вида (выбор из предоставляемого набора цветов фона окон программы, логотипов и языков отображения текстовых сообщений);
• состава карт-схем и размещенных на них ДЭС с помощью подпрограммы редактора конфигурации ;
• индивидуальных параметров подключения и мониторинга контроллеров ДЭС;
• выборочного импорта конфигурации программы DSE Scada Suite в настройки программы.

6. Протоколирования действий пользователей в части управления ДЭС и редактирования конфигурации.

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

Мониторинг оборудования Benning через адаптер MCU

Электро-питающие установки Benning для удаленного мониторинга (Ethernet) требуют использования адаптера TCP/IP MCU . Интересно, что основными интерфейсами являются HTTP и SNMP, а таблицу Modbus TCP предлагается получить через Web-интерфейс при работе адаптера с контроллером MCU 2500. В чем тут фишка, я до конца не понял, кроме того мониторинг написал на SNMP. Следует обратить внимание на то, что для получения полных и корректных данных об оборудовании контроллер MCU должен быть правильно сконфигурирован. Так, напрасно ожидать данные о состоянии батарей от адаптера - если контроллер MCU 2500 не работает правильно с модулем BATTS.
Было намерение (в основном из-за фантастической цены адаптера) разобраться с протоколом обмена между адаптером и контроллером MCU (RS-232). Нашел в сети вот такой документ - но за его достоверность и полезность ручаться не могу.  

Мониторинг оборудования Emerson Network Power через адаптер PSNA

Контроллер M500D не позволяет удаленно (Ethernet) производить мониторинг обслуживания электрооборудования. Для решения этой задачи используем адаптер  PSNA (Web/SNMP Agent Network card). Web - интерфейс адаптера предоставляет значительно больше возможностей, нежели доступ по SNMP, но в некоторых случаях без SNMP не обойтись. MIB-файл содержит малое количество параметров, если отбросить информацию о производителе, изделии и проч. останется только лишь:

The voltage of battery in 0.1 VDC.

The total current of the batteries in 0.1 ADC.

The temperature around the battery in 0.1 Celsius degree.

The current of battery1 in 0.1 ADC.

The current of battery2 in 0.1 ADC.

The temperature around battery1 in 0.1 Celsius degree.

The temperature around battery2 in 0.1 Celsius degree.

The temperature around ambient1 in 0.1 Celsius degree

The temperature around ambient2 in 0.1 Celsius degree

The AC line A voltage in 0.1 VAC.

The AC line B voltage in 0.1 VAC.

The AC line C voltage in 0.1 VAC.

The DC voltage of the Power System in 0.1 VDC.

The DC current of the Power System in 0.1 ADC.

The alarm status of the Power System. (unknown-1,normal-2,alarm-3)

The status of communication with the Power System.  unknown-1,normal-2,interrupt-3

The AUTO/MANUAL control mode of the Power System. unknown-1,auto-2,manual-3

The status of battery charging, unknown(1), floatCharging(2), equalizeCharging(3), testing(4).

The present number of active alarams.

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

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

Мониторинг кондиционеров STULZ

Кондиционеры STULZ для удаленного мониторинга предоставляют свои данные через специализированный адаптер WIB 8000, который приводит многообразие контроллеров отдельных кондиционеров RS-485 к общему интерфейсу Ethernet. На выходе пользователь получает  WEB-интерфейс (не слишком удобный) и возможность опроса по протоколу SNMPv2. Следует обратить внимание на то, что адаптер, да и контроллеры кондиционеров - устройства достаточно достаточно медленные, ещё более в то время, когда адаптер опрашивает контроллеры кондиционеров он может вообще проигнорировать запросы по SNMP и "подвесить" картинку по HTTP. Период этого опроса регулируется параметром "refresh time" и составляет 60 секунд по умолчанию. Так что примерно раз в минуту устройство может не ответить на запрос по SNMP - и увеличение таймаута не помогает. Впрочем и наблюдаемые процессы тоже медленные - так что это не предмет для беспокойства.
MIB-файл, описывающий SNMP адаптера WIB 8000 доступен в "классической " и XML формах. Принцип формирования OID для адресного обращения к параметрам отдельных контроллеров кондиционеров поясним примером.
Контроллер на шине 1 и адрес 7 требует добавления к OID параметра своей адресации

unitOnOff : "1.3.6.1.4.1.29462.10.2.1.4.1.1.1.1013" + ".1"+".7"+".1".

Возможная проблема - отсутствие этого параметра для данного типа контроллера кондиционера - но тут надо разбираться индивидуально. В остальном всё достаточно просто, работает устойчиво и зависит от потребностей приложения.

Теоретически, можно обойтись без WIB 8000 и обращаться к контроллерам кондиционеров напрямую по RS-485 (и/или использовать другой адаптер для перехода на Ethernet). Судя по попадающимся в сети описаниям (достоверность которых можно проверить только экспериментом). STULZ использует Modbus RTU. Если у читателя есть такой опыт - пишите. 

Странное поведение клиента SNMP при работе с неадекватным сервером.

История следующая.


Пользователь клентской программы указал для некоторого устройства, опрашиваемого (чтение данных по некоторым OID)  по SNMP - IP адрес, несовпадающий с IP адресом опрашиваемого устройства. В результате - клиентская программа с грохотом упала. В ходе "разбора полётов" было выяснено следующее:

•      В локальной сети находилось SNMP устройство другого типа ( и другого производителя) , опрашивать которое клиент не планировал и информацией об OID которого не располагал, но IP адрес которого был ошибочно введён.

•     "Community" для чтения этих устройств совпали (да оно и понятно - 'public' -   по умолчанию).

•     Обработка ошибок от функции snmp_sess_synch_response в клиентской программе была организована из рук вон плохо - ну и понятно, возникло нарушение доступа к памяти и т.д. и т.п.

Казалось бы, всё ясно - не используйте одинаковые 'community' для разных устройств, обрабатывайте правильно ответы на неправильные запросы  и проблем не будет... Но.

В ходе более глубокого копания выяснилась некоторая неоднозначность возврата из функции snmp_sess_synch_response.

Берём устройство (или эмулятор) IP, OIDы и community которого мы знаем и обращаемся к нему с запросом данных по несуществующим у него OID (IP и commutity совпадают). Примерно так (часть кода пропущена):

struct snmp_session *sess;

struct snmp_pdu **response;
void *ptr=NULL;
snmp_sess_init(sess);
  
sess->version=SNMP_VERSION_2c;
sess->peername=ip;
sess->community=(unsigned char*)community;
sess->community_len = strlen(community);

ptr = snmp_sess_open(sess);

pdu=snmp_pdu_create(SNMP_MSG_GET);

snmp_parse_oid(buff, anOID, &anOID_len);
snmp_add_null_var(pdu, anOID, anOID_len);

int Ret = snmp_sess_synch_response(ptr, pdu, response);


Варианты возврата из последней функции (для разных, но несуществующих OID) следующие:

•     Ret==STAT_SUCCESS и (*response)->errstat==SNMP_ERR_NOSUCHNAME
•     Ret==STAT_TIMEOUT и (*response)==NULL;  
•     Ret==STAT_SUCCESS и (*response)->errstat==SNMP_ERR_NOERROR;

 ПОЧЕМУ? Ведь проблема одна и та же - агент получил запрос на отсутствующую у него информацию. А потому что ответственность за ответ на запрос c неизвестным OID лежит на агенте SNMP, то есть на том, кто пишет софт для устройства или эмулятора. Ответственность эта - понимается по-разному.

Но не всё потеряно - даже в последнем варианте можно пойти дальше - и обработать возникшую ошибку. Попробуем проанализировать содержимое полученного ответа

 netsnmp_variable_list *vars = pdu_receive->variables;

Список у нас содержит только одну переменную, поэтому посмотрим содержимое её поля type. В нашем случае имеем тип SNMP_NOSUCHINSTANCE.

И конечно, не следует забывать о функции snmp_sess_error. Она не всегда возвращает пустые данные.

Программа учета расхода топлива и отпущенной энергии для малых дизельных электростанций (ПУ МДЭС)

Обеспечение бесперебойного электрического питания объектов различного назначения давно стало общим местом, в котором большую роль играют малые дизельные электростанции (МДЭС) различных типов от разных производителей. Вместе с тем остаётся нерешенным вопрос учета выработанной электроэнергии и израсходованного топлива. Проблема заключается в отсутствии в составе МДЭС приборов коммерческого учета, соответствующих российским требованиям. С другой стороны, многообразие применяемых МДЭС приводит к необходимости "выведения за скобки" подсистемы учета (то есть программно-аппаратных решений, которые можно было бы применять независимо от основного оборудования). Другой проблемой остаётся необходимость защищённого удалённого доступа к подсистеме учета (через Интернет). Для решения описанных проблем может служить описываемая ниже ПУ МДЭС, использующая аппаратные компоненты, имеющие должную российскую сертификацию, а именно

• счетчики ЗАО"Энергомера",
• расходомеры производства ЗАО «Технотон».

Программная реализация использует свободно-распространяемые WEB-сервер на основе Apache и базу данных на основе MySQL, что упрощает и удешевляет разработку и облегчает при необходимости перенос ПУМДЭС на другие операционные системы.

Описание ПУ МДЭС в существующем виде можно скачать здесь.

Мониторинг блока индикации и контроля с модулем управления питанием QFC-PBIC

Попалось под руку устройство QFC-PBIC - надо мониторить состояние подключенных датчиков по локальной сети.

Вроде бы производитель вот тут http://www.qtech.ru/catalog/control/154/info.htm - но почему-то не хочет в этом признаваться, видно - давно было дело, никто не помнит...

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

Натравливаем nmap

>nmap -sU 192.168.1.1/24 -p161

- после нескольких неудачных попыток - выясняем, что IP по умолчанию 192.168.0.3.

Натравливаем snmpwalk ( c молитвой, что community никто не удосужился поменять) откуда-нибудь поближе к корню

>snmpwalk -c public -v 1 192.168.0.3 iso

SNMPv2-MIB::sysDescr = STRING: QTECH GuardBox
SNMPv2-MIB::sysObjectID = OID: SNMPv2-SMI::enterprises.27514.101
SNMPv2-MIB::sysUpTime = Timeticks: (2959774) 8:13:17.74
SNMPv2-SMI::enterprises.27514.101.1.1 = STRING: "2.4"
SNMPv2-SMI::enterprises.27514.101.1.2 = Hex-STRING: 00 08 DC 16 28 33
SNMPv2-SMI::enterprises.27514.101.1.3 = IpAddress: 192.168.1.7
SNMPv2-SMI::enterprises.27514.101.1.4 = IpAddress: 255.255.255.0
SNMPv2-SMI::enterprises.27514.101.1.5 = IpAddress: 192.168.0.1
SNMPv2-SMI::enterprises.27514.101.1.6 = INTEGER: 1
SNMPv2-SMI::enterprises.27514.101.1.7 = IpAddress: 0.0.0.0
SNMPv2-SMI::enterprises.27514.101.1.8 = INTEGER: 0
SNMPv2-SMI::enterprises.27514.101.1.9 = INTEGER: 5
SNMPv2-SMI::enterprises.27514.101.1.10 = IpAddress: 0.0.0.0
SNMPv2-SMI::enterprises.27514.101.1.11 = INTEGER: 60
SNMPv2-SMI::enterprises.27514.101.1.12 = Hex-STRING: 00 00 00 00 00 00
SNMPv2-SMI::enterprises.27514.101.1.13 = Hex-STRING: 00 00 00 00 00 00
SNMPv2-SMI::enterprises.27514.101.1.14 = Hex-STRING: 00 00 00 00 00 00
SNMPv2-SMI::enterprises.27514.101.1.15 = Hex-STRING: 00 00 00 00 00 00
SNMPv2-SMI::enterprises.27514.101.1.16 = Hex-STRING: 00 00 00 00 00 00
SNMPv2-SMI::enterprises.27514.101.1.17 = Hex-STRING: 00 00 00 00 00 00
SNMPv2-SMI::enterprises.27514.101.1.18 = Hex-STRING: 00 00 00 00 00 00
SNMPv2-SMI::enterprises.27514.101.1.19 = Hex-STRING: 00 00 00 00 00 00
SNMPv2-SMI::enterprises.27514.101.1.20 = INTEGER: 0
SNMPv2-SMI::enterprises.27514.101.1.21 = INTEGER: 0
SNMPv2-SMI::enterprises.27514.101.1.22 = INTEGER: 3
SNMPv2-SMI::enterprises.27514.101.1.23 = INTEGER: 0
SNMPv2-SMI::enterprises.27514.101.1.24 = INTEGER: 1
SNMPv2-SMI::enterprises.27514.101.1.25 = INTEGER: 1
SNMPv2-SMI::enterprises.27514.101.1.26 = INTEGER: 100
SNMPv2-SMI::enterprises.27514.101.1.27 = INTEGER: 0
SNMPv2-SMI::enterprises.27514.101.1.28 = INTEGER: 50
SNMPv2-SMI::enterprises.27514.101.1.29 = INTEGER: 5
SNMPv2-SMI::enterprises.27514.101.1.30 = INTEGER: 0
SNMPv2-SMI::enterprises.27514.101.1.31 = INTEGER: 0
SNMPv2-SMI::enterprises.27514.101.1.32 = INTEGER: 1
SNMPv2-SMI::enterprises.27514.101.1.33 = INTEGER: 0
SNMPv2-SMI::enterprises.27514.101.1.34 = INTEGER: 1
SNMPv2-SMI::enterprises.27514.101.1.35 = INTEGER: 1
SNMPv2-SMI::enterprises.27514.101.1.36 = INTEGER: 2
SNMPv2-SMI::enterprises.27514.101.1.37 = INTEGER: 0
SNMPv2-SMI::enterprises.27514.101.1.38 = INTEGER: -1
SNMPv2-SMI::enterprises.27514.101.1.39 = Hex-STRING: 00 00 00 00 00 00
SNMPv2-SMI::enterprises.27514.101.1.40 = INTEGER: 0
SNMPv2-SMI::enterprises.27514.101.1.41 = INTEGER: 5063
SNMPv2-SMI::enterprises.27514.101.1.42 = INTEGER: 100
SNMPv2-SMI::enterprises.27514.101.1.43 = INTEGER: 0
SNMPv2-SMI::enterprises.27514.101.1.44 = INTEGER: 0
SNMPv2-SMI::enterprises.27514.101.1.45 = INTEGER: 0
SNMPv2-SMI::enterprises.27514.101.1.46 = INTEGER: 255
SNMPv2-SMI::enterprises.27514.101.1.47 = INTEGER: 0
SNMPv2-SMI::enterprises.27514.101.1.48 = INTEGER: 1
SNMPv2-SMI::enterprises.27514.101.1.49 = INTEGER: 0
SNMPv2-SMI::enterprises.27514.101.1.50 = INTEGER: 0
SNMPv2-SMI::enterprises.27514.101.1.51 = INTEGER: 0
SNMPv2-MIB::sysDescr = STRING: QTECH GuardBox
Error: OID not increasing: SNMPv2-SMI::enterprises.27514.101.1.51
 >= SNMPv2-MIB::sysDescr

Конечно - никакого MIB-файла нет, но он нам и не нужен.

Теперь находим  QNMS в пробной версии, которая видит наше устройство и с помощью сопоставления snmpget/snmpset и оной программы выясняем назначение OID. Получается так.
Но тут есть проблема. OID, который содержит IP устройства - только для чтения. Как использовать устройство в другой подсети, да ещё и в нескольких экземплярах? Que faire?
Коробка открыта, имя мезонина прочитано, GOOGLE FOREVER!
Находим Configuration Tools.Это работает по UDP через порты 48714 и 48715 (WireShark с нами).

Всё - осталось написать свою программу.