Итак. Задача — разработать сервер который обчитывает приборы по СОМ порту и передает их по ОРС технологии в СКАДА системы. Поддержка распереденной работы (неск. серверов на неск. машинах), поддержка передачи данных по медленным каналам (прослойка между ОРС сервером одной машины и клиентом СКАДА на другой). ну и еще кое какие мелочи — БД, лицензирование (колво и типы приборов) итд.

Какой язык советовали бы? Приветствуются любые идеи. Будем ломать стереотипы

Здравствуйте, ironwit, Вы писали:

I>Итак. Задача — разработать сервер который обчитывает приборы по СОМ порту и передает их по ОРС технологии в СКАДА системы. Поддержка распереденной работы (неск. серверов на неск. машинах), поддержка передачи данных по медленным каналам (прослойка между ОРС сервером одной машины и клиентом СКАДА на другой). ну и еще кое какие мелочи — БД, лицензирование (колво и типы приборов) итд.

I>Какой язык советовали бы? Приветствуются любые идеи. Будем ломать стереотипы
Oberon (есть опыт у Южной Америки), C++Builder/Delphi (есть обширный опыт у РАО ЕЭС).
Всё что знаю, перечислил.

Здравствуйте, iZEN, Вы писали:

ZEN>Здравствуйте, ironwit, Вы писали:


I>>Какой язык советовали бы? Приветствуются любые идеи. Будем ломать стереотипы
ZEN>Oberon (есть опыт у Южной Америки), C++Builder/Delphi (есть обширный опыт у РАО ЕЭС).
ZEN>Всё что знаю, перечислил.


про оберон ой На делфи и у нас написано
Я тут слышал про семейство дотнет. Типа он и так весь насквозь интерфейсный... типа на нем вообще просто ОРС делать

Здравствуйте, ironwit, Вы писали:

I>Я тут слышал про семейство дотнет. Типа он и так весь насквозь интерфейсный... типа на нем вообще просто ОРС делать
На точка-нет SCADA делать не рекомендуется, так как будет полная завязка на windows-архитектуру.
Политика России в этом вопросе сейчас постепенно становится всё более и более жёсткой всвязи с доктриной "энергетической безопасности".

Засилье Windows вызвало в своё время (лет пять-шесть назад) постепенный отказ от гетерогенных но работающих приложений в пользу моногенных слабо приспособленных к реал-тайму win-приложений промышленного масштаба. Издержки огромны! Вложение капитала происходило прежде всего в новое ПО, которое должно заменить старое, и в мощную вычислительную базу для этого на фоне глобальной реструктуризации отрасли (я о РАО говорю), что не даёт совершенствовать капитальные фонды (генераторное оборудование, сети передачи энергии и т.д.), которые изношены на 50..70%. Аварии на ПС сейчас стали обычным явлением, правда, не таким масштабным как в Москве.

I>про оберон ой На делфи и у нас написано

это для сервера
http://www.ipi.ac.ru/lab43/lopc-ru.html

Это клиент и OPC XML
http://www.kassl.de/opc/index.shtml

I>Я тут слышал про семейство дотнет. Типа он и так весь насквозь интерфейсный... типа на нем вообще просто ОРС делать

не легче чем на Delphi. Добавляется проблема перейти с Delphi на дотнет.

В зависимости от задачи — рекомендация взять готовый продукт (СКАДУ) у
тех кто этим занимается профессионально, дописывая только свои особенности.

Здравствуйте, iZEN, Вы писали:

.NET как причина сбоев в энергосети России. Сильно, я в восторге.

Здравствуйте, AndrewVK, Вы писали:

AVK>.NET как причина сбоев в энергосети России. Сильно, я в восторге.
Где я такое писал?

Здравствуйте, ironwit, Вы писали:

I>Итак. Задача — разработать сервер который обчитывает приборы по СОМ порту и передает их по ОРС технологии в СКАДА системы. Поддержка распереденной работы (неск. серверов на неск. машинах), поддержка передачи данных по медленным каналам (прослойка между ОРС сервером одной машины и клиентом СКАДА на другой). ну и еще кое какие мелочи — БД, лицензирование (колво и типы приборов) итд.

I>Какой язык советовали бы? Приветствуются любые идеи. Будем ломать стереотипы

Однозначно Erlang.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, iZEN, Вы писали:

AVK>.NET как причина сбоев в энергосети России. Сильно, я в восторге.
не надо перекручивать. А то становится очень похоже на разговор о политике

