Отправляет email-рассылки с помощью сервиса Sendsay
  Все выпуски  

АСУ Технологических Процессов- Новые Технологии #47


Служба Рассылок Subscribe.Ru проекта Citycat.Ru
АСУ Технологических Процессов- Новые Технологии  # 47

Мир Новых Технологий
  PingWin's Service

В каждом сомнительном деле единственное средство не ошибиться - это предполагать самый худший конец. /Людовик ХIV/

# Здравствуйте, уважаемые подписчики

Одна просьба- Помочь в становлении нового отдела : 

Здравствуйте!

На Тамбовском ПМЭС произошло событие! В струк-ре предприятия появился отдел  АСУ. На сегодняшний день определено большое кол - во задач, которые должен решать наш отдел. Основные:

1 Техперевооружение электроподстанций 500 кВ с применением АСУТП

2 Создание корпоративной сети предприятия и внедрение КИС

Прошу Вас помочь нам советом (на основе собств опыта) , нормативной документацией, тех. литературой и т.д.

PS.Отдельно прошу начальников отделов (служб) АСУ помочь нам с документацией по организации отдела АСУ (Положения о АСУ, должн.инструкции, штатное расписание, советы по организации работ с персоналом) 

С УВАЖЕНИЕМ!

Сергей Васильев - начальник отд. АСУ Тамбовского ПМЭС sergey@max.tstu.ru

Продолжим тематику ОРС.

Удачи, и всего наилучшего!
До встречи на Форуме АСУ ТП !

С уважением,
Дмитрий Милосердов
could@chat.ru

***

Сегодня в выпуске:

1.Сравнение OPC с другими технологиями.

***
Сравнение OPC с другими технологиями.

Ильдар Ибатуллин (IbatullinI@nknh.ru)

http://pi2001.da.ru

        До недавнего времени стандартом де-факто передачи информации от низового уровня, т.е. от DCS/SCADA/MMI был протокол DDE (dynamically data exchange) впервые предложенный фирмой Wonderware и активно поддержанный Microsoft. Так уж вышло, что об историческом разработчике протокола «забыли», да и он не очень-то и старался довести это во всеуслышание. Тем не менее, тот вариант, который использовался в системах Windows (и до сих пор используется для управления запуском приложений и прочих унаследованных приложениях) вскоре перестал устраивать из-за своих недостатков, самые главные из которых: низкая скорость передачи данных и необходимость постоянного контроля соединения. Впоследствии некоторые фирмы стали разрабатывать свои расширения (например, FastDDE от той же Wonderware, AdvancedDDE от Rockwell), которые не нашли отклика среди других разработчиков.

        Дальнейшим «развитием» этого направления у Microsoft стал выпуск спецификации COM, активно продвинутый в массы. Как следствие, на основе этой вспаханной нивы стали развиваться другие технологии, в частности OPC. Основными преимуществами OPC стали: производительность, гарантированное распространение и продуманная архитектура. Но не надо забывать и о недостатках: существование только на одной платформе и недостаточная распространенность приложений верхнего уровня. Сегодня судьба OPC — в руках производителей промышленных приложений. Только они смогут выпустить доброго джина стандартизации из бутылки. И тогда счастливые пользователи избавятся от головной боли, как связать воедино то, что они уже имеют или будут иметь. Хватит ли у Microsoft сил, терпения, упорства и средств, чтобы обеспечить «зеленую улицу» своему детищу? Сможет ли компания, имеющая такое исключительное влияние на компьютерный рынок, совершить революцию и в автоматизации промышленности?

        Последний "хит" от Microsoft в этой области анонсирован в сентябре 1997 г. Имя ему — Windows DNA (Windows Distributed interNet Applications Architecture). Эта архитектура также основана на объектно-ориентированной COM-технологии создания функциональных пользовательских компонентов. Новая идея — разработка спецификаций по отдельным отраслям и сегментам промышленности (Vertical Industry Specifications) — не лишена логики и позволит сконцентрироваться на нескольких областях производства, где наиболее популярны программные продукты, поддерживающие COM. Это можно расценивать как признание поражения всех попыток выработать общий промышленный стандарт. Таким образом, похоже, что будущее стандартизации — в руках Microsoft, и пользователям остается следить за развитием событий.

Связующее ПО

После неудачи General Motors на пути стандартизации для решения задачи интеграции был создан консорциум, в который вошли крупные автомобильные производители (Renault, Mercedes-Benz и др.), представители авиационной промышленности и некоторые фирмы бытовой электроники (Bosch, Siemens Automation и др.). Он получил название AIT (Advanced Information Technology). С его помощью была разработана интеграционная платформа CCE (Common Computing Environment). Данная среда позволяет приложениям независимо от протоколов, операционных систем, баз данных и методов доступа общаться друг с другом. Развитие этой идеи привело к возникновению архитектуры CORBA (Common Object Request Broker Architecture), также одобренной консорциумом AIT. [8]

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

