Чому бортовий комп'ютер «Бурана» не можна порівнювати з IBM PC (і навіть із Space Shuttle)?

Чому бортовий комп’ютер «Бурана» не можна порівнювати з IBM PC (і навіть із Space Shuttle)?

Коли заходить мова про радянський космічний човник «Буран», у мережі часто з’являються дві крайнощі:

• або «це проривне диво інженерії, яке випередило час»,

• або «це відстале залізо на застарілих мікросхемах».

Але порівнювати космічний БЦВК «Бисер-4» з універсальними комп’ютерами за мегагерцами чи мегабайтами — це глибока інженерна помилка. Це прилад, а не персоналка. І порівнювати його потрібно за досконалістю алгоритмів та живучістю. У своєму новому блозі я спробував розібратися в архітектурних муках та технологічних компромісах тієї епохи.

Підставою до написання цього блогу стало очь це відео «Буран» — наше чудо инженерной мысли, которое выбросили на свалку. Компьютер Бурана , що попалося на youtube. Я його подивився і якось стало таке відчуття що порівняння компютерів Буран та Шатл не релевантне і відповідно проривні висновки для радянського екземпляру не правильні. І почав трошки копати. Щоб довго не описувати, зарзу наведу коротку порівняльну таблицю.

Характеристика	БИСЕР‑4 («Буран»)	IBM AP‑101 («Шаттл»)
Тип	Спеціалізований бортовий комп’ютер, розроблений у НВО «Молнія». В одиничному (ну може в кількох) екземплярах, випущений з нуля саме для цього проекту	Універсальний комп'ютер, адаптований IBM для авіоніки і доопрацьований для «Шаттла». Універсальні випукалися з 1965 по 1978, а в варіанті як для Шатла з 1967 по 2011
Елементна база	Секційні мікропроцесори серії К583 (ІІЛ-технологія), прямим аналогом за призначенням та технологією є AMD Am2900, а за принципом побудови — ціла група західних мікросхем, що випускалася з середини 1970-х до початку 1980-х років.	Архітектура на базі mainframe IBM System/360 (серія System/4 Pi)
Розрядність	32‑біт	32‑біт
Продуктивність	~250 тис. оп/с	~325 тис. оп/с
Пам’ять	До 64 KB оперативної пам'яті на магнітних кільцях. Та постійна пам'ять на магнітних кільцях, де були прошиті мікропрограми	~424 КБ оперативної пам'яті + магнітна стрічка, як постійна пом'ять
Відмовостійкість	4 синхронних канали (за принципом мажоритування 3 з 4, далі 2 з 3)	4 синхронних канали + 1 повністю незалежний резервний (BFS)
Автоматизація	Повністю автоматична посадка	Автоматичний політ, але посадка вручну
Програмування	ПРОЛОГ/ ПРОЛ-2/ ДИПОЛЬ / ДРАКОН	HAL/S (High-order Assembly Language for Shuttle), на базі мови FORTRAN
Операційна система	Відсутня. Автомат станів часової петлі (time loop)	завантажує операційну систему FCOS Flight Control Operating System (Операційна система управління польотом). FCOS для Шаттла стала еволюційним піком розвитку військового авіаційного софту, який IBM створювала з 1960х років. Відпрацювала всі 133 місії Шатла і прожила до 2011 року.

Роздуми щодо комп’ютерної системи «Бурана», які вдалося вияснити, та власні коментарі

Архітектура та апаратна частина

БЦВК «Бисер-4»: Система будувалася на спеціалізованих 32-розрядних обчислювальних машинах «Бисер-4» (розробка НПЦАП ім. М. Пілюгіна). 4-кратне синхронне резервування: На борту працювали 4 паралельні обчислювальні канали. Усі чотири машини одночасно виконували один і той самий код та обробляли однакові дані від датчиків. Мажоритарна логіка (“голосування”): Результати обчислень порівнювалися між собою. Якщо один із комп’ютерів видавав збійний результат, логіка виключала його з контуру управління без переривання виконання завдання. Система зберігала працездатність навіть при відмові кількох інших комп’ютерів. Тобто працює, доки зберігається кворум голосування 3 з 4 або 2 з 3 комп’ютерах. Ну, як на партійних зборах. Правда, що робити, коли вийде з ладу судя - питання відкрите.

Програмне забезпечення та мови розробки