Здравствуйте, faulx, Вы писали:

F>Здравствуйте, ironwit, Вы писали:

I>>Какой язык советовали бы? Приветствуются любые идеи. Будем ломать стереотипы

F>Однозначно Erlang.
плюсы?

Здравствуйте, swame, Вы писали:

I>>про оберон ой На делфи и у нас написано

S>это для сервера
S>http://www.ipi.ac.ru/lab43/lopc-ru.html

S>Это клиент и OPC XML
S>http://www.kassl.de/opc/index.shtml

спасибо за ссылки. посмотрю и прочитаю внимательно

I>>Я тут слышал про семейство дотнет. Типа он и так весь насквозь интерфейсный... типа на нем вообще просто ОРС делать

S>не легче чем на Delphi. Добавляется проблема перейти с Delphi на дотнет.

S>В зависимости от задачи — рекомендация взять готовый продукт (СКАДУ) у
S>тех кто этим занимается профессионально, дописывая только свои особенности.
скада есть. необходим все таки сервер который будет обчитывать приборы. Приборов много. на все — не напасешься ОРС серверов от разработчиков приборов. да и не так все просто их в кучу увязать.

Здравствуйте, ironwit, Вы писали:

I>Какой язык советовали бы? Приветствуются любые идеи. Будем ломать стереотипы

Как раз в рамках старых стереотипов:
C++ и SObjectizer

Автор: Евгений Охотников
Дата: 30.12.05

(SObjectizer начинался как инструмент для SCADA, правда давно, в до-OPC-шную эпоху)

Здравствуйте, ironwit, Вы писали:

I>Здравствуйте, faulx, Вы писали:

F>>Здравствуйте, ironwit, Вы писали:

I>>>Какой язык советовали бы? Приветствуются любые идеи. Будем ломать стереотипы

F>>Однозначно Erlang.
I>плюсы?

Минимизация проблем с многопоточностью, распределенностью, отказоустойчивостьюи и real-time-ом. Есть некоторый опыт решения задач, похожих на описанную, и я пришел именно к этому выводу — Erlang. Подробнее:

1. Многопоточность. Точнее говоря, параллельность. Потоки встроены в язык, легкие. "Запускайте по потоку на каждую параллельную активность в предметной области" — советуют авторы языка.

2. Распределенность. Опять-таки встроена в язык, многие вещи сделаны прозрачно. Например, не имеет значения, запущен поток на локальной или на удаленной машине — посылка сообщения выглядит одинаково. Плюс, с языком поставляется mnesia — распределенная база данных.

3. Отказоустойчивость. Наверное, основная "фишка" Erlang-а. Вкратце — потоки организованы в иерархии, одни потоки следят за тем, как выполняются другие, при возникновении проблем перезапускают их. Все, опять-таки, поддерживается библиотекой, ручная писанина сводится к тому, что необходимо прописать чиселки, которые определят максимально допустимое кол-во перезапусков в минуту и т.п.

4. Real-time. Конечно, не жесткий, а мягкий. Поскольку система состоит из кучи потоков (и это, по философии Erlang, есть хорошо и правильно), важные взаимодействия основаны на обмене сообщениями. А отсюда вытекает возможность проставить необходимые таймауты, по истечении которых длительные запросы отрубаются (или происходит еще что-нибудь полезное). Т.е., например, появляется функция poll_device(DeviceId, 10), которая пытается забрать данные с устройства DeviceId, а если в течении 10 секунды устройство не отзовется, начать бить тревогу. (Кстати, о тревогах: в библиотеке есть стандартные функции для работы с алармами и т.п.) Да, пока не забыл, насчет real-time. Будут пугать garbage collection-ом. Не бойтесь!

Ну, не говорю о таких мелочах, как отсутствие проблем с границами массивов, утечками памяти, и даже утечками ресурсов (если не задаваться специальной целью, утечку ресурсов, отличных от памяти, т.е. открытых файлов, сокетов и т.п., в Erlang-е сделать не так просто). Язык — не творение академиков, а родился из практики — телеком, Ericsson, коммутаторы и все такое. Подробнее — здесь.

Лично я писал клиента для OPC на Erlang-е. Сервера писать не приходилось, к сожалению. В части клиента — могу помочь, чем смогу.

Здравствуйте, faulx, Вы писали:

F>Минимизация проблем с многопоточностью, распределенностью, отказоустойчивостьюи и real-time-ом. Есть некоторый опыт решения задач, похожих на описанную, и я пришел именно к этому выводу — Erlang.

