Если уж есть такая потребность в работе с частичными отказами, то разумнее продублировать датчики и поручить системе контроль за ними и выбор исправного. На это у меня уйдет минут 10. А алгоритмы вообще без датчиков сомнительны.

В срок разработки документацию я не включал. Хелп встроеный есть, правда корявый довольно=\
Обыграть работу с обрывами датчиков не очень сложно (с точки зрения программирования) опять же в симатиках есть функции диагностики исправности модулей и цепей датчиков, что сильно ускоряет процесс.


Не сказал бы что применение дублирующих систем для не очень ответственных потребителей (вроде систем общеобменной вентиляции) является оправданым(если конечно вся система не утыкана продуктом отечественного гения в виде датчиков ТСМ). Да и заставить систему работать в "безопастном" режиме при наличии неисправности проще помоему. Это определенно даст снижение комфортности, но не критичное (имхо).

Целесообразность определяется ТЗ, но всякие "безопасные" решения таковыми никак не являются. Например если у вас всего две защиты от замерзания, по обратке и канальной температуре, то например работа без канального термистора крайне опасна. У меня недавно был случай, когда звонит главный инженер одного из объектов и говорит, что одна из приточек встала по аварии канальной температуры. Хотя он сказал это и более делетански, мол бзынькнул диспетчерский комп и на канале одной из систем написал "Аварийная температура в канале". Как выяснилось, проводились какие то работы и нарушили провод питания насоса обвязки. Циркуляции нет, и по обратки защита не срабатывает. Тоже самое может быть, если что то забьет калорифер. Если у вас накрылся термистор на обратке, то как защищать зимой отключенную камеру? Опять таки, вы только можете предполагать, что насос работает и циркуляция есть, и что привод клапана работает...

Это был мой пост под именем Guest - с другой вирт. машины, а пароль забыл. Так вот, у S-300/400 - развитая система диагностики, но обработка ее сообщений - тоже еще то занятие. Обрыв провода насоса циркуляции ловиться "на раз", выдали бы диагностику - и все дела!!!. А SCADA и используется для как источник данных для fuzzy logic при отказе реального источника данных ( например, датчика канальной темп.).
Если внешние условия относительно стабильны, то состояние системы легко прогнозируемы. А при авариях SCADA просто незаменима как анализатор отчетов (можно без выезда на место), чтобы понять, что случилось.
Зачем Заказчика нервировать своим присутствием ? Да и труд наладчиков очень дорог ( найти неисправность). А заменить датчик или насос особого ума не надо. "Прямую" схему сделать легко-согласен, картинки нарисовать - еще легче, но это- не СИСТЕМА,
это - лабораторная установка, и рядом есть "умные и рукастые" дяди,
готовые мгновенно реанимировать свое творение.
Еще одна задачка - экономия тепла и электричества. Тут просто "непаханное поле".
Например, что выгоднее - снижать температуру вторичного контура ИТП для вентустановок
( до минимума, необходимого для поддержания канальной температуры) или снижать объем
подаваемого теплоносителя (ЧП на насосах)? А когда будет работать от электрокотлов ? А "привязать"
к охранке, чтобы менять режим при отсутствии людей, но и не перестараться с переключением.
Тут без отчетов SCADA просто не обойтись!!! Так что SCADA - это и инструмент разработчика, а не
просто "красивые картинки" для охмурения Заказчика.
г. ganin
Пока все встало не по моей вине. Пуско-наладка (по моему опыту) очень быстрая, т.к. все видно
и что не работает- тоже!!! Стоимость on-line help - я заложил стандартную - $100 за экран. Если честно,
то help формируется при написании документации. Конечно. Если Заказчику не нужна документация,
то тут- сложнее. Что касается алгоритмов работы при частичном отказе оборудования - то я настолько привык это делать за много лет, что мне сложнее НЕ ПИСАТЬ этого. Зато сильно впечатляет

Да можно даже горячий резерв контроллеров сделать, тоже не проблемма. И Скада только отразит, что произошла автоматическая смена контроллера. А про датчики и насосы и говорить нечего - плевое дело. Все определяет ТЗ.

