Анализ и разработка современных интеллектуальных методов моделирования в системах принятия решений


Реализация системы планирования содержания тяговых ресурсов на установленную потребность



страница13/24
Дата09.08.2018
Размер2.94 Mb.
#43463
ТипЗадача
1   ...   9   10   11   12   13   14   15   16   ...   24

1.13Реализация системы планирования содержания тяговых ресурсов на установленную потребность


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

1.13.1Модуль квартального планирования КЗО ТПС


Модуль квартального планирования КЗО ТПС разработан с целью обеспечения необходимого содержания ТПС в квартале на установленную потребность для обеспечения перевозочного процесса. Все расчеты проводятся отдельно для каждой региональной дирекции. При этом парк ТПС разделяется по следующим критериям:

  • Вид движения (грузовое/пассажирское)

  • Вид тяги (электровозы/тепловозы)

    • ТПС с электрическим видом тяги дополнительно делятся по роду тока (постоянный/переменный)

Все расчеты и операции проводятся посекционно.

Алгоритм квартального планирования КЗО ТПС состоит из следующих этапов [39]:



  1. Расчет потребного парка ТПС на начало планируемого периода на основе коэффициента неисправных ТПС.

  2. Расчет фактического парка на начало планируемого периода

  3. Сравнение фактического и потребного парка ТПС

  4. Устранение дефицита или профицита парка ТПС

  5. Вывод решения

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

Рассмотрим данные этапы работы алгоритма подробнее.



  1. Расчет потребного парка ТПС на начало планируемого периода.

На вход планировщика поступает информация о план-задании содержания ТПС plan и коэффициент неисправных coefficient для текущего периода для каждой региональной дирекции с указанием числа секций N, вида тяги и движения, а также рода тока. Полученные данные передаются соответствующим объектам регионов. Потребный парк ТПС requiredPark на начало расчетного периода вычисляется следующим образом:

Данный расчет осуществляется в объектах региональных дирекций для каждого вида тяги и движения, а также рода тока.



  1. Расчет фактического парка на начало планируемого периода

На вход планировщика поступает план закупок ТПС boughtPlan на планируемый период, а также на период, предшествующий планируемому кварталу, план взятия ТПС в аренду у собственника fromRent в планируемом квартале, данные по плану списания секций cancellation на окончание текущего квартала и на планируемый период, а также пономерной список всех секций с указанием информации о текущем статусе каждой секции и о следующих параметрах:

  • LocoSecId – идентификатор секции локомотива

  • RegionId – идентификатор дирекции

  • Series – идентификатор серии секции локомотива

  • Status – текущий статус локомотива: "exploitation" (в эксплуатации), "conservation" (в консервации), "tr" (в тех. резерве), "rent" (планируется передача в аренду в планируемом квартале), "sell" (планируется продажа в планируемом квартале)

  • date(year(Year),month(Month),day(Day)) – дата постановки на консервацию или в тех. резерв (только для локомотивов со статусом "Conservation" и "TR")

  • Motion – тип движения: 1 – грузовое, 0 – пассажирское

  • Traction – вид тяги 0 тепло- , 1 – электро-

  • ElectricCurrentType – тип тока: 1 - переменный, 0 – постоянный. Для вида тяги тепло- данный параметр отсутствует

  • Rest- расстояние до ближайшего ремонта

  • build_year(year(Year),month(Month))– дата постройки локомотива

Полученные данные передаются соответствующим объектам регионов. Далее расчет фактического парка осуществляется в объектах региональных дирекций.

В каждой дирекции вычисляется фактическое количество секций с разделением по виду тяги и роду тока factLocoPark, находящихся в эксплуатации в планируемом квартале - explSections. При этом проверяется статус каждой секции в парке ТПС:



  • если секция планируется к списанию ее статус "exploitation" сменяется на статус "cancellation" и не учитываются при вычислении factLocoPark;

  • если секция находится в статусе "tr", но максимальный срок пребывания секции в тех. резерве уже истек, статус секции сменяется на статус "exploitation". Такие секции учитываются при вычислении factLocoPark;

  • если секция планируется к передаче в аренду в планируемом квартале и находится в статусе "rent", то она не учитывается учитываются при вычислении factLocoPark;

  • если секция находится в тех. резерве в планируемом квартале и находится в статусе "tr", и максимальный срок пребывания секции в тех. резерве еще не истек, то она не учитывается учитываются при вычислении factLocoPark;

  • если секция находится в консервации в планируемом квартале и находится в статусе "conservation", то она не учитывается учитываются при вычислении factLocoPark;

  • если секция планируется на продажу в планируемом квартале и находится в статусе "sell", то она не учитывается учитываются при вычислении factLocoPark.

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

Фактический парк ТПС factLocoPark на начало расчетного периода вычисляется следующим образом:



,

  1. Сравнение фактического и потребного парка ТПС

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

Данный расчет осуществляется в объектах региональных дирекций. Информация о результатах расчета передается в главный объект планировщика.