• Спеціалізовані мови: Для проєкту розробили комплекс мов програмування: ПРОЛ2 (для систем реального часу), ПРОЛОГ (для програмування логічних задач), ДИПОЛЬ для моделювання, а також проблемно-орієнтовану графічну мову ДРАКОН, яка мала об’єднати цей досвід.Це була свідома відмова від Асемблера на користь наочної логіки, щоб дати можливість «не програмістам» проектувати систему. Використання спеціалізованих мов високого рівня та мови ДРАКОН дозволило інженерам та алгоритмістам описувати надскладну логіку (включаючи позаштатні ситуації та матриці рішень) у вигляді чітких графічних схем. Робилося це, щоб мінімізувати програмні помилки.Хоча ідея мови ДРАКОН концептуально співзвучна з ідеями IBM Message Broker чи Node-RED, які з’явилися набагато пізніше, її реалізація мала свої особливості. Створення візуального коду для унікального космічного корабля — це не те саме, що потокова автоматизація. Ілюстрацією тогочасних реалій розробки може слугувати такий приклад:Інженер в одному НДІ розробив алгоритмічний блок для роботи з новим датчиком і передав його в інший НДІ, де зводять до купи загальну польотну програму. Електронщик (який не є професійним кодером) використовує цей блок, тестує систему, а вона «звалюється» в помилку. Через якийсь час, після сотого перевантаження, він визначає, що серед десятків кроків збій відбувається саме всередині цього чужого блока. Він себе ще сто разів перевіряє — чи не в нього «криві руки»? Переконується, що його вини немає. Але на цей момент він уже повністю емоційно виснажений і доповідає керівництву про брак. Далі керівництво пише офіційну рекламацію в інше НДІ. Починаються жорсткі розборки між відомствами. В цей час когось позбавляють премії — і, відповідно, родина залишається без нової сукні чи путівки до Криму. А хтось із сивих конструкторів на цьому нервовому ґрунті взагалі отримує інфаркт чи інсульт. Радянська космічна програма будувалася не лише на металі, а й на таких людських драмах.

• Щоб звести такі людські драми до мінімуму і гарантувати абсолютну надійність, софт «Бурана» проходив безпрецедентне за масштабами тестування. Код не просто писали — його буквально «катували» на спеціальних наземних стендах-імітаторах. Головним серцем цієї перевірки став Комплексный стенд ОК-КС (Виріб 0.03) у Підмосков’ї — повнорозмірний макет корабля, напханий усією штатною електронікою та бортовими комп’ютерами.На той час в СРСР уже вміли будувати масштабні випробувальні полігони (як-от знамениті радіолокаційні та протиракетні стенди на Балхаші), і жорсткі вимоги до контролю якості заліза існували давно. Проте створення такого глобального, точного інтегрованого комп’ютерного комплексу суто для тестування софту відбулося в СРСР, мабуть, уперше в історії.Починаючи з весни 1984 року, цей стенд працював у цілодобовому режимі без вихідних упродовж 1600 діб поспіль — аж до самого старту у 1988-му. Спеціальні математичні моделі імітували для бортового софту реальний політ: від уявного тремтіння ракети на старті до температурного пекла під час входу в атмосферу. Понад 80% усіх перевірок було повністю автоматизовано. Комп’ютери стенда мільйони разів проганяли тисячі позаштатних ситуацій, штучно підсовуючи програмі «відмови» датчиків та збої живлення. За час цих випробувань інженери виявили та виправили понад 21 000 зауважень та помилок у логіці. Саме цей виснажливий чотирирічний цифровий марафон на землі дозволив створити софт, який відпрацював у космосі взагалі без збоїв.

• Проєкт «Енергія-Буран» вперше змусив радянських інженерів усвідомити, що цифровий код — це така ж критична деталь, як крило чи двигун. Його не можна перевірити лінійкою чи мікроскопом. Тому стенд ОК-КС став першим у країні масштабним інструментом саме для віртуального (модельованого) тестування логіки, передбачивши сучасні методи розробки на десятиліття вперед.

