CC BY
67
ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ
УДК 621.436.038.6 Л. В. Тузов,
д-р техн. наук, профессор, СПГУВК;
С. В. Райтузов,
аспирант,
СПГУВК;
А. Б. Шадрин,
д-р техн. наук, профессор, ФГБОУ ВПО «Национальный минерально-сырьевой
университет (Горный)»
ЭЛЕМЕНТЫ ВИРТУАЛИЗАЦИИ СЕРВИСОВ В ПРОЦЕССАХ АВТОМАТИЗАЦИИ
И КОНТРОЛЯ НА ТРАНСПОРТЕ
ELEMENTS OF SERVICES VIRTUALIZATION IN THE PROCESSES OF AUTOMATION AND CONTROL IN TRANSPORT
Выполнен анализ и приведены элементы интеллектуализации сервисов для автоматизации и контроля динамических процессов на транспорте.
The article undertakes analysis and introduces elements of intellectualization of services for automation and controlling of dynamic processes in transport.
Kmючевые слова: методологические основы автоматизации процесса, инновационное развитие транспорта, интеллектуальная система, база знаний: вопросы государственного масштаба.
Key words: methodological background ofprocess automation, innovative development of transport, intellectual system, intelligent database: issue of national importance.
ЫДЕЛЕНЫ современные технологии интеллектуализации сервисов для образовательных технологий на уровне выпускающих кафедр с учетом успехов виртуализации машин (VM) и серверов (VS) на процессорах x86 до уровня интеллектуальных транспортных комплексов (ITC). В рамках «Виртуализации 2.0» созданы: Virtual Desktop Infrastructure (VDI) и Desktop as a Service (DaaS) — Рабочий стол как услуга. В VDI реализовано на новом уровне получение удаленного доступа к «личной» VM, сотни которых «консолидированы» на VS. В плане внедрения VDI лидируют компании: “Citrix” (48 %) и “VMware” (36 %). C 2010 г. в ITC уже используют технологии: «Облачных вычислений», « Облаков» и «X»aaS (X реализует услуги: PaaS, IaaS и т. д.). Например, Software as a Service (SaaS) предполагает не лицензирование и покупку, а временную аренду сложного программного комплекса. Технология Desktop as a Service (DaaS) реализует аренду удаленного доступа к VM внутри «фермы» VS ко всем сервисам сложных программных технологий. Соединения пользователей с VM проходят через «Брокер соединений», который служит единой точкой входа, с одной стороны, а с другой — проверяет «Учетные записи» и перенаправляет пользователей на определенную VM [1-7].
В инфраструктуре VDI реализованы три сценария работы с VM.
Individual. Конкретному логину сопоставляется конкретная VM. Пользователь попадает на «свою» выделенную VM.
Persistent Pool. Аналогично предыдущему, но VM создаются «на лету» по шаблону, с необходимым программным обеспечением. Соответствие между VM и пользователем запоминается и
Выпуск 3
Выпуск 3
все данные сохраняются между сеансами. Это позволяет уменьшить затраты на администрирование отдельных VM, как в Individual.
Non-Persistent Pool. Выглядит как предыдущий сценарий, но изменения на VM не сохраняются и после окончания сессии уничтожаются. VM поступает в «Пул свободных». При повторном входе пользователя опять предоставляется «чистая» VM. Все изменения сохраняются на локальных носителях у всех клиентов VDI.
Для целей сетевого обучения сервисам ITC на уровне серверов университета и кафедр выбираем сценарий Non-Persistent Pool, позволяющий в многоцелевом процессе обучения не засорять VM «последствиями экспериментов». Преимущества VM: 1) VM физически находятся в VS и позволяют решать вопросы: надежности, электропитания, защиты от посторонних, резервирования сетевых соединений, хранения и восстановления резервных копий (корпоративные VS должны иметь такие возможности); 2) возможность удаленной работы с VM в любое время и из любого места, в том числе через Интернет; 3) ускорение внедрения мобильных устройств: Android, Apple iPad или c Windows Mobile; 4) конфигурация VM соответствует корпоративным или учебным требованиям. Отметим, что стоимость VS сравнялась со стоимостью компьютерных классов. Если затраты на установку для VS выше, то стоимость обслуживания и владения — ниже. Коэффициент консолидации может достигать до 30-50 VM на VS, а для современных VS с десятками ядер и гигабайтами памяти — до 100-200 на VS.
Недостатки виртуализации: высокие начальные инвестиции в серверное оборудование, сетевую инфраструктуру и системы хранения данных с учетом программного обеспечения. Количество лицензий Windows удваивается, поскольку необходимо иметь лицензионную копию как на VM, так и на рабочем месте пользователя. Трудности работы с мультимедийным контентом (просмотр видео) на VM. Зависимость от сетевой инфраструктуры. Если внутреннюю корпоративную сеть можно продублировать, то остается зависимость от провайдера. Влияние интернет-технологий — одновременная загрузка: по утрам, когда сотни и тысячи пользователей одновременно загружают свои VM, то задержки доступа к VS могут достигать недопустимых величин.
Надо отметить другое решение — Теминальный сервер (TS) для сетей, дополненных X-Window. Для Windows известны решения Citrix Metaframe и Microsoft Terminal Server. Для пользователя нет разницы — VDI или TS похожи, но при использовании TS изоляция между пользователями намного ниже. Один пользователь может создать значительную нагрузку на систему и мешать другим. Администрирование TS имеет свои особенности — надо тщательно подбирать программное обеспечение, которое необходимо пользователям, но не конфликтует с терминальным окружением. Программы Microsoft, как правило, интегрируются в терминальное окружение, но программы других поставщиков могут создавать проблемы и требуют тщательной установки. Любые изменения на Терминальном сервере касаются всех пользователей одновременно. Поэтому эксперименты над программным обеспечением на Терминальном сервере довольно опасны и могут иметь катастрофические последствия.
В VM можно даже дать права администратора пользователю и разрешить установку нового программного обеспечения, а при необходимости восстановить VM из резервной копии. Поэтому VM и VS важно внедрять на уровне выпускающих кафедр для совершенствования доступа к современным образовательным технологиям для ITC.
Xen — технология виртуализации с упрощением требований к аппаратным ограничениям: “creating a world in which XenoServer execution platforms are scattered across the globe and available for any member of the public” — мир, в котором XenoServer разбросаны по всему миру и доступны для любого члена общества.
Xen интегрируется в «Облачные вычисления», позволяя управлять, передавать и таким образом продавать созданные «узлы». Важно, что Xen расширяет возможности развития новых технологий на уровнях администрирования и приложений в сетях. Xen позволяет одной VM (домен) вести себя так, как если бы было много VM. Каждый из этих доменов может запускать собственную операционную систему и существовать почти независимо от других доменов, работающих
на том же сетевом оборудовании. Каждая VM имеет собственный сетевой интерфейс, диски и память.
Отметим, что Xen отличается от эмуляторов VMware, Microsoft Virtual PC или с открытым исходным кодом QEMU. Работа эмулятора — запуск программы на процессоре моделирования, то есть со стороны приложения происходит замедление работы.
Xen реализуется непосредственно на процессоре на полной скорости, и лишь очень небольшие ресурсы Xen выделяет для управления. Поэтому Xen работает быстрее по сравнению с традиционными эмуляторами. Xen обеспечивает надежную изоляцию от сбоев, то есть любой сбой программного обеспечения на одной VM вряд ли повлияет на VS или другие VM. Это делает его полезным, особенно в условиях, когда нет уверенности в намерениях или уровне квалификации слушателей или студентов.
Xen обеспечивает дополнительный уровень абстракции между VM, пользователем и администратором VS. Учитывая повышенную гибкость, приложение может быть отделено от аппаратной части, полностью остановлено, запущено или перемещено. Основной недостаток Xen — работает только с операционными системами, которые были специально изменены, чтобы поддерживать его. Но запуск гостевых ОС возможен на достаточно современном оборудовании. Xen требует больше работы и навыков для установки и запуска VM по сравнению с чистым эмулятором программного обеспечения. Xen требует от пользователя освоения способа работы в гостевом домене, а не просто обычного запуска и работ с программами внешней эмуляции. Xen находится в стадии активного развития, но большая часть документации существует вне времени. В больших «серверных фермах», где каждый узел уже масштабируется до своих рабочих мест, Xen не то, что нужно, хотя разработчики (в том числе свободного программного обеспечения) работают даже на таких функциях для сред.
Отметим, что многие компьютеры даже с современной многозадачной операционной системой могут выполнять только одну инструкцию за один раз. Компьютер переключается между различными задачами так быстро, что задержки становятся незаметными. Виртуализация реализуется под руководством мультиплексированой операционной системы, которая работает над контролем задач и убеждается, что каждая получает свою долю процессорного времени. Операционная система должна планировать задания для запуска задач. С виртуализацией в Xen происходит тот же процесс, но место задач занимают операционные системы. Аспекты планирования обрабатываются ядром Xen, который работает на уровне выше гостевых операционных систем и называется гипервизором.
Посмотрим на то, как традиционно происходит процесс виртуализации и как это реализовано в Xen. Традиционная VM предназначена для имитации реальной машины во всех отношениях, она полностью перехватывает попытки доступа к аппаратным частям и производит их эмуляцию, при этом сохраняя функциональности программного обеспечения, реализуя полную совместимость с приложениями в VM. Это происходит на уровне VM, что делает ее работу заметно медленнее. Xen «обходит замедление» при помощи подхода, называемого паравиртуализацией (пара — аналогичные или близкие). Это не «настоящая» виртуализация, поскольку нет попыток обеспечить полную иллюзию VM. Xen представляет лишь частичную «абстракцию аппаратного обеспечения» на размещение операционной системы, подвергая некоторые аспекты VM — «ограничения на гостевых ОС» (которые необходимо знать), VM работает на Xen, и VM должны действовать соответствующим образом при взаимодействиях с определенным оборудованием в VS.
Большинство из этих ограничений, по определению, не заметны для пользователей VS. Для запуска под Xen ядро гостевой ОС должно быть модифицировано, например ОС должна спрашивать у Xen о выделении памяти, а не брать ее напрямую. Одна из целей проекта Xen состояла в том, чтобы эти изменения происходили в аппаратно зависимых битах гостевой операционной системы, не изменяя интерфейс между ядром и программным обеспечением на уровне пользователя VM. Эта цель проекта по уменьшению трудности перехода на Xen гарантирует, что существующие двоичные файлы будут работать не измененными на Xen ОС и что VM в большинстве случаев
[lQ9
Выпуск 3
Выпуск 3
будет действовать точно так же, как реальная машина, по крайней мере с точки зрения конечных пользователей. Поэтому Xen обменивает «виртуализацию без шва» на высокоэффективную «па-равиртуализированную среду». Следует отметить цель таких работ — “Paravirtualization is necessary to attain high performance and strong resource isolation on uncooperative machine architectures such as x86” (Паравиртуализация необходима, чтобы достигнуть высокой производительности и сильной изоляции ресурсов на несовместной машинной архитектуре, такой как x86). Паравиртуализация не единственный способ для запуска VM. Отметим два конкурирующих подхода: полная виртуализация и виртуализация на уровне ОС.
В данный момент существуют три вида технологий виртуализации. Первая из них — полная виртуализация или эмуляция, в котором виртуальная машина представляет собой программное моделирование аппаратных средств, реальных или вымышленных. Продукты этой категории — VMware и QEMU.
С полной виртуализацией не измененная ОС «размещает» программу пользователя, которая эмулирует машину, на которой работает «гостевая» ОС. Это — популярный подход, потому что он не требует изменения гостевой ОС. У этого подхода является преимуществом то, что виртуализированная архитектура может абсолютно отличаться от архитектуры узла, например QEMU может моделировать процессор MIPS на узле IA-32 и потрясающем массиве других микросхем.
Однако этот уровень аппаратной независимости получается за счет огромного ограничения производительности и скорости. Неускоренный QEMU на порядок медленнее, чем собственное выполнение ОС, а ускоренный QEMU или VMware ESX сервер может ускорить эмулированную машину, если это та же самая архитектура, как и на используемом оборудовании. В этом контексте для нормального использования увеличенная аппаратная универсальность полного эмулятора — несущественное преимущество перед паравиртуализацией.
VMware является известным поставщиком продуктов полной виртуализации, с устойчивым набором инструментов и широкой поддержкой. Недавние версии VMware рассматривали проблему скорости рабочими инструкциями на ходу и динамически преобразовывали код, когда это было необходимо. Хотя этот подход изящен и не требует модификации гостевой ОС, это не дает высокого прироста скорости.
Второй путь — виртуализация на уровне ОС, где то, что виртуализируется, является операционной средой, а не полной машиной. FreeBSD и Контейнеры — пример таких подходов. Виртуализация ОС занимает позицию, которую операционная система уже обеспечивает или, по крайней мере, может обеспечить; достаточная изоляция, чтобы сделать все, что нормальный пользователь VM ожидает — программное обеспечение устанавливается в масштабе всей системы, системные библиотеки модернизируются в госте, не влияя на те, что в узле, и т. д. Таким образом, вместо того, чтобы эмулировать физические аппаратные средства, виртуализация ОС эмулирует полное пространство пользователя ОС, используя средства операционной системы.
FreeBSD и Контейнеры Соляриса — «зоны», являются двумя популярными реализациями виртуализации на уровне ОС. Оба получают из классического Unix chroot зону. Идея состоит в том, что заключенный в зону процесс может получить доступ только к частям файловой системы, которые находятся в соответствующем конкретно определенном каталоге, остальная часть файловой системы, насколько процесс может увидеть, просто не существует. Если установим ОС в каталог, то получаем полную виртуальную среду. Для улучшения изоляции между виртуальными машинами ограничиваются определенные системные вызовы и обеспечиваются виртуальные сетевые интерфейсы. Эти действия приносят большую пользу в деле обеспечения изоляции, но это не есть на столь же полезно или столь же универсально, как если бы это была законченная VM. Поскольку зоны совместно используют ядро, например, паника ядра переведет всю «ферму», находящуюся на одном аппаратном средстве, в нерабочее состояние. Однако, потому что они обходят издержки виртуализации аппаратных средств, виртуализированные машины могут работать с такой же скоростью, как собственное выполнение.
Виртуализации на уровне ОС и Xen дополняют друг друга, каждый подход является полезным в различных ситуациях, возможно даже их одновременное исполнение. Например, можно выделить пользователю единственный Xen VW, который он, в свою очередь, может поделить на многократные «зоны» и использовать по собственному усмотрению.
Отметим элементы интеллектуализации процессов управления на уровне баз данных и знаний в плане: поиска верных стратегий решений для моделей представлений знаний и интеграции функций в машине вывода на ряде уровней совершенствования элементов баз — объектов, контекстных описателей, функционалов от экспертов и администраторов для синтеза формализованных модулей процессов через менеджеров интегрированных проектов.
Требования международных стандартов EN50155, EN50121, NEMA TS2, E-Mark диктуют ускорение развития интерсервисов для интеграции процессов систем управления дорожным движением и управления транспортом.
Отметим сетевые элементы автоматизации процессов на уровне гранулированной техники: видеонаблюдения и передачи по сети голосовых сообщений с питанием от Ethernet (voice overIP, PoE); коммуникационных (Ethernet/IP, Gigabit Turbo Ring, Ring Coupling, Turbo Ring) и комбинированных (Wi-Fi и Turbo Roaming) сетей с безвентиляторными Industrial: Ethernet-коммутаторами, серверами, бортовыми компьютерами, медиаконверторами и модулями GSM/GPRS (c элементами Virtual Server,VPN, SMS Tunnel).
Выделим ряд новых сетевых элементов в гранулированной бортовой сети: блок управления, LIN, датчики (состава воздуха, давления и температуры хладагента, модуль управления воротами гаража); блок управления, CAN-Комфорт, датчики дождя и освещенности, переключатель освещения, блок управления двигателем; блок управления комбинациями приборов через CAN-Kombi (ходовая часть) и LIN и элементы модуля контроля генератора и аккумулятора через диагностический интерфейс по шине данных в LIN.
Общий ток к минусовой клемме батареи подается через сопротивление шунта (значение сопротивления уменьшено для снижения тепловыделения) в модуле данных батареи. Величина необходимого тока определяется через напряжение на сопротивлении шунта (пропорционально току) и вычисляется в модуле данных. Определение параметров батареи (токи зарядки и разрядки и температура батареи) выполняется в модуле данных и передается через диагностическую шину данных в LIN.
Диагностический интерфейс шин данных — элемент защиты блоков управления (через онлайн адаптацию при помощи диагностического тестера и базы знаний от производителя). Отметим варианты диагностических модулей для интерфейсов: CAN-комфорт, CAN-привод, CAN-ходовая часть, CAN-диагностика, MOST, CAN-Infotainment, CAN-Extended. Изменен протокол данных для подключения к CAN-диагностика тестера VAS («старый» протокол — Key Word 2000, «новый» протокол — UDS с ASAM/ODX) с учетом онлайн-адаптации всех блоков управления через базу данных от производителя. CAN-привод и CAN-Extended к узловым разъемам не подключены и соединены со жгутом проводов через обжимные соединители. Можно подключиться к линиям передачи данных блоков управления без демонтажа деталей обшивки и без снятия изоляции жгута проводов.
Колодка и CAN-узловой разъем на левой стойке, плата реле и предохранителей коммутационного блока, плата предохранителей и клемма подключения внешнего источника тока в водоотводящем коробе, плата предохранителей справа на приборной панели и CAN-узловой разъем, плата реле и предохранителей справа в багажном отсеке, плата предохранителей и аварийный размыкатель батареи на плюсовой клемме батареи, держатель реле и кронштейн блока управления бортовой сети в пространстве для ног водителя, плата предохранителей слева на приборной панели — ряд коммутационных бортовых элементов современного транспорта.
Для обучения необходимо использовать ресурсы бортовых сетей (NT): шасси — Chassis-125Kb/s; движения — Роwertrain-1Mb/s; телекоммуникаций — Infotainment/Telecom; диагностики — K-Line Diagnostic (KLD); промахов вождения — Fault tolerant; Сервисов: салона — ^míto
Выпуск 3
(подушки — Airbag, защиты — HVAG, дверей — Door, размещения — Seat, промахов — PreCrash; Сопровождения: Satellite, Squib, OSS, Rollover, Beltpret); Вождения — Gateway и специализированных бортовых систем: BC (Bort Computer) — бортовой компьютер; CON (Controller iD-rive) — управление транспортом через джойстик iDrive; AFS (Active Front Steering) — активное рулевое управление; DME (Digital Motor Electronics) — электронная система управления двигателем; DSC (Dynamic Stability Control) — система динамической устойчивости; ESP (Electronic Stability Program) — система поддержания динамической стабильности; DTS (Dynamic Traction System) — система динамического контроля тяги; ETS (Electronic Traction Support) — электронное управление тягой.
Ряд NT интегрируют сервисы для гибкого взаимодействия процессов: Special Equipment of Logical Management of Signals (SELMS); Converter of Signals (CS), Transceiver of a Signal of Satellite Management (TSSM), Transmitter of Global Positioning System (TGPS); Wireless Radio Transmitter (WRT).
SELMS реализует виртуальные сетевые технологии обучения и управления транспортом. CS конвертирует сигналы радиоспутниковых каналов. TRITON через GSM, Code Division Multiple Access (CDMA) обеспечивает множественный доступ с кодовым разделением посредством спутниковой навигации. Trunk или Globalstar (вторичный канал связи), GPS или ГЛОНАСС/GPS, General Packet Radio Service (GPRS) реализуют веб-технологии в управлении транспортом. SiRF Star III с пониженным энергопотреблением и высокой чувствительностью может определять позицию не только по сигналам спутников, но и по слабым и переотраженным сигналам. TSSM реализуется на оборудовании спутниковой связи Thuraya и упрощает использование спутниковых каналов. Радиоконтроллеры на базе WML-24M, Flash-памяти, радиотрансивера, узла питания упрощают сбор информации на транспорте. Интеграция сервисов на уровне коммуникатора со средствами Wi-Fi и Bluetooth реализована в NAVSTAR с глобальной системой позиционирования — Global Positioning System-Satellite (GPSS): передает на пульт управления навигационной системе координаты; позволяет видеть взаимное расположение транспорта на отображаемой навигационной карте местности и находить наиболее короткий и удобный путь для транспорта.
Наукоемкость е-технологий требует развития стыков учебных планов (для подготовки ба-калавров-техников, специалистов-магистров, кандидатов, докторов) специальностей подготовки кадров по е-технологиям обучения и управления для использования уникальных ресурсов промышленных и мобильных систем ITC на всех этапах петли качества сервисов через создание в учебных заведениях междисциплинарных, многоцелевых творческих научно-технических институтов и центров концентрации интеллектуальных кадровых и инструментальных ресурсов, а также проведения работ по науке, технологиям и технике на базе е-технологий развития промышленной и мобильной механики, автотроники, телематики (матроники).
Список литературы
1. EPLAN Electric Process Plant Engineering 8th Professional еd. 1.9.6 Build 3297. — 2009.
2. Троелсен Э. С# 2008 и платформа .NET 3.5 Framework = Pro C# 2008 and the .NET 3.5 Framework / Э. Троелсен. — 4-е изд. — М.: Вильямс, 2009. — 1368 с.
3. Xen hypervisor 4.0.0 was released on 07 Apr 2010.
4. Xen hypervisor 4.0.1 was released on 25 Aug 2010.
5. xensource.com
6. xgu.ru
7. xen.org/products/xen_archives.html
