PAS7 Studio
Обкладинка блогу про місію Artemis II та сучасний космічний програмний стек
Технології05 квіт. 2026 р.·12 хв читання·Оновлено 05 квіт. 2026 р.

Artemis II і код, який веде до Місяця

У цьому блозі розбираємо місію NASA Artemis II, яка стартувала 1 квітня 2026 року, і пояснюємо, що вона насправді говорить про сучасну інженерію: бортове ПЗ, резервні контури, симуляції, телеметрію, людський контроль і дуже обережну роль ШІ в космічній сфері.

Інженери програмного забезпеченняТехлідиЛюди, яким цікаво, як ІТ виглядає за межами звичайного вебуКоманди, які працюють із критично важливими або наднадійними системами

NASA справді запустила Artemis II 1 квітня 2026 року, і ця місія важлива для ІТ не через романтику космосу, а через те, як виглядає розробка для систем із людським екіпажем. Публічні матеріали навколо Artemis II показують багатошаровий стек: бортове ПЗ SLS, резервне ПЗ Orion, симуляції, центр керування польотом, MER, мережі зв'язку і контури телеметрії. ШІ в цій картині вже є, але як допоміжний інженерний шар, а не як заміна перевірки й людського рішення. [1][4][5][6][7][8][10][12]

Artemis II це перша пілотована місія навколо Місяця за більш ніж 50 років, а не просто ще один запуск. [1][3]
Ця історія значно цікавіша за розмови про один мовний стек. У відкритих матеріалах набагато важливіші шари ПЗ, резервування, симуляції, мережі зв'язку і перевірка. [5][6][8][9][12]
Офіційні матеріали NASA показують і напрямок зі ШІ: автоматизоване тестування, пошук помилок, первинний розбір телеметрії, цифрові помічники для MER, але не безконтрольний автопілот коду. [10][12]
Xin
почати варто з цього

Головне про Artemis II і чому це цікаво ІТ-шникам

Найцікавіша частина цієї історії не в тому, що NASA знову летить до Місяця, а в тому, який програмний стек стоїть за місією, де людей не можна дорелізити в наступному патчі.

Artemis II стартувала 1 квітня 2026 року, а сама місія триває приблизно 10 днів і веде Orion навколо Місяця з поверненням на Землю. [1][2][3][4]
Це не просто символічний обліт. NASA тестує роботу систем із екіпажем, життєзабезпечення, ручне керування, засоби зв'язку, аварійні можливості й роботу інтегрованих систем у реальному далекому космосі. [2][4][12]
Найсильніша інженерна частина цієї історії це бортове ПЗ, резервне ПЗ, цикли оцінки місії, запускові симуляції, телеметрія, Deep Space Network, оптичний зв'язок і перевірка для систем із екіпажем. [4][6][7][8][9][12]
ШІ вже заходить у космічну інженерію, але не як романтичний замінник інженера. Офіційні матеріали NASA говорять про автоматизоване тестування ПЗ, пошук помилок, первинний розбір телеметрії, підготовку процедур і цифрових помічників для MER. [10]
спочатку сама місія

Що треба знати про Artemis II, щоб розуміти її інженерну цінність

Станом на 5 квітня 2026 року Artemis II вже в польоті після запуску 1 квітня о 6:35 p.m. EDT з Kennedy Space Center. Для широкої аудиторії це перший пілотований політ навколо Місяця з часів Apollo. Для NASA це ще важливіше, бо Artemis II перевіряє, як поводяться SLS, Orion, наземні системи й інтерфейси екіпажу не в красивому слайді, а в реальному середовищі далекого космосу. [1][2][3][4]

AP у своєму матеріалі цілком влучно назвала цю місію першою людською подорожжю до Місяця за понад пів століття. Але якщо дивитися очима інженера, Artemis II це насамперед місія про довіру до систем, а не про символіку. [3]

Саме тому тут важливі не тільки ракета, капсула чи екіпаж, а й те, як NASA збирає телеметрію, як тримає дані орбіти в реальному часі, як тестує ручне керування Orion, як організовує контури керування польотом і як закриває уроки після Artemis I. У таких місіях залізо без дисципліни в програмному забезпеченні просто не має ваги.

