Имеется аппарат, состоящий из множества физических устройств. Устройства соединены в бортовую сеть с выходом на ПК. Для каждого устройства имеется программный модуль управления на ПК, реализованный в виде плагина (дочернего окна в MDI-приложении). Контроль аппарата производится в ручном режиме: через контролы плагинов подаются команды на физические устройства, ответы устройств также отображаются на плагинах.

Стоит задача сделать контроль аппарата автоматическим (автоматизированным). Поскольку подобных проектов (различных аппаратов) предполагается много, задача усложняется. Нужно разработать каркас (архитектуру) программы контроля (речь идет только о программе на ПК), пригодный для многократного повторного использования в разных проектах. Отсюда требования к гибкости, наращиваемости и пр. Очевидно, что программа контроля должна настраиваться скриптами. Выглядит привлекательным использование Qt+Python, хотя не обязатально.

Где можно получить детальную консультацию (в том числе платную) по разработке каркаса указанной программы и по выбору соотвествующих технологий?

Рассматриваются также варианты привлечения специалиста на временную или постоянную работу. Одно из основных требований — опыт проектирования и совершенное владение соответсвующими технологиями.

TYD>Очевидно, что программа контроля должна настраиваться скриптами.

Нет, не очевидно.

Здравствуйте, velkin, Вы писали:

V>Нет, не очевидно.

Не буду спорить. Просто для нас это очевидно. Есть некоторый практический опыт решения подобных задач, который убедил нас.

Если предложите хороший альтернативный вариант — с радостью выслушаю.

Здравствуйте, TYuD, Вы писали:

TYD>Имеется аппарат, состоящий из множества физических устройств. Устройства соединены в бортовую сеть с выходом на ПК. Для каждого устройства имеется программный модуль управления на ПК, реализованный в виде плагина (дочернего окна в MDI-приложении). Контроль аппарата производится в ручном режиме: через контролы плагинов подаются команды на физические устройства, ответы устройств также отображаются на плагинах.

TYD> Стоит задача сделать контроль аппарата автоматическим (автоматизированным). Поскольку подобных проектов (различных аппаратов) предполагается много, задача усложняется. Нужно разработать каркас (архитектуру) программы контроля (речь идет только о программе на ПК), пригодный для многократного повторного использования в разных проектах. Отсюда требования к гибкости, наращиваемости и пр. Очевидно, что программа контроля должна настраиваться скриптами. Выглядит привлекательным использование Qt+Python, хотя не обязатально.

TYD> Где можно получить детальную консультацию (в том числе платную) по разработке каркаса указанной программы и по выбору соотвествующих технологий?

TYD> Рассматриваются также варианты привлечения специалиста на временную или постоянную работу. Одно из основных требований — опыт проектирования и совершенное владение соответсвующими технологиями.

Пусть каждый плагин регистрирует все свои параметры (на чтение, на запись, на запись/чтение) на хосте. Дальше уже можно отдельным плагином оформить запрос необходимых параметров из хоста и работать с ним по нужному алгоритму.

Здравствуйте, 13akaEagle, Вы писали:

E>Пусть каждый плагин регистрирует все свои параметры (на чтение, на запись, на запись/чтение) на хосте. Дальше уже можно отдельным плагином оформить запрос необходимых параметров из хоста и работать с ним по нужному алгоритму.

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

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

Раньше эту последовательность осуществлял оператор. Сейчас нужен автомат. Причем такой, чтобы его легко можно было налаживать/подстраивать. Для этого хотим скрипты использовать (чтобы не компилить каждый раз и не раздражать заказчика).

Вообще-то, имеется представление как нужно делать, но плохо ориентируюсь какие использовать технологии. Например, Qt с его встроенным JS или Python+PySide и т.п.

Здравствуйте, TYuD, Вы писали:

TYD>Имеется аппарат, состоящий из множества физических устройств. Устройства соединены в бортовую сеть с выходом на ПК. Для каждого устройства имеется программный модуль управления на ПК, реализованный в виде плагина (дочернего окна в MDI-приложении). Контроль аппарата производится в ручном режиме: через контролы плагинов подаются команды на физические устройства, ответы устройств также отображаются на плагинах.

