Назад в библиотеку

Переход к интеграции 3 уровня

Авторы: Chris McElman, Sergey Seroukhov
Перевод: А.С.Бакшевникова
Источник: McElman, C. From Buttons to Bits — Achieving Level 3 Integration. / C. McElman, S. Seroukhov // Paper 4383, APCOM 2009 conference, Vancouver BC, Oct. 2009.

Аннотация

Системы управления реального времени в горном деле с течением времени прошли развитие от закрытых, проприетарных решений к "системам систем", включающим в себя широкое разнообразие имеющихся в наличии (готовых) компонентов и технологий. Modular Mining Systems перешла на открытые стандарты в своих продуктах линии NextGen, чтобы закрыть пробелы технологии в этих системах. Однако необходимо также преодолеть оставшиеся логические пробелы, чтобы достичь полной интеграции между отдельными системами.

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

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

Введение

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

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

Рисунок 1. Комплексная схема взаимосвязей между управляющими системами и заинтересованными лицами в горном деле.

С 1979 Modular Mining Systems Inc. ведёт работу в шахтной промышленности с более 150 установленными системами на нескольких крупнейших горных производствах мира. Изначально технические требования к этим системам не могли быть удовлетворены имеющимися готовыми технологиями. Системы Dispath производства Modular изначально использовали проприетарные технологии для многих системных компонентов. Эти компоненты, начиная от протоколов передачи данных и БД и заканчивая сценариями и отчётами, были затем переписаны с нуля. Созданная Modular линейка продуктов NextGen свидетельствует об отказе от проприетарных технологий на множестве различных уровней.

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

Постановка проблемы

Несколько ведущих компаний в области горного дела опубликовали своё видение будущего как цифрового, то есть полностью автоматизированного шахтного производства (Albanese, 2008 & Orellana 2007). Количество заинтересованных лиц, компонентов и зависимостей велико. Стоимость традиционных методов интеграции увеличивается экспоненциально с ростом объёма и разнообразия систем. Более важно, что иногда необходима интеграция систе, которые были спроектированы на различных принципах, с фокусом на разных целях. Когда системные компоненты концептуально не увязаны, естественная интеграция не может быть достигнута никакими средствами. Такая задача должна быть решена путём создания системы систем, полностью автоматизирующей шахтное производство.

Анализ проблемы

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

Таблица 1. Примеры технологических пробелов и их решений на текущий момент

Технологические пробелы Решения
Несовместимое аппаратное обеспечение Медиа-преобразователи, стандартизация аппаратного обеспечения
Множество форматов аутентификации LDAP, Active Directory
Несовместимые коммуникационные протоколы Веб-сервисы, CORBA
Несовместимые форматы данных Middleware, сервис-ориентированная архитекрура, XML-преобразования
Разные интерфейсы пользователей Mashup-технологии
Распределённые источники данных Хранилища данных

Продукты линейки NextGen компании Modular объединяют много стандартизированных, готовых аппаратных и программных компонентов для минимизации технологических пробелов при интеграции. Все серверные, десктопные и мобильные приложения NextGen были перенесены на ОС Microsoft Windows с использованием реляционной БД SQL Server. Сейчас Modular использует стандартные технологии Microsoft для аутентификации (Windows Integrated Security), отчётности (SQL Server Reporting Services) и передачи данных (SQL Server Integration Services). Вместо разработки проприетарного веб-портала используется технология Sharepoint Sevices. Все эти технологии максимизируют совместимость и лёгкость взаимосвязи между системами управления реального времени и общего планирования горных работ, распределения ресурсов и управления обслуживанием.

Пробелы технологий были закрыты с помощью существующих инструментов и методологий. Для большей части задач эти вопросы больше не являются проблемой. Тем не менее, simple connectivity не гарантирует естественной интеграции. Остаётся проблема логических пробелов и концептуальной разобщённости. Обеспечение высокоуровневой интеграции требует увеличения стоимости и сложности (Paige & Inbar, 2008). Таблица 2 описывает примеры логических пробелов и ограничения существующих решений в области интеграции для ликвидации этих пробелов.

Таблица 2. Логические пробелы и недостатки существующих решений

Логические пробелы/концептуальная рассозгасованность Недостатки существующих решений
Структурная несогласованность Преобразование форматов возможно с помощью онтологических моделей, но только в случае совместимости понятий?
Неполная информация Сложность в обнаружении и объединении информации из многих систем, если одного источника не достаточно. Простые бизнес-транзакции требуют сбора информации из множества источников. Данные о производстве не содержат сведений об исходных решениях. Это ограничивает возможность понять, почему произошли конкретные изменения.
Дублирующаяся информация Многочисленные параллельные копии информации могут нарушить целостность данных. Сложности в согласовании множества источников данных для промежуточного ПО.
Различные уровни гранулярности Если информация уже была агрегирована, может оказаться невозможной её декомпозиция до более детального уровня.

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

Рисунок 2. Три уровня интеграции

Уровень 1: Закрытые системы, несовместимые технологии, разнообразные объединяющие «мосты» и специальные технологии для интеграции. Проблема: как передавать информацию?

Уровень 2: Системы с открытыми интерфейсами, высокий уровень стандартизации, использование специального промежуточного ПО (Enterprise Application Integration Middleware). Проблема: какую информацию куда передавать? Как обеспечить её актуальность, полноту, достоверность?

Уровень 3: Системы, использующие совместимые технологи. Принципы их проектирования и коммуникационные протоколы соединены таким образом, чтобы исключить пробелы и компоненты естественно дополняют друг друга.

При наличии достаточного количества времени и ресурсов проблемы в технологии более не являются проблемой. Большинство предприятий на данном этапе находятся в процессе перехода с уровня 1 на уровень 2. Но некоторые мечтатели из Rio Tinto и Codelco высказали идеи о «цифровых шахтах» с автоматической обработкой и цифровыми потоками информации, способными действовать с минимальным вовлечением человека. Реализация такой идеи требует самого высокого уровня интеграции – уровня 3.

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

Традиционно проблема интеграции рассматривалась через призму бизнес-процессов, требующих автоматизации. Техники моделирования бизнес-процессов, как IDEF0, Flow Chart, Business Process Definition Language, используются различным промежуточным ПО отражают эту тенденцию (Harmon, 2003).

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

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

Без инноваций, быстроты и решительности невозможно одержать победу над гибким, непредсказуемым противником. Став перед вопросом «как эффективно управлять военными операциями?», вооружённые силы по всему миру вложили миллионы долларов в исследования с целью определить научные принципы построения эффективных систем управления такого масштаба, сложности и быстроты (Atkinson, 2005). Сегодня боевые системы командования и контроля, представляющие собой целую цепочку звеньев командования от стратегического планирования операций, тактического уровня до командования индивидуально солдатами сейчас уже стало реальностью. Эти системы работают, соединяя все элементы в общее информационное пространство в реальном времени (Wilson, 2004).

Военная сфера посвятила значительные исследовательские усилия определению и управлению изменчивыми средами согласно научным принципам (Albert & Hayes, 2006). Эти подходы могут быть использованы и в горном деле. Моделируя действия с помощью принципов command-and-control вместо жёстких бизнес-процессов и используя эти модели для интеграции бизнес-систем, можно достигнуть более гибкой интеграции. Эти модели фокусируются не на повторяемости процессов, а на распространении решений, команд.

Решение

В процессе поиска лучших путей согласования систем управления реального времени стало очевидно, что военные принципы command & control (C2) могут быть изменены и расширены для применения в промышленности. Этот набор принципов описан как “Industrial Command and Control” с целью отделить его от первоначального источника.

Итак, каков новый подход к управлению в реальном времени? Согласно принципам С2, независимо от целей бизнес-процесса управленческая деятельность постоянно проходит через цикл: 1) наблюдение — решающий элемент должен наблюдать за происходящим; 2) ориентирование — необходим анализ ситуации и решение, соответствующее целям; 3) решение — создание и утверждение плана для достижения поставленных целей в текущих условиях; 4) действие — исполнение плана.

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

