Russian Qt Forum

Добрый день!
Есть специализированная железка. Есть программа для работы с ней, но ее качество написания скажем так, оставляет желать лучшего.
Эта программа опрашивает железку. Сниффером было выяснено, что для общения используется SOAP (XML) в HTTP по нестандартному порту.
Сеансы общения/взаимодействия получить можно в любых количествах.

Что требуется:
Написать программу, которая будет опрашивать оборудование и писать данные в базу. В какую - сейчас не важно, это может быть любой тип SQL.
Оптимальный вариант для программы, на мой взгляд, Qt+Qt SOAP. Программа, по хорошему, должна опрашивать несколько железяк независимо друг от друга (то есть многопоточная), многоплатформенная Win+Lin (Как я понимаю, это не проблема - надо использовать только стандартные средства Qt), GUI ей не нужен). По-хорошему, должна висеть сервисом/демоном.

По-идее, к ней нужна вторая часть, которая будет обращаться в базу данных и строить отчеты. Вторая часть может быть написана либо на том же Qt, либо на любом PHP/Python/etc.

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

Хотелось бы понять сложность протокола.
Подробная спецификация в разы упростит оценку.

Железка отвечает по протоколу SOAP ? оччень продвинутая надо сказать железка. Фактически с компьютером на борту...
Тип и Модель сего чЮдного девайса - это секретная информация?

Исходники вашей плохо-написанной программы имеются?
Надо просто повторить функциональность уже существующей программы?

В общем так:
Имеется птичник. Оборудование птичника управляется специализированным компьютером Viper - http://www.bigdutchman.de/ru/pticevodstvo/katalog/sistemy-mikroklimata.html
Эти Viper-ы объединены в сеть типа Profibus/RS-485 и подключены к другому специализированному компьютеру, который на борту, судя по всему, несет Linux.
Вот этот специализированный компьютер уже втыкается в сеть Ethernet и его опрашивает программа.
Первоначально у нас это задумывалось как система диспетчеризации - чтобы все птичники были объединены в локальную сеть, опрашивались раз в 3-5 минут, и, при возникновении каких-либо проблем, технический сотрудник получал своевременную информацию о проблеме. Смонтировали 1 птичник. В результате тестовой эксплуатации выяснилось, что 1 птичник опрашивается около 5 минут. Причем бОльшую часть времени идет процесс "пережевывания данных" - то есть обмена между ПК и специализированным компьютером не происходит. А у нас таких птичников около 20 - то есть на единовременный обход всех птичников надо 5 минут * 20 штук = (условно) 1,5 часа. Я думаю, все согласятся, что 1,5 часа - это большой срок.
Фирма-производитель заявляет, что это у них система сбора информации, 1,5 часа роли не играют, что-то другое будет не раньше весны и стоить будет совсем не детских денег.


Программа куплена от фирмы-производителя железа. Написана, как я вижу, на VB с использованием всяких OCX и т.д.
Исходники, само-собой, отсутствуют - кто же их даст :)
Что касается "повторить функционал" - задача минимум - в онлайне опрашивать железяки, получать состояния датчиков и тревог. По какой-либо тревоге произвести какое-либо действие - как вариант, написать письмо, проиграть какое-нибудь записанное сообщение и т.д. В таком случае для оперативного контроля - свою программу, для анализа и прочего - родную.
Задача максимум - воспроизвести функционал.

ППЦ, так намутить из-за каких-то @$# птичников....

Не проще ли было поставить вместо Viper-ов ПЛК-шки, объединить их в сеть, поставить дополнительно сервер + АРМ оператора (или просто АРМ, который бы выполнял и функции сервера если денех жалко).
На сервер/АРМ поставить SCADA.
SCADA на серваке бы опрашивала ПЛК-шки, писала базу и т.п. ; HMI на АРМ-е оператора отображала бы технологический процесс со всеми плюшками...

Мдаааа.... чего только не придумают лижбы не работать!!!  :)