ТЗ - это ТЗ, никто не спорит. Но в ТЗ, например, присутствует фраза "обеспечить температуру подаваемого воздуха 22 град." Но врядли там будет написано "при выходе из строя датчика температуры прекратить работу установки до замены датчика". Заказчику глубоко плевать, как будете обеспечивать. Понятно, что без теплоносителя или электроподогрева не получится зимой (физика!!!!),
а остальное - Ваши проблемы. А если Ваше решение такое, что чуть-что - и система "встает", то, значит,
вы предлагаете "лабораторную установку", а не "промышленную". К сожалению, Заказчик умнеет не по дням, а по часам (шутка ).
Если в к ТЗ приложите список неисправностей, при которых система "встает", то будет печальная картина, если - нет, Вас ждут другие неприятности.
Есть и другой момент. PLC на то и PLC, чтобы не просто переносить релейные схемы на его язык,
но и для того, чтобы формировать диагностику и отрабатывать нештатные ситуации, облегчив труд наладчика.

Заинтересовало . Насколько я понял, если вдруг датчик умер, то вы прогнозируете при неизменных условиях, что как бы он существует и все продолжает работать с каким то виртуальным датчиком, сделанным из отчетов. И как долго это работало? Может я не правильно понял, но для чего это? Не проще просто заменить. Я делаю просто рабочий режим и жизнеспособный. Не работает что то в рабочем режиме, переходит на аварийное поддержание сохранности оборудования. Что за система S300\400.

Добавлено - 11:22

Заинтересовало . Насколько я понял, если вдруг датчик умер, то вы прогнозируете при неизменных условиях, что как бы он существует и все продолжает работать с каким то виртуальным датчиком, сделанным из отчетов. И как долго это работало? Может я не правильно понял, но для чего это? Не проще просто заменить. Я делаю просто рабочий режим и жизнеспособный. Не работает что то в рабочем режиме, переходит на аварийное поддержание сохранности оборудования. Что за система S300\400.

Добавлено - 11:22

Заинтересовало . Насколько я понял, если вдруг датчик умер, то вы прогнозируете при неизменных условиях, что как бы он существует и все продолжает работать с каким то виртуальным датчиком, сделанным из отчетов. И как долго это работало? Может я не правильно понял, но для чего это? Не проще просто заменить. Я делаю просто рабочий режим и жизнеспособный. Не работает что то в рабочем режиме, переходит на аварийное поддержание сохранности оборудования. Что за система S300\400.

Речь шла про WinCC - у меня она однозначно ассоциируется с Siemens Step7 (S7 300/400). Я и подумал, что Сергей Долганов делал систему на них.
Никаких виртуальных датчиков - просто можно обойтись и без него,
если накоплена информация. Зачем это нужно - чтобы максимально сократить время простоя ( или держать под руками ОЧЕНЬ хороший ЗИП)
Особенно это касается ИТП, т.к. останавливать его в морозы как-то не всем нравится. Интересно, если зимой "накроется" датчик темп. обратной воды в приточке - как поступить с насосом?

Вы знаете, но чаще всего в ТЗ присутствует фраза "Обеспечить температуру приточного воздуха 22 градуса и возможность изменения этого задания. Наверное от того, что я это ТЗ получаю от "вентиляционщиков", и приучил уже их прописывать эти вещи. Ведь ТЗ - составная часть проекта. И в пояснительной записке я еще раз повторяю всю логику работы и те неисправности, которые приводят к останову системы. И именно потому, что заказчик умнеет, то он предпочитает останов системы фатальным последствиям "безопасного режима". Разумеется, что эти все отказы как правило маловероятны. Другой вопрос, что если заказчик готов пойти на дополнительные расходы ради обеспечения резервирования, то глубина непотопляемости и обсуждается отдельно, от спаренных насосов, до ИБП на несколько суток и полный горячий резерв, и затем учитывается в разработке и отражается в проекте.

