На форуме обязательно:
  1. Заполнить свой профиль НА РУССКОМ ЯЗЫКЕ КИРИЛЛИЦЕЙ. См. Правила, п.2.d.
  2. Не писать свой вопрос в первую попавшуюся тему, а вместо этого создать свою. См. Правила, п.3.a.

Рекламу мы не размещаем ни на каких условиях.

Передача данных через VPN канал.

Ответить
Аватара пользователя

Автор темы
VADR
администратор
администратор
Сообщения: 2851
Зарегистрирован: 25 июл 2008, 06:12
Имя: Диев Александр Васильевич
Благодарил (а): 60 раз
Поблагодарили: 44 раза

Передача данных через VPN канал.

Сообщение VADR » 10 янв 2018, 11:31

Приветствую, коллеги.

Вопрос чисто теоретический (по крайней мере, пока). Допустим есть две системы управления на базе симатиков, расположенные в разных цехах. Данные из одной системы нужны в другой (а также наоборот, количество данных небольшое). Каждая из систем через маршрутизатор/файрвол с поддержкой VPN подключена к общей сети, примерно как на рисунке, с той лишь разницей, что это два отдельных проекта, общего проекта соединения нет (я просто для примера нарисовал):
screen_simatic_netw.jpg
Вопрос в следующем: можно ли настроить VPN-канал между роутерами и через него гонять данные? И если можно, что для этого надо? Ссылка на мануал очень желательна.
У вас нет необходимых прав для просмотра вложений в этом сообщении.
Повторное использование кода не отменяет повторного использования мозга при его повторном использовании.


Михайло
почётный участник форума
почётный участник форума
Сообщения: 2630
Зарегистрирован: 10 ноя 2009, 04:58
Имя: Толмачев Михаил Алексеевич
Благодарил (а): 1 раз
Поблагодарили: 77 раз
Контактная информация:

Передача данных через VPN канал.

Сообщение Михайло » 10 янв 2018, 16:20

На всякий случай сообщу, что если активировать Profinet-функцию iDevice, то обмен данными между контроллерами в двух разных проектах станет организовать намного проще. Я только не пробовал.

Почитай эту тему, про iDevice. Кури мануал " I-Device in a standard environment".

Это никак не связано с VPN и Security, но тоже нужно.

Аватара пользователя

Автор темы
VADR
администратор
администратор
Сообщения: 2851
Зарегистрирован: 25 июл 2008, 06:12
Имя: Диев Александр Васильевич
Благодарил (а): 60 раз
Поблагодарили: 44 раза

Передача данных через VPN канал.

Сообщение VADR » 10 янв 2018, 21:04

Спасибо, посмотрю обязательно.
Повторное использование кода не отменяет повторного использования мозга при его повторном использовании.

Аватара пользователя

Автор темы
VADR
администратор
администратор
Сообщения: 2851
Зарегистрирован: 25 июл 2008, 06:12
Имя: Диев Александр Васильевич
Благодарил (а): 60 раз
Поблагодарили: 44 раза

Передача данных через VPN канал.

Сообщение VADR » 12 янв 2018, 00:31

Этот I-Device - штука, безусловно, интересная, но...
Чойто я как-то не вник в эту тему. Делаю пример по мануалу, п.3.2, где в качестве I-Device выступает CP343-1 Lean. Всё создаётся и конфигурится, всё ОК. Делаю аналогичную (на мой взгляд :) ) конфигурацию на 1500-том контроллере. Беру контроллер, ставлю ему коммуникационник CP1543-1, пытаюсь в нём настроить IO-Device - а фигу... разрешает его сделать только IO-controller'ом. Зато позволяет настроить режим IO device у дублированных интерфейсов контроллера, которые сами по себе так и напрашиваются, чтобы свой ввод-вывод к ним подключать.

Отправлено спустя 1 минуту 19 секунд:
Возвращаясь к первоначальному вопросу: а Profinet вообще сквозь маршрутизаторы ходит или только в одноранговой сети?
Повторное использование кода не отменяет повторного использования мозга при его повторном использовании.

Аватара пользователя

Автор темы
VADR
администратор
администратор
Сообщения: 2851
Зарегистрирован: 25 июл 2008, 06:12
Имя: Диев Александр Васильевич
Благодарил (а): 60 раз
Поблагодарили: 44 раза

Передача данных через VPN канал.

Сообщение VADR » 12 янв 2018, 16:30

А в TIA Portal V14 с CM1542 всё получилось :)
Повторное использование кода не отменяет повторного использования мозга при его повторном использовании.


