Система збору зовнішньотраєкторної інформації «Сбор»

Визначення траєкторій випробувань ракет-носіїв та історичних стратегічних випробувальних апаратів здійснювалося за допомогою наземного командно-вимірювального комплексу (КВК) космодрому. До складу КВК входили вимірювальні пункти (ВП), розташовані на території колишнього СРСР.

Розвиток стратегічних аерокосмічних систем вимагав розгалуженої вимірювальної інфраструктури, здатної збирати траєкторні дані, координувати роботу розподілених вимірювальних пунктів і видавати надійні результати в умовах жорстких часових обмежень. Це історичне середовище створило інженерну потребу в таких системах, як наземний командно-вимірювальний комплекс, а згодом і система «Сбор».

Розвиток ракетної техніки вимагав масштабних випробувань, відомих як льотні експерименти. Під час цих випробувань головним завданням було визначення траєкторії польоту випробувального об’єкта. Для цього на території колишнього СРСР було розгорнуто велику кількість засобів супроводу та вимірювальних систем різних типів.

Випробування були настільки інтенсивними, що вузьким місцем стала доставка даних траєкторних вимірювань до Обчислювального центру (ОЦ) космодрому. Ці дані були критично важливими для обробки та формування звітів про траєкторії польоту за результатами проведених випробувань.

Дані записувалися на фізичні носії, такі як магнітні стрічки та перфострічки, після чого літаками доставлялися на космодром. Однак авіація вже не могла гарантувати своєчасну й синхронізовану доставку даних з усіх вимірювальних пунктів.

Поразка у «холодній війні»

У радянську добу в галузі аерокосмічних і стратегічних випробувальних систем було закладено величезний фундамент. Сьогодні ми бачимо модернізовані версії бомбардувальників Ту-160 і Ту-22М3, танк Т-90 та інші зразки. Поява нових типів аерокосмічних випробувальних систем високої складності часто спирається на давно забуті радянські розробки, які досі зберігаються в закритих архівах конструкторських бюро. Радянські інженери створювали технологічні дива, багато з яких залишилися прихованими у запасах того, що колись називали Батьківщиною. Проте не всюди все було так благополучно.

Проблеми виникли з «нервовою системою армії» — зв’язком та обчислювальною технікою. У період застою радянське партійне керівництво різко протистояло кібернетиці, особливо коли йшлося про управління промисловістю, як це пропонував академік Глушков наприкінці 1960-х років. Комуністична партія боялася втратити свій вплив на суспільство, а її «партнери» з-за кордону допомагали підсилювати ці страхи. Наприклад, повернувшись із поїздки до США, академік Арбатов заявив, що комп’ютери — це не більше ніж тимчасова мода на Заході [1].

У цьому середовищі було допущено критичну помилку: замість розвитку власної лінійки комп’ютерів, таких як БЕСМ-6, Радянський Союз зосередився на копіюванні іноземних моделей. Серед них були відомі IBM-360 та PDP-11, які стали основою для радянських комп’ютерів «Єдиної системи» (ЄС), а також моделі на кшталт СМ-3 і СМ-1420. Такий підхід призвів до того, що СРСР пропустив надважливий технологічний зсув — появу персональних комп’ютерів, що спричинило перевиробництво машин серій ЄС та СМ. Далеко за прикладами ходити не доводилося: цілий поверх 7-го корпусу НДІРВ був заставлений цими комп’ютерами, але вже за рік їх демонтували через застарілість і марність.

У головному корпусі ці потворні машини-копії також розташовувалися в різних місцях. На північному полігоні в Сєвєродвінську було побудовано чотириповерхову будівлю для розміщення подібного обладнання, призначеного для збору траєкторних даних про політ стратегічних випробувальних апаратів під час випробувальних пусків з підводних човнів.

На космодромі Плесецьк впроваджувалися комп’ютери СМ-1700 — клони VAX-11/730.

До 1991 року, усвідомлюючи необхідність відокремити свою ділянку від усієї системи «Сбор», провідний інженер Козлов розробив архітектуру бази даних, яка слугувала підсистемою для зберігання траєкторної інформації. Підсистема зберігання проєктувалася за ідеологією файлового сервера — окремого комп’ютера з файловою системою, де зберігалися б файли вимірювальних даних.

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

Уже в 1991 році на файловому сервері використовувалася СУБД Oracle, доступна через технічні матеріали в пізньорадянському інженерному середовищі. Операційною системою була UNIX.

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