Но не все так хорошо, как кажется. Отметим некоторые недостатки внедрения связующего ПО:

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

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

ORB — это связующее ПО, которое позволяет устанавливать клиент-серверные отношения между объектами. Используя ORB, клиент может легко вызывать сервис на объект-сервере, при этом аппаратно клиент и сервер могут быть как на одной машине, так и на разных, и общаться между собой по сети. ORB перехватывает запрос и отвечает за его доставку, передачу параметров, вызов сервиса, а также за доставку результатов. При этом клиенту совершенно не нужно "знать", где объект-сервер находится, какова его операционная система и на каком языке программирования он написан. Все это — вне интерфейса взаимодействия самих объектов. Таким образом, ORB обеспечивает обмен информацией между приложениями на различных устройствах в неоднородной распределенной среде, создавая связную объектно-ориентированную систему.

Консорциум OMG (Object Management Group), основанный в 1989 г., взял на себя труд разработать теорию объектно-ориентированной технологии для развития распределенных компьютерных систем. Основное направление деятельности консорциума можно сформулировать так: развитие общей архитектурной платформы для объектно-ориентированных приложений на основе открытых спецификаций. Его девиз звучал бы, наверное, более патетически: "Архитектура для объединения мира".

Сначала в OMG входило всего 13 компаний, сейчас их число выросло до 500. Это поставщики, разработчики и пользователи компьютерных технологий. Можно сказать, что все компании, заинтересованные в разработке объектно-ориентированных подходов, являются членами OMG.

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

Версия 1.1 спецификации CORBA была выпущена OMG в 1991 г. В ней были определены язык описания интерфейса (Interface Definition Language — IDL) и интерфейсы прикладного программирования (Application Programming Interfaces — API), сделавшие доступным взаимодействие клиент—объект в среде ORB. Суть модели в следующем. Клиент запрашивает сервисы у объекта (который выступает в качестве сервера) через хорошо определенный интерфейс (последний специфицирован в IDL). Для доступа к объекту клиент создает запрос, т. е. сообщение, содержащее информацию о действии, ссылку на сервис, параметры.

Спецификация CORBA 2.0, "родившаяся" в декабре 1994 г., определила информационный обмен между приложениями различных фирм. Она добавила к уже освоенным высотам возможность обмениваться данными через Интернет по протоколу IIOP (Internet Inter-ORB Protocol) и платформенную независимость. Ее внедрение позволяет пользоваться преимуществами Интернет без перестройки промышленной системы.

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

И все-таки архитектура OMG/CORBA более зрелая, чем OPC и тем более Windows DNA. Уже существуют многочисленные ее реализации, применение которых в промышленности делает приложения независимыми от используемых устройств, сетей, операционных систем и компьютеров. Возникают заманчивые перспективы свободного развития приложений, с одной стороны, и общей инфраструктуры — с другой. Правда, если наступит эра всеобщей стандартизации по версии Microsoft, то CORBA останется не у дел. Но, пока она не наступила, CORBA, пожалуй, лучшее решение для объединения в единый комплекс автоматических систем управления различных уровней с учетом того, что некоторые из них устарели, а другие не подчиняются никаким стандартам и предлагают уникальные решения.


***
Off-line Форум и конференция по вопросам автоматизации и АСУ ТП.
Для подписки на него Вы можете послать пустое письмо по адресу-asutp-subscribe@egroups.com
В дальнейшем, для отправки сообщений и вопросов по АСУ ТП писать на:asutp@egroups.com
Страничка Форума находится по адресу-http://www.egroups.com/group/asutp
***

У меня c Екатериной Калмыковой есть еще один совместный проект!
Рассылка "Секреты и откровения авторов рассылок" наверняка заинтересует тех, кому захочется узнать больше об авторах-ведущих рассылок на сервере Городского Кота. Вам откроются личности и характеры ведущих рассылок в откровенных беседах на различные темы - от политики и экономики до искусства и спорта.

Подпишитесь!
http://subscribe.ru/catalog/people.interview

***
                Copyright    2001 Дмитрий Милосердов
Копирование материалов обозрения разрешается только в случае указания на
"PingWin's Service" как на источник получения информации, при этом во всех ссылках обязательно явное указание адреса e-mail could@chat.ru
                            

ПРЕДУПРЕЖДЕНИЕ: "PingWin's  Service" является личной инициативой автора и работает без каких-либо гарантий !



http://subscribe.ru/
E-mail: ask@subscribe.ru
Поиск

В избранное