Очень субъективно о HIKVISION iDS-TCM203-A

    Так случилось, что меня попросили интегрировать распознавание автомобильных номеров камерой HIKVISION iDS-TCM203-A в другую программу. В двух словах - потребовалась библиотечка C#/.NET для удобства работы с устройством. Что из этого получилось - попробую изложить без эмоций, опираясь на факты. Если я в чем то не прав - подскажите в комментариях.

     Камера пришла ко мне без какой-либо сопроводительной документации, что меня не испугало -ведь есть Интернет. Вот тут то и крылась ловушка. Нагугленная информация оказалась очень противоречивой и не вполне соответствующей тому, что я увидел в устройстве.

     

     После нескольких итераций понял, что надо делать:

•  Установил SD карту в камеру, подал питание (24В) и подключил камеру к локальной сети для соединения с компьютером (OC Windows 10).
•  Установил программу SADPTool_3.0.2.4. После запуска этой программы и нажатия кнопки Refresh был произведен поиск камеры по сети и определен IP адрес камеры (далее IPcamera).
•  Запустил Internet Explorer (работа с другими браузерами возможна, но имеет особенности использования компонента ITCPWebComponents). Открыл страницу http://IPcamera. Ввел логин и пароль.
•  Загрузил компонент ITCPWebComponents. Закрыл браузер и установил ITCPWebComponents. Запустил браузер и  открыл страницу http://IPcamera. Авторизовался.
•  Установил автомобильный номер в поле зрения камеры на расстоянии около 3 м. Открыл окно Live View->Live Traffic Statistics. Нажал кнопку Capture. 

       Unknown - там где ожидал номер.  

Поменял Smart Mode на Licence Plate Recognation System.

        Unknown - там где ожидал номер. 

Запрос: Техподдержка, помогите!!!

Ответ: Ну у вас, наверно, не установлены региональные настройки номера....

Запрос: А как их установить?

Ответ: У вас должна быть менюшка - и там надо выбрать Россию, по умолчанию там Европа.

Запрос: Да, я вижу такое меню на Ютубе и мануалах на HIKVISION LPR камеры. Но у меня нет такого меню. 

Ответ: Да, мы задавали этот вопрос китайцам, но они что-то молчат... Попробуйте обновить прошивку.

Запрос: Но номер прошивки(4.2.2), который я вижу в ютубовых роликах и у себя совпадает - а пункты меню не совпадают!

Ответ: Попробуйте обновить прошивку.

Запрос: Я обновил прошивку - вместо версии 4.2.2 стала 4.2.5 - но в меню ничего не изменилось - по прежнему настройки LPR не доступны. Что делать?

Ответ: ....

Запрос:  Что делать?

Ответ: ....

Читаем описание того, что ещё не доступно - кроме недоступного выбора  страны:

"Select License Plate Type. Small-Size Plate Recognition and Large-Size Plate Recognition are selectable. Small-Size Plate Recognition: Select it when the character height of the license plate is in the range of 20 to 30 pixels. Large-Size Plate Recognition: Select it when the character height of the

license plate is in the range of 30 to 40 pixels."

А сколько у меня? Высота символа - 100 пикселов (Capture Resolution = 1920x1080).

Двигаем камеру от номера на расстояние 7 метров.

Попал! Открыл окно Live View->Live Traffic Statistics. Нажал кнопку Capture. Есть номер в текстовом виде.

А можно ли изменением настроек разрешения Encoding and Storage->Image Encoding->Capture Resolution получить возможность для изменения(уменьшения) расстояния, на котором производится распознавание? Нельзя.

А влияют ли настройки видео Encoding and Storage->Video Encoding на распознавание? Не влияют.

А меняет ли что то настройка ROI(Region of Interest)? Не влияет.

Вешаем камеру на дороге с пешеходами, велосипедистами и автомобилями по инструкции. 

• Нет событий распознавания номеров.
• Нет событий распознавания движущихся объектов без номеров.
• Подключение через SDK сообщает о периодических изменениях списка белых/черных списков номеров - хотя изменений никто не делает.
• Подключение по ISAPI работает, но команды назначенные по писанию для LPR - возвращают Forbidden.

