ЭВМ в народном хозяйстве: железная дорога, «Сирена» Аэрофлота, с-х и стройка

Помните женщину в билетной кассе, которая стучала по клавишам странного терминала, а потом из недр стола с грохотом выползал билет? Если помните — у меня для вас новость: вы застали живую историю советской вычислительной техники. В предыдущих частях мы прошлись по истории ЭВМ в СССР и разобрались с поколениями машин. Также мы начали обзор тех областей народного хозяйства, куда ЭВМ внедряли или пытались внедрить. Сегодня продолжаем: железные дороги, «Аэрофлот», сельское хозяйство и стройка.

Железные дороги

Начнём с масштаба, потому что его надо осознать. Десятки тысяч километров путей, около тридцати тысяч локомотивов, сотни тысяч вагонов, тысячи станций.

Такой факт: если выстроить одни только локомотивы в цепочку, она протянется от Москвы почти до Ленинграда. И всем этим надо управлять: каждый вагон учесть, каждый состав сформировать, каждую отправку провести по документам. Вручную. На бумаге. Каждый день.

Неудивительно, что железнодорожники схватились за вычислительную технику одними из первых в стране. Причём схватились так рано, что первая же их история звучит как фантастика. В 1957 году в СССР сделали «автомашиниста» — систему, способную вести электропоезд без участия человека. Вы сейчас правильно прочитали дату, и это не опечатка. Пятьдесят седьмой год. Спутник только-только запустили. А тут — поезд на автопилоте.

Работал автомашинист так. В память ^[1] машины заранее закладывали профиль участка: где подъёмы, где спуски, где ограничения скорости и сколько времени положено на каждый перегон. Грубо говоря, маршрут зашивали заранее — как прошивку в микроконтроллер. Дальше система получала данные с датчиков скорости и пути, сравнивала, как поезд едет на самом деле, с тем, как он должен ехать по расчёту, и решала: тянуть, идти на выбеге или тормозить. Почти круиз-контроль. Только с возможностью остановиться у нужного столба.

Проблем была масса. Например, пройденный путь можно считать по оборотам колёсной пары: знаешь диаметр колеса, считаешь обороты — получаешь расстояние. Беда в том, что диаметр со временем плывёт: колесо изнашивается, его обтачивают. Ошибка ^[2] потихоньку копится — как в шагомере, который шаги считает, но длину шага знает приблизительно. Поэтому автомашинисту приходилось то и дело сверяться с путевыми датчиками и уточнять, где он вообще находится. Иначе этот футуристичный поезд просто промахнулся бы мимо платформы.

Кто именно сделал автомашиниста

Тут в источниках разнобой. Часть железнодорожной литературы приписывает разработку ВНИИЖТу — головному институту отрасли. Другие источники, включая энциклопедические, называют разработчиком пензенский НИИ управляющих вычислительных машин, а опытной площадкой — электросекцию Ср3, которая бегала с этой аппаратурой в 1957–1958 годах. Возможно, что правы все: задачу ставила отрасль, железо делали в Пензе. Но документального подтверждения этой версии нет. Если у кого-то есть точные данные — поделитесь в комментариях. И да, по всем признакам это была первая система автоведения поездов в мире: первые зарубежные упоминания аналогичных разработок появляются только в 1959 году.

В серию тогда это не пошло. Причина банальна: идея опередила железо. Бортовая вычислительная машина выходила сложной, дорогой и не сказать чтобы надёжной. А железная дорога — не полигон, цена ошибки там слишком дорогая. Так что ранний автомашинист остался доказательством, что поезд в принципе можно вести по программе. Для повседневной работы нужна была аппаратура попроще и поживучее: меньше универсальной бортовой математики ^[3], больше заранее просчитанных программ движения и блоков, которые чинят в депо, а не везут обратно в институт.

И всё равно. Пока большая часть народного хозяйства только училась сводить отчёты на ЭВМ, железнодорожники уже примеряли машину к настоящему поезду. Нынешние системы автоведения выросли ровно оттуда.