Ну, мысль интересная. Остается выяснить критерий "неисправности", например, выход из строя входа/выхода контроллера, потеря связи по сети, превышение времени цикла, обрыв питания датчиков (активных),
потеря связи с модулями расширения, "залипание" контактора и т.д.
И попробуйте это дело согласовать... Я бы не подписал. Печально это...
Получается, что работоспособность системы( при отсутствии паспортных данных по наработке на отказ или на сбой - типичная картина) - вещь необоснованная. Т.е. вы предлагаете "кота в мешке", но Ваш аргумент -
"у других работает". Детский лепет , простите...

Описаный мною проект состоит из 2х S7-300 + 2 S7-200 + 3 ET200M + 1 ET200s

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

Все правильно, я просто хотел сказать, что грамотно прописать все на разных платформах бывает хлопотно ( чем "промышленней", тем проще).
Для SCADA - есть набор "псевдозадач", которые затем и делаю на конкретном продукте.

Не понял, а Scada то тут причем? Я то имел в виду прописывание все в алгоритмах. Scada лишь отражает ей переданное и отдает некоторые команды оператора. Канал то между контроллерами и АРМом может быть нарушен.

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

Со Скады я настройку предпочитаю предоставлять минимальную, дабы исключить человеческий фактор. И то, потом такие сочетания этих параметров видишь... По крайней мере даже параметры ПИДов никогда не вывожу. Сам настроил через консоль, и адью. И при резервировании контроллеров, решения принимаются внутренними алгоритмами контроллеров. С АРМа можно попробовать включить резерв, но в аварию не вывалить основную систему.

Минимальные возможности настройки делать неудобно (программатор таскать устанешь), а для ограничения человеческого фактора существует как минимум два решения:
1. Ограничение прав доступа
2. задание граничных значений диапазонов ввода

Именно так. Есть ХОРОШЕЕ средство - группы пользователей. По ним и набор экранов разный, и поля экранов... Да и человека (наладчика) проще обучить с экранами работать, чем в контроллеры лазить. А если на объектах системы разные - то СТАНДАРТНЫЕ по виду экраны облегчают жизнь. Самому бегать и настраивать - несолидно как-то. И документации
меньше. Если совсем плохо - через Инет (мобила) залил настройки или дал "по умолчанию". Трафик - минимальный. Можно и диагностику провести.

А я и не бегаю. Даже зад для этого от стула не отрываю. Просто через нет конектюсь консолью, рисую графики, настраиваю, потом прописываю в алгоритм как значения по-умолчанию и перепрошиваю. Вот и фсё!

Я Вам открою страшную тайну: не во всех ИТП(ЦТП) присуцствует интернет

Но практически во все его можно провести.

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

Итак?

1. В Овне практически ничего не изменить в настройках в онлайне. Обязательно надо отключиться от контроллера. Просто супер.

2. Не работает он с высокоомными термисторами 3 и 10 кОм. А это трехпроводка на больших объектах, а это и проводов больше и аналоговых входов, а значит и контроллеров вдвое больше.

3. А как же измерение напряжения и тока? А как же преобразование физических величин апроксимированно по множеству точек? Как вы подключите нестандартные датчики, например протока или уровня?

4. Нет вообще возможности измерения аналоговым входом сопротивления. А значит нет пожарных и охранных шлейфов на умный дом.

5. И вы считаете CFC графической средой разработки?! Про остальные языки я вообще молчу. Жалкое подобие левой руки. А для аналоговых сигналов вообще рекомендуется ST.

6. Интернет Scada нет вообще. Техподдержка рот раскрыла от примеров. Только только обещают web сервер, но это вообще не то, но его стоимость включат в стоимость каждого контроллера.

7. Codesys безплатен только стандарт. Любое расширение платно. Хоть тот же ENI сервер. Как нескольким разработчикам разрабатывать именно большое здание без него? В Конграфе то элементарно каждый пишет свой контроллер, потом легко слепляется в одном проекте.


Итого: Сам контроллер у Овна по процессору и памяти мощнее и дешевле. Но вот софт оставляет желать лучшего. Ребята вроде вменяемые, многие описанные выше баги обещают исправить. Так что будущее у них есть. Но насчет сырости и багов я нисколь не ошибся. На данном этапе что то простенькое, с ограниченным бюджетом делать можно, но дальше надо развивать софт. Возможно с нашей помощью. Возможно дальнейшее развитие SFC нас порадует.
Я желаю ребятам из Овна перспективного роста.

