Разработка каркаса и выбор технологии для автоматизированного контроля аппарата?

Question

[Юрий]

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

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

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

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

Answer 1

[xmoonlight]

Вариантов много. Зависит от того, как физически происходит взаимодействие и открыт ли протокол (документация), есть ли API/SDK и для какой платформы.

Comments

[Юрий]

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

Answer 2

[Павел Осадчук]

Если бы вы рассматриваете C# и .NET то там есть "расширяемость" и "модульность" из коробки. Называется Managed Extensibility Framework (MEF).
Например мы его используем для сервиса опроса оборудования, когда возникает новое устройство, пишется отдельная сборка реализующая интерфейс

interface IDeviceControllerPlugin : IControllerPlugin

и вызывающая событие

event EventHandler<DataPacketEventArgs> OnDataPacket;

которое уже обрабатывается в самом сервисе.

Добавление нового модуля осуществляется путем бросания его в папку с программой и перезапуском. И повторюсь - все это доступно как часть .NET

Comments

[Юрий]

Подобных технологий сейчас много. В этом тоже часть проблемы. Какая лучше подойдет? За какую браться? Много критериев и тонкостей. Все в постах не напишешь, не обговоришь. Что касается .NET, то смущают вопросы с переносимостью. У нас предполагаются встариваемые варианты проверочной аппаратуры (линуксы и пр.). Да и тяжеловесными кажутся продукты макрософта.