Ключевой фигурой внедрения ЭВМ на железных дорогах стал член-корреспондент АН СССР Анатолий Петрович Петров. В 1959 году по его инициативе во ВНИИЖТе организовали отделение вычислительной техники — и на следующие восемнадцать лет оно стало главным центром автоматизации отрасли.

Первый вычислительный центр в отрасли появился на Московской дороге ещё в 1961 году. А в 1963-м там же построили и первый полноценный Дорожный вычислительный центр — уже не машинный зал при управлении, а отдельную структуру со штатом, регламентом и своими задачами. В том же 1963-м на «Урале-4» впервые посчитали отчёт о густоте движения грузов по шести дорогам Московского узла. Раньше такие отчёты собирали на Центральной фабрике механизированного учёта — с помощью табуляторов и сортировок (что это за звери, я подробно расскажу, когда доберёмся до банковской сферы). Машина справилась с тем же объёмом, срезав затраты времени на треть.

К концу 1960-х дорожные ВЦ появились на Горьковской, Октябрьской, Донецкой и других дорогах, а к 1977 году свои ВЦ были уже на всех железных дорогах МПС. Казалось бы, всё по уму.

Но был нюанс.

Централизованного плана оснащения дорог вычислительной техникой не существовало. Каждая дорога покупала машины сама — исходя из своих денег, своих связей и своих взглядов на прекрасное. ВНИИЖТ делал ставку на «Уралы», многие дороги брали «Мински». Программы, написанные для одного семейства, на другом не работали. Обмен данными между ВЦ соседних дорог превращался в головную боль ^[4]: либо переписывай код, либо сажай человека перебивать цифры вручную. Железнодорожники вошли во вкус ^[5] автоматизации раньше всех — и раньше всех же упёрлись в несовместимость. Стали, по сути, заложниками собственного энтузиазма.

Знакомый сюжет? В прошлых частях мы разбирали этот зоопарк в масштабах всей страны. С появлением ЕС ЭВМ отрасль перешла на единую архитектуру: во второй половине 1970-х дорожные ВЦ начали пересаживаться на ЕС-1033, а позже — на ЕС-1045.

В 1971 году вышел приказ МПС № 17Ц «О разработке автоматизированной системы управления железнодорожным транспортом» — АСУЖТ. К 1974 году технический проект завершили и утвердили. В него заложили девятнадцать функциональных подсистем, накрывающих практически всю деятельность отрасли — от сортировочных станций до расчёта зарплаты в депо.

Что входило в АСУЖТ

Перечислим основные составляющие — для тех, кто любит аббревиатуры так же, как их любило МПС. АСУСС — управление сортировочной станцией: сортировочные листки, натурные листы на отправляемые поезда, учёт вагонов по назначениям, станционная отчётность. АСОУП — оперативное управление перевозками на уровне дороги, в реальном времени: дислокация вагонов и локомотивов, контроль поездного положения. «Экспресс» — резервирование мест и продажа билетов на пассажирские поезда (о нём ниже и подробно). ДИСКОР — диалоговая информационно-справочная система контроля оперативной работы дорог. ИОДВ — интегрированная обработка дорожных ведомостей. УТРЗ — учёт труда и расчёт зарплаты для работников локомотивных депо.

Самое интересное в АСУЖТ, даже не охват, а режим работы. Большинство гражданских ВЦ тогда жили в пакетном режиме: собрали задачи, прогнали ночью, утром раздали распечатки. Железной дороге такое не годилось — вагоны едут сейчас, и знать, где они, нужно тоже сейчас. А оперативной памяти у тогдашних машин — 256, ну 512 килобайт. Меньше, чем весит одна фотография в вашем телефоне.

Разработчики выкрутились: построили хитрые схемы упреждающей подгрузки данных в ОЗУ. По воспоминаниям инженеров, алгоритмы вышли настолько удачными, что по отзывчивости система обгоняла многие куда более поздние решения. Проверить это утверждение мне, честно говоря, нечем. Но если задуматься, то это логично ^[6]: когда памяти в обрез, код пишут аккуратно.

Теперь про билеты — то, чем железнодорожная автоматизация коснулась буквально каждого.