• Як не дивно, “Дракон” отримав міжнародне изнання. У 2011 році програміст Степан Мітюшин створив та випустив у відкритий доступ (Open Source) програму DRAKON Editor. Це стало переломним моментом — мова вийшла за межі закритих космічних КБ.Проєкт став популярним на GitHub, і його підхопила міжнародна спільнота.ДРАКОН адаптували під популярні світові мови програмування (C, C++, Java, Python, JavaScript, Erlang).З’явилися версії інтерфейсу англійською, німецькою, французькою, норвезькою та іншими мовами. Найбільш несподіване міжнародне визнання ДРАКОН отримав у медицині. У Німеччині та інших європейських країнах виникла проблема: медичні протоколи лікування та алгоритми дій лікарів у реанімації часто писалися текстом і були занадто заплутаними. Помилка лікаря в стресовій ситуації дорівнювала катастрофі.Німецькі та литовські медики (наприклад, у кардіохірургії) почали використовувати ДРАКОН для створення наочних медичних алгоритмів. Головне правило мови — “найуспішніший шлях йде по лівому краю, а всі ускладнення та загрози йдуть праворуч” — ідеально підійшло для хірургів та реаніматологів. Лікар під час операції може кинути один погляд на «дракон-схему» і миттєво згадати правильний крок.Сьогодні такі платформи як DrakonHub та Drakon.Tech позиціонують себе на світовому ринку як інструменти для створення безпомилкових алгоритмів не лише для роботів, а й для бізнес-процесів у великих міжнародних корпораціях.Історія ДРАКОНа показує, як суворі вимоги радянського космосу несподівано стали корисними для західної медицини та IT.

• DrakonHub (drakonhub.com) — це найпростіший сучасний хмарний сервіс (SaaS) англійською мовою. Він працює прямо в браузері. Він створений спеціально для того, щоб малювати чисті, ергономічні схеми для бізнесу, медицини чи програмування. Сервіс сам підрівнює блоки та стежить за тим, щоб лінії не перетиналися.

• Drakon.Tech (drakon.tech) — більш професійна англомовна платформа. Вона дозволяє візуально проектувати інтерфейси та логіку, автоматично генеруючи чистий JavaScript/TypeScript код прямо з ваших дракон-схем.

• DRAKON Editor — класична опенсорсна десктопна програма (доступна на GitHub). Вона має англійський інтерфейс і підтримує генерацію коду для Python, C, C++, Java та інших мов.

• Особливе місце в цьому арсеналі посідала мова ДИПОЛЬ — класична таблична мова, побудована на матрицях рішень. Ідея виглядала привабливо: загнати логіку автоматики в чіткі таблиці параметрів «Умова — Дія». Мабуть, кожен сучасний програміст чи архітектор систем автоматизації хоча б раз у житті намагався написати подібний табличний параметризатор, сподіваючись спростити систему. Проте, як показує практика, такі рішення бездоганно працюють лише до першого нестандартного випадку. Як тільки кількість датчиків зростає, таблиці стикаються з комбінаторним вибухом. Описати в них динаміку часу або рідкісні, лавинні збої (наприклад, коли відмова датчика тиску збігається в одну секунду з перезавантаженням генератора) стає фізично неможливо. З’являються небезпечні «сліпі зони». Саме тому розробники «Бурана» змушені були піти далі й створити ДРАКОН. Вони зрозуміли, що сухі таблиці не рятують від логічного хаосу, і замінили їх суворою геометрією схем, де кожен аварійний маршрут наочно веде вправо.

Елементна база (мікросхеми K583 / K588)

У 1980-х роках у СРСР не могли масово виготовляти надійні монолітні 32-розрядні кристали процесорів космічного класу. Для створення БЦВК «Бисер-4» була потрібна висока обчислювальна потужність у 32 біти, виняткова радіаційна стійкість та мінімальне енергоспоживання. Тому розробники пішли шляхом створення секційної (разрядно-модульної) архітектури (Slice architecture), обравши мікропроцесорний комплект серії К583.Технологія І²L (Integrated Injection Logic): На відміну від стандартної ТТЛ-логіки, інтегрально-інжекційна технологія К583 мала унікальну щільність пакування елементів на кристалі, низьке тепловиділення та, головне, високу стійкість до космічного випромінювання.

• Секційність як «конструктор»: Арифметико-логічний пристрій (АЛП) одного процесорного каналу збирався з окремих мікросхем-секцій. Шляхом паралельного каскадування кількох 4-розрядних або 8-розрядних секцій К583ВС формували єдиний внутрішній 32-розрядний тракт обробки даних.