Artemis II це не висадка, а повноцінне випробування систем із екіпажем від початку до кінця. У цьому і є її головна цінність для NASA і для інженерів, які дивляться на місію не як на шоу, а як на репетицію перед ще складнішими польотами. [1][2][4]

Скріншот секції mission-first
як це летить

Профіль місії в п'ять кроків

Artemis II добре пояснює одну річ: це не коротка демонстрація старту, а послідовність перевірок, де кожен етап має власну логіку програмного забезпечення й керування.

01

Старт і вихід на орбіту Землі

Після старту екіпаж не летить до Місяця миттєво. Спершу йде перевірка Orion і бортових систем на високій навколоземній орбіті. [1][4][12]

02

Перевірка всіх ключових систем із екіпажем на борту

Саме тут NASA перевіряє те, чого Artemis I не могла перевірити повністю без людей: інтерфейси екіпажу, життєзабезпечення, зв'язок, ручне керування і нестандартні сценарії. [12]

03

Вихід на місячну траєкторію і політ у навколомісячний простір

Після перевірки біля Землі Orion йде на траєкторію до далекого боку Місяця. Для програмного забезпечення це означає інший режим зв'язку, навігації й підтримки з центру керування польотом. [2][4]

04

Lunar flyby і найдальша точка польоту людей за багато десятиліть

Місія не сідає на Місяць, але проходить навколо нього і повертається по траєкторії вільного повернення. Це дає NASA головне: реальний набір даних про системи з екіпажем для майбутніх місій. [1][3][12]

05

Повернення, вхід в атмосферу і приводнення

Після льотної частини місія знову стає історією про програмне забезпечення, зображення, телеметрію, процедури підбору капсули і післяпольотний аналіз. Саме на цьому етапі після Artemis I виявилися речі, які довелося серйозно доробляти перед Artemis II. [12]

Висновок

Для інженера Artemis II це не одна подія, а довгий ланцюг перевірок, де кожна підсистема має довести, що їй можна довіряти з екіпажем на борту.

де тут ПЗ

Справжня історія програмного забезпечення в Artemis II

Публічні матеріали NASA добре показують, що Artemis II не зводиться до однієї великої програми. Наприклад, у матеріалах про бортове ПЗ SLS інженери прямо називають його brains of the rocket. Це точна, але дуже часткова правда. [5]

Окрім основного бортового ПЗ, у NASA є й окремий резервний шар. В Orion існує Backup Flight Software, яка спеціально зменшує ризик спільної помилки між основним і резервним контуром. Це вже не історія про красиву генерацію коду. Це історія про різнорідне резервування. [6]

Далі йде наземний контур. Центр керування польотом веде місію, але модель інженерної підтримки нікуди не зникає. У матеріалах NASA про Mission Evaluation Room це сформульовано дуже прямо: The operations team is flying the spacecraft. Одразу після цього йде друга половина сенсу: інженери підкріплюють ці рішення аналізом. [7]

Є ще мережевий і даний шар. NASA прямо пише, що Reliable communications are the lifeline of human spaceflight. Для Artemis II це Near Space Network, Deep Space Network, експеримент з оптичним зв'язком O2O, AROW і потоки телеметрії, які одночасно потрібні екіпажу, фахівцям центру керування польотом і технічним командам на Землі. [2][8]

І ще один шар, який часто недооцінюють у популярних текстах, це симуляції. Для Artemis немає опції подивимось у польоті. Саме тому NASA багато років вкладається в моделювання умов запуску, поведінки траєкторії, інтегровані симуляції і перевірку з підключенням реального обладнання, щоб знімати ризики ще до реального старту. [9][12]

У місії такого рівня немає однієї чарівної кодової бази, яка все вирішує. Є кілька шарів, і кожен має свою відповідальність, свої ризики і власний шлях перевірки. [5][6][7][8][9][12]

Скріншот секції software-story
старе і нове разом

Чому ця місія не зводиться до однієї мови чи одного стеку

У космічній інженерії старі й нові інструменти часто живуть поруч. Але для Artemis II набагато важливіше не те, якою мовою написаний окремий інструмент, а як уся система перевіряється і страхується.