До ЭВМ продажа билетов на поезда дальнего следования была организована, скажем мягко, творчески. Кассир мог уточнять наличие мест телефонным звонком на центральный узел. Где-то билеты просто печатали заранее и развозили по кассам пачками. В итоге в одной кассе билетов нет, в другой они лежат мёртвым грузом, и поезд уходит полупустым при толпе желающих.

Ещё в середине 1960-х за проблему взялись всерьёз. Главным конструктором автоматической системы продажи билетов — на десятилетия вперёд — стал Борис Ефимович Марчук из ВНИИЖТ. Первую версию (её назвали «Экспресс-1») развернули в 1971–1972 годах на трёх специализированных ЭВМ «Маршрут-1». Машины эти, кстати, делал ереванский НИИ математических машин на основе своих «Разданов» — приятно встретить старого знакомого из главы про поколения.

Первый блин вышел комом. Автоматизированные и ручные кассы работали параллельно, и появлялись «двойники» и даже «тройники» — одно место, могли продать дважды или трижды. Проблему победили не сразу. Периодические отказы системы порождали очереди — хотя на бумаге всё было сделано ровно для того, чтобы очередей не стало. Но дожали: с 1972 года «Экспресс-1» обслуживал кассы Киевского направления, а в 1974-м — уже весь Московский железнодорожный узел, 580 автоматизированных касс, до пятнадцати тысяч заказов в час.

Пятнадцать тысяч в час. На машинах шестидесятых годов рождения.

В 1982 году запустили «Экспресс-2» — уже на серийных ЕС ЭВМ (сначала ЕС-1045, позже добавились ЕС-1046) под специализированной операционной системой TKS. Функций стало заметно больше: резервирование мест, продажа, финансовая отчётность, справки для пассажиров. А к концу 1980-х «Экспресс» пошёл за границу — началось создание единой сети резервирования мест с железными дорогами соцстран по линии ОСЖД. Билет из Москвы до Берлина, оформленный машиной, перестал быть экзотикой. Купить его, правда, по-прежнему могли далеко не все — но это вопрос уже не к вычислительной технике.

Ещё одно место, куда прогресс на железной дороге пришёл раньше других, — сортировочные станции. Там поезда расформировывают на отдельные вагоны и собирают из них новые составы по назначениям. От скорости и точности этой работы зависит пропускная способность целых направлений, поэтому считать здесь начали рано: ещё до всяких АСУ на станциях трудились малые машины вроде «Наири-К», учитывавшие вагоны в сортировочном парке.

Первые полноценные АСУ сортировочных станций разработали и обкатали в девятую пятилетку, в 1971–1975 годах, на станциях Ленинград-Сортировочный-Московский и Орехово-Зуево — тогда ещё на ЭВМ второго поколения. На основе этого опыта ^[7] сделали типовые системы на малых машинах третьего поколения ЕС-1010 с дисковыми накопителями (ЕС-1010, к слову, венгерского производства — социалистическая кооперация в действии). Ставили их на станции, перерабатывавшие до пяти-шести тысяч вагонов в сутки.

Что такая система делала? Держала в памяти живую модель станции — где какой вагон, что на подходах — и по ней рассчитывала очерёдность роспуска составов. А главным её продуктом, как ни смешно, были бумаги. Сортировочный листок — документ, по которому горка распускает состав: какой вагон на какой путь. Раньше его считали вручную, теперь печатала машина. Плюс натурные листы, справки машинисту, отчётность за смену и сутки, сведения грузополучателям. Параллельно решали задачу автоматизации самого роспуска — тут уже нужны были управляющие ЭВМ, способные отдавать команды аппаратуре централизации стрелок и сигналов. К концу 1970-х станционные системы автоматически обменивались данными с дорожной АСОУП, и диспетчер видел картину движения и переработки вагонов по всему полигону дороги.

В 1980-е на станции пришли АРМы — автоматизированные рабочие места дежурных, работников технических контор, товарных кассиров. Строили их на мини-ЭВМ СМ-1420 и СМ-1600 и на персоналках — от гэдээровского «Роботрона-1715» до советских ЕС-1841 и ЕС-1842.

