PLC vs PC-based

[Михайло]

Конечно это слабость. Там и другие слабости выявятся помимо технических характеристик самого ПЛК. Ведь еще есть такие вещи как панели, привода, сетевое оборудование.... У Сименса на эту тему есть "Все Сразу В Автоматизации Портал"!

[MuadDib]

В жизни нет ничего идеального. Вот у связки ICP DAS + ISaGRAF 3 плюсы:
1. Дешевизна.
2. Поддержка распространенных протоколов (Modbus RTU master, Modbus RTU (TCP) slave, DCON). Соответственно, можно прикрутить поддерживающие эти протоколы дополнительные устройства, включая HMI-панели и привода
3. Достаточно мощный язык программирования ST, на котором можно реализовать вещи типа неподдерживаемых таргетом протоколов обмена.
Но есть и существенные минусы:
1. Нет нормальных средств для создания распределенной системы управления. Очень бедные средства для взаимодействия между контроллерами, с распределенной периферией тоже не все гладко.
2. То, что протоколы обмена разрабатывать можно, не значит, что все это делается легко и непринужденно. Особой гибкости не наблюдается.
3. Несмотря на то, что железо помощнее чем, например, у Сименс S7, время цикла у ISaGRAF проигрывает однозначно. Ни в какое сравнение с истинным PLC не идет. Интерпретатор однако...

Мораль: ICP/ISaGRAF подойдет для небольшой локальной системы управления, где отсутствуют жесткие требования к времени цикла. Традиционный PLC подходит для всего спектра задач АСУТП. У всех PLC тоже есть недостатки, но, в целом, они более универсальны и более надежны. Поэтому сталкивать железо от ICP DAS лбами с PLC смысла нет никакого. Конечно, может быть и есть такие PC-based решения, которые могут посоревноваться с S7, Omron, Allen Bradly и т.п. на их поле, но мне они не известны.

[Михайло]

Вот у связки ICP DAS + ISaGRAF 3 плюсы:
1. Дешевизна.
2. Поддержка распространенных протоколов (Modbus RTU master, Modbus RTU (TCP) slave, DCON). Соответственно, можно прикрутить поддерживающие эти протоколы дополнительные устройства, включая HMI-панели и привода
3. Достаточно мощный язык программирования ST, на котором можно реализовать вещи типа неподдерживаемых таргетом протоколов обмена.

Уверяю Вас, многие не найдут в этих плюсах ничего положительного или отрицательного... Все эти плюсы могут быть и у обычных ПЛК.

[MuadDib]

Уверяю Вас, многие не найдут в этих плюсах ничего положительного или отрицательного... Все эти плюсы могут быть и у обычных ПЛК.

Приведите пожалуйста пример таких ПЛК.

[Василий Иванович]

Про деньги говорить не буду, ибо цена железа - это еще не всё ТСО, но всё остальное есть у того же S7 - и SCL, и поддержка Модбусов всяких, и возможность разработки драйверов нестандартных протоколов.

[Михайло]

У корейской конторы есть куча китайских конкурентов типа Fatek, да и S7-1200 недорог, если уж головой подумать. Модбасом сейчас никого не удивишь, даже Сименс. DCON наверное погорячились распространенным протоколом называть... Мощный язык ST - ну мощный он или не мощный, кому-то он и не нужен вовсе, у Сименса он в виде SCL пожалуйста. Протоколы обмена писать - это скорее ошибка разработчика в выборе оборудования, а вообще можно на любом языке написать этот обмен.
Как видите, плюсов-то нет.

[Alexander]

Да, кстати, упомянутый Fatek на все 100% соответствует по всем трем пунктам. Только что нестандартные протоколы будут реализованы стандартными функциями. Правда, и одна контора, и другая - Тайвань.

[Владимир Кузнецов]

А почему Вы не можете допустить, что имеют право на существование оба продукта? Задачи у всех очень разные, средства достижения тоже могут быть разные. А преимуществ PAC перед PLC в своей отрасли не вижу. Да и систем DCS у IСP DAS тоже вроде нет.

