мастерскада 4

[Serex]

До тех пор, пока ПО привязано к железу, а автоматизация производства на 95% железные конфигурации - никакой смерти PLC не намечается даже.
Красиво рассуждать об интеллектуальных датчиках, но как начинаешь смотреть на них цены - "Че блин за космические технологии?".
Как не толкай колесо прогресса, а по пути повышения цены оно не поедет. Именно так оно получается и в связке ПК-ПЛК.

Почему ПК должен занять нишу ПЛК? Я скорее поверю в какой-нибудь Arduino. Он избавлен от всяких лишних ПО - чистое железо заточенное под задачу с минимально необходимым ПО. И самое важное! - в 100-1000 раз энергоэфективнее какого-то ПК.

[megavolt86]

Я скорее поверю в какой-нибудь Arduino. Он избавлен от всяких лишних ПО - чистое железо заточенное под задачу с минимально необходимым ПО. И самое важное! - в 100-1000 раз энергоэфективнее какого-то ПК.

+1

[greatvict]

А вот есть такая штука у Семёна - WinAC (http://dfpd.siemens.ru/products/automat ... ed/win_ac/).

Да, кстати. Почти в каждой среде программирования контроллеров есть реализация исполнительной системы под Windows. Она может использоваться как для отладки, так и для реальной работы. У нас такая вещь называется MasterLogic и идет как опция к скаде. Используется в тех случаях, когда пользователь не хочет ставить OPC, а напрямую использовать те драйвера, что есть в нашей исполнительной системе для контроллеров. И есть реальные проекты в диспетчеризации, где к компьютеру через преобразователи интерфейсов подключена сотня портов, на которых висят какие-нибудь счетчики. Так что не везде нужна высокая надежность и большое быстродействие.

в виде докер-контейнера

Ну вот например на облачном Linux сервере для демо-проектов sky-monitor крутятся 20 копий исполнительной системы, каждая со своим проектом и ресурсов потребляют не очень много. Так что одно из преимуществ универсальной системы - ее компактность, так как необходимость работы на широком спектре устройств побуждает писать более компактный и эффективный код.

[greatvict]

Почему ПК должен занять нишу ПЛК? Я скорее поверю в какой-нибудь Arduino. Он избавлен от всяких лишних ПО - чистое железо заточенное под задачу с минимально необходимым ПО. И самое важное! - в 100-1000 раз энергоэфективнее какого-то ПК.

Ну я то как раз не говорил, что ПК заменит ПЛК, а скорее наоборот - в виду активного развития ARM процессоров и устройств на их базе появляется возможность переложить на них часть функций SCADA. И в ряде случаев это может привести к тому, что в качестве АРМ можно использовать тонкие клиенты, причем не обязательно на базе ПК, но и на планшетах, мобильных устройствах. А часть задач вообще вынести на облачный сервер (например, долгосрочное хранение архивов). В этом случае и администрирование упрощается всего этого хозяйства.

[MuadDib]

greatvict,

Я правильно понимаю, что в основе Мастерскада 4 - полностью кроссплатформенный рантайм с визуализацией исключительно через веб-интерфейс?

И вот еще что интересно. Как рантайм хранит данные трендов и алармов? Своя система хранения или можно использовать какую-нибудь стандартную СУБД?

На sky-monitor.ru все красиво, но хотелось бы почитать какую-нибудь брошюру с описанием структуры системы, с предполагаемыми use case-ами и т.д. Можно что-то подобное где-то скачать?

[Siluet]

Почему ПК должен занять нишу ПЛК? Я скорее поверю в какой-нибудь Arduino. Он избавлен от всяких лишних ПО - чистое железо заточенное под задачу с минимально необходимым ПО. И самое важное! - в 100-1000 раз энергоэфективнее какого-то ПК

- если Arduino заточить под конкретную задачу, то оно будет интеллектуальным устройством - датчиком с функцией управления и сетевым устройством. Если использовать такую периферию, то функция работы с физическими сигналами(a/d, i/o) с ПЛК снимается. Если нужен быстрый регулятор - то он будет полевым устройством. А функцию централизованного управления системой в целом можно переложить любому вычислительному устройству, которого называйте как хотите - ПЛК, ПК. В это же вычислительное устройство можно перенести часть функция SCADA: обработка, аварийная сигнализация, локальное хранение. Функции долгосрочного хранения, анализа, выдачи отчетов, оповещение по e-mail удобнее отправить в облако или локальный ЦОД. А функцию HMI удобнее реализовать на телефонах, планшетах, тонких клиентах с большими мониторами.

[Romcheg]

А как быть с очень большим классом систем, которые в такой попе мира стоят, что там мобильный-то работает если в определенном секторе метр на метр стоять на одной ноге, и облака там только на небе? И это очень крупные системы и очень ответственные. Этот сектор для бизнеса становится не интересен?

[Jackson]

У компьютера отсутствуют клеммы для подключения индустриальных датчиков и исполнительных механизмов

Не клеммы отсутствуют, а такая возможность в принципе. Есть ПК и с клеммами. Модулей-то можно наставить и к обычному ПК и к промышленному - это не проблема. Только работать не будет.

[MuadDib]

Romcheg,
я так понимаю, что облако - лишь один из вариантов развертывания. Хочу - подписываюсь на их SaaS, хочу - покупаю лицензию и запускаю рантайм у себя. Просто в основе всего этого универсальное нативное ядро.

[greatvict]

Я правильно понимаю, что в основе Мастерскада 4 - полностью кроссплатформенный рантайм с визуализацией исключительно через веб-интерфейс?

Да. Визуализация или через штатные браузеры или через наши приложения-вьюверы (например для Android панели собрали webkit для полноэкранного отображения без лишних элементов управления, присущих стандартным браузерам)

И вот еще что интересно. Как рантайм хранит данные трендов и алармов? Своя система хранения или можно использовать какую-нибудь стандартную СУБД?

Сейчас используется sqlite как самая компактная БД и простая для сборки на разные платформы. Но потом появится поддержка и других БД.

На sky-monitor.ru все красиво, но хотелось бы почитать какую-нибудь брошюру с описанием структуры системы, с предполагаемыми use case-ами и т.д. Можно что-то подобное где-то скачать?

В самой системе, которую можно скачать с этого сайта есть проекты быстрого старта со справкой по ним, но справочная и методическая документация еще в стадии разработки, так как система постоянно дорабатывается, и справка не всегда поспевает за этим.

А как быть с очень большим классом систем, которые в такой попе мира стоят, что там мобильный-то работает если в определенном секторе метр на метр стоять на одной ноге, и облака там только на небе? И это очень крупные системы и очень ответственные. Этот сектор для бизнеса становится не интересен?

Если система крупная, то там может быть частное облако.

[VADR]

не-не-не... управление технологией отправлять в облака - ну его нафиг. Если только какой-нибудь обмен данными между удалёнными предприятиями. И то - стрёмно. Доверять ответственные вопросы сервису, который не можешь контролировать - стрёмно.

[greatvict]

Доверять ответственные вопросы сервису, который не можешь контролировать - стрёмно.

А кто говорит, что его нельзя контролировать? Есть разные подходы к организации такого сервиса. Можно арендовать у провайдера выделенный или виртуальный сервер и на нем самостоятельно установить систему. Можно вообще у себя в офисе разместить его.

[Jackson]

Если система крупная, то там может быть частное облако.

не-не-не... управление технологией отправлять в облака - ну его нафиг.

А надо посчитать, что получится по отказоустойчивости. И нужно говорить конкретно, какую технологию отправляем в облако а какую оставляем локально. И тогда, уверен, найдутся применения и для таких систем. ЖКХ например.

Можно арендовать у провайдера выделенный или виртуальный сервер и на нем самостоятельно установить систему.

Но канал связи выделенным Вы никак не сможете сделать. Поломать БС оператора может кто угодно. И даже если Вы арендуете выделенный сервер - это сервер у хостера, он накроется точно также как и невыделенный. Аренда сервера делается не для отказоустойчивости, а для гарантированной производительности.

Пока что я вижу прекрасное применение для таких систем - например диспетчеризация инфраструктуры зданий, когда например три десятка домов раскиданы по всему городу. Диспетчеризация лифтового хозяйства туда же. Можно это сделать и без облака, но по сути не будет никакой разницы, а покупая облачное решение исполнитель снимет с себя головную боль по организации сбора данных, правза пользователю придётся в случае сбоев обращаться не в одну контору (исполнитель) а в две (ещё и провайдер).

Отправлено спустя 38 минут 1 секунду:
А частное облако - это по сути тот же центральный сервер сбора данных, который можно организовать и обычным классическим образом. Всё равно ведь придётся организовывать линии связи что до сервера сбора данных что до облака - без разницы.

Тут просто надо считать отказоустойчивость и кап.затраты, может и правда применить готовое частное облако будет не хуже чем построить классическую систему.

Но для ответственных систем это пока не решение.

[+] Вот мой пример из судовых систем

Так и просится организовать частное облако вместо классической КСУТС (комплексная система управления техническими средствами судна). По судну разбросаны самые разные системы (грузовая, балластная, топливная, электроэнергетическая, рулевая и так далее), и всё это надо отображать на мостике, а часто и использоать в управлении ещё в двух-трёх систем (пульт грузовых операций, какой-нибудь пульт буровых операций если судно, например, буровое, и т.д.). Логично было бы, чтобы все судовые системы скидывали информацию в частное облако, а пульты уже будут забирать и отображать то что нужно - какой экран на каком пульте выбрали - то и забираем.
Но нельзя.
Ибо сказано в Регистре,

Код: Выделить всё

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

Это следует понимать так. Обычно, скажем, система управления электродвижением (есть же и суда с электродвижением) связана с АСУ электроэнергетической системы (ЭС) напрямую, и получает информацию о текущем состоянии каждого генератора, о суммарной нагрузке и суммарном резерве мощности в электроэнергетической системе. Если рвётся один провод и из АСУ ЭС в АСУ электродвижения перестаёт поступать информация о текущем резерве мощности - это допустимо, т.к. функции АСУ электродвижения непосредственно зависят от функции АСУ ЭС. АСУ электродвижения управляет мощностью гребных двигателей, учитывая состояние электростанции - чтобы не перегрузить электростанцию. А если эти данные пойдут через облако, то получается что АСУ электродвижения непосредственно не зависит от АСУ ЭС, и тогда единичный отказ в ЭС и в АСУ ЭС не должны оказывать влияния на АСУ электродвижения, даже если полностью откажет вся система сбора данных (частное облако), а не просто 1 провод порвётся.
Никак не применить, получается. И поэтому на судне нет централизованной сети и сервера сбора данных - точнее такие сервера есть, но это только регистраторы данных рейса (чёрные ящики), данные с которых ни для чего не используются вообще, они просто хранятся. А пульт судоводителя представляет собой набор дистанционных панелей управления, АРМов и серверов (если требуется, но как правило нет) от всех судовых систем, каждый из этих АРМов и панелей связан только со своей системой. Иногда АРМы совмещаются (один АРМ для нескольких систем), но это очень осторожно - ибо требование отказоустойчивости. Степень ответственности функций (есть чёткие определения и перечень ответственных и неответственных функций) тут не играют никакой роли.

Я даже рекомендую запомнить эту формулировку отказоустойчивости и применять её, понимая дословно, если Вы хотите построить отказоустойчивую систему. Это правило действует в судостроении уже больше ста лет, и даже позаимствовано в авиацию и космос.

А там где такая отказоустойчивость не нужна - почему бы не закатать облако.

[Siluet]

что там мобильный-то работает если в определенном секторе метр на метр стоять на одной ноге, и облака там только на небе?

- значит инфраструктура не развита, мои редкие вылазки в места добычи газа приятно удивляют: станция повышения давления, одни болота в радиусе 25км, а на мобильнике youtube можно в высоком качестве смотреть.

не-не-не... управление технологией отправлять в облака - ну его нафиг.

Естественно, управление в реальном времени ни кто в облака не отправит, надежное хранение истории, отчеты и управление на основе статистических данных - самое то.

Аренда сервера делается не для отказоустойчивости, а для гарантированной производительности.

Отказоустойчивость в серверном оборудование - это не надежность самого оборудования, а мониторинг и своевременная замена оборудования, бэкап и оперативное восстановление из бэкапа. Облака администрируют и обслуживают профессионалы в своей области. Отказоустойчивость там на самом высоком уровне.

Но для ответственных систем это пока не решение.

- как раз для систем, где под ответственностью подразумевается надежное хранение истории.

[Serex]

Все эти облачные сервисы вроде как появились с массовой "гаджетизацией" и дешевым доступом в интернет. До этого оно как-то и не нужно было и пользовалось спросом только у веб-разрабов.
Соответственно для промышленной автоматизации также должно быть два условия
1. Потребность в объединении множества систем для их взаимодействия с целью обмена большим количеством данных, высоким трафиком.
2. Богатая сетевая инфраструктура

Для первого условия потребность только у SCADA систем и то для того чтобы создать высоконагруженный распределенный рантайм с десятками клиентов (у WinCC 7 при более 10 клиентах начинаются танцы с бубном.). Для самого процесса как правило достаточно полевой шины по которой гоняется пара десятков тегов.

Второе условие реализуется плохо, так как жесткие требования безопасности локализуют и минимизируют любые сети. А где-то вообще проблема подключения к интернету, как уже было сказано.

Итог: Облака в промышленной автоматизации - нет перспектив.

[MuadDib]

greatvict, спасибо за ответы! Интересно будет посмотреть на конечный продукт.

Радует, что Инсат решилась на кардинальную переделку основного продукта. Думаю, что в конечном итоге все от этого только выиграют.

Несколько лет назад господин Аблин на семинаре в нашем городе говорил, что спроса на кроссплатформенность нет. И речь тогда шла только о .Net решениях. А теперь все кардинально поменялось. Видимо, спрос появился. :)