Что-то я не понимаю
Читаю паспорт ПЛК150...
Типы поддерживаемых унифицированных входных сигналов:
Напряжение 0...1 В, 0...10 В
Ток 0...5 мА, 0(4)...20 мА
Сопротивление 0...5 кОм.

3. Ток, напряжение и сопротивление померить таки, можно?
Нестандартные датчики протока сигнал 0...10В (4-20mA)не выдают? Не применяем
4. Сопротивление пожарных шлейфов > 5кОм? Возможно. Не встречал.
5. А что плохого в ST? Очень на Basic похоже

В том и дело, что не понимаете.
Kass говорит именно об измерении напряжения, тока, сопротивления, а не о поддержании унифицированных входных сигналов. Иными словами, может ПЛК150 выдать значение измеренного сопротивления, тока или напряжения, а не соответствующие им физические величины, как-то температура, влажность, давление?

Дык, в процентах все получается

И что дают нам проценты? Приводить их потом к измеренным величинам? Конечно, можно и так...
А как быть с задачей измерения физических величин датчиками с нелинейной зависимостью выходного сигнала, про которые говорил Kass? Сигнал у них может быть и 0...10В, а вот какая там кривая изменения этих 0...10В в зависимости от измеряемой величины, знает только производитель. И все? На этом застряли? Не все же так тупо измеряется 0...10В = 0...100%
Если заниматься fallomeasurementом, то можно много чего наговорить. Но, на мой взгляд, из отечественных продуктов ПТК Контар и его среда программирования Конграф самые продвинутые. Этот комплекс обладает довольно мощной математикой, которая даже у импортных продуктов не всегда присутствует. Просто скачайте себе софт с сайта, пока бесплатно раздают и посмотрите.

Для Kass ответ
По пунктам так и начнем.
1. Странно а у меня менялись данные в онлайне - может не о том говорим? У Вас контроллер то был на руках? Если был то странные вещи говорите
2. Про высокоомные термисторы давно пора забыть - не нужны они почти нигде уже - нужна точность более-меннее возьмите pt1000, нужна супер точность берите 4-20, 0-10 и не парьтесь. Приведите примеры применения высокоомных сопротивлений не обусловленные тотальной экономией.
3. Напряжение и ток измеряются без проблем - где то здесь вы не правы.
4. Пожарка и охранка это отдельная тема и к ПЛК не имеет никакого отношения, тем более что ни у ОВЕНа ни у МЗТА на это дело нет разрешений, а если вы заказчику втюхиваете охрану умного дома на ПЛК - вы нехороший человек.
5. CFC и FBD - удел ленивых. STL для профессионалов. Кстати по аналоговым сигналом и ST - именно так и надо с ними работать. Еще раз повторюсь ну невозможно на FBD сделать ооочень многи вещи, никогда, это поймет кто работал на нормальных контроллерах типа Сименса или АленБрэдли и Омрон - остальным кто привык видеть только блоки этого просто не понять никогда к сожалению.
6. Web сервер живой и опробован, правда не нами - на сайте прософта человек рассказывал - и под него у них есть скада на основе эксплорера
7. А зачем Вам ENI сервер - возьмите ОРС и работайте - ОРС бесплатен

Назову еще раз плюсы ОВЕНА:
1. Еще раз повторюсь программу более просто отлаживать за счет наблюдения за всем ее ходом в онлайне
2. Не один, а 3 языка - каждому свое как говорится
3. Важный плюс - конфигурация вх/вых через программу - не надо перемычками как в МЗТА баловаться - там забыл там потерял, хотя оба способа имеют право на жизнь. Это кому как нравится.
4. Встроенная батарея позволяет в течение получаса выдавать данные на диспетчеризацию не управляя выходами - очень важная вещь
5. Настройка безопасного состояния выходов - если питание вырубилось выходы устанавливаются в заданное при разработке состояния, у МЗТА этого нет (оно надо конечно редко, но факты когда было нужно были)
6. Очень ВАЖНАЯ вещь - работа с адресным пространством - как говорится что хочу то и ворочу в любом месте программы можно обратится к тому мест которое нужно, и не надо городить кучу линков и соединений как например в FBD у Конграфа - это оооочень большой плюс.
Еще много могу назвать - сейчас времени нет просто. Kass жду ответа