• Мікропрограмне управління: Процесор не мав апаратно жорсткої системи команд. Завдяки секціям мікропрограмного управління (К583ВУ) команди вищого рівня декодувалися через гнучкі мікрокоди. Це дозволило «зашити» в бортову машину модифіковану систему цілочисленних команд знаменитої серії ЕС ЭВМ (радянського аналога американських мейнфреймів IBM 360/370).

• Важливий архітектурний нюанс: Тут не було загальносистемної шини даних у тому розумінні, як ми звикли бачити в архітектурі персональних комп’ютерів (наприклад, UNIBUS/CBUS у PDP-11 або ISA в IBM PC/XT). Каскадування секцій К583 відбувалося на найнижчому, «кристальному» рівні всередині самого процесорного блоку. Система не ганяла байти по материнській платі — вона оперувала безпосередньо фіксованими 32-розрядними машинними словами, які записувалися напряму в модулі пам’яті. Це була закрита, максимально швидкісна синхронна архітектура, де кожен дріт проектувався під конкретну задачу автоматики. І це не було свідомим капризом конструкторів — у радянських інженерів просто не було вибору. На той час в СРСР апаратні математичні копроцесори (для роботи з плаваючою крапкою) існували лише у вигляді гігантських плат для великих цивільних мейнфреймів типу ЄС ЕОМ або міні-ЕОМ СМ 1420. Жоден бортовий обчислювач військового чи космічного класу (навіть у надпотужних РЛС та системах ППО С-300) не мав апаратної плаваючої крапки. Створити такий мікропроцесор у радіаційно-стійкому виконанні радянська промисловість не могла. Тому вся космічна балістика, кути нахилу та траєкторії прораховувалися вручну через масштабування цілих чисел. Те, що американський IBM AP-101 на Шаттлі робив апаратно, радянські програмісти змушені були вигризати чистою математикою на рівні алгоритмів

БЦВК як системний комплекс та логіка резервування

Сам «Бисер-4» — це не просто процесор, а бортовий цифровий обчислювальний комплекс (БЦВК), що складався з чотирьох паралельних обчислювальних каналів (субмашин). На відміну від звичайних ЕОМ, він мав сувору гарвардську архітектуру загального призначення. Пам’ять команд (ПЗП) та пам’ять даних (ОЗП) були фізично розділені окремими шинами. Це гарантувало, що жоден випадковий збій чи радіаційне наведення в оперативній пам’яті не зможе затерти або модифікувати саму польотну програму. БЦВК мав власні контролери введення-виведення для зняття даних з датчиків та видачі команд на кермові приводи. Головним завданням чотириканальної системи було повне нівелювання як апаратних відмов (виходу з ладу деталей), так і збоїв через іонізуюче космічне випромінювання.

• Апаратна синхронізація: Всі 4 канали «Бисер-4» працювали апаратно синхронно. Система генерації тактових частот була взаємно зв’язана: вона мала складну схему фазового автопідлаштування та резервовані кварцові генератори. Кожен канал виконував одну й ту саму інструкцію в один і той самий момент часу. Будь-яка критична затримка чи десинхронізація каналів відразу фіксувалася апаратними схемами контролю.

• Мажоритарна логіка «3 з 4» (і «2 з 3»): Порівняння результатів відбувалося на кожному циклі міжмашинного обміну та при видачі команд на виконавчі органи.

• Схема голосування: Спеціальні апаратні порівнювачі (мажоритарні елементи) зіставляли коди вихідних 32-розрядних слів усіх чотирьох каналів.

• Локалізація несправностей: Якщо Канал 1, Канал 2 і Канал 3 видали значення 0x00FF, а Канал 4 через радіаційне наведення збився і видав 0x00FE, схема приймала більшість (0x00FF) за істину і передавала її на виконання рулів.

• Апаратне відключення (Disabling): Канал, чиї дані відрізнялися від більшості, фіксувався як збійний. Система виключала його переривання та команди з загальної шини. БЦВК миттєво перебудовувався і продовжував працювати як триканальна система (за принципом «2 з 3»). Якщо збій був тимчасовим (одиночний «фліп» біта в пам’яті від комети чи радіації), операційна система могла спробувати перезапустити канал, «на льоту» скопіювати в його ОЗП чистий стан з інших каналів і знову ввести його в стрій.

• Важливий нюанс математики та датчиків: Щоб канали не розходилися при опитуванні зовнішнього аналогового світу, розробники застосували два хитрих кроки:

• Ніякої плаваючої крапки: «Бисер-4» не мав апаратної підтримки математики з плаваючою крапкою (Floating Point). Усі обчислення велися виключно в цілих числах (Fixed-Point). Програмісти вручну масштабували кожну формулу, що виключало накопичення мікроскопічних округлень, через які канали могли б «розійтися» у фінальних цифрах.

• Міжканальний консенсус: Опитування фізичних датчиків (інерціальних платформ, радіовисотомірів) також було резервованим. Перед виконанням відповідального розрахунку канали обмінювалися зчитаними значеннями через спеціальні регістри міжканального зв’язку. Вони вираховували середнє або медіанне значення, щоб переконатися, що всі 4 процесори прийняли на вході абсолютно ідентичні цифри.

Розглянем комп’ютер IBM AP-101 з Шатл.

Архітектура та апаратна частина

• Походження та філософія: На відміну від «Бисера-4», який створювався «з нуля» під конкретне космічне завдання, IBM AP-101 — це модифікація серійного комерційного сімейства IBM System/4 Pi (яке, своєю черговою, було військовою адаптацією знаменитих мейнфреймів System/360). Американці не винаходили велосипед, а взяли готову, масову, комерційно успішну архітектуру і «запакували» її в захищений корпус для авіоніки.

• Магістральна шина: На відміну від радянського обчислювача, де дані писалися безпосередньо словами в пам’ять на низькому рівні, в AP-101 використовувалася класична для американської військової авіації магістральна шина обміну даними (пізніше стандартизована як MIL-STD-1553). Це була концептуальна мережа, схожа на знайомі нам ISA чи сучасні CAN-шини: блоки літака (датчики, комп’ютери, екрани) «спілкувалися» між собою, надсилаючи пакети даних по єдиному цифровому каналу.

• Пам’ять: Оперативна пам’ять становила 104К слів (що в перерахунку на 32-бітну архітектуру з бітами парності якраз дає близько 416–424 КБ). Цікавий історичний факт: до 1980-х років ця пам’ять була на магнітних сердечниках (феритова) — вона була важкою, але фізично не болялася радіації. Як постійна пам’ять (ПЗП) використовувався стрічковий накопичувач (магнітофон) — перед кожною фазою польоту (старт, орбіта, посадка) комп’ютер заново перезавантажував потрібний шматок операційної системи зі стрічки в ОЗП.

Програмне забезпечення та мови розробки

• Мова HAL/S: Замість створення графічних мов типу ДРАКОН, американці пішли шляхом створення суворої текстової мови високого рівня — HAL/S (High-order Assembly Language for Shuttle). Вона базувалася на ідеях PL/I та FORTRAN, але мала жорсткі обмеження для безпеки космосу. Наприклад, у HAL/S було заборонено динамічне виділення пам’яті та заборонено рекурсії (функція не могла викликати саму себе), щоб програма гарантовано не «зациклилася» і не «з’їла» всю пам’ять.

• Операційна система FCOS: Апаратна частина керувалася спеціалізованою ОС реального часу FCOS (Flight Control Operating System). Це був абсолютний пік авіаційного софту від IBM. Її головна фішка — багатопотоковість із пріоритетами. ОС могла одночасно виконувати десятки завдань (навігація, терморегуляція, зв’язок), миттєво перериваючи другорядні завдання, якщо датчик сигналізував про критичну зміну тиску. Аналогія: Якщо ДРАКОН створювався для того, щоб логіку бачив інженер-непрограміст, то HAL/S створювався як інструмент для професійних кодерів, де компилятор на етапі збірки тексту відловлював 99% помилок математики.

Елементна база

• Апаратна розкіш: Ось тут криється головна технологічна розбіжність. IBM AP-101 мав апаратний пристрій роботи з плаваючою крапкою (FPU). Американським програмістам не потрібно було вручну прораховувати розряди, зміщувати коми чи розкладати синуси в цілочисельні ряди Тейлора. Вони писали стандартні математичні формули з дробовими числами, а процесор рахував їх на рівні мікросхем за мікросекунди.

