Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#361 closed задача (не будем делать)

Добавить упрощенную поддержку протокола АДС

Reported by: san Owned by: alx
Priority: средний Milestone: 1 очередь
Component: sw Keywords:
Cc:

Description (last modified by san)

По мотивам последних установок АТС, на замену координатных станций.
У некоторых наших клиентов уже имеется достаточное количество нашего оборудования старых линеек. Мониторинг этого оборудования возможен только по нашему "протоколу АДС"(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
  • Если принята команда 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

Change History (9)

comment:1 by san, 5 years ago

Description: modified (diff)

in reply to:  description comment:2 by alx, 5 years ago

Replying to san:

  • Можно обновить Supervisor до Supervisor-3U, поддерживающей и старые линейки и 3U, но, во первых, персонал уже привык к старой программе и она их вполне устраивает, во вторых, возникнут вопросы совместимости по некоторым совсем древним устройствам нашего производства(которые в старой программе поддерживаются, а в новой не очень)

Хм... Чтио-то я ничего не понимаю... Сразу несколько "странностей" вызывают недоумение.

Во-первых, если в новой версии Supervisor перестало работрать что-то, что работало в более старой - это, очевидно, проблема Supervisor'а, и, следовательно, там и надо устранить возникшую регрессию. При чем тут аппаратура?

Во-вторых, Ну, допустим, есть регрессия в новой версии Supervisor. Хорошо. Но ты сам пишешь:

В качестве программы мониторинга используется программа Supervisor(старая).

То, что система старая, не означает ли, что регрессии в ней еще нет? И если да, то может просто не надо ее обновлять (по крайней мере, до устранения регрессии)?

В связи c этим есть предложение: добавить упрощенную поддержку протокола АДС в блок 3U, для того чтобы можно было контролировать общую аварию блока с помощью старых программ Supervisor/Monitor.

А не проще будет просто запросить (например по SNMP) переменную .3.0?

Отдельное недоумение вызывает идея использования UDP для передачи потоковых данных интерфейсе RS-232. Почему не TCP? В UDP (в отличие от RS-232 и TCP), как минимум нет управления потоком, и возможно нарушение последовательности фрагментов...

Last edited 5 years ago by alx (previous) (diff)

comment:3 by san, 5 years ago

Отдельное недоумение вызывает идея использования UDP для передачи потоковых данных интерфейсе RS-232. Почему не TCP? В UDP (в отличие от RS-232 и TCP), как минимум нет управления потоком, и возможно нарушение последовательности фрагментов...

Эта разработка была 10 лет назад, сейчас задавать вопросы большого смысла нет, оборудование тысячами стоит у заказчиков в том виде в каком есть.

Немного уточню по Supervisor.
На самом деле это 2 разных программы.
Supervisor(старая) - 2008...2016 годы, сейчас более не поддерживается нами.
Supervisor-3U, относительно новая разработка, должна была быть программой мониторинга для 3U, поддерживающей также старое оборудование, но по факту для работы со старым оборудованием она менее пригодна.

Я понимаю, что решение, которое я предлагаю, не через то место, но других простых вариантов я не вижу.
Само решение, кажется, достаточно просто реализуемо в 3U, и если можно это сделать, то почему бы не упростить клиентам работу с нашим оборудованием.

in reply to:  3 comment:4 by alx, 5 years ago

Replying to san:

Я понимаю, что решение, которое я предлагаю, не через то место, но других простых вариантов я не вижу.

Так другие варианты вижу я, о чем и написал в комментарии. Но ты почему-то мои "во-первых", "во-вторых" и "в-третьих" вниманием обошел, а прокомментировал только последний абзац, где была просто реплика на отвлеченную тему...

Само решение, кажется, достаточно просто реализуемо в 3U, и если можно это сделать, то почему бы не упростить клиентам работу с нашим оборудованием.

Не понимаю пока, в чем состоит предлагаемое упрощение.

comment:5 by san, 5 years ago

Не понимаю пока, в чем состоит предлагаемое упрощение.

У прощение в том что им не придется ничего менять в существующей системе мониторинга, а просто добавить в список опрашиваемых устройств блок 3U.

Во-первых

По Supervisor-3U работы двигаются очень медленно, и приоритет отдаётся задачам связанным с 3U, я думаю что не дождусь когда все недостатки будут устранены.

Во-вторых

В старом Supervisor поддержки 3U нет, если его не обновлять, то контролировать аварию блока будет не возможно.

А не проще будет просто запросить (например по SNMP) переменную .3.0?

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

in reply to:  5 comment:6 by alx, 5 years ago

Replying to san:

У прощение в том что им не придется ничего менять в существующей системе мониторинга, а просто добавить в список опрашиваемых устройств блок 3U.

А почему без этой функции-то им надо что-то менять? Почему сегодня они не могут добавить новое устройство в список? Что мешает?

В старом Supervisor ... контролировать аварию блока будет не возможно.
Можно попробовать поковырять заброшенные исходники старого Supervisor и попробовать добавить туда такой функционал...

??? Так он что, не умеет SNMP? Кажется, начинаю понимать глубину проблемы. А пользовательский скрипт, вызывающий snmpget, тоже нельзя никак добавить? Если да, то понятно, почему возникает проблема с добавлением нового устройства... :(

comment:7 by san, 5 years ago

он что, не умеет SNMP? Кажется, начинаю понимать глубину проблемы. А пользовательский скрипт, вызывающий snmpget, тоже нельзя никак добавить.

Ага, он умеет только "протокол АДС", пользовательских скриптов не предусмотрено.

in reply to:  3 comment:8 by alx, 5 years ago

Resolution: не будем делать
Status: newclosed

Replying to san:

Supervisor(старая) - 2008...2016 годы, сейчас более не поддерживается нами.

После некоторого размышления я решил, что, так как поддержка старого Supervisor'а прекращена, то и добавлять предложенный функционал я не буду, так как такое добавление - это и есть поддержка. Не поддерживаем - значит не поддерживаем.

comment:9 by san, 5 years ago

Согласен, я после обсуждения, склоняюсь к такому-же решению.
В случае острой необходимости, лучше доработать сам старый супервизор, например научить его

запросить (например по SNMP) переменную .3.0

Note: See TracTickets for help on using tickets.