Да я и не пытаюсь их разделять, я за то что бы в каждом конкретном случае применять систему, которая наиболее подходит.
Я за адекватность и практичность, просто мне уже несколько раз сделали замечание по поводу "PC-based", что и вызвало недоумение.

[Владимир Кузнецов]

Это про ISaGRAF или про CoDeSys?

Без разницы. Под них делают контроллеры только слабые компании. В этом тупик и состоит.

ABB использует CoDeSys, ABB - слабая компания?
Овен использует CoDeSys - с ними тоже больше не работаем?
"ICS Triplex ISaGRAF is a Rockwell Automation Company" - Rockwell тоже в топку.

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

Это чем то похоже на движение по написанию своей ОС или SCADA - разумно ли это?

У Сименса на эту тему есть "Все Сразу В Автоматизации Портал"!

Предлагаете всем целиком перейти на Сименс?
А как же тогда конкуренция?
ТИАПортал, кстати, плохой пример - какой год уж пишут, а пока даже базового функционала нет, который был в предыдущих версиях степ7 (полной поддержи языков, симуляции).
P.S. Сименс не брезгует использовать OpenSource в своих продуктах.

[Владимир Кузнецов]

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

Вроде бы и плохо, что производитель сам всё это не предоставил, но возможность сделать по своему тем не менее есть.
Всё будет уже зависеть от квалификации разработчика (интегратора).

3. Несмотря на то, что железо помощнее чем, например, у Сименс S7, время цикла у ISaGRAF проигрывает однозначно. Ни в какое сравнение с истинным PLC не идет. Интерпретатор однако...

Вот тут будет интересно остановиться подробнее:
1) мы в обоих случаях имеем интерпретаторы.
2) какие конкретно модели сравниваем?
3) как меряем?

ISaGRAF заявляют, что у них для х86 таргетов реализована JIT-компиляция, что должно поднять производительность МЭК языков до уровня компилируемого Си.

У всех PLC тоже есть недостатки, но, в целом, они более универсальны и более надежны.

Есть статистика отказов?

[Владимир Кузнецов]

Да, кстати, упомянутый Fatek на все 100% соответствует по всем трем пунктам.

Добавить Фатэку ISaGRAF или CoDeSys и стало бы совсем хорошо.
А так боязно его брать.

[Alexander]

Да у него, у Фатек, и так достаточно навороченный функционал того, что есть. И LD у него не просто LD, а в сочетании с SFC и чутка от FBD. Но не встречал такой компактной и с такими возможностями (при таком объеме, есессно) оболочки у других производителей. Еще плюс - бесплатно.

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

[VADR]

P.S. Сименс не брезгует использовать OpenSource в своих продуктах.

Среди OpenSource весьма много продуктов, которые могли бы быть весьма полезны в АСУТП-шных применениях.
К примеру, есть у всех производителей ПО какое-то средство хранения проектов. От самых простых (запись в файл) до более навороченных (с контролем версий и прочими фишками). Однако не раз и не два встречался с ситуациями, когда смена версии инженерного ПО ставит крест на совместимости со старыми проектами. Почему для этого не использовать, к примеру, git?
Или другой пример: резервное копирование. Есть bacula, до функционала которой пока никакой проприетарный софт не дошёл. Почему бы не использовать? Не понимаю...

[Владимир Кузнецов]

Почему бы не использовать? Не понимаю...

Люди не понимают модель бизнеса опенсорс, думают что раз бесплатно, значит плохо.
"Вот коммерческий софт, его профессионалы пишут, а бесплатный - студенты самоучки", так считают многие.
А нормальные разработчики просто помогают в развитии проектов и извлекают из этого прибыль.

[Marrenoloth]

Раз уж попер офтоп, предлагаю еще к ночи помянуть открытые проекты для хранения базы знаний aka wiki, багтрекеры и программы для управления проектами. По сумме неплохо помогают вне зависимости от контроллеров...

[Михайло]

"Вот коммерческий софт, его профессионалы пишут, а бесплатный - студенты самоучки", так считают многие.