Извини за offtopic, не мог бы ты с позиции Erlang-а вот эту штуку

Автор: Евгений Охотников
Дата: 30.12.05

покритиковать?

Здравствуйте, eao197, Вы писали:

E>Здравствуйте, faulx, Вы писали:

F>>Минимизация проблем с многопоточностью, распределенностью, отказоустойчивостьюи и real-time-ом. Есть некоторый опыт решения задач, похожих на описанную, и я пришел именно к этому выводу — Erlang.

E>Извини за offtopic, не мог бы ты с позиции Erlang-а вот эту штуку

Автор: Евгений Охотников
Дата: 30.12.05

покритиковать?

Прочитал пока на один раз, впечатление поэтому пока сумбурное.

Честно говоря, даже не знаю, как критиковать. Я тоже когда-то писал нечто подобное, попроще, правда. Ну что, еще один механизм обмена сообщениями. Некоторая дисциплина — здесь такая, у других другая. Ну ладно, вот замечания, возможно, глупые:

1. "Тяжеловесность" потоков накладывает отпечаток на архитектурные решения — много говорится о диспетчерах, нитях, контекстах и т.п. В Эрланге потоки легкие, и голова об этом болит только у разработчиков рантайма — головастых парней из Швеции

2. Рассуждения о синхронности и асинхронности. С точки зрения Эрланга синхронность — это нечто, что легко может быть построено над асинхронностью. Т.е. если имеем механизм посылки сообщения Pid!Message (потоку Pid посылается сообщение Message), то можно над этим сделать синхронность:

sync_call(Pid, Message) ->
    Pid!{self(), Message},
    receive
        {Pid, Responce} ->
            {ok, Responce}
    end.

Надеюсь, понятно: посылаем сообщение, ждем ответа. Если ответа нужно ждать не бесконечность, а не больше некоторого времени (здравствуй, real-time!), то пишем:

sync_call(Pid, Message, Timeout) ->
    Pid!{self(), Message},
    receive
        {Pid, Responce} ->
            {ok, Responce}
    after Timeout -> {error, timeout_expired}
    end.

Ну и самое главное: на самом деле этого писать не придется, все уже написано до нас и включено в стандартные поведения gen_server, gen_fsm и gen_event.

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

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

4. Динамичность Эрланга позволяет осуществлять такие вещи, как изменение на лету как протокола обмена сообщениями, так и кода, эти сообщения обрабатывающего. На лету — значит, без остановки и перезагрузки системы.

Здравствуйте, faulx, Вы писали:

F>Здравствуйте, ironwit, Вы писали:

I>>Здравствуйте, faulx, Вы писали:

F>>>Здравствуйте, ironwit, Вы писали:

I>>>>Какой язык советовали бы? Приветствуются любые идеи. Будем ломать стереотипы

F>>>Однозначно Erlang.
I>>плюсы?

F>Минимизация проблем с многопоточностью, распределенностью, отказоустойчивостьюи и real-time-ом. Есть некоторый опыт решения задач, похожих на описанную, и я пришел именно к этому выводу — Erlang. Подробнее:
skip
Здорово буду смотреть в эту сторону внимательнее Совместимости с pascal конечно нет и все драйвера придется переписывать?
F>Лично я писал клиента для OPC на Erlang-е. Сервера писать не приходилось, к сожалению. В части клиента — могу помочь, чем смогу.

сразу вопрос. стандарт DA реализовывали сами или использовали сторонние наработки?

Здравствуйте, ironwit, Вы писали:

F>>Минимизация проблем с многопоточностью, распределенностью, отказоустойчивостьюи и real-time-ом. Есть некоторый опыт решения задач, похожих на описанную, и я пришел именно к этому выводу — Erlang. Подробнее:
I>skip
I>Здорово буду смотреть в эту сторону внимательнее Совместимости с pascal конечно нет и все драйвера придется переписывать?

А вот кстати, не факт Зависит от требуемой скорости. Если нужна максимальная скорость — то надо писать встраиваемый драйвер, на C. Но что-то мне подсказывает, что скорость у вас будет ограничена скоростью работы прибора, т.е. запас есть. И тогда я бы порекомендовал другой способ — писать так называемый порт. Фактически, это просто внешний exe-шник, по pipe-у общающийся с Эрлангом. В обмен на скорость (а надо еще посмотреть, будет ли это узким местом) мы получаем кучу преимуществ: возможность писать на любом языке программирования, умеющим работать со стандартным вводом/выводом (хоть brainfuck), простоту (exe-шник занимается только одной простой задачей), изоляцию ошибок (если exe-шник упадет, Эрланг перезапустит его) и т.п.