Comparison pointТезаЩо реально видно з публічних джерел
У NASA живе спадковий кодТак. У NASA Software Catalog досі є довгоживучі інженерні інструменти зі старою основою. Приклад, STARS для структурного аналізу. [11]Тобто спадок наукового й інженерного програмного забезпечення справді нікуди не зник. Для аерокосмосу це нормально, якщо інструмент корисний, перевірений і добре вбудований у процес.
Artemis II це не одна мова і не один кодовий шарПублічна база навколо Artemis II акцентує не на одному мовному стеку, а на бортовому ПЗ SLS, резервному ПЗ Orion, симуляціях, перевірці, центрі керування польотом і мережах. [5][6][7][8][9][12]Чесніше говорити так: у космічній інженерії є сильний спадковий шар, але стек місії з екіпажем завжди значно ширший і організований навколо надійності, а не навколо одного інструмента.
Головна історія тут про мовуДля Artemis II головні слова це перевірка, резервування, сертифікація, телеметрія, операційна робота і людське право останнього рішення. [6][12]Мова важлива, але ще важливіше, як ПЗ тестується, ізолюється, резервується і документується.
де тут ШІ

Де ШІ вже реально заходить у космічну інженерію, а де їй ще зарано бути головною

ШІ тут уже доречна

Автоматизоване тестування ПЗ, пошук помилок, первинний розбір аномалій у телеметрії, підготовка процедур, підтримка чеклістів, короткі зведення по документах, пошук по матеріалах місії і цифрові помічники для MER. Це вже прямо є в матеріалах NASA JSC Engineering. [10]

ШІ потребує сильного людського контролю

Підтримка рішень для центру керування, ранжування аномалій, пошук по польотних правилах, інженерні помічники з урахуванням контексту. Тут ШІ може бути дуже корисною, але не як єдине джерело істини. [7][10]

ШІ не виглядає чесною заміною

Критична польотна логіка, шляхи сертифікації, право сказати летимо / не летимо, аварійна логіка без зрозумілої перевірки. Тут розмови про нехай модель сама напише і полетимо поки просто несерйозні. [6][12]

Що справді цікаво на майбутнє

У NASA вже паралельно рухаються HPSC і напрями ШІ/ML для бортових обчислень, а в JSC є реальні проєкти ШІ для інженерної підтримки. Найсильніший сценарій тут не заміна інженера, а підсилення перевірки, тестування і операційних контурів. [10]

Найкраща роль ШІ тут не в тому, щоб тихо писати критичну польотну логіку замість інженера. Найкраща роль у допоміжних шарах: тестування, аналіз, первинний розбір телеметрії, робота з процедурами і підтримка рішень. [10][12]

Скріншот секції ai-angle

Нормальний висновок про ШІ

Якщо коротко, ШІ в космічній сфері вже корисна там, де треба швидше бачити, шукати, перевіряти і пояснювати. Там, де треба гарантувати безпеку екіпажу, вона поки що має бути асистентом, а не фінальним автором рішення.

що це дає ІТ

Які уроки з Artemis II реально можна забрати в звичайну ІТ

Ця місія важлива не тому, що ми завтра всі почнемо писати ПЗ для ракет. Вона важлива тому, що дуже чітко підсвічує інженерні речі, які в цивільній розробці теж працюють, просто там їх рідше доводять до такої дисципліни.

Надійність це не одна бібліотека і не один senior. Це кілька шарів відповідальності, які не дублюють, а страхують один одного.

Резервний контур має сенс тільки тоді, коли він не копія основного. Резервне ПЗ корисне не фактом наявності, а тим, що воно реально знижує ризик спільної помилки. [6]

Симуляції не замінюють прод, але без них немає права називати систему готовою. У складних системах репетиції і тестові стенди це не приємний бонус, а необхідність. [9][12]

Телеметрія і спостережуваність не закінчуються на графіках. Вони мають підживлювати реальні рішення, відстеження в реальному часі, реакцію на аномалії і навчання після польоту. [2][7][8][12]

ШІ найсильніша не тоді, коли її ставлять у центр маркетингового слайду, а тоді, коли вона реально пришвидшує аналіз, тестування і допоміжну роботу без втрати людського контролю. [10]

Висновок

Найкращий місток між Artemis II та ІТ такий: хороша інженерія починається там, де команда поважає межі системи сильніше, ніж власний оптимізм.

FAQ

Часті запитання

NASA справді запустила Artemis II?

