ПОДСИСТЕМА УПРАВЛЕНИЯ ПЕРЕВОЗКАМИ

Подсистема управления перевозками представляет собой совокупность задач планирования, организации, контроля, регулирования, учета перевозочного процесса, для решения которых используются экономико-математические методы и современные электронно-вычислительные средства. Укрупненный алгоритм управления перевозками включает три основных взаимосвязанных блока: информационный, управленческий, а также блок оценки результата и принятия решения.

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

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

Прогнозировать возмущения, влияющие на ритмичность и точность выполнения сменно-суточного плана (ССП) перевозок, дают возможность следующие действия:

§ оптимизация заявок на ПС с учетом выполнения двусторонних договорных обязательств;

§ выявление соответствия производительности погрузочно-разгрузочных механизмов заявке клиентуры на ПС;

§ выработка вариантов переадресовки автомобилей в оперативном режиме с учетом дислокации ПС в данный интервал планирования;

§ создание обоснованного резерва автомобилей;

§ разработка новой схемы расчета ССП.

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

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

При формировании ССП следует учитывать, что переадресовка ПС возможна либо в случае поступления новых более приоритетных заявок, либо при отставании в выполнении плана по приоритетным клиентам, либо при изменении условий работы у клиента. Хотя такие процессы затрагивают лишь небольшую часть ССП, это не снижает значимость работы управленческих звеньев.

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

Но предприятия и фирмы все активнее начинают заниматься поиском приемлемых вариантов развертывания подобных систем, поскольку старые управленческие технологии становятся тормозом развития.

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

Но предприятия и фирмы все активнее начинают заниматься по­иском приемлемых вариантов развертывания подобных систем, поскольку старые управленческие технологии становятся тормозом развития.

Типичным примером разработки и внедрения АСДУ грузовы­ми автоперевозками служит ОАО «Первый автокомбинат» города Москвы. В начале 1990-х годов это предприятие перешло на авто­матизированное планирование перевозок железобетонных изделий к строящимся объектам, ориентированное на использование персо­нальных ЭВМ и представляющее собой дальнейшее развитие ав­томатизированной информационно-плановой системы «ПАМИР». Имея банк необходимых исходных данных, содержащий информа­цию о кратчайших расстояниях между вершинами транспортной сети (ТС), марках ПС, списочном парке предприятия, списочном составе водителей, диспетчер центра управления перевозками (ЦУП) комбината на основе выданного программой решения про­изводит отбор маршрутов с точки зрения рациональности перево­зочного процесса. Далее он формирует сменно-суточные задания водителям с последующей распечаткой путевой документации и план-заданий. Обработка путевых листов также автоматизирована (рис. 4.1).

Базовой информацией к расчету является модель ТС и справоч­ник указателя проездов Москвы, постоянно обновляемые в ин­формационно-вычислительном центре автокомбината. После при­вязки объектов строительства к вершинам модели ТС выполняется расчет рациональных маршрутов. Далее выполняется планирование работы ПС, где используется алгоритм решения «задачи о загрузке» и «задачи о назначениях». Представленные задачи по математической постановке эквивалентны задаче о разбиении множества на минимальное количество подмножеств с ограничениями по их характеристикам.

Принцип организации работы ПС ориентирован на первом этапе на централизованное планирование, а в последующем, при наличии сбойных ситуаций - на перераспределение ТС вне зависимости от ранее выполненного закрепления автомобилей за определенными строительными объектами. Полномасштабное развертывание АСДУ в режиме оперативного планирования и управления
•перевозками ЖБИ позволило сократить транспортные издержки, связанные с нарушениями доставки, за счет сокращения времени доставки и повышения ее ритмичности.

Рассматривая схему планирования перевозок, характерную для доставки грузов потребителям своим или привлеченным транспортом, когда координация процесса перевозок осуществляется диспетчером и менеджером, следует сказать о необходимости адаптации «жестких» алгоритмов решения задач. Использование подобных адаптированных «гибких» алгоритмов называют системами поддержки принятия решений (СППР), относящимися к классу интеллектуальных систем.

Рассматривая систему транспортировки, например потребительских товаров со склада в магазины (рис. 4.2), к входящим информационным потокам следует отнести:

•информацию о наличии грузов на складах грузовладельцев — номенклатура, количество, сроки хранения, транспортные свойства (вид упаковки и пр.);

•информацию о наличии ПС — количество и тип технически исправных автомобилей, имеющихся в распоряжении службы организации перевозок или тех, что могут быть заказаны на условиях почасовой (или другого вида) оплаты;

• заявки потребителей — адреса пунктов завоза, количество завозимого груза и время (интервал времени) завоза;

