Внедрение АСУ Диспетчер в Московском речном пароходстве, 1987 г.
Необходимое вступление. В статье «Москва. АСУ Диспетчер» описано проектирование этой системы (Ширяев – руководитель, исполнители – весь мой отдел). Но в ней я не касался вопросов взаимоотношений с Московским пароходством (МРП) и портами в процессе внедрения разработанной системы. А в этих взаимоотношениях были острые моменты.
Итак, АСУ Диспетчер принята в промышленную эксплуатацию (1986 г.), в ВЦ МРП и портов установлены ЭВМ СМ-4, во всех диспетчерских, от Рыбинска через КИМ (канал имени Москвы) и Оку до Горького установлены подключённые к ВЦ дисплеи (мониторы). Все диспетчеры на семинаре обучены. Началась первая «обасученная» навигация. Все (и разработчики, и пользователи, и начальство) с интересом смотрят – что получается. Я лично провожу ночи (когда не мешает начальство) в диспетчерских пароходства. Наблюдаю работу диспетчеров на их дисплеях, иногда вносим корректировки в программное обеспечение (об этом в упомянутой статье немного есть).
Две основные проблемы сопровождали все годы работы системы (10 лет в тогда разработанном виде). Эти проблемы до конца тогда не были сняты, да и не могли быть сняты при той технике. Система тем не менее работала.
Но сначала опишем укрупнено работу системы. Все многочисленные диспетчеры МРП, портов, КИМ со своих дисплеев вводят краткие формализованные сообщения о каждой выполняемой операции (прибытие, начало погрузки и т.д.) по каждому судну, находящемуся в границах их ведения. Эта информация автоматически передаётся во все ВЦ. На её основе решаются задачи отображения дислокации флота, прогноза прибытия судов в порты и к шлюзам, разнообразного оперативного учёта. Всё это представляется на дисплеях и/или в печатном виде.
Всё хорошо, явное продвижение вперёд в управлении работой флота и портов, но вот эти 2 проблемы, несколько отравлявшие нам (разработчикам) жизнь:
1. Отсутствие ведения графика исполненного движения и обработки (ГИД) в том виде, к которому привыкли диспетчера;
2. Недостаточная точность прогноза прибытия судов.
1-я проблема. Диспетчеры пароходства издавна вручную вели этот ГИД. Это непрерывный рулон бумаги-миллиметровки, на котором карандашом проводятся линии по мере поступления информации об очередной выполненной судном операции в конкретном пункте. Для диспетчеров это было наглядным, и к тому же они к этому привыкли. Но мы, разработчики, не могли этого выполнить. Не было таких графопостроителей, которые работали бы не с отдельным листом, а с непрерывным рулоном. Думаю – и сейчас их нет.
2-я проблема – точность прогноза времени прибытия судов в порты и к шлюзам. Кстати, этот термин – прогноз времени прибытия – ввёл в научный оборот в 60-е годы именно я. Помню, руководитель моей аспирантуры Савин В.И меня за него резко критиковал: «Что это за мистика? ЭВМ должна давать точный расчёт, а не мистический прогноз!». Но я настоял на своём, так этот термин и привился на речном транспорте.
В самом деле, что значит – определить время следования судна от одного пункта до другого? Для упрощения предположим, что расстояние между пунктами нам известно (хотя и это не точно, к тому же фактические трассы следования разных судов на одном участке могут различаться).
Предположим также, что уровни воды нам известны, водомерные посты кое-где имеются. Но как от них зависит скорость течения, а от неё потери или приращения скорости судов каждого типа? Нужны многолетние наблюдения по каждому участку.
Поверим также прогнозу погоды. Но как от направления и силы ветра зависят те же самые потери или приращения скорости судов каждого типа на каждом участке? Также нужны многолетние наблюдения.
А состояние судна, его двигателей в каждый момент времени, квалификация штурманов, рулевых, механиков? Об этом даже говорить не буду.
Эти и другие соображения я изложил в 2 научных статьях. Но научные формулы – это ещё не компьютерные программы. А если и они составлены, то они бесполезны без исходных данных о выше указанных зависимостях.
Надо сказать, что в те времена начала применения ЭВМ существовала у большинства людей некоторая мистическая вера в возможности ЭВМ. Машина должна считать точно - и точка! Я по возможности разъяснял диспетчерам, руководителям пароходства и портов, что прогноз времени прибытия абсолютно точным быть не может. Ни через год, ни через 100 лет – никогда. C'est la vie. Но у Вас благодаря ЭВМ теперь всегда есть обобщающая картина по каждому порту и шлюзу. Этим и будьте довольны. В основном и были довольны, система была принята в промышленную эксплуатацию в Московском пароходстве, а затем началась работа по самому крупному Волжскому пароходству.
В заключение расскажу о трагикомическом эпизоде, произошедшем из-за 2-й проблемы (неточность прогноза).
Конечно мы, разработчики, думали, как повысить точность и в имеющихся условиях. В частности, ещё при проектировании я ввёл в картинку ввода строчку «Примечание», в которую следовало записывать любые сведения (в дополнение к чётко формализованным) о судне и водном пути, влияющие на оценку ситуации.
Московское пароходство вскоре организовало сезонную перевозку помидоров и арбузов из Астрахани и других пунктов Нижней Волги в Московские порты. Для этого было выделено несколько специально дооборудованных небольших (600 т) теплоходиков типа СТ-№. Конечно, эти перевозки требовали особенного внимания. Поэтому я придумал следующее. Лично написал проект приказа начальника пароходства, согласовал, прошёл к начальнику пароходства, он (Казанцев Е.Д.) подписал. Приказ обязывал каждое из этих «помидорных» судов передавать соответствующему диспетчеру «капитанский прогноз прибытия», диспетчера – записывать его в строчку «Примечание».
Но дисциплина выполнения приказов тоже не бывает 100%-ной. И вот СТ (не помню №) этот приказ не выполнил. А у него (как потом стало известно) был непорядок с двигателями, тилипал на одной машине.
ЭВМ рассчитала прогноз по заложенным в неё нормам времени следования. Порт послал заявку автотранспортному предприятию (АТП) на автомашины. Утром вся площадь перед Московским Северным портом (МСП) была запружена автомашинами, готовыми немедленно развозить скоропортящийся груз по магазинам. А СТ-№ пришёл только на следующий день.
АТП отправило в МСП штрафной счёт за простой автомашин. В МСП не долго думали и отправили счёт на эту сумму в мой ЦНИИЭВТ. Директор Архипов Е.Е. меня вызывает, слушает, обязывает разъяснить МСП отказ ЦНИИЭВТа оплатить счёт, поскольку инцидент произошёл из-за невыполнения приказа начальника пароходства. Разъясняю, МСП замолкает, но была в этом для нас, разработчиков, конечно не комедия. Пусть и не трагедия, но драма. Так что я о ней вспомнил через несколько десятилетий.