авторефераты диссертаций БЕСПЛАТНАЯ БИБЛИОТЕКА РОССИИ

КОНФЕРЕНЦИИ, КНИГИ, ПОСОБИЯ, НАУЧНЫЕ ИЗДАНИЯ

<< ГЛАВНАЯ
АГРОИНЖЕНЕРИЯ
АСТРОНОМИЯ
БЕЗОПАСНОСТЬ
БИОЛОГИЯ
ЗЕМЛЯ
ИНФОРМАТИКА
ИСКУССТВОВЕДЕНИЕ
ИСТОРИЯ
КУЛЬТУРОЛОГИЯ
МАШИНОСТРОЕНИЕ
МЕДИЦИНА
МЕТАЛЛУРГИЯ
МЕХАНИКА
ПЕДАГОГИКА
ПОЛИТИКА
ПРИБОРОСТРОЕНИЕ
ПРОДОВОЛЬСТВИЕ
ПСИХОЛОГИЯ
РАДИОТЕХНИКА
СЕЛЬСКОЕ ХОЗЯЙСТВО
СОЦИОЛОГИЯ
СТРОИТЕЛЬСТВО
ТЕХНИЧЕСКИЕ НАУКИ
ТРАНСПОРТ
ФАРМАЦЕВТИКА
ФИЗИКА
ФИЗИОЛОГИЯ
ФИЛОЛОГИЯ
ФИЛОСОФИЯ
ХИМИЯ
ЭКОНОМИКА
ЭЛЕКТРОТЕХНИКА
ЭНЕРГЕТИКА
ЮРИСПРУДЕНЦИЯ
ЯЗЫКОЗНАНИЕ
РАЗНОЕ
КОНТАКТЫ


Pages:     | 1 || 3 | 4 |

«Федеральное агентство связи Государственное образовательное учреждение высшего профессионального образования ПОВОЛЖСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ ...»

-- [ Страница 2 ] --

­ цели, критерии, ограничения, которые формируют логику принятия решений для задач, выполняемых агентом.

Далее запускается личность агента – Agent Personality, реализующая жиз ненный цикл агента. По окончании жизненного цикла регистрация агента в системе удаляется. Об этом уведомляются агенты, связанные с данным, после чего агент удаляется из системы.

На Рисунок 10 показаны фазы жизненного цикла агента.

Знания агента Жизненный цикл агента Восприятие Вход (сообщения,события) Планирование Исполняющая Сенсоры Личность агента система Подтверждение Выход (сообщения, события) Исполнение Память агента Индивидуальная онтологическая сцена (модель Текущие планы мира) Рисунок 10 – Фазы жизненного цикла агента Требования к системам управления мобильными ресурсами, сформулиро ванные ранее, приводят к необходимости обеспечения такой архитектуры мно гоуровневых агентов, которая обладает следующими свойствами:

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

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

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

­ Обучение и накопление опыта. Накопление опыта заключается в постоянном анализе эффективности текущей модели размышлений и изменении модели.

Такая возможность позволяет агенту адаптироваться к изменению во внеш ней среде.

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

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

Система, построенная на агентах, удовлетворяющих этим требованиям, способна осуществлять планирование и принятие решений в распределнных средах, поддерживает гибкую настройку за счет формализации и возможности изменения целей и моделей поведения агентов, способна к адаптации к изме няющимся условиям, а также поддерживает работу в режиме, близком к режи му реального времени [43-46]. Отметим, что программная реализация должна поддерживать значительное количество агентов (тысячи) в рамках одной рабо чей станции, для сокращения накладных расходов при межсерверной коммуни кации агентов и возможности образования «регионов» – скопления агентов, ко торые ведут интенсивные переговоры.

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

В качестве примера реактивных агентов можно выделить наиболее из вестное промежуточное программное обеспечение JADE [40]. Эта система по зволяет строить агентов на уровне активностей (называемых также ролями или поведением). Предлагаются сервисы по обмену сообщениями, нахождению других агентов и сервисов (discovery) и публикации агентами предлагаемых ус луг.

Одним из примеров реализации делиберативной архитектуры является система Jadex [41]. Целью исследовательского проекта Jadex является создание рационального слоя на базе инфраструктуры JADE, обеспечивающего возмож ность построения агентов. Jadex реализует модель BDI, расширяя агентов Jade «убеждениями», «целями» и «намерениями», которые могут быть созданы внутри агента. Для достижения своих целей агент выполняет планы, являю щиеся процедурными средствами, кодированными в Java. В Jadex предусмот рена библиотека планов, которыми может оперировать система. Для пополне ния такой библиотеки программист декомпозирует функциональность, которую должен выполнять агент, в отдельные планы.

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

INTEgration of Reactive behavior and RAtional Plannig – объединение реак тивного поведения и рационального планирования. InteRRaP проектировался с учетом уменьшения разрыва между реактивностью и рассудительностью.

Структура агента имеет послойную организацию, что характерно для смешан ных архитектур.

Главная идея архитектуры InteRRaP состоит в разделении агента на три уровня (в соответствии с идеей смешанной архитектуры, т.е. реактивность и способность к рассуждениям):

­ уровень поведения (behavior-based layer) – включает реактивность и методы решения стандартных (простых) задач;

­ уровень локального планирования (local planning layer) – предоставляет ме ханизм для реализации целеустремленности;

­ уровень совместного планирования (cooperative planning layer) – служит для взаимодействия с другими агентами.

Агент получает на вход ощущение и выдает на выходе определенное дей ствие. Для агента вводится понятие состояния (mental state) и базовых функций, которые могут изменять это состояние.

У InteRRaP агента можно выделить следующие составные части, что в целом соответствует BDI модели:

­ ощущение (perception) агента;

­ множество убеждений (beliefs) – информационное состояние;

­ ситуация (situation) – состояние среды. Она определяется как некоторая структура (множество), состоящая из убеждений агента;

­ множество целей (goals), цель можно определить как состояние среды (си туацию);

­ множество намерений (intentions), намерение – сформировавшийся план действий, который впоследствии выполняется.

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

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

2.3 Мультиагентная платформа планирования Архитектура мультиагентной платформы планирования включает в себя онтологию для хранения знаний о предметной области и логике принятия ре шений по планированию и модуль планирования, обеспечивающий необходи мые вычислительные возможности для работы мультиагентного мира [1-2, 70 85].

2.3.1 Онтология – модель знаний предметной области Для описания знаний, необходимых агентам, входящим в состав МАС, используется онтологический подход, согласно которому знания должны быть отделены от программного кода системы и должны храниться в онтологии, представляющей собой сеть понятий и отношений предметной области.

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

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

На Рисунок 11 – Рисунок 13 показаны основные объекты онтологии транспортной логистики.

Объект Ресурс Заказ Груз Географическая точка Транспортная инструкция Точка исполнения Маршрут точка инструкция исполнения Рисунок 11 – Основные объекты онтологии транспортной логистики Расписание:

Параметры ресурса:

Оптимальная скорость Вместимость Начальное положение Время доступности База приписки Необходимость возврата на базу Рисунок 12 – Понятие ресурса Транспортные инструкции Заказ:

Заказ Транспортная Точки исполнения инструкция:

Транспортная Географическая точка Точка инструкция Тип операции исполнения:

Длительность операции Возможное время начала операции Точка Возможное время окон исполнения чания операции Тип руза Груз:

Объем груза Груз Вес груза Рисунок 13 – Понятие и детализация заказа Разработана структура онтологии для описания основных концептов и отношений предметной области. Классы концептов онтологии организованы в иерархию на принципах наследования, концепт характеризуется свойствами (атрибутами). В онтологии транспортной логистики в качестве основных мож но выделить следующие ключевые понятия (концепты) и их атрибуты:

­ Carrier Company – компания-перевозчик, владеющая грузовиками. В систе ме может быть определено несколько перевозчиков с разными стратегиями.

Атрибуты:

Name – название компании-перевозчика (тип string);

­ Customer – клиент перевозчика, для разных клиентов могут быть определе ны различные стратегии перевозки. Атрибуты:

Name – название клиента (тип string);

­ Transportation instruction (TI) – заказ на перевозку от заданного клиента, описывающий перевозимый груз (или набор грузов), откуда и куда перево зится груз, особые условия перевозки и т.д. Атрибуты:

Name – название (тип string), Creation Time – дата создания (тип date), Priority – приоритет выполнения (тип double), Status – текущее состояние TI (тип int):

modified – TI может быть модифицирована, cancelled – TI может быть удалена, planned –TI успешно запланирована в последнем сеансе планирования, unplanned – TI не запланирована в последнем сеансе планирования;

­ Cargo – груз, который могут перевозить перевозчики (обычно в паллетах), груз может требовать или желать специальных условий перевозки. Атрибу ты:

Volume – вес груза, который может быть транспортирован в соответствии с TI (тип double), Waypoint – операции транспортной логистики, выполняемые над грузами (погрузка - collect cargo, выгрузка - drop cargo и т.д.). Атрибуты:

Duration – продолжительность выполнения операции (тип int), LocationName – название географической точки, в которой должна быть выполнена операция по обработке груза (тип string), TimeWindowFrom – начало периода времени, в течение которого должна быть выполнена операция (тип date), TimeWindowTill – окончание периода времени, в течение которого должна быть выполнена операция (тип date), Type – тип операции по обработке груза (тип int):

collect – операция погрузки, drop – операция выгрузки, none – операция отсутствует;

­ Resource – перевозчик компании (грузовик), характеризуемый вместимо стью, раскраской, обеспечиваемыми условиями перевозки (холодильник), возможностью использования прицепов и т.д. Атрибуты:

BaseLocation – географическая точка размещения депо (тип string);

Capacity – максимальная грузоподъемность (тип int);

InitialDateTime – дата появления ресурса в системе (тип date);

InitialLocation – начальная точка размещения ресурса в системе перед на чалом планирования (тип string);

LoadingSequence – определяет последовательность разгрузки ресурса (тип int):

stack – последовательность в соответствии с дисциплиной “последним пришел - первым вышел”, random – случайная последовательность;

­ GeoLocation – географическое место выгрузки или погрузки товара на карте транспортной сети компании. Атрибуты:

Name – название (тип string), FixedTime – постоянное время, требуемое для обслуживания ресурса в географической точке (не зависит от количества операций;

тип int), TimePerUnit – время, требуемое для обработки одной единицы груза (не зависит от типа операции;

тип int);

­ Pattern – типовой маршрут перевозки. Атрибуты:

Name – название (тип string), Price – стоимость TI, соответствующей паттерну (тип double).

Наряду с базовыми концептами в онтологии транспортной логистики ис пользуются следующие базовые отношения:

Клиент имеет заказ;

­ Заказ содержит груз;

­ Заказ содержит транспортную инструкцию;

­ Флот включает грузовики;

­ Флот включает прицепы;

­ Грузовик имеет расписание;

­ Консолидация транспортных инструкций объединяет отдельные инструк ­ ции;

Поездка имеет транспортную инструкцию;

­ Инструкция имеет расписание;

­ Инструкция состоит из операций;

­ Клиент связан с транспортными инструкциями – HaveTI;

­ Операции связаны с перевозчиками и грузами – HaveCargo;

­ Ресурсы (перевозчики) связаны с их владельцами – HaveOwnerCompany;

­ Ресурсы приемлемы для выполнения транспортной инструкции – ­ AllowedResource;

Транспортные инструкции связаны с отдельными операциями над грузами ­ (инструкция включает эти операции) – HaveWayPoint;

Перевозчик связан с типовыми маршрутами – CarrierHasPattern;

­ Маршрут связан с географическими точками – PatternIncludesGeoLocation.

­ Диграмма классов онтологии транспортной логистики показана на Рису нок 14.