Может быть, проще. НО!
Все оборудования птичника - системы поения/кормления/вентиляции - тот же Big Dutchman. От них мы получили полностью законченное решение. Плюс добавочный эффект - заточенность оборудования под требуемую отрасль, хорошо наработанная база по ситуациям. Пользовались разным оборудованием, но пару лет назад было принято решение перейти на B D в связи с хорошими результатами. В общем, рекламой заниматься не буду, скажу только что птичников с этими Вайперами у нас уже много, и ничего другого пока не планируется.

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

Это будет стоить намного дороже.

Если протокол будет известен, то времени уйдет ок. 3-х месяцев. $7-10 тыр. стоимость. Хотя сильно зависит от сложности клиентской части, какие отчеты надо, насколько гуи наворочен будет.

Про клиентскую часть пока ничего - главное получить данные (и сохранить в базу данных).
Еще раз повторю - задача минимум -
Самый минимум - получить список тревог, по ним, если есть тревога, произвести какое-нибудь действие.
Просто минимум - записать данные в базу данных.

Дальнейший вариант №1 (предпочтительный) - преобразовать программу в драйвер для SCADA-системы, например, OpenSCADA.

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

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

Поэтому сейчас прикидываю только минимум - при любом раскладе данные надо получить.

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

Так кого опрашивать? Датчики или "специализированный компьютер"?

Нет. Проверено сниффером. Опрашивается он быстро, но вот затем коммуникационная программа бОльшую часть времени обрабатывает данные.

Опрашивать специализированный компьютер. К датчикам доступа нет.

Опрашивается он быстро - значит данные приходят на ПК!
но ты писал что: "бОльшую часть времени идет процесс "пережевывания данных" - то есть обмена между ПК и специализированным компьютером не происходит. "
"пережевывания данных" - на "специализированном компьютере"?

поясни

Процесс обмена данными между ПК и "специализированным компьютером" (назовем его BFN) состоит из 2 частей.
1. Опрашивается BFN
2. Полученные данные обрабатываются.

Оба этапа занимают 5 минут на птичник.

2 этап очень длинный, занимает бОльшую часть времени. И, пока ПК занимается 2 этапом, другие компьютеры он не опрашивает.

Zebar.
Отправил сообщение в личку.

технологии, они помогают бизнесу. Но наверное это я не тому человеку говорю..

В смысле?

Я про то, что в достаточно простой АСУ ТП птичника умудрились навертеть так шо ппц... Там же  впринципе то ничего сложного нету.. Не тот алгоритм чтобы так тормозило как описал ТС. И ужасно странные наколенные "проприетарные" технологии!

Это понятно, что в каждой области применения свои "закосы", но не до такой же степени:
И стоит ли теперь после этого брать "готовые" решения данной фирмы ?  :)

Да неужели?  ;D

ЗЫ: ну, это уже оффтоп пошел..

В основном да. Смотря какой контроллер брать.
Плюс ещё нужно сюда прибавить ценю на SCADA-систему и на разработку.

обагащенный не совсем удачным опытом скрещения C++ и веб-сервисов, а так-же некоторых итогов процесса знакомства с наличием различных программных компонент и пакетов для различных языков и сред  в данной области (веб-сервися и SOAP) - могу предположить следующее:

Сдается, мне, они там на их VB реализовали разбор SOAP-сообщений вручную. )))
А с учетом того, как именно оно тормоит - бось, что и весь синтаксический анализатор XML тоже))))

"заказт солнца вручную на визуал-басике"! этим программистам памятник надо ставить! ^_^
или руки поотрывать, а потом делать памятник... так и назовем - "Индра Акшме Аль Каша- безркукий, но оччень трудолюбивый программист" ^_^
(впрочем, их менеджерам - тоже надо бы по голове дать наверное))))

В общем, при установке сначала поставился MS SOAP Toolkit 3.0. Поэтому, думаю, все не так страшно.

это классический совковый подход.
Собственно совковый товар от импортного всегда отличался тем, что совковый товар мог соорудить почти любой универсал, которому предметная область до лампочки. При этом ещё и на дизайн всегда плевали. Концепт - "дёшево и сердито". Этот концепт мы ещё называем "ведро с гайками" и многое другое.

Буржуи всегда тщательны в предметной области. И в большинстве случаев их дорогой товар себя очень быстро окупает.

Дык этож вроде немцы делали.. Судя по домену сайта de  :)