Раз уж заполз то вот тема с обсуждением ОВЕНа тех кто с ним работает и обсуждением в т.ч. Web сервисов, там оказывается даже FTP поддержка и работа с файлами есть - интересненько однако - сам не знал.
http://forum.cta.ru/forum_posts.asp?TID=20...5%CD&PN=0&TPN=1

Спасибо за ссылку, почитаю. Но сертификат получил. Сегодня долго сидели с ребятами разработчиками. Сам контроллер интересен. Пару замечаний есть, но думаю исправят. Но вот с софтом, они сами признают и облизываются на контаровский софт. Говорят, что у них дядюшки в штатах нет, самим такое не написать, вот пока подлезли под CoDeSys. Но говорить о том, что это профессиональная среда для разработки, более не надо. Теперь я практически все по ней знаю. Конечно, я знаю, где можно применить сейчас Овны с CoDeSys-ом, но только не большие здания и объекты, это точно. Но мы теперь с ребятами сотрудничаем, и будем всячески помогать с продвижением продукта.

To Fanat

Как я понимаю (на основе имеющейся информации) на данный момент основное преимущество ПЛК ОВНа - низкая цена (включая бесплатность КоДеСиса). Значит, имеет смысл экономить на всем, включая датчики.

To Kass

Да ну ладно...Что у нас хороших программистов в Росии нет ? Просто хотели минимизировать затраты, я думаю.

Если проект большой, то система не есть простая сумма отдельных, пусть и умных, элементов. С увеличением объекта (см. название ветки) увеличивается вес задач по синхронизации работы отдельных элементов, => центр тяжести смещается в сторону SCADA, а контроллер превращается в устройство по сбору и ПРЕДВАРИТЕЛЬНОЙ обработке информации. Естественно, функции управления сохраняются, но зона маневра сокращается, т.к. надо знать, что делают остальные элементы системы.

Да есть конечно, только они бесплатно и за копейки не работают. А значит на разработку требуются не малые средства и время. Что не всегда имеется в наличии. Но поверьте, что если это и находится, то конечная стоимость изделия неимоверно вырастает.

У меня как раз наоборот. Ни одна фирма на мои алгоритмы не делала диспетчеризацию. И более того, очень тяжело делать диспетчеризацию на то, что изначально на это не расчитывалось. Приходится скрещивать ужа с ежом. А зачем? Это как пытаться сделать кольцевой автомобиль для Лемана, который изначально проектировался как внедорожник. Это и значительно дороже и ущербнее.

Я вообще не пойму, почему Вы всегда спорите о том чего нет.
Во первых:
Нет соотвествующих разрешений ни у МЗТА ни у ОВЕНа на применение в "пожарке", так зачем спорить по всяким вопросам не имеющим под собой оснований: про датчики шлейфовые и прочее..
Во вторых
Если Вы нацелены сравнивать как бы россиийское железо то: Контар не является разработкой МЗТА, ни ПО ни Модули и изначально являются америкосовскими. Так уважаемые Господа не стоит сравнивать их: тех кто действительно пытается поднять российский рынок ПЛК и как понимаете сталкнулись с кучей проблем (но стремиться их решить) и тех кто просто нагло выдает чужое за своё.
В третьих
Покрайней мере даже если есть замеченные недостатки, я смогу с Овеном договориться (скупо заявить об ошибке в письме или на форуме) и её исправят (из неоднократного опыта) или изменят под требуемые параметры (никто не совершенен). И именно в этом случае, учитывая мнения большинства нас (тех кто использует эту продукцию) все будут довольны, а на выходе будет именно тот продукт которого все ждут. А вот извеняюсь с Контаром попробуйте переделайте что-либо или заставьте учесть Ваши пожелания в контроллере.
В четвертых
Тема вроде бы была о SCADA системе, так вот если действительно нужно сделать стоящий проект то уж и использовать нужно действительно SCADA-систему а не сопутствующее ПО производителя в виде Конграфа и пр.. потому что в диспетчеризации боюсь у Вас будет не только Контары но и прочее оборудование будь то Преобразователи частоты, контроллеры других производителей, расходомеры, счетчики и пр... а это уже грамотно и вообще возможно сделать только в хорошей SCADA не ориентированной на что-то конкретное.