F>>Лично я писал клиента для OPC на Erlang-е. Сервера писать не приходилось, к сожалению. В части клиента — могу помочь, чем смогу.

I>сразу вопрос. стандарт DA реализовывали сами или использовали сторонние наработки?

Я уже немного выпал из темы, поэтому, возможно, не совсем понимаю вопрос. Я писал OPC-клиента с использованем стандартных библиотек с www.opcfoundation.org. Под Виндовс, на C++, COM. Реализовывал только нужную функциональность, самую простую (запросить данные, получить данные), без всяких асинхронностей и т.п.

Здравствуйте, faulx, Вы писали:

E>>Извини за offtopic, не мог бы ты с позиции Erlang-а вот эту штуку

Автор: Евгений Охотников
Дата: 30.12.05

покритиковать?

F>Прочитал пока на один раз, впечатление поэтому пока сумбурное.

Слушай, огромная просьба: запости, пожалуйста, этот ответ в обсуждение SObjectizer.

Здравствуйте, faulx, Вы писали:

F>Здравствуйте, ironwit, Вы писали:

F>>>Минимизация проблем с многопоточностью, распределенностью, отказоустойчивостьюи и real-time-ом. Есть некоторый опыт решения задач, похожих на описанную, и я пришел именно к этому выводу — Erlang. Подробнее:
I>>skip
I>>Здорово буду смотреть в эту сторону внимательнее Совместимости с pascal конечно нет и все драйвера придется переписывать?

F>А вот кстати, не факт Зависит от требуемой скорости. Если нужна максимальная скорость — то надо писать встраиваемый драйвер, на C. Но


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

Здравствуйте, ironwit, Вы писали:

F>>А вот кстати, не факт Зависит от требуемой скорости. Если нужна максимальная скорость — то надо писать встраиваемый драйвер, на C. Но
I>громадное спасибо заинтересовались этим языком. Есть обсуждения на рсдн чтобы их слить в янус и почитать?
Смотри форум Декларативное программирование там Erlang иногда обсуждают.

Но сам OPC сервер всетки лучше писать на VC++. И никаких билдеров ибо OPC сам по себе протокол дурной так еще и билдер со своими тараканами будет под ногами путаться(я пробовал...). Кстати без валидатора, а лучше двух OPC сервер не написать.
Я делал OPC сервер в виде прокси между кучей наших программ скадами. Тебе ИМХО нужно сделать также те OPC сервер сам по себе программы работающие с железками сами по себе. Поднимаешь сервер на томже компе где работает СКАДА чтобы с DCOM'ом не связыватся, а по сетке данные пусть Erlang гоняет.
И еще одно OPC DA1 реализовывать не нужно. Гмороя много, а толку нету. Я занимался этим года два назад и уже тогода все что я видел прекрасно понимало OPC DA2.

Вот ребята делают что-то похожее.

Здравствуйте, eao197, Вы писали:

E>Здравствуйте, ironwit, Вы писали:

I>>Какой язык советовали бы? Приветствуются любые идеи. Будем ломать стереотипы

E>Как раз в рамках старых стереотипов:
E>C++ и SObjectizer

Автор: Евгений Охотников
Дата: 30.12.05

E>(SObjectizer начинался как инструмент для SCADA, правда давно, в до-OPC-шную эпоху)

Изучили вопрос (на базе статьи и обсуждения) вывели для себя — эта библиотека все таки больше нужна для систем с зачатками ИИ, с очень большой необходимости синхронизаций итд. Для нас как то не подходит

Здравствуйте, faulx, Вы писали:

F>Вот ребята делают что-то похожее.
спс. пошел читать

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, ironwit, Вы писали:

F>>>А вот кстати, не факт Зависит от требуемой скорости. Если нужна максимальная скорость — то надо писать встраиваемый драйвер, на C. Но
I>>громадное спасибо заинтересовались этим языком. Есть обсуждения на рсдн чтобы их слить в янус и почитать?
WH>Смотри форум Декларативное программирование там Erlang иногда обсуждают.

