В 1994 году, когда вся страна шла вразнос, а парламент стоял обгорелый после обстрела танками, я почему-то решил завязать с торговлей и поступить в МГТУ им. Баумана на кафедру «Ядерные реакторы и энергетические установки» факультета «Энергомашиностроение».
То ли потому, что детство провёл рядом со Смоленской АЭС и нахватался радиоактивных выбросов от советского реактора РБМК-1000. То ли потому, что в подростковом возрасте, будучи выгнанным из 8-го класса школы за асоциальное поведение, я поступил в Брянский машиностроительный техникум. А там один из моих преподавателей хвастался тем, что подавал документы в Бауманку - нет, поступить ему не удалось, но саму попытку он считал большим достижением. Видимо, на неокрепшие мозги 15-летнего ботаника это произвело неизгладимое впечатление. И когда я заработал на дикой торговле времён распада СССР немного денег, я решил, что надо учиться в Бауманке и стать инженегром.
В те голодные времена в университете каждый выживал как мог. Университет платил практически ничего от слова совсем. Одни бросали преподавать и шли работать кому повезло, те по специальности или близко, кому не везло, те работали, где придется. Один из наших преподавателей, подрабатывал торговым представителем и предлагал мне, как способному и перспективному студенту атомщику тоже развозить по магазинам печенье и вафли. Но я к тому времени уже был бывший владелец магазинов, и такой фигней заниматься не хотел. Я хотел быть ученым физиком или хотя бы инженером (Спойлер у меня не получилось, и американская коррупция сделала из инженера физика быдлокодера об этом я писал ранее).
Выбор подработок для младшего курса в 90-е был не велик: спорт, торговля, криминал, и все это, не выходя из стен родного университета. Представьте себе картину, ночь спорткомплекс МГТУ им. Н.Э. Баумана длинные фуры, груженные алкоголем, заезжают на задний двор, где будущие конструкторы ракетной и атомной техники сгружают ящики водки, пива, джина и таскают их в подвал спорткомплекса. А том будущие конструкторы вооружений клеят на бутылки алкоголя паленые акцизные марки, клеем БФ. С одной стороны спорт и алкоголь не совместимы, с другой стороны погрузка и разгрузка алкоголя вполне себе заменяла фитнес к тому же за него не плохо платили.
В это время на кафедре работал замечательный доцент Олег Степанович Козлов, преподавал он нам предмет «Управление в Технических Система». И он почему-то вдруг решил, что зарабатывать надо не торговлей, а разработкой программного обеспечения. Кафедра занималась ядерными реакторами и готовила конструкторов железок. Уже тогда были модные и молодежные кафедры связанные с ИТ. Но атомщики и вообще энергетик считались специалистами по говну и пару и никакого отношения как программированию и ИТ не имели. Но Олегу Степановичу было на это наплевать, он для дополнительного заработка начал разработку новой программы для динамического моделирования технических систем. Это была еще советская школа математики.
В работе участвовал Леонид Маркович Скворцов, математик от Бога, который разрабатывал собственные оригинальные методы решения дифференциальных уравнений для жестких систем. Как автор математических методов, он широко известен в узких кругах во всем мире. Достаточно простого поиска по его фамилии: например, в докладе 2025 года по инновационным методам расчета жестких задач есть ссылка на его работу 2010 года, где он отмечен как основоположник одного из двух главных методов решения проблемы устойчивости для жестких систем.
Лихие 90-е. В это время мир мучительно переходит с DOS на Windows 3.11, а в недрах Microsoft готовится уже Windows 95, после которой все последующие поколения пользователей ПК забуду�� командную строку как страшный сон.
В эти легендарные времена большинство в охеревшей стране пыталось как-то выжить, меньшинство пыталось что-то выжать или даже отжать для себя лично. Группа инженеров-математиков, как последние самураи советского образования, продолжали делать что должно, и будь что будет. Как последние легионеры империи, они выполняли свой преподавательский долг. Но что бы кушать, они параллельно, в свободное от основной работы время создавали новый программный продукт.
Программный пакет для решения задач по моделированию систем управления с дико модным в то время графическим интерфейсом.
Название продукта было максимально ура патриотичным исконно посконным: Программный комплекс «Моделирование в технических устройствах» (ПК «МВТУ»). Отсылка на старое название Бауманки - «Московское высшее техническое училище» (МВТУ). В те легендарные времена все, просто абсолютно все преподаватели и сотрудники Бауманки считали ЛГБТ экстремистом нового ректора за то, что он сменил гордое название «Московское высшее техническое училище» на обычное, серое и унылое «Московский государственный технический университет». Бауманское училище было одно во всем СССР, а вот университетов после развала СССР развелось как блох у бездомной собаки. Любой бывший заборостроительный техникум в любом мухосранске стал гордо именовать себя университетом. У бауманцев - собственная гордость, на буржуев смотрят свысока, они все считали, что нужно сохранить в названии слово «училище». Хотя сейчас, я думаю, ректор всё-таки был тогда прав. Те утырки, которые пришли к власти после развала СССР, вполне могли спутать Высшее техническое училище с каким-нибудь ПТУ (профессионально-техническим училищем) и закрыть его к чертям собачьим. А здания - бывший дворец екатерининских времён и сталинскую башню - отдать под модное казино-гостиницу с блэк-джеком и шлюхами.
И вот в таких условиях разброда и шатания наши герои пишут собственное программное обеспечение для моделирования технических систем.
Благодаря железным яйцам Олега Степановича первую версию ПК МВТУ на 286-х компьютерах под Windows 3.1 он с колёс внедрили в учебный процесс. Каждый год три группы студентов кафедры, а это около 60 человек, дисциплинированно в течение учебного года ходили в лабораторию, садились за компьютер и «использовали ПК МВТУ». Студенты, как мыши, плакали, кололись, но продолжали есть кактус - выполнять лабораторные работы по УТС на глючных компьютерах под управлением глючной Windows 3.1 в глючной версии ПК МВТУ версии 1.0. И я тоже был среди этих студентов. И не было большей радости у нас, малолетних дебилов, чем найти в ПК МВТУ ошибку, чтобы Олег Степанович подошёл и сказал: «Нихера себе, как девки пляшут!». Это означало, что вечером в команде разработчиков будут разборки и кого-то будут бить. Потом, когда я стал разработчиком в этой команде, били уже меня - за мои косяки, которые всплывали, когда тупые рукожопые студенты пытались мои волшебные компоненты использовать в своих лабах.
В итоге такого лютого тестирования в кратчайшие сроки качество ПО стало таким, что спустя 25 лет в одном из конструкторских бюро бодрый дедушка поймал меня за галстук в коридоре и говорил так: «Вот ПК МВТУ 3 - это был классный продукт, его писали настоящие инженеры, а ваш сраный SimInTech пишут какие-то полупокерсы».
В 2025 году мне показывали тренажер буровой установки, который запускался и работал! Вот, кстати, видео:
Получив отличный продукт, в котором можно решать учебные задачи теории автоматического управления и не только, авторы его попытались продавать для вузов, но увы денег тогда не было у ВУЗов, его пришлось раздавать бесплатно. А поскольку все стабильно и отлично работало, до сих пор ПК МВТУ - это первый в бывшем СССР программный продукт по количеству изданных вузовских методических материалов. Даже книжки по МВТУ выпускались независимыми авторами в различных вузах. И даже сейчас поиск по ПК МВТУ выдает целый список лабораторных работ от разных авторов в разных концах бывшего СССР.
После 1998 года в страну потянулись за деньгами производители западного ПО. Для начала мировая закулиса рептилоидов в лице Билла Гейтса и Microsoft приучила пользователей платить за софт не на «горбушке», а в кассу. Приучила с помощью кнута в виде «маски-шоу» с ОМОНом и пряника в виде откатов, которые по бухгалтерии западных компаний можно было брать на затраты. Потом потянулись производители инженерного ПО, и началась кровавая баня.
Это было как орда кочевников, нападающая на мирных земледельцев. Западные компании пачками скупали инженеров в свои команды продавцов, как монголы Чингисхана в боевые отряды своей орды загоняли завоёванные народы. «Боинг» покупал за копейки русских инженеров из разваленной авиации и сажал этих инженеров за обезьянью работу по перерисовыванию бумажных чертежей в САПР CATIA.
Западные производители ПО открывали представительства в России, где сидели завоеванные аборигены и меняли файлы лицензий на твердую валюту. Поскольку завоеватели давали дистрибьюторскую скидку аборигенам, куча народу ломилась к ним в офисы поучаствовать в грабеже территорий.
Я сам поучаствовал в этом празднике жизни, продавая французский САПР CATIA.
Наверное, ПК МВТУ как продукт тоже канул бы в Лету, как и множество других продуктов. Тем более, в далеком 1994 году, когда разработчики в МГТУ только начали пилить МВТУ, компания Mathworks уже выкатила свою нашлепку на MATLAB - Simulink. Этот самый Simulink через 10 лет пройдется катком по вузам России и посадит почти всех преподавателей теории автоматического управления на диаграммы Simulink, как англичане посадили китайцев на опиум в XIX веке, или как в отместку китайские барыги подсаживают на фентанил американцев в XXI веке, а весь остальной мир - на китайскую электронику и ширпотреб.
А в это время отечественная разработка медленно, но не уклонно погибала как крейсер Варяг. Хотя разработчиков было достаточно много. Например, на сайте Exponeta, до того, как его купили экстремисты ЛГБТ, в разделе ПО, еще в 2006 году отечественных разработчиков было больше, чем западных. Инетрнет, что характерно все помнит:
https://web.archive.org/web/20060615214736/http://www.exponenta.ru/soft/Others/others.asp
И, вполне возможно, ПК МВТУ, ��есмотря на его крутость, а он был реально круче любых других западных конкурентов, тоже бы тихонько загнулся как многие другие отечественные моделирующие программы.
Но не было счастья, да несчастье помогло. Разработчиков ПК МВТУ спасло то, что еще раньше, в 1986 году, советский реактор РБМК в Чернобыле не выдержал испытаний, которым его подвергали любознательные советские ученые, и взорвался. С тех пор у специалистов атомной сферы появилось новое определение степени устрашения - «страшный, как РБМК».
После Чернобыля во все требования к проектируемым реакторам добавили обязательную часть проекта - углубленный отчет о безопасности, для которого необходимо было выполнять математическое моделирование процессов, и без этого моделирования проект нельзя защитить. Хочешь не хочешь, но на вопрос надзорных органов: «Не ипанет?» - отвечать «Не должно» нужно было с математическим доказательством на руках в виде расчетов с помощью математической модели. Так конструкторы ядерных реакторов приучились проводить моделирование технологических процессов.
И так получилось, что генеральный конструктор реактора РБМК - Научно-Исследовательский и Конструкторский Институт Энергетических Технологий (НИКИЭТ) - был базовым институтом для кафедры, где уважаемый Олег Степанович Козлов издевался над студентами с помощью предмета «Управление в технических системах» на лекциях и ПК МВТУ на лабораторных работах. Как это было принято в те времена, проектный институт привлекал кафедру к выполнению работ. Одной из таких работ стала модернизация системы управления реактора РБМК. К этому времени советская аналоговая система управления АЭС уже устарела, и нужно было менять ее на цифровую, но всем было страшно — это же РБМК.
Тут-то разработчикам ПК МВТУ карта и поперла. Появилась реальная большая задача для реального объекта атомной индустрии. Почему большая? Да потому, что в отличие от самолета, автомобиля, танка или даже корабля, АЭС не имеет ограничений по массе оборудования и электропитанию. А это значит, что конструкторы и проектировщики АЭС могут не думать о том, сколько и каких датчиков ставить в систему управления и безопасности. Сколько нужно проектанту, столько и поставим, а нужно два раза по много (резервирование) и еще немного! А потом по требованиям безопасности все еще раз удвоим и утроим. Трехканальная система безопасности называется. Гуляй, рванина - места на АЭС всем хватит. В итоге система управления и безопасности превратилась в безумного монстра с тысячами листов диаграмм, которую не то что математически моделировать, но просто представить одному человеку сложно.
Интересно, что в первом атомном реакторе система безопасности представляла собой стержень-поглотитель, висящий на канате над активной зоной, и топор, лежащий рядом. Топором надо было перерубить канат для аварийного сброса стержня и остановки реактора. Правда, это был американский реактор. В советском реакторе этот топор бы скоммуниздили, не дожидаясь конца первой смены. Поэтому в советских реакторах с самого начала инженеры делали автоматику: сначала аналоговую, потом по мере появления компьютеров - цифровую. И если для аналоговой автоматики и первых вычислителей еще нужно было думать о количестве сигналов, сложности алгоритмов, объеме памяти, то с появлением промышленных компьютеров никаких ограничений не осталось: хоть тысячу сигналов, хоть миллион, хоть десять миллионов, а по массе и потреблению электропитания ограничений и не было. Компьютер все стерпит и переварит.
И вот в НИКИЭТ появляется задача — заменить аналоговую Управляющую Систему Безопасности Технологическую (УСБТ) для реактора РБМК на цифровую. А прежде, чем ее менять, надо бы проверить ее на модели; мало того, что это требования МАГАТЭ, так и просто ссыкотно. Как говорят опытные инженеры и программисты: «Работает — не трогай». Но тут деваться некуда, время службы памяти на ферритовых сердечниках подошло к концу, надо трогать, надо.
Можно, конечно, взять Matlab Simulink, благо он уже появился, и некоторые малолетние дебилы (я в их числе) даже его научились использовать для УТС в вузах. В это время Simulink, как раковая опухоль в здоровом теле, как СПИД среди наркоманов и гомосеков, уже распространяется в системе российского высшего образования, и многие дебилы его считали лучшим мировым решением. Но проблема в том, что он в 1998 году не считает такие большие модели, как модель управления для РБМК. И поэтому создать модель автоматики реактора в Simulink для проверки системы управления просто невозможно. Что делать, шеф? Все пропало, гипс снимают, кл��ент уезжает!
А тут на белом коне — Олег Степанович Козлов, во главе шайки инженеров-математиков, с ПК МВТУ наперевес:
— Не ссать, давайте сюда, мать вашу, УСБТ! Мы ее отмоделируем со всех сторон, как тузик грелку, вместе с реактором и турбиной на сдачу.
И шо вы думаете? Таки да! Задача, непосильная в те времена для американского MATLAB Simulink, легко и непринужденно считается в Программном Комплексе «Моделирование в Технических Устройствах» (ПК МВТУ). Созданного в свободное от основной работы время командой под управлением преподавателя управление в технических системах. Не зря его на 286-х процессорах тупые студёны мучали 5 лет.
Как пишут в рекламе: чтобы решить вашу проблему математического моделирования сложных систем, возьмите простую советскую… школу математики. Так ПК МВТУ вместе с моделированием внедряется в процесс проектирования систем управления для страшного РБМК и, более того, в нем создается, не побоимся этого слова, цифровой двойник реактора РБМК Смоленской АЭС. Да, и это всё за 25 лет до того, как это стало модно и молодежно.
В те далекие ламповые времена службы безопасности еще не зверствовали, как американские каратели в окрестностях Сайгона, и поэтому результаты сравнения реальных режимов работы с результатами модели можно было спокойно получить в институте и даже опубликовать в научном журнале и презентациях.
И теперь мы с гордостью можем показывать слайды из 2004 года, на которых сравнивается переходной процесс при режиме аварийной защиты номер 5 (АЗ-5 — снижение мощности реактора на 50%), рассчитанный в ПК МВТУ и полученный на реальном реакторе РБМК.
Примерно в то же самое время в «Газпроме» еще не сбылись мечты, потому что американский жулик Браудер и его бухгалтер Магнитский еще пытались скупить акции народного достояния через фирмы-прокладки учрежденными башкирскими инвалидами для экономии на налогах. И если деньги появлялись где-то в научных организация рядом с Газпромом, то только случайно. Так случайно в одном из подразделений ООО «Подземгазпром» возникла задача оптимизации процесса работы подземных хранилищ газа, и там случайно появились деньги.
В то голодное время, если у вас были деньги, тогда к вам приходили либо бандиты, либо проститутки, либо голодные ученые. Бандиты прийти не смогли, потому что это ООО находилось на территории Курчатовского института, где есть радиоактивные материалы, военная охрана с колючей проволокой и контрольно-следовой полосой. Проституток тоже не особо пускали, ибо стратегический объект. Остались голодные ученые-математики, у которых есть справка о третьей форме допуска еще с кафедры «Ядерные энергетические установки». Казалось бы, где ядерные реакторы, а где газовые хранилища? Но когда хочешь есть, еще не так раскорячишься. Кто девушку кормит, тот ее и танцует. Или любой каприз за ваши деньги.
— Вам нужен программный комплекс моделирования подземных хранилищ газа в каменной соли?
— А у нас совершенно случайно он есть!
— Подержи мое пиво, я сейчас заставку сменю.
Как говорится, найди три отличия:
Так ПК МВТУ превратился в ПК МПХГ и был верифицирован на реальных данных с реального газового хранилища.
…С помощью ПК МПХГ была создана расчётная схема процесса отбора из Ереванского ПХГ, которая включает в себя все подземные резервуары, скважины и наземное оборудование (трубопроводы, задвижки и т. д.) этого хранилища. В качестве исходных данных для расчётов принимались экспериментальные данные, полученные на Ереванском ПХГ в 1986–1989 годах…
…Реализация созданных методов в виде программного комплекса стала возможна благодаря участию в этой работе к.т.н., доцента МГТУ им. Н.Э. Баумана Козлова О. С. …
Казалось бы, что может быть общего между ядерными реакторами и хранилищами газа? Необъяснимо, но факт! Математическое моделирование и оптимизация систем управления делаются одним и тем же продуктом и одними и теми же людьми — и для ядерных реакторов, и для газового хранилища. Как говорится, плохому танцору яйца мешают, а хорошему помогают! Советская математическая школа позволяет решать любые задачи в любых областях науки и техники.
Для меня самым удивительным фактом во всей этой истории является то, что разработка ПО велась в свободное от основной работы время, без всякого заказа преподавателем УТС. Олег Степанович Козлов работал преподавателем на кафедре, и его основной обязанностью было учить дебилов-студентов — с чем он, как я на себе испытал, прекрасно справлялся. Другие участники разработки работали кто где, часто в других проектных организациях. При этом команда продолжала дописывать программный продукт ПК МВТУ, фактически в свободное от основной работы время, и потом применять его в своих проектах.
Одним из очередных крутых проектов стало создание полномасштабной динамической математической модели для АЭС «Бушер». Надо напомнить, что уже в те далекие времена Иран был под санкциями, и куча «партнеров» не могла попасть в этот проект, чтобы откусить кусочек от денег за русские АЭС. Более того, на этом проекте даже украинские турбостроители из Харькова зассали работать.
Во многих других стройках АЭС за рубежом эффективные менеджеры с большим удовольствием включали в проекты западных поставщиков, чтобы меньше париться. Например, для китайских АЭС с нашими реакторами систему управления делал Siemens. Причем наш ВНИИА им. Духова честно купил лицензии у АО «Сименс» на программно-технические средства АСУ ТП ТПТС51, но для китайской АЭС все равно пришлось привлекать немцев.
Существует легенда, что Siemens, продав лицензии на средства АСУ ТП ТПТС51 нашему институту ВНИИА им. Духова, рассказал китайцам сказку, будто тупые русские купили у него устаревшее дерьмо динозавров, а лучшие и современные технологии немцы оставили себе. И поэтому китайцы потребовали на наш реактор ВВЭР-1000 поставить АСУ ТП от Siemens. Будь у наших проектантов яйца, они бы заставили китайцев купить и наше АСУ ТП, но мягкотелость дефективных менеджеров помешала.
С АЭС «Бушер» — другой коленкор. Может, Siemens и рад был бы влезть со своими контроллерами в этот проект и отжать немного денег у русских лохов, но санкции дядюшки Сэма уже тогда этого не позволяли.
Получилась интересная ситуевина. Новый проект, в котором нельзя использовать старые советские готовые наработки по автоматике, потому что в 90-е все эти разработки глубоко устарели. Например, средства контроля и управления блочного пульта АЭС создавались на основе архаичных средств: стрелочных приборов, самописцев, световых индикаторов, ключей индивидуального управления оборудованием и т. п.
БЩУ (блочный щит управления) советской АЭС — это стена с сотней стрелочных приборов, индикаторов-лампочек и тысячами кнопок, рубильников и переключателей. Причем, как я уже писал выше, проблем с массой и электроэнергией на АЭС нет, поэтому добавить парочку контролирующих систем и с десяток кнопок при модернизации для улучшения безопасности вообще не составляет труда.
В итоге фантазия разработчиков упиралась только в размер комнаты и пультов. Можно сравнить количество кнопок на двух фотографиях БЩУ советского реактора: начала эксплуатации и после нескольких модернизаций. Как говорится, прогресс налицо, вернее, на лицевой панели пульта, где кнопки теснятся, как клавиши на клавиатуре ПК, только их количество приближается к числу иероглифов в китайском языке.
С другой стороны, в проекте нет западных компаний, у которых не было 10-летнего провала в развитии технологий, чтобы взять в проект готовые решения. По сути, нам нужно было быстро изобрести велосипед с нуля, который на Западе уже был примерно готов. Например, у французов в это время БЩУ АЭС выглядела примерно так:
Если вам показалось, что ситуация что-то подозрительно знакома, то вам не показалось!
Это было именно оно, пресловутое импортозамещение, за 30 лет до того, как это стало модным и молодёжным видом спорта.
…По требованиям МАГАТЭ в центре АСУ ТП должна находиться интегрирующая часть — вычислительная система верхнего блочного уровня (СВБУ), которая должна централизовать информационные потоки и предоставить оперативному персоналу АЭС удобные, надежные и быстрые средства управления АЭС, на современном уровне решать как традиционные задачи, так и задачи, повышающие уровень безопасности АЭС.
СВБУ должна быть основным средством контроля и управления системами нормальной эксплуатации. Это было новым для 1997 года решением для отечественной атомной энергетики…
Вдумайтесь: 1997 год, три года прошло после расстрела парламента, в стране бандиты стреляют друг в друга и взрывают Березовского. Пирамида ГКО уже готова обрушиться, а тут нужен проект СВБУ на новых принципах.
И там было разработано вообще всё, от слова совсем: операционная система реального времени на базе Linux, собственный язык программирования ABIS!!! для описания алгоритмов управления верхнего уровня.
«…С использованием языка ABIS была разработана программная платформа «ОПЕРАТОР», реализующая функции SCADA-систем для объектов большого размера (свыше одного миллиона сигналов):
— с непрерывным, не отключаемым режимом работы (более 30 лет);
— с повышенными требованиями по надежности, безопасности и киберзащищенности;
— способная интегрировать в единую АСУ ТП программно-технические комплексы нижнего уровня различного типа, импортного и отечественного производства…»
И всё это необходимо протестировать и отладить. Все, кто хоть раз что-то программировал, знают, что написание кода — это самая простая и малая часть работы, а вот заставить этот код работать как надо — это отдельный вид спорта. Тем более что это ПО будет управлять АЭС. Как проверить всё это хозяйство, откуда взять свыше одного миллиона сигналов?
Проблема в том, что для того, чтобы качественно отладить СВБУ, нужно иметь готовую низовую систему управления, которая поставляет для неё данные. Но сами технологические системы управления на базе ТПТС в реальности распределённые. Чтобы собрать и отладить новую СВБУ, нужно собрать все стойки этой системы управления, а они в это время ещё проектируются и изготавливаются. Как тут быть? Сидеть на попе ровно и ждать, пока соберут все элементы, а потом начать собирать и отлаживать в последний момент перед отправкой, или что-либо придумать?
Возникает идея собрать алгоритмы АСУ ТП в виде математической модели, которая и будет выдавать для СВБУ всю необходимую информацию, таким образом обеспечивая проверку системы во всех режимах. До этого никто ничего подобного не делал: одно дело — наращивать алгоритмы управления и усложнять систему управления, постепенно добавляя датчики тут и там в процессе модернизации реальной АЭС; другое дело — собрать всё это в виде единой модели АЭС и заставить работать вместе с реальной СВБУ.
А это вообще возможно? Всё возможно, если у вас есть советская математическая школа и ПК МВТУ с командой разработчиков во главе с Олегом Степановичем Козловым. Часть команды разработчиков ПК МВТУ в это время уже работала в Московском «Атомэнергопроекте». В этот момент родилась проектная полномасштабная динамическая математическая модель (ППДММ) «Радуга-ЭУ», где для моделирования нейтронной физики и течения теплоносителя в активной зоне использовалась программа «Радуга», для моделирования турбины — программа ТРР, а все алгоритмы первого и второго контура собирались в ПК МВТУ.
Программы для моделирования нейтронной физики и тепло-гидравлических процессов в то время были уже готовы. Их использовали для обоснования безопасности, а вот собрать полный набор алгоритмов управления и объединить все эти программы в единую модель — такого ещё никто никогда не делал. Но нет тех вершин, которые не смогли бы взять коммунисты, вооружённые единственно верной теорией автоматического управления и ПК МВТУ.
Кроме объединения математических моделей в единый комплекс ПК МВТУ — единственная в тот момент программа моделирования в ядреной индустрии с графическим интерфейсом под Windows — была использована для создания видеокадров управления для отображения математических моделей. Так, например, выглядел обобщённый видеокадр для модели турбины в ТРР.
В ПК МВТУ был создан редактор, где пользователи рисовали принципиальную схему модели, и было сразу видно, что и куда течет, что включено, что выключено и где система ведёт себя не так, как проектировалась. По сути дела, это тот же видеокадр оператора, но только для модели. Он отображает не то, что нужно для управления реактором оператору, а то, что нужно разработчику, чтобы понять, где он накосячил, когда создавал модель. А если создается модель алгоритмов, то можно выявить на стадии создания ошибки в этих алгоритмах. В итоге при создании алгоритмов управления в ПК МВТУ одновременно осуществлялась их проверка и тестовая модель для СВБУ.
В этом проекте впервые была реализована еще одна гениальная идея.
Дело в том, что все существующие к 1994–1997 году расчётные программы для обоснования безопасности АЭС были написаны под командную строку, и модель для расчета создавалась в виде текстового файла, в котором описывалась геометрия проектируемой установки. Например, схема, изображенная на рисунке выше, создавалась в виде текстового файла формата, который понимал расчётный код ТРР, как на следующем рисунке:
Этот текст следовало набрать в текстовом файле с псевдографикой, обязательно в кодировке «Кириллица IBM866». Особенно здесь умиляет пояснение к тексту:
«…Если расчет канала выполняется в другой программе, то в массиве REGOUT передаются комплексы в следующей последовательности: ROGH, ZROF, SLF, Pnas, Hout, Cout, Qto, Tout. Признаком является отрицательное значение числа элементов в канале (Nel), а abs(Nel) есть адрес ROGH в массиве REGOUT (ROGH = REGOUT(abs(Nel)), ZROF = REGOUT(abs(Nel)+1) и т. д.). Если значение номера элемента с насосом (Nnas) отрицательно, то напор насоса определяется в метрах перекачиваемой жидкости…»
Когда модель используется для расчёта в обосновании безопасности, можно представить человека, который освоит этот метод ввода данных со всеми этими правилами и будет создавать модели и выпускать отчеты. Но когда вам нужно быстро сделать модель для вновь проектируемого реактора, которую будут использовать для моделирования режимов с целью отладки БЩУ, такой способ ввода нельзя назвать оптимальным — тут только для его освоения нужно потратить месяцы, если не годы.
К тому же при создании большой модели нужно привлекать специалистов разных специальностей, а не только расчетчиков. А как известно, настоящий специалист подобен флюсу: полнота его односторонняя. И заставить специалиста по управлению турбиной или КИПовца осваивать новый язык представления моделей — это как взрослого медведя из леса учить танцевать.
В то же самое время расчетные коды — и «Радуга», и ТРР — уже обкатаны во многих проектах, на них произведена куча расчетов, и изменять их способ ввода тоже потребует немалых временных затрат.
Казалось бы, выхода нет, всё пропало — гипс снимают, клиент уезжает. Но и тут, как Чип и Дейл, спешат на помощь разработчики ПК МВТУ. Они же изначально создавали пакет как визуальную среду разработки. Чтобы новые пользователи не мучались, создавая модели в виде текста на неведомом языке программирования, мы дадим им инструмент для создания модели в виде понятных диаграмм.
Пусть инженеры создают принципиальную схему установки, задают параметры элементов (диаметры, шероховатости, сопротивления и т. п.), а все нужные текстовые файлы будут созданы автоматически генератором модели!
И чтобы два раза не вставать, нарисованная модель будет одновременно и отображать параметры процесса во время расчета, и обеспечивать управление этой моделью для удобства отладки.
Одним выстрелом убивается не два зайца, а целых пять. Это уже не охота, а браконьерство, и ПК МВТУ тут как запрещенное оружие массового поражения:
Не нужно изучать, как в текстовом файле на неведомом языке создавать сложную модель АЭС.
Модель в виде принципиальной схемы сама является документом, который понятен любому технологу-проектанту, и его можно привлекать к созданию.
Модель в процессе расчета отображает процесс как видеокадр — отладка ускоряется в разы.
Никаких изменений в само расчетное ПО не вносится. Аттестованные и сертифицированные программы «Радуга» и ТРР работают, как и прежде. Дополнительной верификации моделей не требуется.
С диаграммы можно управлять моделью как с пульта оператора для тестирования и отладки режимов работы АЭС.
В итоге модель АЭС во время создания выглядит как показано на рисунке:
А когда мы запускаем расчет, ровно таже модель выглядит, как показано на следующем рисунке:
Четвертый заяц сначала тогда казался collateral damage. Ну, сделали, чтобы быстрее собирать модели, и сделали, пусть будет.
Но в дальнейшем, при развитии ПО, этот заяц сыграл ключевую роль.
Оказалось, что моделирующее ПО начали писать все атомные институты ещё с 1986 года. Вот прямо с аварии и бросились писать расчётный тепло-гидравлический код. И к 2000 году такого кода накопилось уже выше крыши, и мало того, что почти всё написано на Фортране или Си, так он ещё и активно используется и содержит в себе кучу готовых, и, главное, проверенных на практике и верифицированных решений. При этом изучать языки ввода для создания моделей — это как изучать второй иностранный. И поэтому тепло-гидравлический код везде был как чемодан без ручки: и нести тяжело, и выкинуть жалко.
А после 90-х на все предприятия приходит новое поколение малолетних дебилов, которые не то что писать на специальном языке — они даже на обычном языке читать не могут, не говоря уже о том, чтобы писать на специальном. А те, кто может быстро изучить язык программирования, сразу идут в Microsoft, Яндекс или Google, где им платят гораздо больше.
Что делать? Как сохранить тайные знания великих предков?
И тут опять приходит на помощь шайка математиков-инженеров с ПК МВТУ:
Мы к вам приехали на час,
Привет, бонжур, хелло.
А вы скорей любите нас!
Вам крупно повезло!
Мы берём ПК МВТУ, ваш старый советский боевой, проверенный годами расчётный код. И лёгким движением руки превращаем описание моделей на непонятном языке древней и более развитой цивилизации в понятные даже малолетнему дебилу тепло-гидравлические, электрические, логические принципиальные схемы или функционально-блочные диаграммы алгоритмов.
И это не только в отсталой стране России так — точно такая же ситуация и с расчётными атомными кодами в других странах. Про США я писал здесь...:
Вот пример из Германии из 2024 года — вы не поверите, это работает до сих пор. https://t.me/Tech_Petuhoff/643
А первое боевое применение этой идеи было сделано в лихие 90-е.
Понятно, что по законам жанра, после того как полигон проверки АСУ ТП «Бушер» доказал свою работоспособность, началось, как всегда и везде, награждение непричастных и наказание невиновных.
На других проектах, где не было санкций, немецкий Siemens влез в проекты. Так в китайских проектах ВВЭР и АСУ ТП, и БЩУ отдали делать немцам. Но при этом даже на фотографиях видно, что импортозамещённый БЩУ АЭС «Бушер» 90-х выглядел более современным, чем его западный аналог от Siemens того же времени, как говорится, почувствуй разницу:
По мере выползания страны из кризиса 90-х эффективные менеджеры в России начали закупать западный софт везде, где можно и нельзя. И уже на следующем полигоне АСУ ТП для моделирования АЭС вместо «Радуга-ЭУ» использовали американскую тренажёрную систему, в девичестве называемую S3. Но самое смешное, что графическую систему подготовки данных для американской системы моделирования снова купили у разработчиков ПК МВТУ.
И ещё через 10 лет я был на семинаре, где шёл доклад об успехах полигона АСУ ТП на американской системе моделирования. Докладчик был участником Бушерского проекта. На перерыве он мне признался: «Какая же гадость эта американская система, вот полигон АСУ ТП с “Радуга-ЭУ” и ПК МВТУ для АЭС “Бушер” — это было реально круто».
До импортозамещения оставалось каких-то 20 лет.
Подписывайтесь на канал Технолог Петухов там больше и без цензуры
