Итак. Задача — разработать сервер который обчитывает приборы по СОМ порту и передает их по ОРС технологии в СКАДА системы. Поддержка распереденной работы (неск. серверов на неск. машинах), поддержка передачи данных по медленным каналам (прослойка между ОРС сервером одной машины и клиентом СКАДА на другой). ну и еще кое какие мелочи — БД, лицензирование (колво и типы приборов) итд.
Какой язык советовали бы? Приветствуются любые идеи. Будем ломать стереотипы
Здравствуйте, 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%. Аварии на ПС сейчас стали обычным явлением, правда, не таким масштабным как в Москве.
Это клиент и OPC XML http://www.kassl.de/opc/index.shtml
I>Я тут слышал про семейство дотнет. Типа он и так весь насквозь интерфейсный... типа на нем вообще просто ОРС делать
не легче чем на Delphi. Добавляется проблема перейти с Delphi на дотнет.
В зависимости от задачи — рекомендация взять готовый продукт (СКАДУ) у
тех кто этим занимается профессионально, дописывая только свои особенности.
Здравствуйте, ironwit, Вы писали:
I>Итак. Задача — разработать сервер который обчитывает приборы по СОМ порту и передает их по ОРС технологии в СКАДА системы. Поддержка распереденной работы (неск. серверов на неск. машинах), поддержка передачи данных по медленным каналам (прослойка между ОРС сервером одной машины и клиентом СКАДА на другой). ну и еще кое какие мелочи — БД, лицензирование (колво и типы приборов) итд.
I>Какой язык советовали бы? Приветствуются любые идеи. Будем ломать стереотипы
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, iZEN, Вы писали:
AVK>.NET как причина сбоев в энергосети России. Сильно, я в восторге.
не надо перекручивать. А то становится очень похоже на разговор о политике
спасибо за ссылки. посмотрю и прочитаю внимательно
I>>Я тут слышал про семейство дотнет. Типа он и так весь насквозь интерфейсный... типа на нем вообще просто ОРС делать
S>не легче чем на Delphi. Добавляется проблема перейти с Delphi на дотнет.
S>В зависимости от задачи — рекомендация взять готовый продукт (СКАДУ) у S>тех кто этим занимается профессионально, дописывая только свои особенности.
скада есть. необходим все таки сервер который будет обчитывать приборы. Приборов много. на все — не напасешься ОРС серверов от разработчиков приборов. да и не так все просто их в кучу увязать.
Здравствуйте, 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-а вот эту штуку
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, faulx, Вы писали:
F>>Минимизация проблем с многопоточностью, распределенностью, отказоустойчивостьюи и real-time-ом. Есть некоторый опыт решения задач, похожих на описанную, и я пришел именно к этому выводу — Erlang.
E>Извини за offtopic, не мог бы ты с позиции Erlang-а вот эту штуку
Прочитал пока на один раз, впечатление поэтому пока сумбурное.
Честно говоря, даже не знаю, как критиковать. Я тоже когда-то писал нечто подобное, попроще, правда. Ну что, еще один механизм обмена сообщениями. Некоторая дисциплина — здесь такая, у других другая. Ну ладно, вот замечания, возможно, глупые:
1. "Тяжеловесность" потоков накладывает отпечаток на архитектурные решения — много говорится о диспетчерах, нитях, контекстах и т.п. В Эрланге потоки легкие, и голова об этом болит только у разработчиков рантайма — головастых парней из Швеции
2. Рассуждения о синхронности и асинхронности. С точки зрения Эрланга синхронность — это нечто, что легко может быть построено над асинхронностью. Т.е. если имеем механизм посылки сообщения Pid!Message (потоку Pid посылается сообщение Message), то можно над этим сделать синхронность:
Надеюсь, понятно: посылаем сообщение, ждем ответа. Если ответа нужно ждать не бесконечность, а не больше некоторого времени (здравствуй, real-time!), то пишем:
Ну и самое главное: на самом деле этого писать не придется, все уже написано до нас и включено в стандартные поведения 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, Вы писали:
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.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
