Чаганов: После войны

— ... Начнут войну за то, кто станет управлять ОГАС.— Согласно кивает академик.

'Легко ему со мной соглашаться, видимо рассчитывает, что это я буду 'пробивать' его систему'.

— Скажу вам так, Виктор Михайлович,— улыбаюсь притихшему Глушкову, выжидательно смотрящему на меня,— я может быть и поддержал бы вас, даже не взирая на то, что ваша система сложнее и дороже, чем наш Атомный проект в купе с Космической программой, мне не впервой лбом пробивать каменные стены, но делать этого не стану. Знаете почему? Я не верю в её успех.

Академик обречённо опускает голову.

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

Глушков грустно кивает.

'По крайней мере эта постфактум точка зрения на недостатки ОГАС показалась мне в той жизни логичной'.

— Ну хорошо, Виктор Михайлович, только не пытайтесь записывать за мной, в конце нашей беседы вы получите краткой изложение основных мыслей. Итак, приступим — вместо того, чтобы полностью автоматизировать учёт, планирование, оперативное управление и ценообразование в одной системе, я предлагаю создать несколько связанных подсистем, которые будут выполнять примерно те же функции, что и ОГАС , но их функционирование может отлаживаться и запускаться независимо и поэтапно — от простого к сложному. Начну, как это ни странно, не с подсистемы 'План', а с подсистемы 'Диспетчер', которая выполняет роль исполнителя, а точнее системы управления экономикой. Она получает сигналы снизу от объекта управления и сверху — от плановой подсистемы, обрабатывает их и выдаёт управляющие воздействия в форме разрешений приоритетов, лимитов и диспетчерских директив, которые исполняются через каналы поставок и платежей. Важно понимать, что Диспетчер не командует заводами и не вмешивается в технологические процессы. Он, во-первых, присваивает заявкам-поставкам-перевозкам класс приоритета и управляет очередью получения дефицитного ресурса или перегруженного транспортного направления. Во-вторых, корректирует оперативные лимиты на расход возникшего дефицита какого-либо ресурса — не план на год для всех ресурсов — а сколько можно дать дефицита сейчас — в день или неделю, распределяет квоты. В-третьих, Диспетчер даёт разрешение-задержку-запрет платежа через банк и перераспределяет потоки и маршруты. В-четвёртых, объявляет режимы — нормальный, напряжённый аварийный и запускает алгоритм работы, который соответствует этому режиму. В-пятых, посылает предупредительный сигнал наверх в подсистему План в виде — очёта о хронических дефицитах, данных о частоте аварийных вмешательств, об эффективности лимитов и так далее...

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

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

— Как обычно собираем 'первичку',— удивлённо смотрит на меня Глушков,— пересылаем её в кустовой вычислительный центр, он обрабатывает её, оценивает возможность ликвидации последствий своими силами. Если их недостаточно, то пересылаем уже агрегированные данные в Центр, там сводка данных, расчёт вариантов на матрице межотраслевых балансов, на их основе формируются директивы, которые рассылаются вниз на места.

— То есть, Виктор Михайлович, после аварии вы будете дожидаться своего временного 'окна' в местной связи, чтобы передать данные в кустовой ВЦ или сразу обрушиваете всю связь сначала в регионе, начиная передавать 'первичку' наверх вне очереди, затем на линиях идущих в Центр?

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

— Если пересылать первичную информацию в кустовой ВЦ во время аварии без очереди, то никаких каналов не хватит.

— Не понимаю вас, Алексей Сергеевич,— трясёт головой Глушков,— как же плановые органы получат информацию? Как ваш 'Диспетчер' и 'План' получат первичную информацию?

— Моему 'Диспетчеру', Виктор Михайлович, 'первичка' не нужна вообще. Она работает с сигналами и агрегированными данными. Получив сигнал об аварии и несколько чисел, которые отражают масштаб ущерба, типа — выработка электроэнергии упала на 40 процентов или пропускная способность магистрали 'Х' уменьшилась на 25 — он начнёт сразу действовать, меняя приоритеты потребителей, лимиты на ресурсы, маршруты поездов и очереди, даже совсем без связи с Центром. Задача 'Диспетчера' удержать функционирование системы пусть и на более низком уровне, но не допустить её коллапса.