Есть такая технология. Обращайся. Поговорим. Скайп batu1955

TYD>Не буду спорить. Просто для нас это очевидно. Есть некоторый практический опыт решения подобных задач, который убедил нас.

Я так понимаю:
1. Вы хотите сделать парсер некоторого скрипта или взять готовое решение. После парсинга скрипта создавать некую программу в программном контроллере.
2. Создать плагины в которых есть интерфейс ввода/вывода массивов цифровых/аналоговых сигналов оборудования.
3. С помощью программного контроллера управлять через эти плагины устройствами.

Кстати, не забывайте, что есть ещё такой модуль QtScript.
Через метаобъектную систему qt сможете на лету перконфигурировать систему.

TYD>Если предложите хороший альтернативный вариант — с радостью выслушаю.

Но на мой взгляд всё это не совсем рационально. Причём дело именно в гибкости и наращиваемости. Хотя наверное как начальный вариант вполне подойдёт.

У меня, к примеру, есть ещё такое требование, как сверхгибкость без накладных расходов на программирование, и неограниченная наращиваемость.

Здравствуйте, velkin, Вы писали:

V>У меня, к примеру, есть ещё такое требование, как сверхгибкость без накладных расходов на программирование, и неограниченная наращиваемость.
У тебя это где? Лично у тебя или проект такой есть.

Здравствуйте, batu, Вы писали:

B>Здравствуйте, velkin, Вы писали:

V>>У меня, к примеру, есть ещё такое требование, как сверхгибкость без накладных расходов на программирование, и неограниченная наращиваемость.
B>У тебя это где? Лично у тебя или проект такой есть.

Лично у меня. Проект такой есть.

Здравствуйте, velkin, Вы писали:

V>Здравствуйте, batu, Вы писали:

B>>Здравствуйте, velkin, Вы писали:

V>>>У меня, к примеру, есть ещё такое требование, как сверхгибкость без накладных расходов на программирование, и неограниченная наращиваемость.
B>>У тебя это где? Лично у тебя или проект такой есть.

V>Лично у меня. Проект такой есть.
И у меня есть.. Такой. Только я сам себе его придумал. Вернее придумалось

Здравствуйте, velkin, Вы писали:

V>Кстати, не забывайте, что есть ещё такой модуль QtScript.
V>Через метаобъектную систему qt сможете на лету перконфигурировать систему.

Именно через QtScript сделан один из прототипов системы, которую нам делали когда-то контрагенты. Технология заманчивая, но кривовато как-то они сделали программу. Обратился, чтобы усовершенствовали ее, но они сейчас поуши в другом проекте. Они же и порекомендовали посмотреть в сторону Питона. Говорят проще, мощнее, перспективнее...

В QtScript, сказали, одна из проблема в том, что используемый там JS не умеет работать с битовыми полями. Они как-то через ДЛЛки лепили и пр.

V>Я так понимаю:
V>1. Вы хотите сделать парсер некоторого скрипта или взять готовое решение. После парсинга скрипта создавать некую программу в программном контроллере.
V>2. Создать плагины в которых есть интерфейс ввода/вывода массивов цифровых/аналоговых сигналов оборудования.
V>3. С помощью программного контроллера управлять через эти плагины устройствами.

В общем что-то похожее. Только бы с терминологией разобраться, например, что такое 'программный контроллер'.

V>Но на мой взгляд всё это не совсем рационально. Причём дело именно в гибкости и наращиваемости. Хотя наверное как начальный вариант вполне подойдёт.
V>У меня, к примеру, есть ещё такое требование, как сверхгибкость без накладных расходов на программирование, и неограниченная наращиваемость.

Если будет "сверхгибкость без накладных расходов на программирование, и неограниченная наращиваемость", то я буду только рад. Хотя в жизни так не бывает, наверное. В чем суть Вашей технологии?