Единственный момент, который у меня вызывает сомнения - это ориентация на WPF в среде разработки. Кроссплатформенное ядро и привязка к подсистеме, жестко зависящей от Microsoft-овской реализации .Net - это как-то странно. Есть же кроссплатформенные "плюсовые" фреймворки для GUI, тем паче что ядро тоже на "плюсах". Хотя, конечно, на WPF писать удобнее...

[MuadDib]

Все эти облачные сервисы вроде как появились с массовой "гаджетизацией" и дешевым доступом в интернет. До этого оно как-то и не нужно было и пользовалось спросом только у веб-разрабов.

Идея облачного сервиса появилась в 60-х. О вебе тогда еще никто и не слышал. ARPANET появилась позже. Правда, с реализацией тогда не задалось. Запилили масштабируемую отказоустойчивую ОС MULTICS, создали монстроузные мейнфреймы на ее основе, и на этом дело встало. Так что да, полноценно реализовали "облака" только в наше время. Хотя, машины на основе MULTICS ("частные облака" :) ) трудились на разные серьезные конторы до 90-х годов.

[greatvict]

Несколько лет назад господин Аблин на семинаре в нашем городе говорил, что спроса на кроссплатформенность нет. И речь тогда шла только о .Net решениях. А теперь все кардинально поменялось. Видимо, спрос появился. :)