•оперативные данные о состоянии транспортной сети региона.
К исходящим информационным потокам относятся:

• составленный сменно-суточный план перевозок (система маршрутов, маршрутная сеть), передаваемый конечным исполнителям;

•рассчитанный интервал времени прибытия автомобиля, его государственный номер и другая подобная информация, передаваемая получателям грузов.

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

В связи с разнообразием задач планирования и управления рабо­ты ПС становится вес более актуальной идея стандартного пред­ставления данных в виде единой информационной базы системы транспортного обслуживания клиентов, удовлетворяющей требова­ния различных категорий пользователей — грузоотправителей, за­казчиков, перевозчиков. Наличие такого стандартного представле­ния, во-первых, существенно облегчит работу по проектированию маршрутных сетей и схем доставки при переходе от одной задачи к другой, во-вторых, позволит использовать общий принципиальныйподход и единые алгоритмы планирования транспортного процес­са, что значительно упростит взаимодействие всех его участников.

Современный уровень развития аппаратных и программных средств с некоторых пор сделал возможным повсеместное ведение баз дан­ных оперативной информации на разных уровнях управления.

В последние годы оформился ряд новых концепций хранения и анализа корпоративных данных:

1)хранилища данных;

2)оперативная аналитическая обработка;

3)интеллектуальный анализ данных (Data Mining).

Одновременный анализ по нескольким измерениям определя­ется как многомерный анализ. Каждое измерение включает направ­ления консолидации данных, состоящие из серии последователь­ных уровней обобщения, где каждый вышестоящий уровень соот­ветствует большей степени агрегации данных по соответствующе­му измерению. Так, измерение «Исполнитель» может определять­ся направлением консолидации, состоящим из уровней обобще­ния «предприятие — подразделение — отдел — служащий». Измере­ние «Время» может включать два направления консолидации; «год-квартал — месяц—день» и «неделя — день», поскольку счет вре­мени по месяцам и по неделям несовместим. В этом случае стано­вится возможным произвольный выбор желаемого уровня детали­зации информации по каждому из измерений. Операция спуска соответствует движению от высших ступеней консолидации к низ­шим; напротив, операция подъема означает движение от низших уровней к высшим (рис. 4.3).

В специализированных СУБД, основанных на многомерном представлении, данные организованы не в форме реляционных таблиц, а в виде упорядоченных многомерных массивов:

1)гиперкубов (все хранимые в БД записи должны иметь оди­наковую размерность);

2)поликубов (каждая переменная хранится с собственным на­бором измерений, и все связанные с этим сложности обработки перекладываются на внутренние механизмы системы).

В свою очередь, реляционные СУБД (системы ROLAP) обеспе­чивают значительно более высокий уровень защиты данных, хо­рошие возможности разграничения прав доступа, и в большин­стве случаев корпоративные хранилища данных реализуются средствами именно реляционных СУБД, даже при том, что главный недостаток ROLAP по сравнению с многомерными СУБД (MOLAP) — меньшая производительность. Только при использо­вании «звездообразных» схем построения СУБД (не следует путать с одной из схем топологии ЛС) производительность хорошо на­строенных реляционных систем может быть приближена к произ­водительности систем на основе многомерных баз данных.

Идея схемы «звезда» (star scheme) заключается в том, что име­ются таблицы для каждого измерения, а все факты помещаются в одну таблицу, индексируемую множественным ключом, состав­ленным из ключей отдельных измерений (рис. 4.4).

В сложных задачах с многоуровневыми измерениями имеет смысл обратиться к расширениям схемы «звезда» — схеме «созвездие» (fact constellation scheme) и схеме «снежинка» (snowflake scheme), В этих случаях отдельные таблицы фактов создаются для возмож­ных сочетаний уровней обобщения различных измерений (рис. 4.5). Это позволяет добиться лучшей производительности, но часто при­водит к избыточности данных и к значительным усложнениям в структуре БД. в которой оказывается огромное количество таблиц фактов.

В сфере OLAP не может существовать однозначных рекоменда­ций по выбору инструментальных средств. Один из основных воп­росов: требуется ли создание БД жестко заданной структуры или можно анализировать данные, собранные в ранее созданных базах (в случае ROLAP)?

Важно также уяснить, наглядны ли графические возможности, существует ли связь с геоинформационными технологиями, нала­жены ли механизмы экспорта результатов в стандартные форматы.

Как показывает практика, интеграция разнородных програм­мных продуктов в устойчиво работающую систему - один из наи­более важных вопросов, и его решение в ряде случаев может быть связано с большими проблемами.

ПОДСИСТЕМА ПЛАНОВЫХ И АНАЛИТИЧЕСКИХ РАСЧЕТОВ