«Роботрон» вообще заслуживает доброго слова. Именно на этих машинах на Белорусской дороге впервые начали формировать комплекты перевозочных документов — накладные, дорожные ведомости, квитанции. На Московской дороге с их помощью автоматизировали учёт проданных билетов и проверку оформления проездных документов. А ещё «Роботроны» крутили индикацию на справочных табло вокзалов и выдавали справки по расписанию. Так что если вы в конце восьмидесятых сверялись с вокзальным табло — вы, вполне возможно, смотрели на вывод гэдээровской персоналки.

Тогда же специалисты ПКТБ АСУЖТ сделали компонент, без которого вся эта распределённая махина не заработала бы, — систему телеобработки данных, СТО. Она принимала сообщения от множества абонентов, выстраивала их в очередь и направляла к месту обработки, причём умела делать это на весьма кривых каналах связи. Сегодня мы бы сказали: брокер сообщений. Kafka образца восьмидесятых, только очереди крутились не в облаке, а на ЕС ЭВМ в дорожном вычислительном центре.

К началу 1990-х АСУЖТ была распределённой вычислительной сетью на все 32 железные дороги СССР: дорожные ВЦ, Главный ВЦ МПС, десятки тысяч терминалов и АРМ на станциях и в депо. Не интернет, конечно. Но по духу — очень похоже.

«Сирена» Аэрофлота

Теперь поднимемся в воздух.

В конце 1960-х Аэрофлот был крупнейшей авиакомпанией мира и перевозил десятки миллионов пассажиров в год. А управлялась вся эта махина, по сути, телефонными звонками и бумажными бланками. Чтобы продать билет, кассир в каком-нибудь Свердловске звонил в Москву и уточнял, есть ли места. Параллельно то же самое делали десятки кассиров по всей стране. Дальше вы уже сами всё поняли: та же проблема, что и на железной дороге, только в воздухе. Одно кресло уходило двум пассажирам.

Есть цифра, что на Норильском авиапредприятии однажды продали билетов на 12% больше, чем было кресел. Перепроверить её по первичным документам трудно, но очевидно, что это могло быть. Двенадцать процентов лишних билетов — это не сбой. Это система. Причём слова «овербукинг» тогда никто не знал, и умысла в этом уплотнении не было — чистая рассинхронизация данных.

При том, что за океаном с этим столкнулись ещё раньше и уже нашли решение. В США с начала 1960-х работала SABRE — Semi-Automated Business Research Environment, совместное детище American Airlines и IBM, сутью система резервирования авиабилетов.

Мог ли СССР купить или лицензировать такое? Не вышло бы при всём желании: передовую вычислительную технику Запад нам не продавал — не из личной неприязни к Аэрофлоту, а по линии экспортных ограничений. Да и стоимость адаптации чужой системы такого масштаба была бы сопоставима с разработкой с нуля.

Поэтому в середине 1960-х за задачу взялась лаборатория № 17 Института проблем управления АН СССР под руководством доктора технических наук Владимира Александровича Жожикашвили. Он стал главным конструктором и идеологом «Сирены» — «СИстемы РЕзервирования На Авиалиниях». Работа шла в партнёрстве с десятками НИИ и заводов; основное железо делало Северодонецкое НПО «Импульс».

Сердцем системы стала специализированная ЭВМ М-3000, созданная в рамках АСВТ — помните, в прошлых частях мы говорили про эту попытку навести порядок в машинном зоопарке? Выглядело сердце как шеренги шкафов в большом зале московского аэровокзала.

Дальше следите за руками.

Процессор у М-3000 был слабенький даже по меркам своего времени. Компенсировали это радикально: всю базу — порядка пятисот рейсов, тарифы, текущие запросы — держали целиком в оперативной памяти. Ферритовой, на магнитных сердечниках, объёмом 256 килобайт. Да-да: вся всесоюзная система бронирования жила в объёме меньше одной фотографии с вашего смартфона. А чтобы не потерять всё при сбое, раз в несколько минут содержимое памяти сбрасывали на диски. Обыкновенный бэкап. За полвека тут ничего не поменялось.