Скорее речь шла о том, что АРМ на Linux не были особо востребованы. Но сейчас кстати даже в этом ситуация меняется, отчасти за счет импортозамещения. Но общая тенденция к переходу на платформонезависимые и web-ориентированные решения началась давно.
Еще раз резюмирую, что я понимаю под концепцией IoT/интернета вещей, применительно к АСУТП - за счет повышения производительности устройств нижнего уровня (контроллеров, модулей, исполнительных механизмов), а также перехода в них на открытые системы (например, Linux, что позволяет расширять их функционал за счет универсальный программных систем) появляется возможность организовывать более децентрализованные системы управления, где логика управления перераспределяется по возможности ближе к объекту управления. Это повышает отказоустойчивость и производительность системы в целом. Если например можно поместить алгоритм управления в сам исполнительный механизм, то он продолжит работать даже при отказе систем более верхнего уровня. А если алгоритму нужны данные от других систем, то правильнее, чтобы они напрямую передавались между исполнительными механизмами. Об этом кстати и говорилось выше -

Код: Выделить всё

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

А то, что нельзя переложить на нижний уровень, наоборот, отправляется наверх, в "облако" (например, хранение долгосрочных архивов, агрегирование данных из разных источников). И в таком подходе в качестве АРМ можно использовать тонкий клиент, в котором происходит навигация по устройствам нижнего уровня + подключение к облаку, когда необходимо получить данные с него.

