Ну то есть окей, не мне судить что важно а что нет, но есть ли какая-то логика почему именно этот продукт удостоен новости? Почему, например, нет новостей про минорные релизы Google Chrome? Этож сколько новостей можно написать-то...
Именно по этому Дракон отправляется с урезанным экипажем - двое вместо четверых. Так что риск будет только между моментом отстыковки старлайнера (планируется на 6 сентября) и пристыковкой Crew-9 (25 сентября), что, впрочем, тоже не хорошо.
Проблема не только в этом. У посетителей МКС (астронавтов, космонавтов и т.п.) должна быть возможность экстренной эвакуации. Если Старлайнер отправляется в беспилотном режиме, астронавты остаются на МКС без пути отхода - ведь на оставшихся кораблях места не хватит. Не спичку же тянуть...
Это одна из причин по которой в НАСА до сих пор не определились. Наряду с проблемой того что сбойный сервисный модуль сгорит в атмосфере, а значит расследование причин отказа усложняется значительно - на Земле же походу не воспроизвели.
Я не знаю как у вас, но у меня чаще всего бывало так, что довольно значительная часть кода проекта собственно с железом никак не связанна. Например какой-нибудь тестовый стенд собирает данные, сохраняет отчет на флешку. То как он соберет данные это важно, тут никаких вопросов, но вот отлаживать сохранялку в файл прямо на микроконтроллере откровенно запарно. Или коммуникация - работа с драйвером железозависима и не может не отрабатываться на нем, но форматы сообщений и протоколы высокого уровня очень удобно писать в платформонезависимом виде и проверять вот в таких вот эмуляциях. Железо в этом случае просто прячется за моком, сильно подробно копировать его поведение, в данном случае, не нужно, только проверять нужные тестовые сценарии.
При этом в такой модели разработки никто вам не запрещает подробную симуляцию железа и проверку непосредственно кода драйверов и других плохо изолируемых компонентов, тогда можно проводить действительно подробную верификацию софта в таких режимах, которые в железе повторять запарно или просто дорого. Это я собственно и имел ввиду под "любым удобным видом", хотите детализируете, хотите проверяйте только библиотеки которые могут быть платформонезависимы.
А зачем вам прямо эмулировать железо? Тут же задача в первую очередь подтвердить что софт работает так как должно, по крайней мере как я понимаю из статьи. По сути автор просто написал обертки для системных вызовов с тем же интерфейсом что и в rtos.
Такое очень полезно в больших проектах, чтоб автотесты бизнес-логики делать. Вот, например, в НАСА написана своя абстракция для этих целей - Operation system abstaction layer. Представляет собой библиотеку, статически изолирующую системные вызовы, предоставляя совместимый интерфейс. В рамках нее можно отрабатывать довольно сложное поведение систем прямо в линуксе, вообще без железа на столе. Поведение железа при этом эмулируется в любом удобном виде, а использование cmake позволяет в любой момент сменить тулчейн и использовать другой компилятор и другой код непосредственно разговаривающий с железкой. Довольно удобно
Чисто технически, разворачивание и сворачивание это разные операции, скорее всего нужны отдельные приводы для этого, такую массу тащить на орбиту незачем, а на земле можно свернуть внешними приводами. Ну и в целом - сведение и выведение это очень разные процессы по перегрузкам. Для понимания - большую часть времени при создании подобных систем занимает тестирование - т.е. дешевле новый сделать чем спустить этот и потом опять подготовить к запуску.
Вообще предусмотрены. Для возможной дозаправки добавлены соответствующие клапаны, пассивный стыковочный механизм (простейший, по сути интерфейс с РБ) тоже есть. Всерьез, правда, никто не планировал... Подробней можно почитать тут
Другое дело, что в отличие от Хаббла никакая разборка на орбите с заменой внутренних деталей невозможна - там обслуживание было полноценной фичей, Хаббл делался как ПН для Шаттла в первую очередь
На самом деле скорость столкновения может быть почти какой угодно. Мусор может быть и на не-круговой орбите и на наклоненной на 180 градусов относительно орбиты космонавта - вариантов не так уж и мало. А объекты на той же орбите опасности не представляют вообще - относительная скорость почти никакая. 7км\с это ведь относительно Земли, а не относительно космонавта
"Переход к новой "короткой" схеме стал возможен только с вводом в эксплуатацию ракеты-носителя "Союз-2.1а", позволяющей по своим техническим характеристикам и возможностям системы управления выводить космические объекты на заданную орбиту с высочайшей точностью. Также важной особенностью реализации двухвитковой схемы сближения со станцией является предварительное формирование требуемой рабочей орбиты МКС и точное выполнение заложенной в бортовой вычислительный комплекс транспортного корабля программы автономного наведения"
Вы так говорите как будто это фишка Союза (корабля) хотя это в большей степени обеспечено расчетом баллистики и минимизацией "зазора" запуска РН. Ну и тем фактом что наклонение МКС подобрано именно под Байконур, и не факт что с какого-либо другого космодрома, кроме реально экваториальных (а не просто близких, как Канаверал), можно делать выкрутасы с ловлей МКС за 1-2 витка.
Это было бы очень странно, ведь то что делает телескоп первое время это обзоры, а обзоры имеет смысл делать в наиболее широком спектре, т.е. обоими телескопами. Можно вот тут почитать https://habr.com/ru/post/508760/
Не удивлюсь, если немецкие инженеры, увидев, что творит их начальство, уже передали...
А потом сели мотать срок? У нас тут умудряются сесть и за журналистику в этой области, а "передать документацию по управлению" это несколько иной уровень
Срок активного существования у этого телескопа 6.5 лет, и несколько обзоров неба eROSITA уже собрала, так что мы не останемся совсем без ничего. Я думаю шанс на то что сотрудничество по фундаментальным наукам стабилизируется за следующие 3.5 года есть - ИТЕР же как-то продолжают строить. А шанс восстановить сломанный телескоп без знания как он устроен крайне низок. Включить они его наверное включат, но, как и во всем космическом - нет проблем с ситуацией когда все хорошо, главные проблемы возникают в ситуации когда хорошо не все, и вот режимы восстановления можно и не осилить.
Можно сколько угодно спорить о том стоило ли его выключать, фундаментальная наука она для всех. Но это дело тех, кто этим инструментом владеет. Впрочем, Роскосмосу не привыкать заниматься космическим пиратством.
Такие телескопы работают долгие годы - может лучше подождать пока отношения стабилизируются хоть чуть-чуть? С орбиты он никуда не денется, сломать всегда можно успеть, а чинить потом - как? Это не домашняя фотокамера с защитой от дурака, телескоп при неправильном обращении легко можно и спалить или, в лучшем случае, отправить в безопасный режим, а как его оттуда вытаскивать потом, методом тыка?
Желание даже всех ученых ЕКА недостаточно - нужна более конкретная информация о порядке восстановления и требуемых командах, а такую без явного и публичного разрешения никто не предоставит.
Это не то дело, которое "пробуют" - риск не оправдан, второго шанса может не быть.
Просто инженеры консервативны в оценках. Это как с марсоходами - гарантируют не меньше месяца работы, а караются потом годами сверх гарантированного срока.
Да и вообще, тут же речь про передовой научный инструмент! Большинство ключевых технологий в космосе в первый раз, было бы странно если бы предельные характеристики всех решений были точно известны заранее, ведь тогда бы он не был бы передовым, скорее рядовым, правильно?
Продлить ресурс конечно же можно, что-то можно поменять, что-то - просто перепроверить и уточнить ресурс, но это все равно дополнительные операции.
Все сильно зависит от аппарата. "Науке" не нужно было входить в атмосферу другой планеты на второй космической и мягко садиться. Некоторые модули "Казачка" вполне и не разборными могут быть, обслуживание-то не предполагалось.
У космических аппаратов все очень дорого, и потому очень точно рассчитано, считают даже километраж на дорогах - можно проехать не более N километров, иначе ресурс вибростойкости может пострадать слишком сильно, и аппарат может просто не пережить выведение. Предел по хранению может означать, например, предел стойкости конструктивных материалов к воздействию кислорода (в космосе и на Марсе с кислородом не оч, а значит можно использовать что-то более легкое, но менее стойкое к коррозии).
Пример с кислородом я взял из головы, но надеюсь идея понятна - необходимость оптимизировать конструкцию аппаратов до предела может вылезти в неожиданных местах.
Когда о таком говорят, то речь обычно не о близко расположенных участках, а об участках которые находятся буквально в одном здании. Причем если на таких участках мало наблюдателей, и они "правильные", то явка отличается на десятки процентов. Так же наблюдается интересная закономерность - чем выше на участке явка, тем более однообразно люди на участке голосуют - это и есть "хвост кометы", который объясняют вбросами. Собственно если отбрасывать все такие странные УИКи люди в нашей стане оказываются вполне себе однородными, по крайней мере без резких пиков на пустом месте.
Примеры были, выборы в дугих старанах, выборы РФ 2000
Выборы 2000 г
Явка в целом большая, но большая часть голосов, как ни удивительно, кучкуется в одной области. Посмотрим что было в 2016
2016
Чем больше людей приходит, тем более размазанным оказывается ядро.
График в статье тоже выглядит интересно, не нем можно заметить регулярную сетку в верхней части графика:
Самое забавное что это не ошибка - это крайне похоже на результат "подгона" на участков результатов под конкретный процент. Похожую сетку можно увидеть на голосовании за поправку:
2020, голосование за поправку
Не знаю как вам, а мне такой способ поиска проблем кажется вполне убедительным. И он показывает что в среднем результаты по стране вполне себе монотонные, пусть на вашем примере какие-то участки и будут выделяться, но на масштабах страны с большей вероятностью будут выделятся именно проблемные участки. К сожалению, по данным текущей детализации (участок-процент за каждый пункт) более точной картины (чтоб отличить действительно странные участки) построить нельзя. Более интересны в этом смысле результаты электронного голосования, там можно выделить каждый отдельный голос, и отделить время голосования (с определенной, пусть и загрубленной точностью). Но это уже другая история
И все же ее планируемая нагрузка на НОО составляет всего 70
Ошибки тут нет, скорее передёргивание фактов от автора. По первоначальному плану самая первая рабочая конфигурация sls будет способна закинуть на низкую орбиту как раз 70 тонн, эта конфигурация будет летать 1-2 раза (планы постоянно меняются). Block 1a уже сможет больше. Что интересно, информацию о 70 тоннах я смог найти только забитую в различные уголки на английской Вики и паре зарубежных сайтов, так что возможно планы изменились, и теперь реально с первого раза будет по 95т.
Я наверное чего-то не понимаю, но зачем писать на технический ресурс новости о минорном релизе просмотрщика изображений?
3.1.3 - https://habr.com/ru/news/913042/ - 27 мая
3.1.4 - https://habr.com/ru/news/920432/ - 21 июня
и теперь 3.1.5 - 16 июля.
Ну то есть окей, не мне судить что важно а что нет, но есть ли какая-то логика почему именно этот продукт удостоен новости? Почему, например, нет новостей про минорные релизы Google Chrome? Этож сколько новостей можно написать-то...
А кто-нибудь знает существует ли еще smd-taxi ? Сайт у них не особо обновляется, но по крайней мере это был установщик реально местной сборки
Именно по этому Дракон отправляется с урезанным экипажем - двое вместо четверых. Так что риск будет только между моментом отстыковки старлайнера (планируется на 6 сентября) и пристыковкой Crew-9 (25 сентября), что, впрочем, тоже не хорошо.
Проблема не только в этом. У посетителей МКС (астронавтов, космонавтов и т.п.) должна быть возможность экстренной эвакуации. Если Старлайнер отправляется в беспилотном режиме, астронавты остаются на МКС без пути отхода - ведь на оставшихся кораблях места не хватит. Не спичку же тянуть...
Это одна из причин по которой в НАСА до сих пор не определились. Наряду с проблемой того что сбойный сервисный модуль сгорит в атмосфере, а значит расследование причин отказа усложняется значительно - на Земле же походу не воспроизвели.
Я не знаю как у вас, но у меня чаще всего бывало так, что довольно значительная часть кода проекта собственно с железом никак не связанна. Например какой-нибудь тестовый стенд собирает данные, сохраняет отчет на флешку. То как он соберет данные это важно, тут никаких вопросов, но вот отлаживать сохранялку в файл прямо на микроконтроллере откровенно запарно. Или коммуникация - работа с драйвером железозависима и не может не отрабатываться на нем, но форматы сообщений и протоколы высокого уровня очень удобно писать в платформонезависимом виде и проверять вот в таких вот эмуляциях. Железо в этом случае просто прячется за моком, сильно подробно копировать его поведение, в данном случае, не нужно, только проверять нужные тестовые сценарии.
При этом в такой модели разработки никто вам не запрещает подробную симуляцию железа и проверку непосредственно кода драйверов и других плохо изолируемых компонентов, тогда можно проводить действительно подробную верификацию софта в таких режимах, которые в железе повторять запарно или просто дорого. Это я собственно и имел ввиду под "любым удобным видом", хотите детализируете, хотите проверяйте только библиотеки которые могут быть платформонезависимы.
А зачем вам прямо эмулировать железо? Тут же задача в первую очередь подтвердить что софт работает так как должно, по крайней мере как я понимаю из статьи. По сути автор просто написал обертки для системных вызовов с тем же интерфейсом что и в rtos.
Такое очень полезно в больших проектах, чтоб автотесты бизнес-логики делать. Вот, например, в НАСА написана своя абстракция для этих целей - Operation system abstaction layer. Представляет собой библиотеку, статически изолирующую системные вызовы, предоставляя совместимый интерфейс. В рамках нее можно отрабатывать довольно сложное поведение систем прямо в линуксе, вообще без железа на столе. Поведение железа при этом эмулируется в любом удобном виде, а использование cmake позволяет в любой момент сменить тулчейн и использовать другой компилятор и другой код непосредственно разговаривающий с железкой. Довольно удобно
Чисто технически, разворачивание и сворачивание это разные операции, скорее всего нужны отдельные приводы для этого, такую массу тащить на орбиту незачем, а на земле можно свернуть внешними приводами. Ну и в целом - сведение и выведение это очень разные процессы по перегрузкам. Для понимания - большую часть времени при создании подобных систем занимает тестирование - т.е. дешевле новый сделать чем спустить этот и потом опять подготовить к запуску.
Вообще предусмотрены. Для возможной дозаправки добавлены соответствующие клапаны, пассивный стыковочный механизм (простейший, по сути интерфейс с РБ) тоже есть. Всерьез, правда, никто не планировал... Подробней можно почитать тут
Другое дело, что в отличие от Хаббла никакая разборка на орбите с заменой внутренних деталей невозможна - там обслуживание было полноценной фичей, Хаббл делался как ПН для Шаттла в первую очередь
На самом деле скорость столкновения может быть почти какой угодно. Мусор может быть и на не-круговой орбите и на наклоненной на 180 градусов относительно орбиты космонавта - вариантов не так уж и мало. А объекты на той же орбите опасности не представляют вообще - относительная скорость почти никакая. 7км\с это ведь относительно Земли, а не относительно космонавта
https://tass.ru/kosmos/5360378
Уж не знаю зачем это конкретно, я не настоящий сварщик, видимо не всякая возможная орбита МКС подходит для быстрой схемы
Вы так говорите как будто это фишка Союза (корабля) хотя это в большей степени обеспечено расчетом баллистики и минимизацией "зазора" запуска РН. Ну и тем фактом что наклонение МКС подобрано именно под Байконур, и не факт что с какого-либо другого космодрома, кроме реально экваториальных (а не просто близких, как Канаверал), можно делать выкрутасы с ловлей МКС за 1-2 витка.
Это было бы очень странно, ведь то что делает телескоп первое время это обзоры, а обзоры имеет смысл делать в наиболее широком спектре, т.е. обоими телескопами. Можно вот тут почитать https://habr.com/ru/post/508760/
А потом сели мотать срок? У нас тут умудряются сесть и за журналистику в этой области, а "передать документацию по управлению" это несколько иной уровень
Срок активного существования у этого телескопа 6.5 лет, и несколько обзоров неба eROSITA уже собрала, так что мы не останемся совсем без ничего. Я думаю шанс на то что сотрудничество по фундаментальным наукам стабилизируется за следующие 3.5 года есть - ИТЕР же как-то продолжают строить. А шанс восстановить сломанный телескоп без знания как он устроен крайне низок. Включить они его наверное включат, но, как и во всем космическом - нет проблем с ситуацией когда все хорошо, главные проблемы возникают в ситуации когда хорошо не все, и вот режимы восстановления можно и не осилить.
Можно сколько угодно спорить о том стоило ли его выключать, фундаментальная наука она для всех. Но это дело тех, кто этим инструментом владеет. Впрочем, Роскосмосу не привыкать заниматься космическим пиратством.
Такие телескопы работают долгие годы - может лучше подождать пока отношения стабилизируются хоть чуть-чуть? С орбиты он никуда не денется, сломать всегда можно успеть, а чинить потом - как? Это не домашняя фотокамера с защитой от дурака, телескоп при неправильном обращении легко можно и спалить или, в лучшем случае, отправить в безопасный режим, а как его оттуда вытаскивать потом, методом тыка?
Желание даже всех ученых ЕКА недостаточно - нужна более конкретная информация о порядке восстановления и требуемых командах, а такую без явного и публичного разрешения никто не предоставит.
Это не то дело, которое "пробуют" - риск не оправдан, второго шанса может не быть.
Просто инженеры консервативны в оценках. Это как с марсоходами - гарантируют не меньше месяца работы, а караются потом годами сверх гарантированного срока.
Да и вообще, тут же речь про передовой научный инструмент! Большинство ключевых технологий в космосе в первый раз, было бы странно если бы предельные характеристики всех решений были точно известны заранее, ведь тогда бы он не был бы передовым, скорее рядовым, правильно?
Продлить ресурс конечно же можно, что-то можно поменять, что-то - просто перепроверить и уточнить ресурс, но это все равно дополнительные операции.
Все сильно зависит от аппарата. "Науке" не нужно было входить в атмосферу другой планеты на второй космической и мягко садиться. Некоторые модули "Казачка" вполне и не разборными могут быть, обслуживание-то не предполагалось.
У космических аппаратов все очень дорого, и потому очень точно рассчитано, считают даже километраж на дорогах - можно проехать не более N километров, иначе ресурс вибростойкости может пострадать слишком сильно, и аппарат может просто не пережить выведение. Предел по хранению может означать, например, предел стойкости конструктивных материалов к воздействию кислорода (в космосе и на Марсе с кислородом не оч, а значит можно использовать что-то более легкое, но менее стойкое к коррозии).
Пример с кислородом я взял из головы, но надеюсь идея понятна - необходимость оптимизировать конструкцию аппаратов до предела может вылезти в неожиданных местах.
Когда о таком говорят, то речь обычно не о близко расположенных участках, а об участках которые находятся буквально в одном здании. Причем если на таких участках мало наблюдателей, и они "правильные", то явка отличается на десятки процентов. Так же наблюдается интересная закономерность - чем выше на участке явка, тем более однообразно люди на участке голосуют - это и есть "хвост кометы", который объясняют вбросами. Собственно если отбрасывать все такие странные УИКи люди в нашей стане оказываются вполне себе однородными, по крайней мере без резких пиков на пустом месте.
Примеры были, выборы в дугих старанах, выборы РФ 2000
Выборы 2000 г
Явка в целом большая, но большая часть голосов, как ни удивительно, кучкуется в одной области. Посмотрим что было в 2016
2016
Чем больше людей приходит, тем более размазанным оказывается ядро. График в статье тоже выглядит интересно, не нем можно заметить регулярную сетку в верхней части графика:
Самое забавное что это не ошибка - это крайне похоже на результат "подгона" на участков результатов под конкретный процент. Похожую сетку можно увидеть на голосовании за поправку:
2020, голосование за поправку
Не знаю как вам, а мне такой способ поиска проблем кажется вполне убедительным. И он показывает что в среднем результаты по стране вполне себе монотонные, пусть на вашем примере какие-то участки и будут выделяться, но на масштабах страны с большей вероятностью будут выделятся именно проблемные участки. К сожалению, по данным текущей детализации (участок-процент за каждый пункт) более точной картины (чтоб отличить действительно странные участки) построить нельзя. Более интересны в этом смысле результаты электронного голосования, там можно выделить каждый отдельный голос, и отделить время голосования (с определенной, пусть и загрубленной точностью). Но это уже другая история
Картинки взяты отсюда
Ошибки тут нет, скорее передёргивание фактов от автора. По первоначальному плану самая первая рабочая конфигурация sls будет способна закинуть на низкую орбиту как раз 70 тонн, эта конфигурация будет летать 1-2 раза (планы постоянно меняются). Block 1a уже сможет больше. Что интересно, информацию о 70 тоннах я смог найти только забитую в различные уголки на английской Вики и паре зарубежных сайтов, так что возможно планы изменились, и теперь реально с первого раза будет по 95т.