Каналы связи: телефонные линии. Скорость — от 300 до 2400 бит/с. Правда, скорость 2400 бит/с была роскошью, обычно — 600–1200 бит/с. Использовался протокол негарантированной доставки, чем-то похожий на современный UDP. Разработчики декларировали около 97% надёжности доставки сообщений.

Но почему не гарантированной? Потому что телефонные линии в СССР были далеко не идеальным каналом связи. Иногда уровень помех мог быть таким, что данные приходили с ошибками. Переспрашивать — терять время, канал и так узкий (помним, что 2400 бит/с — роскошь, и работать приходилось на уровне 600–1200 бит/с).

Использовали разные хитрости, вроде контрольных сумм и изначального дублирования пакетов.

Оконечным оборудованием были терминалы операторов — пульты с билетопечатающими устройствами. По виду — громоздкие столы с тумбами, в каждой из которых жил печатающий механизм весом в несколько десятков килограммов, работавший с оглушительным стрекотом. Прообраз принтера. Связь терминалов с центром обеспечивали распределительно-преобразующие устройства — непрограммируемые коммутаторы, раздававшие запросы и собиравшие ответы.

«Сирену-1» официально запустили 21 апреля 1972 года. И здесь надо разобраться с масштабом запуска, потому что в описаниях системы есть две цифры, которые на первый взгляд противоречат друг другу.

С одной стороны, система обслуживала продажи для касс Аэрофлота почти в четырёх сотнях городов СССР. С другой — терминалы стояли только в Центральных агентствах воздушных сообщений, ЦАВСах, а их было всего 15–20 на самые крупные города. Противоречия нет: работало это двухступенчато. Кассир в небольшом городе звонил по телефону оператору ближайшего ЦАВСа, и уже тот со своего пульта посылал запрос в Москву. Центральная ЭВМ отвечала полностью в режиме онлайн — напомню, на дворе начало семидесятых. В пиковые часы очередь запросов доходила до 150–300 штук.

Почему не поставить терминал в каждую кассу? Потому что терминал был дорогим и капризным, а каналы связи не потянули бы прямое подключение тысяч точек. Зато теперь понятно, почему авиакасса в крупном советском городе — это не ларёк, а чуть ли не отдельное здание, иногда со своей автобусной остановкой.

ЦАВСы постепенно открывались по стране: в 1975-м заработал центр в Ростове-на-Дону, к 1980-му — в Риге, Киеве, Свердловске и других городах. Складывалась распределённая иерархическая сеть с центром в Москве.

В начале 1980-х пришла «Сирена-2». Дорогие специализированные М-3000 заменили серийными машинами СМ-1 и СМ-2, написали специализированную ОС ТАИС и собственную СУБД САК, а схему сделали децентрализованной: 16 центров обработки данных вместо одного. Появились диалоговые карточки: при каждом запросе на внешнем носителе создавалась запись с переменной частью диалога. По сути — предки современных форм ввода, вынесенные на диск, потому что оперативной памяти катастрофически не хватало. Ну и главное для пассажира: система научилась считать маршруты с пересадками и обслуживать стыковочные рейсы.

«Сирена-2» дожила до 1990-х, когда её сменила «Сирена-3» на мейнфреймах IBM S/390 под управлением TPF. Из «Сирены-2» выросли постсоветские «Сирена-2М», «Сирена-2.3» и «Сирена-2000», а сильно позже — современная система Leonardo, на которую «Аэрофлот» перешёл в 2022 году. Непрерывная родословная длиной в полвека. Кстати, здания ЦАВСов во многих городах стоят до сих пор. Функции уже не те, а остановки — те же.

Сельское хозяйство

С небес спустимся на землю. В буквальном смысле.

В сельское хозяйство ЭВМ шли медленнее, чем в промышленность, и тут нет никакой загадки: объекты управления размазаны по огромной территории, работы сезонные, а про качество связи на селе вы и сами догадываетесь. Тем не менее к началу 1980-х в отрасли работало около трёхсот информационно-вычислительных центров с машинами, периферией и средствами связи.