Михайло
почётный участник форума
почётный участник форума
Сообщения: 2630
Зарегистрирован: 10 ноя 2009, 04:58
Имя: Толмачев Михаил Алексеевич
Благодарил (а): 1 раз
Поблагодарили: 77 раз
Контактная информация:

Передача данных через VPN канал.

Сообщение Михайло » 12 янв 2018, 18:15

подробнее, подробнее, пожалуйста... :ges_clap2:

Аватара пользователя

Автор темы
VADR
администратор
администратор
Сообщения: 2851
Зарегистрирован: 25 июл 2008, 06:12
Имя: Диев Александр Васильевич
Благодарил (а): 60 раз
Поблагодарили: 44 раза

Передача данных через VPN канал.

Сообщение VADR » 12 янв 2018, 18:56

Ну, не то, чтобы совсем всё - получилось сделать I-Device на базе контроллера из серии S7-1500 и коммуникационника CM1542. А как именно - смогу описать только в понедельник, на домашней виртуалке у меня только 13-я версия есть. Впрочем, там получилось всё по мануалу. По памяти - примерно так:
1. Вставил в проект контроллер из 1500-й серии (кстати, выбор таких в 14-й версии намного больше).
2. В Device View прицепил к нему CM1542-1
3. Выбрал на нём PROFINET interface, в параметрах зашёл в Ethernet addresses, добавил подсеть и выставил IP-адрес. После этого в пункте Operating mode появилась возможность выбрать IO Device. Вот как раз сейчас проверяю - в 13-й версии такой для возможности CM1542-1 нет (для контроллера - есть).
Ну и дальше в Operating mode появился подпункт I-device communications, в котором можно задать Transfer area и откуда после компиляции hardware можно экспортировать GSD.
Под вопросом осталась правильность конфигурирования Media redundancy - когда в конфигурации нет Manager, нет возможности сделать его клиентом. Поставил Manager(auto), я думаю, это единственный способ сделать конфигурацию, которая потом оживёт при физическом соединении с аналогичными кусками из других проектов.
Ну а возможность распространения profinet за роутер также осталась под вопросом. Не посылает меня руководство на курсы по profinet :(.
Повторное использование кода не отменяет повторного использования мозга при его повторном использовании.


winb
осмотрелся
осмотрелся
Сообщения: 160
Зарегистрирован: 31 янв 2017, 08:44
Имя: Маркушин Андрей Геннадьевич
Благодарил (а): 6 раз
Поблагодарили: 26 раз

Передача данных через VPN канал.

Сообщение winb » 15 янв 2018, 09:01

По профинету за роутером... Вопрос - какой PROFINET? Если RT (realtime) - PROFINET IO, IRT - не нужен, то вполне себе пройдёт, стандарт PROFINET поддерживает стандартные TCP-UDP.
Если нужно RT прокинуть за маршрутизатор, то этот маршрутизатор должен "понимать" PROFINET IO/IRT. И если на уровне распределения вроде бы всё нормально должно быть, то на уровне маршрутизации - попечальнее, IP-то поддерживается, а остальные верхнеуровневые навороты "оптимизировали" (как эйчары персонал предприятия :)). В следствие чего "обычный" маршрутизатор может не понять, например, к какому VPN относится пакет PROFINET IO, и что с этим пакетом делать. В общем, нужно смаршрутизировать PROFINET IO - используйте специализированное оборудование.
Или не используйте PROFINET IO вообще - для передачи данных между цехами с задержкой в сотню-другую миллисекунд (если с сетями всё плохо, обычно - десятки миллисекунд) вполне хватит TCP соединения и нормально настроенного сетевого оборудования.

Аватара пользователя

Автор темы
VADR
администратор
администратор
Сообщения: 2851
Зарегистрирован: 25 июл 2008, 06:12
Имя: Диев Александр Васильевич
Благодарил (а): 60 раз
Поблагодарили: 44 раза

Передача данных через VPN канал.

Сообщение VADR » 15 янв 2018, 10:50

Насчёт специализированного оборудования - я как раз и смотрю на Scalance (впрочем, всё это пока что - теоретические изыскания и попытка компенсировать то, что меня на курсы по сименсовским сетям не отправляют). И отказаться от Profinet IO - тоже вариант. Тот же Modbus TCP прекрасно пройдёт через все VPN и роутеры. Но с Profinet IO разобраться всё-таки хочется...
Повторное использование кода не отменяет повторного использования мозга при его повторном использовании.