Между прочим, с плагинами очень неплохо работает все это хозяйство (имею ввиду имеющийся сейчас ручной режим, а не автоматический, который только планируем). Дело в том, что некоторые физ. устройства нам поставляют контрагенты вместе с плагинами, которые сами же и пишут. Мы им даем программу-оболочку (с главным окном MDI) со всякими там драйверами, они пишут плагин, с его помощью автономно отрабатывают устройство и передают нам. Мы берем ихнее устройство, ихний плагин и проводим входной контроль. Все это легко интегрируется в систему со многоими устройствами (конфигурируется ini-файлами).

Поскольку, плагины — это обычная ДЛЛка, то каждый контрагент лепит ее с использованием любой технологии (кто Qt, кто Билдер и пр). Т.е. мы не связываем особо им руки, но все это легко, как конструктор, собирается в одну кучу без всяких перекомпиляций.

Кстати, хотелось бы, чтобы была преемственность, т.е. чтобы старые плагины использовать без изменений. Их уже целый ворох накопился.

TYD>Если будет "сверхгибкость без накладных расходов на программирование, и неограниченная наращиваемость", то я буду только рад. Хотя в жизни так не бывает, наверное. В чем суть Вашей технологии?

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

Для примера, взять тот же Microsoft COM, да, он позволяет кое-что создавать, но какими невероятными усилиями. Опять же жёсткая заточенность под Windows.

TYD>Между прочим, с плагинами очень неплохо работает все это хозяйство (имею ввиду имеющийся сейчас ручной режим, а не автоматический, который только планируем). Дело в том, что некоторые физ. устройства нам поставляют контрагенты вместе с плагинами, которые сами же и пишут. Мы им даем программу-оболочку (с главным окном MDI) со всякими там драйверами, они пишут плагин, с его помощью автономно отрабатывают устройство и передают нам. Мы берем ихнее устройство, ихний плагин и проводим входной контроль. Все это легко интегрируется в систему со многоими устройствами (конфигурируется ini-файлами).

TYD>Поскольку, плагины — это обычная ДЛЛка, то каждый контрагент лепит ее с использованием любой технологии (кто Qt, кто Билдер и пр). Т.е. мы не связываем особо им руки, но все это легко, как конструктор, собирается в одну кучу без всяких перекомпиляций.

TYD>Кстати, хотелось бы, чтобы была преемственность, т.е. чтобы старые плагины использовать без изменений. Их уже целый ворох накопился.

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

Здравствуйте, velkin, Вы писали:

V>Не назвал бы это технологией, так как в разработке, хотя вышеуказанные цели достигнуты, но это только начало. Суть в том, что есть возможность получать из плагинов любое количество функциональности. Причём у меня ещё существуют некоторые требования. Одно из них чтобы плагинизацию мог выполнить новичок в программировании, то есть концепция архитектуры и её реализация должна быть очень простой. Это важно, так как в моих более ранних архитектурных опытах чаще всего программные системы переусложнялись, то есть за гибкость приходилось платить очень сильно, и она ещё к тому же было недостаточна, а если откровенно, чаще вредна, чем полезна.

У нас близкие взгляды на проблему. Но меня не в меньшей степени интересует используемый инструментарий. QtScript?

Я послал Вам сообщение в личку.

Здравствуйте, TYuD, Вы писали:
TYD> Стоит задача сделать контроль аппарата автоматическим (автоматизированным). Поскольку подобных проектов (различных аппаратов) предполагается много, задача усложняется. ми технологиями.
SCADA?

Здравствуйте, TYuD, Вы писали:

TYD>Если правильно понял, плагины накидали нам кучу информации, а отдельный модуль ее анализирует (абстрагировавшись от всяких сетей, драйверов и пр.).

TYD>Хорошая мысль, что-то похожее и у нас варится. Проблема в том, что данные не только анализируются. Их нужно еще сформировать по каким-то циклограммам. Плагины в соответствии с циклограммами должны посылать запросы/команды соответствующим физ. устройствам. Причем запросы к разным устройствам взаимосвязаны. Например, одно устройство включает питание; другое устройство анализирует напряжение и потребление тока; после устаканивания питания третье устройство осуществляет какое-то действие и т.д.

TYD>Раньше эту последовательность осуществлял оператор. Сейчас нужен автомат. Причем такой, чтобы его легко можно было налаживать/подстраивать. Для этого хотим скрипты использовать (чтобы не компилить каждый раз и не раздражать заказчика).