Самой развитой сетью ИВЦ располагала система Госкомсельхозтехники — ведомства, которое снабжало колхозы и совхозы техникой и запчастями. Больше чем в тридцати областных объединениях внедрили АСУ материально-технического снабжения. Цифры эффекта в отраслевых отчётах приводились серьёзные: Московское областное объединение нарастило товарооборот по запчастям более чем на 25 миллионов рублей при сокращении числа работающих; Горьковское срезало запасы на базах на 15 миллионов и уменьшило штат на треть; годовой экономический эффект оценивали примерно в полмиллиона рублей при окупаемости меньше трёх лет. Это данные из ведомственной литературы — со всеми поправками на то, кто и зачем такие отчёты писал. Но порядок величин похож на правду: складской учёт для ЭВМ — задача понятная.

Проблема сидела в другом месте. Объединениям не хватало около двух тысяч электронных бухгалтерских машин «Искра» и ещё больше — аппаратуры передачи данных из районов в областные ИВЦ. Голова в виде вычислительных центров работала, а руки — первичный сбор данных на местах — не поспевали.

И тут нужна важная оговорка.

«Искра» прекрасно считала запчасти и движение товаров по складам. Но никакая «Искра» не могла повлиять на то, что в колхозных ведомостях урожайность завышали под план, а реальные потери при хранении списывали «за ветхостью тары». Есть старый программистский принцип: garbage in — garbage out. Мусор на входе — мусор на выходе. ЭВМ честно обрабатывала приписки и выдавала аккуратно посчитанные приписки. Пока на зернотоках не появились нормальные весы и датчики влажности, никакая вычислительная машина спасти пшеницу не могла. Но это претензия уже не к технике.

Стройка

Вы когда-нибудь видели сетевой график большой стройки? Простыня в несколько квадратных метров, сотни кружочков и стрелок: какая работа за какой следует, что можно вести параллельно, где проходит критический путь. Теперь умножьте: таких строек в стране — тысячи одновременно, от доменных печей в Магнитогорске до микрорайонов в Набережных Челнах, у каждой — сотни субподрядчиков, и всё это связано потоками бетона и металлоконструкций. Управлять таким хозяйством по бумажным графикам означало гарантированную штурмовщину, срывы сроков и простор для злоупотреблений.

Поэтому строители хотели ЭВМ ничуть не меньше железнодорожников. И получили. Назвали её «Аккорд».

Систему разработали в середине 1960-х в Институте гидродинамики Сибирского отделения АН СССР, в Новосибирске, под руководством Юрия Алексеевича Авдеева.

Скрытый текст

В литературе система везде проходит просто как АККОРД, без пояснений. Гуляющую по сети версию про «автоматизацию контроля и координации» подтвердить не удалось — оставим её на совести пересказчиков. Если знаете, откуда имя, — расскажите в комментариях.

В основе «Аккорда» — те самые сетевые графики: метод, который в те годы сам по себе был переворотом в управлении проектами. На Западе для их расчёта нередко брали мощные и дорогие универсальные машины. Новосибирцы же сделали систему, которая крутилась на том, что уже стояло в обычных вычислительных центрах: на «Минске-22», а затем и на «Минске-32» в режиме совместимости. Код писали на ЯСК, языке символического кодирования, — плотно, вручную, с минимальными требованиями к ресурсам.

Функционально «Аккорд» был набором программных комплексов, замыкавших цикл управления стройкой. Сердце — календарное планирование, комплексы «Дельта» и «Омега». Они отвечали на главный вопрос любого прораба: что важнее — сдать в срок или сэкономить ресурсы? При жёстких сроках система подбирала потребные ресурсы, при жёстких ресурсах — искала оптимальное распределение сроков. На выходе — календарный план, список критических работ, прогноз завершения этапов. Рядом работали комплексы поскромнее: «Сигма» считала графики трудовых ресурсов по исполнителям и объектам, «Гамма» превращала планы в конкретные заказы поставщикам и смежникам.

Обкатывали всё это на строительстве Челябинского металлургического завода: сначала мелкосортный прокатный стан «250» в 1967 году, потом кислородно-конвертерный цех в 1968-м. Причём внедряли не учёные в вакууме — работали вместе со строителями на площадке.