Customer (from ObjectClass) Name : String 1.. 0..n 0.. HaveTI (from Relation) CarrierCompany (from ObjectClass) TransportationInstruction 1.. (from TransportationObject) 1..1 1.. 1.. 1..n 1..n HaveWaypoint TransportationObject Company (from Relation) (from ObjectClass) 1..1 (from TransportationObject) 0..n HaveOwnerCompany (from Relation) 0.. 1..1 AllowedResource Waypoint (from Relation) 0..n (from ObjectClass) 0..n 1.. 1..1 1.. GeoLocation (from TransportationObject) Resource FixedTime : Integer (from TransportationObject) 1..1 0..n Name : String 0.. 1.. 0..n HaveCargo 1..n (from Relation) 0..n 1..n Quantity : Double CarrierHasTIPattern (from Relati...

PatternIncludesGeoLocation 1.. (from Relati...

Cargo 0..n (from ObjectClass) Volume : Double 1.. Pattern (from ObjectClass) 1.. Рисунок 14 – Диаграмма классов онтологии транспортной логистики Модель знаний предметной области (онтология) может быть представле на в виде дерева наследования (в правой части экрана) или в виде семантиче ской сети, вершинами которой являются концепты, а ребрами – отношения ме жду концептами (Рисунок 15).

Описание классов понятий и отношений Рисунок 15 – Способы представления онтологии 2.3.2 Агенты мира транспортной логистики Заказы и ресурсы имеют агентов, представляющих их интересы в систе ме. Кроме них рекомендуется использовать:

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

В Таблица 2 представлен список агентов транспортной сети.

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

­ Company Agent мониторинг ситуации по основным критериям, реагирует на изменение критериев пользователем, выбирает проблему для решения (слишком высокий риск, низкая при быль и т.д.), изменяет стратегии работы агентов;

­ Order Agent следит за изменениями в маршруте, может войти, модифицировать или покинуть маршрут, создает новый маршрут (если нет подходящего), рассчитывает прибыль, ищет лучшие маршруты и ведет переговоры по подвижкам по заданным критериям, реагирует на предложения от других маршрутов;

­ Trip Agent реагирует на предложения изменить маршрут для заказов, находит разные маршруты из А в В (минимальной дистанции, высокой скорости, максимальной комфортности и т.д.), ищет подхваты для построения круговых маршрутов, ищет подходящий грузовик, ­ Truck Agent следит за изменениями в маршрутах, делает предложения маршрутам, когда складывается нужного размера маршрут, рассчитывает стоимость перевозки, ищет варианты лучшего использования;

­ Driver Agent обслуживает предпочтения водителя, ищет подходящие грузовики и маршруты;

­ Fuel Agent определяет лучшие места заправки на маршруте, реагирует на изменения в ценах на заправках, инициирует пересмотр маршрутов при изменении цены на топливо.

Архитектура мира агентов транспортной сети представлена на Рисунок 16.

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

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

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

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

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

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

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

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

Алгоритм планирования представлен на Рисунок 17.

Рисунок 17 – Алгоритм автоматизированного планирования в системе планирования грузоперевозок Пример протокола взаимодействия между агентами в процессе планиро вания приведен на Рисунок 18.

Протокол задачи планирования Агент заказа Агент грузовика Ввести заказ Актуализация заказа Запрос к грузовикам на определение расстояния до цели Определить расстояние до цели Расстояние до цели Сформировать список ближайших грузовиков Запрос о характеристиках грузовиков Определить характеристики грузовиков Прот. Характеристики грузовиков Выбор ближайшего к цели грузовика с соответствующими характеристиками Подтвердить выбор Вернуться в Очередь событий Рисунок 18 – Пример протокола взаимодействия между агентами при ре шении задачи планирования Взаимодействие агентов в процессе пегеговоров при планировании пред ставлено на Рисунок 19.

Пример хода переговоров по подвижкам заказов в процессе планирования приведен на Рисунок 20 – Рисунок 22.

Рисунок 19 – Взаимодействие между агентами в процессе переговоров Шаг Заказ Заказ 2 Заказ Заказ D Шаг Заказ Заказ 1 Заказ 2 Заказ D Рисунок 20 – Шаги 1 и 2. Проведение переговоров при поступлении нового зака за: Заказ 4 меняет свое положение и смещается вправо Шаг Заказ Заказ 2 Заказ Заказ D Шаг Заказ Заказ 1 Заказ 2 Заказ D Рисунок 21 – Шаги 2 и 3. Дальнейшие переговоры: в результате переговоров внутри системы Заказ 2 смещается вправо Шаг 4 Заказ Заказ 2 Заказ Заказ D Шаг Заказ Заказ 2 Заказ Заказ Рисунок 22 – Шаги 4 и 5. Достижение итогового решения: в результате перегово ров Заказ 1 смещается влево и Заказ 4 размещается без конфликтов с другими заказами 2.3.4 Реализация мультиагентной платформы планирования ресурсов Основной функциональной возможностью данной платформы является работа в режиме реального времени и адаптивная реакция в ответ на посту пающие извне события. Для этого информация о данных событиях должна по являться сразу же после их поступления. В связи с этим система должна иметь возможность определять географические координаты всех мобильных ресурсов (например, с помощью GPS), сопоставлять их с электронной картой территории для визуализации всей транспортной сети компании, определять расстояния между различными пунктами на карте и обеспечивать постоянную обратную связь с водителями для обмена информацией. Чтобы реализовать данную функциональность, наиболее оптимальным решением является использование уже имеющихся на рынке геоинформационных и картографических сервисов.

Таким образом, в платформе должны быть богатые возможности по интеграции с новыми сервисами.

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

Рисунок 23 – Логическая архитектура системы На Рисунок 24 представлена физическая архитектура системы. Для раз личных систем, разрабатываемых на базе мультиагентной платформы, вариан ты использования готовых компонентов могут несколько отличаться друг от друга. Причиной тому является разница в требованиях к внедрению в различ ных компаниях, разный уровень «технологической зрелости» (технического ос нащения), а также специфика уже используемого в компаниях программного обеспечения.

Рисунок 24 – Физическая архитектура системы При реализации систем планирования может использоваться такая совре менная модель реализации программного обеспечения, как SaaS (Software as a Service, ПО как сервис), при которой заказчики платят не за владение про граммным обеспечением как таковым, а за его использование, что позволяет распределять стоимость системы по времени использования и количеству поль зователей. Данная модель может стать очень востребованной среди небольших транспортных компаний, не имеющих возможности единовременной оплаты разработки информационных систем, но готовых платить небольшую ежеме сячную плату в расчте на каждое используемое транспортное средство.

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

гори зонт планирования включает от 1 до 7 дней.

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

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

На Рисунок 25 – Рисунок 27 представлены образцы, иллюстрирующие интеллектуальную логику принятия решений, причем основной задачей являет ся адаптивное перепланирование новых заказов в реальном времени.

Первый пример (Рисунок 25) иллюстрирует выбор системой наиболее вы годного варианта размещения с учтом возможных рисков.

На Рисунок 26 представлена ситуация, когда собственный грузовик ком пании запланирован для выполнения заказа 1 и уже находится в пути на по грузку. Сразу же после поступления нового заказа 2 система принимает реше ние использовать для этого заказа уже запланированный собственный грузовик вместо свободного, но дорогостоящего стороннего перевозчика и осуществляет перепланирование заказа 1, подбирая для его выполнения более подходящий ресурс.

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

Рисунок 25 – Планирование грузоперевозок: Ситуация Рисунок 26 – Планирование грузоперевозок: Ситуация Рисунок 27 – Планирование грузоперевозок: Ситуация Таким образом, мультиагентное адаптивное планирование позволяет до биться следующих преимуществ:

­ обеспечение индивидуального подхода к выполнению каждого заказа;

­ автоматизация основных операций операторов по планированию ресурсов;

­ накопление знаний о специфике бизнеса, позволяющих уточнять и совер шенствовать правила принятия решений при планировании;

­ повышение оперативности принятия решений и сокращение времени плани рования;

­ осуществление эффективного наглядного оперативного управления имею щимися заказами, повышение операционной эффективности;

­ своевременное извещение операторов о возможных проблемах (отсутствие заказов на будущее, расхождение между «планом» и «фактом», неэффектив ное использование транспортных средств и т.д.);

­ получение соответствующей комплексной систематизированной отчетности, снижение издержек по составлению и систематизации отчетной документа ции.

3 МУЛЬТИАГЕНТНАЯ СИСТЕМА УПРАВЛЕНИЯ ТРАНСПОРТНЫМИ РЕСУРСАМИ (МАС УТР) Рассмотрим мультиагентную систему управления транспортными ресур сами, реализованную на основе мультиаегнтного подхода и метода адаптивного планирования.

3.1 Назначение системы Мультиагентная система управления транспортными реурсами (МАС УТР) предназначена для использования:

­ менеджерами центрального офиса и филиалов ТЛК (для прима и автомати зированного планирования заявок);

­ руководителями центра и филиалов ТЛК (для мониторинга работы).

МАС УТР предназначена для выполнения следующих функций:

1. Сбор и регистрация заявок на перевозку грузов, вводимых вручную с помо щью регистрационной формы МАС УТР;

2. Мониторинг текущего статуса транспортных средств и заявок (в каком со стоянии на данный момент находится заявка, каково отклонение от плана при его наличии и т.д.) путем организации обратной связи с водителем;

3. Адаптивное автоматическое планирование: назначение ресурсов (транс портных средств, водителей) для выполнения поступающих в режиме реаль ного времени заявок на транспортировку грузов с помощью подсистемы ав томатического планирования;

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

5. Ведение основных справочников: контрагентов, ресурсов, городов и т.п.;

6. Введение справочников атрибутов (тип груза, объем, грузоподъемность и пр.);

7. Визуализация текущего расписания в разрезе любого из имеющихся типов ресурсов за выбранный временной интервал;

8. Формирование печатных форм: при необходимости пользователь может соз дать с помощью редактора печати заявки шаблон требуемого документа и использовать его в дальнейшем;

9. Формирование отчетов для руководителя на основании критериев эффек тивности (график, показывающий доход, себестоимость и рентабельность по запланированным заявкам;

график загрузки водителей и тягачей;

график, отображающий уровень сервиса и т.д.);

10.Учет особенностей использования ресурсов с помощью редактора правил.

В Таблица 3 приведены используемые термины.

Таблица 3 – Термины МАС УТР Работник оперативного отдела, координирующий и контролирующий распределение заявок и осу Диспетчер ществляющий взаимодействие с Собственными ресурсами Юридическое/физическое лицо, размещающее Заявку на перевозку груза и производящее опла Заказчик ту Событие, связанное с поступлением от Заказчика Заявка запроса на оплачиваемую перевозку груза Транспортно-логистическая компания (ТЛК) Клиент План который отражает предполагаемую при быль, выручку, километраж, затраты на перевоз ку. Как правило, он составляется в конце текуще Мастер - план го месяца на следующий. на основании заклю ченных с клиентом долгосрочных договоров Юридическое лицо, осуществляющее перевозку Перевозчик Водитель/Тягач/Прицеп Ресурсы Ресурсы, находящиеся в оперативном управле Собственные нии ТЛК ресурсы/флот Ресурсы, принадлежащие Перевозчику, не нахо Сторонние дятся в оперативном управлении ТЛК ресурсы/флот Документ учета движения товарно-материальных Товарно ценностей;

составляется грузоотправителем для транспортная каждого грузополучателя отдельно на каждую накладная (ТТН) поставку Юридическое лицо, которое осуществляет поиск Экспедитор перевозчика, выступает в качестве посредника 3.2 Установка и запуск системы Для корректной работы с системой рабочая станция пользователя должна удовлетворять следующим основным требованиям к аппаратной и программ ной части:

­ Процессор Intel Pentium 4 с тактовой частотой не менее 1,6 Ггц;

­ Объем оперативной памяти – не менее 512 Мб (рекомендуется – 1024 Мб);

­ Операционная система Microsoft Windows XP Service Pack 2 / Microsoft Win dows Vista;

­ Microsoft.NET Framework 3.5;

­ Пакет офисных программ Microsoft Office 2000 или выше.

Для работы с системой необходимо запустить следующие компоненты:

­ Приложение для доступа к БД системы;

­ Подсистему автоматического планирования;

­ Собственно клиентское приложение.

При запуске клиентского приложения необходимо в окне аутентифика ции пользователя ввести логин и пароль (Рисунок 28).

Рисунок 28 – Окно аутентификации пользователя Описываемая система имеет физическую архитектуру клиент-сервер на основе технологий Java Enterprise Edition версии 5.0. Для доступа к данным ис пользуется технология Enterprise Java Beans 3.0 Persistence и Hibernate, что по зволит достаточно просто сменить СУБД в случае необходимости. Рекомен дуемые СУБД – MS SQL Server 2000/2005 или Oracle 10g.

3.3 Начало работы с системой 3.3.1 Интерфейс и главное окно системы МАС УТР обладает графическим интерфейсом пользователя и имеет большинство стандартных элементов интерфейса, таких как меню, кнопки ко манд, вкладки, списки, кнопки-флажки и др.

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

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

Навигация осуществляется из главного окна МАС УТР (Рисунок 29).

Рисунок 29 – Главное окно МАС УТР Доступ ко всем экранным формам осуществляется путем выбора соответ ствующих опций главного меню системы (Рисунок 30), а также через кнопки на формах, в рамках выполнения определенных функциональных задач.

Рисунок 30 – Опции главного меню системы Опции главного меню системы:

­ «Управление» - позволяет управлять информацией по заявкам и ресурсам;

­ «Справочники» - предназначается для хранения всевозможной информации по ресурсам, контрагентам, единицам измерения и т.п.;

­ «Мониторинг» - позволяет визуализировать созданные расписания по каж дому из ресурсов, обеспечивает доступ к электронной карте, а также быстро получить самую актуальную информацию по заявкам и ресурсам;

­ «Отчеты» - предназначается для мониторинга деятельности компании в це лом;

­ «Администрирование» - используется для настройки разделения прав досту па для различных категорий пользователей, определения филиалов и задания правил;

­ «Открытые формы» - позволяет изменять настройки интерфейса и просмат ривать все открытые формы;

­ «Настройки» – позволяет устанавливать величины, используемые по умол чанию;

­ «Помощь»- предоставляет информацию о функционале системы и о системе в целом.

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

­ Создать – позволяет вводить новую информацию (создать новую заявку, контрагента и т.п.);

­ Скопировать – позволяет создать копию уже существующей формы (напри мер, заявки);

­ Открыть – используется для того, чтобы открыть форму с уже введенными данными (существующую форму заявки, контрагента);

­ Обновить – используется для актуализации данных;

­ Удалить – используется для удаления выделенного элемента;

­ Восстановить – в случае, если на форме проставлен флажок «Показывать удаленные записи» с помощью этой кнопки можно восстановить выделен ную удаленную запись;

­ Показывать удаленные – используется для просмотра удаленных заявок. Все удаленные заявки помечены зачеркиванием и имеют более светлый цвет шрифта.

­ Закрепить в центре - при отжатии кнопки форма будет отображаться в виде отдельного окна, которое пользователь может расположить в том порядке, в котором ему удобно.

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

На форме всех выпадающих списков расположены следующие пикто граммы, унифицированные в рамках МАС УТР:

(Выбрать) – выделенная запись подставляется в поле выбора;

­ (Обновить) – обновление данных выпадающего списка;

­ (Добавить)– вызов окна добавления новой записи соответствующего ­ справочника;

(Закрыть) – закрытие окна выпадающего списка.

­ ­ 3.3.2 Ввод новой заявки Для ввода новой заявки необходимо выбрать опцию меню «Управление»

«Заявки». В появившемся окне в верхней части экрана пользователю необ ходимо нажать кнопку «Создать», в результате чего откроется регистрационная форма заявки (Рисунок 31).

Для перехода по полям используются «горячие» клавиши или мышь.

кнопка редактирования Рисунок 31 – Окно регистрации новой заявки Все поля заявки, за исключением полей «Номер заявки» и «Дата ввода за явки», будут пустыми. Поле «Номер заявки» формируется системой автомати чески и является неизменяемым. Поля, обязательные для заполнения, помече ны пиктограммой.

Дата ввода заявки соответствует дате и времени создания заявки. При желании пользователь может скорректировать данные значения.

Поля «№ заявки вход», «№ и дата доверенности» предназначены для руч ного ввода входных и выходных данных по заявке. Поле «№ и дата доверенно сти» предназначено для ввода номера доверенности, выданной водителю на пе ревозку груза и дату ее выдачи. Поле «Юр. лицо заказчику» предназначено для определения компании, имя которой будет фигурировать в документах выдан ных заказчику.

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

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

Для облегчения ввода предполагаемых заявок в журнале заявок сущест вует кнопка «В мастер-план», которая позволит создать копии уже существую щих заявок с проставленной галочкой «Предполагаемая». Для этого необходи мо в журнале заявок выделить требуемую заявку и нажать кнопку «В мастер план». У созданных заявок поля «Запланированное время», «Предпочитаемое время» и «Фактическое время» на вкладке «Операции» будут пустыми. В слу чае если необходимо создать несколько предполагаемых заявок, то следует на жать клавишу ctrl, выделить требуемые заявки, и далее нажать кнопку «В мастер-план».

Для того чтобы ввести название заказчика, т.е. организации, которая сде лала заказ, необходимо из выпадающего списка выбрать наименование заказ чика. Если контрагент отсутствует в данном списке, то необходимо ввести дан ного заказчика в справочник «Организация» (подробнее об этом – в разделе 0).

Также для контрагента необходимо указать его географическое местопо ложение – локацию.

В случае необходимости отредактировать уже имеющуюся информацию по контрагенту, необходимо нажать на знак многоточия (…) в поле «Заказчик»

(при условии, что в поле уже указано наименование организации).

Флажок в окне «Экспедитор» подразумевает, что заказчик является экс педитором. В случае если флажок не был проставлен, то организация, исполь зующая АС УТР сама выступает в качестве экспедитора либо перевозчика.

Флажок «Экспедитор» в данном окне является редактируемым, помечается в том случае, если в справочнике «Организации» был проставлен соответствую щий флажок.

Данные, касающиеся детальных сведений по заявке, сгруппированы в виде отдельных вкладок:

­ на вкладке «Сведения» содержится информация о параметрах заявки;

­ на вкладке «Операции» вводится информация о местах и времени погрузки / разгрузки;

­ вкладка «Планирование» используется для вывода информации о ресурсах, назначенных на данную заявку и указания предпочитаемых ресурсов;

­ на вкладке «Дополнительные сведения» содержится контактная информация о перевозчиках и водителях;

­ на вкладке «Импортированные сведения» будет содержать какую-либо ин формацию только в случае, если данная заявка была импортирована из внешнего файла;

­ на вкладке «Результат перевозки» отражена информация о внештатных си туациях, возникших при перевозке.

3.3.3 Последовательность действий менеджера по обработке заявки В данном разделе приводится описание последовательных действий ме неджера для обработки конкретной заявки.

После получения заявки менеджер должен зарегистрировать ее в АСУ ТР.

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

Далее данные заявки проверяются и утверждаются нажатием кнопки «Принято». Если пользователь заполнил не все обязательные поля, то кнопка «Принято» будет неактивной.

После утверждения заявки менеджер приступает к планированию. При планировании заявки в АС УТР менеджер может использовать два режима ра боты:

­ Автоматическое планирование (назначение заявки на ресурс осуществляется подсистемой автоматического планирования самостоятельно;

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

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

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

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

После наступления запланированного времени начала выполнения заявки менеджер отслеживает фактическое время выполнение заявки. Для этого в окне регистрационной формы заявки на вкладке «Операции» менеджер отмечает фактическое время начала и/или окончания соответствующей операции. Для ускорения ввода фактического времени выполнения операции пользователь может использовать кнопки «Фактическое начало» и «Фактическое окончание»

на вкладке «Операции» регистрационной формы заявки.

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

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

При выборе режима автоматического планирования менеджер должен выполнить следующую последовательность шагов:

1. Создать группировки, выбрав опцию главного меню «Управление»

«Группы ресурсов - Заданные» таким образом, обозначив для системы, ка кой водитель, на каком тягаче и прицепе ездит.

2. Создать корректировки – то есть указать для каждого ресурса группировок начальное местоположение.

3. Ввести новую заявку, заполнив все обязательные поля.

4. В регистрационной форме заявки нажать кнопку «Автоматическое планиро вание».

5. Подсистема автоматического планирования из введенных группировок ав томатически выберет подходящую тройку (или двойку) и назначит заявку на выбранные ресурсы. Менеджер не указывает никаких ресурсов на вкладке «Планирование» вручную.

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

3.3.3.2 Работа в ручном режиме Если менеджер использует «ручной» режим планирования, то приоритет остается за ним, т.е. если менеджер указывает предпочитаемые ресурсы на вкладке «Планирование», регистрационной формы заявки, то МАС УТР назна чает заявку именно на те ресурсы (водителя, прицеп и тягач), которые указал менеджер (прицеп может быть не указан).

При выборе режима «ручного» планирования менеджер должен выпол нить следующую последовательность шагов:

1. Ввести новую заявку, заполнив все обязательные поля.

2. В регистрационной форме заявки на вкладке «Планирование» указать те ре сурсы, которые будут исполнять данную заявку.

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

1. Указать для каждого ресурса его начальное местоположение.

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

3. Если же менеджер проводит корректировку варианта транспортного средст ва, подобранного системой автоматически, то кнопка «Автоматическое пла нирование» остается нажатой во время ввода предпочитаемых ресурсов, а по завершении их ввода менеджер нажимает кнопку «Сохранить».

4. МАС УТР назначит указанные предпочитаемые ресурсы на заявку, если не имеется никаких противоречий (ресурс уже назначен на выполнение другой более выгодной заявки и т.п.).


3.4 Управление 3.4.1 Управление ресурсами 3.4.1.1 Мастер-план Мастер-план предназначен для того, чтобы сравнивать план с фактом, а именно сравнивать достижение запланированных показателей с показателями, достигнутыми на текущий момент. Для того чтобы создать мастер-план, необ ходимо выбрать опцию меню «Управление» «Мастер-планы», нажать кноп ку «Создать» и в открывшемся окне выбрать требуемый период времени (Рисунок 32). В результате высветится список заявок, которые были запланиро ваны и у которых начало первой операции попадает в выбранный период вре мени. Как правило, на момент создания Мастер плана у всех заявок в данном списке проставлена галочка «Предполагаемая», т.к. сначала предполагаемые заявки вводятся, затем планируются, а затем уже создается документ «Мастер план», который фиксирует расчетные значения на момент утверждения плана, такие как Прибыль, Выручка, Километраж, Затраты на перевозку, Затраты на простой, Затраты всего. После сохранения мастер - плана первоначальные «расчетные» значения фиксируются и переносятся в верхнюю часть формы, а в нижней же части формы отражаются текущие значения, которые были рассчи таны системой на текущий момент (Рисунок 33). В дальнейшем, при открытии данного документа в любой момент пользователь может сравнить текущие по казатели с запланированными и проконтролировать выполнение плана.

Рисунок 32 – Мастер-план Рисунок 33 – Отчет мастер-плана 3.4.1.2 Корректировки местоположения Для осуществления планирования необходимо указать местоположение конкретного тягача, прицепа и водителя. Без указания начального местополо жения подсистема автоматического планирования «не видит» ресурс. Местопо ложение ресурса задается документом «корректировки» местоположения.

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

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

­ для привлеченных ресурсов предусмотрена возможность неоднократного ввода корректировок местоположения. Предполагается, что система не об ладает полными данными о привлеченных ресурсах, их положение может измениться без участия системы (привлеченный ресурс выполнял заявку другой компании). Поэтому местоположение привлеченного ресурса счита ется актуальным лишь в течение 24 часов после выполнения им последней заявки из списка заказов системы.

В системе предусмотрено три способа указания местоположения ресурса:

­ с помощью опции меню «Управление» Корректировки местоположения (Рисунок 34);

­ при помощи кнопки «Изменить текущее местонахождение» в карточке ре сурса (местоположение задается отдельно для каждого из ресурсов водитель, тягач, прицеп);

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

и «Дата и время», которые соответствует дате и времени первой погрузки данной заявки.

­ Рисунок 34 – Корректировки местоположения Визуально проследить перемещение водителя, прицепа и тягача можно с помощью опции меню «Мониторинг». Данные могут быть представлены на диаграмме Гантта («Мониторинг» «Расписание водите лей/тягачей/прицепов»), а также на карте («Мониторинг» «Расположение тя гачей») В случае если фактическое местоположение ресурса не совпадает с ме стоположением по данным системы (например, согласно значению адреса раз грузки, указанному в последней заявке, выполненной данным ресурсом, он должен находиться в Казани, а фактически ресурс находится в Москве), ме неджер должен указать в МАС УТР истинное местонахождение ресурсов. Для этого менеджер должен создать новую запись, в которой и указать новую лока цию (местонахождение ресурса). При нажатии кнопки «Создать» на экране отобразится окно (Рисунок 35), в котором пользователь может ввести новое ме стоположение ресурса. При нажатии кнопки «Открыть» открывается окно уже созданной корректировки.

Рисунок 35 – Окно добавления корректировки местоположения В случае если не установлен флажок «Обрабатывать при планировании», подсистема автоматического планирования не учитывает данный ресурс в про цессе планирования. Такая запись будет выделена зеленым цветом.

3.4.1.3 Периоды недоступности Данные документы создаются, чтобы менеджер мог указать, в какой пе риод времени тот или иной ресурс недоступен, т.е. система не должна планиро вать заявки на данный ресурс. Для ввода информации о недоступности ресурса используется опция меню «Управление Периоды недоступности (Рисунок 36).

При нажатии кнопки «Создать» на экране отобразится окно (Рисунок 37), в котором пользователь может ввести новую запись о недоступности ресурса.

При нажатии кнопки «Открыть» открывается окно уже созданной недоступно сти.

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

Рисунок 36 – Периоды недоступности Рисунок 37 – Окно добавления недоступности ресурса 3.4.1.4 Регистрация транспорта стороннего перевозчика Данный пункт меню предназначен для ведения сведений о ресурсах при влеченных перевозчиков. Для ввода информации о них используется опция ме ню «Управление» «Регистрация транспорта стороннего перевозчика»

(Рисунок 38).

Рисунок 38 – Регистрация транспорта стороннего перевозчика При нажатии кнопки «Создать» на экране отобразится окно (Рисунок 39), в котором пользователь может ввести запись о новом стороннем перевозчике.

При нажатии кнопки «Открыть» открывается окно уже существующей записи.

Для сторонних ресурсов с помощью выпадающих списков указывается следующая информация (Рисунок 39):

­ тип транспорта – указывается тип прицепа;

­ область местонахождения – обозначается зона предполагаемой погрузки (область, штат и т.п.);

­ область направления – обозначается зона предполагаемой разгрузки (об ласть, штат и т.п.);

­ организация – указывается наименование организации-перевозчика;

­ время начала и время окончания – указывается период, когда указанный ре сурс доступен.

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

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

­ адрес погрузки с областью нахождения ресурса;

­ адрес разгрузки с областью направления;

­ требуемый тип требуемого прицепа с указанным типом транспорта.

­ Рисунок 39 – Окно ввода сведений о привлеченном ресурсе В результате сопоставления в разделе «Зарегистрированные перевозчики»

на вкладке «Планирование» (Рисунок 49) будут отражаться только ресурсы, полностью удовлетворяющие параметрам заявки.

3.4.1.5 Группы ресурсов Под группой понимают возможные приемлемые сочетания ресурсов (во дителей, прицепов и тягачей), которые показывают, что в указанный промежу ток времени данный водитель может быть назначен на определенный тягач и прицеп. В группировке указывают устоявшиеся «тройки» (т.е. какой водитель, на каком тягаче и прицепе ездит) или «двойки» (если указан только водитель и тягач), а также период, в течение которого существование данной тройки (двойки) актуально. Указывать все возможные сочетания водитель – прицеп – тягач нецелесообразно.

Группировку ресурсов можно создать в окне «Управление» «Группы ресурсов – Заданные» » (Рисунок 40).

Рисунок 40 – Группы ресурсов - Заданные При нажатии кнопки «Создать» на экране отобразится окно (Рисунок 41), в котором пользователь может ввести запись о новом стороннем перевозчике.

При нажатии кнопки «Открыть» открывается окно редактирования уже суще ствующей записи.

В случае если не установлен флажок «Обрабатывать при планировании», то подсистема автоматического планирования не учитывает данную группу ре сурсов в процессе планирования. Такая запись будет выделена зеленым цветом.

Документ по группировке создается с указанием временного периода (т.е.

указываются даты, когда конкретный водитель может ездить на конкретном грузовике и прицепе).

Отслеживать актуальные группы ресурсов (т.е. действующие на текущий момент времени) можно в окне «Управление» «Группы ресурсов - Текущие»

(Рисунок 42).

Рисунок 41 – Окно регистрации группы ресурсов Рисунок 42 – Группы ресурсов - Текущие Для удобства пользователя в окне «Группы ресурсов - Текущие» помимо основных кнопок используются специальные кнопки:

­ кнопка «Прекратить» используется для того, чтобы указать текущие дату и время в качестве времени окончания действия выделенной группировки;

­ кнопка «Перегруппировать» используется для открытия формы ускоренного ввода изменений в группу (Рисунок 43). В результате выбранная группиров ка будет закрыта текущей датой, а в появившемся окне будет сформирована новая группа, при этом дата начала будет соответствовать текущей дате, ре сурсы по умолчанию будут также проставлены. Менеджер должен будет из менить только требуемый ресурс и указать дату окончания новой группи ровки.

­ Рисунок 43 – Окно перегруппировки ресурсов 3.4.2 Управление заявками 3.4.2.1 Просмотр списка заявок Для отображения всех заявок необходимо выбрать опцию меню «Управ ление» «Заявки». По каждой заявке отображается информация, позволяющая менеджеру осуществлять мониторинг всего списка заявок (Рисунок 44).


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

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

Отфильтровать заявки можно также с помощью Фильтра по дате заявки.

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

На форме «Управление заявками» указана обобщенная информация по следующим полям:

­ Номер заявки – указывается номер заявки, формируемый системой автома тически;

­ Дата заявки - указывается дата регистрация заявки;

­ Статус заявки – позволяет отслеживать текущее состояние заявки;

­ Заказчик – указывается краткое наименование заказчика;

­ Дата загрузки – указывается дата и время первой загрузки;

­ Место загрузки – указывается только наименование города загрузки;

­ Дата разгрузки – указывается дата и время последней разгрузки;

­ Место разгрузки – указывается только наименование города разгрузки;

­ Перевозчик – указывается наименование перевозчика, осуществляющего пе ревозку;

­ Водитель – указывается фамилия, имя, отчество водителя, выполняющего заявку;

­ Модель – указывается наименование модели тягача;

­ Номер тягача – указывается гос. номер регистрации тягача;

­ Тип прицепа – указывается тип прицепа;

­ Номер прицепа – указывается гос. номер регистрации прицепа;

­ Офис – наименование офиса менеджера, который или внес заявку в систему, или внес последние изменения в регистрационной форме заявки;

­ Менеджер – указывается логин менеджера, внесшего последние изменения в заявку;

­ Стоимость от заказчика – указывается стоимость заявки;

­ Стоимость перевозчику – указывается величина стоимости, выплачиваемой перевозчику за выполнение заявки;

­ Передано – наличие данного флажка означает, что сведения по заявке пере даны в систему 1С.

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

Рисунок 44 – Управление заявками Кроме этого, в системе предусмотрена возможность настраивания кон кретным пользователем «под себя» списка и порядка столбцов в форме управ ление заявками.

­ Чтобы скрыть столбец, надо установить мышку на заголовок соответствую щего столбца правая клавиша выбрать пункт меню «Скрывать эту ко лонку» столбец будет скрыт.

­ Чтобы отобразить столбец: установить мышку на заголовок любого столбца правая клавиша настройка колонок в отобразившемся окошке будет список скрытых столбцов. Выбирается тот столбец, который необходимо восстановить, затем правая клавиши мыши выбрать пункт меню «Пока зывать эту колонку» столбец будет восстановлен.

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

Помимо основных кнопок («Создать», «Открыть», «Удалить», «Обно вить», «Показывать удаленные», «Закрепить в центре») в верхней части окна имеются следующие кнопки:

­ Восстановить – данная кнопка используется для восстановления удаленных данных, поэтому она становится активной только при выделении удаленной ранее заявки;

­ В мастер – план – используется для копирования заявок в мастер-план;

­ Печать – при нажатии на данную кнопку вызывается окно с параметрами печати. Позволяет распечатать список заявок;

Экспорт – с помощью данной кнопки реализована возможность экспорта ­ списка заявок в MS Excel;

Реверсивная загрузка – данная кнопка предназначена для того, чтобы вновь ­ поступающие заявки появлялись в начале списка всех заявок;

Загрузить все - при помощи данной кнопки можно загрузить весь список ­ заявок, введенных в систему;

Остановить – при помощи данной кнопки можно остановить процесс загруз ­ ки всех заявок в систему.

3.4.2.2 Статусы заявок Для отображения статуса заявки приняты следующие цветовые обозначе ния:

­ светло-желтый цвет – не утвержденная заявка или импортированная. В сис теме предусмотрена возможность импорта заявок из внешних файлов (из файлов MS Excel, текстовых файлов формата.rtf);

­ светло-зеленый цвет – утвержденная заявка;

­ голубой цвет – заявка выполняется;

­ светло - розовый цвет – запланировано не в срок (т.е. запланированное время выполнения заявки не соответствует предпочитаемому времени) ­ розовый цвет - заявка находится в процессе планирования (В обработке).

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

После открытия и сохранения регистрационной формы новой заявки она будет иметь состояние «Неутвержденная» и отображаться светло-желтым цве том в списке заявок. Если заявка импортирована из внешнего файла, то она также будет окрашена в светло-желтый цвет, и будет иметь статус «Импорти рованная».

Пользователь заполняет все обязательные поля. Для сохранения введен ных изменений необходимо нажать кнопку «Сохранить».

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

После нажатия кнопки «Автоматическое планирование» в верхней части регистрационной формы статус заявки изменится с «Утвержденная» на «В об работке».

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

После наступления запланированного времени начала выполнения заявки менеджер отслеживает и проставляет фактическое время выполнение заявки.

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

Статус «Выполненная» – когда данная заявка была запланирована и про ставлено время окончания последней операции заявки.

В Таблица 4 приведены основные условия и действия, приводящие к из менению статуса заявок.

Таблица 4 – Статусы заявок № Статус заявки Необходимые условия Цвет заявки Неутвержденная Не все обязательные поля в регистра- светло 1.

или Импортиро- ционной форме заявки заполнены желтый ванная и/или кнопка "Принято" не включена Утвержденная Включена кнопка "Принято" светло-зеленая 2.

В обработке Включена кнопка "Автоматическое розовый 3.

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

вкладке "Планирование" в разделе "Транспортное средство" заполнены поля ресурсов Выполняется Проставлено фактическое время на- голубой 5.

чала первой операции заявки и заявка была запланирована Выполненная Проставлено фактическое время нет цвета 6.

окончания последней операции заяв ки и заявка была запланирована Закрытая Проставлено фактическое время нет цвета 7.

окончания последней операции заяв ки и № и дата ТТН Запланировано не Заявка запланирована, но запланиро- светло 8.

в срок ванное время выполнения какой-либо розовый операции не совпадает с предпочи таемым временем Удаленная Заявка была удалена из регистраци- светло-серый 9.

онной формы заявок цвет, сама за явка зачеркну та Отмененная Заявка была отменена нет цвета 10.

3.4.2.3 Вкладка « Общие сведения»

Данные, касающиеся детальных сведений по заявке, указываются на вкладке «Общие сведения» (Рисунок 45).

­ Раздел «Свойства» содержит детальные сведения о заявке:

выпадающий список «Валюта» предназначен для выбора наименования валюты, в которой будет осуществлен расчет по заявке (рубль, доллар США или евро);

поле «Курс валюты» применяется для указания курса, по которому будет осуществлен перерасчет в рублевом эквиваленте (по умолчанию указыва ется единица (1), соответствующая одному рублю). Поле обязательно для заполнения;

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

выпадающий список «Форма оплаты заказчика» используется для указа ния формы оплаты (наличная/безналичная) при проведении расчетов с заказчиком;

поле «Средняя стоимость по стране» предназначено для указания средней стоимости топлива по стране;

в поле «Топливный сбор» указывается до полнительный сбор за топливо в случае повышения его стоимости (ис пользуется при необходимости);

Поле «Единица длины» предназначено для того, чтобы определить в ка ких единицах измерения будут в дальнейшем указаны параметры груза (длина, ширина, высота);

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

флажки «Страховка груза», «Наличие страховой ответственности пере возчика», «Страхование ответственности заказчика» предназначены для учета информации о страховании груза;

флажок «Обратная загрузка» используется в качестве справочной инфор мации;

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

­ В раздел «Междугородняя / Международная» вводится информация, если заявка является международной:

в текстовые поля «Таможня грузополучателя» и «Таможня грузоотправи теля» вносятся сведения о наименовании таможен;

в поле «Особые условия» вводится дополнительная текстовая информа ция.

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

в подразделе «Общие сведения» указать «№ заявки у заказчика» (номер заявки, который уже был присвоен заказчиком для данной заявки) и «Плотность» (плотность перевозимого груза);

в подразделе «Упаковка» в поле «Кол-во» определить количество упако вочных единиц, в поле «Ед» указать их тип (к примеру, 10 палеток), в по ле «Тип» указать тип упаковки (к примеру, палетки);

в подразделе «Общий вес» указать вес всего груза «Нетто» (без упаковки) и «Брутто» (с упаковкой);

в подразделе «Размеры» пользователь должен указать размеры всего пе ревозимого груза, а именно его длину, ширину, высоту и объем;

в подразделе «Содержимое» в поле «Кол-во» определить кол-во единиц товара в одной упаковке (к примеру, в одной палетке 20 бутылок молока), в поле «Тип» - указать тип самого груза («молоко»), далее в поле «Еди ницы» - указать (к примеру, «бутылки»), «Вес единицы» - указать вес од ной бутылки и в поле «Стоимость единицы» - стоимость одной бутылки;

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

в подразделе «Дополнительная информация» пользователь может указать дополнительную информацию о перевозимом грузе.

Кнопки «Добавить», «Изменить», «Удалить» используются для создания, изменения и удаления различных грузов.

Рисунок 45 – Вкладка « Общие сведения»

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

3.4.2.4 Вкладка «Операции»

В рамках одной заявки может фигурировать несколько адресов погрузки и разгрузки. В рамках каждого адреса могут осуществляться следующие дейст вия: перемещение, погрузка, подготовка, разгрузка, стоянка. Все эти действия отражены на данной вкладке. Для обозначения данных понятий используется вкладка "Операция" регистрационной формы заявки (Рисунок 47). Добавить новую операцию можно следующими способами:

­ используя кнопку «Добавить» на вкладке «Операции» формы редактирова ния заявки, при нажатии которой открывается окно редактирования опера ции;

­ используя поля ускоренного ввода операций на вкладке «Операции».

1. В первом случае в появившемся окне редактирования операции (Рисунок 47) необходимо указать следующие данные:

­ тип операции. В зависимости от выбранного типа (погрузка, порожний пе реезд, разгрузка, транспортировка, или стоянка) активны будут те поля, ко торые относятся непосредственно к выбранному типу операции. Например, если выбрана операция "Разгрузка", то поля "Грузоотправитель", и "Адрес отправителя" будут недоступны, так как данные поля относятся к другому типу операций («Погрузка»).

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

«Организации»), либо через кнопку «Добавить» в окне выпадающего списка.

Новое значение автоматически будет проставлено в поле «Грузоотправитель / Грузополучатель». Следует отметить, что в выпадающем списке будут вы свечиваться только те организации, которые были отмечены как «Грузоот правитель»/»Грузополучатель» соответственно в карточке организации.

­ Пункт отправления/назначения, Город отправления/назначения. Для того чтобы ввести пункт отправления/назначения, следует в соответствующем поле с выпадающим списком указать необходимый адрес. Если в выпадаю щем списке необходимый адрес отсутствует, то следует внести этот адрес в справочник локаций, перейдя в него непосредственно через опцию меню «Справочники» «Локации» (Рисунок 67) или на вкладке «Локации» в ре гистрационном окне соответствующего контрагента (Рисунок 67).

­ Километраж, км. указывается автоматически при автоматическом планиро вании.

­ Длительность каждой конкретной операции (погрузки, разгрузки и т.п.) ука зывается в поле «Длительность, мин.».

­ Предпочитаемое и фактическое время начала/окончания выполнения опера ции. В полях «Предпочитаемое время начала»/ «Предпочитаемое время окончания» указывается время, к которому необходимо начать / закончить операцию по требованию заказчика. Поля «Фактическое время начала»/ «Фактическое время окончания» используются для отслеживания менедже ром момента непосредственного начала/окончания выполнения операции.

­ Комментарий (в случае необходимости).

2. Ускоренный ввод операций осуществляется с помощью полей «Организа ция», «Адрес», «Предпочитаемое время начала», «Длительность», располо женных в нижней части экрана. В поле «Организация» по умолчанию про ставляется то же значение, что и в поле «Заказчик» (при необходимости пользователь может изменить значение в поле «Организация»). Значения в поле «Длительность» проставляются автоматически на основании данных, указанных в карточке выбранной организации («Справочник» «Организа ции» поле «Нормативное время»);

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

Временные данные считаются указанными корректно в следующих слу чаях:

­ Заполнено только поле «Длительность» для всех операций погруз ки/разгрузки (при этом заявка будет планироваться на самое раннее время, которое возможно);

­ Заполнены поля «Предпочитаемое время начала» и «Предпочитаемое время окончания»;

­ Заполнены поля «Предпочитаемое время начала» и «Длительность»;

­ Заполнены поля «Предпочитаемое время окончания» и «Длительность».

­ Рисунок 47 – Добавление новой операции Для редактирования ранее введенной информации по какой-либо опера ции необходимо нажать на кнопку «Открыть», в этом случае будет открыто ок но (Рисунок 47) с уже введенными данными. Для сохранения отредактирован ных данных необходимо нажать на кнопку «Сохранить».

Для удаления введенной операции используется кнопка «Удалить». Уда ленная операция будет помечена флажком в столбце «Закрыт» табличной части вкладки «Операции». Таким образом, пользователь видит все свои действия с операциями и при желании может их скорректировать. Однако, после того как пользователь сохранит заявку (а, следовательно, и все введенные изменения) удаленные операции отображаться не будут.

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

В системе осуществляется проверка правильности ввода дат:

­ если операция является первой в последовательности, то ее окончание должно быть раньше даты начала последующей операции;

­ если операция является последней, то дата ее начала должна быть позже да ты окончания предыдущей операции;

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

Если время и последовательность заданы некорректно, то соответствую щая операция выделяется розовым цветом (Рисунок 48).



Pages:     | 1 || 3 | 4 |
 





 
© 2013 www.libed.ru - «Бесплатная библиотека научно-практических конференций»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.