• Технологія: Комп’ютер будувався на базі ТТЛ (Транзисторно-транзисторної логіки). На відміну від радянської інжекційної логіки (І²L), ТТЛ-мікросхеми IBM вимагали більше енергії та виділяли більше тепла, але американська напівпровідникова промисловість могла виготовляти монолітні 32-розрядні процесорні плати з високою тактовою частотою без необхідності збирати АЛУ «як конструктор» з 4-бітних шматочків.Модернізація: Наприкінці 1980-х комп’ютери оновили до версії AP-101S. Вони перейшли на КМОН-технологію (CMOS), стали вдвічі меншими, втричі легшими та отримали вже 1 МБ пам’яті, пропрацювавши в такому вигляді до закриття програми у 2011 році.

БЦВК як системний комплекс та логіка резервування

• Синхронний пул (PASS): Чотири комп’ютери AP-101 об’єднувалися в систему PASS (Primary Avionics Software System). Як і в «Бисер-4», вони працювали абсолютно синхронно, крок за кроком виконуючи один і той самий код і обмінюючись результатами через міжканальні зв’язки. Мажоритарний контроль відсікав комп’ютер, який «збрехав».

• Архітектурна «параноя» (Система BFS): Американці пішли далі у питанні захисту від специфічних помилок софту. Вони подумали: «Добре, якщо один комп’ютер збився апаратно — три інших його вимкнуть. Але що, якщо в самому коді HAL/S закралася логічна помилка, яку не помітили на Землі? Тоді всі 4 синхронні комп’ютери одночасно виконають цю помилку і разом зависнуть або видадуть хибне рішення!»Рішення: Вони створили 5-й комп’ютер, який назвали BFS (Backup Flight System). На ньому крутилася абсолютно інша операційна система, а весь польотний код для нього писала інша компанія-конкурент (Rockwell) на іншій мові програмування! Він працював «в тіні», просто слухав датчики і рахував траєкторію паралельно. Якщо б система PASS «зійшла з розуму» через баг у коді, пілот одним натисканням тумблера міг повністю відключити четвірку IBM і передати керування п’ятому, абсолютно незалежному комп’ютеру.

Висновок

«Порівнювати БЦВК “Бисер-4” з IBM AP-101 чи, тим паче, з домашніми ПК за частотою процесора — це все одно, що порівнювати цифровий медичний кардіостимулятор зі смартфоном на Android. Смартфон швидший і має більше пам’яті, але кардіостимулятор працює без перезавантажень 10 років і рятує життя завдяки бездоганному алгоритму. “Бисер-4” був саме таким приладом. І його велич — не в мікросхемах, а в логіці управління, яка дозволила роботу самостійно перехитрити шторм на Байконурі».

Post Scriptum 1

Хоча, є один елемент який можна порівнювати. А порівнювати можна пам’ять. Оперативна пам’ять в обох обчислювачах була магнітна. На феритових кільцях. Чому феритова? Та тому що вона стійка до іонізуючого випромінення і енерго не залежна.
В СРСР магнітна пам’ять, на феритових кільцях, випускалася ще з другої половнни 1960х років і в не змінному вигляді дійшла до Бурана. Під неї випускалися зі спеціальних феритів кільця діаметром до 3 міліметрів і через ці кільця пропускалися тоненькі мідні дроти. Модуль пам’яті був кубом зі стороною мабуть 20 сантимертів в якого з кожної грані виходила купа контактів. Всі ці куби прошивалися вручну жінками під мікроскопами (їх офіційно називали «прошивальниці»). Коли це оперативна пам’ять - це ще нічого. Там всі модулі стандартні і прошивка типова. Але в “Бисер-4” і постійна пам’ять мікропрограм була зібрана також на магнітній пам’яті. А ось тут криється те саме технологічне пекло, тому, що прошивка під програму не стандартна. Кожна зміна коду ДРАКОН чи ПРОЛ-2 для нової прошивки «Бисера» вимагала фізичного виготовлення нової металевої матриці та тижнів ручної праці «прошивальниць» під мікроскопом. Це пояснює, чому софт «Бурана» «заморозили» задовго до старту.

В IBM AP-101 тільки оперативна пам’ять була феритовою. Прошивка там серійна, типова, так вони ще і шилися машинами (станками). А постійна пам’ять була на 2 магнітних накопичувачах (грубо кажучи магнітофонах). Під час польоту Шаттла магнітофон (MMU) використовувався тільки як жорсткий диск для початкового завантаження програми чи зміни фаз пльоту. Сам процесор AP-101 не читав команди безпосередньо зі стрічки в реальному часі — він завантажував їх у феритову ОЗП, і вже з ОЗП виконував код.

