СИСТЕМА ПРИНЯТИЯ РЕШЕНИЙ В РАМКАХ КОНЦЕПЦИИ ИСПОЛЬЗОВАНИЯ ГЛОНАСС ДЛЯ ОТСЛЕЖИВАНИЯ ОБЪЕКТОВ В ЗОНЕ КОНТРОЛЯ
Авторы:
1.
Грозненский государственный нефтяной технический университет им. акад. М. Д. Миллионщикова
Тип:
Статья
Страницы:
с 88
по 97
Статус:
Опубликован
Получено:
05.04.2017
Одобрено:
28.02.2020
Опубликовано:
25.04.2017
Классификаторы:
ВАК 05.12.2013 Системы, сети и устройства телекоммуникаций
ВАК 05.13.01 Системный анализ, управление и обработка информации (по отраслям)
ВАК 05.13.06 Автоматизация и управление технологическими процессами и производствами (по отраслям)
ВАК 05.13.10 Управление в социальных и экономических системах
ВАК 05.13.18 Математическое моделирование, численные методы и комплексы программ
ВАК 05.13.19 Методы и системы защиты информации, информационная безопасность
УДК 681.327.1/13
ГРНТИ 20.01 Общие вопросы информатики
ГРНТИ 28.01 Общие вопросы кибернетики
ГРНТИ 49.01 Общие вопросы связи
ГРНТИ 50.01 Общие вопросы автоматики и вычислительной техники
ГРНТИ 82.01 Общие вопросы организации и управления
ВАК 05.13.01 Системный анализ, управление и обработка информации (по отраслям)
ВАК 05.13.06 Автоматизация и управление технологическими процессами и производствами (по отраслям)
ВАК 05.13.10 Управление в социальных и экономических системах
ВАК 05.13.18 Математическое моделирование, численные методы и комплексы программ
ВАК 05.13.19 Методы и системы защиты информации, информационная безопасность
УДК 681.327.1/13
ГРНТИ 20.01 Общие вопросы информатики
ГРНТИ 28.01 Общие вопросы кибернетики
ГРНТИ 49.01 Общие вопросы связи
ГРНТИ 50.01 Общие вопросы автоматики и вычислительной техники
ГРНТИ 82.01 Общие вопросы организации и управления
Язык материала:
русский
Ключевые слова:
ГЛОНАСС, транспортная логистика, общий алгоритм, принятие решений, информационные технологии
Аннотация (русский):
Рассматривается задача построения подсистемы поддержки принятия решений в системе транспортной логистики на основе новой концепции использования навигационных систем, которая, в отличие от существующих концепций, не только фиксирует факт нарушения регламента перемещения груза или его хранения, но и позволяет воспрепятствовать злоумышленным действиям по отношению к обрабатываемому грузу. Для унификации процедуры принятия решений предложен общий формат типовых шаблонов ситуации принятия решений, включающий следующие разделы: тип нестандартной ситуации; территориально-пространственные характеристики нестандартной ситуации; описание нестандартной ситуации; паспортные данные источников, из которых поступила информация о нестандартной ситуации; специфические параметры и характеристики нестандартной ситуации; фиксации отдельных стадий изменения нестандартной ситуации во времени; статистические данные по каждой нестандартной ситуации. Раскрыто и детализировано содержание каждого из перечисленных разделов. Приведен общий алгоритм процесса принятия решений в системе оказания услуг ГЛОНАСС по транспортной логистике, которая должна быть размещена в диспетчерском центре транспортной компании, оказывающей услуги по перевозке грузов. На основе анализа алгоритма сформирован перечень информационных технологий, которые целесообразно использовать в предложенной системе оказания услуг ГЛОНАСС.
Рассматривается задача построения подсистемы поддержки принятия решений в системе транспортной логистики на основе новой концепции использования навигационных систем, которая, в отличие от существующих концепций, не только фиксирует факт нарушения регламента перемещения груза или его хранения, но и позволяет воспрепятствовать злоумышленным действиям по отношению к обрабатываемому грузу. Для унификации процедуры принятия решений предложен общий формат типовых шаблонов ситуации принятия решений, включающий следующие разделы: тип нестандартной ситуации; территориально-пространственные характеристики нестандартной ситуации; описание нестандартной ситуации; паспортные данные источников, из которых поступила информация о нестандартной ситуации; специфические параметры и характеристики нестандартной ситуации; фиксации отдельных стадий изменения нестандартной ситуации во времени; статистические данные по каждой нестандартной ситуации. Раскрыто и детализировано содержание каждого из перечисленных разделов. Приведен общий алгоритм процесса принятия решений в системе оказания услуг ГЛОНАСС по транспортной логистике, которая должна быть размещена в диспетчерском центре транспортной компании, оказывающей услуги по перевозке грузов. На основе анализа алгоритма сформирован перечень информационных технологий, которые целесообразно использовать в предложенной системе оказания услуг ГЛОНАСС.
Ключевые слова:
ГЛОНАСС, транспортная логистика, общий алгоритм, принятие решений, информационные технологии
ГЛОНАСС, транспортная логистика, общий алгоритм, принятие решений, информационные технологии
Введение В настоящее время спутниковая система навигации ГЛОНАСС активно используется в транспортной системе как частными лицами и организациями, так и в учреждениях государственного подчинения. Особенно важное место занимает спутниковая навигация в системе перевозки грузов, являясь одной из основ непрерывного контроля процесса перемещения и местонахождения груза. Однако существующая технология использования ГЛОНАСС в транспортной логистике не позволяет по существу активно воспрепятствовать злоумышленным действиям по отношению к перевозимому или хранимому грузу - она может лишь зафиксировать факт нарушения регламента перемещения груза или его хранения. В работах [1, 2] была предложена новая концепция использования навигационной системы ГЛОНАСС в транспортной логистике, позволяющая создать систему априорного реагирования на возможные угрозы по отношению к охраняемому грузу, мгновенно активизируя системы тревожной сигнализации и оповещения при возникновении потенциальной опасности для груза. В указанных работах была проведена системная классификация факторов, значимых для процесса обработки охраняемого груза, разработана концепция использования ГЛОНАСС для контроля всех перемещений в зоне этого груза. Следующим важным этапом реализации этой концепции [2] является разработка общей схемы принятия решений (функционирующей на основе концепции) в процесс управления в транспортной логистике с учетом всей совокупности факторов, значимых для процесса обработки охраняемого груза, что и явилось целью исследования. Отметим, что работ по управлению в транспортной логистике много (в частности, [3-5]). Однако процедуры принятия решений в них носят традиционный характер, что требует значительной модификации этих процедур в рамках поставленных в нашем исследовании задач. Структура подсистемы поддержки принятия решений Одним из наиболее важных компонентов системы оказания услуг ГЛОНАСС по транспортной логистике (назовем их УГТЛ) является подсистема, отвечающая за процесс реализации всех действий и мероприятий, необходимых для решения задач управления процессом обработки грузов. В рамках УГТЛ указанный процесс управления целесообразно представить как объединение двух видов управления: оперативного и стратегического. Эти виды управления разбиваются на отдельные этапы, следующие из которых являются для них общими: 1) сбор и подготовка исходных данных; формирование вариантов управленческих решений; выбор и принятие одного из вариантов; реализация выбранного варианта; контроль за процессом реализации, включая результат; анализ результатов реализации; при выявлении недопустимых или нежелательных отклонений - корректировка выбранных решений с последующим повторением описанного цикла управления. В цикле стратегического управления к перечисленным этапам добавляются еще два: начальный (второй по порядку) этап - прогнозирование параметров всех компонентов модели управления (компоненты, непосредственно связанные с перевозкой грузов, УГТЛ, внешнее окружение). Состав УГТЛ является разнородным, включающим как программно-аппаратные и технические средства (датчики разных типов, аппаратно-программные средства ГЛОНАСС, в том числе датчики легитимности сотрудников, и др.), так и субъектов (обслуживающий персонал, клиенты и др.) и субъектно-ориентированные средства, связанные с локальным сервером [2]. Именно поэтому процесс формирования управленческих решений и их реализации в УГТЛ достаточно сложен и включает в себя как различные подсистемы автоматического контроля и управления, так и подсистемы автоматизированного управления, которые предполагают непосредственное участие человека в процессе формирования и принятия решений (прежде всего, в нестандартных ситуациях) субъектом - лицом, принимающим решения (ЛПР). Поскольку возникновение нестандартных ситуаций типично при злоумышленных попытках проникновения к охраняемому грузу, то участие ЛПР в составе УГТЛ является необходимым условием эффективности ее функционирования. Для повышения эффективности управления в УГТЛ предлагает провести унификацию процедуры принятия решений на основе введения типовых шаблонов ситуации принятия решений и формирования базы знаний по нестандартным ситуациям. Указанный шаблон имеет фиксированную структуру, позволяющую дать достаточно полное описание любой нестандартной ситуации со степенью ее детализации, достаточной для формирования приемлемых вариантов решений в процессе управления. Для этого предлагается включить в структуру шаблона следующие данные по нестандартной ситуации (параметры нестандартной ситуации): 1. Тип нестандартной ситуации. Возможными значениями данного параметра нестандартной ситуации могут быть: 1.1. Авария технического характера (неработоспособно транспортное средство, перевозящее груз; авария на транспортном пути, по которому перевозится груз; обрушение или затопление в складском помещении, где хранится груз, и т. п.). 1.2. Стихийное бедствие или техногенная авария в зоне нахождения перевозимого груза (обрушение или затопление дорожного полотна; гололед; экстремальный для данного груза холод или экстремальная жара; наводнения, землетрясения, пожары и т. д.). 1.3. Отклонения от логистического плана по перевозке груза (по времени; по маршруту; по параметрам оперативного контроля; по параметрам сопровождения или обслуживания перевозимого груза и т. д.). 1.4. Нарушение установленного регламента обработки груза со стороны персонала, обслуживающего груз. 1.5. Нарушение регламента обработки груза лицами, не связанными с перевозкой груза, в том числе сотрудниками, не задействованными в процесс перевозки данного груза, руководством, посторонними лицами. 1.6. Конфликты или чрезвычайные происшествия в зоне обработки груза, в том числе с участием обслуживающего персонала. 1.7. Выход из строя или отказ в системе контроля и управления за перевозкой груза. Возможные значения (оценки) перечисленных параметров могут быть числовыми (получаются на основе экспертного оценивания) или лингвистическими (выбираются из списка возможных значений: локальная/малая/средняя/большая/аварийная). 2. Территориально-пространственные характеристики нестандартной ситуации. Возможными значениями параметра являются: 2.1. Территориальные координаты, в рамках которых возникла нестандартная ситуация (географические координаты и координаты по отношению к населенным пунктам, другим географическим объектам, официальный километраж на данной дороге). 2.2. Особенности места возникновения нестандартной ситуации (строения вокруг места происшествия, характер местности, погодные условия в момент происшествия). 3. Описание нестандартной ситуации. Значением третьего параметра является словесное описание ситуации в соответствии с заданным шаблоном, структура и содержание которого требуют дополнительного анализа. Наличие шаблона существенно облегчит формирование перечня возможных нестандартных ситуаций в УГТЛ, содержащего описание каждой нестандартной ситуации, которые уже возникали при перевозке охраняемых грузов или потенциально могут возникнуть. Каждая из нестандартных ситуаций, входящих в указанный перечень, должна иметь свой код и формулу, т. е. максимально краткое, но полное выверенное описание нестандартной ситуации. При возникновении нестандартной ситуации вначале система управления ищет сходную нестандартную ситуацию в перечне, затем, при нахождении подобной или близких ситуаций по базе знаний нестандартной ситуации, пытается найти или сформировать возможные варианты решений по ликвидации или преодолению нестандартной ситуации. Если данной нестандартной ситуации в перечне нет, то руководство УГТЛ должно включить новую нестандартную ситуацию в перечень, снабдив ее всеми необходимыми атрибутами. 4. Паспортные данные источника (источников), из которых поступила информация о возникновении нестандартной ситуации, а также для каждого источника время фиксации информации о нестандартной ситуации в УГТЛ и в системе управления транспортной компании. Необходимо также, наряду с установленным в системе идентификатором каждого источника, привести следующие данные: тип источника информации (датчик, сотрудник, постороннее лицо и др.), его местоположение по отношению к месту возникновения нестандартной ситуации, надежность источника. 5. Специфические параметры и характеристики нестандартной ситуации при наличии таковых либо фиксации нестандартной ситуации как типовой. Эти параметры индивидуальны для каждого типа нестандартной ситуации; например, при затоплении зоны нахождения груза нестандартная ситуация характеризуется уровнем и скоростью подъема воды, при пожаре - близостью огня к грузу, при несанкционированном приближении к грузу - количеством лиц, нарушающих регламент, и скоростью их приближения, а также их квалификацией, при отклонении отдельных показателей от плановых значений - процентами отклонения и т. д. 6. Фиксации отдельных стадий изменения нестандартной ситуации во времени. Данный показатель, в частности, включает параметры, характеризующие направление и скорость возможного изменения нестандартной ситуации, что актуально для принятия адекватных управленческих решений с учетом динамики нестандартной ситуации. 7. Статистические данные по каждой нестандартной ситуации при наличии сведений в базе данных по ее повторяемости, а также результаты анализа этих данных, в частности, по наличию тренда, временной и территориальной составляющей. Наличие статистических данных позволяет выявлять определенные закономерности применительно к рассматриваемой нестандартной ситуации и на этой основе формировать и принимать более эффективные решения. Отметим, что описанный выше шаблон может быть востребован также для описания нормальных ситуаций, когда нет никаких отклонений показателей от их плановых значений, в частности при запросе из УГТЛ по текущей ситуации. На основе описанной выше детализации возможных нестандартных ситуаций с использованием шаблонов может быть сформирован общий алгоритм процесса принятия решений в УГТЛ (рис.). В процессе формирования алгоритма были реализованы следующие два принципа управления. Первый принцип - непрерывность процесса принятия решений, т. е. готовность системы управления реагировать на возникновение нестандартной ситуации в любой момент времени и при любых внешних и других сопутствующих условиях процесса обработки охраняемого груза. Необходимость соблюдения данного принципа очевидна с точки зрения выполнения требований по сохранности и безопасности охраняемого груза. Второй принцип - это готовность к немедленному оперативному реагированию при возникновении нестандартных, и прежде всего чрезвычайных ситуаций. Данный принцип является естественным продолжением предыдущего, т. е. система управления должна быть готова не только сформировать требуемые решения по ликвидации нестандартной ситуации - эти решения предполагают необходимость немедленного реагирования на нестандартную ситуацию и реализацию оперативных действий. Непосредственно процесс управления в УГТЛ, представленный алгоритмом на рисунке, разбит на этапы, которые типичны для большинства систем организационного управления. Первый этап, сбор и подготовка данных, нацелен на формирование образа текущей ситуации (показатель 3 шаблона - описание ситуации) в соответствии с установленным шаблоном ситуации, описанным выше. При этом данные от датчиков (положения, перемещения, температуры и др.), а также от приемников ГЛОНАСС вначале поступают на локальный сервер и только после первичного анализа и обработки на локальном сервере передаются в диспетчерский центр. При этом диспетчерский центр получает независимо навигационные данные. При формировании образа ситуации может возникнуть необходимость получения дополнительной экспертной информации, например при оценке уровня подготовленности злоумышленников, для чего могут привлекаться в том числе и внешние специалисты. При заполнении шаблонов возникает также необходимость привлечения данных из ряда информационных баз данных - они перечислены на рисунке. Обратим внимание на блок 23 «Активизация системы по ЧС (чрезвычайным ситуациям)» - в случае, когда система управления не смогла справиться с возникшими проблемами, активизируется специальная технология действий в аварийных и чрезвычайных ситуациях. Ее разработка требует отдельного рассмотрения. При сборе и подготовке данных от датчиков используется микроконтроллер, прежде всего для унификации и подготовки всех данных, поступающих ото всех имеющихся источников данных. Микроконтроллер позволяет также контролировать состояние работоспособности каждого из источников (прежде всего, датчиков), выявлять на первичном уровне различные дефекты, противоречия, несоответствия и отклонения в данных, поступающих от разных датчиков, а также, отвечая на запросы из диспетчерского центра УГТЛ, давать полную информацию о текущем состоянии подконтрольных микроконтроллеру источников (в частности, датчиков). Общий алгоритм процесса принятия решений в УГТЛ: МК - микроконтроллер; БЗ - база знаний; БД - база данных Одним из основных является второй этап - формирование управляющих решений. В зависимости от ситуации предусмотрены следующие варианты формирования управляющих решений с учетом состава и содержания имеющихся и поступивших входных данных: 1) при наличии полного состава входных данных, характеризующих ситуацию принятия решений, используются различные алгоритмы поиска оптимальных решений; 2) при отсутствии всех или части требуемых входных данных либо отсутствии моделей, адекватных в должной мере текущей ситуации, но при наличии базы данных по прецедентам могут быть использованы методы искусственного интеллекта, опирающиеся на накопленный эмпирический опыт по ликвидации нестандартных ситуаций; 3) в случае отсутствия возможности формировать управленческие решения на основе двух предыдущих подходов могут быть использованы продукционные правила (при наличии базы продукционных правил); 4) в случае отсутствия возможности формировать управленческие решения на основе предыдущих подходов к формированию вариантов решений решение может быть принято непосредственно ЛПР с возможным привлечением экспертов. Отметим, что участие человека в процессе выработки решения обусловлено не только возможным отсутствием необходимых формализованных процедур формирования управляющих решений, но и необходимостью особого контроля при принятии ответственных решений (например, в чрезвычайных ситуациях), необходимостью срочных и значимых изменений в логистике процесса перевозки груза и др. Третий этап связан непосредственно с актом принятия определенного управленческого решения. При этом при использовании автоматизированных методов формирования решений, т. е. без участия человека (например, при выходе из строя одного из датчиков), акт принятия сводится к формированию поручений соответствующим работникам. Если же в процессе формирования и принятия решений участвует человек, то решение принимается ЛПР. Четвертый и пятый этапы, связанные реализацией решения и контроля исполнения, являются типовыми для любых систем организационного управления, и поэтому их детализация не приводится. Шестой этап предназначен для анализа результатов реализации принятого решения после завершения этапа контроля и анализа результатов реализации решения. Если принятое решение в результате его реализации позволило устранить отклонения процесса обработки груза от предписанного регламента и этот факт зафиксирован после проведения анализа, то процесс функционирования системы управления, в соответствии с принципом непрерывности, возвращается к началу для реализации очередного цикла процесса управления и принятия решений. Если же процесс функционирования УГТЛ не удалось возвратить в регламентный режим, то предпринимаются попытки по корректировке уже выработанных ранее решений с целью обеспечения большей адекватности решения реальной ситуации и, тем самым, повышения вероятности устранения нестандартной ситуации. При этом очевидно, что число попыток корректировки решения должно быть разумно ограничено (реализовано на седьмом этапе), поскольку, если многочисленные попытки по устранению нестандартной ситуации не привели к желаемому результату, то ситуация должна рассматриваться как чрезвычайная и должны приниматься чрезвычайные меры по устранению нестандартной ситуации. Таким образом, при отсутствии желаемого результата в изменении состояния системы после корректировки возникает необходимость перейти к более радикальным мерам и действиям, связанным с режимом чрезвычайной ситуации. Именно этот исход процесса принятия решений и составляет содержание восьмого этапа. Формирование алгоритма процесса принятия решений в условиях аварийной ситуации требует отдельного рассмотрения. Таким образом, общий алгоритм процесса принятия решений в УГТЛ описан. Его практическая реализации требует дальнейших исследований, поскольку почти все блоки представленного алгоритма имеют сложное содержание и построение алгоритмов их функционирования является отдельной задачей. Информационные технологии, используемые в составе УГТЛ Из общего алгоритма функционирования УГТЛ вытекает, что процедуры, связанные с управлением, весьма разнородны, и поэтому информационные технологии (ИТ), которые предназначены для поддержки и реализации этих процедур, охватывают широкий спектр различных программно-информационных средств. Общий алгоритм на рисунке позволяет исследовать востребованность ИТ в различных компонентах алгоритма и на этой основе выявить, какие из них и в каких компонентах общего алгоритма УГТЛ целесообразно использовать. Реализация очередного цикла управления начинается со сбора и регистрации данных, поступающих из различных внешних и внутренних источников: от датчиков (прежде всего, инфракрасных датчиков перемещения - как субъектов в зоне сохранности груза, так и самого груза; датчиков сохранности упаковки груза; погодных датчиков, датчиков легитимности персонала и др.), систем видеонаблюдения, интернет-источников из локального сервера и от персонала, журнала событий, а также из различных хранилищ документов и баз данных (по текущим ситуациям, нормативным и законодательным документам, по прошлым ситуациям и событиям, по зданию и др.). Использование микроконтроллера также требует использования определенных ИТ. Наконец, необходимы средства контроля корректности, полноты, непротиворечивости, достоверности и адекватности данных, поступающих от всех источников. Таким образом, на этапе сбора и подготовки исходных данных востребованы следующие типы ИТ, которые размещаются на локальном сервере: I. Информационные технологии поддержки процессов сбора, обработки и накопления данных от различных первичных датчиков в условиях непрерывного режима функционирования УГТЛ, которые имеют интерфейсы взаимодействия с микроконтроллеров. При этом прием данных с датчиков микроконтороллер и выдача команд на исполнительные устройства должны предполагать возможность использования как проводных, так и беспроводных технологий. В качества вариантов могут быть использованы ИТ на основе встраиваемых плат сбора данных со стандартным системным интерфейсом (наиболее распространен интерфейс PCI), такие как Cypress CY3654, CISC; ИТ на основе модулей сбора данных с внешним интерфейсом (RS-232, RS-485, USB) - COM Port Toolkit, Cypress CY3654; ИТна основе цифровых измерительных приборов (ЦИП) или интеллектуальных датчиков. Для поддержки функционирования последних можно использовать ИТ с интерфейсами: GPIB (IEEE-488), 1-wire, CAN,HART, такие как Hewlett-Packard, VEE 3.0, IAR EWB. II. Информационные технологии по поддержке систем видеонаблюдения; например программы SecurOS, WV-ASM200; для работы с сетевыми камерами - программы IP Camera Viewer, BB-HNP17 компании Parasonic; для анализа данных - программы WV-ASFE904, WJ-SRV920RU. III. Информационные технологии, обеспечивающие систематический поиск в соответствии с заданным регламентом данных в глобальных сетях, прежде всего в Интернет (например, программа СайтСпутник, Recuva). IV. Системы обработки, документирования данных и их хранения (например, Process Street, XaitPorter, Zoho Docs). V. Информационные системы контроля качественных характеристик данных разного типа (например, программа Master’s degree). Важным условием формирования состава ИТ в информационной системе сбора и подготовки данных является программно-аппаратная совместимость всех ИТ, что является необходимым условием их совместного и эффективного использования в рамках единой информационной системы. Второй этап технологии поддержки принятия решений (рис.) связан с функционированием диспетчерского центра транспортной компании. Имеется ряд ИТ, предназначенных для использования в процессе управления бизнесом; в частности, для этих целей могут быть задействованы SCADA-системы, предназначенные для поддержки функционирования систем диспетчерского управления и сбора данных, а также в процессе сбора и регистрации данных, поступающих от датчиков разных типов, и EAM-системы. Таким образом, предлагается использовать на втором этапе следующие ИТ: VI. EAM-системы. Информационные технологии, предназначенные для обеспечения управления основными фондами предприятия в рамках стратегии EAM (Enterprise Asset Management), которая представляет собой систематическую и скоординированную деятельность организации по оптимальному управлению физическими активами и режимами их работы, рисками и расходами на протяжении всего жизненного цикла для достижения и выполнения стратегических планов организации. ЕАМ-системы позволяют в организации системно контролировать и управлять следующими процессами: техническое обслуживание и ремонт; управление финансами, качество и трудовые ресурсы в части технического обслуживания, ремонтов и материально-технического обеспечения; управление складскими запасами (запчасти для технического обслуживания), материально-техническое снабжение. VII. SCADA-системы. Рынок SCADA является одним из самых быстрорастущих рынков систем контроля в мире. Согласно результатам исследования глобальной консалтинговой компании Frost&Sullivan «Стратегический анализ мирового рынка систем SCADA», в 2009 г. выручка этого рынка составила 4623,1 млн долл., а к 2016 г. она достигла 7074,1 млн долл. [6, 7]. Последующие этапы общей технологии функционирования системы поддержки принятия решений (рис.) могут быть реализованы на основе использования EAM- или SCADA-систем. Целесообразно использовать одновременно оба типа ИТ: SCADA-системы - для поддержки работы диспетчерского центра, включая сбор и подготовку данных, поступающих от датчиков, EAM-системы - для процессов, связанных с менеджментом. На восьмом этапе возникает задача выбора и использования ИТ в подсистеме регистрации аварийных ситуаций. Одним из наиболее важных отличий подсистемы регистрации аварийных ситуаций от компонентов, представленных на рисунке, являются жесткие требования ко времени выработки и принятия управленческого решения ввиду дефицита времени. В связи с этим в составе подсистемы регистрации аварийных ситуаций необходимо использовать ИТ, которые способны максимально быстро решать поставленные задачи - даже, возможно, в ущерб качеству решения. Указанное требование налагает особый отпечаток на ИТ в системах и подсистемах по аварийным ситуациям. Кроме того, имеются ограничения на сложность получаемых решений, поскольку в условиях дефицита времени проблемно реализовывать сложные варианты решений. Наконец, ИТ, используемые в составе подсистемы регистрации аварийных ситуаций, должны быть способны мобильно учитывать динамически происходящие изменения в текущей ситуации, практически мгновенно адаптируя процесс поиска решений к изменившимся условиям поиска. Все вышесказанное позволяет сделать вывод, что по своему базовому назначению ИТ, используемые в составе подсистемы регистрации аварийных ситуаций, аналогичны ИТ, используемым в других компонентах общей технологии функционирования подсистемы принятия решений, но достаточно серьезные специфические требования к ним выделяют их в качестве самостоятельного типа ИТ. Ключевым этапом процедуры поддержки принятия решений являются формирование и подготовка вариантов решений. Как видно из технологии принятия решений (рис.), для УГТЛ востребованы следующие методы формирования решений: 1. Методы, основанные на анализе формализованных моделей, включая оптимизационные методы. Эти методы необходимы прежде всего в функциональных подсистемах, связанных с инфраструктурными службами - выбор маршрутов перевозки, размещение грузов, их складирование, поскольку работа указанных служб может быть описана с помощью формализованных моделей. 2. Методы, основанные на использовании продукционных правил. Эти методы используются при решении тех задач, в которых нет возможности построить формализованные модели, в частности в подсистеме безопасности, надежности. 3. Методы искусственного интеллекта, основанные на поиске вариантов решений с использованием баз знаний, аккумулирующих теоретические и эмпирические знания, а также результаты анализа имеющегося опыта (своего и чужого) по решению рассматриваемой или близкой проблемы. Методы используются при возникновении новых ситуаций, которые ранее не возникали в процессе перевозки грузов. Эти методы могут быть востребованы также в подсистеме регистрации аварийных ситуаций. 4. Экспертные методы, основанные на использовании опыта и интуиции специалистов в рассматриваемой сфере, предполагают обязательное участие ЛПР в процессе формирования и выбора вариантов решений. Эти методы могут быть востребования в диспетчерском центре компании. Таким образом, для эффективной реализации системы поддержки принятия решений в УГТЛ целесообразно иметь ИТ, реализующие следующие методы поиска решений. VIII. Формализованные методы поиска оптимальных решений, адаптированные под задачи и условия функционирования УГТЛ, например SAM-Method, EMO-method. IX. Методы поиска решений, основанные на продукционных правилах. X. Информационные технологии, реализующие методы искусственного интеллекта, например программа SCADA Systems. XI. Информационные технологии принятия решений с участием ЛПР и экспертов. Укажем, что применительно к подсистеме регистрации аварийных ситуаций одним из наиболее известных программных продуктов является программная система Accident Alarm System (CAAS). Очевидно, что необходимо наличие общей программной среды, которая позволяла бы обеспечить рациональное использование перечисленных четырех классов методов поиска оптимальных решений в рамках единой системы. Одной из важных задач формирования системы поддержки принятия решений, описываемой схемой на рисунке, является создание среды для функционирования всех компонентов, ответственной за все информационные потоки в рамках системы поддержки принятия решений, за взаимодействие УГТЛ с локальным сервером и локального сервера с диспетчерским центром. Подобная ИТ должна представлять собой комплекс организационных, проектных, инженерно-технических, а также программных решений, способных обеспечить гибкое и эффективное решение всех необходимых задач, что позволяет отнести ее к автоматизированным системам. На основе вышесказанного заключаем, что в УГТЛ востребованы также: XII. Информационные технологии формирования автоматизированных систем управления в УГТЛ и диспетчерском центре транспортной компании как единой информационно-управляющей среды функционирования всех других ИТ. Таким образом, полноценная реализация ИТ в составе УГТЛ предполагает наличие ИТ из перечисленных выше 12 типов, объединенных в единую систему на основе общей информационно-управляющей среды. Выбор конкретного типа ИТ из перечисленных выше предполагает учет специфических требований и возможностей транспортной компании. Заключение Задача построения подсистемы поддержки принятия решений в системе транспортной логистики рассматривалась на основе новой концепции использования навигационных систем, сформулированной нами в предыдущих работах. Эта концепция, в отличие от существующих, не только фиксирует факт нарушения регламента перемещения груза или его хранения, но и позволяет воспрепятствовать злоумышленным действиям по отношению к обрабатываемому грузу. Для унификации процедуры принятия решений предложен общий формат типовых шаблонов ситуации принятия решений, включающий в себя следующие разделы: тип нестандартной ситуации; территориально-пространственные характеристики нестандартной ситуации; описание нестандартной ситуации; паспортные данные источников, от которых поступила информация о нестандартной ситуации; специфические параметры и характеристикинестандартной ситуации; фиксация отдельных стадий изменения нестандартной ситуации во времени; статистические данные по каждой нестандартной ситуации. Раскрыто и детализировано содержание каждого из перечисленных разделов. Приведен общий алгоритм процесса принятия решений в системе оказания услуг ГЛОНАСС по транспортной логистике, которая должна быть размещена в диспетчерском центре транспортной компании, оказывающей услуги по перевозке грузов. На основе анализа приведенного алгоритма сформирован перечень информационных технологий, которые целесообразно использовать в указанной системе оказания услуг ГЛОНАСС. На следующем этапе исследований, в продолжение данной работы, необходимо сформировать процедуру и общий алгоритм функционирования подсистемы по чрезвычайным ситуациям. Полученные результаты являются основой для формирования программно-аппаратной системы оказания услуг ГЛОНАСС по транспортной логистике, на основе предложенной нами концепции.
1. Пашаев М. Я., Минцаев М. Ш. Формирование состава показателей эффективности процесса оказания услуг ГЛОНАСС по транспортной логистике // Вестн. Астрахан. гос. техн. ун-та. 2016. № 4. С. 19-28.
2. Пашаев М. Я., Минцаев М. Ш. Концепция построения системы контроля за процессом оказания услуг ГЛОНАСС по транспортной логистике // Науч.-техн. вестн. Поволжья. 2017. № 1. C. 91-99.
3. Вордлоу Д. Л., Вуд Д. Ф., Джонсон Дж., Поль Р. Мерфи-мл. Современная логистика. М.: Изд. дом «Вильямс», 2005. 624 с.
4. Кристофер М. Логистика и управление цепочками поставок. СПб.: Питер, 2004. 316 с.
5. Афонин А. М., Афонина В. Е., Петрова A. M., Царегородцев Ю. Н. Транспортная логистика: организация перевозки грузов. М.: Форум; Инфра-М, 2014. 368 с.
6. Remenyi D., Sherwood-Smith M. Achieving Maximum Value from Information Systems. JohnWiley, New York, 1997. 278 p.
7. Gerasimos G. Rigatos. Modelling and Control for Intelligent Industrial Systems. Springer-Verlag Berlin, Heidelberg, 2011. 409 p.