winb
осмотрелся
осмотрелся
Сообщения: 160
Зарегистрирован: 31 янв 2017, 08:44
Имя: Маркушин Андрей Геннадьевич
Благодарил (а): 6 раз
Поблагодарили: 26 раз

Передача данных через VPN канал.

Сообщение winb » 15 янв 2018, 13:17

Да тут скорее вопрос - зачем нужен PROFINET IO в данной ситуации? Высокая производительность и детерминированность доставки данных нужна больше на полевом уровне, где сети и строятся на специализированном (ну или на неуправляемом) оборудовании. Передача данных между производственными участками - уже немного другой уровень автоматизации, там обычно требования к реалтайму пониже. Я вообще не принимаю прямой выход полевых сетей на цеховой уровень - для этого и нужен Скаланс 6хх серии, правда я с ним не работал - стараюсь использовать CPU через отдельный коммуникационный интерфейс как шлюз в общую сеть для устройств контроллера. А там уже "сетевики" раскидывают оборудование по VLANам...
Отказываться от PROFINET в пользу MODBUS - менять шило на мыло, проще использовать TCP-соединение на уровне контроллера - сконфигурировать соответствующее одностороннее S7-соединение и через него работать.
Трудоёмкость:
1. Добавить 1 Unspecified S7-соединение, указав адрес шлюза.
2. Проработать протокол (в данном случае - выделить место под обмен, чаще всего в блоках данных)
3. Вызвать соответствующий коммуникационный блок (PUT, GET)
Всё. Из затрат - желательно использовать отдельный CP для подключения к внешней сети.
VPN-канал всё равно роутер обеспечивать будет, если допинговаться получиться, связь будет

Аватара пользователя

Автор темы
VADR
администратор
администратор
Сообщения: 2851
Зарегистрирован: 25 июл 2008, 06:12
Имя: Диев Александр Васильевич
Благодарил (а): 60 раз
Поблагодарили: 44 раза

Передача данных через VPN канал.

Сообщение VADR » 15 янв 2018, 13:38

winb писал(а):
15 янв 2018, 13:17
Передача данных между производственными участками - уже немного другой уровень автоматизации
Вот тут тема уже ближе к практике, с такой задачей я сталкивался и решалось это более геморным способом (прокидыванием кабелей из цеха в цех с риском получить проблемы из-за раздельных контуров заземления). Технология такая: конвейер подаёт сыпучий материал из одного цеха в другой. Исполнительный механизм - шнек с частотником в первом цехе, входит в его систему управления и проектируется первым пректировщиком. Измерение уровня в приёмном бункере - во втором цехе, соответственно - вторая система управления и второй проектировщик. Проекты, соответственно, разные. Из измерения и исполнительного механизма надо сделать контур управления. Вот на такой случай я и смотрю в сторону перекидывания данных от системы к системе.
winb писал(а):
15 янв 2018, 13:17
проще использовать TCP-соединение на уровне контроллера - сконфигурировать соответствующее одностороннее S7-соединение и через него работать
Я правильно понимаю, что стороны этого S7-соедниения можно сконфигурить в разных проектах и заставить работать вместе? Можно ссылочку на мануал? И, кстати, как оно диагностируется? Нужно ведь предусмотреть сценарий на случай обрыва связи...
Повторное использование кода не отменяет повторного использования мозга при его повторном использовании.


winb
осмотрелся
осмотрелся
Сообщения: 160
Зарегистрирован: 31 янв 2017, 08:44
Имя: Маркушин Андрей Геннадьевич
Благодарил (а): 6 раз
Поблагодарили: 26 раз

Передача данных через VPN канал.

Сообщение winb » 15 янв 2018, 14:04

Для контуров управления надежнее использовать всё-таки соединение через полевые шины, PN-PN Coupler, например. Зависимость производства от сетей общего назначения - мне не очень нравится, но при необходимости... Диагностика на уровне программных блоков - есть. А если совсем по-хорошему - только хардкор, только сети АСУТП (ну или телеуправления) :) Могу порекомендовать PN/PN Coupler - объём данных небольшой, обмен - быстрый, надёжность - высокая. Отдельный кабель сетевой тянуть придётся, конечно, но электрическая изоляция сетей в документации https://cache.industry.siemens.com/dl/ ... _en-US.pdf обозначена.
VADR писал(а):
15 янв 2018, 13:38
Я правильно понимаю, что стороны этого S7-соедниения можно сконфигурить в разных проектах и заставить работать вместе?
При работе через S7-соединение, его можно сконфигурировать и выполнять операции чтения-записи данных только на одном контроллере. Мануал сейчас не найду, но ссылка встречалась в теме: viewtopic.php?f=152&t=10016