Так. Artemis II стартувала 1 квітня 2026 року. Станом на 5 квітня 2026 року місія вже в польоті, а сама програма описує її як приблизно 10-денний випробувальний політ із екіпажем навколо Місяця. [1][2][3][4]

Чому Artemis II важлива для ІТ, якщо це космос, а не звичайна розробка?

Тому що вона дуже чисто показує, як виглядає розробка там, де надійність важливіша за швидкість. Тут видно реальні шари: бортове ПЗ, резервне ПЗ, центр керування польотом, телеметрію, зв'язок, симуляції і людське право останнього рішення. [5][6][7][8][9][12]

Чи зводиться історія програмного забезпечення Artemis II до одного старого стеку?

Ні. У NASA і справді є довгоживучі інженерні інструменти, і це видно в Software Catalog. Але Artemis II це значно ширша історія: бортове ПЗ, резервне ПЗ, перевірка, симуляції, центр керування польотом, зв'язок і людська відповідальність. [6][11][12]

Чи вже використовує NASA ШІ у космічній інженерії?

Так, але в дуже конкретних ролях. У матеріалах JSC Engineering прямо фігурують автоматизоване тестування ПЗ, пошук помилок, робота з аномаліями телеметрії, підготовка процедур і цифрові помічники для MER. Це сильний сигнал, але не той самий, що `ШІ вже пише і сертифікує весь критичний польотний код`. [10]

То яка найчесніша ІТ-мораль із Artemis II?

Найчесніша така: у складних системах виграє не найгучніший стек, а той, де є перевірка, резервування, спостережуваність, хороші симуляції і зрозумілий людський контроль. Artemis II це дуже жорстке нагадування саме про це. [6][8][9][12]

джерела

Що я читав для цього тексту

Основу тут складають офіційні матеріали NASA, NASA OIG і JSC Engineering. Зовнішній погляд я брав мінімально, тільки там, де він додає нормальний контекст, а не шум.

Перевірено: 05 квіт. 2026 р.Актуально для: Artemis IIАктуально для: стек NASA SLS та OrionАктуально для: розробка для критично важливих системАктуально для: інженерні процеси з підтримкою ШІПеревірено з: сторінки місії NASA Artemis IIПеревірено з: звіт NASA OIG про готовністьПеревірено з: каталог програм NASAПеревірено з: матеріали NASA JSC про ШІ в інженерії

Пов'язані статті

Скільки коштує розробка AI асистента у 2026: RAG чатбот, база знань, CRM, Telegram та підтримка
ai-assistants

Скільки коштує розробка AI асистента у 2026: RAG чатбот, база знань, CRM, Telegram та підтримка

Практичний гід для бізнесу: від чого залежить ціна розробки AI асистента у 2026 році, що входить у RAG чатбот, інтеграції з CRM, Telegram, guardrails, оцінювання, моніторинг і супровід.

AI може зробити більше. Не краще: що насправді кажуть дослідження про розробку ігор
blogs

AI може зробити більше. Не краще: що насправді кажуть дослідження про розробку ігор

Generative AI входить у production ігор, але докази складніші за хайп. Розбираємо adoption, ставлення гравців, ризики якості та практичний workflow.

AI для розробки лендінгів: де він реально прискорює запуск, а де псує конверсію
blogs

AI для розробки лендінгів: де він реально прискорює запуск, а де псує конверсію

Дослідження про використання AI у розробці лендінгів: v0, Webflow AI, Builder.io, Framer-подібні AI builders, генерація UX, copy, SEO, персоналізація, A/B тести, ризики шаблонності, безпеки, доступності та технічного боргу.

AI SEO / GEO у 2026: ваші наступні клієнти — не люди, а агенти
growth

AI SEO / GEO у 2026: ваші наступні клієнти — не люди, а агенти

Пошук зміщується від кліків до відповідей. Боти та AI-агенти сканують, цитують, рекомендують і дедалі частіше купують. Дізнайтесь, що таке AI SEO / GEO, чому класичного SEO вже недостатньо, і як PAS7 Studio допомагає брендам перемагати у «агентному» вебі.

Професійна розробка для вашого бізнесу

Створюємо сучасні веб-рішення та боти для бізнесу. Дізнайтеся, як ми можемо допомогти вам досягти цілей.