Напередодні нового 1991 року керівництво НДІРВ вирішило створити відділ на базі найкращих фахівців із відділів САПР та АСУ. Валентина Олексійовича Козлова призначили начальником відділу, оскільки він був єдиним розробником, який завершив свою частину роботи на самому початку створення системи «Сбор».

Начальник відділу взяв на себе завдання з підбору персоналу для розробки безпрецедентного на той час програмного забезпечення для системи «Сбор», а також проведення вхідного контролю якості апаратного забезпечення системи. Крім того, як показало майбутнє, він також відповідав за організацію складних фінансових схем, що забезпечили фінансування розробки системи в період пострадянського колапсу. З одного боку, ця схема була ініціативою Козлова і єдиним життєздатним варіантом на той час; з іншого — вона мала для нього особисте значення.

Питання про те, як уникнути чергового провалу, висіло над ними, як дамоклів меч. На той час невдачі йшли одна за одною.

Під вікнами у внутрішньому дворі НДІРВ стояли оригінальні обчислювальні машини, створені на замовлення радянського інституційного замовника для спеціалізованої технічної академії з метою моделювання системи координації управління пуском. Шафи з обладнанням стояли покинуті під дощем, нікому не потрібні з військових. НДІРВ був переповнений обчислювальною технікою, єдиною реальною цінністю якої була велика кількість дорогоцінних металів у ній.

Спроба створити систему «Сбор» з використанням комп’ютерів СМ-1420 (радянська копія американського PDP-11) та адаптерних стійок закінчилася провалом. Нічого не працювало. Усе викинули.

Ситуація нагадувала відому байку Крилова «Квартет» — не було комплексного бачення майбутньої системи. Більшість керівників інституту були радіоінженерами, вони не були розробниками програмного забезпечення і не мали розуміння архітектури ПЗ. Тим часом фахівці, які займалися розробкою ПЗ для системи «Вега», були перевантажені завданням перенесення програм із обчислювальних комплексів на базі ЄС-1045 на персональні комп’ютери IBM PC/AT.

До 1991 року технічні матеріали, доступні в пізньорадянському інженерному середовищі, містили інформацію про методології аерокосмічних льотних випробувань і протоколи зв’язку, що використовувалися на міжнародному рівні. Це лягло в основу інженерних вимог до передачі даних та інтеграційного дизайну системи «Сбор».

Наприкінці 1980-х років швидкість передачі даних на полігоні потенційного противника становила 1200–2400 біт/с. У Радянському Союзі дійшли висновку, що автоматизація «вітчизняного наземного випробувального комплексу» також необхідна. Спочатку було прийнято рішення інтегрувати «вимірювальні системи» в інтересах космодрому Плесецьк.

Добре відомо, що 2–3 грудня 1989 року відбулася зустріч Джорджа Буша та Михайла Горбачова, на якій Горбачов підписав капітуляцію Радянського Союзу в холодній війні.

«Я запевнив Президента Сполучених Штатів, що ніколи не розпочну війну проти США».

Міжнародні домовленості про прозорість запровадили вимоги щодо звітності для певних історичних стратегічних випробувальних систем і відповідних записів про місцеперебування.

Однак не всі були готові «підняти руки і здатися». Юрій Семенович Соломонов [3], головний розробник нової мобільної стратегічної пускової системи, відіграв ключову роль у розвитку російської програми стратегічних випробувань. Розробка та випробування систем цього класу стали частиною історичного випробувального середовища, яке вимагало досконалішого збору траєкторних даних і координації вимірювальних систем.

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

Створення «нового і безпрецедентного»

Головна мета системи збору траєкторних даних «Сбор», що розроблялася, — надати вичерпний звіт про проведені льотні випробування протягом 24 годин після випробувального пуску.

Друга фаза системи «Сбор» отримала назву «Єдина система управління» (ЄСУ). ЄСУ була розроблена для роботи з маневреними випробувальними апаратами, які рухалися нетрадиційними траєкторіями, що вимагало адаптивного перенацілювання антен наземних вимірювальних систем у реальному часі. Це передбачало підготовку системи відстеження «Вега» до супроводження прогнозованих точок траєкторії під час льотних випробувань. Для забезпечення ефективного проведення льотних експериментів усі вимірювальні системи мали бути інтегровані в єдиний наземний комплекс відстеження, включаючи «Вега-НО», «Кама-А», «Кама-Н», «Вісмутин», «Велор» та інші.

