Сегодня я хотел бы вспомнить былое и рассказать вам, уважаемые читатели, об одном своём раннем опыте построения автоматизированных систем управления (АСУ), используемых на транспорте. Я опишу вам свой личный опыт по построению АСУ контейнерным пунктом. Этот проект является для меня, можно сказать, одним из таких, которыми я горжусь. Я пришёл на него в далёком 2002 году простым инженером-программистом, а закончил в 2005 руководителем проекта. Проект закончился внедрением в опытную эксплуатацию на одной из станций Московской железной дороги. К сожалению, потом в силу определённых обстоятельств компания, в которой я работал, перестала существовать, и я потерял концы. В каком виде эта АСУ находится сейчас, мне, к сожалению, не известно.
Как всё начиналось
Тогда, в далёком 2002 году, в недрах одного ведомственного научно-исследовательского института МПС — ВНИИЖТ — разрабатывалась автоматизированная система управления контейнерным пунктом. Разработка велась уже давно, там были какие-то унаследованные старинные компоненты, которые запускались ещё на деревянных мейнфреймах Международных Деловых Машин. В общем, разработка велась на каком-то Foxpro (коллеги, я прошу прощения за такие ругательства, но слов из песни не выкинешь). За разработку отвечал один бессменный человек. В общем, всё как обычно.
Компания, в которой я тогда работал, вносила в деятельность МПС всякие инновации. Конкретно отдел разработки, в который я устроился тогда ещё простым инженером-программистом, занимался переработкой программного обеспечения использовавшихся на железнодорожном транспорте АСУ, выводом их на новые рельсы и технологии. И вот наш директор поставил мне задачу — провести обследование и предложить комплексное решение проблемы точного позиционирования козлового крана на контейнерной площадке.
А в те времена технология GPS была не то, чтобы неизвестна, но не пользовалась уж широкой популярностью. Бытовые навигаторы были довольно низкоточными, могли более или менее определять координаты в движении, лучше со скоростью побольше. Ну это было примерно как с первыми мобильными телефонами, которые надо было носить в чемодане. Утрирую, конечно, но тем не менее. И вот, перебрав множество вариантов (всякие там лазеры, RFID-метки и т. д., и т. п.), мы останавливаемся на использовании GPS-технологии. Я сажусь за изучение небесной механики и релятивистской физики, чтобы иметь самое непосредственное понимание того, как по мельчайшим разностям во времени приёма сигналов со спутников вычислять координаты. Но в итоге мы просто находим геодезические приёмники, которые работали в двух технологиях (GPS и ГЛОНАСС; да, я использовал ГЛОНАСС ещё до того, как это стало мейнстримом :). Они нам и помогли.
Что в итоге? На научно-технический совет выносится идея о точном позиционировании крана при помощи GPS-приёмников, работающих в дифференциальном режиме. Заявляем точность в полметра, при том, что производители тогда говорили о точности до 5 метров максимум (или минимум). При этому на своих полигонах мы добились именно такой точности — дифференциальный режим позволял нивелировать все ошибки, получаемые в локальной зоне из-за погодных условия и прочего подобного. Идея защищена, нам позволяют попробовать запустить пилотный проект на одной из станций МЖД. Это была станция Москва-Товарная-Рязанская.
Переход на архитектуру SOA
В те далёкие времена очень модной была новая архитектура построения информационных систем SOA (service oriented architecture, сервисно-ориентированная архитектура). Она и сегодня не потеряла своей актуальности, а тогда с ней носились все, как дурень с писаной торбой. И вот наш молодой коллектив одним из принципов разработки АСУ и ИС взял на вооружение реализацию SOA при помощи технологии межсистемного взаимодействия CORBA. Сегодня об этой технологии уже мало кто вспоминает, а тогда она была на острие инноваций.
И вот наш отдел разработки берётся сделать новую инкарнацию АСУ КП для появившегося уже ОАО «РЖД» на технологии CORBA с использованием подхода SOA. Архитектуру системы нарисовали быстро, защитили на раз. Заказчика взяло за живое полная модульность и компонентность, взаимозаменяемость и открытость протоколов. Впрочем, были и противники. Куда без них?..
В итоге мы выходим на реализацию системы со следующим компонентным составом:
- Сервер приложений — центральный компонент системы, в котором велась модель контейнерной площадке, на которой была развёрнута система. СП обеспечивал исполнение запросов клиентских машин (три типа АРМ) к СУБД, выполнял расчёты, готовил план работ, оптимизировал перемещение крана по контейнерной площадке, строил отчётность.
- СУБД — PostgreSQL с базой данных, в которой хранилось практически вся информация, курсирующая в системе. Кроме того, промежуточный интеграционный слой также требовал себе отдельную схему для каких-то там своих тёмных дел.
- АРМ приёмосдатчика в конторе — обычный компьютер с ОС Windows, стоявший в офисном здании, в котором происходила работа приёмосдатчиков по оформлению документов, обслуживанию клиентов и т. д. Отвечал за контроль работы козлового крана, правильность подготовки плана работ, отчётность.
- АРМ приёмосдатчика на площадке — наладонный компьютер в индустриальном исполнении, обеспечивающий работоспособность в расширенном интервале температур и выдерживающий какие-то непомерные нагрузки (бросок с размаху на бетонный пол с высоты роста взрослого мужчины он выдержал). Мы нежно называли его «жёлтенький», поскольку он, как ни странно, был жёлтого цвета. На нём отображалась текущая подача вагонов, списки контейнеров, текущий план работы крана. Он позволял обновлять модель контейнерной площадки, если вдруг она где-то сбилась. Мы долго работали над эргономикой графического интерфейса пользователя и разработали принципы, которые позволяли использовать этот наладонник в рукавицах. Да, мы разработали простой интерфейс с большими кнопками ещё до того, как это стало мейнстримом :).
- АРМ машиниста крана — бортовой компьютер крана специального собственного производства с ОС Linux. Стоял непосредственно в кабине у крановщика под его левой рукой. Имел одну красную кнопку, на которую машинист должен был нажимать при выполнении очередного задания. Хотя мы могли автоматически понимать, что задание выполнено, заказчик захотел задействовать человеческий фактор. На широкий экран выводился текущий план работ.
- Подсистема позиционирования крана — два геодезических приёмника GPS, один из которых стоял на здании конторы приёмосдатчиков, а второй ездил на каретке козлового крана. Мобильный приёмник соединялся с бортовым компьютером крана и через него передавал в информационный эфир системы свои относительные координаты в асинхронном режиме («всем, кому это интересно»). Передача могла вестись с частотой от 1 до 10 Гц. Координаты передавались в метрах от базовой точки, а также в системе «ряд — место — ярус».
- Подсистема контроля захвата груза — тензометрический датчик, также соединённый с бортовым компьютером крана, который определял факт захвата или отпускания контейнера.
- Промежуточный интеграционный слой — объектный брокер, работавший на той же самой машине, что и СП, и обеспечивавший межмодульное и межсистемное взаимодействие. Взаимодействие было двух видов — синхронное (для выполнения команд) и асинхронное (для выдачи в эфир координат крана). Также взаимодействие обеспечивалось не только между модулями системы, но и со смежными железнодорожными системами по ведомственной сети передачи данных. В частности, в разработанную систему приходила информация о подачах вагонов с контейнерами со всей необходимой информацией для планирования работы.
Всё это дело взаимоувязывалось и работало одновременно. Было несколько режимов работы, в том числе и такой, который показывал на экране АРМ приёмосдатчика в конторе графическое отображение контейнерной площадки и перемещение крана на ней в реальном времени. Некоторые смотрели на эту анимацию с завороженностью того свойства, что даже оторвать было нельзя. Человек втыкался в монитор, смотрел то на него, то в окно на двигающийся кран. Люди не могли себе представить, что мы реализовали давнишнюю мечту железнодорожников, которую многие коллективы пытались безуспешно разработать и реализовать ещё чуть ли не с 1970-ых годов.
Поскольку на станции Москва-Товарная-Рязанская имеется две контейнерные площадки для двадцатифутовых контейнеров, то система позволяла одновременно вести работы двух бригад, состоящих из приёмосдатчика в поле и крановщика. Впрочем, архитектура была разработана так, что в потенциале можно было подцепить хоть миллиард площадок — главное, чтобы вычислительных мощностей и пропускной способности канала хватило. Кстати, о канале. Для обеспечения связности компонентов системы мы развернули радиосеть, по которой и осуществлялось межмодульное взаимодействие. Да, мы сделали свой Wi-Fi ещё тогда, когда это не стало мейнстримом :).
Внедрение
Мы долго отрабатывали наши технические решения на самой площадке, благо руководство станции дало полное добро на наши эксперименты с краном и контейнерами. Но в конце концов настало время внедрения, приёмо-сдаточных испытаний и передачи в опытную, а затем и в постоянную эксплуатацию. В ЦКИ ОАО «РЖД» была сформирована комиссия для приёмки системы, в которую вошла куча сотрудников из различных подразделений. Были путейцы, был кто-то с коммерческой дистанции, были с дистанции электроснабжения. Приехали сотрудники из центрального аппарата, которые отвечали за безопасность, в том числе и информационную. В общем, всё было по-взрослому. Мне, ставшему тогда уже руководителем этого проекта, было совсем не до шуток. Несмотря на то, что Программа и методика испытаний была утверждена, а сами испытания по ней мы провели несколько раз, меня всё равно била мелкая дрожь.
Но всё прошло благополучно. Даже представитель службы безопасности, который с размаху кинул «жёлтенький» на пол, не смог помешать работоспособности системы. Да, на экране наладонника появилась надпись «Связь с сервером потеряна», однако это случилось лишь от того, что из разъёма вылетела антенна. После возвращения оной обратно, всё заработало так, как будто бы компьютер и не падал. В общем, все пункты ПМИ были сданы, мы ещё выполнили несколько дополнительных проверок, не предусмотренных процедурой приёмки. Большая часть сотрудников комиссии осталась вполне довольна. А иные просто не показывали своих чувств, поэтому сложно сказать, что они там думали на самом деле.
Однако на следующий день я на личном опыте узнал, что такое «технологический луддизм», как я это теперь называю. Ведь не секрет, что делу внедрения автоматизированных систем управления сопротивляется в первую очередь наименее квалифицированный персонал. В данном случае мы столкнулись с тем, что приёмосдатчики, чью работу, казалось бы, мы облегчаем в десятки раз. Но нет. Главарь приёмосдатчиков собрал в кучу всё оборудование, которое мы передали им по акту, и со словами «Заберите, нам это не нужно» придвинул его ко мне. Поскольку я отказался, он просто взял и положил эту кучу в сейф. Всё.
Но, на самом деле, в конечном итоге этот технологический луддизм был преодолён. Уговорами и разъяснениями с привлечением начальника станции, который дал честное железнодорожное слово, что никто не будет уволен из-за повышения производительности труда. Ведь это основная боязнь низкоквалифицированого персонала в деле автоматизации — как будто бы все такие работники поголовно читали труды Н. Винера про кибернетическое порабощение человека капиталистической системой, ставящей автоматизацию на службу эксплуатации трудящихся.
В общем, вот как-то так. С удовольствием отвечу на любые вопросы, если таковые найдутся…
Описание моего опыта управления проектами по разработке и внедрению автоматизированных систем управления и информационных систем:
- Стенд Комплексной Автоматизации: описание опыта разработки
- Комментарии к героическому эпосу в трёх рунах о внедрении MIS
Автор: Darkus
