В начале 2000-ых мне довелось немного поучаствовать с создании московского монорельса. Участвовал я так, немножечко с краешку, но некоторые впечатления остались, которыми и хочу поделиться. Фотографии из моего личного архива.

Я тогда был программистом, специализирующимся на программах для обмена данными на верхнем уровне автоматизированных систем (для тех, кто в теме - OPC-серверов). Моё участие в проекте началось, когда уже была запущена экспериментальная трасса, и пора было переходить к созданию своей системы.

Несколько слов об экспериментальной трассе. Она была построена на территории московского института теплотехники, имела полкилометра в длину, и по ней туда-сюда ездил состав из двух вагонов, купленный в Швейцарии. Ездил в автоматическом режиме, без машиниста. Этот поезд, с учётом того, как он себя покажет на экспериментальной трассе, должен был стать прототипом для разработки наших поездов, которые делались в Екатеринбурге. Я однажды участвовал в каком-то совещании на территории института теплотехники и видел эту трассу и этот поезд, но фотоаппарата с собой не было, так что помещаю здесь его фотографию, позаимствованную с официального сайта тех времён.

Планы были наполеоновские. Предполагалось, что трасса от ВДНХ до Тимирязевской станет пилотной, на которой будут отработаны все технологии, после чего начнётся строительство больших линий. Помню, планировали дорогу от м. Коломенская до МГУ и ещё какие-то длинные трассы.

Фирма "Московские монорельсовые дороги", созданная для управления всем этим процессом, для технической части проекта наняла "не-помню-как-называется" организацию (я её буду дальше называть заказчиком, потому что для нас заказчиком была именно она), которая, в свою очередь, разбила задачу на несколько систем, и для каждой наняла свою фирму. В частности, та, где я работал, делала систему центрального диспетчерского управления (СЦДУ). Чтобы испытывать систему, пока поезд и трасса не готовы (имеется ввиду не экспериментальные, а реальные трасса и поезд), планировалось сделать программу, эмулирующую движение поездов. Моей задачей было обеспечение передачи данных из этого эмулятора в нашу диспетчерскую систему. Пару раз я съездил на совещания, вроде начал договариваться о способах обмена данными, а потом всё заглохло. То ли с разработчиками эмулятора не договорились по деньгам, то ли они что-то такое сделали, что было решено не продолжать работу, точно не знаю. Факт в том, что эмулятор сделан не был, и моё участие не потребовалось.

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

Я снова подключился к этому проекту, когда трасса была построена, первый поезд почти готов, все системы тоже вчерне готовы, и встала задача научить их взаимодействовать. Первое совещание по этому вопросу, в котором я участвовал, произвело на меня удручающее впечатление. Наша СЦДУ должна была получать данные от пяти других систем: СУ ЭПС (система управления электроподвижным составом, т.е. система, установленная на бортовом компьютере поезда), АСДУ-Э (автоматизированная система диспетчерского управления энергообеспечением ), СУ ПДП (система управления путевыми датчиками положения), СУ СП (система управления стрелочными переводами) и ещё одной СУ, названия которой я не помню. На тот момент все деньги были поделены, причём без учёта работ по наладке взаимодействия, поэтому никто не хотел брать на себя дополнительных обязательств, и каждый пытался сделать так, чтобы вся работа легла на другую сторону взаимодействия. В итоге выяснили, что те платформы, на которых разработаны СУ ПДП, СП и та, названия которой я не помню, поддерживают стандартный протокол ModBus, и с ними вопрос был решён - наша платформа тоже его поддерживала. Оставались ЭПС и АСДУ-Э.

Ребята с ЭПС были самыми адекватными, они изначально понимали, что поработать придётся, и с ними не возникало проблем ни тогда, ни после. Мы быстро договорились о формате обмена и закрыли вопрос. Немного портили картину только попытки нашего заказчика вмешаться в технические вопросы, в которых он ничего не понимал. В частности, было требование включать в каждый пакет, который пересылает поезд системе, уникальный номер поезда, чтобы не перепутать, от кого что пришло. Мы с двух сторон пытались объяснить, что это не нужно, потому что выбранный для связи протокол TCP и так обеспечивает идентификацию отправителя, дублировать эту информацию на верхнем уровне не нужно, но заказчик не хотел нас слышать. В конце концов я шепнул товарищу с ЭПС, что ну его, заказчика, на фиг, не будем сейчас спорить, а потом сделаем так, как нужно. Так и получилось.

Первые версии программы для связи с поездом приходилось испытывать так, как показано на фотографии. Сеть ещё не была готова, поэтому я с ноутбуком спускался в депо, залезал в недостроенный поезд, подключался к нему по проводу и отлаживал свою программу. Это дало мне возможность погулять по депо (людей там, почему-то, не было) и сунуть свой нос туда, куда я его совать не должен был. Например, посидеть на месте машиниста.

Так выглядят приборы в кабине машиниста.

