#361 closed задача (не будем делать)
Добавить упрощенную поддержку протокола АДС
| Reported by: | san | Owned by: | alx |
|---|---|---|---|
| Priority: | средний | Milestone: | 1 очередь |
| Component: | sw | Keywords: | |
| Cc: |
Description (last modified by )
По мотивам последних установок АТС, на замену координатных станций.
У некоторых наших клиентов уже имеется достаточное количество нашего оборудования старых линеек. Мониторинг этого оборудования возможен только по нашему "протоколу АДС"(xсhange\ MC04-DSL Monitor всегда свежий мониторинг\прочее\ Протокол.doc) , оборудование включено в сеть через конвертер UART over UDP (например сетевой модуль V-port).
В качестве программы мониторинга используется программа Supervisor(старая).
Сейчас к имеющемуся у клиентов нашему оборудованию добавляется ещё один блок 3U(АТС), и клиенты также хотят постоянный контроль этого блока, на предмет возникновения аварии или недоступности блока.
Но есть следующие проблемы:
- Других систем мониторинга через которые можно мониторить 3U у клиентов нет.
- Для одного блока ставить отдельную новую систему мониторинга не целесообразно.
- Можно обновить Supervisor до Supervisor-3U, поддерживающей и старые линейки и 3U, но, во первых, персонал уже привык к старой программе и она их вполне устраивает, во вторых, возникнут вопросы совместимости по некоторым совсем древним устройствам нашего производства(которые в старой программе поддерживаются, а в новой не очень)
В связи c этим есть предложение: добавить упрощенную поддержку протокола АДС в блок 3U, для того чтобы можно было контролировать общую аварию блока с помощью старых программ Supervisor/Monitor.
Суть решения:
- Слушать UDP порт 1001
- Если в порт принята команда
7E 00 00 00 7E(принятые байты в HEX):- если в блоке нет аварий, в ответ на IP отправителя на UDP порт 12345 отправить
7E 7F 80 1B C7 0F 2C 7E - если в блоке есть хотя бы одна авария, в ответ на IP отправителя на UDP порт 12345 отправить
7E 7F 80 1B C7 2F 0C 7E
- если в блоке нет аварий, в ответ на IP отправителя на UDP порт 12345 отправить
- Если принята команда
7E 80 00 80 7E:- если в блоке нет аварий, в ответ на IP отправителя на UDP порт 12345 отправить
7E FF 80 1B C7 0F AC 7E - если в блоке есть хотя бы одна авария, в ответ на IP отправителя на UDP порт 12345 отправить
7E FF 80 1B C7 2F 8C 7E
- если в блоке нет аварий, в ответ на IP отправителя на UDP порт 12345 отправить
Change History (9)
comment:1 by , 6 years ago
| Description: | modified (diff) |
|---|
follow-ups: 4 8 comment:3 by , 6 years ago
Отдельное недоумение вызывает идея использования UDP для передачи потоковых данных интерфейсе RS-232. Почему не TCP? В UDP (в отличие от RS-232 и TCP), как минимум нет управления потоком, и возможно нарушение последовательности фрагментов...
Эта разработка была 10 лет назад, сейчас задавать вопросы большого смысла нет, оборудование тысячами стоит у заказчиков в том виде в каком есть.
Немного уточню по Supervisor.
На самом деле это 2 разных программы.
Supervisor(старая) - 2008...2016 годы, сейчас более не поддерживается нами.
Supervisor-3U, относительно новая разработка, должна была быть программой мониторинга для 3U, поддерживающей также старое оборудование, но по факту для работы со старым оборудованием она менее пригодна.
Я понимаю, что решение, которое я предлагаю, не через то место, но других простых вариантов я не вижу.
Само решение, кажется, достаточно просто реализуемо в 3U, и если можно это сделать, то почему бы не упростить клиентам работу с нашим оборудованием.
comment:4 by , 6 years ago
Replying to san:
Я понимаю, что решение, которое я предлагаю, не через то место, но других простых вариантов я не вижу.
Так другие варианты вижу я, о чем и написал в комментарии. Но ты почему-то мои "во-первых", "во-вторых" и "в-третьих" вниманием обошел, а прокомментировал только последний абзац, где была просто реплика на отвлеченную тему...
Само решение, кажется, достаточно просто реализуемо в 3U, и если можно это сделать, то почему бы не упростить клиентам работу с нашим оборудованием.
Не понимаю пока, в чем состоит предлагаемое упрощение.
follow-up: 6 comment:5 by , 6 years ago
Не понимаю пока, в чем состоит предлагаемое упрощение.
У прощение в том что им не придется ничего менять в существующей системе мониторинга, а просто добавить в список опрашиваемых устройств блок 3U.
Во-первых
По Supervisor-3U работы двигаются очень медленно, и приоритет отдаётся задачам связанным с 3U, я думаю что не дождусь когда все недостатки будут устранены.
Во-вторых
В старом Supervisor поддержки 3U нет, если его не обновлять, то контролировать аварию блока будет не возможно.
А не проще будет просто запросить (например по SNMP) переменную .3.0?
Вот этот вариант ещё более-менее реален. Можно попробовать поковырять заброшенные исходники старого Supervisor и попробовать добавить туда такой функционал...
comment:6 by , 6 years ago
Replying to san:
У прощение в том что им не придется ничего менять в существующей системе мониторинга, а просто добавить в список опрашиваемых устройств блок 3U.
А почему без этой функции-то им надо что-то менять? Почему сегодня они не могут добавить новое устройство в список? Что мешает?
В старом Supervisor ... контролировать аварию блока будет не возможно.
Можно попробовать поковырять заброшенные исходники старого Supervisor и попробовать добавить туда такой функционал...
??? Так он что, не умеет SNMP? Кажется, начинаю понимать глубину проблемы. А пользовательский скрипт, вызывающий snmpget, тоже нельзя никак добавить? Если да, то понятно, почему возникает проблема с добавлением нового устройства... :(
comment:7 by , 6 years ago
он что, не умеет SNMP? Кажется, начинаю понимать глубину проблемы. А пользовательский скрипт, вызывающий snmpget, тоже нельзя никак добавить.
Ага, он умеет только "протокол АДС", пользовательских скриптов не предусмотрено.
comment:8 by , 6 years ago
| Resolution: | → не будем делать |
|---|---|
| Status: | new → closed |
Replying to san:
Supervisor(старая) - 2008...2016 годы, сейчас более не поддерживается нами.
После некоторого размышления я решил, что, так как поддержка старого Supervisor'а прекращена, то и добавлять предложенный функционал я не буду, так как такое добавление - это и есть поддержка. Не поддерживаем - значит не поддерживаем.
comment:9 by , 6 years ago
Согласен, я после обсуждения, склоняюсь к такому-же решению.
В случае острой необходимости, лучше доработать сам старый супервизор, например научить его
запросить (например по SNMP) переменную .3.0
Replying to san:
Хм... Чтио-то я ничего не понимаю... Сразу несколько "странностей" вызывают недоумение.
Во-первых, если в новой версии Supervisor перестало работрать что-то, что работало в более старой - это, очевидно, проблема Supervisor'а, и, следовательно, там и надо устранить возникшую регрессию. При чем тут аппаратура?
Во-вторых, Ну, допустим, есть регрессия в новой версии Supervisor. Хорошо. Но ты сам пишешь:
То, что система старая, не означает ли, что регрессии в ней еще нет? И если да, то может просто не надо ее обновлять (по крайней мере, до устранения регрессии)?
А не проще будет просто запросить (например по SNMP) переменную .3.0?
Отдельное недоумение вызывает идея использования UDP для передачи потоковых данных интерфейсе RS-232. Почему не TCP? В UDP (в отличие от RS-232 и TCP), как минимум нет управления потоком, и возможно нарушение последовательности фрагментов...