Возвращаемся к ручному запуску распознавания для неподвижного номера. Посмотрим - что там в TCP трафике? Видим HTTP PUT запрос "/ISAPI/ITC/manualCap". Смотрим документацию по ISAPI - описания такого запроса нет. По нему возвращается много чего (видимо изображения - пока не разбирался). Но главное - в фиксированной позиции в дампе присутствует строка номера - что и надо. Замешиваем запрос с Digest-аутентификацией сначала на postman, а потом на С#.

Итого: 
Чтобы распознавать LP надо иметь неподвижный номер на расстоянии >7 метров и "ручной" захват. Посмотрим - как это будет соответствовать требованиям по размещению камеры и основной программе.

Реализация SNMP v3 на примере Coriant hiT7300

3 версия протокола SNMP (Simple Network Management Protocol) появилась достаточно давно в ответ на слабые возможности 2 версии в аспекте безопасности. Однако, несмотря на доступность и широкое распространение описаний версии 3 протокола[1], существует мало описаний реализаций, основанных на SNMP v3. Текущий пост отражает опыт автора по исследованию дампов обмена ‘Coriant Element Manager GUI’ (далее EM) и Multi-Haul Transport Platform hiT7300 (далее hiT).

Мы рассмотрим серию SNMP get и set запросов, выдаваемых EM в момент запуска и аутентификации приложения, и ответы hiT на эти запросы. Прежде чем углубиться в последовательность и содержание запросов, необходимо обратить внимание на следующее:

  1)      Клиент(EM), для успешной аутентификации, должен обладать информацией о следующих USM параметрах (RFC 3414):

·         Username – напр. ‘Administrator’,

·         Authentication protocol – MD5,

·         Authentication key - напр. ‘12345’,

·         Privacy protocol – AES,

·         Privacy key – напр. ‘12345’,

·         Context name – ‘tnms’.

  2)      При создании UDP соединения на клиентской стороне операционной системой производится выделение ‘source port’ (не путать с ‘destination port’, который для SNMP по умолчанию 161). Значение ‘source port’ может изменяться при различных запусках клиентского приложения. В рассматриваемой реализации значение ‘source port’ используется при динамическом формировании OID. Например, при выделении ‘source port’ = 60583, имеем побайтово 0xEC и 0xA7, и динамический суффикс в составе OID вида ‘.236.167’.

  

  3)      Собственный IP адрес известен клиентской стороне и используется при динамическом формировании OID. Например, для IP адреса клиента ’10.60.1.5’ в составе OID некоторых запросов будет присутствовать часть ’.10.60.1.5.’.

  4)      Упомянутое выше значение Username используется также при формировании OID. Например, для ‘Administrator’ в составе OID некоторых запросов будет присутствовать часть ’ .65.100.109.105.110.105.115.116.114.97.116.111.114.’ (ASCII).

Обратимся теперь к последовательности и содержанию get и set запросов при запуске EM, аутентификации и создании сессии (часть дампа далее не приводится):

Запросы 1 и 2. В соответствии с RFC 5343 производим "discovery" параметров EngineID, EngineBoots и EngineTime,

Request:

data: get-request,

msgData: plaintext,

variable-bindings: -

Answer:

data: report,

msgData: plaintext,

variable-bindings: (1 item)

1.3.6.1.6.3.15.1.1.4 (usmStatsUnknownEngineIDs)(Integer32) ==> 1.

Интересно, что полученные значения EngineBoots и EngineTime используются, начиная с запроса 4, а в запросе 3 для них необходимо установить нулевые значения.

Запрос 3. Запрос usmStatsNotInTimeWindows

Request:

data: get-request,

msgData: encryptedPDU,

variable-bindings: -

Answer:

data: report,

msgData: encryptedPDU,

variable-bindings: (1 item)

1.3.6.1.6.3.15.1.1.2.0 (usmStatsNotInTimeWindows)(Integer32) ==> 0.

Общее количество пакетов, полученных SNMP engine вне авторитативного окна.

Запрос 4. Запрос snmpAgentState.

Request:

data: get-request,

msgData: encryptedPDU,

variable-bindings: (1 item)

