Штекеры и гнёзда цифровых портов Ethernet

[kirillio]

Приветствую всех!
Пытаюсь разобраться со штекерами. Понял, что зарылся.
Прошу подсказать, как правильно описывать стандартизированные разъемные соединения для многожильных кабелей, которые не требуют описания распиновки и соответствия контактов штырь-гнездо? Например Ethernet кабели и порты. Пример общего вида.

Снимок88.PNG

С графикой - всё понятно. Вопросы:
1. Для устройства с цифровым портом передачи данных правильно ли назначил определения и логику выводов?

Снимок9.PNG

2. Правильно ли обозначены определение и логика вывода оконечного устройства?

Снимок10.PNG

3. Для случаев, когда разъемные соединения должны выполняться разными типами штекеров (например RJ45, но где-то обычный, а где-то пыле-влаго-защищённый; по сути - расходный материал / запчасть) в какой части Е это уместно отразить данные о типах штекеров(изделий) ?.. Эти данные необходимы монтажникам в виде целевых указаний где какой тип использовать; также в конечном счёте эти данные должны отображаться в виде общего количества в спецификации. Как это исполнить пока не понимаю.

Конечная цель:
- получить таблицу коммутации (соединений) портов устройств.
- получить перечень штекеров и соответствия типа штекера устройству.
- перечень и количество штекеров по спецификации.
Пока как это сделать я не представляю. На данном этапе задача: получить пригодную для этого схему и описаний БД.

4. Устройство имеет группу пользовательских параметров адресации устройств. Пока я нашел для себя способ описывать эти параметры через группу свойств "Доп.поле n", но это чертовски не удобно. Может есть какие-либо более подходящие для этого поля или возможность переименования свойств?

Снимок11.PNG

Конечная цель:
- получить таблицу адресации устройств.

[kirillio]

"О сколько нам открытий чудных готовят просвещенья дух..." - по п.1 и 2 нужно было копать в сторону группы свойств "Вывод устройства ПЛК, кабель сети / коммуникационной шины".

[+]

Получается я промахнулся. Не перестаю удивляться - что не нажатие мышки, то целая вселенная. Это каким нужно обладать над-мозгом, чтобы такое изобрести?.. огогшеньки-ого-го!

Но любой информации от более опытных и ведающих в данной теме людей, я буду рад и премного благодарен.

[MVekb]

По п.4 нужно смотреть меню Параметры - Конфигурировать свойства:

Pict1.PNG

[kirillio]

По п.4 нужно смотреть меню Параметры - Конфигурировать свойства:

Благодарю Вас. В 2.9 это сидит в Данные проекта > Конфигурировать свойства...
Да, таким образом решаемо. Для описания Ethernet соединений такой подход - это чистой воды рукопашный колхоз. Правильно использовать встроенный функционал группы свойств "Вывод устройства ПЛК, кабель сети / коммуникационной шины" - там уже зашита туева хуча протоколов, в т.ч. и Ethernet. Правда, есть сложность: логика IT-специалиста, логика программиста-разработчика, логика переводчика и логика пользователя еплан - это 4 разных логики; мозг вскипает в попытке понять "а что же те парни имели ввиду?", когда писали это...

[+]

Снимок12.PNG

Снимок13.PNG

Непонятно вследствие чего вывалилась ошибка "Неправильное соединение с конкретным портом..."

[mf_]

"а что же те парни имели ввиду?", когда писали это...

Адрес - внутренний адрес (или адрес в памяти) вывода ПЛК, например, Q1.1. Символический адрес, я так понимаю, наименование тэга, привязанного к этому выходу ПЛК, например, START_MOTOR. Если вывод шины, значит символический адрес ПЛК, например, PLC1.
По-моему так... (с)

А на втором скриншоте это не ошибка. Из хэлпа:
"В информационной области под этим полем отображается дополнительная информация о выбранной системе шин, связанной с поведением во время обмена данными ПЛК. При этом отображаются комбинации следующих записей:

Неправильное соединение с конкретным портом: эти системы шин можно экспортировать с подробным соединением портов.
Физическая сеть: эти системы шин формируют физическую сеть.
Логическая сеть: для этих систем шин также экспортируется логическая сеть, указанная в свойстве Логическая сеть: Имя."

[kirillio]

..это не ошибка. Из хэлпа..

Ага, я уже нашёл и понял, что это подсказка, а не сообщение ошибки. :)

"Неправильное соединение с конкретным портом: эти системы шин можно экспортировать с подробным соединением портов.
Физическая сеть: эти системы шин формируют физическую сеть.
Логическая сеть: для этих систем шин также экспортируется логическая сеть, указанная в свойстве Логическая сеть: Имя."

мой мозг никак не может это воспринять... :))) особенно слово "шины" в контексте ethernet с его топологией "точка-точка"

[keysansa]