— Но без анализа 'первички', Алексей Сергеевич, ваш 'План' будет слеп.

— 'Плану' тоже первичка не нужна, ему нужен 'агрегат' по отраслям. Какой размерности матрицу межотраслевых балансов вы закладываете в ОГАС на первом этапе?

— Это будет зависеть,— Глушков поднимает глаза к потолку,— от возможностей той вычислительной техники, которую сможет обеспечить наша электронная промышленность. Чем больше — тем лучше.

— Нет, Виктор Михайлович, я спрашиваю какая размерность матрицы межотраслевого баланса вам необходима, чтобы достаточно точно описать экономику?

— Думаю, что на первом этапе будет достаточно иметь матрицу 200 на 200 в продуктовом выражении и для простоты примерно такую же в стоимостном. Точность описания будет на уровне 80-90 процентов.

— Хорошая стартовая точка, поскольку после размерности 300 мы будем детализировать не экономику, а 'шумы' исходных данных. Итак, 200 на 200. Если на каждый элемент матрицы выделить 'слово' длиной 4 байта, то чтобы держать её целиком в памяти потребуется около 160 килобайт. Чтобы постоянно без подгрузки держать в памяти 'продуктовую' и 'стоимостную' матрицы, а также ценовые вектора, нужно примерно 330 килобайт. Плюс операционная системы, справочная информация и тэ-пэ — получаем 512 килобайт ферритовой памяти. Многовато, конечно, но такую память должна иметь лишь основная ЭВМ подсистемы 'План'. Давайте прикинем сколько времени будет считать эти две матрицы межотраслевого баланса наш флагман вычислительной техники БЭВМ-6...

'В 'девичестве' БЭСМ-6 академика Лебедева, но с улучшениями от 'товарища Чаганова'. Первым делом добился 'позорного' лимита 15-битной адресации — удалось настоять на 24-х битах— при этом я горячо поддержал виртуальную страничную адресацию, предлагаемую авторским коллективом. Много 'копий было сломано' вокруг вопроса разрядности данных. С трудом, но удалось уйти от предлагаемого 48-битного машинного слова к 32-битному, соблазнив авторов вычислительным сопроцессором с прямым доступом к памяти, который будет выполнять арифметические операции с двойным словом. С энтузиазмом прошло моё предложение расширить кэши, со скепсисом — поставить вместо аккумулятора 16 нормальных универсальных регистров и задокументировать единый канальный интерфейс с прямым доступом к памяти и чёткой системой прерываний и приоритетов. Впрочем, авторы были готовы мне многое 'простить' после того, как я объявил, что вместо элементной базой БЭВМ-6 будут не дискретные транзисторы, а первые в мире интегральные микросхемы с малой степенью интеграции. БЭВМ — это не БЭСМ, по классу она скорее похожа на Эльбрус-1 или ЕС-1060 из моего прошлого с обшей производительностью 10-15 миллионов операций в секунду, что на порядок превышает БЭСМ'...

— ... Итак, простые расчёты показывают,— подмигиваю я сосредоточенному Глушкову,— что речь идёт если не о десятых долях секунды, то максимум об их единицах для моб-матриц 200 на 200 и максимум нескольких минутах — для 400 на 400.

— Согласен, — кивает академик,— проблема не в скорости вычисления, а в подготовке агрегатов данных для них и в скорости их пересылки в вычислительный центр...