Рычаг управления движением может нажиматься (или сдвигаться влево, точно не знаю). Это нужно для контроля внимания машиниста. Время от времени звучит сигнал, и машинист должен нажать на рычаг. Если этого не происходит, система считает, что с машинистом что-то случилось, и экстренно останавливает поезд. Держать рычаг всё время нажатым система не допускает.

С этой системой связана одна забавная история. Наша СЦДУ, естественно, получала информацию обо всех инициированных системой аварийных торможениях и записывала эту информацию в лог, который потом можно было посмотреть. Но вскоре после начала испытательных поездок диспетчеры попросили, чтобы эта информация не только писалась в лог, но и показывалась на главном экране в режиме реального времени. Оказалось, что машинистам понравилось при подъезде к станциям специально переставать реагировать на сигналы системы, чтобы поезд останавливался сам. Это приводило к потерям энергии, так как обычное торможение было сделано рекуперативным (т.е. часть кинетической энергии поезда возвращалась в сеть в виде электричества), а экстренное торможение рекуперативным не было. По логам было трудно уличить конкретного машиниста в нарушении правил, вот и понадобилось отображение в реальном времени, чтобы отучить машинистов от такой привычки.

А вот так собирались поезда, прямо на рельсе.

Недособранный поезд внутри.

А это трансбордер (поворотный круг). Поезд заезжает на поворотный рельс, который затем поворачивается так, чтобы оказаться напротив нужной линии, на которую поезд съезжает с круга (это называется депо веерного типа). В этом помещении меня вообще не должно было быть, поэтому я так, одним глазком заглянул, отсюда и неудачный ракурс.

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

Но теперь проблемы начались на нашей стороне. SCADA-система Citect, на которой мы строили свою СЦДУ, конечно же, умела получать данные через OPC, но при этом напрочь игнорировала тот факт, что OPC-сервер может находиться на другом компьютере, в результате чего связь с ним может быть потеряна из-за неполадок в сети или перезапуска того компьютера, и эту связь надо автоматически восстановить, как только появится такая возможность. Потерю связи Citect замечал минут через 15, а восстанавливал спустя один-два часа, если вообще восстанавливал. Для автоматизированной системы реального времени такое неприемлемо. Но это его поведение для нас новостью не было, мы уже решали такую проблему в другой системе - в системе управления кондиционированием, вентиляцией, отоплением Успенской Звонницы. Я тогда написал свой OPC-сервер, который запускался на том же сервере, что и Citect (поэтому разрывов связи между ними не было), а сам получал данные от удалённого сервера, нормально реализуя проверку и восстановление связи с ним (ну, условно нормально - в майкрософтовском COM, на котором базируется использовавшийся в системе OPC DA 2.05, очень плохо проработаны вопросы потери и восстановления связи, приходилось прыгать с бубном, чтобы обеспечить какую-то видимость нормальной работы). Я взял свой сервер из той системы и настроил его для работы с сервером АСДУ-Э, даже дописывать ничего не пришлось. Решение получилось откровенно ублюдочным, но хотя бы работало. К сожалению, это обычная практика, когда из-за недостатков основного продукта приходится прибегать к таким вот костылям.

Но вот поезда собраны, начались экспериментальные поездки.

Поезд выезжает на тестовый маршрут.

Вскоре после этого в нашу фирму поступила претензия - моя программа регулярно теряла связь с поездом. Я отправился в диспетчерскую решать проблему на месте. Некоторое время безуспешно искал у себя ошибку, пока моя начальница не догадалась запустить параллельно с моей программой пингование (это проверка работоспособности сети), и стало видно, что программа теряла связь как раз в те моменты, когда переставал проходить пинг. Мы показали это заказчику, он позвал представителя фирмы, которая отвечала за радиоканал для связи с поездом, и тот без тени смущения заявил, что всё в порядке, это же радиосвязь, она никогда не будет такой же устойчивой, как связь по проводу, город, помехи, всё такое. Они, конечно, ещё настроят своё оборудование, чтобы уменьшить количество разрывов, но они всё равно будут регулярно случаться, и надеяться на иное бесполезно. Мне в этот момент захотелось чем-нибудь его стукнуть - ведь это был тот самый человек, который на том памятном совещании по взаимодействию стучал себя пяткой в грудь на тему того, что они обеспечат идеальную связь. Именно из-за его слов для связи с поездом был выбран протокол TCP, чувствительный к таким разрывам. Если бы мы с разработчиками поезда ещё тогда знали, что так будет, то настояли бы на использовании UDP, в котором нет сложной процедуры установления связи - ну, пропадёт несколько пакетов, и фиг с ними, характер обмена данными такое допускал, а разработка программы и для меня, и для ребят с поезда была бы проще. Но в тот момент было поздно что-то менять, наши программы уже были готовы. Сейчас жалею, что по молодости лет постеснялся сказать этому человеку всё, что я о нём думаю.

Вид на разворачивающийся поезд из окна диспетчерской.