Пятилетний опыт на челябинской стройке дал удивительный результат. Выяснилось: чтобы уложиться в самые жёсткие сроки, не нужно гнать всю стройку в аврале. На повышенную интенсивность — две-три смены — достаточно перевести 10–12% работ, остальные идут в нормальном режиме. Прямые затраты при этом падали на 3–4%, а срок ввода становился действительно гарантированным.

Вдумайтесь: аврал не на всей площадке, а на одной её десятой. Любой начальник стройки на глазок решил бы наоборот — гнать всё. Правильный ответ оказался контринтуитивным, и нашла его машина, которой интуиция ^[8] не мешала.

«Аккорд» был флагманом, но не единственным инструментом строительной кибернетики. В отраслевой литературе тех лет попадались упоминания целого куста систем Госстроя с колоритными именами.

«Миллионник» считал нормы расхода материалов на миллион рублей строительных работ — быстро прикидывал, сколько цемента, металла и леса нужно региону или гигантской стройке.

«Супер» координировал графики бетонных заводов и строек: в эпоху массового железобетона вовремя подвезённый раствор был вопросом жизни объекта.

«Спрут» помогал планировать коррупционные схемы планировал автоперевозки товарных смесей и сыпучих материалов. И нет, назван он не в честь известного сериала: тот выйдет на экраны сильно позже. Подробной документации по этой троице найти не удалось, следы — в основном в старой отраслевой периодике

Вычислительная база у строителей, между прочим, была солидная. В отраслевых НИИ вроде киевского НИИАСС Госстроя УССР работали БЭСМ-6 — машины на миллион операций в секунду. Вспомните сто операций «Урала-1» из первой части. Четыре порядка разницы — за десять с небольшим лет. На таких гигантах считали перспективную потребность ^[9] в строительных машинах и механизмах, до тридцати видов техники разом; для расчётов потребности в рабочей силе применяли БЭСМ-3М.

А для задач вроде «Миллионника» в ИВЦ Минстроя Киргизской ССР уже использовали ЕС-1020 и писали на PL/1 в связке с ассемблером — вполне передовой стек для гражданских АСУ того времени.

Проблемы у строителей были те же, что и везде: техники на местах остро не хватало, кадры в трестах привыкли к телефонному праву, а ведомства друг с другом не дружили. Мощные ВЦ институтов умели многое — но дотянуться от них до каждой площадки было непросто. Флагманские стройки считались на БЭСМ-6, а на обычных сетевые графики по-прежнему рисовали вручную, на той самой простыне с кружочками. Кому интересно, как это выглядело вживую, — поищите воспоминания линейных ИТР семидесятых. Там много боли.

Что в сухом остатке

В этой статье сведены четыре отрасли. И если железная дорога логично коррелирует с «Аэрофлотом», то сельское хозяйство и стройка кажутся накинутыми до кучи. Это не так.

Обратите внимание ^[10] на интересную зависимость. Там, где реально было реализовать честный алгоритм, где данные рождались внутри системы и их не имело смысла подделывать (продажа билетов, роспуск вагонов на горке, сетевой график стройки) ЭВМ приживались и давали результат, который можно пощупать. А там, где данные на вход вводил человек со своими мотивами (урожайность в ведомости, «уточнённые» сроки, которые начальник переписывал каждую неделю) ЭВМ честно считала и выдавала, что ей дали. Срабатывал печальный принцип garbage in — garbage out.

Со стороны это могло выглядеть так, что в каких-то отраслях ЭВМ просто не нужны или трудновнедряемы. Но проблема крылась глубже: далеко не все были готовы оказаться под контролем беспристрастной машины.

Ну а то, что «Аккорд» — приёмами, а «Экспресс» и «Сирена» — прямой родословной дожили до наших дней, само по себе неплохая характеристика тех разработок. Проверьте при случае: билет, купленный на сайте РЖД, до сих пор оформляет далёкий потомок системы Марчука.

В следующей части посмотрим, как ЭВМ работали в Госбанке, медицине и образовании. И встретим старого знакомого — Анатолия Китова.

© 2026 ООО «МТ ФИНАНС»