Система «Сбор» розроблялася як основа (і справді нею стала) для управління вимірювальними системами шляхом динамічного перенацілювання їхніх вузькоспрямованих антен для адаптації до різких змін траєкторії випробувального апарата. Наземний вимірювальний комплекс розглядався як єдиний організм — цілісна розподілена вимірювально-інформаційна система, призначена для льотних випробувань маневрених апаратів.

Як легенда прикриття висувалася версія, що твердопаливні випробувальні апарати можуть демонструвати зміни швидкості горіння залежно від стану твердого палива, яке реагує на різні умови зберігання. Мікротріщини в паливі могли змінити площу поверхні горіння, що призвело б до варіацій інтенсивності тяги серед окремих твердопаливних випробувальних апаратів. Щоб компенсувати ці розбіжності, бортова логіка управління могла генерувати індивідуальні траєкторії на активній ділянці польоту.

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

Однак усе це неминуче зіткнулося з проблемою інтеграції несумісного.

Складність цього завдання визначалася кількома факторами:

1) Усі вимірювальні системи (ВС) розроблялися незалежно одна від одної та мали різні інтерфейси, коди, кадри вимірювань, різну довжину повідомлень і різні типи синхронізації.

2) Усі вимірювальні системи (ВС) були розосереджені по величезній території, від західних до східних кордонів Росії.

3) На той час вибір операційних систем був обмежений і залежав від пізньорадянських каналів технічного забезпечення та доступних інженерних матеріалів.

4) Завдання збору та розподілу траєкторних даних не були автоматизовані на жодному полігоні, і не існувало усталеної методології для виконання таких операцій.

5) Не було команди з досвідом вирішення подібних завдань.

6) Лінії зв’язку були ненадійними, а передача даних мала здійснюватися через захищені канали зв’язку.

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

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

Для цього надскладне наукове завдання розбили на кілька конкретних. Першим кроком було виявлення та визначення постійних елементів у мозаїчному потоці інформації. Ці стабільні компоненти мали стати основою для проєктування архітектури ПЗ і розробки власне програмного забезпечення системи «Сбор».

Як фундаментальна константа всередині системи виступила концепція, яка вже була добре відома в наукових колах СРСР, — ідея Інформаційно-обчислювальної мережі (ІОМ). У 1990 році під редакцією члена-кореспондента АН СРСР І. А. Мізіна та доктора технічних наук Ф. П. Кулєшова вийшов довідник «Протоколи інформаційно-обчислювальних мереж (ІОМ)» [4]. Розгляд системи «Сбор» як ІОМ дозволив визначити роль вимірювальних систем (ВС) у функціонально-логічній та фізичній структурі ІОМ.

Було очевидно, що концепція ІОМ на той час ще не застосовувалася до наземного вимірювального комплексу космодрому. Усі вимірювальні системи були автономними. Розробка програмного забезпечення ІОМ для системи «Сбор» також вимагала знайти стійкий фундамент у фрагментованих знаннях про розробку ПЗ — той, що слугував би послідовним орієнтиром для логічного створення софту системи «Сбор».

За таку основу було обрано «Еталонну модель взаємодії відкритих систем (OSI)». Щойно OSI була обрана як керівний принцип, наступним завданням стало розширення та адаптація її методологій і алгоритмів для побудови всіх рівнів ПЗ для кожного елемента ІОМ на космодромі.

Боротьба зі складністю

Перші спроби розробити систему збору траєкторних даних із вимірювальних систем відстеження стратегічних випробувальних апаратів і космічних ракет-носіїв на всій території Радянського Союзу на базі технологій типу PDP-11 і VAX закінчилися провалом. У НДІРВ намагалися використати СМ-1420 разом із саморобними адаптерними платами для телефонних і телеграфних інтерфейсів, але не змогли досягти експлуатаційної готовності через невідповідність між культурою розробки апаратного забезпечення та складністю завдання до 1991 року.

На космодромі Плесецьк, у центрі збору траєкторних даних, ситуація набула відтінку трагікомедії. Після встановлення СМ-1700 в Центрі обробки даних космодрому військові попрацювали з системою дві години, після чого винесли суворий вердикт: «Не придатна!»

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