При этом возможны следующие случаи:

  • – фактический и потребный парки равны

  • – существует профицит парка секций в данной дирекции

  • – существует дефицит парка секций в данной дирекции

  1. Устранение дефицита парка ТПС

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

    1. Вывод из тех. резерва

      1. В региональных дирекциях, в которых присутствует недостаток, отбираем секции, находящиеся в тех. резерве, у которых уже прошел минимальный срок пребывания в тех. резерве. Формируем список секций для вывода их из тех. резерва в эксплуатацию, при этом сортируя по критерию «Наименьший пробег от ТР».

    2. Передислокация секций из региональных дирекций с избытком.

      1. Главный объект планировщика запрашивает у объектов регионов, в которых наблюдается профицит, информацию о количестве секций, доступных для передислокации. Планировщик выбирает наиболее оптимальный набор «объектов регионов - количество передаваемых от них секций для передислокации» по следующим критериям:

        • Ближайшее расположение дирекции (депо)

        • Наименьший пробег от КР , СР, ТР3

        • Наиболее поздний год постройки.

Выбор оптимального набора «объектов регионов - количество передаваемых от них секций для передислокации» на данном шаге производится с помощью решения транспортной задачи, основные моменты которого будут раскрыты в разделе 1.14.

      1. Объект планировщика сообщает объектам региональных дирекций решение по передислокации секций.

      2. Объекты региональных дирекций обновляют информацию о количестве секций (добавляют или изымают секции) после данной операции.

    1. Вывод из тех. резерва с последующей передислокацией.

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

      2. Объекты региональных дирекций обновляют информацию о количестве секций (добавляют или изымают секции) после данной операции.

    2. Вывод из консервации

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

        • Наименьший пробег от КР , СР, ТР3

        • Наиболее поздний год постройки.

    1. Вывод из консервации с последующей дислокацией.

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

        • Наименьший пробег от КР , СР, ТР3

        • Наиболее поздний год постройки

      1. Объекты региональных дирекций обновляют информацию о количестве секций (добавляют или изымают секции или переводят секции в консервацию) после данной операции.

  1. Устранение профицита парка ТПС

      1. После выполнения операций по исправлению ситуации недостатка в региональных депо главный объект планировщика смотрит, остались ли при этом региональные дирекции с профицитом. Если да – то весь оставшийся профицит секций переводится в консервацию. При этом список перевода в консервацию формируются на основе сортировки по критериям:

        • Наименьший пробег от КР , СР, ТР3

        • Наиболее поздний год постройки

  1. Вывод решения

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

1.13.2Модуль квартального планирования КЗО ЛБ


Модуль квартального планирования КЗО ЛБ был разработан на языке Java с целью обеспечения необходимого содержания ЛБ в квартале на установленную потребность для обеспечения перевозочного процесса. Поскольку общие принципы алгоритма планирования ЛБ схожи с описанными выше основными моментами алгоритма планирования ТПС, рассмотрим здесь предложенную методику построения программной реализации указанных модулей и структуру данных в них.

Рисунок 4.. Основные объекты построенной системы



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

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

Пакет dataWrapper представляет собой набор классов для общения планировщика с внешней средой. Классы из пакета inputReader обрабатывают сообщения, поступающие на вход планировщика, и формируют в удобном для него формате входные данные, которые описывает класс InputData. Предназначение класса OutputData состоит в хранении решений планировщика и составлении выходных сообщений планировщика. Более подробно протокол общения построенных в данной работе модулей с внешней средой описан в Приложении 2.

Пакет depot содержит в себе классы, характеризующие объекты и производственные процессы внутри депо. Центральным объектом здесь является объект Depot, который содержит в себе сводку основных правил и ограничений при работе по содержанию тяговых ресурсов в депо. Ответственным по работе с персоналом является класс HumanResources, который хранит информацию о контингенте ТЧМ и ТЧМП в конкретном депо, а также их прогнозную и плановую списочную численность. Класс Person описывает заданную и рассчитываемую информацию о сотруднике, включая даты приема на работу и ухода на пенсию, образование, класс квалификации, имеющиеся права управления License, а также историю всех статусов PersonStatusType и позиций Position, занимаемых сотрудником. Оставшиеся классы InventoryPlan и UpgradePlan отражают наряд-задание и квоту на направление ТЧМ на повышение класса квалификации.

Описанный выше класс Depot наследуется от класса Station и входит в топологию сети железнодорожных станций, работа с которой осуществляется объектами пакета topology. Об используемых при этом методах более подробно будет рассказано в разделе 1.14.

Указанные выше классы License, PersonStatusType и Position описывают виды прав, статусов сотрудников и их позиций и относятся к пакету types. Статус сотрудника – это его текущее состояние, которое может принимать одно из перечисленных значений: работа, выход на пенсию, стажировка на должность машиниста, направлен на повышение квалификации, ротация, увольнение.

Позиция сотрудника - это сочетание должности (ТЧМ/ТЧМП) и вида локомотива (отраженного в классе LocoType), на которых работает данный сотрудник.