Аватара пользователя

Автор темы
VADR
администратор
администратор
Сообщения: 2851
Зарегистрирован: 25 июл 2008, 06:12
Имя: Диев Александр Васильевич
Благодарил (а): 60 раз
Поблагодарили: 44 раза

Передача данных через VPN канал.

Сообщение VADR » 15 янв 2018, 16:30

winb писал(а):
15 янв 2018, 14:04
Зависимость производства от сетей общего назначения - мне не очень нравится, но при необходимости...
Тут речь не идёт о сетях общего назначения. Скорее - своя сеть для нужд АСУТП, через которую, в частности, внешняя система сбора данных собирает информацию с OPC-серверов и нет штатного доступа для иных пользователей. Ну и ещё одно из применений - обмен данными между системами. На 2-3-4 системах такое решение будет дороже отдельного кабеля, а дальше - уже не факт.
winb писал(а):
15 янв 2018, 14:04
При работе через S7-соединение, его можно сконфигурировать и выполнять операции чтения-записи данных только на одном контроллере.
А вот тут возникает вопрос безопасности. Читается/пишется всё просто и легко, но для этого надо будет открывать доступ для S7 к контроллеру, а это чревато появлением злоумышленника... Хотелось бы иметь возможность ограничить объем доступных данных и тип доступа - только для чтения.
Повторное использование кода не отменяет повторного использования мозга при его повторном использовании.


winb
осмотрелся
осмотрелся
Сообщения: 160
Зарегистрирован: 31 янв 2017, 08:44
Имя: Маркушин Андрей Геннадьевич
Благодарил (а): 6 раз
Поблагодарили: 26 раз

Передача данных через VPN канал.

Сообщение winb » 16 янв 2018, 07:19

Тогда можно использовать обычное Unspecified TCP соединение (AG_SEND/RECEIVE для СP, TSEND/TRECEIVE для встроенных интерфейсов). Если сети - свои, то риски падения сети можно считать приемлемыми. И S7-соединение не используется. При недостатке скорости, можно и UDP соединение замутить, в протокол обмена ввести подтверждение приёма телеграммы.


LexSL
здесь недавно
здесь недавно
Сообщения: 88
Зарегистрирован: 16 дек 2011, 14:13
Имя: Михайлов Алексей
Поблагодарили: 11 раз

Передача данных через VPN канал.

Сообщение LexSL » 17 янв 2018, 08:12

VADR писал(а):
15 янв 2018, 13:38
И, кстати, как оно диагностируется?
S7 соединения: функция

Код: Выделить всё

C_CNTRL(EN_R := true // IN: BOOL
    ,ID :=  IdConn// IN: WORD
    ,RETVAL := RetVal // OUT: INT
    ,ERROR :=  Error// OUT: BOOL
    ,STATUS :=  Status// OUT: WORD
    ,C_CONN :=  Connected// OUT: BOOL
    ,C_STATUS :=  ConnStatus// OUT: WORD
    ); // VOID
где ID - идентификатор соединения (номер в NetPro)

TCP соединения через CP модуль: функция

Код: Выделить всё

AG_CNTRL(ACT := true // IN: BOOL
         ,ID := 0 // IN: INT
         ,LADDR := WORD_TO_BLOCK_DB(_pt.DBNr).DW[Adr + 2] // IN: WORD
         ,CMD :=  CtrlCmd// IN: INT
         ,DONE :=  CtrlDone// OUT: BOOL
         ,ERROR :=  CtrlError// OUT: BOOL
         ,STATUS := CtrlStatus // OUT: WORD
         ,RESULT1 := CntrlRes1 // OUT: DWORD
         ,RESULT2 := CntrlRes2 // OUT: DWORD
         ); // VOID
где: ID = 0 означает диагностику всех соединений, CMD = выбор команды (например, 3 - диагностика, читать manual)
в RESULT1 содержится инфа 0..31 bits = ID 1 - ID 32 connection (0 - connection terminated/not configured, 1 - connection established)
в RESULT2 содержится инфа 32..64 bits = ID 33 - ID 64 connection (0 - connection terminated/not configured, 1 - connection established)
Сконфигурированные в NetPro соединения через CP устанавливаются автоматически (причем есть значение CMD, которое позволяет разорвать принудительно соединение).

TCP соединения через "бошку" (T блоки - T_CON, T_SEND, T_RECV, T_DISCON): читать, что возвращают функции (Open Communication via Industrial Ethernet)

Ответить

Вернуться в «Общие вопросы»