Modbus для 1С

[tonyk]

Коллеги!
Возникла задача писАть в 1С кое-какие данные из ПЛК. В ПЛК, ессно, присутствует Modbus в ипостасях RTU и TCP. Вопрос: есть ли для 1С готовый, пусть даже и платный, клиент Модбас? А лучше сервер, тогда ПЛК сможет сразу записывать данные в него.

[Михайло]

https://infostart.ru/public/1244318/

[petr2off]

Мне сама идея пускать 1С в сетку с ПЛК не нравится категорически. Офисная сеть и сеть АСУ ТП должны быть разнесены по разным подсетям.
Более правильно, как мне кажется - Поставить сервер с 2 сетевыми интерфейсами с SQL сервером. АСУ ТП по своему интерфейсу пишет в базу данных нужные данные, а 1С берет их с SQL сервера - что для нее вполне просто.

[tonyk]

petr2off, я тоже склоняюсь к такому же варианту, просто решил проработать вопрос со всех сторон. Кстати, АСУ ТП бывают разные, например, та, с которой я столкнулся, буквально пара ПЛК и ПК с 1С, на которой в автоматическом режиме ведётся учёт продукции. Поэтому решил обдумать и тот вариант, который озвучил в теме.

[rwg]

Есть ли для 1С готовый, пусть даже и платный, клиент Модбас?

Я бы искал переходник 1С - OPC сервер

[tonyk]

Есть ли для 1С готовый, пусть даже и платный, клиент Модбас?

Я бы искал переходник 1С - OPC сервер

Есть такие. Но есть СКАДА, которые работают без ОРС, потому что драйвер для Модбас в них встроен.

[Никита]

Я бы искал переходник 1С - OPC сервер

ODBC называется :) Причем может быть в разных ипостасях - как клиент ODBC в OPC-сервере, как механизм обмена в скаде или вообще подключенная SQL-таблица трендами. Пускать 1С (со всеми тетками) в архивы АСУ, как уже отмечалось, настоятельно не рекомендуется. А вот выкладывать средствами одного и читать средствами другого череж промежуточную DMZ - может быть вполне приемлемо.

[Sokolov_Dmitry]

https://www.aggsoft.ru/tcpip-data-logge ... ling-1.htm

[Andreywys]

У меня службой по modbus собираются данные и пишутся в базу mssql, а 1с забирает из базы.
https://github.com/AndreyVys/ModbusToBa ... Service.vb
Из оборудования - moxa nport 5150 для RTU
Если решите допиливать самостоятельно, то читайте вот эту тему https://owen.ru/forum/showthread.php?t=20122

[Velt]

Можно написать на Питоне скрипт, который опрашивает ПЛК по Modbus TCP и кладёт данные в таблицу БД. Оттуда уже 1С какие надо данные выгружает.

[Jackson]

Можно написать на Питоне скрипт, который опрашивает ПЛК по Modbus TCP и кладёт данные в таблицу БД

И готового такого тоже уже может быть много. Хоть в SQL, хоть в .XLS.

[VADR]

Но нередко в таких мерах нет необходимости. Надо посмотреть, какой вообще функционал требуется на предприятии кроме этой стыковки с 1С. То есть: нужна ли там система оперативно-диспетчерского управления или нет, нужна ли какая-то аналитика технологической информации или нет, и т.п. по уровню между контроллерами и 1С. Вполне возможно, оптимальным будет внедрение по всему предприятию единой системы, собирающей данные с локальных контроллеров, хранящей у себя, ведущей какую-то технологическую аналитику (материальные и энергетические балансы, например), и предоставляющую доступ к этим данным для 1С, например, через ODBC или какой-нибудь web xml. Для одной задачи это будет избыточно, а если на все задачи предприятия по этому уровню - на каждой такой задаче в среднем окажется дешевле.

[keysansa]

Мне сама идея пускать 1С в сетку с ПЛК не нравится категорически. Офисная сеть и сеть АСУ ТП должны быть разнесены по разным подсетям.
Более правильно, как мне кажется - Поставить сервер с 2 сетевыми интерфейсами с SQL сервером. АСУ ТП по своему интерфейсу пишет в базу данных нужные данные, а 1С берет их с SQL сервера - что для нее вполне просто.