— Вот здесь и возникает самая сложная часть нашей задачи, Виктор Михайлович, организация связи внутри подсистем и между ними. Исторически в нашей стране линии связи идут из регионов в центр, то есть на лицо её конфигурация типа 'звезда' с очень редкими связями между 'лучами'. 'Лучи' эти имеют разную надёжность и довольно низкую пропускную способность, что делает их практически бесполезными для целей ОГАС, которые предусматривают планирование и оперативное управление экономикой с пересылкой огромных объёмов информации. Даже лучшая по полосе пропускания линия ВЧ обычно ограничена 10 голосовыми каналами, то есть примерно 40-ю килогерцами. Оценим какая же пропускная способность каналов связи нам необходима для устойчивой работы ОГАС. Если принять вашу структуру, 100 'узлов' в регионах и 20 тысяч предприятий, то ежесуточно надо будет гонять по сетям в Центр примерно 20 Гигабайт информации. То есть, пропускная способность кабеля порядка 2 мегабит в секунду. Это конечно нижняя оценка, так как необходимо иметь резервирование на случай аварии, да и вообще полезная информация обычно составляет лишь половину от пересылаемой, так что для устойчивой работы можно смело называть число — 10 мегабит в секунду. Однако это сейчас, следует ожидать определённого роста информационного потока со временем. Разумно заложить в этот рост хотя бы десятикратное увеличение и получим 100 мегабит в секунду. Теперь разделим на 100 лучей и получим, что для нашей сети нужен кабель с пропускной способностью 1 мегабит в секунду, ну или 25 кабелей ВЧ, или 10 кабелей 'Телефункен', которые Вермахт использовали в войну для междугородней и военной связи. Ещё точнее, кабель может быть один, поскольку есть варианты кабелей с сотней экранированных витых пар в одном...

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

— Пока что только, Виктор Михайлович, лишь с пропускной способностью каналов связи, построенных на немецких высокочастотных кабелях. А вот с её организацией — есть. В случае, например, выхода из строя центрального узла работа ОГАС — диспетчеризация, платежи и планирование — прекращается до починки неисправности. А если выйдет из строя один из опорных 'узлов', то остановится работа крупного сегмента ОГАС, что равносильно входных потере данных от крупного сегмента экономики и, что влияет в худшую сторону и на управление, и на планирование ОГАС в целом. Для 'Сети сетей' же, которая предложена к реализации нашей Комиссией, центральный узел для диспетчеризации и планирования не является необходимым. Выход же из строя любого опорного узла — не будет критичным, так как его функции будут распределены между оставшимися.

— Не очень понятно.— Мотает головой академик.

— Поясню на примере, Виктор Михайлович. Ваш ОГАС имеет строгую иерархию — 1 головной ВЦ в Центре, сотни — опорных ВЦ и тысячи — абонентских пунктов. Некоторые узлы имеют связь друг с другом на физическом уровне. Весь поток первичной информации движется сверху вниз, агрегируется в узлах, обсчитывается в Центре. Команды управления идут сверху вниз. 'Сеть сетей'— работает по другому...

'Иностранное слово интернет в Комиссии не прижилось'.

— ... Опорные узлы соединены друг с другом в кольцо Диспетчер при помощи кабелей и умных коммутаторов. Сети Диспетчер и План общаются, как через шлюз — память, в которой хранится последняя версия матрицы межотраслевого баланса— так и через умные коммутаторы, которые служат накопителями агрегированных данных для планирования, но излишними для диспетчеризации. Кроме сетей Диспетчер и План имеются АСУ предприятий — Абоненты, которые соединены с Диспетчером через свои шлюзы, в них идёт накопление агрегированной первички для Диспетчера и Плана. Почему 'Сеть сетей' лучше? Из-за своей устойчивости к отказу и способностью полнее использовать пропускную способность кабелей. То есть, мы не тянем всю первичку в опорный узел, а оставляем её на АСУ предприятий, наверх же идут только агрегаты. Поэтому резка падает объём циркулирующей в 'Сети сетей' данных, а выход из строй Абонента не сильно повлияет на информационную целостность системы и её устойчивость.

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

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

— В ОГАС контроль будет двойным, Алексей Сергеевич, и на предприятии, и в опорном узле, а у вас только на предприятии.

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