Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 52
Волшебное наследие MS из 90ых (когда MS была зубаста и страшна) — DCOM, OLE, ActiveX… Что там ещё было в этой куче? Намертво проприентарное, зажатое в суровом кулаке, использующееся для удавления любых попыток конкурировать… Нынешня MS мягка, податлива и потому нестрашна.
Тот, кто умеет адаптироваться к изменяющимся условиям — выживает.
И это радует, MS молодцы!
И это радует, MS молодцы!
С точки зрения бизнеса — наверное. С точки зрения IT — после ухода Гейтса MS стала просто «никакой». Что-то там делает, старается, но её можно просто игнорировать.
Она перестала быть кровным врагом, а частью «доброго мира» не стала. Так, контора бывшей империи зла.
Она перестала быть кровным врагом, а частью «доброго мира» не стала. Так, контора бывшей империи зла.
Полностью согласен, что с приходом Баллмера к рулю компания стала унылой и малоперспективной. Баллмер полный тупица (идиотские противопоставления PC Макам, задержки выпуска ключевых продуктов на годы!!!), и только когда Гейтс на время приходит исправлять ситуацию, кое-что получается дельное (например, та же Windows 7).
Гнать Баллмера в шею надо.
Гнать Баллмера в шею надо.
Сам веду проект на базе Ruby on Rails в области промышленной автоматизации, уже лет пять. За эти годы уже реализовали передачу данных из контроллера на сервер GET-запросом! Такие скромные достижения конечно из-за инертности отрасли. Там до сих пор активно используются архитектуры 8051, самым смелым интернет-протоколом является sFTP, все разговоры о развитии упираются в безопасность, но в качестве защиты используется 32-битные чексуммы MODBUS CRC. Возможно, под давлением «гражданских» применений типа «интернета вещей» эту отрасль удастся обновить.
Совершенно с Вами согласен, а чтобы было больше «гражданских» применений нужны открытые стандарты и технологии. ModBus у нас есть, теперь нужен открытый и переносимый аналог OPC.
Очень интересно! Можете рассказать пару слов о нем?
веду проект на базе Ruby on Rails в области промышленной автоматизации
Очень интересно! Можете рассказать пару слов о нем?
Система GSMcontrol www.zarealye.com/?cat=3, в России не нашел клиентов, в Финляндии работает.
Это как бы SCADA для GSM-контроллеров, т.е. беспроводная передача данных через Интернет. До сих пор не нашли нормальной реализации HTTPS-стека на GSM-модеме!
Это как бы SCADA для GSM-контроллеров, т.е. беспроводная передача данных через Интернет. До сих пор не нашли нормальной реализации HTTPS-стека на GSM-модеме!
Точно так, я бы сказал всё ещё хуже…
> Дело в том, что основная часть моих коллег по цеху не являются ИТ-специалистами и работаю в рамках тех инструментальных средств, которые являются стандартом «де-факто»
Я помню как на свой страх и риск делал тулзу конфигурации SCADA на XML вместо INI файлов. Вроде пустяк, но сопротивление было ожесточенным (причем со стороны сотрудников всего лет на 5 меня старше). Все-таки дополнительные риски в серьезных проектах очень нежелательны. Времени на эксперименты, как всегда нет, а зафакапить проект такими нововведениями очень даже легко можно.
Было время, когда активно набирали «студентиков». Те в порыве бешенного энтузиазма стали продвигать Open Source: Code::Blocks, WxWidgets, Qt и сопутствующие тулчейны. В результате начались жестокие проблемы, начиная с багов компиляции с gcc для использовавшихся контроллеров, до багов терминальных программ и прочих тулзовин, которые переписывались с дельфей на «кроссплатформенных» фреймворках.
Так что иногда «отличное враг хорошему: работает — не трогай!»
Я помню как на свой страх и риск делал тулзу конфигурации SCADA на XML вместо INI файлов. Вроде пустяк, но сопротивление было ожесточенным (причем со стороны сотрудников всего лет на 5 меня старше). Все-таки дополнительные риски в серьезных проектах очень нежелательны. Времени на эксперименты, как всегда нет, а зафакапить проект такими нововведениями очень даже легко можно.
Было время, когда активно набирали «студентиков». Те в порыве бешенного энтузиазма стали продвигать Open Source: Code::Blocks, WxWidgets, Qt и сопутствующие тулчейны. В результате начались жестокие проблемы, начиная с багов компиляции с gcc для использовавшихся контроллеров, до багов терминальных программ и прочих тулзовин, которые переписывались с дельфей на «кроссплатформенных» фреймворках.
Так что иногда «отличное враг хорошему: работает — не трогай!»
Да ведь не работает… Я занимался глобальной интеграцией АСУТП достаточно большого предприятия в MES систему, не смогли мы использовать OPC для этого. Купили в результате OPC-тунель. Получилось и работы больше по настройке и денег кучу потратили.
Я не предлагаю отказаться от SCADA и начать писать самописные программы, я предлагаю другой способ взаимодействия. Если идея переродиться в открытый стандарт и будет работать, то появиться и драйвера для SCADA систем и поддержка производителей. Будем вспоминать OPC как страшный сон)) (Мечты конечно)
Я не предлагаю отказаться от SCADA и начать писать самописные программы, я предлагаю другой способ взаимодействия. Если идея переродиться в открытый стандарт и будет работать, то появиться и драйвера для SCADA систем и поддержка производителей. Будем вспоминать OPC как страшный сон)) (Мечты конечно)
Некорректно я написал…
В данном случае я также испытываю «бешенный энтузиазм» по теме использования REST подхода. Сам являюсь большим фанатом рельс в частности и Ruby в целом. Так что… довольно интересно.
А по поводу сопротивления: закостенелость и боязнь доп. рисков — вот одно из главных препятствий перед прогрессом.
В данном случае я также испытываю «бешенный энтузиазм» по теме использования REST подхода. Сам являюсь большим фанатом рельс в частности и Ruby в целом. Так что… довольно интересно.
А по поводу сопротивления: закостенелость и боязнь доп. рисков — вот одно из главных препятствий перед прогрессом.
Согласен, но надеюсь, что ситуация измениться и REST (наверно лучше сказать XPCA) приживется если появятся работающие реализации, у меня в голове такой план:
1. Создание прототипа серверной части (мой проект Galilei). Кстати пишу на C# не потому что очень уж его люблю, а потому что надеюсь что под флагом .NET у него больше шансов прижиться в нашей отрасли.
2. Пилотный проект на реальном объекте (выпросил у начальства крохотный проект для этой цели)
3. Создание черновика спецификации, протокола XPCA.
4. Создание OPC сервера для XPCA, что позволит использовать XPCA как туннель OPC протокола.
5. Расширения для SCADA систем, где это возможно. Причем как драйвера, для получения данных с XPCA серверов, так и поддержку получения данных по XPCA для систем верхнего уровня.
1. Создание прототипа серверной части (мой проект Galilei). Кстати пишу на C# не потому что очень уж его люблю, а потому что надеюсь что под флагом .NET у него больше шансов прижиться в нашей отрасли.
2. Пилотный проект на реальном объекте (выпросил у начальства крохотный проект для этой цели)
3. Создание черновика спецификации, протокола XPCA.
4. Создание OPC сервера для XPCA, что позволит использовать XPCA как туннель OPC протокола.
5. Расширения для SCADA систем, где это возможно. Причем как драйвера, для получения данных с XPCA серверов, так и поддержку получения данных по XPCA для систем верхнего уровня.
Как там было в фильме «Майор Пейн»?
> «Дави потихоньку, детка!»
УДАЧИ!
> Кстати пишу на C# не потому что очень уж его люблю, а потому что надеюсь что под флагом .NET у него больше шансов…
Правильно. Бытует мнение, что Ruby пока слишком экзотичен.
> «Дави потихоньку, детка!»
УДАЧИ!
> Кстати пишу на C# не потому что очень уж его люблю, а потому что надеюсь что под флагом .NET у него больше шансов…
Правильно. Бытует мнение, что Ruby пока слишком экзотичен.
Мне бы помощи вместо удачи)
Надо подумать… Поизучать тему.
Таски уже расписаны?
Таски уже расписаны?
Я очень желаю всем интеграторам, чтоб ваш проект сдох, так и не родившись.
А вам желаю понять специфику отрасли и таки быть в курсе современных разработок. И не изобретать собственных велосипедов там, где они не нужны.
А вам желаю понять специфику отрасли и таки быть в курсе современных разработок. И не изобретать собственных велосипедов там, где они не нужны.
Ну, вы бы всё же как-то чуть подробнее. А то понятно, что не понравилось, но что именно, и почему?
Ниже есть от меня большой комментарий.
Протоколов УЖЕ вагон, нет, состав и маленькая тележка. Их так-то замучаешься в одну систему интегрировать. OPC в этом плане сильно спасает.
Теперь появляются люди, которые говорят «А давайте к этому вагону изобретем ЕЩЕ один протокол! Это же так классно, изобретать новые протоколы».
При этом сами признаются, что с последними усилиями большой части отрасли (http://opcfoundation.org/About/MemberList.aspx) в области стандартизации не знакомы.
Протоколов УЖЕ вагон, нет, состав и маленькая тележка. Их так-то замучаешься в одну систему интегрировать. OPC в этом плане сильно спасает.
Теперь появляются люди, которые говорят «А давайте к этому вагону изобретем ЕЩЕ один протокол! Это же так классно, изобретать новые протоколы».
При этом сами признаются, что с последними усилиями большой части отрасли (http://opcfoundation.org/About/MemberList.aspx) в области стандартизации не знакомы.
А еще в DCOM'е невозможно контролировать таймауты, поэтому кратковременный сбой сети способен вогнать клиентское приложение в глубокий ступор.
Мы свой продукт с OPC перевели на OPC UA — новое поколение OPC, без жесткого протокола передачи данных (http://en.wikipedia.org/wiki/OPC_Unified_Architecture). Сейчас поддерживается HTTP (XML) и TCP (бинарный формат). Там есть всё, что угодно — discovery service для анализа адресного пространства сервера, независимая безопасность, push и pull модели получения данных, типизация данных, кроссплатформеность. За членство в OPC Foundation отстегнуть пришлось, но там суммы терпимые, зависят от прибыли компании.
Мы свой продукт с OPC перевели на OPC UA — новое поколение OPC, без жесткого протокола передачи данных (http://en.wikipedia.org/wiki/OPC_Unified_Architecture). Сейчас поддерживается HTTP (XML) и TCP (бинарный формат). Там есть всё, что угодно — discovery service для анализа адресного пространства сервера, независимая безопасность, push и pull модели получения данных, типизация данных, кроссплатформеность. За членство в OPC Foundation отстегнуть пришлось, но там суммы терпимые, зависят от прибыли компании.
Да OPC UA — это шаг на встречу, но есть и там изъяны.
1. Опять же закрытый стандарт;
2. RPC модель довольно громоздка.
3. Поддержка SCADA систем намного меньше, чем у OPC DA. Хотя это со временем конечно измениться.
1. Опять же закрытый стандарт;
2. RPC модель довольно громоздка.
3. Поддержка SCADA систем намного меньше, чем у OPC DA. Хотя это со временем конечно измениться.
Стандарт открытый (IEC 62541), в том плане, что никто его за семью печатями не прячет. Но закопирайченный. Я плохо разбираюсь в лицензировании, поэтому не могу сказать, что вправе сделать простой разработчик никому ничего не платя.
Не понял, при чем тут RPC. В OPCUA действительно есть протокол сервисов, что-то типа удаленного вызова процедур. Remote Procedure Calling, я так понял про это речь? Но помимо того есть протокол доступа к адресному пространству и протокол запроса данных. Они ничего общего с DCOM/RPC не имеют. Не знаю как это сказать, вполне обычные протоколы для доступа к данным, поддерживают асинхронные вызовы. Указал идентификатор, интервал обновления и каллбек, получил дескриптор подписки. При желании можно клиент и на сокетах написать, все форматы описаны в стандарте.
Поддержка SCADA уже большая. Меньше чем у OPC, но почти все крупные системы его уже поддерживают.
Понятно, что хочется свой открытый и бесплатный стандарт, но широкой поддержки он всё равно не найдет. Все крупные игроки переключились или переключаются на OPC UA, так что уйти от него будет сложно, так же как от OPC DA. SDK для большинства SCADA систем стоят много денег, и просто так интегрировать в них свой протокол не выйдет.
Кроме того я бы на вашем месте четче оценил объём предстоящей работы. Одно дело получить значение из контроллера по HTTP, другое — написать свой стандарт, удовлетворяющий требованиям широкого круга САПР. Ведь надо думать о безопасности, отказоустойчивости, гарантии времени передачи, функциональности…
Не понял, при чем тут RPC. В OPCUA действительно есть протокол сервисов, что-то типа удаленного вызова процедур. Remote Procedure Calling, я так понял про это речь? Но помимо того есть протокол доступа к адресному пространству и протокол запроса данных. Они ничего общего с DCOM/RPC не имеют. Не знаю как это сказать, вполне обычные протоколы для доступа к данным, поддерживают асинхронные вызовы. Указал идентификатор, интервал обновления и каллбек, получил дескриптор подписки. При желании можно клиент и на сокетах написать, все форматы описаны в стандарте.
Поддержка SCADA уже большая. Меньше чем у OPC, но почти все крупные системы его уже поддерживают.
Понятно, что хочется свой открытый и бесплатный стандарт, но широкой поддержки он всё равно не найдет. Все крупные игроки переключились или переключаются на OPC UA, так что уйти от него будет сложно, так же как от OPC DA. SDK для большинства SCADA систем стоят много денег, и просто так интегрировать в них свой протокол не выйдет.
Кроме того я бы на вашем месте четче оценил объём предстоящей работы. Одно дело получить значение из контроллера по HTTP, другое — написать свой стандарт, удовлетворяющий требованиям широкого круга САПР. Ведь надо думать о безопасности, отказоустойчивости, гарантии времени передачи, функциональности…
К сожалению не имею OPC UA спецификации, но если я не ошибаюсь та часть которая работает по HTTP представляет собой SOAP. SOAP в свою очередь использует RPC модель взаимодействия м\у клиентом и сервером. Преимущество REST в данном случае, что я могу получить данные с помощью обычного HTTP запроса даже в обычном браузере, а вот для SOAP придется организовывать вызов — пример. Поправьте, пожалуйста если я ошибаюсь.
Использование REST идеологии, делает сервера и клиенты намного «тоньше», вот за что я воюю.
А по объему работы… конечно я согласен, что одному не по силам все это сделать. Надеюсь, что на каком то этапе появятся люди, которые смогут помочь не только на словах, но и делом. Если же этого не произойдет, то значит это было не нужно, и смысла работать над этим нет.
Использование REST идеологии, делает сервера и клиенты намного «тоньше», вот за что я воюю.
А по объему работы… конечно я согласен, что одному не по силам все это сделать. Надеюсь, что на каком то этапе появятся люди, которые смогут помочь не только на словах, но и делом. Если же этого не произойдет, то значит это было не нужно, и смысла работать над этим нет.
Вы немного перепутали, SOAP это формат, как JSON. Это RPC использует его, а не наоборот. Из JavaScript'а технически можно отправить OPC UA запрос, только придется формировать и парсить XML в ручную. Это по сути и есть реализация OPC UA. Сейчас готовых JavaScript классов для работы с OPC UA на прикладном уровне вроде бы нет, хотя, если погуглить, то можно найти несколько планов реализации. Думаю, рано или поздно появится.
Я понимаю преимущество REST, можно встроить GUI получающий данные прямо в HTML. Думаю, в скором времени такая возможность должна будет появиться и для OPC UA.
К слову, под REST тоже придется делать прокси, не давать же прямой доступ к контроллерам.
Я понимаю преимущество REST, можно встроить GUI получающий данные прямо в HTML. Думаю, в скором времени такая возможность должна будет появиться и для OPC UA.
К слову, под REST тоже придется делать прокси, не давать же прямой доступ к контроллерам.
> К слову, под REST тоже придется делать прокси, не давать же прямой доступ к контроллерам.
Защита от DDOS или для чего-то еще?
Аутентификация и другие вопросы безопасности, как я понимаю, можно наладить на уровне контроллеров.
Защита от DDOS или для чего-то еще?
Аутентификация и другие вопросы безопасности, как я понимаю, можно наладить на уровне контроллеров.
Балансировка нагрузки. В том продукте, над которым работаю я, прокси-серверы используется даже внутри самого объекта автоматизации, между контроллерами и операторскими станциями (экранами с мнемосхемами). Один процесс операторской станции может требовать нескольких сотен подписок на значения из разных контроллеров для обновления экрана. Когда таких станций несколько десятков, вычислительная нагрузка на контроллер может превысить квоту свободного времени, которое контроллер может потратить на обслуживание сети без нарушения времени цикла. В этом случае на станции могут выводиться ложные сообщения о потере связи с контроллером.
Если я правильно понял, то прокси выполняет роль кэша и агрегатора?
Да. При том получается, что с контроллером TCP/IP линк один, а с прокси — много. Недостаток в том, что прокси становится точкой централизации данных, и в случае отказа, если прокси всего один, весь объект «ослепнет». Поэтому на практике используются разные методы повышения надежности — переключение на прямую связь с контроллером при отказе прокси, дублирование, каскадирование. Это уже в конкретных случаях по разному.
Еще один эффект — это увеличение времени реакции «GUI» на изменения в контроллере, но на практике задержка пренебрежительно мала.
Еще один эффект — это увеличение времени реакции «GUI» на изменения в контроллере, но на практике задержка пренебрежительно мала.
Да, да — посмотрите более внимательно в сторону SOAP. Во-первых это стандарт, а во-вторых для SOAP уже много модулей понапридумывали.
И MS по этому поводу кое-что сделала msdn.microsoft.com/en-us/library/ms950803.aspx.
Использование REST идеологии, делает сервера и клиенты намного «тоньше», вот за что я воюю.
REST — это высокоуровневый транспорт, не надо на него завязываться.
а вот для SOAP придется организовывать вызов
При отладке да — придется потрудиться, но готовые программные модули SOAP должны облегчить эту задачу до безобразия. Доходит даже до того, что есть генераторы «рыб» для конкретного SOAP, генерирующие код по WSDL…
И MS по этому поводу кое-что сделала msdn.microsoft.com/en-us/library/ms950803.aspx.
Использование REST идеологии, делает сервера и клиенты намного «тоньше», вот за что я воюю.
REST — это высокоуровневый транспорт, не надо на него завязываться.
а вот для SOAP придется организовывать вызов
При отладке да — придется потрудиться, но готовые программные модули SOAP должны облегчить эту задачу до безобразия. Доходит даже до того, что есть генераторы «рыб» для конкретного SOAP, генерирующие код по WSDL…
Я очень хорошо понимаю о чем вы говорите, перед тем как обратить внимание на REST, я как то пытался написать свободный OPC XML DA сервер c использованием WSDL… Для серверной части вообще штука очень даже клевая и у REST такого нет, а вот на клиенской части мне кажется REST обыгрывает, т.к. доступ к данным можно организовать без SDK или «рыб», а с помощью стандартных HTTP библиотек. Наверно поэтому я и пришел к REST, хотелось делать проще все)
Почитайте про OPC UA
Они давненько уже отказались от DCOM, поддерживают Linux и много чего еще.
Они давненько уже отказались от DCOM, поддерживают Linux и много чего еще.
Если вы захотите организовать веб портал, на котором будут отображаться данные с OPC UA сервера, как вы поступите?
Можно через JAVA в браузере (SDK к слову есть). Но тогда можно нечаянно задосить источник данных, в том смысле, что начнутся сетевые таймауты из-за того, что поток обслуживающий запросы будет перегружен. При этом в случае контроллера он, возможно, сможет выполнять техпрограмму, это уже зависит от реализации.
По идее грамотным решением будет либо запуск мощного UPC UA прокси сервера, с редиректом клиентских запросов из браузера к нему, либо в качестве UPC UA прокси использовать веб-сервер — получать данные из источников прямо на сервер, а потом отдавать клиентам стандартными способами.
Вместо JAVA можно заюзать и XBAP, есть реализация OPC UA для .NET. Но это уже не кроссплатформенно. Техничеси, возможно реализовать OPC UA и на HTML5 — вебсокетах и java script'е. Не знаю, есть ли готовые рализации.
GUI в любом случае придется описать, сами SDK никаких визуальных компонентов не содержат.
По идее грамотным решением будет либо запуск мощного UPC UA прокси сервера, с редиректом клиентских запросов из браузера к нему, либо в качестве UPC UA прокси использовать веб-сервер — получать данные из источников прямо на сервер, а потом отдавать клиентам стандартными способами.
Вместо JAVA можно заюзать и XBAP, есть реализация OPC UA для .NET. Но это уже не кроссплатформенно. Техничеси, возможно реализовать OPC UA и на HTML5 — вебсокетах и java script'е. Не знаю, есть ли готовые рализации.
GUI в любом случае придется описать, сами SDK никаких визуальных компонентов не содержат.
Промышленная автоматизация инертна, но этому есть одно важное объяснение — безопасность.
Честно говоря, мне вообще не понятно зачем системы АСУ ТП подключать к интернету? Для того, чтобы крутой начальник мог на мнемосхемы из своего домашнего туалета посмотреть? Это бред. Система АСУ ТП должна быть изолирована от всяких там интернетов. А касательно SCADA систем, можно сказать, что использование их аргументированно только тогда, когда сам технологический объект мал и относительно безопасен. Навряд ли вам кто-то разрешит поставить скаду на нефтеперерабатывающий завод. Я честно говоря против передачи данных по модбасу и другим типовым протоколам, лучше большинство сигналов подключать к ПЛК напрямую, жесткопроводно, это во много раз увеличивает надежность и безопасность объекта.
Честно говоря, мне вообще не понятно зачем системы АСУ ТП подключать к интернету? Для того, чтобы крутой начальник мог на мнемосхемы из своего домашнего туалета посмотреть? Это бред. Система АСУ ТП должна быть изолирована от всяких там интернетов. А касательно SCADA систем, можно сказать, что использование их аргументированно только тогда, когда сам технологический объект мал и относительно безопасен. Навряд ли вам кто-то разрешит поставить скаду на нефтеперерабатывающий завод. Я честно говоря против передачи данных по модбасу и другим типовым протоколам, лучше большинство сигналов подключать к ПЛК напрямую, жесткопроводно, это во много раз увеличивает надежность и безопасность объекта.
Честно говоря, мне вообще не понятно зачем системы АСУ ТП подключать к интернету? Для того, чтобы крутой начальник мог на мнемосхемы из своего домашнего туалета посмотреть? Это бред.
Конечно напрямую подключать АСУ ТП в интернет — бред. Но вот вытягивать необходимые параметры с узлов в систему более высокого уровня, последующая их обработка и предоставление данных через веб-портал для обзора работы предприятия как единого целого, интеграция с ERP системами, и т.д — на настоящий момент актуальная задача. Я видел в ГазПромНефть прекрасный веб -портал которым пользовались практически все сотрудники предприятия и он действительно был нужен и полезен. И на нефтеперерабатывающих заводах РСУ интегрируют с системами MES уровня и организуют нечто подобное. Только системы на базе PI System работают оооочень коряво на мой взгляд, а вод веб решения куда более позитивно воспринимаются пользователями.
> Конечно напрямую подключать АСУ ТП в интернет — бред.
Почему бред? Вот есть к примеру кустовые установки на севере. Все из себя такие автономные, по ModBus с диспетчерской через радиоканал общаются. Но вот в прошивке завелась бага «sometimes» — непонятные коллизии, таймауты и прочее. Нужно слать в коммандировку инженеров тысяч за 70 — 80 на человека, чтоб диагностическую инфу по RS232 вычитать и перезалить обратно подправленный конфиг.
А ведь ModBus для того и разрабатывался, чтоб абстрагируясь от транспортного уровня осуществлять коммуникацию через что угодно. Диспетчерская интернетом обеспечена, кусты обеспечены связью с диспетчерской. Почему бы не проводить сервис удаленно?
Почему бред? Вот есть к примеру кустовые установки на севере. Все из себя такие автономные, по ModBus с диспетчерской через радиоканал общаются. Но вот в прошивке завелась бага «sometimes» — непонятные коллизии, таймауты и прочее. Нужно слать в коммандировку инженеров тысяч за 70 — 80 на человека, чтоб диагностическую инфу по RS232 вычитать и перезалить обратно подправленный конфиг.
А ведь ModBus для того и разрабатывался, чтоб абстрагируясь от транспортного уровня осуществлять коммуникацию через что угодно. Диспетчерская интернетом обеспечена, кусты обеспечены связью с диспетчерской. Почему бы не проводить сервис удаленно?
По соображениям безопасности, я бы не стал так делать. Да и не дадут. Все таки отображение данных через интернет это одно, а вот управление и конфигурация это совсем другое дело.
Даже давать возможность только отображения данных через интернет, я бы не рекомендовал для большинства малых и средних АСУ ТП. А уж давать возможность переконфигурировать систему через интернет — это вообще неприемлемо для отрасли промышленной автоматизации.
SCADA это же «supervisory control and data acquisition». Т.е. высокоуровневый контроль и сбор данных. Никто не делает управление исполнительными механизмами непосредственно от ПК с SCADA-системой :)
И как раз НЕиспользование SCADA аргументировано для малых объектов, где можно обойтись парой кнопочек и цифровых индикаторов (как максимум — операторской панелью с графическим экранчиком).
И как раз НЕиспользование SCADA аргументировано для малых объектов, где можно обойтись парой кнопочек и цифровых индикаторов (как максимум — операторской панелью с графическим экранчиком).
Какой КОШМАР!
Данная статья может являться замечательным примером того, как люди не понимают разницы между стандартами и технологиями.
Это звучит примерно как «Зачем нам HTTP, он закрытый (описан в каких-то RFC, которых я никогда не читал). У него куча недостатков. Поэтому вместо него мы лучше будем использовать UDP. Он открытый, в пакетах можно отправлять что угодно...»
Так вот, немножко про OPC:
1. Стандарт OPC UA существует (в разных вариантах) уже 4 года
2. Он кросс-платформенный, включая бинарные протоколы. (Поддержка их крайне важна для разработчиков PLC, да и прочего совместимого оборудования)
3. Он расширяемый (при необходимости, стандартным образом)
4. Он поддерживается огромным количеством производителей, включая таких не специфичных для промавтоматизации как SAP
5. Для совместимости со старыми версиями существуют «преобразователи», которые могут быть использованы для конверсии из UA в Classic и обратно.
6. Стоимость членства в OPC Foundation — от 500 долларов в год
7. Уже существует множество SDK, в том числе и открытых
Вы там выше в комментариях упоминали про интеграцию… Так вот, запомните на всю свою последующую жизнь — стандартизация протоколов обмена данными является абсолютно необходимым требованием для успешной интеграции больших систем. А не «зато мы можем писать любые данные которые нам взбредет в голову».
Кстати, именно поэтому в OPC используется SOAP, а не REST. В REST на сегодня даже нет единого формата описания схемы ресурсов (несколько черновых и недоделанных — не в счет).
Данная статья может являться замечательным примером того, как люди не понимают разницы между стандартами и технологиями.
Это звучит примерно как «Зачем нам HTTP, он закрытый (описан в каких-то RFC, которых я никогда не читал). У него куча недостатков. Поэтому вместо него мы лучше будем использовать UDP. Он открытый, в пакетах можно отправлять что угодно...»
Так вот, немножко про OPC:
1. Стандарт OPC UA существует (в разных вариантах) уже 4 года
2. Он кросс-платформенный, включая бинарные протоколы. (Поддержка их крайне важна для разработчиков PLC, да и прочего совместимого оборудования)
3. Он расширяемый (при необходимости, стандартным образом)
4. Он поддерживается огромным количеством производителей, включая таких не специфичных для промавтоматизации как SAP
5. Для совместимости со старыми версиями существуют «преобразователи», которые могут быть использованы для конверсии из UA в Classic и обратно.
6. Стоимость членства в OPC Foundation — от 500 долларов в год
7. Уже существует множество SDK, в том числе и открытых
Вы там выше в комментариях упоминали про интеграцию… Так вот, запомните на всю свою последующую жизнь — стандартизация протоколов обмена данными является абсолютно необходимым требованием для успешной интеграции больших систем. А не «зато мы можем писать любые данные которые нам взбредет в голову».
Кстати, именно поэтому в OPC используется SOAP, а не REST. В REST на сегодня даже нет единого формата описания схемы ресурсов (несколько черновых и недоделанных — не в счет).
Уважаемый, я не в коем случае не хотел Вас пугать)
Я прекрасно понимаю разницу между стандартами и технологиями. Согласен, даже с тем что заголовок звучит не совсем корректно, верно что REST это технология, а OPC протокол. Но если бы я написал по другому, не думаю что из названия можно было бы понять о чем речь.
Насчет, вашего «отеческого совета», я хотел, что бы вы внимательней еще раз прочитали, что здесь написано… речь идет о создании, как раз таки, такого стандарта, причем открытого, на базе более легковесной технологий. Я лишь представляю идею над которой работаю. Не надо оскорбляться)
У REST нет описания схемы ресурсов потому, что это задача уровня приложения. Так же, как в SOAP не описана симантика процедур. OPC UA как раз ее и описывает, я же предлагаю идею стандарта, который описывает схему ресурсов REST под задачи автоматизации.
Я прекрасно понимаю разницу между стандартами и технологиями. Согласен, даже с тем что заголовок звучит не совсем корректно, верно что REST это технология, а OPC протокол. Но если бы я написал по другому, не думаю что из названия можно было бы понять о чем речь.
Насчет, вашего «отеческого совета», я хотел, что бы вы внимательней еще раз прочитали, что здесь написано… речь идет о создании, как раз таки, такого стандарта, причем открытого, на базе более легковесной технологий. Я лишь представляю идею над которой работаю. Не надо оскорбляться)
Кстати, именно поэтому в OPC используется SOAP, а не REST. В REST на сегодня даже нет единого формата описания схемы ресурсов (несколько черновых и недоделанных — не в счет)
У REST нет описания схемы ресурсов потому, что это задача уровня приложения. Так же, как в SOAP не описана симантика процедур. OPC UA как раз ее и описывает, я же предлагаю идею стандарта, который описывает схему ресурсов REST под задачи автоматизации.
Являюсь разработчиком собственной СКАДА-системы.
Готов принять участие в поддержке этого стандарта в своей СКАДА-системе! Где качать библиотеки, примеры и тестовые имитаторы для проверок? :)
Готов принять участие в поддержке этого стандарта в своей СКАДА-системе! Где качать библиотеки, примеры и тестовые имитаторы для проверок? :)
У меня OPC в дипломе фигурировал, хоть и ужасно тяжеловесный и местами нелогичный на первый взгляд но это промышленный стандарт.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Технология REST вместо OPC в системах промышленной автоматизации