2 сетевые карты лишние. Разделение сетей не должно быть на уровне устройства. Это делить нужно на уровне маршрутизатора и/или брандмаура.
На стороне ПЛК закрыть все входящие соединения. Исходящие тоже лишние закрыть (Quod licet jovi, non licet bovi). Общение через ДМЗ. Где и будет общий сервер.

Отправлено спустя 4 минуты 39 секунд:

Но нередко в таких мерах нет необходимости. Надо посмотреть, какой вообще функционал требуется на предприятии кроме этой стыковки с 1С.

Никогда разделение не мешает безопасности. Создает проблемы в работе - да. Как и всякая проблема безопасности.
И никогда дополнительная безопасность, если она не мешает работе, не является проблемой.

Отправлено спустя 1 минуту 53 секунды:

Вполне возможно, оптимальным будет внедрение по всему предприятию единой системы, собирающей данные с локальных контроллеров, хранящей у себя, ведущей какую-то технологическую аналитику (материальные и энергетические балансы, например), и предоставляющую доступ к этим данным для 1С, например, через ODBC или какой-нибудь web xml.

Безопаснее будет, если контроллеры будут отсылать информацию на промежуточный сервер.

[VADR]

Никогда разделение не мешает безопасности.

Я не о разделении говорил и не о безопасности, а о питоновских скриптах, опрашивающих контроллер по модбасу по запросу от 1С.

Безопаснее будет, если контроллеры будут отсылать информацию на промежуточный сервер.

Да, примерно так. Промежуточный сервер, на который собирается информация с контроллеров. Это может быть как сервер, выделенный просто для хранения информации, так и сервер в составе системы АСОДУ, MES или ещё чего-либо в том же духе. Насчёт того, контроллер туда данные кладёт, или эта система контроллеры опрашивает - вопрос открытый. В любом случае надо стремиться к тому, чтобы контроллер как можно меньше был зависим от внешних систем. И тут есть несколько вариантов проблем:
1. Контроллер кладёт данные на внешний сервер, например, по modbus tcp. Что будет, если этот сервер ляжет и контроллер не сможет к нему подключиться? Что будет, если сервер начнёт тупить и процесс обмена данными затянется?
2. Внешняя система запрашивает данные из контроллера. Что будет, если злоумышленник завладеет этим сервером и он начнёт посылать хренову тучу запросов, а то ещё и хитрых запросов, чтобы DOS устроить? Вряд ли контроллеры на такую активность рассчитаны.
3. Есть промежуточный OPC-сервер в сети контроллера или DMZ, который один опрашивает контроллер с заданной периодичностью. На мой взгляд, вариант оптимальный: контроллеру по большому счёту пофиг, если его перестали опрашивать. Если злоумышленник положит наш промежуточный OPC-сервер, большой беды не будет, разве что прекращение обмена данными на некоторое время. С другой стороны - дополнительное оборудование - дополнительная точка отказа.

[keysansa]

Я не о разделении говорил и не о безопасности, а о питоновских скриптах, опрашивающих контроллер по модбасу по запросу от 1С.

Я не против, если они запускаются ИЗ контроллера. Открывать доступ извне - всегда понижение безопасности.

Отправлено спустя 1 минуту 37 секунд:

Промежуточный сервер, на который собирается информация с контроллеров.

На который сами контроллеры будут отсылать информацию. Только ту, что решит разработчик.

Отправлено спустя 2 минуты 28 секунд:

Насчёт того, контроллер туда данные кладёт, или эта система контроллеры опрашивает - вопрос открытый.

С точки зрения безопасности - закрыт и давно.
Входящих соединений не должен принимать контроллер. Да, это накладывает ограничения на обслуживание. Но тут решать будут ответственные лица. И это закрытый вопрос.

Отправлено спустя 1 минуту 47 секунд:

1. Контроллер кладёт данные на внешний сервер, например, по modbus tcp. Что будет, если этот сервер ляжет и контроллер не сможет к нему подключиться?

Вы с точки зрения безопасности спрашиваете - запишет контроллер себе ошибку и все. Связи у него с внешним миром нет. Если есть еще каналы - туда отправит сообщение.

