Средства и методы разработки

Самоконфигурирующаяся система. Навеяно "умными домами" ->. Которые в реальности "тупы, как два сибирских валенка вместе". http://caxapa.ru/559384.html
Пусть есть центральный контроллер. К которому по некоторым каналу(ам) подключены периферийные модули. Канал связи имеет 3 режима 1) назначить адреса и определить сетевую конфигурацию 2) получить идентификационный string с каждого 3) индивидуальная работа с модулем согласно его свойствам. Первые 2 стандарты и совместимы. Контроллер читает string модуля и шлет его в облако. Производитель модуля шлут туда же некий универсальный драйвер модуля, написанный на каком-то managed коде. Какое-нибудь подмножество С|С++ (без стандартной либы, буста и прочего). Есть объектная иерархическая модель всего. И код производителя модуля - это код методов для конкретного свойства модуля, чтобы привести все модули к единому виду. Далее у нас в облаке происходит сборка прошивки управляющего контроллера. Код собирается из предварительно настроенных и отконфигурированных кусочков ОСи, VM, описанных выше "протодрайверов" и проч. Потом на контроллера запускается управляющая программа, например, в виртуальной машине, которая делает целевую юзеровскую функциональность. Что имеем в +: * максимальную гибкость в плане модулей и совместимости (при достаточной универсальности и гибкости протокола канала) самых разных версий как модулей, так и контроллеров и ОСей контроллеров * Разумный расход ресурсов контроллера. Как все хорошо знают на примере Android, засрать 4 ядра по 2 гига и гиг оперативки для современных методов разработки ПО - плевое дело. * Полный контроль за юзером и производителями модулей - без облака они никуда. Как следствие, капитализация каждого юзера и каждого поставщика моделей в нашу пользу * Возможность формальной верификации кода "протодрайверов" (а ля MISRA), чтобы туда не заложили лишнего. Критика?