Тут можна сказати , що радянські військові та космічні стандарти вимагали, щоб система мала zero boot time (миттєву готовність при подачі живлення) і 100% гарантію від витирання коду під час ядерного спалаху або прольоту через радіаційні пояси Землі. Магнітна стрічка на Шаттлі розглядалася радянськими конструкторами як «крихка механіка з рухомими частинами», яка може заклинити від вібрацій чи перевантажень. Але, на мій погляд причина крилася в іншому. У СРСР вміли проектувати процесорну логіку та алгоритми, але як тільки справа доходила до прецизійної точної механіки (механізмів протягування стрічки, прецизійних магнітних головок, дисків та лакованої майларової плівки) — радянська промисловість потрапляла в технологічну прірву.

У США стрічкові накопичувачі (типу IBM 729) ще у 1950-60-х роках стали стандартом. Секрет полягав у трьох речах:

• Формула магнітного лаку: Американці навчилися наносити надтонкий, рівномірний шар оксиду заліза на майларову (лавсанову) основу, який не обсипався після тисячі проходів.

• Прецизійні стендастові та феритові головки: Для високої щільності запису потрібен був мікроскопічний і стабільний зазор у головці (одиниці мікронів).

• Складна пневматика та вакуумні петлі: Щоб стрічку не рвало при миттєвому старті й зупинці, IBM вигадала вакуумні колонки-буфери.

У СРСР цивільна й навіть обчислювальна стрічка (наприклад, для ЕС ЕОМ) була жахливої якості. Вона опадала «іржою», забивала головки за кілька годин роботи, розтягувалася та рвалася. А аерокосмічні стрічкові накопичувачі для Space Shuttle (MMU — Mass Memory Unit) вимагали закритих герметичних касет із прецизійною механікою, здатною витримувати перевантаження в 8G та вібрації. Для СРСР зробити такий пристрій серійно з гарантією 99.999% було непосильним завданням. В СРСР намагалися зробити свій бортовий магнітофон для космосу. Він називався механічний накопичувач «Куб» (не плутати з феритовим кубом пам’яті). Його розробляли для станцій «Салют» та «Мир», але він постійно жував стрічку через вібрації, тому в «Бисере-4» конструктори з жахом відмовилися від механіки й обрали надійне, хоч і каторжне, дротове ПЗП на феритах. Підтвердженям цьому є незлічення кількість анектодів радянського часу про протирання магнітних головок, там історій з порваними магнітними стрічками.

Тому СРСР жив довгий час: або перфокарти, або магнітна пам’ять з кастомною прошивкою і тижін очікування поки прошивальниці не виконають роботу, або паперові стрічки з перфорацією.

Post Scriptum 2

Коли пишеш таку статтю, виникає якесь подвійне відчуття.

• З одної сторони, люди, що створили “Бисер-4” зробили власний подвиг. Вони достойні похвали і нагороди.

• З іншої сторони, завжди хочеться оцінити: “А як воно покращило життя людей тої епохи?”.

І отут у мене виникає дилема. Люди, що створили “Бисер-4” зробили титанічну роботу, але вона майже не вплинула на покращення життя людей тої епохи. Люди що стврили лінійку IBM360 потім IBM AP-101 - вони створили серійні продукти, проривні для свого часу. IBM AP-101 або її модифікації застосували:

• F‑15 Eagle (винищувач)

• E‑3 Sentry AWACS (літак дальнього радіолокаційного виявлення)

• Harpoon Missile (протикорабельна ракета)

• S-kylab (космічна станція)

• Space Shuttle (основна авіоніка)

• Використовувався також у B‑52, F‑4

• в аеропортах на диспетчерських вишках всього світу

• в батискафах та інших системах.

Якщо ж подумати про СРСР то до Буран з “Бисер-4” в космос літали: Суюзи, Протони, космічні станції МИР, Салют. Чому потрібно було робити нову систему з нуля?

Ось як виглядає еволюція радянських бортових ЕОМ від «Аргонів» до БИСЕР‑4.

🧩 Етапи розвитку 1968 — Аргон‑11С
Перший бортовий комп’ютер для «Зонд», мінімальна пам’ять, але вже апаратна відмовостійкість.

1968 — Аргон‑12А
Для орбітальних станцій «Алмаз» (Салют‑2/3/5), подвійна надлишковість.