TYD>Вообще-то, имеется представление как нужно делать, но плохо ориентируюсь какие использовать технологии. Например, Qt с его встроенным JS или Python+PySide и т.п.

По примеру OPC и т.д. интеграционных серверов:
Хост должен иметь перечень не просто параметров, а контейнеров для параметра. Без изменения уже существующих плагинов тут конечно уже не обойтись.
Хост регистрирует значения, создавая их контейнеры в своём кеше. На изменения значений можно подписываться, отписываться. При помощи boost.python можно создать модуль питона, импортируя в питоне можно получить уже ссылку на контейнер параметров. Плагин подгружает питон, подпихиваем ему необходимый скрипт, скрипт подгружает нужный модуль обёртки контейнера, а обёртка контейнера каким-то образом получает ссылку на контейнер хоста(вот тут я думаю может быть много способов, но я не занимался подобным, поэтому не подскажу).
В данном случае скрипт плагина может изменять любые параметры хостового контейнера и соответственно воздействовать на всю систему.
Вот такие записки дилетанта.

Здравствуйте, C.A.B, Вы писали:
CAB>SCADA?

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

В Java-мире это можно сделать, например, так:
1. Ядро системы — модульная архитектура на базе контейнера OSGi (Equinox подойдет). Интерфейс можно реализовать любой: хотите, веб, хотите, SWT, хотите, Swing. Соответственно, работать это будет на любой платформе — Windows, Mac, Linux.
2. Отдельные плагины для разных устройств. Если подключение по TCP — вообще отлично. Если нет, пара нативных библиотек решит проблему.
3. Кастомизация легко реализуется на Groovy или JavaScript (в Java есть встроенные средства для скриптинга).

Плюсы: высокая скорость разработки, очень зрелая платформа, гибкое, масштабируемое и высокопроизводительное решение.
Минусы: если до этого делали на Qt+Python, то придется подучить Java

Здравствуйте, 13akaEagle, Вы писали:

E>По примеру OPC и т.д. интеграционных серверов:
E>Хост должен иметь перечень не просто параметров, а контейнеров для параметра. Без изменения уже существующих плагинов тут конечно уже не обойтись.
E>Хост регистрирует значения, создавая их контейнеры в своём кеше. На изменения значений можно подписываться, отписываться. При помощи boost.python можно создать модуль питона, импортируя в питоне можно получить уже ссылку на контейнер параметров. Плагин подгружает питон, подпихиваем ему необходимый скрипт, скрипт подгружает нужный модуль обёртки контейнера, а обёртка контейнера каким-то образом получает ссылку на контейнер хоста(вот тут я думаю может быть много способов, но я не занимался подобным, поэтому не подскажу).
E>В данном случае скрипт плагина может изменять любые параметры хостового контейнера и соответственно воздействовать на всю систему.
E>Вот такие записки дилетанта.

С хостом все проще. Все данные варятся на одном ПК, в одной программе и даже м.б. в одном потоке. Поэтому задача, как подписаться, как получить ссылку на источник рассылки и пр. решается просто. Не могу пока определиться со стеком технологий. То ли главная программа на Питоне с привелечением PySide, то ли главная на Qt c его QtScript...

А вот про boost.python и пр... можно ли поточнее ссылку или пример.

Здравствуйте, Baudolino, Вы писали:

B>Плюсы: высокая скорость разработки, очень зрелая платформа, гибкое, масштабируемое и высокопроизводительное решение.
B>Минусы: если до этого делали на Qt+Python, то придется подучить Java

Да Java мне нравится, но никогда с ней не возился. Мы сильно привязаны к С++, т.к. бортовые вычислители толкько на нем или на Ассемблере. Поэтому Qt ближе, хотя его тоже придется осваивать... А еще мне казалось, что Явовские продукты тормозят. Питон тоже тормоз.

Здравствуйте, Baudolino, Вы писали:

B>1. Ядро системы — модульная архитектура на базе контейнера OSGi (Equinox подойдет).

Там привязки внешних библиотек есть наверняка? Чтобы контрагентов не переучивать на Яву...

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