Comments 35
Кажется, текст статьи не совсем раскрывает то, что обозначено в её заголовке, в особенности в первом слове заголовка... Может, чуть-чуть подредактировать то или другое?
Звучит интересно, удачи в реализации. Насчёт кода кажется вы могли бы использовать С++20 штуки для измерения времени(вместо простых чисел в math constants) и кажется с таким количеством интерфейсов(virtual) можно было бы подумать про стирание типов вместо обычного подхода с виртуальными функциями
Не совсем понятны некоторые утверждения. Например, что при предлагаемой логике будет понятно как будет приниматься КА. Так это известно всегда - есть ТЗ и заказчик принимает изделие сверяясь с каждой запятой этого ТЗ. И программы-методики отработки создаются исходя из необходимости подтверждения каждого пункта ТЗ. Затем, про аналогию с беспилотниками. Что беспилотник может делать самостоятельно, без команд с земли?
Про ТЗ: это в идеальном мире, где и подрядчик и заказчик знаете все-все. В реальной космической отрасли сильно иначе. К сожалению, не редка ситуация, что те, кто делают модельный расчет для разработки конструкции, закладываются на такой тип управления, который земля не может обеспечить либо в принципе, либо без существенной переделки.
Второй момент: беспилотники могут парировать много нештатных ситуаций: от отказа одного из приборов, до нивелирования ряда факторов. И да, беспилотники бывают тоже разные: от крылатых ракет до глубоководных аппаратов.
Может разговор про коммерческие спутники. То, что идет как госзаказ, ТЗ для заказчика это Библия. По крайней мере для носителей. А насчет моделей, так это зависит от исполнителей, а не от принятой системы проектирования. Вон, когда не учли азимут космодрома, выяснилось, что полезная нагрузка моделировалась как материальная трчка, а не как трехмеоный объект. Ну так сами себе злобные буратины.
Про парирование отказов. Еще полвека назад это существовало в боевых ракетах. Велся постоянный контроль исправности оборудования (на основе мажоритара), забракованный прибор или пытались восстановить перезапуском, или отключали из контура управления, либо переходили на упрощенный алгоритм управления. Если этого нет в современных спутниках, то можно только посочувствовать.
Такое, естественно есть, но вот в чем дело: ракете с неисправным прибором лететь недолго, да и задача всего одна, как-никак выполнить можно. А вот спутнику нужно жить долго и решать много задач. То что вы описывает упрощенной режим управления у нас это переход в безопасный режим. Но во многих ситуациях борт может сам проанализировать причину сбоя и выйти из безопасного режима и выполнить-таки задачу
Кстати, есди я правидьно понял, то смысл вашей идеи в формализации обратной связи. От результатов испытаний и экспдуатации до исходной модели.
Не скажу, что это идея, скорее это желание
Удалено.Промазал с веткой
Что можно сказать: разработка Rust ведется гораздо более централизовано чем C++.
Пожалуй, это так, но скорее по историческим причинам. Rust Foundation — это такой же конгломерат, а не единая организация (например, как Microsoft развивающий C# или Swift который разрабатывает Apple).
Насчёт компиляторов: предлагаю посмотреть на gccrs. Пока ещё не готов к использованию, но процесс идёт.
Когда я в последний щупал дизель, то там были определённые сложности с написанием кода не привязанного к конкретной базе. Вроде невозможности использовать UUID с SQLLite. Да, нативной этот тип базой не поддерживается, но библиотека могла бы абстрагировать этот момент, но разработчики принципиально не хотят это делать.
Кстати, вижу, что sqlx набирает популярность. Предлагаю рассмотреть эту библиотеку.
Azul тоже не единственная имеющаяся библиотека для пользовательского интерфейса. К сожалению, все они не совсем (или совсем не) уровня Qt. Но развиваются, может со временем станет лучше.
И все же rust foundation это организация где есть менеджеры, а есть разработчики, а сверху над все этим один бюджет. И тут ситуации серьезно отличается от плюсов.
Про gccrs знаю, но пока не выглядит серьезной альтернативой, т.к. этот тот же rustc, но обращающийся к ir gcc, вместо llvm. Поправьте, если не прав.
Не многие орм городят огород, если бд что-то не поддерживает, т.к. зачастую это слишком дорого по производительности.
Про sqlx спасибо, погляжу.
И все же rust foundation это организация где есть менеджеры, а есть разработчики, а сверху над все этим один бюджет.
Дык, участники/спонсоры foundation деньги не просто так заносят, а чтобы иметь влияние. Чем это принципиально отличается от плюсового комитета, где тоже участники вынуждены договариваться?
Про gccrs знаю, но пока не выглядит серьезной альтернативой, т.к. этот тот же rustc, но обращающийся к ir gcc, вместо llvm. Поправьте, если не прав.
Вопрос заставил задуматься. До этого воспринимал gccrs именно как альтернативный фронт-энд. Теперь прям интересно действительно ли переиспользуются какие-то части rustc. Ответ пока не знаю. Но даже если и да, но я всё-равно не навал бы это "тем же rustc".
В любом случае, сказать хотел скорее, что движение к "децентрализации" есть. Кстати, ещё есть cranelift/wasmtime.
Про gccrs знаю, но пока не выглядит серьезной альтернативой, т.к. этот тот же rustc, но обращающийся к ir gcc, вместо llvm. Поправьте, если не прав.
Всё-таки поправляю — есть два проекта:
- rustc_codegen_gcc — это как раз GCC бекенд для rustc.
- gcc-rs — это именно альтернатива rustc.
Статья о чем? Rust, Postgresql, sqlite c++,.. вам шашечки или ехать?
Прежде чем куда-то ехать надо оценить саму возможность приехать к цели.
Если вы читали внимательно статью, то я дал ссылку на минимальный проект, с которым уже можно взаимодействовать, но есть одно: он написан на C++. Это замечательный язык, я его очень люблю, но Rust обещает гораздо большую безопасность кода без потери производительности. Это очень важно, когда нету возможности обеспечить качество увеличением числа людей, работающих на данном участке.
Качества увеличением числа людей добиться не возможно, а переходом на другие средства разработки вы просто увеличите время на побочные работы, не связанные непосредственно с моделированием и управлением.
Ну как же: на одного разработчика поставить хотя бы одного тестировщика (грубо), то ясно что ошибок выгребаться будет больше (не забываем, что помимо моделей, нужно поддерживать "безошибочность" кода).
Rust это не средство, это язык разработки, который позволяет (в теории) уменьшить время на тестирование и исправление ошибок.
Вы рассматриваете только ошибки кодирования. Между тем, главным здесь является предмет математического моделирования, точность и адекватность математических моделей, выбор законов управления,.... принципы взаимодействия ММ различных компонентов системы (управляющие органы, модель аппарата как тонкостенной конструкции содержащей тела космонавтов, ...). И поскольку вы ни слова не сказали о моделировании короткого и длинного движения КА, мне представляется, что вы зря упомянули о ЛА и о том, что вы якобы 12 лет работали в космической отрасли (позвольте спросить, что вы там делали?)
Приведите пожалуйста список литературы, который вы изучили и по которому увидели/рассмотрели суть проблемы, которую собираетесь решать.
Как я собрался писать открытую библиотеку для разработки и управления спутниками