1973 — Аргон‑16
«Робоча конячка» радянської космонавтики: Союзи, Прогреси, Салют, Мир. Трикомпонентна структура з голосуванням, 8 КБ RAM, 64 КБ ROM. Надійність понад 25 років без відмов.

1980‑ті — Аргон‑16Б
Модернізований варіант для станції «Мир», більше пам’яті, трохи вища продуктивність.

1978–1984 — БИСЕР‑4
Спеціально створений для «Бурана». 4+1 канали з апаратним голосуванням, заточений під автоматичну посадку. Унікальний, не використовувався більше ніде.

⚖️ Висновок До «Бурана» вся радянська космічна техніка жила на Аргонах — серійних, але вузькоспеціалізованих і надзвичайно надійних. «Буран» же отримав штучний екземпляр — БИСЕР‑4, який був потрібен лише для однієї задачі: автоматичного польоту й посадки 100-тонного човна.

Якщо ж згадати ком’ютери, які найбільше вплинути на життя людей тої епохи в СРСР то я б згадав такі:

• ЕОМ серії МИР1 та МИР2

Впилинула на інженерів на науковців України, як мінімум. Своєю компактністю, простотою управління та високорівневою мовою програмування “Аналитик” комп’ютери повернулися обличчам до людей. І воно не було страшним, а навтіь досить ласкавим і елегантним. Програмування на цій машині давало людям можливість будувати елегантні програмні абстракції, які до цього в СРСР не будували. Тодішнє програмування в машиних кодах з прошивкою в дротом в феритовх кільцях видавалося якоюсь злою електромеханікою. Ці машини Київського Інституту кібернетики були революцією. Мова «Аналитик» дозволяла комп’ютеру оперувати не просто числами, а аналітичними виразами (інтегралами, похідними). IBM пізніше викупила один екземпляр МИР-2, бо Глушков реалізував апаратну підтримку високорівневої мови на рівні мікрокоду швидше за американців!

• Калькулятори серії Б-3-34, МК-54, МК-52, МК-61

Хоч архітектурна ідея й була запозичена у калькуляторів HP (із їхньою зворотною польською нотацією), але реалізація була повністю на існуючих технологіях СРСР. Набір команд там явно наслідував великі ЕОМ (адресація точно від асеблер СМ 1420 / PDP-11). Тисячі школярів та студентів грали в ігри на цих калькуляторах, обраховували лабораторні роботи, писали ігри. Сотні радіоаматорів намагалися «хакнути» їх через клавіатуру чи сигнали індикаторів, шукаючи приховані регістри та недокументовані функції. СРСР тоді стояв за крок до винайдення власного аналога Arduino чи Raspberry. Достатньо було додати порт вводу/виводу з прямим записом в регістри пам’яті, ну хоч якийсь RS232, а паралельний - ще краще. А мікросхему, на якій будувався цей калькулятор (серія К145), згодом «обрізали» і масово випускали для ширшого вжитку: у цифрових годинниках, магазинних вагах, контролерах управління перших радянських пральних машин «Вятка-автомат-16». Я вважаю, що це кращий вплив на людське житя.

• Поява в СРСР процесора Z80 та різних клонів комп’ютера ZX-Spectrum на його основі

В СРСР виник цілий рух тих, хто власноруч збирав «Спектруми» з розсипу мікросхем, писав ігри, грав у них, зламував софт та ігри чи вчився програмувати. На основі Z80 згодом умільцями випускалися й знамениті побутові АОН (автоматичні визначники номера). Особисто я зібрав 3 чи 4 екземпляри ZX-Spectrum. Мене неймовірно вразив асемблер Z80. В цьому плані я людина балувана бо перший асемблер, який я вивчив був найелегантніший від PDP-11. Після нього асемблер від К580ВМ80 (Intel 8080) чи 8086 (IBM PC) здавалися якимось сірими та неповними. А от Z80 зайшов одразу — своєю логікою, альтернативними регістрами та роботою з перериваннями, оптимальністю. Ну і варто згадати, що попри купу проблем зі спеціалізованими магнітними накопичувачами в країні, ця манюня стійко і якісно зчитувала програми, записані на старі, потерті касети МК-60 з радянських магнітофонів 4-го класу, у яких і швидкість протяжки плавала, і частотна корекція працювала номінально, і магнітні головки стояли криво. Скільки людей завдяки цьому навчилися програмувати!