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

Какой язык советовали бы? Приветствуются любые идеи. Будем ломать стереотипы
... << RSDN@Home 1.2.0 alpha rev. 648>>
Я не умею быть злым, и не хочу быть добрым.
Re: теоретический вопрос
От: iZEN СССР  
Дата: 08.04.06 17:57
Оценка: -1 :)
Здравствуйте, ironwit, Вы писали:

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


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

Oberon (есть опыт у Южной Америки), C++Builder/Delphi (есть обширный опыт у РАО ЕЭС).
Всё что знаю, перечислил.
Re[2]: теоретический вопрос
От: ironwit Украина  
Дата: 09.04.06 14:48
Оценка:
Здравствуйте, iZEN, Вы писали:

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



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

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


про оберон ой На делфи и у нас написано
Я тут слышал про семейство дотнет. Типа он и так весь насквозь интерфейсный... типа на нем вообще просто ОРС делать
... << RSDN@Home 1.2.0 alpha rev. 648>>
Я не умею быть злым, и не хочу быть добрым.
Re[3]: теоретический вопрос
От: iZEN СССР  
Дата: 09.04.06 17:40
Оценка: 6 (1)
Здравствуйте, ironwit, Вы писали:

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

На точка-нет SCADA делать не рекомендуется, так как будет полная завязка на windows-архитектуру.
Политика России в этом вопросе сейчас постепенно становится всё более и более жёсткой всвязи с доктриной "энергетической безопасности".

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

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

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

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


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

В зависимости от задачи — рекомендация взять готовый продукт (СКАДУ) у
тех кто этим занимается профессионально, дописывая только свои особенности.
Re[4]: теоретический вопрос
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 09.04.06 20:03
Оценка: 1 (1) +1 -2 :)
Здравствуйте, iZEN, Вы писали:

.NET как причина сбоев в энергосети России. Сильно, я в восторге.
... << RSDN@Home 1.2.0 alpha rev. 646 on Windows XP 5.1.2600.131072>>
AVK Blog
Re[5]: теоретический вопрос
От: iZEN СССР  
Дата: 09.04.06 21:42
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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

Где я такое писал?
Re: теоретический вопрос
От: faulx  
Дата: 10.04.06 03:37
Оценка: +1
Здравствуйте, ironwit, Вы писали:

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


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


Однозначно Erlang.
Re[5]: теоретический вопрос
От: ironwit Украина  
Дата: 10.04.06 05:21
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


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

не надо перекручивать. А то становится очень похоже на разговор о политике
... << RSDN@Home 1.2.0 alpha rev. 648>>
Я не умею быть злым, и не хочу быть добрым.
Re[2]: теоретический вопрос
От: ironwit Украина  
Дата: 10.04.06 05:21
Оценка:
Здравствуйте, faulx, Вы писали:

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


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


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

плюсы?
... << RSDN@Home 1.2.0 alpha rev. 648>>
Я не умею быть злым, и не хочу быть добрым.
Re[4]: теоретический вопрос
От: ironwit Украина  
Дата: 10.04.06 05:21
Оценка:
Здравствуйте, 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>тех кто этим занимается профессионально, дописывая только свои особенности.
скада есть. необходим все таки сервер который будет обчитывать приборы. Приборов много. на все — не напасешься ОРС серверов от разработчиков приборов. да и не так все просто их в кучу увязать.
... << RSDN@Home 1.2.0 alpha rev. 648>>
Я не умею быть злым, и не хочу быть добрым.
Re: теоретический вопрос
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 10.04.06 06:57
Оценка:
Здравствуйте, ironwit, Вы писали:

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


Как раз в рамках старых стереотипов:
C++ и SObjectizer
Автор: Евгений Охотников
Дата: 30.12.05

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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[3]: теоретический вопрос
От: faulx  
Дата: 10.04.06 07:08
Оценка: 13 (1)
Здравствуйте, 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-е. Сервера писать не приходилось, к сожалению. В части клиента — могу помочь, чем смогу.
Re[4]: теоретический вопрос
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 10.04.06 07:48
Оценка:
Здравствуйте, faulx, Вы писали:

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


Извини за offtopic, не мог бы ты с позиции Erlang-а вот эту штуку
Автор: Евгений Охотников
Дата: 30.12.05
покритиковать?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[5]: теоретический вопрос
От: faulx  
Дата: 10.04.06 09:22
Оценка: 5 (1)
Здравствуйте, eao197, Вы писали:

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


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


E>Извини за offtopic, не мог бы ты с позиции Erlang-а вот эту штуку
Автор: Евгений Охотников
Дата: 30.12.05
покритиковать?


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

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

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

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

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


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

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


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

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

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

4. Динамичность Эрланга позволяет осуществлять такие вещи, как изменение на лету как протокола обмена сообщениями, так и кода, эти сообщения обрабатывающего. На лету — значит, без остановки и перезагрузки системы.
Re[4]: теоретический вопрос
От: ironwit Украина  
Дата: 10.04.06 09:24
Оценка:
Здравствуйте, faulx, Вы писали:

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


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


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


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


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

I>>плюсы?

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

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

сразу вопрос. стандарт DA реализовывали сами или использовали сторонние наработки?
... << RSDN@Home 1.2.0 alpha rev. 648>>
Я не умею быть злым, и не хочу быть добрым.
Re[5]: теоретический вопрос
От: faulx  
Дата: 10.04.06 09:42
Оценка: 5 (1)
Здравствуйте, 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. Реализовывал только нужную функциональность, самую простую (запросить данные, получить данные), без всяких асинхронностей и т.п.
Re[6]: теоретический вопрос
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 10.04.06 10:45
Оценка:
Здравствуйте, faulx, Вы писали:

E>>Извини за offtopic, не мог бы ты с позиции Erlang-а вот эту штуку
Автор: Евгений Охотников
Дата: 30.12.05
покритиковать?


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


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[6]: теоретический вопрос
От: ironwit Украина  
Дата: 10.04.06 12:58
Оценка:
Здравствуйте, faulx, Вы писали:

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


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

I>>skip
I>>Здорово буду смотреть в эту сторону внимательнее Совместимости с pascal конечно нет и все драйвера придется переписывать?

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



громадное спасибо заинтересовались этим языком. Есть обсуждения на рсдн чтобы их слить в янус и почитать?
... << RSDN@Home 1.2.0 alpha rev. 648>>
Я не умею быть злым, и не хочу быть добрым.
Re[7]: теоретический вопрос
От: WolfHound  
Дата: 10.04.06 20:44
Оценка: 6 (1)
Здравствуйте, ironwit, Вы писали:

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

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

Но сам OPC сервер всетки лучше писать на VC++. И никаких билдеров ибо OPC сам по себе протокол дурной так еще и билдер со своими тараканами будет под ногами путаться(я пробовал...). Кстати без валидатора, а лучше двух OPC сервер не написать.
Я делал OPC сервер в виде прокси между кучей наших программ скадами. Тебе ИМХО нужно сделать также те OPC сервер сам по себе программы работающие с железками сами по себе. Поднимаешь сервер на томже компе где работает СКАДА чтобы с DCOM'ом не связыватся, а по сетке данные пусть Erlang гоняет.
И еще одно OPC DA1 реализовывать не нужно. Гмороя много, а толку нету. Я занимался этим года два назад и уже тогода все что я видел прекрасно понимало OPC DA2.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.