Дело не в этом. У бесплатного софта нет стратегии развития. В любой момент ты можешь ждать тупиковое состояние, когда проект остановлен и т.п. Было скрупулезно подсчитано и выявлено, что разработка всех версий Windows вышла по деньгам дешевле, чем разработка всех Линуксовых систем. Ну это просто для примера.
Ну и просто повторяю: сейчас все серьезные конторы создают программные продукты типа TIA Portal, CX-One и т.д., которые объединяют все продукты автоматизации (ПЛК, панели, приводы) на единой платформе. Если ты решил связать судьбу только с контроллерами, то опенсорс - пожалуйста. Но многим с тобой не по пути.

[VADR]

"Вот коммерческий софт, его профессионалы пишут, а бесплатный - студенты самоучки", так считают многие.

Дело не в этом. У бесплатного софта нет стратегии развития.

Что есть стратегия развития? План вытряхивания денег из конечного пользователя? Пример: есть у меня на одном из участков система, в которой операторский интерфейс и инженерная станция собраны на компах под win 2000. Система 2002-го года. Софт той версии официально не поддерживает XP и выше (хотя экспериментально проверяли - на XP работает, а на win 7 - нет). Если сдохнет железо - найти новое с поддержкой w2k по драйверам - проблема. Даже XP скоро станет проблемой. Что делать? Обновление версии до новой стоит очень красивых денег, при чём новые возможности этой новой версии остаются невостребованными: единственная причина апгрейда - несовместимость ОС с новым железом... Это и есть стратегия развития - выжимание денег из воздуха?

В любой момент ты можешь ждать тупиковое состояние, когда проект остановлен и т.п.

А проприетарные проекты не уходят в тупик и не останавливаются? Кто сейчас вспомнит, к примеру, windows millenium? Только вот положение конечного пользователя такого проекта по сравнению с пользователем закрытого опенсорсного - весьма плачевно. На опенсорсе можно заново проект поднять новой группой разработчиков, можно поковыряться самостоятельно и продлить дальнейшую совместимость... да и "закрыть" опенсорсный проект значительно сложнее.

Было скрупулезно подсчитано и выявлено, что разработка всех версий Windows вышла по деньгам дешевле, чем разработка всех Линуксовых систем. Ну это просто для примера.

Даже если так (хотя верится с трудом - считали спецы из MS?), о чём это говорит? Да ни о чём абсолютно.

Ну и просто повторяю: сейчас все серьезные конторы создают программные продукты типа TIA Portal, CX-One и т.д., которые объединяют все продукты автоматизации (ПЛК, панели, приводы) на единой платформе. Если ты решил связать судьбу только с контроллерами, то опенсорс - пожалуйста. Но многим с тобой не по пути.

Что мешает в таких системах "всё в одном" использовать открытые компоненты? Большинство открытых проектов - кроссплатформенные, работают в том числе и на windows. Основная идея - любое ПО выполняет одну задачу, но делает это очень хорошо. В отличие от изобретённых вновь велосипедов с квадратными колёсами :) Блин... не раз уже сталкивался и офигевал: "Ведь всё это уже есть! Вот оно: разработано, проверено, отлажено, работает.. бери да пользуйся!"

PS: Каюсь, сам увёл тему в оффтоп, а сейчас, похоже, перевожу в холивар... :(

[MuadDib]

Давненько не следил за темой, поскольку был занят :(
Во-первых, спасибо всем откликнувшимся на мой пост. Fatek, похоже, действительно интересное железо. Насколько я понял, он поддерживает работу в режиме Modbus TCP Master, что критично для наших разработок. Будем посмотреть :)

Вот тут будет интересно остановиться подробнее:
1) мы в обоих случаях имеем интерпретаторы.
2) какие конкретно модели сравниваем?
3) как меряем?

1. согласен.
2. С моей стороны - наиболее распространенный в нашей системе контроллер i7188eg 40MHz
3. Среда разработки предоставляет "текущее" и "максимальное" время цикла

