Как стать автором
Обновить

Комментарии 25

Спасибо, очень интересная штука, работаю непосредственно в этой теме(промышленная автоматизация) и как раз сейчас стою перед очередным этапом разработки, в которой придется плотно использовать Linux/C++ для промышленной автоматизации.
Поделитесь, зачем? Никогда не видел решения на базе Linux. Как-то на Windows-е :(
Решения разные бывают, тут должно быть устройстов без морды, исключительно бекграунд сервис, который занимается конверсией протоколов, и архивирование указанного списка параметров их контроллеров, для этого была выбрана железка на ARM, потому что А — дешевая, Б — мало-потребляющая, в ней будет стоять какой нить дебиан, на котором должно что-то крутиться, такая штука как описана в этой статье может быть удачной стартовой платформой.
«Как-то на Windows'е» решения стабильно вывешивают синий экран? Или могут год проработать без перезагрузки?
>>Или могут год проработать без перезагрузки?
Когда работал в АСУТП на одной из ТЭЦ нашей необъятной родины, то мне не приходилось видеть ситуации когда нужно было перезагружать комп. Как правило, что-то случалось связанное с производством, а не ИТ-спецификой. Минус тогдашнего процесса, то что на бесперебойники экономили (((
Это домыслы. Вывешивает синий экран не виндовс, а кривые драйвера, даже кривое пользовательское приложение давно не может вывесить синий экран. Если у вас стабильная платформа, конфигурация которой не меняется три раа в месяц, то виндовс решения могут работать без перезагрузки месяцами. Сам недавно реализовывал такое приложение, которое в поле, без какого либо обслуживания крутится по многу месяцев. Писал на .NET+WPF. Были проблемы при разработке, и стабильностью, и как ни странно с очень именитым опен сорс компонентом.
Что значит домыслы? Это реальность вокруг: зависшие табло с рекламой и информацией в офис. центрах и вокзалах, зависшие банкоматы, перезагрузка компьютера в почтовом отделении. И как-то всё равно, что ядро в Windows идеальное, а вот драйвера к железу не отлажены. Суть, наверное, в другом. Windows снижает порог вхождения. Как PHP. Это значит, что специалист меньшей квалификации может написать программу и она заработает. Но это не означает, что он может написать хорошую программу.
Не очень понятно из фразы, что за проблемы при разработке и стабильностью.
И что же вы не назвали этот именитый опенсорс компонент? Страна должна знать своих героев.
SqLite, проблемы конечно были объективно не в нем в самом, а в том, в каком окружении он применялся, но как мне кажется, компонент, основное применение которого встраиваемые решения, должен был бы заострять внимание на той проблеме которая у меня возникла. Если коротко, то проблема была в непрерывном создание/удалении файла журнала, что при использовании в сочетании копакт-флеш диском, приводило к порче оного(диска) через 2 месяца работы, со всеми вытекающими. Просто если вы просто часто пишете на CF данные, то они пишутся циклически, и одни и те-же ячейки флеша не используются часто, что не приводит к отказу, если же вы будете раз в секунду создавать/удалять файл с одним и тем же названием — это приводит к непрерывной модификации одной и тойже ячейки, что для флеша смертельно.
А что касательно порога вхождения, возможно вы где-то и правы, но не все замыкается на порог вхождения. Есть еще интеграция с существующей инфраструктурой, дальнейшее обслуживание(люди которые будут пользоваться продуктом) итд…
Да, вы правы, таких факторов много. И в общем-то в совокупности они вполне оправдывают создание решений на Windows. Интеграция с существующей инфраструктурой сильна похожа на пресловутую совместимость, которая была основной картой Microsoft при изгнании других игроков с рынка. Это очень удобно, когда твои программные продукты совместимы… только с твоими же продуктами :)
Дальнейшее обслуживание — весомый аргумент. В случае АСУ ТП часто требуется вмешательство местных инженеров при изменении процедуры производства. Но есть случаи, когда система поставляется в закрытой коробке и вмешательства не требуется.

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

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

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

Павел, а пробовали это все собирать и работать на linux arm процессорах? Так как у меня сейчас стоит задача именно сделать modbus tcp2rtu slave контроллер(gateway) на ARM-linux на борту.
К сожалению нет, пока не было такой необходимости. НО! т.к. разработка базируется на ALTLinux, у них вроде есть отдельный репозиторий пересобранных под ARM пакетов. То предполагаю, если в этом репозитории есть всё необходимое для сборки libuniset (а вроде есть),
то и libuniset сам по себе соберётся, т.к. какого-то специального архитектурно-зависимого кода в себе не содержит.
заодно: у вас задача сделать просто шлюз modbus TCP<-->RTU или там что-то интеллектуальное с какой-то своей логикой?
А то готовые шлюзы именно для этой задачи существуют и относительно не дорого.
Да, я находил такие шлюзы. Но хочется уложиться в меньшие деньги, да и на контроллер задумал завести больше задач, чем шлюз. Если у меня получется — обязательно отпишу вам.
Хорошо. Пишите и если будут вопросы по использованию…
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории