Приложение на CORBA



Начало
Общи сведения за CORBA
OMG и архитектура на CORBA
Обектен модел на CORBA
Езикът IDL
Проект BioStandards
Приложение на CORBA в пациентските регистри
Приложение на CORBA в телероботиката
 
 

Проект за телеоперативна система, базирана на CORBA в реално време


    Новите разработки за отдалечено опериране като телеобучение, виртуални лаборатории и on-line роботи представляват предизвикателни разпределени приложения за роботи, при които изследователските екипи трябва да се справят с хетерогенни, динамични и високо-конкурентни системи за контрол. Работата с разпределени обекти е изключително важна за справянето с комплексността на такива системи, т.к .тя предлага всички предимства на концепцията за обектно-ориентираното програмиране.

    Тук е описана разработката на телеоперирано приложение за роботи, което използва рамка за разпределена телероботика, базирана на CORBA – свойства, например Асинхронния метод за извикване и приоритети в реално време. Демонстрирани са и потенциалните предимства, които носи CORBA като цяло при разработката на приложения в телероботиката.

1 Въведение

    Разпределените компютърни системи и интернет технологиите отвориха нови хоризонти пред телеоперативните системи за роботи. Примери за такива нови приложения за така наречените “свързани в мрежа” и “on-line” роботски системи, са телеобучението, виртуалните лаборатории, отдалечените и on-line управлявани системи и проекти, изискващи сътрудничеството на отдалечени потребители, учени и уреди. Общите предимства на системите в телероботиката, изградени на базата на технологията на разпределените компютърни системи са намалените цени на системите, произволното местоположение на клиентите, динамичния достъп на отдалечени експерти, в случай че това е необходимо, backup (напр. телепрограмирането), намалената цена на обучение на оператори. Разработването на много нови приложения в телероботиката зависи от финансовия фактор. При традиционния подход при телеопериране на роботи, системната архитектура осигурява тясна свръзка на единичен клиентски прибор (master) и сървърски робот (slave), изпълнявайки супервизираща роля, водеща до разнообразни динамични модели на взаимодействие.

1.1.Междинен софтуер

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

    Наличните решения включват Java отдалечено извикване на метод на JavaSoft (Java Remote Method Invocation, Java RMI), Разпределеният компонентен обектен модел на Microsoft (Distributed Component Object Model, DCOM) и Обща архитектура за архитектура за посредници при запитвания за обекти на OMG (Common Object Request Broker Architecture, CORBA). Java RMI на Sun осигурява прост и бърз модел за архитектура за разпределени обекти. Той е продължение на добре познатия модел на отдалечено извикване и позволява изпращането на обекти: данните и методите се пакетират и изпращат по мрежата към получателя, който трябва да е в състояние да разпакетира и интерпретира съобщението. Главната спънка при RMI подхода е че цялото приложение трябва да е написано на Java. Това ограничение е обезпокоително в общите хетерогенни среди на роботските приложения, които често обединяват общи и специализирани софтуерни и хардуерни компоненти. DCOM на Microsoft поддържа работа с разпределени обекти, като позволява лек достъп до отдалечени обекти. Въпреки, че DCOM преодолява зависимостта на RMI от използването на Java, чрез употребата на Език за обектно описание (Object Description Language) с цел постигането на независимост от езика, той все още има някои ограничения, касаещи кода и последователността на приложенията. На практика възможностите на специалистите са ограничени, т.к. DCOM е частно решение, работещо основно на Microsoft опартивни системи. Когато целта е да се осигури незвисимост от езика, търговската организация, и операционните системи, CORBA е най-доброто решение. То осигурява подобни механизми лесен достъп до отдалечени разпределени обекти и преодолява проблемите, свързани с интероперативността на Java RMI и DCOM. Установени са няколко междинни реализации, свързващи разнообразни езици и операционни системи и те са базирани на спецификации, които са независими от търговсите организации и се популяризират от Групата за управление на обекти (Object Management Group, OMG). Към момента CORBA е логичния избор за свързване на комплексни разпределени приложения. Настоящия проект се фокусира на предимствата на CORBA в цялостния процес на разработка на описаната телеоперативна система.

2. Разработка на телеопериран робот.

    Разглеждания случай е модифицирана система master-slave. Операторът е подсигурен с непрекъснат телеоперативен контрл на отдалечения уред и трябва да осъществи проста задача по преместване на обект.

   