WH>Но сам OPC сервер всетки лучше писать на VC++. И никаких билдеров ибо OPC сам по себе протокол дурной так еще и билдер со своими тараканами будет под ногами путаться(я пробовал...). Кстати без валидатора, а лучше двух OPC сервер не написать.
у нас на Delphi все драйвер (точнее object pascal ). Так что...
WH>Я делал OPC сервер в виде прокси между кучей наших программ скадами. Тебе ИМХО нужно сделать также те OPC сервер сам по себе программы работающие с железками сами по себе. Поднимаешь сервер на томже компе где работает СКАДА чтобы с DCOM'ом не связыватся, а по сетке данные пусть Erlang гоняет.
а каким образом Erlang обменивается данными между процессами работающими на разных машинах? и просто между процессами внутри одной машины.
WH>И еще одно OPC DA1 реализовывать не нужно. Гмороя много, а толку нету. Я занимался этим года два назад и уже тогода все что я видел прекрасно понимало OPC DA2.
Согласен

Здравствуйте, ironwit, Вы писали:

I>Итак. Задача — разработать сервер который обчитывает приборы по СОМ порту и передает их по ОРС технологии в СКАДА системы. Поддержка распереденной работы (неск. серверов на неск. машинах), поддержка передачи данных по медленным каналам (прослойка между ОРС сервером одной машины и клиентом СКАДА на другой). ну и еще кое какие мелочи — БД, лицензирование (колво и типы приборов) итд.

I>Какой язык советовали бы? Приветствуются любые идеи. Будем ломать стереотипы

Не понял. А что надо-то? Чтобы попроще было, или штоб максимально через ж*пу?

Хочешь соригинальничать — используй Erlang. Из всех "нестереотипных" решений на нем одном получится "попроще", он для этой задачи подходит лучше всех остальных.

Здравствуйте, ironwit, Вы писали:

E>>C++ и SObjectizer

Автор: Евгений Охотников
Дата: 30.12.05

I>Изучили вопрос (на базе статьи и обсуждения) вывели для себя — эта библиотека все таки больше нужна для систем с зачатками ИИ, с очень большой необходимости синхронизаций итд. Для нас как то не подходит

Спасибо, что ознакомились со статьей
Может для задач с более сложной логикой окажется восстребованным.

Здравствуйте, eao197, Вы писали:

E>Здравствуйте, ironwit, Вы писали:

E>>>C++ и SObjectizer

Автор: Евгений Охотников
Дата: 30.12.05

I>>Изучили вопрос (на базе статьи и обсуждения) вывели для себя — эта библиотека все таки больше нужна для систем с зачатками ИИ, с очень большой необходимости синхронизаций итд. Для нас как то не подходит

E>Спасибо, что ознакомились со статьей
та не за шо
E>Может для задач с более сложной логикой окажется восстребованным.
+1

Здравствуйте, Gaperton, Вы писали:

G>Здравствуйте, ironwit, Вы писали:

I>>Какой язык советовали бы? Приветствуются любые идеи. Будем ломать стереотипы

G>Не понял. А что надо-то? Чтобы попроще было, или штоб максимально через ж*пу?
а если попроще то что посоветуете?

Глас вопиющего в пустыне к модераторам (Владу, Андрею, или ещё кто в курсе):

F>sync_call(Pid, Message) ->
F>    Pid!{self(), Message},
F>    receive
F>        {Pid, Responce} ->
F>            {ok, Responce}
F>    end.

F>sync_call(Pid, Message, Timeout) ->
F>    Pid!{self(), Message},
F>    receive
F>        {Pid, Responce} ->
F>            {ok, Responce}
F>    after Timeout -> {error, timeout_expired}
F>    end.

Я подрихтовал схему для Эрланга порядка 1.5 месяца назад. Как я понимаю, в движке RSDN по прежнему старый (глючный) вариант.

С кем можно связаться чтобы заменить схемы?

Здравствуйте, ironwit, Вы писали:

G>>Не понял. А что надо-то? Чтобы попроще было, или штоб максимально через ж*пу?
I>а если попроще то что посоветуете?
Erlang. www.erlang.org Ничего проще и лучше для таких задач в мире не существует.

А если совсем попроще — пишите на том, что знаете . И чем "скриптовее" будет язык, тем лучше.

Здравствуйте, Gaperton, Вы писали:

G>А если совсем попроще — пишите на том, что знаете . И чем "скриптовее" будет язык, тем лучше.

спасибо.. мы к этому уже склонились... осталось только понять ньюансы... и тестить тестить тестить ))