Поэтому
Спор собственно ни очем. Всё весьма субъективно и каждое находит своё применение. А сравнивать ориентированное под конкретные задачи железо и вообще общепромышленое оборудование нецелесообразно и лишено здравого смысла.
Просто написал со строны смотря на Вашу дискускуссию.

Во-первых.
"Соответствующих разрешений" нет ни у каких ПЛК. И дело тут не в самих контроллерах, а в наших правилах. На том же сайте контара есть пример здания в США, где реализована в частности и пожарка.

Во-вторых.
Я не пытаюсь сравнивать "как бы именно российское" железо. И никто нагла не выдает одно за другое. Тут вы снова не в курсе. Вы вдумайтесь в само название Контар... Контроллер американо-российский. Что ж тут наглого и в чем присвоение. Просто владелец Ареконта и МЗТА один и тот же человек. Если так рассуждать, то Фольксваген и Бугатти нагло присваивает разработки Ауди, Крайслер еще более нагло присваивает разработки от Мерседеса, а Бентли от БМВ, Ранасоник от Техникса... Простите, но все лидеры с кем то объединены. Это явление называется индустриализация.

В-третьих.
В Контаре во многом учтены мои пожелания. Те что не учтены, обещают учесть во второй версии Конграфа.

В-четвертых.
Конграф никогда не являлся Скадой и никогда не будет ей являться. Это лишь среда разработки алгоритмов контроллеров, причем на сегодняшний день одна из лучших. А если вы говорите о сопутствующей Контару, то наверное вы хотели сказать об АРМе. Только вы скорее всего о нем ничего не знаете, что бы сказать хоть что то. А вот сервера интернет скады нет вообще ни у кого, поэтому контар то тут явный лидер.

Поэтому. Спора нет в моих утверждениях. У нас есть непринужденная беседа. Если подойти к ней излишне эмоционально, то можно увидеть спор, как в табличке "ПИВА НЕТ". Расслабьтесь и настройтесь на спокойный обмен информацией.

Ага наклон мыслей наконец-то выявлен, хоть и не очень пристойным вызовом с моей стороны! Представтесь пожалуйста KASS -и в насколько интересных Вы связях с Контаром коли Ваши мысли там учитывают и почему владеете Вы большей инфой нежели остальные, в том числе и документацией МЗТА....

Интернет SCADA - это значит есть интернет - есть SCADA, а нет интернета и нет SCADA? Если так, то это интересное решение

Хм откуда у Вас такие данные, Уважаемый?

У вас есть другие данные? Тогда поправьте меня.

Безусловно есть.
http://www.citect.com/products-and-services/citectscada.html намбер 1
http://www.automation-drives.ru/as/downloa...Navigator_r.pdf намбер 2 (тут мануал к сожалению, не нашел описания с восхвалениями)
у InTouch есть решение для веба, к сожалению ссылку не нашел.
Позволю себе заметить, что все представленные продукты, за исключением wincc, не имеют отношения к производителю оборудования и являются открытыми SCADA-системами.

Еще пример: http://www.arcinfo.com/doc/EN/PRODUCTS/Web...iers/WebVue.pdf

Скорее трудно найти SCADA без и-нет сервисов.

Да нет господа, вы меня не так поняли. Я имел в виду не софт для организации интернет сервера, а именно организованные и поддерживаемые сервера производителем контроллеров. А так я должен купить софт, купить сервер, для маленького проекта можно повесить как минимум на 10 мБит канал, платить за интернет... А если его повесить на М9, для использования видеонаблюдения в скаде, то вообще бюджет вылезет из всех приличных границ. Тут же све эти заморочки взял на себя производитель. Я скада проекты леплю за спасибо. ИМХО это несколько другое. Поэтому я ожидал ссылки на такие сервера с примерами.