Упомянутый контроллер, хорошенько нагруженный алгоритмами и обменом с Modbus RTU слейвами, может иметь цикл 200мс и более. Системы на S7-300, с которыми мне приходилось иметь дело, имеют существенно более короткие циклы. Причем нет никакой уверенности, что на каждом цикле ISaGRAF обновляется информация со всех слейвов. Одни догадки. В нашем случае все это некритично, но для многих задач может быть неприемлемо.

ISaGRAF заявляют, что у них для х86 таргетов реализована JIT-компиляция, что должно поднять производительность МЭК языков до уровня компилируемого Си.

Я говорил об ISaGRAF 3. Ничего не слышал о применении JIT-технологии в данном продукте. Не поделитесь ссылкой?

Есть статистика отказов?

Железо надежное. У нас около двух десятков контроллеров, за все время эксплуатации (более 5 лет с постепенным вводом новых узлов) был один дохлый контроллер i8437 (изначально получен таким от поставщика, заменили его по гарантии).
У нас также параллельно эксплуатируется система иного рода, с аналогичным железом и сопоставимым количеством узлов (но без ISaGRAF и прочих АСУТПшных софтин). Там условия более тяжелые (блоки питания попроще, используется RS-232 и т.д.) В этой системе бывают отказы с периодичностью раз в несколько месяцев. В основном дохлые порты, что зачастую лечится заменой соответствующей микрухи.
А вот с косяками ISaGRAF все похуже. В упомянутой системе иногда прекращается обмен с Modbus слейвами без видимых причин и без выставления признака недостоверности. Причем, с какими-то слейвами обмен может идти, а с какими-то - нет. Лечится перезагрузкой контроллера. Случается приблизительно раз в месяц на одном из контроллеров системы. В нашем случае это не критично, но очевидно, чем чреваты такие выкрутасы в ответственной системе управления...

[Serex]

Классическая схема АСУТП:
датчики - PLC-контроллер - OPC-сервер - SCADA (+среда программирования контроллера + конфигуратор датчиков)
И что-то пока не вижу серьезных попыток это перевернуть. Попыток то конечно много, но все они так...
А PC-based - это скорее от лукавых продавцов.
Я сам постоянно рассуждаю, где бы сэкономить в той схеме.
Когда автоматизируешь завод, там понятно, что нужна полная схема со всеми продуктами.
Но ведь иногда хочеться сделать пару датчиков на промышленном железе, и для этого нужно покупать все продукты сразу, а это дорого.
Получается либо завод, либо ничего - и это не романтично ))
Вот для таких целей и придумывают PC-based контроллеры
Но это одна причина.
Бывает хочется воткнуть в PLC флэшку 16гБ за 800руб, писать туда архивы и раз в неделю снимать в виде таблицы отчеты.
Так вот к тем, кто так хочет приходят на помощь PC-based )) Опять же по причине экономии, так как разворачивать классическую схему дороговато.
Вообщем PC-based - это от экономии ))

[Владимир Кузнецов]

2. С моей стороны - наиболее распространенный в нашей системе контроллер i7188eg 40MHz

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

3. Среда разработки предоставляет "текущее" и "максимальное" время цикла

Замерять нужно на одинаковых задачах, например придумать тестовый проект.
По времени цикла можно сделать грубые сравнения, ориентировочные (когда разница на порядок, то и этого конечно хватит).
Для более детального исследования производительности, я бы сделал тестовый стенд, который позволил бы измерить время реакции системы на событие.
Например точно замерить время от момента поступления сигнала на DI и до момента срабатывания DO.
Это особенно полезно в случае распределённой периферии (связанной с блоком CPU кабелем).

Упомянутый контроллер, хорошенько нагруженный алгоритмами и обменом с Modbus RTU слейвами, может иметь цикл 200мс и более. Системы на S7-300, с которыми мне приходилось иметь дело, имеют существенно более короткие циклы. Причем нет никакой уверенности, что на каждом цикле ISaGRAF обновляется информация со всех слейвов. Одни догадки. В нашем случае все это некритично, но для многих задач может быть неприемлемо.

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

Я говорил об ISaGRAF 3. Ничего не слышал о применении JIT-технологии в данном продукте. Не поделитесь ссылкой?