Единственный момент, который у меня вызывает сомнения - это ориентация на WPF в среде разработки. Кроссплатформенное ядро и привязка к подсистеме, жестко зависящей от Microsoft-овской реализации .Net - это как-то странно.

ядро тоже на "плюсах"

На C++ сейчас только среда исполнения, она полностью отделена от среды разработки, и даже представление проекта разное (в DT проект хранится в БД, в RT используется байт-код для программ данного узла). То есть DT целиком на .Net, причем визуализация выделена в отдельный слой абстракции. Уже сейчас можно выполнять все операции над проектом только через объектную модель без загрузки интерфейса вообще (так например у нас организованы автоматические тесты среды разработки). То есть, учитывая, что сам .Net можно считать кроссплотформенным (сама Microsoft в последнее время активно занимается его переносом на Linux), то при необходимости портирования вопрос встанет только со слоем визуализации. Просто пока альтернатив для разработки UI сложных десктопных приложений кроме WPF не видно. И заранее неизвестно, что именно получит развитие в дальнейшем. Сейчас можно только сказать, что скорее всего развиваться в основном будут Web/HTML5 технологии, но в текущим их состоянии разработка весьма трудоемка. Еще следует учитывать, что использование развивающихся технологий при разработке может приводить к тому, что через несколько лет разработанное решение уже окажется недостаточно эффективным и его придется переделывать.
Еще один момент - хотя продукт в целом новый, но в него перенесены некоторые модули из MasterSCADA 3.x, например транслятор ST. Также в будущем сделаем поддержку в исполнительной системе .Net API, чтобы пользователи могли подключать к ней свои ФБ, в том числе написанные ранее для 3.x (заставлять всех переходить на C++ неразумно, особенно там, где нет нужды использовать их кроме как под Windows).

