Comments 25
Спасибо, очень интересная штука, работаю непосредственно в этой теме(промышленная автоматизация) и как раз сейчас стою перед очередным этапом разработки, в которой придется плотно использовать Linux/C++ для промышленной автоматизации.
Поделитесь, зачем? Никогда не видел решения на базе Linux. Как-то на Windows-е :(
Решения разные бывают, тут должно быть устройстов без морды, исключительно бекграунд сервис, который занимается конверсией протоколов, и архивирование указанного списка параметров их контроллеров, для этого была выбрана железка на ARM, потому что А — дешевая, Б — мало-потребляющая, в ней будет стоять какой нить дебиан, на котором должно что-то крутиться, такая штука как описана в этой статье может быть удачной стартовой платформой.
«Как-то на Windows'е» решения стабильно вывешивают синий экран? Или могут год проработать без перезагрузки?
>>Или могут год проработать без перезагрузки?
Когда работал в АСУТП на одной из ТЭЦ нашей необъятной родины, то мне не приходилось видеть ситуации когда нужно было перезагружать комп. Как правило, что-то случалось связанное с производством, а не ИТ-спецификой. Минус тогдашнего процесса, то что на бесперебойники экономили (((
Когда работал в АСУТП на одной из ТЭЦ нашей необъятной родины, то мне не приходилось видеть ситуации когда нужно было перезагружать комп. Как правило, что-то случалось связанное с производством, а не ИТ-спецификой. Минус тогдашнего процесса, то что на бесперебойники экономили (((
Это домыслы. Вывешивает синий экран не виндовс, а кривые драйвера, даже кривое пользовательское приложение давно не может вывесить синий экран. Если у вас стабильная платформа, конфигурация которой не меняется три раа в месяц, то виндовс решения могут работать без перезагрузки месяцами. Сам недавно реализовывал такое приложение, которое в поле, без какого либо обслуживания крутится по многу месяцев. Писал на .NET+WPF. Были проблемы при разработке, и стабильностью, и как ни странно с очень именитым опен сорс компонентом.
Что значит домыслы? Это реальность вокруг: зависшие табло с рекламой и информацией в офис. центрах и вокзалах, зависшие банкоматы, перезагрузка компьютера в почтовом отделении. И как-то всё равно, что ядро в Windows идеальное, а вот драйвера к железу не отлажены. Суть, наверное, в другом. Windows снижает порог вхождения. Как PHP. Это значит, что специалист меньшей квалификации может написать программу и она заработает. Но это не означает, что он может написать хорошую программу.
Не очень понятно из фразы, что за проблемы при разработке и стабильностью.
И что же вы не назвали этот именитый опенсорс компонент? Страна должна знать своих героев.
Не очень понятно из фразы, что за проблемы при разработке и стабильностью.
И что же вы не назвали этот именитый опенсорс компонент? Страна должна знать своих героев.
SqLite, проблемы конечно были объективно не в нем в самом, а в том, в каком окружении он применялся, но как мне кажется, компонент, основное применение которого встраиваемые решения, должен был бы заострять внимание на той проблеме которая у меня возникла. Если коротко, то проблема была в непрерывном создание/удалении файла журнала, что при использовании в сочетании копакт-флеш диском, приводило к порче оного(диска) через 2 месяца работы, со всеми вытекающими. Просто если вы просто часто пишете на CF данные, то они пишутся циклически, и одни и те-же ячейки флеша не используются часто, что не приводит к отказу, если же вы будете раз в секунду создавать/удалять файл с одним и тем же названием — это приводит к непрерывной модификации одной и тойже ячейки, что для флеша смертельно.
А что касательно порога вхождения, возможно вы где-то и правы, но не все замыкается на порог вхождения. Есть еще интеграция с существующей инфраструктурой, дальнейшее обслуживание(люди которые будут пользоваться продуктом) итд…
Да, вы правы, таких факторов много. И в общем-то в совокупности они вполне оправдывают создание решений на Windows. Интеграция с существующей инфраструктурой сильна похожа на пресловутую совместимость, которая была основной картой Microsoft при изгнании других игроков с рынка. Это очень удобно, когда твои программные продукты совместимы… только с твоими же продуктами :)
Дальнейшее обслуживание — весомый аргумент. В случае АСУ ТП часто требуется вмешательство местных инженеров при изменении процедуры производства. Но есть случаи, когда система поставляется в закрытой коробке и вмешательства не требуется.
В общем, в каждом случае, конечно, требуется выбор, исходя из обстоятельств. Но Windows никогда не являлась и не является универсальной платформой на все случаи жизни. Тем более, лучшей по техническим характеристикам. Иначе бы не существовало, например, QNX или Solaris.
Дальнейшее обслуживание — весомый аргумент. В случае АСУ ТП часто требуется вмешательство местных инженеров при изменении процедуры производства. Но есть случаи, когда система поставляется в закрытой коробке и вмешательства не требуется.
В общем, в каждом случае, конечно, требуется выбор, исходя из обстоятельств. Но Windows никогда не являлась и не является универсальной платформой на все случаи жизни. Тем более, лучшей по техническим характеристикам. Иначе бы не существовало, например, QNX или Solaris.
может стоит тогда попробовать эту? ;)
— ввод/вывод;
— сетевой обмен;
— процессы управления (алгоритмы);
— хранение данных;
— работа с БД.
— транзакции;
Я правильно понял, это можно использовать как альтернативу OPC-серверу?
Думаю что не совсем, это можно использовать как каркас для создания OPC сервера, при этом реализацию части отвечающей за OPC вам придется делать самому.
Да, если под альтернативой понимать «назначение». В данном случае аналогом OPC-сервера является компонент названный SharedMemory(SM). Т.е. хранилище значений всех переменных, уведомляющее всех «заказчиков» об изменениях. Но в строгом смысле это всё-таки не OPC-сервер, т.к. не соответствует спецификации для OPC-серверов. OPC-сервера — заточены на windows-технологии.
При этом, как я писал в конце, систему построенную с использованием libuniset легко можно интегрировать в другую систему в том числе, она может взаимодействовать с любым OPC-сервером по протоколу Modbus (RTU или TCP) выступая в качестве slave-устройства. Т.е. вы можете на контроллере всё построить на libuniset с Linux и дополнительно запустить ModbusSlave (готовый компонент), который будет брать значения из SM и отдавать в ответ на запросы внешнего OPC-сервера.
При этом, как я писал в конце, систему построенную с использованием libuniset легко можно интегрировать в другую систему в том числе, она может взаимодействовать с любым OPC-сервером по протоколу Modbus (RTU или TCP) выступая в качестве slave-устройства. Т.е. вы можете на контроллере всё построить на libuniset с Linux и дополнительно запустить ModbusSlave (готовый компонент), который будет брать значения из SM и отдавать в ответ на запросы внешнего OPC-сервера.
Павел, а пробовали это все собирать и работать на linux arm процессорах? Так как у меня сейчас стоит задача именно сделать modbus tcp2rtu slave контроллер(gateway) на ARM-linux на борту.
К сожалению нет, пока не было такой необходимости. НО! т.к. разработка базируется на ALTLinux, у них вроде есть отдельный репозиторий пересобранных под ARM пакетов. То предполагаю, если в этом репозитории есть всё необходимое для сборки libuniset (а вроде есть),
то и libuniset сам по себе соберётся, т.к. какого-то специального архитектурно-зависимого кода в себе не содержит.
то и libuniset сам по себе соберётся, т.к. какого-то специального архитектурно-зависимого кода в себе не содержит.
Так… меня тут поправили знающие люди. Оказывается сборка libuniset под ARM уже есть.
ftp.altlinux.ru/pub/distributions/ALTLinux/Sisyphus/arm/RPMS.classic
ftp.altlinux.ru/pub/distributions/ALTLinux/Sisyphus/arm/RPMS.classic
заодно: у вас задача сделать просто шлюз modbus TCP<-->RTU или там что-то интеллектуальное с какой-то своей логикой?
А то готовые шлюзы именно для этой задачи существуют и относительно не дорого.
А то готовые шлюзы именно для этой задачи существуют и относительно не дорого.
Sign up to leave a comment.
Знакомство с libuniset — библиотекой для создания АСУ