Хроники инженера-разработчика. Глава 3. 8
ВИШЕНКА НА ТОРТЕ ИЛИ МЕЧТЫ СБЫВАЮТСЯ ...
Это история об "имитации", к тому же являющаяся ярким и убедительным примером того, что с появления новой техники вообще, а вычислительной, в частности, практически всегда открываются и новые возможности, да ещё какого уровня - принципиального, до толе вообще не возможного.
Даже "натурный эксперимент", а это и о самолетостроении, порой и близко, по ряду очень существенных причин, не стоит с ней.
Ниже мои хроники об этой истории, но не только.
В 1982 году вышла книга двух, если не изменяет память немецких инженеров, с интригующем названием "Имитационное моделирование производственных систем на языке GPSS".
Несколько слов о понятийном аппарате.
"Имитация (от лат. imitatio — "подражание") — это процесс воспроизведения или подражания объекту, явлению или поведению с целью копирования его характеристик.
Воспроизведение каких-либо процессов, отличительных особенностей чего-либо с возможной точностью".
И соответственно, "имитационное моделирование — метод исследования, при котором создаётся имитационная модель реального или гипотетического процесса, или системы с целью анализа её поведения и прогнозирования различных сценариев".
Его суть в том, что «изучаемая система заменяется моделью, которая с достаточной точностью описывает реальную систему.
Модель может быть представлена в виде блок-схем, диаграмм, дифференциальных уравнений и другими способами, понятными для обработки программными технологиями.
На сегодня существует несколько видов имитационного моделирования:
дискретно-событийное, системно-динамическое и агентно-ориентированное, которые уже достаточно широко применяются в различных областях, в том числе, и в промышленности.
В некоторых промышленно развитых странах, как например, в Германии дело-то зашло настолько далеко, что некоторым из наших руководителей, по-прежнему сообщения о масштабах его применения, кажутся натуральными "фейками".
К горькому сожалению, но это действительность сегодняшнего дня!
Ещё в 2010 году ознакомился с материалами международной конференции, проходившей в г. Москве.
Так вот, из доклада доцента одного из наших ВУЗов узнал, что на то время в промышленности Германии уже существовал порядок, при котором проектную документацию на реконструкцию или, тем более на постройку нового завода, без приложения протокола имитационного моделирования, эти проекты Советами директоров не рассматриваются вовсе!
В тоже время узнал и о "Tecnomatix", одного из многочисленных программных продуктов фирмы "Siemens", предназначенных для использования в промышленности.
Этот «продукт» оказался многофункциональным набором решений для автоматизированной подготовки и автоматизации производства.
Он связал воедино технологию производства и проектирование изделий, включая разработку техпроцессов, имитационное моделирование и управление производством.
Довелось и уже собственными глазами увидеть, а что действительно, выдаёт этот "Tecnomatix" на-гора организаторам и управленцам от производства.
Не скрою, впечатление от увиденного было очень убедительным!
Похоже, уже оглядываясь назад в прошлое, к началу 90-х годов, мы-то с немцами шли, что называется «ноздря в ноздрю».
Если они и дальше успешно продолжили свои разработки, довели их до своего логического завершения, то нам был объявлен натуральный локаут!
Институт наш развалился, а его сотрудники, оказавшись много месяцев без заработной платы, разбрелись в поисках лучшей доли, кто куда.
Во множестве исчезли отечественные инженерные школы разработчиков, а на смену им пришли "продукты" сплошного иноземного происхождения, взять того же "сименса".
И до сих пор, на наших заводах доля их, более чем заметная, только вот заменить-то их оказалось и не чем.
Вот как-то так получилось.
В 2013 году, уже по заданию на предмет возможности использования в нашем производстве, ознакомился и с отечественной разработкой – "AnyLogic" (рус. "ЭниЛоджик") — программного обеспечения для имитационного моделирования, разработанное российской компанией «The AnyLogic Company» из Санкт-Петербурга.
Наши ребята сделали «конфетку», причём, на очень приличном уровне, не уступавшем и зарубежным аналогам.
Основное отличие "ЭниЛоджика" состояло в том, что в нём разработчики реализовали комплексный подход к имитационному моделированию, использовали все из трёх видов моделирования - дискретно-событийное, агентное и системную динамику.
Программный комплекс "ЭниЛоджика" не просто совокупность специализированных программ, а натуральная программная платформа, с большими возможностями его функционала и сервисных «примочек».
Причём, с открытой архитектурой – путём до программирования, позволяющей пользователям уже самостоятельно адаптировать и расширять его возможности, то есть индивидуально проводить кастомизацию, ну и с "«вишенкой" в лице его прекрасного интерфейса.
К моему большому сожалению, но использовать в прямую «ЭниЛоджик» в авиационном производстве для наших задач, оказалось нам не с руки.
Хорошо представляя принцип работы, его я освоил достаточно быстро, самостоятельно создав 14 малюсеньких имитационных моделек по всем методам моделирования, которые в него и были зашиты.
Оказалось, что в нашем случае, разработчиков "ЭниЛоджика" "погубила" их же собственная суперуниверсальность, но отмечу, что в других обстоятельствах, она действительно к "месту".
При создании имитационных моделей сборочных процессов, нам к тому, что уже разработали питерские ребята, пришлось также до программировать, причём в относительном выражении, доходящем аж до 70 – 80 %.
Стало понятно, что просто проще всё, но уже на 100% разработать самим.
Но вернусь в год 1982.
Как уже известно из настоящих Хроник, на то время мы уже два года вовсю «моделировали» производственную систему завода, её важнейшую «технологическую» часть.
Правда, с помощью ДОД СУБД ИНЕС моделировали только "технологические" и "организационные" структуры, а потому, от наших моделей, большего, чем "ЧТО есть ЧТО?" принципиально иметь не могли.
Хотя и подозревали, что если организовать в Базах данных массовое хранение "событийных фактов", отнесенным к тем или иным объектам, то в последующем, их "просмотром" за определенный период времени, уже можно и получить сведения о их "движении", т.е. рассматривать не одну лишь "статику" системы, но и её "динамическое поведение".
К примеру, собирая информацию по складу, с его приходом и расходом, могла получиться, хоть и скудная, но уже его динамическая «модель».
Кстати, а вот подобных объектов, начиная с рабочих мест и их агломераций, за которыми необходимо глаз не спускать, на машиностроительных заводах хоть пруд пруди.
Этим занимаются специалисты низшей квалификации, хотя подобная работа может выполняться полностью автоматически, с применением того же штрих-кодирования.
Одним словом, знакомясь с этой новой книгой, было чертовски интересно узнать технические подробности, в первую очередь, о том, как авторы справляются с упомянутым мной "динамическим" аспектом производственных систем, применив для этого уже метод имитационного моделирования.
Ключом к их решению стала т.н. "модель-матрица состояния", элементы которой в системном или реальном времени, алгоритмически меняют свои значения.
Всего и делов-то! Изящное и простое в реализации техническое решение.
Вот бы и нам такое?!
"Охота пуще неволи".
Дождался и я возможности, правда только к середине 10-х годов уже 21 века, наконец-то, попробовать и свои силы в "имитации".
В то время так получилось, что занимался вопросами обеспечения крупносерийного выпуска нашего отечественного среднемагистрального самолета МС-21.
Потребовались многократные поверочные расчеты пропускной способности Линии сборки этого самолета под всё нарастающие объемы годового выпуска.
В основном, помимо оценки пропускной способности её "станций", составлялись и годовые календарные графики поставок.
Графики не простые, помимо необходимой квалификации, потребовавшие и немалых затрат времени, потому как выполнялись вручную в "Microsoft Project", — в американском программном обеспечении для управления проектами.
По согласованию и при непосредственном участии Николая Михайловича Медведева, курировавшего этот вопрос на заводе, для упрощения и ускорения создания этих графиков, решили автоматизировать их разработку.
Более того, совместить разработку графиков с одновременной проверкой пропускной способности сборочных станций, а учитывая, что она должна синхронно возрастать вместе с ростом годового выпуска самолетов, для этого случая готовить необходимые исходные данные.
Разработку осуществили в сжатые сроки и относительно легко, использовав дискретно-событийный метод имитационного моделирования, как наиболее подходящий для этой задачи.
Для создания "внутри-станционных" диаграмм сборочных работ, привлекли более десяти специалистов из всех нужных нам цехов основного производства завода, включая и его аэродромный цех.
Диаграммы, на тот момент запуска, содержали только экспертные структурированные оценки сборочных циклов, с учетом их снижения на "серии", аналогично динамики "кривых снижения трудоёмкости".
А специалистами, которые и разработали эти "диаграммы", стали молодые ребята, но - уже ведущие инженеры цехов, входящих в Линию сборки этого самолета.
К нашей просьбе они отнеслись с пониманием и, не смотря на внеплановую для них работу, выполнили её квалифицированно и оперативно.
Именно благодаря их усилиям, наша разработка и обрела ту, необходимую в подобных случаях объективность, благодаря которой в последующем можно было, уже с чистой совестью, доверять уже «машинным» Графикам поставки МС-21.
Нам и мне лично опять сильно повезло, потому как, нашим и единственным для разработки программистом, оказался именно он, - Роман Сергеевич Тимохин, на то время, как и его коллеги из цехов, также молодой парень.
Впервые о Романе я узнал за несколько лет до этого, как нашего заводского "хакера", взломавшего для своей инициативной разработки, коды одной "иностранки".
Тогда-то я и положил на него свой глаз, не без основания полагая, что с этим парнем, если "придется", можно пойти и в разведку.
Но то, что на самом деле произошло, уже в ходе нашей разработки, превзошло все мои радужные ожидания.
Это отдельная - очень показательная и весьма поучительная история, о том что «всё течёт и всё изменяется»!
На ней остановлюсь подробнее.
Начну с рассказа о том, как проходила наша разработка, оказавшаяся опять-таки, - впервые в истории этого завода.
Мы ничего специально не разрабатывали, в том смысле, что обошлись без классического технического проектирования, за исключением отдельных небольших "схемок", выполненных натурально на "салфетках".
В основном, это были получасовые беседы о том, что нам необходимо получить.
Первый вариант Роман представил уже через пару-тройку недель, регулярно предлагая мне, те или иные решения и доработки в наш программный комплекс, а, к тому же, мы с ним работали в удаленном режиме, экономя наше время.
И что меня, памятуя собственную практику, особенно впечатлило, за всё время нашей разработки, его программы ни разу не "с глючили" и всегда исполняли то, что и было нам надо – одним словом, высший класс, подчеркну, всегда думающего программиста!
До этого, у меня был почти десятилетний перерыв участия в разработках программных комплексов, поэтому произошедшие за это время перемены, оказались очень наглядными.
Резко возросла скорость создания кодов программ, что привело к перераспределению нагрузки между участниками подобных разработок.
Если в предыдущие десятилетия, после "постановки задачи" уже полностью рабочие программы появлялись, только спустя несколько месяцев и часто давали сбои, то сейчас ситуация кардинально изменилась – программистам, тем, которые действительно "матёрые", что называется, только подавай!
Одним словом, сроки новых программных разработок зримо снизились, что позволило их проводить в большем количестве или даже экспериментировать сверх плана.
И более того, с развитием языков программирования, появились и новые подходы "скоростного" создания новых программных продуктов.
Одним из них, по аналогии с промышленностью, стал подход на основе "макетов-демонстраторов" в разработках систем с принципиально новыми технологиями.
Его и по сей день, широко использует "DARPA" (Defense Advanced Research Projects Agency) — Управление перспективных исследовательских проектов Министерства обороны США, основанное ещё в 1958 году, как ответ американцев на запуск Советским Союзом первого в мире искусственного спутника Земли.
Этот же подход использует и наш, аналогичный "DARPA", Фонд перспективных исследований (ФПИ), созданный в России только в 2012 году.
Для создания программных комплексов, этот подход особенно эффективен.
В отличие от прототипов в "металле", которые в подавляющем числе случаев, практически невозможно "плавно" перевести в опытно-промышленные и, тем более, серийные образцы, а вот "программы" это с легкостью позволяют, чем значительно сокращают и сроки, и трудоёмкость их разработки.
Суть проста, первоначально создаётся "ядро" с открытой функциональной архитектурой будущего программного комплекса, а затем, подобно новогодней ёлки, к уже существующему коду "навешиваются" модули дополнительных программ.
В частности, выполнять такие "фокусы" под силу с использованием объектно-ориентированных языков программирования типа Java (Джава) или языков сценариев (скриптовых языков), например, языка программирования Lua из Бразилии.
Но, снова вернусь к нашей "имитации".
Нашего новорожденного назвали "Симулятором Линии сборки МС-21".
Оказался он программным комплексом с "двойным дном" - с двумя режимами, решавшими две, хотя и связанные между собой, но отдельные технические задачи. И обе, методом имитационного моделирования.
С первым режимом – для построения оперативно-календарных Графиков сборки, в разрезе вплоть до отдельно взятой сборочной станции, и Графиков поставки, непосредственно Заказчикам самолета МС-21.
Все Графики строились под заданные объемы годового выпуска, и что особенно важно для больших серий - под поточную форму организации крупносерийного авиационного производства.
Для визуализации Графика использовали стандартный "Стандарт-План" поточного производства, предложенный Владимиром Фёдоровичем Юргенсом, профессором, зав. кафедрой "Производство самолётов" Московского авиационного института (МАИ) с 1940 по 1950 годы, в книге "Общая сборка самолетов", издания М., Оборонгиз, 1944 года.
Матрица этого Графика была традиционной, в виде диаграммы Ганта, но в нашем случае, по каждой «станции» Линии сборки ещё и с указанием по шкале календарного времени "цепочки" серийных номеров самолётов и, опять наша "вишенка" - их разноцветья по календарному времени.
Именно цвет (зеленый, желтый или красный) использовали для визуализации предельно-допустимой пропускной способности станций Линии, с одновременной фиксации этого события для календарного планирования мероприятий по устранению подобных проблем на ней.
К тому же, нашему Роману Сергеевичу не составило и большого труда, конвертировать "График" уже в форму американского "Microsoft Project".
Этот режим нашего "Симулятора" позволил сократить разработку «Графика» с одного дня до 30 - 40 минут, проводить расчеты без ограничений "горизонта планирования", хоть на год или, при жгучем желании, аж и на десять лет вперед.
При этом учитывалась и «незавершенка», т.е. объемы производства, переходящие на следующий год.
Графики считал достаточно объективными, потому, как их исходные данные происходили не из теории, а были получены от специалистов «низшего» звена, на самом деле знающих действительное, текущее положение дел на Линии сборки.
Но оказалось, что "верхам" нашей сермяжной "правды" вовсе и не надо, в то время, они хотели шагать широко, но при том, забывая, что и штаны-то можно порвать.
Не переставал удивляться, тем победным реляциям, которые посыпались в преддверии серии МС-21, из наших СМИ.
Ведь те цифры, которые публично озвучивались на самых верхах, в качественном плане, пересекались и с теми данными, с которыми работал, и я лично сам.
Вторым, для нас и очень необычным, был режим «мультика» - формирования "Графика" по текущим циклам с одновременной визуализацией "движения" нашего "ЭМЭСа" по технологическому маршруту сборки, вплоть до аэродромного цеха, т.е. до сдачи уже непосредственно Заказчику этого самолета.
На мониторе персоналки наши самолеты "побежали", одновременно, порой "рисуя", и весьма неприглядные "казусы", а проще говоря тревожные "события", которые в реальном производстве могут стать серьезными рисками для достижения заводом директивных объемов годовых выпусков этого нового самолета.
В частности, наш "Симулятор" периодически и очень наглядно "рисовал" гармошки из собираемых самолетов, скапливающихся по разным техническим причинам у той или иной сборочной станции.
Именно этот пример, а вместе и со всей нашей историей об «имитации», являются тем неоспоримым, фактом «ЗА» - применению имитационного моделирования в нашей промышленности, и, в частности, в отечественном самолетостроении.
И наша практика подтвердила, что ЭТО того действительно стоит!
Ведь и мы "сами с усами", многое познать и своевременно сделать, тоже "могём" и не хуже иноземцев.
Для этого есть у нас главное - и светлые головы, и золотые руки!
Свидетельство о публикации №225111900523