[Jackson]

Отказоустойчивость в серверном оборудование - это не надежность самого оборудования, а мониторинг и своевременная замена оборудования, бэкап и оперативное восстановление из бэкапа.

Мне как АСУТПшнику совершенно это всё неинтересно. Сервера падают, это случается - факт. А с причинами пусть хостер разбирается.

Облака администрируют и обслуживают профессионалы в своей области. Отказоустойчивость там на самом высоком уровне.

Это фраза для рекламного проспекта, а не для диалога специалистов, которые на самом деле понимают что к чему.

как раз для систем, где под ответственностью подразумевается надежное хранение истории

Априори не может быть гарантированно надёжным хранение данных в хранилище, которое мне не принадлежит.

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

Итог: Облака в промышленной автоматизации - нет перспектив.

Почему? У любого решения есть своя ниша применения. Если говорить об АСУТП цеха или завода - да, не перспектив. Но это не единственные типы АСТП, есть другие. Мы например тоже свой сервис делаем, на него есть спрос.

Еще раз резюмирую, что я понимаю под концепцией IoT/интернета вещей, применительно к АСУТП - за счет повышения производительности устройств нижнего уровня (контроллеров, модулей, исполнительных механизмов), а также перехода в них на открытые системы (например, Linux, что позволяет расширять их функционал за счет универсальный программных систем) появляется возможность организовывать более децентрализованные системы управления, где логика управления перераспределяется по возможности ближе к объекту управления.

Во-1-х вывод совершенно неверный, но это оставим. Во-2-х у всего есть свои стороны. Повышаете удобство - повышаете и геморройность, а часто снижаете надёжность. Вот и всё. Я ж объяснил, что есть уйма применений где так и просится, но нельзя.
Кроме того, это всё надо ещё и администрировать. Сисадмин в АСУТП - это новое слово (без иронии).

[Siluet]

Априори не может быть гарантированно надёжным хранение данных в хранилище, которое мне не принадлежит.

- это все равно что сравнивать наличные и безналичные деньги с учетом того, что эти деньги полезны только владельцу.
На счет надежности: 100% гарантии ни кто не даст, но если сравнивать локальное хранилище (которое может сгореть, быть затопленным, подвергнуться мех. разрушению, и быть трижды отформатированно криворуким администратором) и облачное хранилище (которое может находится одновременно в нескольких ЦОДах страны, автоматический бэкап на уровне хостера, бэкап самого пользователя, автоматическое горячее восстановление, более "аккуратное" отношение к оборудованию) - стоит задуматься.

Не надо тут доказывать надёжность и эффективность решения. Здесь не выставка - здесь специалисты, которые понимают как это всё работает. Специалистам надо дать максимум информации

- я всего лишь аргументированно опровергаю одностороннее мнение, что облака - это не надежно

[Jackson]

Неа, неаргументированно совершенно.