Фигура 1. Описание на екперименталния модел
Телероботската система е реализирана от експерименталния модел, показан на фиг. 1 Отдалеченият манипулатор е Unimation Puma 560, интерфейса му е на машина Intel с опеарционна система Solaris, работеща с RCI/RCCL програмна среда. Сензорната система се състои от черно-бяла камера, IR сензор за близост, монтиран близо до хващача на манипулатора, видео камера, монтирана на тавана и обхващаща цялото тестово поле и стерео-визуална система пред предмета-цел.

    Отдалечената среда може да бъде следена от няколко клиента чрез разпространение на данните от гореизброените сензори. Всяка клиентска част има клиентско приложение, от което може да бъде избрана исканата графична услуга от някой от изброените сензори. По-напредналите технологично клиентски части са снабдени с мулти-модален потребителски интерфейс, в който се включват ръкавица за виртуална реалност и проследител (tracker). При описаните по-долу опити локалните и отдалечените компютърни системи са свързани чрез Fast Ethernet swich, който не отчита съществено забавяне .

2.1. Клиент

    За да бъде позволено на клиентите да комуникират с отдалечената среда, да програмират и следят изпълнението на задачата, всяка клиентска част е осигурена с клиентско приложение. То е изградено на CORBA услугите, които осигуряват яснота за местоположението и релизацията на наличните компоненти. Потребителят може да търси компонентите (CORBA обекти) с помощта на именуващата услуга, като я избере от възможностите на графичния потребителски интерфейс, с който е снабдено клиентското приложение.

    Именуващата услуга (една от основните услуги на CORBA ), ще открие обектите на базата на техните имена и ще върне референция към отдалечения обект, съхранен под това име. Това позволява диамично конфигуриране на приложението, без никаква промяна в клиентския код.

    Телеоперативното приложение включва няколко хетерогенни сензора, чиито данни трябва да бъдат предадени на клиентските части и бързо да бъдат върнати на потребителя. На фиг.2 е показан интерфейса на клиентското приложение, където се вижда получената информация.

Фигура 2. Интерфейс на клиентското приложение

    Операторът може да избира между две възможности при дефинирането на задачите на приложението. Най-опростената възможност е да се изпълни поредица от прости команди (т.е. придвижи рамото до позиция P, вземи предмета, изведи стойността на сензора, затвори хващача и т.н.). По-практична алтернатива е да се дефинира приложение чрез редактирането на програма, която ще се изпълни чрез употребата на език на високо ниво (подобен на С). За да използва поредица от прости команди клиентското приложение може да използва Синхронен метод за извикване на отдалечени обекти, като се блокра (приложението) докато сървъра отбележи края на заявеното действие. Този подход на изчакване и продължаване не може да бъде използван в това приложение. На практика клиентът има нужда да извиква изпълнението на конкурентни действия към сървъра като иска да получи данни от множество сензорни източници, докато контролира движението на рамото и на хващача. Тъй като в стандарта бе въведен Асинхронния модел на извикване (AMI) за работа с неблокиращи извиквания, разработеното приложение използва за целите на тези изисквания асинхронни извиквания, реализиращи чакаща “рандеву” стратегия.

2.2.Сървър

Както е показано на фиг.1 тестовата част включва сървърско приложение, което управлява Puma манипулатора, както и няколко сензора в зависисмост от клиентските заявки, чиито ред и спешност трябва да бъде спазен.

    За да координира употребата на манипулатора и за да гарантира своята собствена устойчивост при достъп от конкурентно изпълнявани операции, сървърското приложение използва CORBA услугата за контрол на конкурентността. Тази услуга използва ключалки, за да предостави въаможността на даден клиент да достига до специфичен източник по определен начин. Така координацията се постига чрез предпазването на множество клиенти от едновременно действащи ключалки за един и същи източник, ако действията на тези клиенти могат да са в конфликт. Разработва се заместването с употребата на услугата за сигурност при осгуряването на защита от достъп на оторизиран клиент на системата до CORBA обектни методи, които трябва да са скрити от него. Съществуват две отделни клиентски приложения –едно за стандартните потребители и едно за администриращите потребители. Последните могат да спрат цялото приложение в спешни случаи, но в замяна от съображения за по-сигурен и по-подходящ дизайн трябва да бъде използвана услугата за сигурност.

    Тестваното приложение позволява на множество клиенти текущо да следят и контролират задачата, като това води до голям брой заявки към сървъра. Управлението на тези заявки, като се запази техния ред на получаване и приоритет изисква сървъра да има ефективна мултинишкова (multythread) архитектура. За да отговори на тези изисквания сървърското приложение бе реализирано с употребата на thread Pool механизъм, наличен в CORBA. При този механизъм група от нишки статично се създават в началото, като по този начин се избягва претрупването на създаване и разпадане на нишки по време на изпълнението и се ограничава максималния брой нишки на сървъра.

    Сървърното приложение трябва също така да бъде чувствително към приоритета на клиентските заявки. На практика администраторските заявки са с по-голям приоритет от тези на обикновения потребител, а дори един и същи клиент може да прави заявки с различен приоритет .

    За поддръжката на приоритетността на клиентските заявки бе използван Priority Mapping (част от CORBA ), който преобръща асоциираните с CORBA операции CORBA приоритетни нива в приоритетни нива на операционните системи и обратно. CORBA предоставя още два модела, които могат да бъдат ползвани за база за пометодно извикване: SERVER_DECLARED и CLIENT_PROPAGATED. При SERVER_DECLARED модел всеки обект се свързва с ниво на приоритет по време на създаването си, докато при CLIENT_PROPAGATED модел клиентското приложение установява приоритет за всеки метод и сървърското приложение трябва да спази този приоритет.

    Функционалността, която бе реализирана чрез тези възможности на CORBA се нарича “авариен бутон”, като нейният едниствен метод push() спира приложението в спешни ситуации. Приоритетът на този метод е SERVER_DECLARED, т.к. той винаги трябва да бъде изпълняван на най-високото възможно ниво за незабавно спиране на системата. Друга възможост на CORBA – Thread Pool с Lanes бе използвана, за да бъде отстранена възможността сървъра да не може незабавно да изпълни метода поради инверсия на проиоритети или претоварването на нишките. Тъй като нишките в отделни Lanes са свързани с различни пироритети с незастъпващи се граници, свързването на Lane с единична нишка с най-висок приоритет, който да е запазен за изпълнението на push() метода гарантира предвидимо поведение.

   