JIT появился только в ISaGRAF 5 (и там похоже всё гораздо интереснее чем я думал :))
Как я понял, все вкусности (ISaGRAF 5 и расширения) есть только для LinPAC, сам ICPDAS предлагает только ISaGRAF 3.
Но в случае ICPDAS на ISaGRAF 5 с JIT свет клином не сошёлся, для критических приложений можно задействовать Си.

А вот с косяками ISaGRAF все похуже. В упомянутой системе иногда прекращается обмен с Modbus слейвами без видимых причин и без выставления признака недостоверности. Причем, с какими-то слейвами обмен может идти, а с какими-то - нет. Лечится перезагрузкой контроллера. Случается приблизительно раз в месяц на одном из контроллеров системы. В нашем случае это не критично, но очевидно, чем чреваты такие выкрутасы в ответственной системе управления...

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

[Владимир Кузнецов]

У бесплатного софта нет стратегии развития.

1) Как то я не уловил момент, когда разговор на OpenSource и freeware перешёл :)
И ISaGRAF и CoDeSys ни тем, ни другим не являются.
2) Всё зависит от размера проекта - для микро проекта, созданного одним человеком для решения конкретной задачи оно может быть и справедливо.
Для крупных проектов, это неправда.

В любой момент ты можешь ждать тупиковое состояние, когда проект остановлен и т.п.

3) Всё с ног на голову перевёрнуто. На самом деле, для коммерческих (закрытых) проектов это более вероятно и гораздо более опасно для пользователя.
Если автор коммерческого ПО решит его прикрыть, то ты как пользователь уже ничего с этим не сделаешь.
Более того, в коммерческом проекте, разработчик может вынудить пользователей постоянно покупать новые версии, прекращая развивать старые.

Ну и просто повторяю: сейчас все серьезные конторы создают программные продукты типа TIA Portal, CX-One и т.д., которые объединяют все продукты автоматизации (ПЛК, панели, приводы) на единой платформе.

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

[Владимир Кузнецов]

Пример: есть у меня на одном из участков система, в которой операторский интерфейс и инженерная станция собраны на компах под win 2000. Система 2002-го года. Софт той версии официально не поддерживает XP и выше (хотя экспериментально проверяли - на XP работает, а на win 7 - нет). Если сдохнет железо - найти новое с поддержкой w2k по драйверам - проблема. Даже XP скоро станет проблемой. Что делать? Обновление версии до новой стоит очень красивых денег, при чём новые возможности этой новой версии остаются невостребованными: единственная причина апгрейда - несовместимость ОС с новым железом...

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

[Владимир Кузнецов]

Вообщем PC-based - это от экономии ))

Не соглашусь.
PC-based это в первую очередь гибкость.
PC-based удобно использовать в законченных продуктах.
PC-based + ISaGRAF / CoDeSys ничем не уступают классическому PLC.

[Михайло]

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

PC-based это в первую очередь гибкость.
PC-based удобно использовать в законченных продуктах.

Вы не отражаете, что говорите. Какая блин гибкость? Все проектировщики настолько оловянные, что некоторым хватает даже Овна. Зачем гибкость? Что она дает? Зачем? Зачем? Зачем?
Если нужна гибкость - выбирайте Сименс, АББ. А если хотите вечного мозготраха, то к Вашим услугам - тысячи мелких производителей. Вот такой парадокс.

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

Так говорят люди, которые никогда не видели полную стоимость создания АСУТП, систем автоматизации и результатов их эксплуатации.

На самом деле у всех есть абсолютно равнозначный выбор:
1. Дешевое дерьмо
2. Дорогое качество

И люди выбирают под себя.

[Владимир Кузнецов]

На самом деле у всех есть абсолютно равнозначный выбор:
1. Дешевое дерьмо
2. Дорогое качество

Так говорят люди, которые везде суют сименс подороже и получают не кислый гешефт на поставке ;)
И тут есть как минимум третий вариант:
3. Дорогое дерьмо (потому что как вы систему запрограммируете, так она и поплывёт)

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