Керівництво НДІРВ було змушене провести численні кадрові зміни. Новим начальником відділу призначили Валентина Олексійовича Козлова, архітектора баз даних. Попереднього керівника розробки перевели на посаду старшого інженера-електронника. Козлов почав набирати добровольців із відділів САПР та АСУ. Хоча і свої, і сторонні пошепки говорили, що їхні зусилля приречені на провал, новостворена команда була сповнена рішучості взяти реванш за минулу поразку.

Андрія Вадимовича Ніколаєва призначили провідним розробником програмного забезпечення, Юрій Борисович Волошин став його заступником як програміст першої категорії, а Геннадію Валерійовичу Аксюті доручили розробку програмного забезпечення файлового сервера бази даних.

Ніколаєву Андрію та Волошину Юрію на той час було по 30 років. Вони навчалися в Харківському авіаційному інституті (ХАІ) на факультеті ракетобудування, на програмі, орієнтованій на розробку історичної аерокосмічної системи [5]. Обидва пройшли професійну підготовку з розрахунку траєкторій для аерокосмічних випробувальних об’єктів і відслужили два роки лейтенантами у ВПС СРСР. Ескадрилья Ніколаєва була визнана найкращою у ВПС СРСР у 1985 році, а Волошин служив у полку колишньої «Нормандії-Німан» і відвідував Північну Корею у складі військової делегації.

Обидва мали досвід у бойових мистецтвах, національних методах тайм-менеджменту та психологічній підготовці [6-17]. Ніколаєв особисто розробив програмний комплекс САПР і вперше в історії НДІРВ здав його до галузевого фонду алгоритмів і програм. Крім того, Ніколаєв і Волошин розробили САПР для мікроелектронної апаратури, яку також було передано до фонду. Ця інновація дозволила вперше в Харкові виготовити фотошаблони для мікротранзисторів. Одне слово, жодного з них не можна було залякати складною роботою чи високою відповідальністю.

Команда була повністю сформована на початку 1991 року. Однак у повітрі витала загальна атмосфера розпаду Радянського Союзу. Молоді фахівці нарешті отримали доступ до комп’ютерів і негайно встановили на них ігри. Проводити незліченні години на роботі за іграми стало на той час «нормою».

Ніколаєв, який відповідав за сектор збору траєкторних даних та їх доставку до файлового сервера бази даних, різко поклав цьому край. Він публічно видалив усі ігри зі «спільних персональних комп’ютерів».

Реакція Козлова була миттєвою: «Ти розлякаєш усю команду, яку я так ретельно збирав!»

Відповідь Ніколаєва була сміливою, але виправданою: «Команда — це не гурток за інтересами, де люди грають в ігри в робочий час».

З того моменту ті, хто хотів працювати, залишилися, а ті, хто хотів грати, пішли. Команда очистилася від метафоричної «п’ятої колони». Це стало початком справжньої роботи — без жодних дурниць.

Загальна ситуація на той час була похмурою — інженери 1980-х років були принижені, зведені до ролі наймитів, вантажників і будівельників. Дехто навіть підмітав вулиці перед інститутом.

Однак поява нового, критично важливого завдання — того, з яким ніхто до них не зміг впоратися, — стала надзвичайним джерелом мотивації для новоствореної команди.

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

Отже, необхідно було переосмислити запитання: «Що саме ми робимо?» Проблема в розробці системи «Сбор» полягала в її складності. Інформація нагадувала прекрасну мозаїку в дитячому калейдоскопі. Цю складність треба було приборкати. На той час я вже читав про метод боротьби зі складністю в книзі Габбарда «Проблеми роботи» [18] (хоча Комуністична партія СРСР це не заохочувала). У цій книзі пропонувалося зафіксувати один ключовий елемент, а потім приєднати до нього всі інші частини предметної області, формуючи таким чином повну мозаїку.

З історії авіаційної техніки була добре відома конкуренція між двома вертолітними конструкторськими бюро — Камова і Міля — у розробці важкого транспортного вертольота. Міль і Камов обрали різні підходи: Камов спробував створити складний вертоліт, тоді як Міль переніс усю складність на один компонент — лопать несучого гвинта. На практиці виявилося легше розробити складний компонент, ніж повністю складну машину. У результаті проєкт Ка-22 було скасовано, а Мі-6 випускався серійно і заповнив небо Батьківщини [19, 20, 21].

Першим завданням у розробці Інформаційно-обчислювальної мережі (ІОМ) системи «Сбор» було спрощення. Традиційна фізична структура ІОМ показана на схемі:

Під час розробки системи «Сбор» необхідно було здійснити трансформацію, яка спростила б складність як логічної, так і фізичної структури ІОМ шляхом:

1) заміни всіх елементів ІОМ одним універсальним елементом — Інформаційним концентратором;

2) заміни термінала, на який орієнтована ІОМ, на вимірювальну систему; іншими словами, заміни буквено-цифрового термінала на зразок ЄС 7927 на вимірювальну систему;

3) заміни мейнфреймів на АРМ (Автоматизовані робочі місця).

Модифікована фізична структура Інформаційно-обчислювальної мережі (ІОМ) Єдиного наземного вимірювального комплексу (ЄНВК). ВС – Вимірювальна система; ІК – Інформаційний концентратор; АРМ – Автоматизоване робоче місце фахівця.

Тепер можна було конкретизувати архітектуру апаратних і програмних компонентів системи «Сбор». Традиційна схема апаратної архітектури, що використовувалася в обчислювальній техніці того часу, складалася з центрального процесора, мультиплексора передачі даних (комунікаційного процесора) та терміналів.

Специфікація прототипу Інформаційного концентратора (ІК) привела до такої схеми:

Для забезпечення паралелізму інформаційних потоків, що циркулюють в Інформаційній системі обробки «Сбор», було обрано операційну систему UNIX. Отже, архітектуру програмного забезпечення Інформаційного концентратора (ІК) можна описати такою схемою:

Тепер розгляньмо детальніше інтерфейсний процесор, також відомий як пристрій НІ-526.

Структурна схема цієї двопроцесорної обчислювальної системи наведена нижче.

Пристрій сполучення складається з:

• n блоків сполучення з ЕОМ через інтерфейс С2 (1)
• двох обчислювальних блоків (2)
• n блоків вводу-виводу (3)
• спільного ОЗП для обох обчислювальних блоків (4)
• двох центральних процесорів (ЦП) (5)
• двох виділених модулів ОЗП, кожен із яких доступний лише для свого ЦП (6)
• двох виділених модулів ПЗП, кожен із яких доступний лише для свого ЦП (7)

Пристрій сполучення підключається кабелями через свої блоки сполучення з ЕОМ за допомогою інтерфейсу С2 (1) до пристрою розширення послідовних портів з інтерфейсом RS-232 (широко відомим як COM-порт для персональних комп’ютерів).

Як персональний комп’ютер (ПК) під управлінням операційної системи UNIX було обрано IBM 386SX.

Таким чином, зовнішній вигляд Інформаційного концентратора (НІ-525) був визначений, що дозволило оновленій команді зафіксувати зовнішній вигляд універсального елемента системи «Сбор» — Інформаційного концентратора.

Далі необхідно було модифікувати Еталонну модель взаємодії відкритих систем (OSI) для Єдиного наземного вимірювального комплексу та розробити відповідне програмне забезпечення.

Джерела

1. ЗДАС «Загальнодержавна автоматизована система збору та обробки інформації»
2. База космічних сил Ванденберг
3. Соломонов Юрій Семенович
4. Протоколы информационно-вычислительных сетей: Справочник / С.А. Аничкин, С.А. Белов, А.В. Бернштейн и др.; Под ред. И.А. Мизина, А.П. Кулешова. М.: Радио и связь, 1990. 504 с.
5. Історичне джерело про радянські/російські аерокосмічні випробувальні системи
6. Гранін Д. Эта странная жизнь
7. Олександр Нечаєв. Чого я навчився, відстежуючи кожну хвилину протягом 2 років (за мотивами письменника Даниїла Граніна)
8. Каллаген С. Adrift: Seventy-Six Days Lost at Sea (ілюстрації автора) / Вперше опубліковано англійською. Нью-Йорк: Houghton Mifflin Harcourt, 1986. 240 стор.
9. Стівен Каллаген
10. Франкл В. Сказати життю «Так!»: Психолог у концтаборі
11. Цен Н.В., Пахомов Ю.В. Психотренінг: ігри та вправи
12. Тейлор Ф. В. Принципи наукового менеджменту
13. Ганнес Ліндеман
14. Володимир Леві. In Touch & In Tune
15. Леві В. Искусство быть другим
16. Абаєв Н.В. Чань-буддизм і культурно-психологічні традиції в середньовічному Китаї
17. Капабланка Основи шахової гри
18. Л. Рон Габбард Проблеми роботи
19. Ка-22
20. Мі-6
21. Забутий радянський гвинтокрил — Камов КА-22 та КА-35