В индустрии «умных частных домов» денег мы не видим, поэтому обдумываем бесплатное предоставление платформы для DYI проектов. В общем-то по запросу готовы предоставлять лицензии в обмен на короткое описание проекта с несколькими картинками по его завершению.
А вот автоматизация зданий совсем другое дело, там мы активно работаем и развиваем это направление.
SCADA работает под Linux, но OPC сервера естественно только на Windows. Для того, чтобы получить к ним доступ через IP, нужно на Windows настроить DCOM по нашей инструкции.
Да, баня умной не стала, это только «первые шаги».
Про SD карту непонятно. Как она в реальном времени сообщит о проблеме и построит графики?
Про администрирование датчиков: Сделано так:
Подключаем к 1-wire шине новый датчик.
Далее, если мы не знаем его id, то в устройстве «термостат», в меню, выбираем поиск нового датчика. Находим, сохраняем.
Если мы знаем его id, то просто добавляем его в таблицу идентификаторов в AggreGate.
После этого значение нового регистра появится в следующем по порядку регистре температур в таблице в AggreGate.
Замены датчиков пока не было, но все по тому же принципу.
Привязка к месту – можно создать таблицу соответствий в «общих таблицах». Id датчика = описание датчика. Или просто дать правильное имя регистру датчика.
У нас, кстати, в алгоритме реализовано обнаружение хабов и неуправляемых коммутаторов в случаях, когда через них идет более двух линков. Сами они в топологии не рисуются (т.к. неизвестно, сколько там этих хабов стоит), но линки, идущие через них, особым образом помечаются.
А вы сами разрабатывали всю логику обнаружения топологии? Если все это делалось для одной конкретной сети, то усилия впечатляют! Можете рассказать, какие алгоритмы используете для обнаружения неверных связей?
По поводу замечания про алгоритм. Конечно, в его описании мы «срезали углы», чтобы было понятнее. Я попросил разработчиков модуля топологии прокомментировать: Согласны, что это утверждение верно, только в предположении полноты таблиц переадресации на коммутаторах «А» и «Б». Свойство полноты означает, что таблицы содержат все узлы подсети, которым могут быть доставлены пакеты через порты «а» и «б» коммутаторов «А» и «Б», соответственно. Поэтому, если они не соединены напрямую, то существует путь по которому пакеты маршрутизируются из «А» порта «а» в «Б» и из «Б» порта «б» в «А», но так как сеть не содержит циклов, то эти пути будут совпадать и любой промежуточный коммутатор «В» будет виден коммутатором «А» на порту «а» и коммутатором «Б» на порту «б», но тогда рассмотренное нами необходимое условие не выполняется.
В алгоритме автоматического поиска топологии второго уровня мы ставили задачу правильно определить возможные связи между коммутаторами исключив ложные, есть возможность добавить дополнительные связи при необходимости. При неполных таблицах ложные связи можно исключить рассматривая окружение коммутаторов, а именно, так называемое, сквозное множество на порту «а» коммутатора «А» и соответственно, порту «б» коммутатора «Б», это множество всех известных узлов полученных на всех портах коммутатора за исключением выбранного порта. Так вот, если сквозные множества на порту «а» и «б», соответственно, имеют общие узлы, то коммутаторы не могут быть соединены напрямую через порты «а» и «б, при условии, что они находятся в одной подсети.
В целом, конечно, работа модуля обнаружения топологии намного сложнее, чем его краткое описание в статье. Задача статьи — просто рассказать тем, кто не занимался вопросом всерьез, как в целом устроено определение топологии. А ссылочки на статьи мы привели, чтобы те, кто заинтересовался, смогли изучить тему поподробнее.
Вопрос недавно решился радикально путем замены Windows Shell с Explorer'а на наше ПО. Кроме того изменением ключа реестра отключается запуск Task Manager'а и в самом ПО были сделаны доработки для того, чтобы не запускался браузер и другие сторонние программы.
Забавно. У нас тоже в похожем компоненте тоже шрифт, и жалобы пользователей, что не показывается кириллица и различные желаемые ими кракозябры вроде трех горизонтальных полосок %)
При этом у нас модель еще сложней, компонент эмулирует «матрицу светодиодов».
На вебе, к сожалению, нормально будет работать только в Java-версии. В HTML5 видео пойдет через сервер и VNC, будет дергаться и тормозить. Мы знаем, что делать, но это не быстро…
Платформенность продукта накладывает определенные ограничения. Widgets=HMIs, но мы не можем переименовать узел в дереве, так как потребители других решений вообще не в курсе, что такое HMI, а решения объединяются друг с другом на одном сервере.
Модели — это наш основной компонент для построения серверной логики, а PLC дискавери — поиск OPC серверов путем сканирования сегмента IP адресов, потом туда добавятся и другие протоколы.
Про хитрых операторов нам тоже много рассказывают, пока мы предлагали сделать блокировку путем использования сторонних программ, но по ходу это не всех устраивает %)
Да, в копии базы будет абсолютно все, включая события, которые произошли за время работы проекта и не удалились по истечению срока годности. В чем-то это может и не очень хорошо.
Про интерфейс согласен. Гуй и есть из нулевых, первые применяемые сейчас иконки рисовались в 2004-2005. Но тут одним экраном скада не обойтись — надо переделывать всю платформу разом, а это множество продуктов и сотни иконок, экранов и т.д. Дойдет в ближайшее время дело и до этого.
IEC скоро будут все, включая 61850, потому что планируются серьезные проекты в энергетике.
Насчет проектов: если нет удаленки, можно разрабатывать локально, хоть с того же компа, а вечером слить копию базы на флешку и развернуть дома. То есть по сути наша БД сервера и есть «проект».
Удаленная разработка хороша в небольших проектах. Мы имеем возможность помогать нашим партнерам по всему миру, подключаясь к их серверам и разруливая различные сложности в настройке. Куда-нибудь посерьезнее понятное дело не пустят %)
Конечно зависит. На практике при достаточном количестве ресурсов (CPU, RAM) concurrent mode failure не случаются. А если ресурсов не хватает, то и винды пойдут в swap, остановив любую классическую скаду.
Уже ответил Iceg, Wonderware/Schneider мы смотрим. Конечно не копируем, у нас другой подход, но стараемся аналогичный функционал обеспечить и сейчас активнейшим образом над юзабилити работаем.
Ну и веб доводим до ума, он вышел в 5.1, но еще есть что полечить =)
Интересно, что насчет драйверов нас многие ругают — дескать мало у вас, а драйвера=скада. У всех разный подход сложился…
Соглашусь с вами и Kanava, конечно же Schneider скупивший все скады на свете безусловно один из лидеров и мы смотрим и на WSP, и на Citect, чтобы по минимуму косячить при развитии.
И при этом конечно план сделать не просто «yet another SCADA», хочется универсальную платформу построить. WSP в этом смысле импонирует даже названием %)
А вот автоматизация зданий совсем другое дело, там мы активно работаем и развиваем это направление.
Новости мы сейчас публикуем в блоге (http://blog.aggregate.tibbo.com/ru/) и соцсетях, но планируем вернуться на хабр.
Про SD карту непонятно. Как она в реальном времени сообщит о проблеме и построит графики?
Про администрирование датчиков: Сделано так:
По поводу замечания про алгоритм. Конечно, в его описании мы «срезали углы», чтобы было понятнее. Я попросил разработчиков модуля топологии прокомментировать: Согласны, что это утверждение верно, только в предположении полноты таблиц переадресации на коммутаторах «А» и «Б». Свойство полноты означает, что таблицы содержат все узлы подсети, которым могут быть доставлены пакеты через порты «а» и «б» коммутаторов «А» и «Б», соответственно. Поэтому, если они не соединены напрямую, то существует путь по которому пакеты маршрутизируются из «А» порта «а» в «Б» и из «Б» порта «б» в «А», но так как сеть не содержит циклов, то эти пути будут совпадать и любой промежуточный коммутатор «В» будет виден коммутатором «А» на порту «а» и коммутатором «Б» на порту «б», но тогда рассмотренное нами необходимое условие не выполняется.
В алгоритме автоматического поиска топологии второго уровня мы ставили задачу правильно определить возможные связи между коммутаторами исключив ложные, есть возможность добавить дополнительные связи при необходимости. При неполных таблицах ложные связи можно исключить рассматривая окружение коммутаторов, а именно, так называемое, сквозное множество на порту «а» коммутатора «А» и соответственно, порту «б» коммутатора «Б», это множество всех известных узлов полученных на всех портах коммутатора за исключением выбранного порта. Так вот, если сквозные множества на порту «а» и «б», соответственно, имеют общие узлы, то коммутаторы не могут быть соединены напрямую через порты «а» и «б, при условии, что они находятся в одной подсети.
В целом, конечно, работа модуля обнаружения топологии намного сложнее, чем его краткое описание в статье. Задача статьи — просто рассказать тем, кто не занимался вопросом всерьез, как в целом устроено определение топологии. А ссылочки на статьи мы привели, чтобы те, кто заинтересовался, смогли изучить тему поподробнее.
Осталось то же самое провернуть под Linux.
При этом у нас модель еще сложней, компонент эмулирует «матрицу светодиодов».
Вот пара ссылок:
На вебе, к сожалению, нормально будет работать только в Java-версии. В HTML5 видео пойдет через сервер и VNC, будет дергаться и тормозить. Мы знаем, что делать, но это не быстро…
Платформенность продукта накладывает определенные ограничения. Widgets=HMIs, но мы не можем переименовать узел в дереве, так как потребители других решений вообще не в курсе, что такое HMI, а решения объединяются друг с другом на одном сервере.
Модели — это наш основной компонент для построения серверной логики, а PLC дискавери — поиск OPC серверов путем сканирования сегмента IP адресов, потом туда добавятся и другие протоколы.
Про хитрых операторов нам тоже много рассказывают, пока мы предлагали сделать блокировку путем использования сторонних программ, но по ходу это не всех устраивает %)
Про интерфейс согласен. Гуй и есть из нулевых, первые применяемые сейчас иконки рисовались в 2004-2005. Но тут одним экраном скада не обойтись — надо переделывать всю платформу разом, а это множество продуктов и сотни иконок, экранов и т.д. Дойдет в ближайшее время дело и до этого.
Насчет проектов: если нет удаленки, можно разрабатывать локально, хоть с того же компа, а вечером слить копию базы на флешку и развернуть дома. То есть по сути наша БД сервера и есть «проект».
Удаленная разработка хороша в небольших проектах. Мы имеем возможность помогать нашим партнерам по всему миру, подключаясь к их серверам и разруливая различные сложности в настройке. Куда-нибудь посерьезнее понятное дело не пустят %)
Что добавить, что убрать?
Ну и веб доводим до ума, он вышел в 5.1, но еще есть что полечить =)
Интересно, что насчет драйверов нас многие ругают — дескать мало у вас, а драйвера=скада. У всех разный подход сложился…
И при этом конечно план сделать не просто «yet another SCADA», хочется универсальную платформу построить. WSP в этом смысле импонирует даже названием %)