1.3.6.1.4.1.42229.1.1.1.7.128.6.0

Answer:

data: get-responce,

msgData: encryptedPDU,

variable-bindings: (1 item)

1.3.6.1.4.1.42229.1.1.1.7.128.6.0 (snmpAgentState)(Integer32) ==> 3(ENABLED).

Состояние агента.

Запрос 5. Запрос sysDescr

Request:

data: get-request,

msgData: encryptedPDU,

variable-bindings: (1 item)

1.3.6.1.2.1.1.1.0 (sysDescr)

Answer:

data: get-responce,

msgData: encryptedPDU,

variable-bindings: (1 item)

1.3.6.1.2.1.1.1.0 (sysDescr)==> ’--------- Copyright 2019 Coriant. All rights reserved.’ (OctetString)

Запрос 6. Запрос interfaceVersion структурно аналогичен 4 и 5.

Запрос 7. Запрос usmXUserLastSuccessfulLogin

Request:

data: get-request,

msgData: encryptedPDU,

variable-bindings: (1 item)

1.3.6.1.4.1.42229.1.1.1.9.2.1.13.13.65.100.109.105.110.105.115.116.114.97.116.111.114

Answer:

data: get-responce,

msgData: encryptedPDU,

variable-bindings: (1 item)

1.3.6.1.4.1.42229.1.1.1.9.2.1.13.13.65.100.109.105.110.105.115.116.114.97.116.111.114 (usmXUserLastSuccessfulLogin)

==> 07:e3:09:0a:06:1f:36:00:2b:00:00(OctetString)

 ==>2019-09-10 и т.д.

Непосредственно в OID включено Username (‘Administrator’) -’.65.100.109.105.110.105.115.116.114.97.116.111.114.’ , для которого запрашивается время его последней успешной аутентификации.

Запрос 8. Запрос создания сессии

Request:

data: set-request,

msgData: encryptedPDU,

variable-bindings: (4 items)

1.3.6.1.4.1.42229.1.1.1.9.6.1.2.6.10.60.1.5.236.167==>4(Integer32)==> createAndGo    1.3.6.1.4.1.42229.1.1.1.9.6.1.5.6.10.60.1.5.236.167==>2(Integer32)==> sessionRemoteLogin

1.3.6.1.4.1.42229.1.1.1.9.6.1.3.6.10.60.1.5.236.167==>41646d696e6973747261746f72(OctetString)==> sessionUserName(‘Administrator’)

1.3.6.1.4.1.42229.1.1.1.9.6.1.4.6.10.60.1.5.236.167==> 4043542020(OctetString)==>sessionManager ==> 'root'

Answer:

data: get-responce,

msgData: encryptedPDU,

variable-bindings: (4 items)

1.3.6.1.4.1.42229.1.1.1.9.6.1.2.6.10.60.1.5.236.167==>4(Integer32)==> createAndGo    1.3.6.1.4.1.42229.1.1.1.9.6.1.5.6.10.60.1.5.236.167==>2(Integer32)==> sessionRemoteLogin

1.3.6.1.4.1.42229.1.1.1.9.6.1.3.6.10.60.1.5.236.167==>41646d696e6973747261746f72(OctetString)==> sessionUserName(‘Administrator’)

1.3.6.1.4.1.42229.1.1.1.9.6.1.4.6.10.60.1.5.236.167==> 4043542020(OctetString)==>sessionManager ==> 'root'

Непосредственно в OID включены IP адрес и порт-источник : ‘.10.60.1.5.236.167’.

В посте кратко проиллюстрированы особенности реализации SNMP v3, присущие hiT7300.

[1] Douglas R. Mauro and Kevin J. Schmidt “Essential SNMP” (second edition).

[2] gtacknowledge.extremenetworks.com/articles/How_To/How-to-decrypt-SNMPv3-packets-in-Wireshark
[3] labs.spritelink.net/talking-snmpv3-with-nsn-hit7300

[4] hiT7300 misc docs

[5] SNMP Version 3 Concepts

Программа управления дизельными электростанциями 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). Нашел в сети вот такой документ - но за его достоверность и полезность ручаться не могу.