logo
ИСТ / AIC_Lectures

Подсистема управления перевозками

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

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

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

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

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

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

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

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

Рис. 1.1. Схема оперативного планирования перевозок

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

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

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

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

Рис. 1.2. Схема информационных потоков в системе доставки грузов

К исходящим информационным потокам относятся:

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

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

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

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

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

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

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

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

Рис. 1.3. Измерения и направления консолидации данных

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

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

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

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

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

Рис. 1.4. Пример схемы "звезда"

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

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

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

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

Рис. 1.5. Пример схемы "снежинка" (фрагмент для одного измерения)