"О сколько нам открытий чудных готовят просвещенья дух..." - по п.1 и 2 нужно было копать в сторону группы свойств "Вывод устройства ПЛК, кабель сети / коммуникационной шины".

Да, я тоже пытался использовать данные типы вывода контроллера, однако:
1. Они не согласуются друг с другом. Т.е. устройство, подключенное ко второму с данным соединением, вызывает несоответствие при прогоне (устройство использует больше функций).
2. Как в спецификации разъемов, указать, например, что в некоторых случаях используется прямой кабель Ethernet по варианту обжимки A, а во втором - кросс?

ЗЫ. На сегодня, я нашел только один вариант - использовать жгуты - компактнее прямых соединений, но так же информативно.

[kirillio]

2. Как в спецификации разъемов, указать, например, что в некоторых случаях используется прямой кабель Ethernet по варианту обжимки A, а во втором - кросс?

С этим-то как раз проще всего, как мне кажется: отразить в каком-либо поле ОУ тип штекера RJ45.A - для кросс-кабеля и RJ45.B - для прямого, а в общих указаниях листа ОД делать отсылку к EIA/TIA 568A и 568B. Либо любую иную схему не стандартизированной распиновки, с отсылкой на отдельный лист схемы с указаниями.

[kirillio]

Они не согласуются друг с другом. Т.е. устройство, подключенное ко второму с данным соединением, вызывает несоответствие при прогоне

В принципе, в первом приближении, удалось подружить порты, ключевые прогоны вроде ОК за исключением пары.

[+]

"Отсутствует определение штекера"
"Наличие нескольких ОУ, слишком много главных функций"
пока не придумал из-за чего и что с этим делать

В отчеты по штекерам данные тоже высыпаются. Далее дело за настройкой и подгонкой шаблонов для отчётов.

[+]

Архив проекта. Ссыль какое-то время поживёт, если вдруг кому интересно - лист принципиальной схемы смотрите, принципиальны настройки логики соединений. https://cloud.mail.ru/public/bUKQ/v1s15pZL3

Касательно своих слов об описании Ethernet соединений, мол

...такой подход - это чистой воды рукопашный колхоз. Правильно использовать встроенный функционал группы свойств "Вывод устройства ПЛК, кабель сети / коммуникационной шины"...

то, либо я чего-то не понял, либо на поверку "рукопашный колхоз" не такой уж и колхоз, а вполне себе рабочий (если не единственный) вариант. Для описания одноранговой сети построенной по принципу "из дырки-в-дырку, без заморочек" - встроенных полей достаточно, тут я понимаю как собрать (а значит и запихнуть в отчёт) данные IP-адресации, но как только сеть в параметрах немного сложнее и замороченнее - упс, тупик. Буду думать.
PS Приветствую любые замечания, предложения и мысли по теме.

[mf_]

но как только сеть в параметрах немного сложнее и замороченнее - упс, тупик. Буду думать.

А в чём тупик, например?

Мне как-то не приходилось использовать штекеры, и неприятным открытием для меня оказалось, что кабель в этом случае подключается штекер-штекер, а не устройство-устройство. У Вас в спецификации кабеля от W1 до W1, что неинформативно совсем.

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

[kirillio]

А в чём тупик, например?

На 4 скриншоте топикстартера неполный перечень параметров. В полном (расширенном) составае могут фигурировать, например:
IP-адрес порта, IP-адрес хоста, маска подсети, IPадрес шлюза, DNS1, DNS2, MACадрес, VLAN_ID, протоколы, номера портов TCP/UDP, имя физической сети, имя логической сети. Данные параметры актуальны для уровня сети L2/L3 и редко нужны для описания полевой сети. Полей, описывающих цифровые порты и каналы, которые я нашел в еплан (возможно не там искал или не всё правильно понял), полагаю, явно маловато и нужно что-то добавлять. Поэтому решением для данной версии Е могут быть пользовательские "Доп.поле N"

в спецификации кабеля от W1 до W1, что неинформативно совсем

Согласен. Целью было задать в Е правильную логику соединения, получить отсутствие конфликтов, увидеть и понять при таком описании соединения какой "некий_символ" в какую часть отчёта попадает. Допиливание формы отчёта и доводка процесса - это уже второй шаг, после того как соединение собралось.

Не исключаю, что это намеренное несоответствие для упрощения процесса.

Именно так. Потому что..

...стандартизированные разъемные соединения для многожильных кабелей, которые не требуют описания распиновки и соответствия контактов штырь-гнездо...

и

а в общих указаниях листа ОД делать отсылку к EIA/TIA 568A и 568B

Я не понял причин ошибок при прогоне "Отсутствует определение штекера" и "Наличие нескольких ОУ, слишком много главных функций". Определить штекер не получилось. Может кто-то растолковать?

[mf_]

Я не понял причин ошибок при прогоне "Отсутствует определение штекера" и "Наличие нескольких ОУ, слишком много главных функций". Определить штекер не получилось. Может кто-то растолковать?