Из забавных ситуаций ещё вспоминается то, как я однажды что-то там донастраивал в диспетчерской перед самым началом эксплуатации системы, и тут вдруг входит комиссия во главе с Гаевым, тогдашним начальником метрополитена. Я тихонько сидел в углу и не отсвечивал, комиссия обсуждала совершенно неинтересные мне вопросы, в общем, мы друг на другу не мешали. Но один старичок из комиссии всё-таки привлёк моё внимание. Мне показалось, что это заслуженный и уважаемый человек, но из-за возраста уже начавший терять связь с реальностью. И очень эмоциональный. Зашла речь о запуске монорельса в экскурсионном режиме (все уже понимали, что сырая недоработанная система нормальный режим просто не потянет, а отодвигать сроки начала эксплуатации ещё дальше было уже нельзя, вот и придумали экскурсионный режим). Тут старичок почти подпрыгнул: "Вот, мы людей в поезда пустим, а они нам стёкла побьют, сиденья порежут, стены изрисуют! Не пускать всех подряд, только организованные группы по предварительным заявкам от предприятий!" Ему мягко возразили, что сейчас так уже не делают, но он не унимался: "Тогда - как в аэропортах, с регистрацией по паспорту!" Комиссия мягко замяла тему, переключившись на какой-то другой вопрос.

С началом эксплуатации монорельса моё участие в проекте закончилось, дальше я имел с ним дело только как простой пассажир. На тот момент в системе работали две моих программы, но продолжают ли они там работать до сих пор, или уже всё давно переделано, мне неизвестно. Из-за срыва сроков основного проекта наш договор с заказчиком и даже гарантийный срок по нему закончились до того, как началась эксплуатация, так что я даже не имел возможности увидеть работу своих программ в реальных условиях и не знаю, насколько хорошо они справились (надеюсь, что хорошо). Когда проект начинался, он вызвал у меня огромный энтузиазм, потому что мне казалось, что это признак наступления какого-то прекрасного будущего, но та неорганизованность и некомпетентность, которую я увидел, свела почти на нет мой оптимизм. То, что получилось, явно не годится для тиражирования, и то, что сейчас от монорельса пытаются избавиться - печальный, но закономерный итог. Я немного рассказал о том, что видел сам, но те наши ребята, которые участвовали в проекте больше меня, тоже рассказывали интересные истории. Перескажу наиболее запомнившиеся (сам там свечку не держал, могу в каких-то деталях наврать).

На трассе расположены путевые датчики положения. Они чувствуют приближение металла. У поезда есть специальная лыжа, которая проходит при движении над датчиком, он срабатывает и передаёт сигнал о том, что поезд находится над ним. По сравнению со швейцарским прототипом было решено выбрать более дешёвые китайские датчики, у которых чувствительность меньше. Но поезд при движении качается, если он отклонялся в противоположную от датчика сторону, датчик не срабатывал. Опустили лыжу пониже. Теперь поезд (он же качается!) стал иногда разбивать датчики лыжей. Подняли лыжу на прежнюю высоту, но сделали длинной. Теперь, пока лыжа проходит над датчиком, поезд успевает качнуться туда-сюда, датчик срабатывает. Такой вот колхоз.

Экономили на всём. Бортовой компьютер поезда выбрали подешевле, с низкой производительностью. Тогда не было такого избытка процессорных мощностей, как сейчас, да и компьютеры в промышленном исполнении всегда сильно отставали от персональных, в разы превосходя их по цене. В результате этот компьютер сильно тормозил. Разработчики поезда даже попросили нас скрыть на главном экране СЦДУ информацию о положении, которую передавал сам поезд - слишком заметно было, что она отстаёт от того, что показывают путевые датчики. Ещё у поезда есть система аварийной остановки при обнаружении препятствия на пути. Так в этой системе от срабатывания датчика до выдачи сигнала на торможение проходило около полутора секунд - неприемлемо много. Когда проект начинался, шла речь о трёх режимах движения поездов - автоматическом (машинист сидит на всякий случай), полуавтоматическом (машинист следит за поездом и вмешивается в нестандартных ситуациях) и обычном ручном. К концу разработки об автоматическом и полуавтоматическом режимах предпочитали не вспоминать.

Наш заказчик позиционировал себя как алгоритмист, мало разбирающийся в технических вопросах, поэтому на совещаниях в такие вопросы обычно не вмешивался (хотя иногда всё-таки бывало, обычно с отрицательным результатом). А вот дойдёт дело до алгоритмов, тогда он себя, мол, покажет. Ну, дошло. Реализовывали мы ту часть СЦДУ, которая должна менять расписание движения поездов при каких-то нештатных ситуациях. Заказчик выдал несколько алгоритмов для простых случаев. Наши пристают с более сложными ситуациями - а как быть тут. А он - ну, придумайте что-нибудь. Что делать, придумали... Наши сотрудники, не имеющие соответствующей подготовки, просто потому, что остались крайними. Вряд ли получилось хорошо, вероятно, людям, использовавшим нашу систему, было за что ругать нас.

Вот, рассказал, что запомнилось. Надеюсь, было интересно.