Знакомство с libuniset — библиотекой для создания АСУ

[A1ien]

Спасибо, очень интересная штука, работаю непосредственно в этой теме(промышленная автоматизация) и как раз сейчас стою перед очередным этапом разработки, в которой придется плотно использовать Linux/C++ для промышленной автоматизации.

[EvilsInterrupt]

Поделитесь, зачем? Никогда не видел решения на базе Linux. Как-то на Windows-е :(

[A1ien]

Решения разные бывают, тут должно быть устройстов без морды, исключительно бекграунд сервис, который занимается конверсией протоколов, и архивирование указанного списка параметров их контроллеров, для этого была выбрана железка на ARM, потому что А — дешевая, Б — мало-потребляющая, в ней будет стоять какой нить дебиан, на котором должно что-то крутиться, такая штука как описана в этой статье может быть удачной стартовой платформой.

[ITLav]

«Как-то на Windows'е» решения стабильно вывешивают синий экран? Или могут год проработать без перезагрузки?

[EvilsInterrupt]

>>Или могут год проработать без перезагрузки?
Когда работал в АСУТП на одной из ТЭЦ нашей необъятной родины, то мне не приходилось видеть ситуации когда нужно было перезагружать комп. Как правило, что-то случалось связанное с производством, а не ИТ-спецификой. Минус тогдашнего процесса, то что на бесперебойники экономили (((

[A1ien]

Это домыслы. Вывешивает синий экран не виндовс, а кривые драйвера, даже кривое пользовательское приложение давно не может вывесить синий экран. Если у вас стабильная платформа, конфигурация которой не меняется три раа в месяц, то виндовс решения могут работать без перезагрузки месяцами. Сам недавно реализовывал такое приложение, которое в поле, без какого либо обслуживания крутится по многу месяцев. Писал на .NET+WPF. Были проблемы при разработке, и стабильностью, и как ни странно с очень именитым опен сорс компонентом.

[ITLav]

Что значит домыслы? Это реальность вокруг: зависшие табло с рекламой и информацией в офис. центрах и вокзалах, зависшие банкоматы, перезагрузка компьютера в почтовом отделении. И как-то всё равно, что ядро в Windows идеальное, а вот драйвера к железу не отлажены. Суть, наверное, в другом. Windows снижает порог вхождения. Как PHP. Это значит, что специалист меньшей квалификации может написать программу и она заработает. Но это не означает, что он может написать хорошую программу.
Не очень понятно из фразы, что за проблемы при разработке и стабильностью.
И что же вы не назвали этот именитый опенсорс компонент? Страна должна знать своих героев.

[A1ien]

SqLite, проблемы конечно были объективно не в нем в самом, а в том, в каком окружении он применялся, но как мне кажется, компонент, основное применение которого встраиваемые решения, должен был бы заострять внимание на той проблеме которая у меня возникла. Если коротко, то проблема была в непрерывном создание/удалении файла журнала, что при использовании в сочетании копакт-флеш диском, приводило к порче оного(диска) через 2 месяца работы, со всеми вытекающими. Просто если вы просто часто пишете на CF данные, то они пишутся циклически, и одни и те-же ячейки флеша не используются часто, что не приводит к отказу, если же вы будете раз в секунду создавать/удалять файл с одним и тем же названием — это приводит к непрерывной модификации одной и тойже ячейки, что для флеша смертельно.

[A1ien]

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

[ITLav]

Да, вы правы, таких факторов много. И в общем-то в совокупности они вполне оправдывают создание решений на Windows. Интеграция с существующей инфраструктурой сильна похожа на пресловутую совместимость, которая была основной картой Microsoft при изгнании других игроков с рынка. Это очень удобно, когда твои программные продукты совместимы… только с твоими же продуктами :)
Дальнейшее обслуживание — весомый аргумент. В случае АСУ ТП часто требуется вмешательство местных инженеров при изменении процедуры производства. Но есть случаи, когда система поставляется в закрытой коробке и вмешательства не требуется.

В общем, в каждом случае, конечно, требуется выбор, исходя из обстоятельств. Но Windows никогда не являлась и не является универсальной платформой на все случаи жизни. Тем более, лучшей по техническим характеристикам. Иначе бы не существовало, например, QNX или Solaris.

[A1ien]

Никто не говорил слово лучшая, любое решение принимается по совокупности многих факторов, таких как цена решения/стоимость разработки/обслуживание и еще много других. В нашем случае решение на Windows было оправдан тогда, сейчас оправдано решение на Linux :)

[PavelVainerman]

может стоит тогда попробовать эту? ;)

[zhogar]

— ввод/вывод;
— сетевой обмен;
— процессы управления (алгоритмы);
— хранение данных;
— работа с БД.

— транзакции;

[PavelVainerman]

с точки зрения «АСУ», что вы имеете ввиду?

[zhogar]

В основные направления также стоит включить «транзакции», в не «сетевого обмена», в АСУ должна присутствовать единица отката/подтверждения операции, допустим транзакция АСУ какого либо диспетчерского пункта.
Я это имел введу.

[PavelVainerman]

я конечно не совсем понял, всё-таки что имелось ввиду… но в любом случае… если речь об управлении — это часть темы «Алгоритмы»,
если это речь об общепринятом понимании транзакций, как части относящейся к БД — то собственно это тема «работа с БД».
Под направлениями, я именно это имел ввиду.

[Iceg]

Я правильно понял, это можно использовать как альтернативу OPC-серверу?

[A1ien]

Думаю что не совсем, это можно использовать как каркас для создания OPC сервера, при этом реализацию части отвечающей за OPC вам придется делать самому.

[PavelVainerman]

Да, если под альтернативой понимать «назначение». В данном случае аналогом OPC-сервера является компонент названный SharedMemory(SM). Т.е. хранилище значений всех переменных, уведомляющее всех «заказчиков» об изменениях. Но в строгом смысле это всё-таки не OPC-сервер, т.к. не соответствует спецификации для OPC-серверов. OPC-сервера — заточены на windows-технологии.
При этом, как я писал в конце, систему построенную с использованием libuniset легко можно интегрировать в другую систему в том числе, она может взаимодействовать с любым OPC-сервером по протоколу Modbus (RTU или TCP) выступая в качестве slave-устройства. Т.е. вы можете на контроллере всё построить на libuniset с Linux и дополнительно запустить ModbusSlave (готовый компонент), который будет брать значения из SM и отдавать в ответ на запросы внешнего OPC-сервера.

[chubuk]

Павел, а пробовали это все собирать и работать на linux arm процессорах? Так как у меня сейчас стоит задача именно сделать modbus tcp2rtu slave контроллер(gateway) на ARM-linux на борту.

[PavelVainerman]

К сожалению нет, пока не было такой необходимости. НО! т.к. разработка базируется на ALTLinux, у них вроде есть отдельный репозиторий пересобранных под ARM пакетов. То предполагаю, если в этом репозитории есть всё необходимое для сборки libuniset (а вроде есть),
то и libuniset сам по себе соберётся, т.к. какого-то специального архитектурно-зависимого кода в себе не содержит.

[PavelVainerman]

Так… меня тут поправили знающие люди. Оказывается сборка libuniset под ARM уже есть.

ftp.altlinux.ru/pub/distributions/ALTLinux/Sisyphus/arm/RPMS.classic

[PavelVainerman]

заодно: у вас задача сделать просто шлюз modbus TCP<-->RTU или там что-то интеллектуальное с какой-то своей логикой?
А то готовые шлюзы именно для этой задачи существуют и относительно не дорого.

[chubuk]

Да, я находил такие шлюзы. Но хочется уложиться в меньшие деньги, да и на контроллер задумал завести больше задач, чем шлюз. Если у меня получется — обязательно отпишу вам.

[PavelVainerman]

Хорошо. Пишите и если будут вопросы по использованию…