Со вторым всё просто.

Снимок.PNG

Переименуйте один из штекеров и ошибка уйдёт. Это же разные устройства.

Отправлено спустя 16 минут 8 секунд:
А вот таким образом и первой ошибки нет.

Снимок1.PNG

[keysansa]

В принципе, в первом приближении, удалось подружить порты, ключевые прогоны вроде ОК за исключением пары.

"Наличие нескольких ОУ, слишком много главных функций"

Вот именно это и не дает мне покоя. Причем, как только располагаешь его на схеме - все ок. Чуть изменения (не касающиеся данного соединения), все потерялся вход в изделии и вылез другой.

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

С этим-то как раз проще всего, как мне кажется: отразить в каком-либо поле ОУ тип штекера RJ45.A - для кросс-кабеля и RJ45.B - для прямого, а в общих указаниях листа ОД делать отсылку к EIA/TIA 568A и 568B. Либо любую иную схему не стандартизированной распиновки, с отсылкой на отдельный лист схемы с указаниями.

Ну, чисто для визуализации - да, можно и в функциональный текст добавить сведения про 568А/568В.

[kirillio]

как только располагаешь его на схеме - все ок. Чуть изменения (не касающиеся данного соединения), все потерялся вход

Спасибо, учту. Попробую покрутить-вертеть.

[mf_]

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

Предлагаю посмотреть в сторону выводов ПЛК с функцией "Кабельный вывод сети / шины, общее". Там эти параметры присутствуют. Может быть это то, что нужно?

Снимок1.PNG

[kirillio]

посмотреть в сторону выводов ПЛК с функцией "Кабельный вывод сети / шины, общее". Там эти параметры присутствуют. Может быть это то, что нужно?

Я тоже так думал сначала...

по п.1 и 2 нужно было копать в сторону группы свойств "Вывод устройства ПЛК, кабель сети / коммуникационной шины".

Повторюсь, для описания одноранговой сети (как правило это уровень полевой сети Ethernet) этих параметров достаточно, ту вопросов нет. Но как только вам потребуется где-то что-то маршрутизировать, например, для уровня АСУ-Д или территориально распределенных объектов, тут уже может чего-то не хватить. Тут неподалёку есть жаркая ветка про информационную безопасность в АСУТП, это вот как раз для этих нужд актуально. Когда у вас на предприятии выделенная изолированная технологическая локальная сеть передачи данных АСУ, с ограниченным и контролируемым доступом к узлам коммутации и связи, то в таких заморочках вряд ли есть необходимость.

keysansa,

чисто для визуализации - да

да и без визуализации, при отражении этих данных в типе штекера, высыпать их в отчёт по штекерам оказалось что не проблема совсем.

[MaksimS]

Может быть в data portal есть хороший пример как конфигурировать Ethernet?

[kirillio]

Может быть в data portal есть хороший пример как конфигурировать Ethernet?

Из того что смотрел (циско, Шнайдер, феникс) - вообще не парятся ребята, тупо выход "всё-во-всё".

[keysansa]

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

Ну, на схеме правила маршрутизации не укажешь, как и используемые приложения... Хотелось бы, но нет... Отдельным документом пока.

[kirillio]

Ну, на схеме правила маршрутизации не укажешь, как и используемые приложения... Хотелось бы, но нет... Отдельным документом пока.

Это почему же?.. особенно, для случаев, когда этих правил - как кот наплакал.
Интереса ради, могли бы Вы, Сергей, подсветить пример того "отдельного документа", которым Вы оформляете правила маршрутизации?
Я это делаю на листе в параметрах порта/кабельной линии. Если чегото много получается, то в таблице+тексте, на том же листе.

[keysansa]

Интереса ради, могли бы Вы, Сергей, подсветить пример того "отдельного документа", которым Вы оформляете правила маршрутизации?
Я это делаю на листе в параметрах порта/кабельной линии.

Могу, чутка позже. Но обслуживать маршрутизацию и безопасность нанимают отдельных людей, которые чаще всего электрические схемы читать умеют. У них свои схемы и журналы, которые часто и ДСП гриф имеют.
Я согласен, что IP адреса на схеме - очень удобно и помогает (а еще номера узлов Modbus RTU, Profibus), но

[kirillio]

Могу, чутка позже. ... У них свои схемы и журналы, которые часто и ДСП гриф имеют.

Данные и конкретное содержание меня не интересуют, а вот общий принцип и структура документа, с целью раскрытия сути работ по маршрутизации и оптимизации информационной подачи - буду Вам очень признателен.

PS Задаю вопрос, т.к. в своей практике пока мне не доводилось иметь дело со столь дифференцированным подходом к организации сетевой безопасности в процессе эксплуатации (т.е. когда наладчики - налаживают, админы - админят, безопасники - безопасят; и у каждого свой журнально-бумажный кодекс + собственные правила и практики); слышать - наслышан, сталкиваться - не доводилось.