2.3. Разпространение на сензорните данни

    Проблемът с разпространенирто на множество сензорни данни към много клиенти е типичен за приложенията в телероботиката и заслужава специално внимание. За ефективността, извличането и разпространението на данните трябва да се избягват преброяващите операции. Още повече - трябва да може да дефинира нивото на получаване на исканите данни, за да се избегне ненужно разпространение на информация.

    За постигането на тези цели, разпространението на сензорни данни бе базирано на Observer (наблюдател) модела. Той изисква дефинирането на два CORBA класа за всеки наличен сензор : “предмет” от страна на сървъра и “ наблюдател “ от страна на клиента. В случая на конкретната реализация на решение за микрокамера, за да получи видеоданните от камерата клиентското приложение извиква метод attach(video x) на обекта camera (предметът), изпраща референция към video обекта (наблюдателя). Всеки camera обект има списък с всички video обекти, които са били достигнати. Когато видеоданните са готови, сървърското приложение може да извика video_obj[1].draw(image_data) метода за всички “достигнати” видео обекти. Методът detach() позволява на клиента да спре видео потока, като премахва референцията му от списъка за разпространение на данни.

3. Експерименти и анализи

    В конкретния проект бе предложена обектна рамка, базирана на CORBA в реално време и бе оценена нейната ефективност при конкурентно изпълнение (с различни приоритети) на прости задачи на телеробота. Бе проверена и пълнотата, модуларността и гъвкавостта на рамката при изпълненето на задача за закрепяне на предмет, както и цялостното приложение на телеробота с подаването към различни клиенти на хетерогенни сензорни данни. Разработката на сървъра изискваше само реализация на CORBA обектите за поддържаните уреди, т.е. не е необходим код за имплементацията за комуникационните слоеве, т.к. кода на сървъра е базиран на налични услуги на CORBA, които са вградени в рамката.

    В контекста на опита по закрепяне на предмет бе изчислено влиянието на сензорната обратна връзка за действието на оператора. За целта бяха оборудвани няколко тестови площадки, които комбинират различни подгрупи от наличните сензори (бордова камера, IR сензор за близост и камера с видимост на цялото поле). Задачата изискваше вкарването на квадратна запушалка в дупка с големина около 3 мм. След опитна сесия от около две минти с входящите уреди (ръкавица и tracker), десет неумели операции доведоха до успешен край операцията. Анализите на времето на изпълнение показват, че операторите, снабдени с обратна връзка от множеството сензори имат по-бърз курс на обучение. Реализацията на различни алтернативни тестови площадки експлоатира способността на рамката лесно да се пригажда към промените в архитектурата: новите уреди лесно могат да са интегрирани в сървъра, като изискват само реализацията на интерфейсите и методите, налични в клентските приложения.

4. Заключение

    Нарастващата популярност на CORBA архитекурата като междинен софтуер за разпределени, вградени системи в реално време прави тази архитектура подходящ кандидат за развитието на приложенията в телероботиката. С този проект, чрез разработката на реалистичен експеримент в телероботиката, бе изследвано дали две нови разширения на CORBA стандарта (Асинхронен метод на извикване и CORBA в реално време) могат да бъдат по-удачни за нуждите на приложенията в телероботиката. Опитът в разглеждания случай показа, че последните CORBA спецификации наистина намаляват програмните усилия в комплексните приложения, като скриват от разработчиците детайлите, касаещи комуникациите мажду разпределени обекти. Разбира се сама по себе си CORBA не реализира приложение, необходима е допълнителна работа за система в телероботиката. Опитът доведе до софтуерна рамка, която постига стабилност, преносимост, отвореност, разтегливост и повторна използваемост на приложението.