Также при планировании используются вспомогательные классы из пакета supportive и других пакетов, не показанных на Рисунке 4.1.

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

Рисунок 4.. Структура объекта Resolver

Рассмотрим структуру объекта Resolver, отвечающего за один цикл планирования по всем проблемам в депо. Структура данного класса приведена на Рисунке 4.2. Метод solve(Step) выполняет планирование для заданного этапа Step, разделяя, где возможно, проблемы на параллельные депо-потоки.

Планирование состоит из 3 этапов, представленных в диаграмме подклассом Step. Шаг Step.PREPLANNING отвечает за расчёт плановой и прогнозной списочной численности ТЧМ и ТЧМП, а шаги Step.DEFICIT и Step.SURPLUS за планирование и выполнение операций по устранению дефицита и профицита соответственно. На каждом шаге объект Resolver запускает параллельные процессы-помощники Helper для каждого депо, которые идентифицируют проблемы для своего заданного депо и решают их. На шаге Step.DEFICIT дополнительно после работы всех процессов-помощников запускается объект планирования командировок Relocation, призванный устранить оставшийся дефицит.

Для решения найденных проблем класс Resolver использует набор возможных операций над контингентом сотрудников operations, ответственным за который является класс OperationPool (см. Рисунки 4.2 и 4.3). Объект данного класса хранит в себе все необходимые операции для одного цикла планирования и правила получения правильной последовательности операций для каждого шага планирования в Resolver. По запросу он возвращает последовательность операций для решения текущего шага планирования для заданной позиции. Дополнительно, если требуется учесть условия внутри/вне тяги WithinTraction или внутри/вне депо WithinDepot, также фильтрует последовательность операций, чтобы их вид соответствовал заданным условиям.

Рисунок 4.. Диаграмма классов, отвечающих за возможные операции над ТЧМ и ТЧМП

Рассмотрим теперь строение предложенной структуры данных, отвечающей за возможные операции над контингентом ТЧМ и ТЧМП по устранению дефицита и профицита в депо. Диаграмма структуры классов и зависимостей между ними представлена на Рисунке 4.3.

Абстрактный класс Operation в общих чертах характеризует операцию над сотрудниками, которая приводит прогнозную списочную численность к ее плановому значению. Операции разделены на 8 типов, представленные в Operation подклассом Type. Для каждого типа разнятся значения свойств операции withinDepot (операция затрагивает сотрудников внутри/вне депо), positionChange (операция включает/исключает изменение позиции сотрудника), withinTraction (операция затрагивает сотрудников внутри/вне тяги), aimedFunction (должность, на которую направлено действие данного типа операции), newStatus (статус сотрудника после проведения операции).

Kаждый тип операции (кроме RequalificationTraction) представлен классом, наследующимся от описанного выше абстрактного класса Operation. Класс Requalification отражает свойства операции переквалификации ТЧМ и ТЧМП, включая в себя подтип RequalificationTraction для переквалификации с одного вида тяги на другой. Класс Promotion описывает операцию оформления ТЧМП на должность ТЧМ, Demotion - временного перевода ТЧМ на должность ТЧМП, Relocation – направления сотрудника в командировку в другое депо, Upgrade - направления ТЧМ на повышение квалификации, Rotation - ротации кадров, Retirement - выхода на пенсию.

Для учета поставленных ограничений каждый тип операций реализует методы getPredicateTyped(Position pos, Depot curDepot), getPredicateSuitable(Position pos, Depot curDepot), которые содержат в себе правила фильтрации сотрудников для указанной позиции (отвечающие критериям отбора той или иной операции), а также метод getComparator(Position pos, Depot curDepot), сортирующий сотрудников по заданному в операции приоритету. Операция может действовать как восполнение дефицита, так и на устранение профицита, что отражает ее поле sign. После применения конкретной операции к контингенту какого-либо депо все затронутые данной операцией сотрудники записываются в объект операции, что позволяет с легкостью вывести окончательные решения планировщика о действиях над сотрудниками.

Решение, полученное в результате работы объекта Resolver на каждом этапе, отражается в объекте solvingData (Рисунок 4.2), представленном классом OutputData, который содержит в себе все планируемые депо в их текущих состояниях. В конце планирования по запросу главного объекта планировщика OutputData формирует все решения в виде выходных сообщений.

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



Каталог: upload -> medialibrary
medialibrary -> Авиакомпания свяжет Хабаровск с приморским поселком Кавалерово Это направление включено в список субсидируемых государством маршрутов
medialibrary -> Число пассажиров региональной авиации Приморья приближается к 25 тысячам
medialibrary -> Россия выиграла разбирательство в международном арбитражном суде по иску немецкой компании Sana Consulting
medialibrary -> Перечень вопросов для подготовки к зачету по дисциплине «Операционные системы»
medialibrary -> 1. Рабочая программа Цели освоения дисциплины


Поделитесь с Вашими друзьями:
1   ...   9   10   11   12   13   14   15   16   ...   24




База данных защищена авторским правом ©vossta.ru 2022
обратиться к администрации

    Главная страница