AlexHell, проблем очень много. Если ничего не делать, то они и не решатся сами собой. Возможно я ничего не добьюсь в этом направлении. По большому счету это не важно. "Делай, что должен, и будь, что будет". Всю жизнь так работаем. Глаза боятся, а руки делают. И многое удается. Если не внедрим мидлвэр в отрасли, то у себя уж точно запустим, если он окажется стоящим.
Поэтому, несмотря на все страхи, не отношусь пессимистично к этой затее. Были бы решения правильные приняты и проверены, а дальше можно будет пробивать. За время работы связи появились очень большие. Но пока сам не готов концептуально. Точнее, в общих чертах все понятно, но в деталях не нахожу красивых решений. Вот, например, с flatbuffers
Во-первых проект еще не начался. Назревает. Во-вторых, мы не головники. Не можем диктовать. А в третьих, и это главное, где вы видели у нас много специалистов? Команды есть, но специфические. Как в Союзе. Даже хуже. На сто чиновников один специалист. В ряде направлений ситуация доходит до того, что один-два человека на всю страну владеют технологией. И им, как правило, за 70.
Чтобы было нагляднее скажу, что всю математику и все ПО для упомянутого мною аппарата разработал один человек. Хотя вокруг крутились сотни каких-то чиновников.
И еще пример. Считается, что разработка математики и ПО ничего не стоит. Оно как-то само собой появляется. Ресурсов не требует. Главное железяку выточить.
Все руководство, включая главных конструкторов, некомпетентно. Это чиновники. Попробуйте им объяснить, что такое мидлвэрэ. Что оно очень важно, надо много сил затратить... Он сделает круглые глаза и скажет: "Но ведь делают же без этого! А когда сделаете, то как его пощупать?" Попробуйте объяснить это, например, полковнику полиции.
Неужели вам не знакома картина? Сплошь и рядом.
Между прочим у Боинга подобная ситуация в космонавтике. Чтобы что-то небольшое изменить - сумасшедшие миллиарды государство должно потратить. Такой себе монстр-монополист. Как при социализме. Не зря у них правительство Маска продвигает. С огромным трудом, между прочим. Хотят конкурентный рынок создать. Но там правительство хоть понимает, что нужно делать! Они дельцы. Деньги умеют считать.
Ну и подобная мидлвэрэ не такая уж простая задача, чтобы вечерком ее решить. Амеры лет 15 возились с ней, прежде чем выйти на стандарт. Причем очень серьезные фирмы и ресурсы задействовались. Поинтересуйтесь про историю модернизации крейсеров Тикандерога.
Я сейчас не занимаюсь разработкой такого мидлвэра. И не понятно буду ли. Просто наблюдаю провал в отрасли. Хочу для себя оценить задачу, найти правильные идеи, решения. Концептуально. Когда все сложится в голове. Можно будет пробивать пытаться.
Мой вопрос в ветке - это один из огромного множества. Форумы не помогают особо. В идеале нужна консультация со спецами. И не одна. Ищу таких людей
AlexHell: "можете же специально для своей архитектуры сделать свою сериализацию только нужных вам структур..."
Собственно, так и было сделано. Мы взяли в качестве стандарта структуры С/С++ и ими описали сообщения в сети между абонентами. Придумали правила, формирования структур, чтобы было одинаковое выравнивание на разных архитектурах (на 16-ти и на 32-разрядных контроллерах/процессорах).
Этого вполне хватало, пока мы работали в рамках одного проекта (назовем это беспилотником, на борту которого около десятка процессоров и пара десятков контроллеров). Мы, как головники, определили общие правила (стандарт) сети, а для каждого абонента - свой вход/выход в виде структур на С/С++. Контрагентов поставили перед фактом в виде ТЗ, и они его вынуждены отрабатывать. К тому же все программы для таких задач (эмбэд) пишутся на С/С++. Пару таких машин довели до серийного производства. Все прекрасно.
Но вот встали задачи пошире. Задача уровня носителя подобных беспилотников (на два порядка масштабнее система) и взаимодействия разнородных беспилотников между собой и с носителями. Т. е. много разных команд разработчиков, разных технологий, разных школ. Дикая каша получается. Всех заставить плясать под одну дудку не получается. Да и дудка наша (упоминавшийся выше подход) оказалась не вполне универсальной для новой задачи и мы не головники.
Каша технологий не позволяет увязывать между собой различные аппараты и подсистемы. А сейчас основные дивиденды получаются именно в сетецентрических системах, где взаимодействует множество разнородных изделий.
У нас тупиковая ситуация получается: каждый разработчик лепит так, как ему нравится, как привык. И отвечает только за свою частную задачу. Системные задачи, которые по своей сути везде одинаковые, решаются каждым разработчиком по разному (изобретается велосипед). Лепить в одну систему такие устройства невозможно. Разработка затягивается на десятилетия, а модернизационный потенциал никакой. Чтобы новую функцию (подсистему) добавить нужно перепроектировать все заново.
Американы лет 20 назад решили для себя эту проблему, внедрив единый обязательный стандарт DDS. Т.н. middleware, которое работает поверх разных физических коммуникаций, поверх разных ОС, на разных языках программирования. Один из камней в фундаменте DDS - язык IDL описания данных, передаваемых по сети (причем без вызова удаленных процедур, просто данные).
Казалось бы что проще - описать структуру данных на неком абстрактном языке, которую потом транслировать в нужный язык программирования. Но это превращается в такого монстра! От С они вообще отказались. На С++ во всю используют STL, которая практически не используется в системах реального времени (из-за тяжеловестности и низкой скорости), не говоря уже о микроконтроллерах. Короче, как я понял, DDS для тяжелых ОС типа Линукса и пр.
Хочется чего-то легкого. Но, к своему удивлению, не нашел подходящего. Больше всего привлек flatbuffers. У них есть даже компилятор в С (не в С++). Но они рассматривают, похоже, только настольные системы, о чем я писал в первом посте.
Короче, я вижу колоссальную (я бы сказал даже экзестенциальную) необходимость в middleware для интеграции систем реального времени. И первым кирпичом в ней вижу язык описания данных (с соответсвующими компиляторами под С, С++, Java и пр.).
Хочется, чтобы язык был простым и легким. Чтобы на микроконтроллерах можно было использовать.
Смотрел на GitHub немного FlatCC - компилятор для С (хотелось бы, чтобы сериализатор работал в том числе и на контроллерах, где нет STL). Как я понял, они достигают быстродействие сериализации благодаря тому, что не упаковывают/распаковывают данные, а передают структуры, как есть, т.е. с естественным выравниванием структур (с дырками). Доступ к полям обеспечивают простым смещением указателя. Так понял, что на разных языках структуры данных выравниваются одинаково. Они этим и пользуются. Но правила выравнивания ориентированы на х86, где есть адресация по байтам (точнее по 8-битам, т.к. байт может состоять из другого количества бит). Это значит, что в других системах (где адресация другая или бигэндиан) придется таки переупаковывать и терять производительность.
Ну ладно бы с производительностью.. Я бы пошел на это, если бы был сериализатор готовым. Но их FlatCC не умеет этого. Например, разработчики сильно удивились, что в некоторых компиляторах нет типа int8_t, а только int16_t или даже int32_t и выше. А у них все заточено на int8_t. Мне же предложили самому все закодить, написать документацию и вступить в их ряды. Но у меня нет ресурсов для этого. Нужно готовое решение. Кстати ветку с нашим обсуждением они быстро закрыли.
Подобных технологий сейчас много. В этом тоже часть проблемы. Какая лучше подойдет? За какую браться? Много критериев и тонкостей. Все в постах не напишешь, не обговоришь.
Что касается .NET, то смущают вопросы с переносимостью. У нас предполагаются встариваемые варианты проверочной аппаратуры (линуксы и пр.). Да и тяжеловесными кажутся продукты макрософта.
Все протоклы и драйверы нашей разработки, в этом смысле их можно считать полностью открытыми. Дисциплина сетевого обмена проста, надежна и отработана. В это даже влазить не нужно. API у каждого из физических устройств специфичны, но общее правило одинаково: все команды упаковуются в бинарное сообщение в виде флагов/полей и пр., ответ устройства также приходит в виде структурированного бинарного сообщения (датацентрическая организация взаимодействия - никаких удаленных процедур и пр.). Последнее обстоятельство очень упрощает задачу - можно абстрагироваться от способа обмена, конфигурации сети и пр. Можно сконцентрироваться только на обработке прикладных данных на ПК.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
Поэтому, несмотря на все страхи, не отношусь пессимистично к этой затее. Были бы решения правильные приняты и проверены, а дальше можно будет пробивать. За время работы связи появились очень большие. Но пока сам не готов концептуально. Точнее, в общих чертах все понятно, но в деталях не нахожу красивых решений. Вот, например, с flatbuffers