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

1. Прекращение поддержки COM / DCOM

Автоматизированный обмен данными между классическими OPC приложениями базируется на COM технологии Microsoft. Как только операционная система Windows стала широко использоваться во всем мире, и этот факт поспособствовал использованию компьютеров на ОС Windows в автоматизации, сформировались идеальные условия для распространения технологии OPC. В начале 2002 года Microsoft запустила .NET Framework и объявила об отказе от DCOM. Подобное заявление не означает, что будущие версии операционной системы Windows не будут поддерживать DCOM, но в результате такого развития событий базовая технология классической OPC не будет развиваться и рано или поздно устареет.

2. Ограничения DCOM

С технологией COM / DCOM, Microsoft в 90-х годах представила набор функций, которые были высоко оценены конечными пользователями: как домашних компьютеров в непромышленном сегменте, так и профессиональными пользователями, которые использовали компоненты Windows в промышленной автоматизации. Эти функции включают: копирование и вставку, ‘drag and drop’, связывание и внедрение. DCOM также предлагает полную инфраструктуру связи с  необходимыми функциями безопасности, такими как аутентификация, авторизация и шифрование. DCOM Security контролирует права доступа к данным и программам на удаленных компьютерах. В  то же время безопасность DCOM представляет собой серьезную проблему для инженеров, системных интеграторов и разработчиков, которые налаживают связь с OPC  через ПК. Настройка безопасности это достаточно сложная задача и требует много знаний. В результате настройки инженеры и системные интеграторы для ускорения процесса обычно выбирают предоставление очень широких прав доступа на всех компьютерах сети OPC и, следовательно, в значительной степени отключают защиты от несанкционированного доступа. Этот факт противоречит ИТ-требованиям безопасности и, в конечном счете, приводит к рискам и ущербам, причиненным по неосторожности или из-за саботажа. Настройки безопасности DCOM часто являются камнем преткновения при настройке связи с OPC.

3. Связь с OPC через брандмауэры

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

4. Использование OPC не на Windows платформах

«Вездесущность» платформ Microsoft в промышленных приложениях является важным фактором в обеспечении быстрой адаптации коммуникаций под классический OPC. В то же время, интеграция концепций  OPC провалилась в отраслях, работающих с другими ОС. Например, в ИТ-индустрии часто используют Unix или Linux системы. В автоматизации также есть сегменты, в которых применение Windows категорически запрещено. Встроенные решения являются областью, в которой Windows неприменима (за исключением Windows CE или Embedded XP). В таких решениях сложные приложения встроены непосредственно в полевые устройства, контроллеры, операторские панели и другие устройства, управляемые VxWorks, QNX, встроенным Linux, RTOS или другими операционными системами без DCOM. Интеграция концепции  OPC обречена на провал в тех областях, где нужно использовать DCOM в качестве технологической основы. Во встроенных системах эта основа отсутствует.

5. Высокая производительность OPC для связи через веб-службы

С выпуском OPC спецификации XML-DA в 2003 году, OPC Foundation впервые показала способ выхода из зависимости от платформы Windows, а также от ограничений, связанных с DCOM. Сегодня многие OPC XML-DA продукты уже продемонстрировали высокие возможности Web-сервисов на основе технологии OPC. Пропускная способность  XML-DA, однако, примерно в 5-7 раз меньше по сравнению с DCOM DA. Такая производительность считается чрезвычайно низкой для многих задач автоматизации. Возможности, предоставляемые веб-службами на основе OPC довольно внушительные, но все-таки требуется более высокая производительность.

6. Единая модель данных

До сих пор необходимо было иметь три разных ОРС-сервера в классическом OPC — Data Access (DA, чтение и запись), Alarms & Events (AE) и Historical Data Access (HDA) – для получения, например, текущего значения температуры от датчика, события по температуре (по превышению установленного предела) и исторического среднего значения температуры. Это принуждало пользователей доступаться к текущим данным, событиям и историческим данным тремя разными путями. Объединение трех моделей данных упростит все не только для производителей, но и для системных интеграторов и пользователей.

7. Поддержка сложных структур данных

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

8. Процесс передачи данных без потери данных

OPC DA был первоначально определен как  циклическое информирование клиентского приложения о текущем состоянии обработки данных. Если в физическом канале связи между клиентом и удаленным OPC сервером возникнут нарушения, согласно спецификации OPC DA  связь будет оборвана. Изменения данных, которые произошли в то время, когда связь отсутствовала, не могут быть переданы клиенту OPC и являются утерянными. Подобная потеря данных не является критической для большинства применений OPC DA, таких как запись трендов, мониторинга процесса или визуализации. Но технология OPC все больше проникает в области, в которых требования более жесткие. Например, OPC технология стала применятся в таких областях, как химическая и фармацевтическая промышленность, где данные должны записываться безостановочно. И это тоже стало возможным благодаря предоставленным разработчиками расширениям. Они основаны на решениях, которые отслеживают состояние соединения и обеспечивают быстрое обнаружение нарушения связи и автоматическое восстановление связи при разрыве, буферизацию данных в Data Access сервер, резервирование и передачу с промежуточным запоминанием. Являясь полезными, данные расширения не были занесены в спецификацию классического ОРС и отличаются у разных производителей.

9. Повышенная защита от несанкционированного доступа к данным

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

10. Поддержка вызовов методов

Во многих случаях важно не только чтение и запись значений, но и выполнение команд, таких как запуск или остановка устройства  или загрузка файлов в устройство. Спецификация OPC команд (OPC Commands Specification) определяет возможности для выполнения команд, но все это только в черновом варианте. Данная спецификация в классическом ОРС не реализована.

 

Tags

 
Поделиться в Ok Ok Ok Ok Share for Odnoklassniki Ok Ok

0 Комментариев

Вы можете первым оставить свой комментарий.

Оставить комментарий

 




 

Вы же не робот? *