Отправлено спустя 5 минут 56 секунд:

Что будет, если сервер начнёт тупить и процесс обмена данными затянется?

Это уже давно решено асинхронным обменом.

Внешняя система запрашивает данные из контроллера.

С точки зрения безопасности - уже дыра. Просто закрыть дыру.

Есть промежуточный OPC-сервер в сети контроллера или DMZ, который один опрашивает контроллер с заданной периодичностью. На мой взгляд, вариант оптимальный: контроллеру по большому счёту пофиг, если его перестали опрашивать.

Это не OPC сервер, а OPC клиент, как мы недавно выяснили ))
Плюс, сеть контроллера не должна быть в DMZ.
Контроллер умеет в SSL?

Отправлено спустя 4 минуты 9 секунд:

Если злоумышленник положит наш промежуточный OPC-сервер, большой беды не будет, разве что прекращение обмена данными на некоторое время. С другой стороны - дополнительное оборудование - дополнительная точка отказа.

Это еще будет повод усилить меры безопасности.
Вопрос будет, какого уровня доступа данный OPC сервер

[Velt]

Можно написать на Питоне скрипт, который опрашивает ПЛК по Modbus TCP и кладёт данные в таблицу БД

И готового такого тоже уже может быть много. Хоть в SQL, хоть в .XLS.

Так и я о том. В Питоне много готовых пакетов. Поэтому скрипт можно написать быстро. А если вручную с нуля модбас-протокол писать - то ну его нафиг....

[Andreywys]

В Питоне много готовых пакетов.

Можно хоть на каком языке написать, библиотеки modbus есть для всех популярных языков.

[Jackson]

Можно хоть на каком языке написать

Я предлагал взять уже написанное.

[Velt]

В Питоне много готовых пакетов.

Можно хоть на каком языке написать, библиотеки modbus есть для всех популярных языков.

Вы правы, просто лично я с PyCharm только недавно познакомился и меня приятно удивило, как можно легко и быстро найти и установить нужные библиотеки, даже не открывая браузер.

[Andreywys]

Вы правы, просто лично я с PyCharm только недавно познакомился и меня приятно удивило, как можно легко и быстро найти и установить нужные библиотеки, даже не открывая браузер.

Это позволяет и visual studio, и многие другие ide. Но python не совсем удобен для windows, по моему скромному мнению.

Я предлагал взять уже написанное.

Зачастую уже написанное не совсем подходит или сильно геморное в настройке. У меня есть купленный advanced tcp data logger, но пришлось заморочиться и написать свое. Например, обмен life bit или хитрая обработка данных. И тогда проще написать свой код, чем пытаться разобраться в настройках готовой программы, писать обработку в хранимых процедурах на sql сервере и т.п. Но, в случае, если нужно просто взять несколько переменных и положить их в базу, то готовое решение вполне подходит, особенно, если нет навыка программирования на каком-нибудь языке.

[keysansa]

Это позволяет и visual studio, и многие другие ide. Но python не совсем удобен для windows, по моему скромному мнению.

python pip вам очень сильно поможет с установкой зависимостей.

Отправлено спустя 2 минуты 47 секунд:

Например, обмен life bit или хитрая обработка данных. И тогда проще написать свой код, чем пытаться разобраться в настройках готовой программы

Часто людям легче написать свое, это есть. Но человек пишущий всегда свое - отстает по скорости разработки, и по размеру результата.
Но если платят за объем кода, тогда согласен.

[Andreywys]

python pip вам очень сильно поможет с установкой зависимостей

Собственно как и composter в php, nuget в visual studio, npm в node.js и т.д.
И, если бы я писал для linux консольное приложение, то наверняка использовал бы python.

[keysansa]

python pip вам очень сильно поможет с установкой зависимостей

Собственно как и composter в php, nuget в visual studio, npm в node.js и т.д.

Да, согласен, кроме node, и php (там pear) это другая тема.

И, если бы я писал для linux консольное приложение, то наверняка использовал бы python.
Вернуться к началу

Что вам удобнее, я для консоли использую С

[Andreywys]

Я не "настоящий сварщик", поэтому С, кроме arduino ide, больше нигде не использую. В windows vs с .net, в линукс bash и python.