Этот НОРД-цикл в С2 называется OODA Loop (Richards, 2001). Когда НОРД-цикл выполняется решающими элементами, информационные входы и выходы могут быть разделены на категории, изображенные на рисунке 3:

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

Рисунок 3. Входы и выходы НОРД-цикла и решающая сеть

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

Рисунок 4. Композиция систем управления реального времени, основанная на решающей сети

Для достижения полной автоматизации цикла управления концептуально полная С2 система должна включать 5 ключевых функциональных групп: 1) общая операционная картина для наблюдения за происходящим; 2) планирование и анализ для анализа ситуации и более эффективной постановки целей; 3) принятие решений для помощи в принятии решений по наиболее эффективному достижению целей; 4) управление ресурсами для сообщения решения исполняющим ресурсам; 5) коммуникация и объединение – основа, поддерживающая все остальные функции.

Рисунок 5 показывает, как эти функции накладываются на НОРД-цикл.

Рисунок 5. Пять ключевых функциональных элементов С2-системы

Общая операционная картина в этом случае может состоять из электронной карты, показывающей особенности ландшафта, сеть дорог для перевозки, оборудование и материалы для добычи. Ключевой инструмент планирования может включать графический интерфейс пользователя с отображением линий времени, позволяющий располагать ресурсы по задачам с помощью drag-and-drop. Интерфейс управления ресурсами, обеспечивающий логистическое представление, может служить для отображения исполнения задач, обеспечивая также обновление общей операционной картины. Инструменты поддержки принятия решений, как, например, оптимизация задач перевозки, могут обеспечить помощь в принятии решений по оптимальному распределению ресурсов. Наконец, инструменты объединения, как текстовый или видеочат, сделали бы возможной координацию и обратную связь в реальном времени независимо от расстояния между частями системы.

Поскoльку данные были специфицированы, стала возможной стандартизация фкоммункационных форматов. Военный С2 включает концепцию основанного на XML языка управления боем (Battle Management Language, BML), который используется военными офицерами для отдачи приказов и получения обратной связи в формализованном виде. BML может передавать приказы в чёткой, полной, однозначной форме 5W (Who, What, Where, When, Why) любому подразделению, симулятору и даже роботу. Это только один пример возможной стандартизации. Логичным шагом была бы попытка использовать подобный подход для различных эскалаций и делегирования в горном деле. В будущем мы, возможно, увидим стандартные протоколы для отправки эскалаций и метрик исполнения и распределения ситуационной информации. Наглядный пример, описывающий типичный информационный поток и решающую сеть, включающую планировщика выпуска продукции, диспетчера и водителя грузовика, описана в таблице 3.

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

Действующее лицо: планировщик выпускаДействующее лицо: диспетчер Действующее лицо: водитель грузовика
Входы
Ситуационная информация Доступность оборудования, материальных запасов, расписание ремонтов и обслуживающих работ. Погода, видимость, трафик, свободный персонал, доступность оборудования и производительность. Погода, видимость, состояние оборудования, запас топлива, состояние шин.
Ресурсы 12х830Е грузовики, 3х4100 экскаваторы. 10 свободных грузовиков, 2 свободных экскаватора. Грузовик 101.
Цель Кто: 830E грузовик
Что: извлечь 25,000 тонн отходов из восточного карьера
Когда: за период с 1 по 15 января
Где: с восточного карьера на западную свалку
Зачем: цели по производству на июнь.
Кто: диспетчер
Что: вывезти мусор
Когда: с 7:00 до 19:00
Где: С платформ 1, 2 на свалку 6
Зачем: краткосрочный план по производству.
Кто: грузовик 101
Что: ехать к карьеру 201
Когда: 7:20
Где: платформа 1, перевозка на свалку 6
Зачем: выполнить утренний план по производству.
Внутренняя обработка
Наблюдение - объёмы руды и мусора;
- планы по бурению и подрывам породы;
- отчёты по производительности.
- карта шахты;
- граф перевозок;
- отчёты по производительности.
- бортовая карта;
- запас топлива;
- препятствия на дороге.
Ориентирование - приоритеты по перевозкам материалов;
- производительность экскаваторов;
- расписание перевозок и трафика;
- доступность грузовиков.
- число свободных грузовиков;
- число свободных экскаваторов;
- производительность экскаваторов;
- расстояния перевозок;
- запасы топлива.
- дорога East Pit Rim road к карьеру 201;
- дорога закрыта в связи с подрывными работами;
- необходим альтернативный маршрут.
Решение Создать план. Список задач для грузовика. Подтвердить задачу.
Действие Передать краткосрочный план системе диспетчеризации. Передать задачи водителям грузовиков. Ехать к карьеру 201 по альтернативному маршруту.
Выходы Обеспечить запланированную перевозку руды/мусора. Руда/мусор перевезены. Состояние оборудования, расхождения между ожидаемыми и фактическими временем перевозки, расстояниями, маршрутами. Вести грузовик от платформы 1 к свалке 6.
Статус - вывоз мусора соответствует плану;
- производство руды ниже планируемого;
- добыча руды выше планируемой.
- фактические к требуемым грузовики: 10/8;
- текущий статус всего оборудования;
- материалы перевезены на свалку 6;
- текущее местоположение оборудования.
- грузовик 101 готов;
- дорога к платформе 1 перекрыта.
Эскалации Нет Нет От водителя к диспетчеру.
Что: дорога закрыта
Почему: подрывы с 6:00 до 8:00

Выводы

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

Применение компанией Modular принципов command-and-control при разработке линии продуктов NextGen обеспечит наличие в каждом решающем элементе технологический и средств для поддержки каждой из пяти функциональных групп С2. Этот подход упростит интеграцию созданных Modular систем управления в систему систем, необходимую для полной автоматизации работы шахты.

Ссылки

  1. 1. ALBANESE, T. (2008). Rio Tinto chief executive unveils vision for 'mine of the future'. Retrieved June 17 2009, from http://www.riotinto.com/media/5157 7037.asp
  2. 2. ALBERTS, D.S. & HAYES, R.E. (2006). Understanding Command and Control, Retrieved June 17 2009, from http://www.dodccrp.org/files/Alberts UC2.pdf.
  3. 3. ATKINSON, S R. (2005). The Agile Organization. Retrieved June 17 2009, from http://www.dodccrp.org/files/Atkinson Agile.pdf.
  4. 4. BOYD, J.R. (1987), Organic Design for Command and Control. Retrieved June 17 2009, from http://www.d-n-i.net/boyd/pdf/c&c.pdf.
  5. 5. Enterprise Application Integration. Retrieved June 17 2009, from http://en.wikipedia.org/wiki/Enterprise application integration.
  6. 6. HARMON, P. (2003). Business Process Change, Morgan Kaufmann, San Francisco, California, USA. 529p.
  7. 7. IDEF0 Function Modelling Method. Retrieved June 17 2009, from http ://www.idef.com/idef0.html.
  8. 8. OODA Explained. (2006) Retrieved June 17 2009, from http://www.d-n- i.net/boyd/boyds ooda loop.ppt.
  9. 9. ORELLANA, M. (2007). Digital Codelco: Codelco's Strategy in the Use of Information & Communication Technology & Automation. Retrieved June 17 2009, from http://downloads.gecamin.cl/cierre_eventos/apcom2007/prsntcns/00048_00263_pr.pdf.
  10. 10. PAIGE, R., INBAR, D. (2008). Reality Check: The Costs of Data and Application Integration. Retrieved June 17 2009, from http ://www.information- management.com/infodirect/2008 99/10002234-1.html.
  11. 11. RICHARDS, C.W. (2001). A Swift,Elusive Sword. Retrieved June 17 2009, from http://www.d- n-i.net/richards/sword 4 boyd.pdf.
  12. 12. SCHADE, U. and HIEB, M.R. (2006). Formalizing Battle Management Language: A Grammar for Specifying Orders. Paper 06S-SIW-068, Spring Simulation Interoperability Workshop, Huntsville, Alabama, April 2006a.
  13. 13. WILSON, C. (2004). Network Centric Warfare: Background and Oversight for Congress. p. 15 Retrieved June 18 2009, from http://www.globalsecurity.org/military/library/report/crs/33858.pdf.