Все это хорошо... Вот только серьезный заказчик вряд ли пойдет на подобные решения - представь себе систему управления небольшого даже заводика, выведенную на сервер такой - ужасть просто.. А ежели хакеры? Как с ними борются то? Защищенных вещей не бывает - можно у Пентагона спросить Просто сам принцип это диспетчеризации через интернет неправильный. А что делать если провайдер сдох??? Или где-то эскаватор перебил кабель (на моей практике было такое) или еще что...
Решение контара по интернет СКАДЕ хорошо для небогатых или ЖАДНЫХ клиентов - это да, сравнений никаких... И еще раз спрашиваю: А нафига этот серевер нужен то??? Если есть возможность поставить ПЛК, который поддерживает Web-Server, его точно так же можно к нету подключить и радость в жизни. Я на Сименсе подобную ерунду делал ради интереса - достаточно неплохо получается.
Единственно что меня радует в интернет-сервере Контара - это WAP - это действительно интересно, но еще раз повторюсь - для владельцев коттеджей и прочей шелупони разряда - хочу дешевле. Нормальному заказчику - это только как доп опция подойдет Ставишь сименс какой нить, а для обмена через мобильник - рядом МС8, например. И все работает на ура.

У сименса с этого года есть стандартные решения для таких зачач, проходящие правда по направленю "телеметрия".

2 Fanat. Это решение даже не для клиента. У клиента АРМ стоит локальный. А вот для поставщиков оборудования, которые продолжают его обслуживать - это огромный плюс. Они могут отслеживать его не выезжая на объект, который зачастую может находиться за тысячи километров. Про хаккеров давайте лучше не будем заводить тему. Во-первых, никто не разу еще не сломал. Во-вторых, сломать тогда по аналогии можно и вэб-сервер, и удаленный АРМ, и взломав саму сеть "заводика" можно получить доступ к локальному АРМу. А что касается вэб сервера встроенного, то ради игрушек я тоже это пробовал, но применять это не пришлось. Во-первых, большой трафик от каждого объекта, а ведь многие сидят на мобильниках. При этом скорость просто смешная. Во-вторых, контаровский сервер хранит записи от проектов, накопленные годами, и вы можете посмотреть любые параметры и построить графики того, что происходило год назад. Это очень полезно при рассмотрении каких то нештатных ситуаций. С вэб-сервером - обломитесь.

To KASS
Вы всех убедили, что лучше Контара может быть только ДВА Контара.
Теперь осталось объявить о начале акции "Купи Контар и найди под крышечкой путевку в Америку на двоих" - клиент косяком пойдет.

Акция мне ни к чему. Контар пусть и проводит. Главное что бы вам было удобно работать.

Господа, во время перечитывания всей темы я пришёл к выводу, что автора здесь давно нет, мы отклонились от темы, и по моему мнению, я согласен с тем что было ранее сказано - обратиться нужно к самому производителю, пусть у него голова болит о совместимости и возможностям интеграции его решений с другими АСУ. Киньте в меня камень если я неправ ))

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

Да мы то по сути не решаем тут вопросы производителей, а просто пытаемся поделиться опытом. Ведь все делают системы на разных платформах, и только тут мы можем обменяться плюсами и минусами различных платформ. Так что тема интересна именно нам, а разработчику уже по стольку поскольку... Меня например Fanat сподобил сходить обучиться на ПЛК. Где то применю, контроллер интересный. Кто то что то другое попробовал. В этом и есть польза.

Добавлено - 12:22
Да мы то по сути не решаем тут вопросы производителей, а просто пытаемся поделиться опытом. Ведь все делают системы на разных платформах, и только тут мы можем обменяться плюсами и минусами различных платформ. Так что тема интересна именно нам, а разработчику уже по стольку поскольку... Меня например Fanat сподобил сходить обучиться на ПЛК. Где то применю, контроллер интересный. Кто то что то другое попробовал. В этом и есть польза.